Существует множество фичей упрощающих жизнь системному администратору. Различные системы удаленного управления позволяют установить ОС на девственно-чистый сервер и сегодня это совсем не проблема. Даже наличие второго винчестера превращает проблему переустановки операционки в банальность. Поэтому в этой статье рассмотрим самый суровый из случаев: пусть на сервере имеется только один полностью разбитый винчестер, а наша задача — удалённо переустановить ОС.

Удивлённо поднимем брови, умиляясь тому, как гибка наша любимая операционка, засучим рукава и приступим к делу.

Однажды, встал такой вопрос: а почему у меня 2 мышки и 1 курсор? И тогда мы начали искать решение и мы его нашли. Это был проект Сpnmouse, правда он был заброшен еще в 2004 году, но это нам ни капли не помешало.

Summary

Announced: 2010-05-20
Credits: 80sec
Affects: сайты на ngnix+php с возможностью загрузки файлов в директории с fastcgi_pass

Background

Зачастую How-To по настройке связки nginx с php-fpm / php-cgi есть подобные строчки:

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    include fastcgi_params;
}

Допустим есть у нас под Linux софтварный RAID1 собранный с помощью mdadm:

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb[1] sda[0]
      8387572 blocks super 1.2 [2/2] [UU]

И появился у нас еще один винчестер который хотелось бы воткнуть в данную машину расширив доступное дисковое пространство не потеряв при этом в отказоустойчивости т.е. перейти с RAID1 на RAID5.

Возможно, кому-то уже доводилось попадать в неприятную ситуацию – когда по какой-то причине выходит из строя RAID-контроллер, или просто массив «рассыпается». Особенно часто это происходит с дешевыми контроллерами, встроенными в материнскую плату. Расскажу небольшую, но поучительную историю, произошедшую со мной на заре моей админской карьеры.

До недавних пор я думал, что единственный способ узнать о причине BSOD'а – это белые буковки на синем «экране смерти». Недавние события немного расширили мои познания в области диагностирования неполадок, и этими знаниями я хочу поделиться с вами, хабражители.
Случилась очередная поломка системы у очередного клиента. «Синий экран, и нечего не шевелится» — так описала проблему девушка, которая за компьютером работала. Дело было около 18 вечера, и ехать на выезд совсем не хотелось. Перезвонив клиенту, я сказал, что компьютер посмотрю удаленно, хотя сам понимал, что заниматься ним придется завтра. Тем не менее совесть не дала просто забыть о компе до завтра.

Ну а в качестве подарка — история с википедии:

«Отцом» праздника является американский сисадмин с 20-летним стажем Тед Кекатос, посчитавший, что хоть раз в год системные администраторы должны чувствовать благодарность со стороны пользователей. Первый раз данный праздник был отмечен 28 июля 1999 года. Это был просто пикник на природе на окраине Чикаго, в котором приняли участие члены небольшой софтверной компании.

30 июля — День системного администратора. Озадачившись вопросом, чем бы порадовать своих коллег, я составил небольшой списочек магазинов, где можно найти прикольные подарки для айтишника. Кому интересно заходите под хабракат

Предупреждение: Описанное в статье несколько устарело, т.к. я забросил винды в эпоху Windows 2003.

Каждый раз, когда меня знакомые спрашивают: «какой антивирус лучше?», я могу сказать только одно: «антивирус — как придворный шаман. Бывают лучше, бывают хуже, но определить, кто лучше камлает, не получится». Антивирус не гарантирует защиту от вирусов, более того, у него есть полное моральное право пропустить новую заразу и начать её детектить дня через 2-3 после «инцидента». Т.е. как основное средство защиты он годится не очень.

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

Теория

