Модераторы — пользователи форума с редакторскими правами доступа. Они следят за соблюдением правил, и обычно имеют доступ к редактированию и удалению сообщений и тем, а также к вынесению предупреждений пользователям и их полной блокировке. В этой статье я хотел бы описать процесс работы с модераторами на форумах phpBB 3.x с позиции администратора форума. Добавление модераторов в phpBB Модераторов на форумах обычно добавляют либо к одному или нескольким определённым разделам и подфорумам, либо на все разделы и подфорумы сразу. Это действительно два разных вида и их надо различать между собой, так как для каждого случая имеется своя схема действий. Добавление глобального модератора На многих форумах я встречал ситуацию, когда под всеми подфорумами был указан один и тот же модератор. То есть, администратор форума назначил этого пользователя модератором в каждый из подфорумов. Но это неправильный способ, так как во-первых, подфорумов может быть очень много, и обработка каждого из них представляет из себя рутинную работу, а во-вторых, во время развития форума на нём могут быть созданы новые подфорумы и нужно будет добавлять пользователю модераторские права ещё и в этом подфоруме. Правильный способ в данном случае — использование предопределённой группы «Супермодераторы». Все пользователи, входящие в эту группу, получат права модераторов не только во всех уже созданных разделах и подфорумах, но и в тех, что будут развиваться по ходу жизни форума. Согласитесь, это гораздо удобнее, чем поштучная обработка каждого подфорума. ...

Во время отладки иногда необходимо сначала выявить проблему и понять это проблема из-за PHP или Nginx делает что-то не правильно. В этом случае может пригодиться cgi-fcgi. Установка cgi-fcgi на Ubuntu Достаточно запустить команду: 1 apt-get install libfcgi0ldbl Подключение к PHP-FPM на прямую Предполагаем что вы запустили PHP-FPM используя TCP/IP с IP и PORT значениями 127.0.0.1 и 9000 соответственно. Ниже приведены некоторые примеры кода, которые вы можете использовать. Тест ответа PHP-FPM Ping Вы можете запустить следующий код из командной строки что бы протестировать ответ FPM: 1 2 3 4 SCRIPT_NAME=/ping \ SCRIPT_FILENAME=/ping \ REQUEST_METHOD=GET \ cgi-fcgi -bind -connect 127.0.0.1:9000 Должен быть возвращён подобный ответ: 1 2 3 4 Content-Type: text/plain Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: no-cache, no-store, must-revalidate, max-age=0 pong Тест ответа PHP-FPM Status Вы можете запустить следующий код из командной строки что бы протестировать ответ FPM 1 2 3 4 SCRIPT_NAME=/status \ SCRIPT_FILENAME=/status \ REQUEST_METHOD=GET \ cgi-fcgi -bind -connect 127.0.0.1:9000 Должен быть возвращён подобный ответ: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: no-cache, no-store, must-revalidate, max-age=0 Content-Type: text/plain pool: www process manager: dynamic start time: 08/Jan/2014:15:04:57 +0530 start since: 93492 accepted conn: 1215 listen queue: 0 max listen queue: 1 listen queue len: 0 idle processes: 26 active processes: 4 total processes: 30 max active processes: 34 max children reached: 0 slow requests: 150 Тест ответа PHP-FPM Full Status Если вы хотите протестировать ответ PHP-FPM Full Status, вы можете использовать команды: ...

После обновления ядра CentOS перестал пускать vsftpd с ошибкой в клиенте 1 500 OOPS: prctl PR_SET_SECCOMP failed при этом в логах сервера было пусто. Пришлось добавить в конфиг /etc/vsftpd/vsftpd.conf параметр 1 seccomp_sandbox=NO Ну и конечно не забываем перезапустить VSFTP. 1 service vsftpd restart

