Архивы рубрики ‘Статьи’

Наверное я не первый кто столкнулся с вопросом как оттестировать правила написанные для mod_rewrite прежде чем их добавлять на обработку для веб сервера. Например, мы имеем цель превратить длинную строку запроса в переменные, чтобы подать их потом на обработку какому-то скрипту. У меня стояла тривиальная задача, есть каталог картинок, распределенный по директориям с зависимостью от качества изображения и при запросе какой-либо картинки ее нужно было конвертировать на ходу в мелко изображение, отдавать клиенту в браузер и считать статистику запросов.

Итак, имеем URL такого типа:  /103/77/e/100_Natural_Wonders2_0__1.jpg

Задача: получить переменные с него и передать на обработку скрипта, который уже сделает свое дело (сменит размер изображения, добавит плюсик в статистику и отдаст клиенту изображение). Сам скрипт обработки я предоставлять тут не буде, но добавлю что результативный URL должен быть такого вида:

/convert.php?folder=images&file=$4&width=$1&height=$2&aspect=$3

Вы скажете: в чем тут проблема, пиши строку, добавляй ее в правила mod_rewrite и включай дебаг rewrite в apache и смотри обработку. Так можно сделать, но во первых если сайт уже рабочий, то ваши эксперименты могут повлиять на его работу, а во вторых если у вас не apache установлен, а nginx – что тогда ?

Немого поковырявшись и поспрошав умных людей нашел утилиту pcretest, которая идет вместе с пакетом PCRE. Она как раз нам и нужна для ловли блох в ваших регулярных выражения. Работает она следующим образом: запускаем утилиту, в строке re> ставим #, далее прописываем ваше правило и закрываем выражение # и жмем Enter. Далее появляется строка data> где вы должны указать ваш URL без домена и http, вводим его и нажимаем Enter. Далее получаете результатом или переменные 1,2 и т.д (зависит от вашего правила) или результат No match – это значит, что ваше правило ошибочное и вы не получили результата. Дальше я приведу два теста, первый содержит ошибку в строке регулярного выражения, второй – правильный.

1) Ошибочное регулярное выражение:

#pcretest

PCRE version 8.02 2010-03-19

re> #^/(\d{1,3})/(\d{1,3})/([er])/([a-zA-Z\d_.-]+)?/$#

data> /103/77/e/100_Natural_Wonders2_0__1.jpg

No match

data>^D

2) Правильное регулярное выражение:

#pcretest

PCRE version 8.02 2010-03-19

re> #^/(\d{1,3})/(\d{1,3})/([er])/([a-zA-Z\d_.-]+)?$#

data> /103/77/e/100_Natural_Wonders2_0__1.jpg

0: /103/77/e/100_Natural_Wonders2_0__1.jpg

1: 103

2: 77

3: e

4: 100_Natural_Wonders2_0__1.jpg

data> ^D

Итак , результат на лицо. Надеюсь данная статья вам поможет быстро решить ваши задачи.

Язык php имеет бурное развитие и новые версии выходят довольно часто, поэтому вебмастера стараются держать свои программные продукты в актуальном виде. Не так давно свет увидела новая версия php 5.3. На сегодняшний день вышло уже 2 (два) обновления и версия php имеет номер 5.3.2.

Внимание: на данный момент Zend Optimizer не поддерживает версию php 5.3, поэтому если вы используете Zend на вашем сервере, то вы не должны обновлять php до версии 5.3, так как это приведет к неработоспособности ваших сайтов.

Итак, приступаем к настройке в DirectAdmin. Переходим в каталог: /usr/local/directadmin/custombuild . Забираем последние обновления софта с DirectAdmin: ./build update . Меняем версию php на 5.3 в файле options.conf переменная php5_ver или через интерактивную конфигурацию запустив команду: ./build options

После изменений можно приступать к пересборке php запустив команду: ./build php n

Стандартные сборки софта конечно же не каждому подойдут, поэтому после установки DirectAdmin или в дальнейшем нам потребуется сделать пересборку софта на свой вкус. Вы скажете что это очень просто, заходишь в директорию /usr/local/directadmin/custombuild/configure , далее переходишь в поддиректорию требуемого ПО, например php и правишь на свой вкус конфигурационный файл.

