Rise up and walk!...

Прошло достаточно много времени с момента последнего сообщения - надо восстановить историческую справедливость и продолжить делится знаниями с уважаемыми читателями.

В следующих статьях будет много интересного и полезного.
Stay tuned.

SaltStack: управление произвольным количеством файлов конфигураций

Переплываем на Хабр ) Кросспощу свою статью оттуда:
SaltStack: управление произвольным количеством файлов конфигураций

Знакомтесь - SALTStack

Этот пост будет первым из цикла по статей по использованию SALTStack

Итак, начнем!
Что такое SALTStack? (www.saltstack.com) Кроме всего прочего в этой системе можно выделить такие ключевые возможности:

• Управление конфигурациями сервисов на нескольких серверах одновременно
• Удаленный запуск команд на нескольких серверах одновременно
• Получение информации о окружении в режиме реального времени.
• Возможность взаимодействия с SQL/NoSQL базами данных для получения или сохранения конфигураций, результатов выполнения и прочей информации
• Простота настройки и эксплуатации
• Поддержка основных серверных платформ (Linux/Windows)
• Написана на языке Python, который идеально для этого подходит.

Ок, скажете Вы, а что тут принципиально нового по сравнению с Puppet, CFEngine и прочими подобными системами? Да, эти системы выполняют примерно одинаковую функцию, а именно - управляют конфигурациями сотен сервисов на разных физических серверах или облачных конфигурациях. Но у SALT'а есть много отличий, а именно:

• Скорость выполнения задач просто мгновенная, - в асинхронном режиме команду выполняют сотни клиентов одновременно.
• Возможность запускать команды удаленно.
• Обновление конфигураций по команде с сервера, а не автоматически клиентами.
• Современность - поддержка облачных платформ наряду с обычными серверами.
• Огромный community с тысячами рецептов.

Советую для лучшего понимания, начать с обучающего курса
http://docs.saltstack.com/topics/tutorials/walkthrough.html

Тонкости "итилизации" нашего IT

Это первая статья из будущего цикла по внедрению ITSM.

Ну вот и началось!... После успешного завершения курсов ITIL v3 Founation в головах коллег (да чего греха таить, - и в моей тоже) зародились мысли о том самом светлом и безоблачном идеальном IT отделе в своей любимой компании. Тут тебе и правильно оформленный и документированный сервис-ориентированный подход с формализованными процессами, и Service Desk с умными операторами первой линии умеющими пользоваться корпоративной базой знаний, и сама база знаний с описанными инцидентами/проблемами и вариантами их решений, и инцидент менеджмент построенный грамотно, и постоянные улучшения работают, и, естественно, премии за малое к-во выходов за рамки SLA по сервисам в процессе их функционирования, и ... Ну просто загляденье не правда-ли?
Но в процессе внедрения (о, нет, - слишком громко, - пока только в процессе сбора информации для внедрения) сталкиваемся с суровой пост-совковой бизнес машиной, которая как асфальтоукладчик нивелирует все Ваши потуги поднять IT отдел на качественно новый уровень. Я умышленно не буду говорить о крупных игроках рынка, - у них есть возможность нанять думающих в правильном направлении топ менеджеров, которые понимают, что без внедрения ITSM понимать и управлять IT отделом будет очень сложно, - сейчас о том бизнесе который уже вышел из этапа стартапа и, в процессе роста, испытывает острую необходимость оптимизировать рабочие процессы сам того ещё не понимая. :)
Основные проблемы с которыми придется столкнуться:

• Бестолковый топ менеджмент. К сожалению в нашей стране при создании бизнеса мало кто из его создателей задумывается о том, как им правильно потом управлять. И действительно, - купил, привез, перепродал, - зачем много думать. "BP, ROI, CRM, ERP, и .т.д. этого мы не знаем, - это какие-то там люди в бизнес школах изучают, а нам и без этого все понятно"
  
