Как данный Гайд относится к Pw? Ну если за вас на сервере все ПО настроили то вам он не к чему. А лично я с этим столкнулся и ответов не нашёл. + Ко всему прочему когда началась активная DDOS атака на сайт и все хостинги стали от меня открещиваться пришлось повесить и сайт и форум на свой сервер.В результате чего возникла следующая проблема ip всех зарегистрированных пользователей отображалось как ip сервера. Так что я уверен что кому то он точно пригодится.
Модифицируем значения ряда переменных: #cat ./config.inc.php .... # Задаём произвольную (не более 48 символов), известную только нам и серверу, последовательность символов, используемых в дальнейшем для шифрования содержимого файлов Cookie с помощью алгоритма Blowfish $cfg['blowfish_secret'] = 'strongKey'; .... # Задаём режим авторизации с помощью Cookie $cfg['Servers'][$i]['auth_type'] = 'cookie'; .... # Задаём абсолютный путь к PMA, что будет использоваться им в пере-направлениях $cfg['PmaAbsoluteUri'] = 'http://site.name/pma/'; .... # Уточняем конфигурацию подключения к серверу MySQL $cfg['Servers'][$i]['host'] = 'localhost'; $cfg['Servers'][$i]['connect_type'] = 'tcp'; $cfg['Servers'][$i]['compress'] = true; # Включаем поддержку расширенного функционала, предоставляемого PHP5 и MySQL5 $cfg['Servers'][$i]['extension'] = 'mysqli'; .... # Запрещаем работать от имени суперпользователя - ибо нефиг $cfg['Servers'][$i]['AllowRoot'] = false; .... # Явно запрещаем работать пользователю СУБД, не имеющему пароля $cfg['Servers'][$i]['AllowNoPassword'] = false; .... # Принудительно задаём предпочтительные настройки кодировок и языковых раскладок $cfg['DefaultLang'] = 'en-utf-8'; $cfg['DefaultConnectionCollation'] = 'utf8_general_ci'; $cfg['Lang'] = 'en-utf-8'; $cfg['DefaultCharset'] = 'utf-8'; .... Для пущей безопасности защищаем конфигурацию от чтения посторонними: #chmod o-rw ./config.inc.php Вот и все сложности, было бы, от чего напрягаться. Права на данный гайд принадлежат моему коллеге Андрею
Отмечу сразу данный гайд написан не мной. Выложен по просьбе правообладателя данного материала. OS: Debian GNU/Linux Lenny. Обнаружил вчера, что среди начинающих администраторов есть много любителей установить PHPMyAdmin (далее PMA) с помощью системы управления пакетами Debian. Якобы это проще и надёжнее, чем делать его самому; вроде как умные люди постарались - чего поперёд них бежать? Так вот - это не так, ни каким местом. Во первых - версия в пакете всегда старее, чем на сайте. Во вторых - из соображений обеспечения максимальной работоспособности сборщики пакета вынесли скрипты PMA в /usr/share со встраиванием "алиаса" в конфигурацию "web"-сервера, что гарантирует проблемы при мало мальски усложнённой схеме. В третьих - установка PMA, взятого с сайта разработчиков проста до безобразия. Идём на сайт разработчиков: http://www.phpmyadmin.net/home_page/downloads.php Выкачиваем архив с интересующей нас версией PMA: #cd /usr/src #wget http://citylan.dl.sourceforge.net/project/phpmyadmin/phpMyAdmin/3.3.10/phpMyAdmin-3.3.10-english.tar.gz Распаковываем архив и перемещаем его содержимое в положенное ему место: #tar -xvf phpMyAdmin-3.3.10-english.tar.gz #mkdir -p /var/www/site.name/pma #mv ./phpMyAdmin-3.3.10-english/* /var/www/site.name/pma На самом деле, после распаковки дистрибутива PMA готов к использованию. Разработчики старались сделать порог вхождения в работу с комплексом управления СУБД как можно ниже, и у них это получилось (я помню ещё те времена, когда без "напильника" PMA не запускался). Если зудит от ощущения себя членом человеческого стада, потребляющего унифицированный продукт - можно подкорректировать конфигурацию PMA и успокоится в осознании своей исключительности и индивидуальности. Переходим в директорию, содержащую скрипты PMA: #cd /var/www/site.name/pma Активируем конфигурационный файл, параметры которого переопределят получаемые по умолчанию из файла "./libraries/config.default.php": #mv ./config.sample.inc.php ./config.inc.php
Создаем конфигурационный файл описания механизма "прозрачного проксирования" на "back-end" для последующего включения в конфигурации виртуальных хостов: #touch /etc/nginx/proxy.conf Приводим его к следующему виду: proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; Создаем файл конфигурации виртуальных хостов, поддерживаемых нами: #touch /etc/nginx/sites-available/u000.local #touch /etc/nginx/sites-available/u001.local Приводим их примерно к следующему виду: server { listen eth0.0.local:80; server_name u000.local www.u000.local; # Указываем кодировку отдаваемых страниц charset utf-8; access_log /var/www/u000/log/nginx.access.log; error_log /var/www/u000/log/nginx.error.log; # запрещаем отдавать кому бы то ни было файлы .htaccess и .htpasswd location ~* /\.ht { deny all; } # Перенаправление на сервер "back-end" location / { proxy_pass http://127.0.0.1:8080/; include /etc/nginx/proxy.conf; } # Статическое наполнение у нас отдает сам Nginx из директорий ресурсов пользователей в соответствии с указанными типами файлов location ~* \.(css|gif|jpeg|jpg|js|txt|png|tif|tiff|ico|jng|bmp|doc|pdf|rtf|xls|ppt|rar|rpm|swf|xpi|zip|tgz|gz|bz2|tar|bin|exe|dll|deb|dmg|iso|img|msi|msp|msm|mid|midi|mp3|mpeg|mpg|mov|flv|asx|asf|wmv|avi)$ { root /var/www/u000/www/; } } Казалось бы, зачем прописывать модули перенаправления трафика между "front-end" и "back-end" в каждом описании виртуального хоста, если они однотипны? Можно вынести их в общее описание конфигурации Nginx, но, тогда у нас не будет типового подхода к возможности индивидуальной настройки разделения трафика. Например, не исключено, что для избранных хостов в Apache2 указаны нетипичные расширения для исполняемых файлов и мы хотели бы их не отдавать напрямую клиенту. Указываем символическими ссылками Nginx на доступные конфигурации виртуальных хостов для загрузки: #ln -s /etc/nginx/sites-available/u000 /etc/nginx/sites-enabled/u000 #ln -s /etc/nginx/sites-available/u001 /etc/nginx/sites-enabled/u001 И удаляем ссылку на конфигурацию виртуально хоста "по умолчанию": #rm /etc/nginx/sites-enabled/default Перезапускаем Nginx: #/etc/init.d/nginx restart По завершению конфигурирования Nginx закрываем от постороннего взгляда директорию конфигурации: #chown -R root:root /etc/nginx #chmod -R o-rwx /etc/nginx Ещё никто не заинтересовался публикацией настолько, что бы оставить здесь своё мнение. А мне действительно хотелось бы знать, что вы думаете о ней. Подскажите, если нашли ошибку или просто знаете как сделать мир лучше. P.S Уважаемые модераторы если тема создана не в том разделе просьба перенести в нужный. Права на данный гайд принадлежат моему коллеги Андрею по его просьбе выложен.[/b]
Теперь "back-end" не будет отвечать на запросы из-вне и будет заниматься только отработкой тяжеловесных запросов отработки динамики. Перейдем к конфигурированию Nginx. Общая конфигурация Nginx находится в файле "/etc/nginx/nginx.conf", конфигурации хостов и сайтов описываются в файлах, располагающихся в директориях "" и "", подключаемых с помощью директив "include /etc/nginx/conf.d/*.conf;" и "include /etc/nginx/sites-enabled/*;". Изменим ряд директив общего конфигурационного файла "/etc/nginx/nginx.conf": # указываем пользователя, от чьего имени запускается Nginx user www-nginx www-nginx; ... # количество запускаемых рабочих процессов приравняем к количеству процессорных ядер на нашем сервере worker_processes 1; ... http { .... # описание параметров регламентирующих работу Nginx с доменными именами, необходимо выставлять величину превышающую количество обслуживаемых доменных имён server_names_hash_max_size 512; server_names_hash_bucket_size 512; .... # запрещаем сообщать версию Nginx в ответе клиенту server_tokens odd; # описание параметров работы сжатия трафика и перечень типов файлов подвергаемых сжатию gzip on; gzip_comp_level 3; gzip_proxied any; gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript; ... }
Надеюсь новичкам пригодиться. Так как сам столкнулся с данной проблемой. Устанавливаем Nginx из набора пакетов: #aptitude install nginx Получаем версию 0.6.32. Древняя, по сравнению с размещённой на сайте разработчика - 0.8.29. Лучше, конечно, собрать сервер из исходных кодов, что мы когда нибудь и сделаем; а сейчас приступим к конфигурированию пакетной версии. Делаем резервные копии затрагиваемых нами конфигурационных файлов: #cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.dist После установки из пакетов Nginx не стартовал, и это к лучшему; учитывая то, что у нас уже установлен настроенный на работу с портом "80" Apache2, запущенный с правами пользователя "www-data", ничего хорошего из запуска не вышло. Для начала заведем для Ngnix отдельного пользователя, от имени которого он будет работать в системе: #groupadd www-nginx #useradd --home-dir /var/lib/nginx --shell /bin/false --gid www-nginx www-nginx Сразу припоминаем, что доступ в директории web ресурсов пользователей доступ у нас жёстко ограничен. Для того, что бы наш Nginx мог обратится к нужным ресурсам необходимо ввести пользователя "www-nginx" в группы владельцев web ресурсов, которым разрешён доступ на чтение: #usermod --append --groups ug000 www-nginx #usermod --append --groups ug001 www-nginx Доработаем конфигурацию Apache2 до той, в которой он будет корректно отрабатывать в связке с прозрачным "прокси" Nginx. Для начала установим модуль, предоставляющий Apache2 принимать от "прокси" реальный IP адрес обращающегося клиента, с учётом того, что он замаскирован включённой нами прослойкой из "прозрачного прокси". Суть в том, что модуль позволяет Apache2 использовать заголовок X-Forwarded-for, передаваемый с запросом, в качестве значения заголовка несущего реальный IP удалённого клиента (припоминаем, что IP удалённого клиента в запросе у нас занят IP "прозрачного прокси"): #aptitude install libapache2-mod-rpaf Делаем резервные копии затрагиваемых нами конфигурационных файлов: #cp /etc/apache2/mods-available/rpaf.conf /etc/apache2/mods-available/rpaf.conf.dist Приводим конфигурационный файл "/etc/apache2/mods-available/rpaf.conf" к следующему виду: RPAFenable On # включаем механизм RPAFsethostname On # включаем передачу заголовка X-Host RPAFproxy_ips 127.0.0.1 # указываем адрес "front-end" Пройдемся по конфигурационным файлам Apache2 и везде, где есть указание на то, какие интерфейсы и порты прослушиваются, укажем "127.0.0.1:8080". Как минимум это конфигурационные файлы "/etc/apache2/ports.conf" и "/etc/apache2/sites-available/*". Например, для файла "/etc/apache2/ports.conf" это будет: NameVirtualHost 127.0.0.1:8080 Listen 127.0.0.1:8080 А для "/etc/apache2/sites-available/u1000.local": <VirtualHost 127.0.0.1:8080> ServerName u000.local ServerAlias www.u000.local ... Для того, что бы в журнальных файлах Apache2 фиксировался реальный IP удалённого клиента, а не IP "прокси", заменяем в описании формата вывода журналируемой информации переменную "%h" на "%{X-Forwarded-For}i"; как, впрочем, и рекомендовано разработчиками Apache2. Перезапустим Apache2: #/etc/init.d/apache2 restart
Имена участников (разделяйте запятой).