Все правильно, можно сделать так как вы говорите, но есть один нюанс, когда пройдет обновление скриптов сборки, то все ваши правки будут изменены на стандартные настройки и вы опять будете править конфигурацию под себя по новой. Итак, чтобы не делать одну и ту же работу каждый раз, делаем все правильно.

Начнем на примере пересборки php. Итак нам нужно чтобы в php была поддержка SOAP (php будет работать через suphp). Идем в директорию /usr/local/directadmin/custombuild, создаем там директорию custom, в нее копируем директорию suphp c данными с директории configure. И уже в скопированной вновь директории правим файлик configure.php5 (для php версии 5) или configure.php4 (для php версии 4). После добавления нужных опций пересобираем php средствами DirectAdmin.

А теперь все тоже самое, но в командах:

cd /usr/local/directadmin/custombuild

mkdir custom

cd custom

cp –R /usr/local/directadmin/custombuild/configure/suphp /usr/local/directadmin/custombuild/custom

cd /usr/local/directadmin/custombuild/custom/suphp

vi configure.php5

добавляем предпоследней строчкой «—enable-soap» \ и приступаем к пересборке php

cd /usr/local/directadmin/custombuild

./build php5-cgi n

Столкнулся с проблемой при снятии данных курса обмена через xml запрос. На машинке где все (apache, php, libxml и т.д.) собрано с портов все отлично работает, а на машинке где DirectAdmin, вместо данных получаю или пустую страницу или ругань о не возможности получить данные. Поковырявшись в скриптах сборки увидел, что libxml собирается по умолчанию без поддержки iconv.

Лечим так:

1) переходим в /usr/local/directadmin/custombuild, открываем на редактирование файл build, находим функцию doLibxml2() и меняем:

./configure —prefix=/usr/local —without-python

на

./configure —prefix=/usr/local —without-python –with-iconv

2) делаем пересборку libxml2: ./build libxml2 n

3) делаем пересборку php: ./build php5-cli n или ./build php5-cgi n, в зависимости от режима работы вашего php

Перезапускаем apache и проверяем работу скрипта.

Итого: так как разработчики DirectAdmin не знают другого языка как английский, то ничего удивительного нет в том, что iconv им не нужен.

Для смены пароля на почту используйте URL такого типа:

http://mydomain:2222/CMD_CHANGE_EMAIL_PASSWORD

где mydomain смените на название вашего доменного имени или IP адрес сервера, ну и протокол http или https.

В открывшемся окне указываете свой email адрес, текущий пароль и новый пароль два раза. На этом можно считать ваше задание выполнено :)

Если вы на этой странице, то вы уже столкнулись с вопросом настройки SSL для DirectAdmin. Эта статья никоим образом не относится к настройки SSL для apache.

Итак как же это сделать? Все элементарно и просто, генерируем само подписанный SSL если у вас его нету:

/usr/bin/openssl req -x509 -newkey rsa:1024 -keyout /usr/local/directadmin/conf/cakey.pem -out /usr/local/directadmin/conf/cacert.pem -days 9999 -nodes

настраиваем права на файлы:

chown diradmin:diradmin /usr/local/directadmin/conf/cakey.pem
chmod 400 /usr/local/directadmin/conf/cakey.pem

Если у вас уже есть SSL сертификат и ключ, то скопируйте их так:

сертификат:   /usr/local/directadmin/conf/cacert.pem

ключ: /usr/local/directadmin/conf/cakey.pem

Если есть CA Root Certificate, то копируем его в: /usr/local/directadmin/conf/carootcert.pem

Далее прописываем в конфигурационном файле DirectAdmin:

SSL=1

и если есть подписанный сертификат и ключ и CA Root, то добавляем еще и

carootcert=/usr/local/directadmin/conf/carootcert.pem

После сохранения конфиг. файла не забываем перезапустить DirectAdmin.

Все наверное сталкивались с вопросом как добавить еще один IP, кроме основного, в Debian. Все очень просто. Заходим по ssh на сервер, переходим в каталог /etc/network/ и редактируем файл interfaces. Например нам нужно добавить IP 192.168.1.100/32:

