19 ноября 2012 г.

Глупости админиские. На прицеле - 5й национальный канал Украины

Ну не смог удержаться и написать сей пост. (Оным ознаменую ряд статей о том как много у нас горе-админов)
Суть сегодняшнего поста: приходик ко мне бедный пользователь и говорит, что старательно отправляет почту на имя одного адресата в домене @5.ua  (по этическим соображениям не буду указывать кого именно), а ему письма то не доходят вовсе, то доходят но с каким-то искаженным содержимым, то в спам попадают, то ещё какие-то грабли с ним происходят.
Ну у бедного пользователя стоит Chrome и через него он логинится в Google Apps Mail и отправляет письмо в 3 строки (не HTML, нет вложенных файлов, - вообще - просто 3 строки по русски!), а письмо не доходит.
Ок - копаем: Феерично, не правда ли? Разбираем криворукость по частям:
0. Ну, видно, что почта переехала на Google Apps Mail - похвально!...
1. Не особенная проблема, но смотрится странно - MX priority 0 - можно, но лучше не делать. Во всех мануалах стоит начальное priority = 10, ну да ладно...
2. pri=45 mail.5.ua - вот тут начинается магия, - хост вообще не отвечает на SMTP запросы, тоесть, судя по доменному имени там был почтовик, но либо времненно умер (на мемент выявления проблемы), либо умер уже давно, но из DNS не убрали.
3. pri=50 h7.prohosting.com.ua - видимо SMTP хостера, где лежит сайт. Самое удивительное, что он принимает почту для домена @5.ua хотя она и переехала на гугл!!!
и что мы там видим?  Бедолага, который выгребает почту с GMAIL совершенно позабыл про то, что его почта частично поступает ещё и на SMTP сервер провайдера, о чем говорит сообщение о переполненности ящика! Отсюда вытекают его жалобы на, то что он чего-то не получает...

Вообще-то за такое админов пороть надо, и я привожу у себя в блоге эту статейку для того, что бы админы не забывали делать все чисто и правильно.

16 ноября 2012 г.

FALLBACK сервис для WEB портала - спасаемся от проблем!

В этом посте я постараюсь описать одну из техник применяемых мною в повседневной работе при администрировании web серверов. Быть может кому-либо будет полезным такой метод.
Итак, дано:
  • есть web портал (php scripts/mysql databases/static files)
  • необходимость минимального простоя в случае сбоев
  • надобность иметь резервные копии содержимого портала
Вроде бы и так все понятно - резервные попии делаются по расписанию (день, месяц, год, ...), правильно (инкрементный бэкап, сбросы на ленту/DVD,...)- данные не потеряются! Чего ещё надо?
А вот вам ситуация, при чем далеко не гипотетическая: Ваш замечательный сайт http://www.mysupersite.com уже в первой десятке поисковой выдачи, народ валит к Вам на ресурс, реклама дает прибыль, - вобщем ляпота! Вы заглядывая в аналитикс не можете нарадоваться, и все у Вас правильно, и резервные попии и девелопмент сервер для программистов есть и вооще, - все как должно быть. Но тут, внезапно, сайт не отвечает, доступа к серверу нету, а саппорт хостера сообщает, что у них потоп/перегрев/вырубилась хост машина VPS/пропали каналы связи (нужное подчеркнуть) или в сервере сгорели винчестера (сразу 4 в RAID10 :) ) или ещё 100 причин по которым конечные пользователи портала его не видят. Кошмар! Надо что-то срочно сделать, - резервные копии есть, - разворачиваем новый сервак и понеслась...
Знакомо? Многим - наверняка да. Сколько времени потратили? от 1-го ... 2-х часов до нескольких суток (если физически вышли из строя комплектующие сервера, а нового нету).

Как я спасаюсь от этого? все просто - fallback web server! Идея была позаимствована (и немного модифицирована) из практик использованя fallback MTA (вторичный почтовый сервер который занимается отложенной отправкой писем электронной почты).