Любой уважающий себя вирус, оказавшись запущенным, тем или иным методом стремится в системе закрепиться, т.е. создаёт исполняемый файл или библиотеку, которая прописывается тем или иным образом в запуск. «Авто» запуск или в форме «дополнения» к другим исполняемым файлам (debugger, hander, плагин, и т.д.) — не важно. Важно: существует барьер под названием «запуск кода». Даже старые-добрые вирусы, дописывающие себя в исполняемые файлы, всё равно должны иметь возможность писать в файлы, которые предполагается запускать.

Безусловно, есть вирусы, размножающиеся без создания файлов (например, мс-бласт). Но условием появления этого вируса должна быть доступность сервера для обращений с носителей вируса или запуск кода через эксплоит в браузере\сетевой компоненте. В случае дыры в браузере дальнейшее размножение не возможно (т.к. нужно обращаться к браузерам на других машинах, а это требует поднятия сервера, куда будут ходить другие пользователи и мотивации пользователям ходить именно на этот узел). В случае дыры в сетевой компоненте и размножения без сохранения на диск, описанная мною методика с большой вероятностью работать не будет и возможна эпидемия. Однако, я не уверен, что антивирусы поймают такой 0day эксплоит, плюс, их (дыры) довольно резво фиксят, так что этот сценарий я откладываю как маловероятный. Наличие же файрволов ещё более уменьшает их опасность. От не-0day вполне же спасает своевременная (автоматизированная) установка обновлений.

Итак, основную бытовую опасность представляют вирусы, запускающиеся «из файла» (хотя бы потому, что они переживают перезагрузку компьютера). Если мы запретим каким-то образом запуск «неправильных» файлов, то проблема будет решена (т.к. несохраняющийся в файле вирус не сможет пережить перезагрузку, а в случае запуска с правами пользователя, даже банального релогина).

В Windows существует технология — политика ограниченного запуска приложений. Её можно активировать в режиме «запрещать всё, что не разрешено». Если поставить запрет полный — для всех, включая администраторов, все файлы, включая библиотеки, то мы получим точную гарантию того, что посторонний (не входящий в список разрешённых) файл не будет запущен. По-крайней мере я пока не слышал, чтобы в этой технологии были дыры. Обращаю внимание, нужно запрещать и библиотеки тоже, потому что печально известный конфикер запускается с флешек именно с помощью запуска библиотеки обманом rundll32.

Однако, запреты и разрешения не будут иметь смысла, если не сформулировать правила, которые запретят запуск «чужаков».

Модель безопасности

Перед тем, как описать подробно конфигурацию, сформулирую теоретические принципы её организации:

1. То, куда пользователь может писать закрыто для запуска.
2. То, что пользователь может запускать, закрыто для записи.

Введение.
Мне повезло работать в организации которая развивается, и время от времени возникают новые задачи, позволяющие и мне расти. На этот раз мне было необходимо объединить головной офис и второй филиал. Задача для меня не новая, но к её решению я решил подойти иначе нежели раньше.
На текущий момент в головном офисе установлена FreeBSD + mpd5 в качестве PPTP сервера. В первом филиале аналогично(за исключением того что используется как vpn клиент). Так же есть 8 точек где установлено по одному компьютеру с ОС Windows XP «цепляющихся» к головному стандартным клиентом этой ОС.
Мне необходимо создать еще один туннель между двумя сетями, но любимую ОС FreeBSD я использовать не могу, в силу ограниченного места для установки роутера во втором филиале(это магазин розничной торговли, все оборудование приютилось на узеньком стелаже). К тому же хотелось попробовать прошивку dd-wrt, о которой так много слышал, в деле.

Заголовок можно продолжить:… или плавный перевод почты на другой сервер.
Недавно встала задача — реализовать возможность использования почтового сервера, не имеющего прямого выхода в интернет. Причем работать он должен вместо старого, который работает, естественно под другим IP-адресом.

20 июня вышел в свет Chef 0.9.0, и затем ещё несколько патчей, устраняющих ошибки в этом продукте. Фактически можно рекомендовать к использованию, начиная с версии 0.9.4.