#cd /etc/network/
#vi interfaces
auto eth0:0
iface eth0:0 inet static
address 192.168.1.100
netmask 255.255.255.255

сохраняем файл и выходим с редактора. Теперь нам нужно применить наши изменения. Делается это следующими командами, если у вас есть доступ к клавиатуре и монитору:

#/etc/init.d/networking stop
#/etc/init.d/networking start
#/etc/init.d/networking restart
# ifdown eth0
# ifup eth0


Если нету доступа к монитору и клавиатуре, то проще перезагрузить сервер.

С недавних пор FreeBSD поддерживает бинарное обновление системы, то есть не нужно теперь ждать пока соберутся все исходники. Для обновления нужно использовать утилиту freebsd-update.
Для обновления в текущем релизе (то есть получать только исправления применимые к текущей установленной версии) используйте следующие команды:

freebsd-update fetch
freebsd-update install
reboot

Для перехода на следующую версию:

freebsd-update -r 7.3-RELEASE upgrade
freebsd-update install
reboot
freebsd-update install
reboot


Поработав некоторое время с ipcad начал замечать, что с увеличением
трафика проходящего через роутер нагрузка на процессор начала возрастать
колоссально. Порыскав в поисковиках, нашел, что можно заменить ipcad
на счетчик NetFlow, тем более что во FreeBSD
он уже с «коробки». 

Итак, что мы имеем роутер: с одним внутренним интерфейсов, несколько
исходящих на разные uplink-и и роутер пропускает через себя только
реальные IP адреса (NAT-а нет).

И так правила выглядят так:

/usr/sbin/ngctl -f- <<-SEQ
mkpeer em0: netflow lower iface0
name em0:lower netflow
connect em0: netflow: upper out0
mkpeer netflow: ksocket export inet/dgram/udp
msg netflow:export connect inet/192.168.1.1:4444
connect vlan0: netflow: lower iface1
connect vlan0: netflow: upper out1
connect vlan1: netflow: lower iface2
connect vlan1: netflow: upper out2
connect vlan2: netflow: lower iface3
connect vlan2: netflow: upper out3
connect vlan3: netflow: lower iface4
connect vlan3: netflow: upper out4
connect vlan4: netflow: lower iface5
connect vlan4: netflow: upper out5
connect em3: netflow: lower iface6
connect em3: netflow: upper out6
SEQ

Надеюсь, эта статья поможет вам быстро решить задачу.

Я читаю почтовые рассылки по qmail последние несколько лет, и если
встречается там вопрос, на который ответов больше, чем на любые другие
вопросы, то это вопрос, на который отвечают: "читай FAQ 5.4". Этот
вопрос имеет много формулировок, но в основном звучит так:

"Когда кто-то пробует послать почту через мой сервер, он получает
сообщение 'Sorry, that domain isn't in my list of allowed rcpthosts'
('Извините, этого домена нет в списке разрешенных для релея хостов').
Что мне делать"?

Из дальнейшего чтения видно, что сама тема пересылки (релея) почты зачастую
приводит новичков в замешательство, какую роль здесь играет файл rcpthosts ?
и какое отношение к пересылке имеют tcprules tcpserver'а ?
Поэтому я написал следующее, чрезвычайно многословное объяснение принципов
пересылки, описал, как сделать ее выборочной, а также рассказал о некоторых
ловушках, которые могут вам встретиться. Может показаться, что для сказано
слишком много слов для объяснения столь несложной концепции. Однако,
прочитав сотни сообщений из рассылок qmail по этой теме, я подумал, что
смогу определить большинство источников путаницы и непонимания, и
попробовал предугадать все вопросы, которые могут у вас возникнуть. 

Итак. О чем вообще идет речь ? Что такое открытый релей ?

- Вы установили ваш qmail сервер. Он обслуживает несколько почтовых доменов
(то есть, они перечислены в вашем файле locals или в virtualdomains).
- Вы настроили сервер так, чтобы qmail-smtpd мог принимать соединения на
25 порту и получать почту от других хостов.
- Другой хост в Internet соединяется с вашим сервером на 25 порту. Это может
быть другой почтовый сервер с работающим на нем qmail, sendmail или с другим
MTA, или же просто конечный пользователь, который хочет послать почту со
своего персонального почтового клиента (Outlook, The Bat, Netscape Mail и т.п.)