В общих чертах шаги которые надо проделать таковы:
  1. Заводим второй сервер (физический, если Вы хотите в случае аварии на основном в полном объеме поднять сервис или VPS в случае если необходимо просто "перебится" пока восстанавливается основной сервер) желательно, конечно же не на одной хост площадке, дабы и резервный сервер не накрылся "медным тазом" при проблемах у хостера.
  2. Делаем первичну полную синхронизацию сервисов (ставим такие же версии php/mysql/apache и т.д.), файлов (переносим конфигурации сервисов, статику сайта, скрипты сайта, user uploads и т.д.), баз данных (дампим/ресторим) - в общем делаем почти полностью зеркало сайта - отличатся они будут только адресами.
  3. Включаем master-slave репликацию для MySQL (в моем случае. подробнее: http://dev.mysql.com/doc/refman/5.0/en/replication.html) или подобные техники в любом другом любимом Вами сервере баз данных. Важно, чтобы в результате данные в базах в любой момент времени были синхронны.
  4. Пишем простецкие скрипты на bash с использованием rsync (подробнее: http://rsync.samba.org/) для синхронизации файлов на fallback сервер. Но, не забудьте грамотно выстроить процедуру синхронизации, так как  для очень большего количества файлов в проекте эта процедура может занять много времени, - стоит синхронизировать сайт частями в разное время (редко изменяющиеся скрипты сайта - раз в сутки ночью, файлы пользователей - раз в 1-2 часа.). Подскажу, сразу волшебную опцию для rsync: --bwlimit=<N> Kb/S - без неё вы просто "уложите" основной сайт при синхронизации данных!
Я умышленно не привожу готовых скриптов, примеров конфигураций и пр., для того, чтобы отсеять "linux эникейщиков" молодых администраторов не очень любящих думать своей головой.

После всего Вы получите сервер готовый в любой момент заненить вышедший из строя боевой. Как это сделать? Либо в мануальном режиме (заменить DNS/поменять IP на сервере если можно), либо в полуавтоматическом режиме (watchdog скрипт для мониторинговой системы), либо в полностью автоматическом (Keepalived/Heartbeat и прочие техники)

Каковы ещё выгоды от наличия такого сервера? Из очевидных:
  • Возможность делать резервные копии с fallback сервера не нагружая при этом основной боевой, что очень критично при дампах баз, которые могут блокировать таблицы
  • Быстрое восстановление работоспособности портала в случае серьёзных проблем на основном сервере.
  • Возможность проводить тестирование новых сервисов портала в боевых условиях (с оглядкой на проблемы с репликацией баз данных, подробнее: http://dev.mysql.com/doc/refman/5.0/en/replication-features.html)
  • Возможность при запредельной нагрузке на основной сервер, перераспределить нагрузку на fallback сервер. (я планирую написать отдельную статью про это)
К одной из неочевидных выгод (выявлены при экплуатации танных техник) относится выявление следов взлома основного сайта по синхронизированным файлам, которые взломщик использовал в ходе проникновения и потом удалил на основном сервере.

В любом случае - резервные копии  никогда не мешали! Удачи, - берегите сервера.

13 ноября 2012 г.

Политика использования паролей в Linux

"... всякий админ терпеть не может программистов за их безалаберность в отношении безопасности систем и кода; всякий програмер не меньше ненавидит админов за их параноидальные замашки в отношении той же безопасности..."
(с) народно-айтишная мудрость.

- Тебе не кажется подозрительным, что ты зашел на сервер в 5:32 утра?
- Я не заходил! Я спал... И вообще-то ночью люди спят!
- А какой был у тебя пароль на этоит сервер, тот что я тебе давал, rmQX0Nw3?

- Нет, я такой пароль запомнить не смог, потому поменял на другой!
- И какой-же он у тебя сейчас?
- Секурный, очень: 1q2w3e4r
- А попробуй сейчас войти по ssh и сообщи мне как успехи. ок?
- Не заходит, пишет Access denied, а почему так?
- Потому, Шарик, что ты балбес!...


(из общения админа и программиста какой-нить конторки)

Знакомо? Ещё нет? Ну, тогда лучше, чтобы такая ситуация и не произошла.
Как избавится? Вот простой рецепт, приготовить может каждый имея системные средства.
  1. Меняем простецкие требования по умолчанию для паролей в linux. Для етого правим файлик /etc/pam.d/system-auth где имеется строка вида:
    password    requisite     pam_cracklib.so try_first_pass retry=3
    и добавляем к ней некоторые правила по сложности пароля, а именно:
    password    requisite     pam_cracklib.so try_first_pass retry=3 minlength=10 lcredit=1 ucredit=1 dcredit=1 difok=4
    что добавили:
    - minlength=10 - ну тут понятно.
    - lcredit=1 (lower case) - минимальное к-во строчных букв в пароле
    - ucredit=1 (upper case) - минимальное к-во заглавных букв в пароле
    - dcredit=1 (digits) - - минимальное к-во цифр в пароле
    - difok=4 - минимальное отличное от старых к-во символов, которые необходимо сменить при изменении пароля на новый.
    (подробнее http://linux.die.net/man/8/pam_cracklib)
    Тоесть мы, таким образом заставим пользователей создавать пароли не менее 10 символов в длинну, с минимум одной строчной, одной заглавной буквами и одной цифрой.
  2. Заставляем нерадивых пользователей системы сменить пароль при следующем логине. Для это есть утилита chage в стандартном дистрибутиве linux (подробнее: http://linux.die.net/man/1/chage)
    chage -M 0 -d <yesterday-YYYY-MM-DD> <user-login>
    для желающих автоматизировать процесс, как домашнее задание - написание скрипта, который будет находить пользователей (c uid >= 500) и применять к ним эту команду
 Ну и конечно же необходимо поставить какую-то софтинку для отлова и блокирования злосных брутфорсеров, к примеру, - denyhosts (http://denyhosts.sourceforge.net/) для того, чтобы не сильно досаждали и не смоли подобрать какие-то словарные пароли в стиле 1q2w3e4r .
Берегите свои системы, свои данные и свои нервы! Успехов.

G-WAN - модно, быстро, интересно!

Сегодня расскажу про G-WAN (http://gwan.ch/) - быстрый web сервер с закрытым кодом. Спасибо, в очередной раз, энтузиастам выпускающим интересные вещи, а именно сию поделку, которая без преувеличения поразила скоростью своей работы. Все администраторы web серверов так или иначе должны знать apache/nginx/lighttpd (не нужное зачеркнуть :) ) для того, чтобы вообще постороить web сервис. Но если эти киты индустрии давно на рынке, хорошо документированы, облизаны на всевозможных форумах и давно стали привычными в обиходе софтинками, то G-WAN представился "темной лошадкой" (проприентарный исходный код, вакуум в документации, минимум упоминаний на форумах и вообще - мало историй внедрений) после тестирования которой, так и захотелось на неё поставить!...

Итак:
  • скачали (благо на сайте хоть и не самая свежая версия, но freeware)
  • поставили (забудьте про configure/make - уже в бинарнике 32/64)
  • настроили (только не теряйте голову сразу - тут нет привычного .conf файла, да и надобности в нем нету тоже)
  • запустили (как говорится "из коробки")
  • http://localhost:8080/?hello.c - вуаля, - вот вам и Hello World!
 Вся процедура занимает менее 3-х минут.

А теперь магия! Попробуйте проделать не сложный тест (предполагается, что у вас есть apache/nginx/lighttpd настроенный и работающий) - положить статическую картинку весом в 75к байт и запустить apache benchmark (ab):

ab -c 500 -n 10000 http://www.your-site.com/cool-image.png

как думаете что будет (если пренебречь ограничением по tcp сокетам, которые в среднем израсходуются где-то к 6-8к запросам)? Индеец загнется почти сразу остальные побарахтаются, но выдадут до 80% ошибок в ответах. А вот для G-WAN это вообще не проблема! Не спрашивайте как это работает (исходных кодов нету), но это работает!

Интересно? Продолжаем!

Вот как выглядит исходный код скрипта в ссылке (http://localhost:8080/?hello.c):

#include "gwan.h" // G-WAN exported functions

int main(int argc, char *argv[])
{
   xbuf_cat(get_reply(argv), "Hello World (C)");

   return 200; // return an HTTP code (200:'OK')
}


да, именно - это С! Тоесть вместо PHP/Perl и прочих скриптовых языков с медленными обработчиками, Вы можете писать сайт прямо на С/С++ и он будет работать в сотни раз быстрее, добавим к этому технологию edit & play (автоматическая перекомпиляция кода при правках) и получим некое подобие PHP для С-шников :) Вы спросите, а чем собственно это лучше чем CGI/FastCGI? А тем, что при изменении С кода Вам не нужна перекомпиляция (G-WAN делает это атоматом), в скрипте можно использовать массу встроенных в сервер возможностей как то: аналог memcache и прочее (полный перечень можно найти на сайте или в презентации http://gwan.ch/archives/g-wan_prez.pdf)

На данный момент я занимаюсь тестированием и возможностью внедрения сервера в production окружение. Пока только как static content server для других нагруженных проектов, но в дальнейшем в планах есть освоить методику написания сервлетов для этого сервера и использовать его для отдачи динамического контента.

Больше по теме:
http://www.wikivs.com/wiki/G-WAN_vs_Nginx

Ждите продолжения!