Изменены протоколы работы клиентов и сервера, поэтому обновление с Chef 0.8 надо производить и на сервере, и на клиентских машинах. Сам процесс обновления тривиален (на сервере при условии установки из гемов — gem install chef chef-server chef-server-api chef-server-webui chef-solr ohai, плюс рестарт сервисов, плюс rake install, на клиенте просто gem i chef).

Основные изменения затронули механизм хранения «кулинарных книг», — теперь можно поддерживать одновременно несколько версий одной книги. Улучшена поддержка Windows-клиентов.

С чего все начиналось

«Есть 2 типа админов — те, кто ещё не делают бекапы, и те, кто уже делают.»
Будучи первым типом админа, после случайного rm -rf * в директории с проектом, очень печально осознавать, что последняя резервная копия была сделана около полугода назад. Попав в такую ситуацию, я начал поиск простого и не ресурсоемкого средства для резервного копирования информации.
Критерии:
1) Возможность делать бекапы на лету в условиях ограниченных системных ресурсов (например VPS)
2) Возможность нативно удалять устаревшие бекапы
3) Возможность работать с примонтированной файловой системой

Под катом описан пример перевода файловых серверов на BitTorrent.

Бесплатные решения Mozilla Foundation под Windows для электронной почты и интернета уже давно используются в нашей организации — функциональные, удобные и относительно стабильные.
И всё бы ничего — но рано или поздно встает вопрос об автоматизации обновления этих продуктов.
Пробороздив просторы интернета, удалось узнать, что существует несколько интересных способов обновлений.
Один из них — создание собственного сервера обновлений — в общем всем хороший способ, но с ходу не получилось с ним разобраться (если у кого-то есть опыт — делитесь!). Доступно по ссылке.
Я же расскажу про другой способ.

Несколькими постами раньше уже были темы об использовании SMS уведомлений в Nagios. Сегодня я расскажу ещё об одном способе уведомлений. Нижеописанный способ несколько надёжнее описанных ранее, но и требует некоторых денежных вложений. Он полезен в том случае, когда какие-то из уведомлений являются критически важными (как, например, выход кондиционера из строя или увеличение влажности).

Способ заключается использовании мобильного телефона с корпоративным тарифом (дабы деньги на телефоне не кончились неожиданно).

Физически подключается к серверу по bluetooth, com или usb. На уровне ПО мы будем использовать два скрипта: один из них умеет отправлять sms, второй проверяет статус мобильной сети. Если мобильная сеть недоступна, то nagios отправляет сообщение на email.

Оба скрипта написаны на python и используют библиотеку gammu для подключения к телефону.

Прочитал топик SMS-уведомления из Nagios малой кровью и удивился почему автор называет это «малой» кровью…
Хочу рассказать про свой способ оповещения при помощи SMS, при котором время получения сообщения как минимум меньше и как максимум вездесущий Google не узнает номера вашего мобильного телефона.

Стоял как-то раз админ в курилке и думал — а как бы ему так в нерабочее время вдали от компьютера и интернетов узнать, что на каком-то из его серверов проблема возникла. Можно конечно посадить студента за монитор с Nagios, чтоб он если что звонил админу и говорил «Тут красненькое что-то появилось»… Стоп. Звонил. На мобильный. Нафиг студента, SMS можно получать. На этом мысль остановилась и админ пошёл пить кофе. Потом вернулся и сел за рабочее место, где в браузуре был загружен Google Calendar… и решение пришло само.

Уже второе письмо отправленное с аккаунта Gmail не доходит до адресата, сообщая следующее:

«Delivery to the following recipient failed permanently:

ekaterina@*.com

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 591 591 ekaterina@*.com your host [74.125.82.177] is blacklisted by dnsbl.sorbs.net. Send your questions to blacklist-admin@mx1.*.org (state 14).»

Если кратко: Не удалось доставить сообщение, так как удаленный сервер отклонил его в связи в подозрением на спам.

Что же это получается? Какие-то @#$% занесли Google в спам-лист?

Приветствую!

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