• Закостенелость компаний. Хорошо управляемая, динамично развивающаяся компания может менять что-либо в своей организации/деятельности/отношениях и т.д. очень быстро и без особенных потерь ресурсов и времени. А отличным показателем является возможность изменить что-либо даже без видимых выгод для компании, - просто чтобы не превратится в болото. Для таких компаний внедрения ITSM - не проблема. Надо поменять бизнес процессы, - пожалуйста, но только если это впоследствии приведет к видимым выгодам. Для закостенелых, не умеющих меняться компаний, процесс внедрения ITSM просто невыполним.
  
• Отсутствие корпоративной базы знаний. Наше отношение к знаниям - просто отвратительно! Мы ничего не формализуем, а ведь формализация бизнес процессов дает тысячи выгод: не надо постоянно обучать новых людей отнимая время работающих, -человек сам может изучить описанные БП в которых будет участвовать пользуясь базой знаний. Не страшно потерять ключевого специалиста, - ведь все, что он делал для компании хорошо описано им самим же. Внедрение новых процессов и аудит текущих будет требовать значительно меньше времени.
  
• В общем объеме - низкий уровень знаний персонала. "Тематические тренинги, курсы, семинары, сертификации для персонала? Нет не слышал! Ты на работу должен уже прийти со всем готовеньким!". Или: кум директора занимает руководящую должность в IT? Ну и что, что у него филологическое образование? :) Знакомо, - не так-ли? Особенно это относится к крупным государственным компаниям, да и бизнес таким частенько грешит.

Я привел лишь малую часть тех проблем которые необходимо решить, или хотя бы начать решать перед внедрение ITMS в компании. Ну а если это покажется вам не решаемым, - ну тогда скорее всего вам и не надо ничего внедрять.

... продолжение следует...

Генератор последовательных адресов

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

Сразу прошу прощения за отсутствие обработчиков исключений, - писался для себя и подразумевает осмотрительное использование. Собственно весь интерес - ф-ция yield (https://wiki.python.org/moin/Generators)
Вот пример вывода:

Надеюсь будет полезным не только мне. :)

Использование deploy keys на GITHUB

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

1. Имеется репозиторий на GITHUB (публичный или приватный) 
2. есть система CI (TeamCity, Jenkins/Hudson, scripts, или ещё что-то) работающая на каком-либо linux сервере. 

Все, вроде бы стандартно, при начальном деплое проекта делаем git clone репозитория, на запрос имени пользователя вводим свою учетку на github (или, вы же продвинутый?, авторизовались по ключам предварительно загруженным на странице аккаунта github), но это совершенно не подходит для организации автоматизированного деплоймента. Основная причина и очень часта проблема: разработчики все делают от имени своего аккаунта на VCS системах в том числе и интегрируют свои ключи в процесс CI. Не трудно догадаться что произойдет, когда разработчик по той или иной причине покинет команду, - он в праве изменить свои ключи, или вовсе их удалить и "медный тазик" быстро накрывает весь процесс деплоймента. 

Как избежать? ответ в сабже. GITHUB, в частности, поддерживает внедрение deploy-keys в сам репозиторий (Repository->Settings->Deploy Keys) что напрочь убирает вероятность сломать систему автодеплоймента. Теперь процесс по шагам: 