Начинается сеанс SMTP с удаленным хостом.
Сначала удаленный хост называет себя: 

HELO somehost.somewhere.net

Ваш сервер отвечает:
  250 mail.yourdomain.net

Удаленный хост сообщает поле "From" сообщения:
  MAIL FROM: joe@somewhere.net

Ваш хост отвечает:
  250 ok

Удаленный хост теперь посылает одну или несколько команд RCPT TO,
которые определяют получателей сообщения:
  RCPT TO: bob@elsewhere.com

Минуточку! elsewhere.com - это НЕ один из доменов, которые обслуживает
Ваш сервер. Что Ваш сервер сделает? Он может согласиться принять
сообщение и попытаться доставить его:
  250 ok

Или он может отклонить его:
  553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) 

  В первом случае, ваш сервер работает как релей: он принимает и соглашается
попробовать доставить сообщение, которое не предназначено для одного из
ваших доменов. Во втором случае, он отказывается быть релеем. Файл rcpthosts,
который получил свое название от команды RCPT TO, определяет, будет ли адрес
получателя принят к дальнейшей обработке: он будет принят, только если домен,
указанный в команде RCPT TO, имеется в rcpthosts (об исключениях из этого
правила поговорим позже). Если файла rcpthosts не существует, то любой адрес
получателя будет принят.
  Сервер SMTP называется "открытый релей", если он соглашается
переслать почту независимо от того, кто и кому ее отправляет. Если другой хост
соединяется с портом 25 и отправляет какие-то письма, открытый релей примет
эту почту и будет пробовать ее доставить независимо от того, кем является его
адресат и кто посылает ее. Сервер qmail без файла rcpthosts будет действовать
как открытый релей.

  Так почему же я не должен иметь открытый релей? Моим пользователям
необходимо отправлять почту в другие домены. И вообще, почему некто, не
являющийся моим пользователем, может захотеть использовать мой сервер
как релей ?

  Несколько лет назад это действительно было безопасным решением; люди
обычно использовали релей, предоставленный им своим ISP, работодателем или
университетом. А потом появились спамеры (другое написание - спаммеры) - люди,
организующие массовые рассылки непрошенной электронной корреспонденции
коммерческого характера. Вместо использования ресурсов собственного сервера
они разыскивают открытый релей, который сможет принять и разослать
единственное сообщение, скажем, со 100000 адресатами.
Такой невольный помощник спамера должен будет забыть о нормальной работе своего
сервера и приготовиться к резкому увеличению исходящего трафика; кроме того,
администраторы почтового релея будут, вероятно, затоплены жалобами получателей
спама.
Релей может даже оказаться в "черном списке", чтобы другие, более
настроенные хосты в Интернете отказались получать почту от него.
Открытий почтовый релей в наши дни рассматривается как безответственность. 

Ок, довольно доводов, вы меня убедили. Я не хочу иметь открытый релей.
Как я могу исправить свои настройки?

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

Но теперь мои собственные клиенты получают сообщение "Sorry,
that domain isn't in my list of allowed rcpthosts"! Я хотел бы, чтобы мои
собственные клиенты могли использовать мой сервер как релей, но я, наверное,
не смогу перечислить все домены в моем rcpthosts файле, в которые они могут
захотеть послать почту.

  Вы тоже с этим сталкивались? К счастью, есть способ заставить qmail-smtpd
выборочно игнорировать файл rcpthosts. Если переменная RELAYCLIENT
установлена в переменных окружения qmail-smtpd, rcpthosts будет
игнорироваться и пересылка будет разрешена. Все, что вам нужно - это найти
способ установить RELAYCLIENT для ваших клиентов, но не для кого-либо еще.
  Для начала вам нужен способ идентифицировать ваших клиентов. В протоколе
SMTP не предусмотрено авторизации по имени пользователя и паролю. Как же
определить, исходит ли некоторая SMTP-сессия от одного из ваших клиентов?
Вернейший способ выделить вашего клиента из остального мира состоит в
проверке следующего факта: ваш клиент соединяется с вашим сервером с
хоста из вашей сети, то есть с хоста, чей IP-адрес находится в вашем
адресном пространстве.
  Как только вы узнаете, что пользователь соединился с одного из ваших