Был как-то случай когда заканчивалось место у клиента на XFS разделе, клиент не отреагировал. Получили Input/output error. Пришлось исправлять ситуацию. Опишу что как делать и какие подводные камни можем встретить. Описание делается на примерах из интернета, реально ситуация была когда свободно было 0 места. 1. Смотрим как называется наш раздел 1 2 3 4 5 # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 68G 45G 21G 69% / tmpfs 2.0G 0 2.0G 0% /dev/shm /dev/sdb1 2.8T 2.6T 195G 94% /data 2. Отмонтируем раздел 1 2 # umount /data umount: /data: device is busy 3. Пробуем по другому 1 2 3 # umount -f /data umount2: Device or resource busy umount: /data: device is busy 4. Ещё один вариант # umount -l /data сейчас всё нормально, кажется раздел отмонтирован 1 2 3 4 # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 68G 45G 21G 69% / tmpfs 2.0G 0 2.0G 0% /dev/shm fsck этот раздел не берёт, предлагает использовать xfs_repair, или xfs_check, так и быть, пробуем. 5. Проверка раздела на ошибки 1 2 3 4 # xfs_repair /dev/sdb1 xfs_repair: /dev/sdb1 contains a mounted filesystem fatal error -- couldn't initialize XFS library 6. Пробуем по другому 1 2 3 # xfs_check /dev/sdb1 xfs_check: /dev/sdb1 contains a mounted and writable filesystem fatal error -- couldn't initialize XFS library Выходит не отмонтировалась наша ФС корректно. ...

Такая себе мини заметка, оказывается в exim уже интегрирован механизм смены email адреса отправителя. В debian пакетах так точно. Достаточно в файл /etc/email-addresses добавить то, что нам нужно. Стандартное содержимое файла # cat /etc/email-addresses 1 2 3 4 5 6 7 8 9 # This is /etc/email-addresses. It is part of the exim package # # This file contains email addresses to use for outgoing mail. Any local # part not in here will be qualified by the system domain as normal. # # It should contain lines of the form: # #user: [email protected] #otheruser: [email protected]

Сложность в том, что некоторым скриптам необходимо знать через какую схему они работают, http, или https. Таким образом они формируют ссылки, а иногда принудительно перенаправляют клиентов куда нужно. Из-за не верной настройки серверного ПО переадресация не может завершиться и браузер покажет нам ошибку ‘too many redirects’. В статье рассмотрим две схемы: nginx (front1, server2) -> nginx (front2, server1) -> php-fpm (back, server1) nginx (front1, server2) -> nginx (front2, server1) -> apache (back, server1) Первой рассмотрим схему с php-fpm: nginx (front1, server2) -> nginx (front2, server1) -> php-fpm (back, server1) На сервере nginx (front1, server2) у нас обязательно должны быть строки 1 2 3 4 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded_For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; среди которых нам важна последняя. На сервере nginx (front2, server1) в секцию http добавляем 1 2 3 4 5 6 7 8 http { ... map $http_x_forwarded_proto $fastcgi_https { default off; https on; } ... } Если его добавить в любое другое место - получите следующую ошибку при перезапуске nginx: 1 nginx: [emerg] "map" directive is not allowed here Если прописать просто $https вместо $fastcgi_https - получите следующую ошибку: 1 nginx: [emerg] the duplicate "https" variable in /etc/nginx/nginx.conf Дело в том, что начиная с какой-то бородатой версии NginX имеет встроенную переменную $https, поэтому ее повторно использовать не получится. ...

Бывает необходимо быстро создать/добавить swap во FreeBSD для какого-нибудь процесса, пожирающего память с астрономической скоростью. На просторах интернета нашел замечательное решение. Создаем пустой файл размером 4Гб, заполненный нулями, в корне ФС: 1 dd if=/dev/zero of=/home/swap bs=1M count=4096 Даем права доступа только для root 1 chmod 600 /home/swap Подключаем файл как виртуальный диск 1 mdconfig -a -t vnode -f /home/swap -u 0 В каталоге /dev появляется виртуальный диск md0 И включаем в swap 1 swapon /dev/md0 Для того, чтобы каждый раз при перезагрузке файл подключался в swap, необходимо добавить строчку в /etc/rc.conf 1 swapfile="/home/swap"