1. На машине где проводится автодеплой генерируем ssh ключи (к примеру: ssh-keygen -t dsa -b 1024 -f ) от имени того пользователя который будет вызывать git pull . Советую генерировать dsa/1024 ключи для большей секурности. В случае если деплоится много проектов сразу на одну машину, рекомендую добавлять к имени файла-ключа ещё и имя репозитория в который он будет внедрен - так вы никогда не запутаетесь где именно какой ключ. 
2. Внедряем публичную часть созданного ключа в GITHUB (собственно копируем и вставляем в Repository->Settings->Deploy Keys, дав ключу вменяемое название, - к примеру имя CI системы и хоста на котором она работает) 
3. Обязательно необходимо сообщить ssh клиенту как общаться с GITHUB по ssh (по умолчанию необходимо использовать имя пользователя git, а не имя локального пользователя). Для этого необходимо внести соответствующие правки в /home/<deploy-user-name>/.ssh/config: где <reponame>.github.com - фейковое имя хоста для использования в ssh ссылке на ориджен в GITHUB, id_dsa. - приватная часть ключа сгенерированного выше. 
4. Теперь немного магии (которая, конечно не магия вовсе - просто не совсем очевидный момент). В большинстве случаев для клонирования репозитория используется http ссылка на репозиторий на GITHUB, которая для нашего случая совсем не подходит. Надо либо сразу делать клонирование по ssh ссылке, либо заменить уже присутствующую http ссылку на ориджен (git remote rm <http:origin> затем git remote add <ssh:origin>). Не забываем менять в ssh ссылке имя хоста на <reponame>.github.com (создан выше как алиас для github.com но с другими учетными данными) 

Собственно вот и все. После этих процедур вы будете иметь возможность независимо от аккаунтов разработчиков деплоить проекты.

Удаление записи из известных хостов SSH

Не секрет, что администраторам linux систем часто приходится с одного и того же компьютера (рабочей/домашней машинки, к примеру) ходить по ssh на разные хосты. Не стану рассказывать зачем есть папка .ssh в хомяке, собственно как и файлы known_hosts и authorized_keys - нормальному админу грех этого не знать :) Но часто бывает проблема (даже не проблема, - так неудобство) когда уже внесенный в known_hosts публичный ключ некоего хоста становится инвалидным (толи хост-машину поменяли, толи DNS запись или IP адрес перенесли). В таком случае Вы получаете сообщение вида: Естественно нужно понимать, что произошедшее - действительно легитимное изменение фингерпринта хоста, а не хакерская атака. И вот Вам нужно просто снести изменившуюся запись для того, чтобы при следующей попытке зайти на хост снова прошел обмен ключами. Почти всегда это делается руками, но есть простая команда для автоматизации процеса. (у меня cat ~/.ssh/known_hosts | wc -l показывает 98! и копаться в них выискивая нужный ключ - прото долго) вот, что может Вам помочь.

Быстрый консольный способ оценить скорость сетевого соединия в Linux

Предположим есть 2 хоста между которыми необходимо проверить скорость передачи данных. Такая задача возникает в случае необходимости периодически передавать между ними данные для понимания временнЫх издержек при передаче (это, к примеру, могут быть данные репликации MySQL для высоко нагруженной записями БД). Как оценить скорость, если под рукой только консоль? Очень просто, впрочем как и большинство таких задач в linux, просто не совсем очевидно :) Итак для тестов нам понадобятся утилиты nc и dd. На первом хосте (цель для передачи данных) запускаем: Запустили nc в listen mode на порту 12345 На втором хосте (передатчик данных )запускаем: В результате - получаете скорость передачи данных (от вывода dd)

NGINX. Редирект статики для серверов разработки

Дошли, наконец-то руки описать один прелестный прием в сервере nginx. И себе - чтобы не забыть, и Вам, чтобы пользовали.
Итак: имеем production сервер с веб порталом и несколько development серверов, используем git для создания распределенных сред разработки (с последующим мержингом веток разных разработчиков и деплоем на production сервер). Рассмотрим подробнее один из серверов разработчиков (любой, в данном случае), а именно как сделать некоторые полезности при разработке веб портала. Так вот: есть клон git репозитория с файлами скриптов (и прочего стаффа веб приложения) с которым все ясно - программист пишет, комитит, апдейтит и пр. Но вот вопрос как быть с тестами написанного? Самым простым и действенным решением есть развернуть на сервере разработчика весь сайт, который тот разрабатывает и тестируй себе на здоровье! Но вот вопрос со статикой сайта (картинки, css, js, и т.д.) остается открытым - делать 5-20 копий статики накладно, ведь может занимать много места на диске. Потому, используя nginx можно брать статику прямо с production сервера. Нагрузки на него много мы не сделаем, а вот хлама на development серверах будет порядком поменьше, да и проблемы с синхронизацие будут отброшены за ненадобностью.
Собственно вот рецепт: (приведу часть рабочего конфига nginx с пояснениями)
Вообще-то - никакой магии - просто средствами nginx проверяется наличие локально запрошенного файла и, в случае его отсутствия, - редирект на основной сайт.
Вот так вот.

