Опубликовано Автор: dmitry

Chillispot — ещё тот «перец»!..

К одной из моих заметок прислали комментарий — «Да это же очевидно!». Абсолютно согласен! В блоге своем я пишу что-либо только после того, как уже разобрался с этим, и для меня то, что я написал тут тоже стало уже «очевидным». Но, до этого — зачастую приходится основательно перелопатить интернет, форумы, блоги и т.п. Вот возьмем, к примеру, тот же Chillispot 🙂 …

Начнем с простейшего — во многих интернет-источниках адрес сайта Chillispot указан как http://www.chillispot.org/. Но на сегодняшний день (и как пишут, это длится еще с середины 2007 года) сайт этот не существует, а информация, загрузки, FAQ, форум и пр. теперь находятся по новому адресу — http://www.chillispot.info/. Но к этому мы вернемся позже, а пока…

Вступление

Собственно, что это такое и зачем оно надо. Chillispot — это контроллер доступа. Его задача в максимально общей формулировке — пускать пользователей из одного сегмента сети в другой. То есть, если уже «приземленно», то с одной стороны (во внутренней подсети) находятся клиенты, а с другой стороны — бескрайние просторы интернета. И Chillispot с одной стороны на основании информации от сервера авторизации либо пускает этих клиентов в сеть либо нет. А с другой стороны, Chillispot осуществляет взаимодействие с сервером учета Radius, благодаря чему поставщик услуг (провайдер) знает сколько клиент провел времени в интернете, а также какой объем информации клиент принял и отдал в интернет. И, если совсем уж без намеков — Chillispot чаще всего используется тогда, когда кто-то хочет создать хотспот, работающий под управлением ОС Linux, и управляемый каким-нибудь биллингом, взаимодействующим с Chillispot посредством Radius-а.

При этом непосредственно Chillispot выполняет три задачи:

  1. Формирует LAN-подсеть для клиентов хотспота. Для этого он сам выступает в роли DHCP-сервера, раздавая клиентским компьютерам IP-адреса.
  2. Взаимодействуя с сервером RADIUS работает контроллером доступа, не пропуская в интернет неавторизованных клиентов, и предоставляя доступ с указанными (RADIUS-ом) параметрами — авторизованным.
  3. Предоставляет клиентам страницу авторизации (специальную веб-страницу) на которой они могут ввести логин и пароль, чтобы попасть в интернет.

Существует целый класс аппаратных устройств, у которых есть и своё собственное название — NAS (Network Access Server — сервер доступа в сеть). Chillispot можно считать «программным» NAS. Кстати, аббревиатуру запоминайте — она нам еще встретится при настройке…

1. Подготовка

Что нам нужно.

  • Две сетевые платы — одна из которых «смотрит» в интернет, а вторая — во внутреннюю подсеть. Примем как исходное условие, что плата, «смотрящая» в интернет (WAN), в нашем Linux имеет обозначение eth0, а та, которая обращена во внутреннюю подсеть (LAN) — eth1. Номера эти тоже запомним — это также потребуется в процессе настройке.
  • Для сетевой платы, посредством которой компьютер подключен в интернет (WAN/eth0) ДОЛЖНО БЫТЬ НАСТРОЕНО ВСЁ! То есть, настройки его адреса, шлюза, маски подсети и пр. либо же работающий DHCP-клиент, одним словом, этот компьютер должен «нормально ходить в интернет». Для сетевой платы, к которой подключаются пользователи (LAN/eth1), в Linux НИЧЕГО НАСТРАИВАТЬ НЕ НУЖНО. Linux должен ее только лишь определить и «подставить» соответствующий драйвер. Chillispot сам «поднимет» на указанном интерфейсе все необходимое для подключения пользователей — DHCP-сервер и т.д и т.п.
  • В системе должен присутствовать модуль TUN-драйвера. Как утверждают, модуль этот присутствует в ядре Linux уже достаточно давно (не помню, начиная с какой версии), но по умолчанию он не загружается автоматически при старте системы.  По-этому, его предлагают включать в список модулей автоматически загружаемых при запуске системы (файл /etc/modules). Но, просмотрев скрипт запуска Chillispot, я увидел, что при его выполнении обязятельно запускается и модуль TUN-драйвера. По этому никаких дополнительных действий предпринимать я не стал. Как проверить, есть ли драйвер в системе? В консоли от имени root-а запускаем комманду (выделена синим)  и видим ответ (выделен оранжевым цветом):