IP-адресов, вам нужно будет установить RELAYCLIENT так, чтобы этот
пользователь мог пересылать почту. Очень просто настроить qmail так, чтобы
он делал это. Чтобы выяснить, как это сделать, прочитайте о выборочном
релее с помощью tcpserver и qmail-smtpd. 

Ну а если большинство моих пользователей не находятся в моей сети
и используют различных ISP? Разве я не могу позволить им пересылать почту,
если эта почта приходит с одного из моих доменов? 

  Большинство людей понимает "приходит с одного из моих доменов" как "имеет
один из моих доменов в адресе отправителя". Проблема здесь в том, что
подделать адрес отправителя очень просто. Вам пришлось бы брать слово с
отправителя, что его адрес - это действительно то, что он написал в
MAIL FROM. Ясно, что это никуда не годится с точки зрения безопасности. 

Как же тогда пересылать почту таких клиентов? 

  Лучший способ для них состоит в том, чтобы использовать те SMTP-серверы,
которые предоставляет им их ISP. Обычно нет никакой причины использовать
именно ваш сервер, чтобы пересылать их почту, подойдет любой сервер,
который согласится передавать их почту, и таким сервером в принципе должен
быть почтовый сервер ISP.

  К сожалению, некоторые ISP не просто требуют, чтобы отправляющий хост
находился в их сети, но еще и хотят, чтобы конвертный обратный адрес
пересылаемого через них письма был именно тем почтовым адресом, который
они выдали данному клиенту. Я никогда не видел почтового клиента для
не-Unix ОС, который позволял бы задавать конвертный адрес отправителя,
отличающийся от адреса, который появится в заголовке письма в поле "От";
так что если ваш клиент хочет передать почту через SMTP-сервер его ISP
(и его ISP выполняет вышеописанную проверку адреса), он не сможет вписать
в поле "От" своего письма тот адрес, который вы выдали ему - вся его почта
должна будет иметь обратный адрес в домене его ISP. 

Так что же должен делать мой клиент, если он хочет, чтобы его почта
имела обратный адрес в моем домене, но его ISP - из числа вышеописанных?

  Есть некоторые частичные решения этой проблемы; мне кажется, что ни один
из них не идеален. Вероятно, лучшее - это "POP-before-SMTP": вы позволяете
некоторому IP-адресу передавать через Ваш сервер в течение короткого периода
времени после того, как хост с этим адресом авторизуется через POP. Есть
различные решения POP-before-SMTP; например, тот, который не требует
никакого внесения исправлений в исходные тексты qmail - это relay-ctrl
Брюса Гуентера. Единственная проблема с этим подходом следующая: по крайней
мере в некоторых популярных почтовых клиентов Windows жестко зашито
посылать все поставленные в очередь письма ПЕРЕД проверкой почты. Ваши
пользователи должны будут привыкнуть проверять свою почту перед
отправкой писем.
  Другое возможное решение, которое иногда рекомендуют, заключается в
запуске qmail-smtpd с разными IP-адресами и на нестандартном порту, и
информировании ваших пользователей о том, как сконфигурировать их
почтовые клиенты, чтобы использовать ваш сервер для их исходящей почты.
Одна из проблем заключается в том, что некоторые почтовые клиенты не
позволяют вам устанавливать нестандартный порт SMTP. Другая проблема
состоит в том, что этот способ не предлагает никакой реальной защиты,
только "защиту через мрак". Вы можете несколько обезопасить себя с
использованием tarpit'а. Это поможет предотвратить злоупотребление, если
шлюз будет обнаружен.
  Существуют патчи к qmail-smtpd, для использования SMTP AUTH, расширения
SMTP, которое позволяет выполнить авторизацию по имени пользователя
и паролю для разрешения пересылки. Если почтовые клиенты ваших
пользователей поддерживают SMTP AUTH, то это - превосходный способ позволить
пересылать избранным пользователям не из вашей сети. 

  См. сайт qmail для получения дополнительной информации.