Глупости админиские. На прицеле - 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 сервер провайдера, о чем говорит сообщение о переполненности ящика! Отсюда вытекают его жалобы на, то что он чего-то не получает...

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

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 сервер. (я планирую написать отдельную статью про это)

К одной из неочевидных выгод (выявлены при экплуатации танных техник) относится выявление следов взлома основного сайта по синхронизированным файлам, которые взломщик использовал в ходе проникновения и потом удалил на основном сервере.

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

Политика использования паролей в 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

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

Генерация паролей в *nix - это просто!

Хотелось бы увековечить некий замечательный инструмент системного администратора *nix систем, а именно - простой, не требующий никаких дополнительных средств, кроме встроенных в систему утилит, генератор паролей.

вот такой вот прекрасный shell скрипт для генерации паролей:

i=0; while [ $i -lt <pass_cnt> ]; do  cat /dev/urandom | tr -dc a-z0-9A-Z | head -c<pass_length> ; echo; let i=i+1; done

вобщем-то все гениальное просто:
У нас всегда есть /dev/urandom - в котором много псевдослучайного содержимого, - главное правильно вычленить из него то, что подходит для паролей (не загромождаем пароли всякими :, %, № и т.д. - выставим, что нам надо латинские буквы и цифры a-z0-9A-Z). Что нужно - так это заполнить числами <pass_cnt> - количество генерируемых паролей, <pass_length> - длинна генерируемого пароля. Вуаля!
Примерный вывод:

/home/eugene #i=0; while [ $i -lt 5 ]; do  cat /dev/urandom | tr -dc a-z0-9A-Z | head -c25 ; echo; let i=i+1; done
KuYJfTccG8LXTobjPAvonccQE
TYYWMoNxivCgX1BntWncATGWr
ocDyB9rMZ1mN6Et8EV3wmKiOa
u65z86ptl1ZlhCiGsVZ1s0XD7
tEO6zBn4dxUPtabFb7GrkjjrM

5 паролей, по 25 символов.

Для удобства можно выставить алиасы для bash:
alias pass10='i=0; while [ $i -lt 10 ]; do  cat /dev/urandom | tr -dc a-z0-9A-Z | head -c10 ; echo; let i=i+1; done'
alias pass20='i=0; while [ $i -lt 10 ]; do  cat /dev/urandom | tr -dc a-z0-9A-Z | head -c20 ; echo; let i=i+1; done'

NGINX Сервер по-умолчанию.

...дабы не забыть и потом использовать!..

   С точки зрения SEO, для рабочего web проекта с 20к+ посетителей в сутки очень резонно, чтобы не было возможности ходить на ваш любимый сайт по IP-based url. То есть: если есть сайт http://www.goodsite.com, то ссылки вида http://123.123.123.123 (собственно IP адрес сервера где находится ваш сайт) не должны существовать вообще или должны редиректится с кодом 301 на соответствующие разделы вашего сайта.
   Почему это плохо:
1. Много сайтов используют domain name из url для перехода в соответствующие под-домены, разделы и др. и при введении ip адреса в качестве domain name будут вести себя не предсказуемо.
2. Поисковыми машинами ссылки на http://www.goodsite.com и http://123.123.123.123 будут фактически индексироваться как разные сайты.

Как быть? Достаточно просто:
В повседневной работе я использую сервер nginx Игоря Сысоева в качестве фронтэнда для всех своих проектов и на нем реализация схемы с редиректами проходит достаточно легко.