[root@my-svr etc]# modprobe -l -a tun 

/lib/modules/2.6.24.7-desktop-2mnb/kernel/drivers/net/tun.ko.gz
  • Настроенный RADIUS-сервер. Именно он хранит записи о клиентах, имеющих доступ в интернет, а также результаты подсчета их времени и трафика. Собственно, у меня к этому времени уже был установлен и настроен FreeRADIUS.
  • Работающий веб-сервер с поддержкой SSL. Тут с меня советчик плохой — лично я себе по-быстренькому поставил apache-ssl, а чтобы он не мешал основному apache, запретил ему в конфиге «слушать» порт 80. На что стоит обратить внимание при таком, по сути, «варварском» подходе — файл конфигурации «секурного» сервера (это отдельный сервер, а не mod_ssl к обычному apache)  свой собственный и находятся в отдельной папке — /etc/httpsd/conf/httpsd.conf. Также отдельно расположена и папка html-документов этого сервера (/var/lib/httpsd/html), и папка cgi-скриптов (/var/lib/httpsd/cgi-bin). Думаю, правильнее будет все-таки воспользоваться одной из многочисленных инструкций, имеющихся в интернете, и настроить «обычный» apache с использованием mod_ssl. Но, при любом из подходов нужно будет, во-первых, запомнить папку в которой должны размещаться cgi-скрипты (потребуется при настройке), а во-вторых, «обзавестись» ssl-сертификатами для Вашего сервера. «По умолчанию», при установке apache с mod_ssl папка, куда нужно будет положить cgi-скрипт «безопасной» авторизации  это /var/www/cgi-bin (для случая моей установки на Mandriva), а ssl-сертификаты генерируются «автоматом» на этапе установки указанных пакетов. Лично я сертификаты для себя сгенерировал самостоятельно, воспользовавшись следующей командой, найденной мною где-то на просторах интернета (будьте внимательны, это одна строка):

openssl req -new -newkey rsa:4096 -nodes -keyout /etc/ssl/ca/ca.key -x509 -days 3650 -subj /C=UA/ST=Ukraine/L=Zaporozhye/O=EI/OU=IT/CN=my.server.adres/emailAddress=my@adres.com -out /etc/ssl/ca/ca.crt

Естественно, персональные данные (выделенные красным) в команду Вы подставляете свои собственные. Особое внимание нужно обратить на имя сервера, которое Вы впишите в команду — оно должно быть в точности таким же, как ответ Вашего компьютера на команду «hostname -f«. Также обратите внимание на ту часть команды — «/etc/ssl/ca/«,  которая обозначает путь, куда будут записаны сформированные сертификат и ключ (в команде присутствует дважды!!!).  Дополнительно почитать про сертификаты можно еще по следующим адресам:

  1. http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#ownca
  2. http://www.opennet.ru/base/dev/apache_mod_ssl.txt.html
  3. http://forum.oszone.net/thread-68700.html

После генерации сертификатов прописываете их использование в файл конфигурации сервера apache-ssl (ну или apache с mod_ssl). Это конечно не избавит в дальнейшем от сообщений браузеров об неизвестном центре сертификации, т.к. сертификаты «самоподписанные», но те, кого это не устраивает, могут приобрести настоящие сертификаты. Существует еще одна возможность, на тот случай, если у Вас есть возможность разместить свой скрипт на безопасном сервере, доступном с того компьютера, на котором планируется разместить Chillispot, Об этом — ниже…

2. Установка

Чем (для меня) хорош дистрибутив Mandriva? Обилием программ в «родных» репозиториях! Запустите «Центр управления», выберите «Установку и удаление программ», введите в поле поиска желаемое, и с определенной долей уверенности можно утверждать, что «оно там найдется»… Так же было и с Chillispot — он оказался в списке доступных пакетов, я всего-лишь поставил «птичку» и нажал кнопку «Применить»…