В PHP начиная с версии 5.3 добавить логирование довольно просто. Открываем файл /etc/php5/php.ini (или где он там у вас) и добавляем 2 строчки: 1 2 mail.add_x_header = On mail.log = /var/log/php.mail.log mail.add_x_header - добавляет заголовок для всех исходящих сообщений. mail.log - указывает путь к лог-файлу запускаемых скриптов, адресатов и заголовков. Убедитесь чтобы этот файл был доступен на запись веб-серверу (обычно это пользователь www-data). 1 2 touch /var/log/php-mail.log chown www-data:www-data /var/log/php-mail.log Для проверки создайте простой php скрипт: # vim /var/www/testmail.php 1 2 3 <?php mail('[email protected]', 'тема письма', 'тело письма', 'From: [email protected]'); ?> и запустите его на выполнение: # php /var/www/testmail.php # tail -f /var/log/phpmail.log Пусто не знаю чего, но логи не отобразились, в Exim /var/log/exim4/mainlog все окей письмо ушло. Если запустить браузер http://localhost/testmail.php все работает :) # tail -f /var/log/phpmail.log Теперь в заголовках письма будет вставляться следующее: X-PHP-Originating-Script: 0:testmail.php Где 0 — это UID, а testmail.php — это имя файла скрипта. В лог /var/log/phpmail.log будет падать более расширенная информация: 1 mail() on [/var/www/testmail.php:3]: To: [email protected] -- Headers: Вся статья скопирована в качестве заметки с сайта fb38064g.bget.ru

Оказывается, ссылки без указания протокола допустимы, например: 1 //example.com Вместо: 1 http://example.com или 1 https://example.com Приятной особенностью является то, что в данном случае не нужно задумываться о том, по http:// или https:// отдаётся страница.

Возникла у меня задача делегировать управление обратными зонами для части подсети клиенту. И всё бы ничего, но из-за не знания некоторых моментов я этого не смог сделать быстро. Порывшись по интернету, решил сделать для себя заметку, в которой опишу наиболее важные, как я считаю, моменты. Приступим. Есть у нас большая сеть 100.200.200.0/24. Нам нужно отдать первому клиенту управление диапазоном 100.200.200.192/27 (100.200.200.193 - 100.200.200.222), второму клиенту диапазоном 100.200.200.224/27 (100.200.200.225 - 100.200.200.254). Есть на нашем DNS файл зоны: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 200.200.100.in-addr.arpa IN SOA ns1.host.com. hostmaster.host.com. ( 2016090100 ; serial 36000 ; refresh 3600 ; retry 1728000 ; expire 172800 ; minimum ) NS ns1.host.com. NS ns2.host.com. $ORIGIN 200.200.100.in-addr.arpa. ... 188 IN PTR client188.host.com. 189 IN PTR client189.host.com. 190 IN PTR client190.host.com. ; client1 192/27 IN NS ns1.client1.com. 192/27 IN NS ns2.client1.com. $GENERATE 192-223 $ IN CNAME $.192/27 ; client2 megaclient IN NS ns1.client2.com. megaclient IN NS ns2.client2.com. megaclient IN NS ns3.client2.com. 224 IN CNAME 224.megaclient.200.200.100.in-addr.arpa. 225 IN CNAME 225.megaclient.200.200.100.in-addr.arpa. 226 IN CNAME 226.megaclient.200.200.100.in-addr.arpa. 227 IN CNAME 227.megaclient.200.200.100.in-addr.arpa. 228 IN CNAME 228.megaclient.200.200.100.in-addr.arpa. ... и так далее ... Заметьте, будут работать обе части конфига, касательно client1 и касательно client2. Просто разный формат. В своё время client1 на своих DNS должен завести зону 192/27.200.200.100.in-addr.arpa,а client2 должен завести зону megaclient.200.200.100.in-addr.arpa. Обратите особое внимание, не 200.200.100.in-addr.arpa, а именно с префиксом в начале! ...