Собственно рассказывать про rewrite в nginx я не буду - писано уже много (google it!). А вот сама суть в директиве server_name: если указать в качестве имени сервера _ (подчёркивание), то при обращении к не существующему виртуальному хосту, будет отрабатывать именно этот сервер. Ну а внутри него можно разрисовать несколько условий в том случае если у вас много виртуальных хостов.

Информационные технологии в нашем бизнесе. Часть первая: Искали админа? Вот он я!

Очень короткое предисловие.
Многое уже было написано, сказано и раскритиковано в этой теме. Не буду пытаться повторить кого-то (хотя, так или иначе получится ибо я не первый :) ), но очень хочется описать свой личный опыт и попытаться проанализировать как в Украине (а, впрочем, и в других странах ex-СССР) обстоят дела во взаимоотношениях бизнеса и IT с позиции тех кого называют компьютерщики, сис. админы, "программисты", инженеры компьютерных систем и пр. Хотя государство удостоило нас в КЗоТ-е всего-лишь странным словосочетанием "администратор систем" (каких? может машинного доения - не ясно...)
Намеренно оставим за бортом этого цикла постов крупный бизнес (банки/страховые и др.), системных интеграторов, провайдеров и прочие компании в которых от толкового IT департамента во многом зависит прибыль, стабильность работы, безопасность и прочее, - такие компании, в большинстве случаев очень тщательно отбирают персонал и понимают, что IT это не нахлебники, а полноценная часть бизнес процессов компании.

Часть первая: Искали админа? Вот он я!
Первый пост из цикла в котором рассмотрим такую ситуацию: Вы админ и приходите на работу в новую для себя компанию.
Умолчим пока о причинах которые вынуждают компании искать себе специалистов по системному администрированию, - таковые будут рассмотрены отдельным постом. Но вот, Вам понравились/подошли/не было другого выбора (лишнее зачеркнуть) условия описанные в вакансии компании и Вы шлете свое резюме.
И смех и грех №1: Описание вакансии - залог успеха!
Ну тут можно отдельные мемуары писать, но будем краткими, - в 75% случаев описание вакансии у толкового администратора вызывает улыбку. Ведь не зря имеется расхожая шутка о том, что если описание вакансии админа спроектировать на водителя, то получится что-то в духе: "Компании требуется водитель с открытыми категориями A1, A, B, C, D, E, ..., со стажем управления автомобилями почти всех известных марок, опытом слесаря, электрика, моториста, дизельщика, жестянщика. Обязательным является требование умения сконструировать свой собственный двигатель внутреннего сгорания. Плюсом будет опыт участия в ралли и Формуле 1. Испытательный срок - 3 мес. Оклад - 2000 грн., после испытательного срока - 2500 грн.".
Ну, право же, - смешно!
Достаточно часто встречаются описания вакансий для системных администраторов написанных людьми настолько далекими от IT, что в итоге получается просто ахинея, ну вот, к примеру, "... необходимые знания: DHCP, DNS, FTP, VPN, ISDN, OSI, TCP, Internet...". То есть - нашли много интересных сокращений (знакомый/бывший админ сказал написать именно так!) и разместили вакансию... Или вот ещё: "Обязательные знания: Ubuntu linux, 1C Предприятие 7.7" - как вам такая связка? Ну и чтобы совсем добить, вот такое: "управление 8 ПК с Windows, настройка сети, общего доступа; обязательно наличие сертификата CCNA", и т.д. В общем-то много есть подобных перлов на сайтах по трудоустройству, - читатель может ознакомится с такими "вакансиями" потратив 10-15 минут.
И смех и грех №2: Кто приходит на собеседования? Резюме - наше все!
Итак, на такую вакансию, как описано выше, откликается соискатель. В 90% приходит на почту резюме, да еще и какое! ого! 2-3 страницы печатного текста с подробным описанием типа: "доскональные знания MS Windows XP, Vista, 7, MS Word, Excel, PowerPoint, Photoshop, Прокладка сетей, настройка Internet, WiFi, 1C, ...." - ну не администратор - находка! все знает, и работал и там и сям - опыт того и сего. "Да все могу! да я делал это уже 100500 раз! да это легко!". Приходит такой человек на собеседование (кстати проводит его та же секретарша, которая текст "вакансии" создавала), и вот основным вопросом остается только З/П. Сходили к директору - пара вопросов - напутствие и в бой! Правда не всегда интересуются, а почему так много мест работы со сроком менее полугода...