(Ничто не вечно под луной… Пока я собирался описать установку Chillispot, вышел новый дистрибутив Mandriva — версии 2009.1, в пакетах которого Chillispot, увы, уже  не оказалось. Но, на проверку, преспокойно устанавливается и работает пакет от дистрибутива версии 2009.0).

На всякий случай, я сохранил пакет у себя на FTP в соответствующей папке.

3.  Конфигурирование

Вся конфигурация Chillispot описывается одним единственным файлом — /etc/chilli.conf. Каждый параметр в нем прокомментрирован, единственное «неудобство» — «как всегда», на английском. Кроме того, можно в консоли запустить команду

chilli --help

, которая выведет подсказку с параметрами. Следует учесть (и это сказано в man к chilli, но как-то не явно), что все те параметры, которые выводит подсказка , могут быть прописаны в файл конфигурации /etc/chilli.conf, единственное — писать их нужно без двойного дефиса («—»).  Перейдем непосредственно к файлу конфигурации. Во-первых, обратите внимание на несколько фраз из комментариев к параметрам.

  • Фраза «For most instalation you need to modify this tag» обозначает, что данный параметр скорее всего Вам придется изменить с учетом потребностей и параметров Вашей инсталяции.
  • Фраза «Normally you do not need to uncomment this tag» обозначает, что если Вы не хотите «наконфигурировать» что-то совсем нетрадиционное и экстравагантное, не надо раскомментировать строку с данным параметром. Это не означает, что параметр не будет установлен. Будет использовано его значение «по-умолчанию», которое обычно устраивает почти все 100% пользователей.
  • Фраза «Do not uncomment this tag unless you are an experienced user» рекомендует не раскомментировать данный параметр, если Вы не являетесь опытным пользователем. (Практически, как старые таблички «Не влезай, убьет!»).

Теперь о самих параметрах. Все их я описывать не буду, опишу лишь те, которые необходимо было изменить. (Параметры выделены жирным, их значения — красным).

radiusserver1 127.0.0.1 — адрес (1-го) сервера RADIUS, у которого Chillispot запрашивает данные при авторизации клиентов.  То есть, чтобы Chillispot пропустил в интернет пользователя с «такими-то» логином и паролем, этот пользователь именно с этими логином и паролем должен быть записан в базе пользователей данного RADIUS-сервера. В моем случае указан адрес 127.0.0.1, так как мой RADIUS-сервер расположен (установлен) на том же самом компьютере, что и Chillispot. В качестве параметра можно указывать как ip-адрес, так и имя (например server.radius.net) сервера.

radiusserver2 127.0.0.1 — адрес (2-го) сервера RADIUS. Как пишут в комментарии к данному параметру, если Вы используете только один RADIUS-сервер, то в данном параметре укажите то же самое значение, что и для radiusserver1. Нигде явно  это не сказано, но рискну предположить, что данный параметр указывает на RADIUS-сервер аккаунтинга (того, который считает потребленные пользователем время и трафик). И в случае такой вот (раздельной) инсталяции, когда один RADIUS-сервер используется для авторизации, а второй для подсчета, данный параметр должен указывать на сервер учета. Но у меня нет возможности проверить правильность данного предположения… В моем случае указан адрес 127.0.0.1, так как у меня используется один RADIUS-сервер. В качестве параметра можно указывать как ip-адрес, так и имя (например server.radius.net) сервера.

radiussecret testing123 — пароль, который Chillispot использует при обмене с RADIUS-сервером. Данный пароль позволяет Вам быть уверенным в том, что никто другой не влезет в Ваш RADIUS-сервер (естественно, если Вы изменили пароль на свой собственный, а не оставили тот, что указан тут и который является паролем по умолчанию используемым на всех инсталляциях «с  нуля»). Что следует учесть при смене пароля. Как и любой пароль, его «должны знать двое». То есть, если Вы меняете этот пароль на свой собственный тут (в настройках Chillispot), то его нужно сменить и в настройках RADIUS-сервера! У RADIUS-сервера настройка данного параметра (в простейшем случае) находится в файле «/etc/raddb/clients.conf«. Комментариями там все это «разбавлено прилично», но если их выкинуть, то выглядеть все это будет так:

