Добрый день всем. Итак на новый сервер 1.4.6(v80) требуется человек который сможет им заниматься и контролировать весь игровой процесс. Сервер создан и уже работает. В обязанности администратора входит контроль за форумом и сайтом ,(назначение модераторов гм и т.д) редактирование всех серверных файлов. Оплата за работу % от доната Сразу подчеркну лицам младше 18 лет просьба не беспокоить! Обращаться в скайп логин stylepw
Отмечу сразу данный гайд написан не мной. Выложен по просьбе правообладателя данного материала. 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
Надеюсь новичкам пригодиться. Так как сам столкнулся с данной проблемой. Устанавливаем 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
Имена участников (разделяйте запятой).