Мне приходилось искать на работу системных администраторов (в свою компанию, друзьям, просто подсказывать знакомым годится ли тот или иной человек им на работу) и картина складывается просто удручающая: во время кризиса 2008-09 годов банки, страховые компании, средний бизнес уволили толпу псевдо системных администраторов. Кто это такие? В 75% случаев - студенты старших курсов, которые, научившись хоть как-то  делать такие вещи как:
1. ставить windows - спросите у них, что такое tcp/445 порт в системе? или что такое принт-сервер?
2. настраивать сеть - спросите что за маска под-сети такая хитрая 255.255.224.0? или вот, - зачем нужна команда route?
3. ставить софт - обязательно спросите какие альтернативы есть для MS Word? или ставил ли человек хоть раз нормальный лицензионный продукт?
4. управлять базами данных - спросите в чём разница между MS SQL и MY SQL?
5. закупать оборудование - спросите про разницу между SATA и SAS? или что такое tape autoloader?
6. создавать IT инфраструктуру - спросите что такое firewall? или почему в том или ином сервере должно быть именно 16Гб ОЗУ?
и т.д.
Ответы на эти простенькие вопросы таких вот псевдо админов порадуют своей богатой гаммой тупостей.

Плодами работы вот таких вот "товарищей" на мелкий и средний бизнес становятся бестолково настроенные офисные инфраструктуры, тысячи в пустую потраченных гривен, простои в работе компаний в результате постоянных сбоев, отсутствие актуальных резервных копий критичных данных, и, в итоге - абсолютный негатив по отношению к самой профессии системного администратора. Ещё одним побочным эффектом работы таких людей является устоявшееся мнение, что админ это человек "принеси-подай": ведь если посмотреть с точки зрения руководства - сидит человек ничего не делает/создает видимость работы (таковы уж реалии - если все более менее правильно настроено - работы не много) - пусть хоть что-то сделает, - лампочки заменит, груз поднимет, приберёт и т.д....


(Продолжение следует)

WEB SERVER. Права доступа к файлам и каталогам сайта.

Каждый системный администратор, которому доводилось управлять работой любого web сервера, сталкивался с несколькими проблемами связанными с разграничением доступа к файлам (будь-то скрипты, фотографии, js, css, и т.д.). Для начала рассмотрим типичные ситуации приводящие к проблемам в дальнейшем:
1. Ничего не делание или "я поставил сайт по инструкции производителя". Так, в основном, поступают начинающие администраторы или те, кому лень думать, а тем более, делать что-либо. Тоесть скачали, распаковали, положили сайт со скриптами, скажем, в /var/www/super-site, прописали конфиги web сервера, нового сайта для подключения к БД и все! Работа зделана и http://super-site.com.ua открывается, пользователи регистрируются, картинки и файлики заливаются - все работает!
2. Заливка файлов на сервер или "что-то пользователи не могут залить свои файлы на сервер!?". Ах, ну да, мы же не дочитали до конца, - там ведь написано, что web сервер должен иметь права на запись в папочку upload где-то в файловой структуре сайта. Не долго думая, ставим 0777 на нужную папочку и вот - файлики пишутся - проблема решена!
3. Совместная работа или "что-то программист Вася не может зделать необходимый ребрендинг нашего супер сайта". Да, оказывается Вася не может редактировать файлы в структуре сайта, - нет прав на запись. Не беда, - дадим Васе нужные права. Вот только не ясно, сколько таких Вась будет в дальнейшем, - да не будем заморачиваться и поставим на весь сайт права 0777. Вот - теперь программист Вася и его коллеги (вебмастер Коля, SEO оптимизатор Ваня) смогут безпроблемно поменять файлы в сайте так, как им надо. Вуаля!..

