Как убрать тестовую страницу Apach
В DocumentRoot и лежит тестовая страница, если действительно этот конфиг используется.
Лол, на тестовой странице написано же
To prevent this page from ever being used, follow the instructions in the file /etc/httpd/conf.d/welcome.conf.
sudo /etc/init.d/apache2 restart Как-то так
У него цементос, так что не так.
Не больно знаток апача, но разве не reload?
Сайт на CMS или самописный? Тут без дополнительной информации мало кто скажет. Просто БД не видит.
жумла, похоже. и корень не задан или задан неверно
Не больно знаток апача, но разве не reload?
Да без разницы. Все равно конфиг перечитает.
А в чем профит от reload, не подскажете? Существующие подключения в даун не уйдут или что? И какие минусы/плюсы у restart/reload. Не знаток, интереса ради вопрошаю.
Права пофиксь, апач не может шаблоны прочитать. man chmod/chown.
На хостинге RU-CENTER в настоящее время используется веб-сервер Apache версии 2.4.
Директивы файла .htaccess действуют для каталога, в котором размещён такой файл, и для всех его подкаталогов. Если вы желаете с помощью .htaccess изменить настройки для сайта в целом, его следует размещать в корневом каталоге сайта
Пожалуйста, будьте внимательны при редактировании файла .htaccess! При сохранении такого файла в кодировке UTF-8 в нём не должно присутствовать BOM-сигнатуры. Для редактирования файла .htaccess и других конфигурационных файлов мы рекомендуем использовать не «Блокнот» Windows, а специальные текстовые редакторы, например Notepad++.
1. Перенаправление доменов c синонима сайта на основной домен с кодом 301
Перенаправить запросы на domain.ru с любого из синонимов сайта
RewriteEngine On
RewriteCond %
RewriteRule ^(.*)$ http://domain.ru/$1 [L,R=301]
Перенаправить запросы на www.domain.ru с любого из синонимов сайта
RewriteEngine On
RewriteCond %
RewriteRule ^(.*)$ http://www.domain.ru/$1 [L,R=301]
Эти правила рекомендуется размещать в самом начале файла .htaccess.
2. Постоянное перенаправление с кодом 301
Redirect 301 /page.html http://www.domain.ru/new_page.html
Например, для перенаправления всех запросов к странице /period/?test=123 вашего сайта на domain.ru, вы можете написать:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %
RewriteRule ^period/$ http://domain.ru/ [L,R=301]
3. Переопределение страниц ошибок
#401 Авторизация не выполнена
ErrorDocument 401 http://domain.ru/errors/401.html
#403 Доступ запрещен
ErrorDocument 403 http://domain.ru/errors/403.html
#404 Страница не найдена
ErrorDocument 404 http://domain.ru/errors/404.html
#500 Внутренняя ошибка сервера
ErrorDocument 500 http://domain.ru/errors/500.html
Соответствующие файлы страниц ошибок (401.html, 404.html и др.) необходимо разместить в каталоге
Для того чтобы при случайном упоминании прямых ссылок на такие страницы они не проиндексировались в поисковых системах, рекомендуется:
User-agent: *
Disallow: /errors
/ваш_домен/docs/errors/.htaccess, в котором прописать
4. Постраничное перенаправление запросов на другой домен c кодом 301
Следующий код перенаправит все запросы к страницам вашего сайта на аналогичные страницы другого сайта, например, запрос http://domain.ru/main будет переадресован на http://www.newdomain.ru/main:
Redirect 301 / http://www.newdomain.ru/
RewriteEngine On
RewriteRule ^(.*)$ http://newdomain.ru/$1 [R=301,L]
5. Ограничение доступа к сайту по IP
Запретить доступ к сайту с IP-адресов 123.4.5.6 и 123.5.4.3
Order Allow,Deny
Allow from all
Deny from 123.4.5.6 123.5.4.3
Запретить доступ к сайту со всех адресов кроме 123.4.5.6 и 123.5.4.3:
Order Deny,Allow
Deny from all
Allow from 123.4.5.6 123.5.4.3
Запретить доступ к сайту для всех:
6. Переопределение главной страницы сайта (индексного файла каталога)
Сделать главной страницей файл menu.html:
8. Запрет выдачи листинга каталога
В случае отсутствия в папке главной страницы (индексного файла), при обращении без указания конкретного имени файла в запросе будет выдан список всех файлов, находящихся в каталоге. Для того чтобы запретить отображение листинга каталога, добавьте в файл .htaccess строку:
Скрипт должен иметь атрибут исполнения (+x, права доступа, начинающиеся с 7, например, 755).
10. Блокировка переходов со сторонних ресурсов
Для запрета перехода c baddomain.ru на domain.ru добавьте в .htaccess следующее:
Если требуется запретить переходы с нескольких доменов, то используйте следующие директивы
В файле .htaccess использование кириллицы не допускается. При составлении правил перенаправления для кириллических доменов необходимо указывать имя домена в punycode. Узнать имя домена в punycode можно с помощью сервиса Whois.
Например, для перенаправления site.ru на caйт.рф нужно воспользоваться следующим правилом:
RewriteEngine on
RewriteCond %
RewriteRule ^(.*)$ http://xn--80aswg.xn--p1ai/$1 [R=301,L]
В этом случае ваши посетители могут увидеть именно punycode-представление доменного имени в адресной строке браузера. Это не является ошибкой.
12. Перенаправление с HTTP на HTTPS и обратно
Для работы перенаправления на сайте должен быть установлен действительный SSL-сертификат.
Перенаправить запросы на https://domain.ru
Перенаправить запросы на http://domain.ru
3. Диагностика ошибок
Если после редактирования или размещения .htaccess при обращении к сайту вы получили ошибку 500, то, скорее всего, в файле .htaccess допущена ошибка. Посмотреть её причины вы можете в лог-файле /var/log/ваш_домен.error_log.
Chillispot — ещё тот «перец».
К одной из моих заметок прислали комментарий — «Да это же очевидно!». Абсолютно согласен! В блоге своем я пишу что-либо только после того, как уже разобрался с этим, и для меня то, что я написал тут тоже стало уже «очевидным». Но, до этого — зачастую приходится основательно перелопатить интернет, форумы, блоги и т.п. Вот возьмем, к примеру, тот же Chillispot 🙂 …
Начнем с простейшего — во многих интернет-источниках адрес сайта Chillispot указан как http://www.chillispot.org/. Но на сегодняшний день (и как пишут, это длится еще с середины 2007 года) сайт этот не существует, а информация, загрузки, FAQ, форум и пр. теперь находятся по новому адресу — http://www.chillispot.info/. Но к этому мы вернемся позже, а пока…
Вступление
Собственно, что это такое и зачем оно надо. Chillispot — это контроллер доступа. Его задача в максимально общей формулировке — пускать пользователей из одного сегмента сети в другой. То есть, если уже «приземленно», то с одной стороны (во внутренней подсети) находятся клиенты, а с другой стороны — бескрайние просторы интернета. И Chillispot с одной стороны на основании информации от сервера авторизации либо пускает этих клиентов в сеть либо нет. А с другой стороны, Chillispot осуществляет взаимодействие с сервером учета Radius, благодаря чему поставщик услуг (провайдер) знает сколько клиент провел времени в интернете, а также какой объем информации клиент принял и отдал в интернет. И, если совсем уж без намеков — Chillispot чаще всего используется тогда, когда кто-то хочет создать хотспот, работающий под управлением ОС Linux, и управляемый каким-нибудь биллингом, взаимодействующим с Chillispot посредством Radius-а.
При этом непосредственно Chillispot выполняет три задачи:
Существует целый класс аппаратных устройств, у которых есть и своё собственное название — NAS (Network Access Server — сервер доступа в сеть). Chillispot можно считать «программным» NAS. Кстати, аббревиатуру запоминайте — она нам еще встретится при настройке…
1. Подготовка
После генерации сертификатов прописываете их использование в файл конфигурации сервера apache-ssl (ну или apache с mod_ssl). Это конечно не избавит в дальнейшем от сообщений браузеров об неизвестном центре сертификации, т.к. сертификаты «самоподписанные», но те, кого это не устраивает, могут приобрести настоящие сертификаты. Существует еще одна возможность, на тот случай, если у Вас есть возможность разместить свой скрипт на безопасном сервере, доступном с того компьютера, на котором планируется разместить Chillispot, Об этом — ниже…
2. Установка
Чем (для меня) хорош дистрибутив Mandriva? Обилием программ в «родных» репозиториях! Запустите «Центр управления», выберите «Установку и удаление программ», введите в поле поиска желаемое, и с определенной долей уверенности можно утверждать, что «оно там найдется»… Так же было и с Chillispot — он оказался в списке доступных пакетов, я всего-лишь поставил «птичку» и нажал кнопку «Применить»…
(Ничто не вечно под луной… Пока я собирался описать установку Chillispot, вышел новый дистрибутив Mandriva — версии 2009.1, в пакетах которого Chillispot, увы, уже не оказалось. Но, на проверку, преспокойно устанавливается и работает пакет от дистрибутива версии 2009.0).
На всякий случай, я сохранил пакет у себя на FTP в соответствующей папке.
3. Конфигурирование
Вся конфигурация Chillispot описывается одним единственным файлом — /etc/chilli.conf. Каждый параметр в нем прокомментрирован, единственное «неудобство» — «как всегда», на английском. Кроме того, можно в консоли запустить команду
Теперь о самих параметрах. Все их я описывать не буду, опишу лишь те, которые необходимо было изменить. (Параметры выделены жирным, их значения — красным).
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«. Комментариями там все это «разбавлено прилично», но если их выкинуть, то выглядеть все это будет так:
Как видим, присутствующий в списке параметр «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) и пользователями нельзя.
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) нужно открыть в любом нравящемся Вам текстовом редакторе, найти (практически в самом начале) строки:
и раскомментировать их! Первая из строк задает тот самый пароль (который нужно указать, желательно все-таки свой собственный а не «умолчательный», и, естественно, одинаковый, для обоих конфигурационных файлов — 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 и добавляем в него следующую строку:
Чтобы форвардинг заработал сразу (без перезагрузки всей системы), перезапускаем поддержку сети командой:
Во-вторых, с Chillispot поставляется скрипт правил файервола, который необходимо запускать при загрузке системы. Сразу после установки файл этот находится в папке /usr/share/doc/chillispot/ и называется firewall.iptables. Открываем его в редакторе и смотрим на значения, присвоенные двум переменным (в самом начале файла) — EXTIF=» eth0 « и INTIF=» eth1 «. В качестве значения переменной «EXTIF» (внешний интерфейс) должна быть указана сетевая плата, «смотрящая» в интернет. А в качестве «INTIF» (внутренний интерфейс) — плата, к которой подключаются пользователи (точка доступа). В самом начале данной заметки, в исходных условиях мы приняли, что к интернету у нас подключен интерфейс eth0, а к точке доступа — eth1. Таким образом, значения указанных параметров нас устраивают целиком и полностью. Если же подключение выполнено наоборот, то нужно соответствующим образом изменить и значения этих двух параметров, указанные в файле 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 и добавляем в него следующую строку:
(Кстати, может перед тем, как слепо следовать моим советам, стоит проверить, а есть ли там такой файл?)… Сохраняем изменения, выходим из редактора, и чтобы RADIUS-сервер «подхватил» новые настройки, перезапускаем его:
5. И вот теперь запускаем!
Не знаю почему, но Mandriva при установке Chillispot не запускает его «в работу» сразу же после установки, как делает это со многими другими сервисами (например, с тем-же веб-сервером apache). Более того, хотя скрипт запуска и присутствует в папке /etc/init.d/, по умолчанию он не запускается во время загрузки. То же самое и с нашим скриптом правил файервола. По этому, их нужно указать как сервисы (службы), стартующие «автоматом». Сделать это можно, например, в Mandriva Control Center (Центр управления Mandriva) — закладка «Система», пункт «Включение и отключение системных сервисов», поставить птичку в поле «При запуске». Лично я предпочел для этого воспользоваться своим любимым Webmin-ом…
Ну что ж, время пришло, запускаем Chillispot:
Ну вот и все. Надеюсь, ничего не забыл …
Также, про настройку Chillispot можно прочитать по следующим ссылкам:
ВНИМАНИЕ! Предлагается вариант приобретения биллинговой программы Easyhotspot (русифицированный и модернизированный вариант) и подробного руководства по установке хотспота. Подробности здесь.
PS. Учтите, что это достаточно старая заметка! В те давние времена я разбирался с Chillispot, преследуя определенную цель, а именно — создание биллинговой системы для управления хотспотами на базе модернизированной версии программы Easyhotspot. С тех пор много воды утекло, и со временем указанный биллинг претерпел немало изменений, включая в том числе и такие (касающиеся именно описываемой тут процедуры установки контролера доступа Chillispot):