client localhost {
	ipaddr = 127.0.0.1
	secret		= testing123
	require_message_authenticator = no
	nastype     = other	# localhost isn't usually a NAS...
}

Как видим, присутствующий в списке параметр «secret» имеет то же самое значение — «testing123». Таким образом, меняя пароль в настройках Chillispot, необходимо изменить его и в настройках RADIUS-сервера в файле /etc/raddb/clients.conf. Если же Ваш RADIUS-сервер хранит настройки клиентов в SQL-базе, то менять нужно там. Как это сделать — решаете самостоятельно.

Возвращаемся к настройкам Chillispot.

dhcpif eth1 — номер (идентификатор) сетевой платы,  к которой подключены пользователи («сторона LAN»). Ее номер мы указывали в самом начале в условиях, помните? Для данной платы в Linux НИЧЕГО НАСТРАИВАТЬ НЕ НУЖНО. Linux должен ее только лишь определить и «подставить» соответствующий драйвер. Chillispot сам «поднимет» на указанном интерфейсе все необходимое для подключения пользователей — DHCP-сервер и пр. Что еще важно учесть — между Chillispot и пользователями (в случае необходимости) должно устанавливаться только т.н. «dumb»-оборудование, т.е., простые коммутаторы (switch), хабы (hub)  или точки доступа (AP). Использовать функции  NAT, masquarade, route, firewall  между Chillispot (выходом eth1) и пользователями нельзя.

#net 192.168.182.0/24 — данный параметр, как видите, в моих настройках остался закоментированным. Но он имеет непосредственное отношение к только что описанному параметру dhcpif. Параметр этот задает маску подсети LAN. То есть, сам Chillispot как шлюз будет виден под адресом 192.168.182.1, а пользователям при их подключении будут предоставляться адреса в диапазоне от 192.168.182.2 до 192.168.182.254. Параметр этот рекомендуют как раз не менять без особой нужды. Но, если «вдруг что», то Вы можете изменить номер самой подсети (например, 192.168.1.0). При этом важно, чтобы номер внутренней подсети не совпадал с внешней (если, допустим, Ваш компьютер подключен к ADSL-маршрутизатору). С другой стороны, может случиться так, что 250-и возможных пользователей Вам окажется мало. На этот случай, в FAQ, размещенном на сайте Chillispot, предлагают сменить маску подсети (указать значение параметра как net 192.168.182.0/20, ну и, естественно, раскомментировать его).

uamserver https://192.168.182.1/cgi-bin/hotspotlogin.cgi — страница авторизации (UAM — Universal Authorisation Metod).  Данный параметр указывает на  расположение страницы, которая позволяет пользователям вводить логин и пароль для доступа в интернет. Причем, на расположение ее в (скажем так) «внешней» адресации (URl), а не в виде «/var/www/cgi-bin/hotspotlogin.cgi».  Именно ради возможности размещения и обслуживания этой страницы нам и был нужен «защищенный» веб-сервер.  Страница авторизации НЕ ОБЯЗАТЕЛЬНО должна находиться на том же самом сервере, где установлен Chillispot. Помните, с самом начале я говорил, что можно использовать «чужой» веб-сервер. В таком случае, его адрес (включая и месторасположение самой страницы авторизации) нужно будет указать ИМЕННО В ЭТОМ параметре.  При этом, кроме того, потребуется разрешить доступ к указанному адресу без авторизации (см. ниже). Как видите, при авторизации пользователь перенаправляется на страницу, обмен с которой происходит с использованием SSL-шифрования (адрес начинается как https://). Данная страница (а точнее скрипт, написанный на языке perl) поставляется в пакете с Chillispot и после его установки находится в папке /usr/share/doc/chillispot/.  Данный скрипт нужно скопировать в папку, в которой Ваш веб-сервер хранит И ОБРАБАТЫВАЕТ исполняемые CGI-скрипты. Для случая использования apache с mod_ssl это папка /var/www/cgi-bin. А в «моем» случае использования отдельного сервера apache-ssl — папка /var/lib/httpsd/cgi-bin.  После того, как файл скопирован, его нужно сделать исполняемым (команда chmod +x hotspotlogin.cgi) а также назначить владельцем этого файла того пользователя, от имени которого запущен веб-сервер (в моем случае — chown apassl:apassl hotspotlogin.cgi, в Вашем — посмотрите в файлах конфигурации apache).  После этого данный файл ПОЧТИ готов к использованию, но об этом ниже.