Для мало-мальски соображающих админов описанный сюжет - предверие апокалипсиса с данными сайта, а потенциально и со всем сервером. На выходе мы имеем набор каталогов и файлов которые может модифицировать/удалить любой пользователь системы в т.ч. и злоумышленник, проникший на сайт, от имени web сервера.

Поделюсь своим видением того, как правильно организовать разграничение прав доступа.
1. Самое главное в начале разработки модели доступа полностью описать все "действующие лица". Первое, что приходит в голову: собственно процесс web сервера (httpd/nginx/lighttpd/...) и персонал обслуживающий сайт на уровне прямого доступа к файлам (программисты, дизайнеры и пр.). Все вроде бы правильно, однако не стоит забывать, что есть ещё и системы резервного копирования, системы автоматизированного деплоймента, сторонние сервисы (как то ftp для прямого доступа к контенту сайта), и прочие.
2. Не менее важно правильное определение "узких" мест фаловой структуры сайта. Каталоги для записи пользовательского контента, разнообразных кешей скриптов, статических библтотек и прочего. Все эти места будут имет отличные от основной части права на доступ к своему содержимому.

Предположим в тестовой системе имеется несложный сайт с такой структурой:
/var/www/site
                |->application-core
                |->public-files
                     |->users-content
                |->cache
и имеем web сервер, 2-х программистов, одного дизайнера и систему резервного копирования.
Далее решаем задачу с правами пользуясь знаниями (man chown, man chmod, man usermod, bash scripting) и логикой описанной ниже.
1. Ясно, что для того, чтобы содержимое сайта было отображено клиенту необходимо, чтобы web сервер мог читать все необходимые ему файлы и входить в каталоги. Однако, старайтесь давать web серверу минимум прав и только там, где это нужно. К примеру, если вы после установки сайта запустили скрипт setup.php или install.php, по его завершении, уберите возможность web серверу читать этот файл - так вы обезопасите себя от возможности его повторного запуска. Собственно для того, что бы вев-сервер имел доступ на чтение файлов достаточно установить права на чтение (r) для всех файлов сайта для пользователей отличных от владельца/группы. Установите так же права на исполнение (x) для всех каталогов.
2. Дайте програмистам и дизайнеру почти полную свободу в доступе к файлам сайта, - зделайте для этих людей отдельную группу в системе (скажем, developers) и пропишите её как основную для каждого аккакунта (usermod -g вам в помощь). Назначте владельцем файлов и каталогов сайта кого-то из программистов и задайте им группу developers. Дайте полные права для владельца и группы (rw) для файлов, а для каталогов, - ещё и доступ на вход (x).
3. Не забывайте о том, что атрибут eXecute (x) - совершенно ненужная вещь для файлов сайта (конечно если это не cgi скрипты, которые необходимо запускать), а вот для каталогов - очень даже необходимая.
4. Систему резервного копирования можно по сути в разрезе прав доступа приравнять к веб серверу, - соответственно для её функционирования будет достаточно прав указанных в п.1
5. Есть ещё несколько каталогов в которые веб-сервер должен иметь возможность записывать файлы (загруженный пользователями контент, свои кэши и прочее) для них необходимо поступить с правами так: сделать их владельцем учётную запись от которой работает веб-сервер, группой назначить developers (см. п. 2). Владельцам и группе дать полные права (rw), а  для каталогов ещё и выполение (x), остальным пользователям системы дать доступ только для чтения (для системы резервного копирования).

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