#uamhomepage http://192.168.182.1/welcome.html — страница приветствия. Как видите, в моем случае этот параметр не используется. Что это за страница такая? Краткое описание работы Chillispot (возможно с него стоило начать?!..):

Когда неавторизованный (еще) пользователь из внутренней сети (LAN) пытается получить доступ к интернету (WAN), Chillispot перехватывает его запрос и пользователь перенаправляется на страницу авторизации по адресу, как указано в параметре uamserver (см. выше).  В «выпрыгнувшем» окошке пользователю предлагается ввести логин и пароль. Полученные значения логина и пароля Chillispot отправляет на проверку серверу RADIUS. Если они верны (RADIUS-сервер отвечает утвердительно), то Chillispot предоставляет пользователю полный доступ в интернет. Пользователь перенаправляется на запрошенный им адрес.  Вот так вкратце работает Chillispot.

С другой стороны, есть возможность перенаправить такого пользователя сначала не на страницу ввода логина и пароля, а на т.н. «страницу приветствия». На этой ОБЫЧНОЙ веб-странице Вы можете разместить любую информацию, которую посчитаете нужной (рекламу, правила пользования, еще что-то)… Вот адрес именно такой «страницы приветствия» и нужно указать как значение параметра uamhomepage. Ну и, естественно, раскомментировать строку с этим параметром. Что еще нужно учесть при этом? Первое — если эта страница находится на другом сервере (а такое тоже допускается), доступ к ней должен быть разрешен без авторизации (см. ниже). Далее — на этой странице обязательно должна присутствовать ссылка, вызывающая то самое всплывающее окошко ввода логина и пароля. Адресс такой — http://192.168.182.1:3990/prelogin (правильнее — адрес вида http://chilli.login.server:3990/prelogin, где абстрактное chilli.login.server обозначает адрес сервера, на котором расположена страница авторизации (нужно подставить РЕАЛЬНОЕ значение)). И последнее — в случае использования страницы приветствия автоматической переадрессации пользователя после успешной авторизации по запрошенному им адресу НЕ ПРОИСХОДИТ. Таким образом, если параметр uamhomepage задан (адрес страницы указан, и строка раскомментирована), то пользователь при авторизации будет переходить на страницу приветствия. Если же нет, то сразу на страницу ввода логина и пароля.

uamsecret ht2eb8ej6s4et3rg1ulp — пароль, который Chillispot использует в своем обмене данными со страницей авторизаци (hotspotlogin.cgi). По умолчанию эта строка закоментирована. Пусть этот факт не вводит Вас в заблуждение — это не значит, что пароль не используется! Это значит, что используется его значение по умолчанию! Почему я так заостряю на этом Ваше внимание? Помните, я написал ранее, что файл hotspotlogin.cgi почти готов к использованию? Дело в том, что в нем использование этого самого пароля по умолчанию ОТКЛЮЧЕНО! Таким образом, чтобы получить РАБОТАЮЩУЮ страницу авторизации, ее (т.е. файл hotspotlogin.cgi) нужно открыть в любом нравящемся Вам текстовом редакторе, найти (практически в самом начале) строки:

#$uamsecret = "ht2eb8ej6s4et3rg1ulp";
#$userpassword=1;

и раскомментировать их! Первая из строк задает тот самый пароль (который нужно указать, желательно все-таки свой собственный а не «умолчательный», и, естественно, одинаковый, для обоих конфигурационных файлов — chill.conf и hotspotlogin.cgi). Вторая строка включает использование этого пароля скриптом hotspotlogin.cgi. Если Вы забудете это сделать, то окно авторизации будет все время выдавать ошибку…

#uamallowed www.chillispot.org,10.11.12.0/24 — адреса (страницы, имена, подсети), доступ к которым разрешен пользователю без авторизации. Если адресов много (как в примере), то они разделяются запятыми. Как видите, параметр по умолчанию закоментирован. В данном случае он не используется. Если же Вам необходимо предоставить пользователям доступ к каким-либо внешним страницам без/до/для (!!!) авторизации, то их нужно указать тут и раскомментировать строку. Это может потребоваться, например, в случаях использования внешних («чужих») страниц авторизации и/или приветствия,  описанных выше.

#dns1 172.16.0.5

и

#dns2 172.16.0.6 — адреса первого и второго серверов DNS. Эт о адреса серверов DNS, которые Chillispot по dhcp выдает клиентским компьютерам. По умолчанию эти строки закоментированы. Это не значит, что клиентские компьютеры не получат адресов DNS. Это значит, что не используются принудительное их указание в файле настроек  Chillispot-а. В таком случае (когда эти параметры закомментированы) адреса DNS-серверов используются из настроек сетевой платы WAN-интерфейса (eth0) самого компьютера с Linux на котором установлен и запущен Chillispot. При желании Вы можете использовать собственные значения — их нужно указать, а строки раскомментировать.

Последние два параметра я добавил в файл chill.conf сам. На этой странице для того, чтобы иметь возможность оключать пользователя согласно сецификации RADIUS, рекомендуется запускать Chillispot с параметрами –coaport 3799 и –coanoipcheck. Но, как сказано в man к chilli эти параметры можно указать и в файле конфигурации chill.conf. Что я и сделал:

coaport 3799
coanoipcheck

4. Еще чуть-чуть и запускаем…

До полной работоспособности Chillispot осталось сделать самую малость. Но важную «малость». Во первых, нужно включить опцию ip forvarding в настройках системы. Для этого в текстовом редакторе  открываем файл /etc/sysctl.conf и добавляем в него следующую строку:

net.ipv4.ip_forward = 1

Чтобы форвардинг заработал сразу (без перезагрузки всей системы), перезапускаем поддержку сети командой:

/etc/init.d/network restart

Во-вторых, с Chillispot поставляется скрипт правил файервола, который необходимо запускать при загрузке системы. Сразу после установки файл этот находится в папке /usr/share/doc/chillispot/ и называется firewall.iptables. Открываем его в редакторе и смотрим на значения, присвоенные двум переменным (в самом начале файла) — EXTIF=»eth0« и INTIF=»eth1«. В качестве значения переменной «EXTIF» (внешний интерфейс) должна быть указана сетевая плата, «смотрящая» в интернет. А в качестве «INTIF» (внутренний интерфейс) — плата, к которой подключаются пользователи (точка доступа). В самом начале данной заметки, в исходных условиях мы приняли, что к интернету у нас подключен интерфейс eth0, а к точке доступа — eth1. Таким образом, значения указанных параметров нас устраивают целиком и полностью. Если же подключение выполнено наоборот, то нужно соответствующим образом изменить и значения этих двух параметров, указанные в файле firewall.iptables. Разобравшись с настройками и сохранив изменения (если таковые были), выходим из текстового редактора и копируем файл правил в папку, где расположены все скрипты, выполняющиеся при запуске системы:

cp /usr/share/doc/chillispot/firewall.iptables /etc/init.d/firewall.iptables

Затем файл /etc/init.d/firewall.iptables делаем исполняемым:

chmod +x /etc/init.d/firewall.iptables

И после этого просто запускаем его:

/etc/init.d/firewall.iptables

Что еще по поводу файервола? В правилах, поставляемых с Chillispot не учтена необходимость открытия порта, используемого для того, чтобы иметь возможность оключать пользователя согласно сецификации RADIUS. На уже упоминавшейся странице можно посмотреть или даже прямо скопировать содержимое файла firewall.iptables с уже открытым для этой цели 3799-м портом. Это может оказаться актуальным, в том случае, если Ваша биллинговая программа может отключать пользователей посредством команд RADIUS-сервера.

Дальше. Серверу RADIUS для «правильного восприятия» Chillispot нужно добавить поддержку некоторых атрибутов, специфичных для chilli. Сам файл атрибутов поставляется вместе с FreeRADIUS (в моем случае — версия 2.0). Файл атрибутов называется dictionary.chillispot и находится в папке /usr/share/freeradius/. Нужно лишь включить его поддержку в основном файле настроек «словарей». Для этого открываем в текстовом редакторе файл /etc/raddb/dictionary и добавляем в него следующую строку:

$INCLUDE /usr/share/freeradius/dictionary.chillispot

(Кстати, может перед тем, как слепо следовать моим советам, стоит проверить, а есть ли там такой файл?)… Сохраняем изменения, выходим из редактора, и чтобы RADIUS-сервер «подхватил» новые настройки, перезапускаем его:

/etc/init.d/radiusd restart

5. И вот теперь запускаем!

Не знаю почему, но Mandriva при установке Chillispot не запускает его «в работу» сразу же после установки, как делает это со многими другими сервисами (например, с тем-же веб-сервером apache).  Более того, хотя скрипт запуска и присутствует в папке /etc/init.d/, по умолчанию он не запускается во время загрузки. То же самое и с нашим скриптом правил файервола. По этому, их нужно указать как сервисы (службы), стартующие «автоматом». Сделать это можно, например, в Mandriva Control Center (Центр управления Mandriva) — закладка «Система», пункт «Включение и отключение системных сервисов», поставить птичку в поле «При запуске». Лично я предпочел для этого воспользоваться своим любимым Webmin-ом…

Ну что ж, время пришло, запускаем Chillispot:

/etc/init.d/chillispot start

Ну вот и все. Надеюсь, ничего не забыл …

Также, про настройку Chillispot можно прочитать по следующим ссылкам:

  1. https://help.ubuntu.com/community/WifiDocs/ChillispotHotspot/7.10
  2. http://www.opennet.ru/base/net/wireless_hotspot_howto.txt.html
  3. http://www.chillispot.info/chilliforum/viewtopic.php?id=18

ВНИМАНИЕ! Предлагается вариант приобретения биллинговой программы Easyhotspot (русифицированный и модернизированный вариант) и подробного руководства по установке хотспота. Подробности здесь.

PS. Учтите, что это достаточно старая заметка! В те давние времена я разбирался с Chillispot, преследуя определенную цель, а именно — создание биллинговой системы для управления хотспотами на базе модернизированной версии программы Easyhotspot. С тех пор много воды утекло, и со временем указанный биллинг претерпел немало изменений, включая в том числе и такие (касающиеся именно описываемой тут процедуры установки контролера доступа Chillispot):

  • Во-первых, в качестве базовой ОС для Easyhotspot сейчас мною используются дистрибутивы Debian или Ubuntu, что подразумевает использование, с одной стороны, deb-пакетов, а с другой стороны — соответствующего менеджера для управления ими;
  • Во вторых, биллинг Easyhotspot теперь в качестве програмного NAS (если он используется сервером), устанавливает не устаревший (и давно заброшенный разработчиками) Chillispot, а его обновленный «форк» Coova-Chilli.
  • Ну и в третьих, инсталятор биллинга теперь не устанавливает готовый deb-пакет, а компилирует программу Coova-Chilli «из исходников» непосредственно на самом сервере Easyhotspot. Этот факт (в числе прочего) позволил уйти от необходимости использования только 32-битных версий операционных систем (т.к. старый Chillispot на 64-битных ОС работать отказывался).
  • Свежее описание процедуры установки Coova-Chilli («из исходников») на актуальных релизах дистрибутивов Debian и Ubuntu приведено в новой заметке: «Chillispot в 2021 году».