Серверное администрирование *

Здравствуйте уважаемое хабросообщество.

Понадобившись в один прекрасный день настроить агрегирование сетевых интерфейсов на рабочем сервере, но (к большому удивлению) не найдя ни одной статьи на хабре про технологию ipmp, решил написать не большой очерк-ман по установке и внедрению IPMP (IP Multipathing) в Solaris 10. Хочу сразу предупредить, что статья несет в основном практическую нагрузку, поэтому заранее извиняюсь если где то не в полном объеме раскрыл теоретическую составляющую данной темы.
И так все работы были выполнены на сервере Oracle Sun T3-1, с пропатченным ILOM-м, Solaris 10 на борту и двумя сетевыми карточками igb0 и igb1.

root@s1-solaris1#cat /etc/release
Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
Copyright 1983, 2011, Oracle and/or its affiliates. All rights reserved.
Assembled 23 August 2011

root@s1-solaris1#uname -a
SunOS s1-solaris1 5.10 Generic_147440-09 sun4v sparc sun4v

Но сначала немного теории:

IPMP — это технология объединения физических каналов (интерфейсов), для балансировки нагрузки исходящего трафика и отказоустойчивости входящего трафика. В solaris-е, ipmp присутствует начиная с 8-ой версии и управляется демоном in.mpathd.

В нашей компании в качестве почтового сервера используется Zimbra Collaboration Server. И хотя при наборе адреса подходящие имена автоматически подставляются в адресное поле, однажды была поставлена задача сделать общую адресную книгу на базе GAL (global address list). Преимущество такой книги в том, что она всегда является актуальной, операции над акаунтами (удаление/добавление/редактирование) автоматически применяются к книге и отображаются у всех пользователей. В принципе задача не сложная, но как оказалось несколько заковыристая. Поэтому я опишу весь процесс, дабы помочь тем, кто столкнется с подобным. А также приведу примеры исправления возможных ошибок.

Описание касается Zimbra Coloboration Server версии 7.1.x установленной на Ubuntu server. Описывается настройка GAL в режиме «Внутренний». Использованы материалы из статьи GAL Sync Account, а также Zimbra forum

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

 

Задача — на минимальных ресурсах VPS развернуть хостинг нескольких не нагруженных сайтов. Сделать это быстро и удобно с минимальными проблемами в будущем и не падать на пиковых нагрузках.

Основные принципы:

1. ОС — Centos-6 86_x64 потому что стабильно, удобно и легко обновляемо.
2. Никакого самосборного софта. А то как говорится «командой make && make install любой дистрибутив превращается в Slackware.»

Есть несколько идентичных серверов (4 ноды) на Amazon EC2 с Ubuntu. Каждый генерирует и хранит у себя на диске кэш, который хотелось бы синхронизировать. Но простой rsync тут не подойдет — файлов несколько миллиардов, nfs — слишком медлителен, и т. д. Полный список рассмотренных вариантов с пояснениями ниже.

К тому же, время от времени нужно удалять устаревшие файлы сразу на всех серверах, что пока делается вручную и занимает несколько суток. Вопрос наиболее быстрой для такого Use Case файловой системы планирую описать позже. Оговорюсь только, что по нескольким причинам была выбрана XFS.

После теста нескольких кластерных технологий и файловых систем, по совету старшего товарища, решили использовать тот же rsync, но в связке с inotify. Немного поискав в интернете готовое такое решение, дабы не изобретать велосипед, наткнулся на csyncd, inosync и lsyncd. На хабре уже была статья о csyncd, но он тут не подходит, т.к. хранит список файлов в базе SQLite, которая вряд-ли сможет сносно работать даже с миллионом записей. Да и лишнее звено при таких объемах ни к чему. А вот lsyncd оказался именно тем, что нам и было нужно.

UPD: Как показала практика, необходимо ощутимое измение и дополние в тексте. Я решил внести лишь незначительные правки в основную часть, а новыми выводами поделиться в конце статьи.

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

Для этого мы будем использовать 4 сервера на Linux CentOS 5.5, а так же Apache, Tomcat6, mod_jk, Heartbeat.
web1, web2 сервера — для распределения запросов средствами Apache и отказоустойчивости средствами Heartbeat. tomcat1, tomcat2 сервера — Tomcat сервера для Java-приложения.

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

IAdmin — это система создана для автоматической генерации конфигов Bind на хостинговом сервере и представляет собой базу iadmin в БД MySQL и скрипт, который на основании данных из базы генерирует конфигурационные файлы. Для настройки Bind используются таблицы dns_domains, dns_records, dns_subgmail. Основной скрипт, написанный на перле читает данные из БД iadmin и создаёт файлы конфигурации. Файлы зоны генерируются в дирректории /var/cache/bind/. Там же хранятся и прочие файлы зон, которые не обслуживаются системой iadmin. Этой же системой создаётся конфиг для secondary-DNS, который туда и переносится. До тех пор, пока скрипт не отработает, все изменения из БД НЕ материализуются.

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

Мы ежедневно используем аппаратное обеспечение от компании Dell.

За последний прошедший год мы убедились в прекрасной работе оборудования от компании Dell и теперь хотим рассказать о преимуществах серверов поподробнее.

В данной статье, расскажу об удобстве iDRAC6 и его виртуальной консоли.

iDRAC6 – мощное средство удаленного управления сервером, что позволит устанавливать и переустанавливать ОС самим.

При миграции сервера в облако возникла необходимость разместить несколько веб-сайтов, работающих по HTTPS на одном физическом IP-адресе.
При этом нужно было остаться на той же операционной системе CentOS 5.6 и штатном apache-2.2.19.
Готового решения для CentOS не нашел, поэтому предлагаю свой вариант решения.

Теория

Согласно RFC 4366, раздел 3.1. Server Name Indication это возможно.
Для полноценной работы это расширение должен поддерживать и сервер и клиент (браузер).

Практика

Поддержка расширения SNI согласно Wikipedia появилась в Apache HTTP Server начиная с версии 2.2.12.
Подробности есть в Apache Wiki.
Для работы расширения нужна библиотека OpenSSL версии 0.9.8f или выше.
Проблема в том, что в CentOS 5.6 встроен OpenSSL версии 0.9.8e, и «поднять» ему версию не так то просто, т.к. именно на эту версию завязано много других компонент.
Собирать отдельный OpenSSL и Apache вне дерева пакетов — неспортивно.
В процессе поиска решения наткнулся на альтернативу: библиотеку gnutls и модуль mod_gnutls.
Библиотека gnutls в системе тоже присутствует и тоже очень старая, правда достаточно безболезненно удаляется вместе с зависимостями.

В результате были собраны и установлены «свежие» пакеты gnutls и mod_gnutls, которые дали нужный функционал с минимальным влиянием на остальную систему. Под катом подробности по процессу сборки и примеры файлов конфигурации.

По данным Netcraft Web Server Survey за июнь 2011 года, доля веб-сервера Microsoft IIS на всех доменах в Сети продолжила падать и с майских 18,37% опустилась до уровня 16,82%. Это самый низкий показатель с конца 1997 года.

У Nginx третье место (6,55%).

На любом околосетевом форуме легко найти с десяток веток о выборе оборудования для BGP-пиринга с возможностью «держать две, три, пять, двадцать пять фулвью». Большинство таких веток выливается в холивары на тему Cisco vs. Juniper или еще чего похуже. Офлайновое же их развитие нередко напоминает мультфильм о шести шапках из одной овичины. В общем, бывает смешно.

И крайне редко обсуждается вопрос о необходимости этого самого фулвью.

1. Постановка задачи

Дано
Debian-сервер «из коробки» (установлен из дистрибутива)

Задача
Организовать работу нескольких проектов на сервере, чтобы люди, которые ими занимаются, не имели доступа к соседним проектам:

• Ограничить возможность обзора файловой системы определенной папкой для пользователя проекта.
• Ограничить возможность запуска бинарников пользователями
• Ограничить возможность открытия портов на сервере (нужно как-то по другому сформулировать)
• Автоматизировать добавление пользователя в систему: создание папки, конфига apache, пользователей mysql или postgres

Как известно специалистам, в современном сервере более 10% стоимости составляет корпус. Стоимость корпуса в конечном счете сказывается на стоимости услуг для клиентов датацентра. Ранее наша компания разработала экономичные 2U-корпуса, которые позволили уменьшить себестоимость серверов начального уровня, что не могло не порадовать наших клиентов. Мы решили развить эту идею, и рассматривали дальнейшие пути снижения себестоимости наших услуг. А поскольку наша компания является экологически сознательной, мы успешно и полностью реализовали новый производственный проект — серверные корпуса из картона:

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

Эта история произошла со мной в течение предыдущей недели — с 26-го по 31 января 2009. Прожив этот чудесно крохотный период своей жизни, я осознал необходимость простых вещей, поверил в существование «случая» и все более разочаровался в людях. Тегами этой недели были RAID, Инфобокс и бекап. Хотя началось-то все гораздо раньше…

Это точно не новость, но я только недавно набрался таки решимости для покупки яндексовского поиска для нашего сайта и… был весьма удивлен, обнаружив единственный вариант лицензии: «бесплатно» company.yandex.ru/technology/products/Yandex-Server/conditions.xml
Беглое исследование показало, что массово продукт еще не используется, на хабре этой информации так же не нашлось.
Установка и конфигурация «по-быстрому», в общем, проблемы не составила; локальный Яндекс довольно шустро проиндексировал более 300 тысяч документов (в индексе «Большого» Я их не более 100 тысяч) и забрав тпримерно 2,6 gb под индекс.
Я доволен; качество поиска — вполне, xml отдается без проблем.
Ищем только по html, txt — невелика беда.

Как сделать себе 100 почтовых ящиков вида моё@имя.ru, каждый объемом 6,5 гигабайт, и платить за это всего 1 рубль в день?

Под катом — рассказываю пошагово. Для тех, кто не знал про это, или знал, но неохота было разбираться.

Зачем? Для личных целей — чтобы на визитке не стыдно было печатать какой-нибудь «vasya-p1982-2@bk.ru». Для организаций тоже пригодится. В компании, которой я работал, на весь штат сотрудников на хостинге было всего 200 мегабайт места под почту. Этого было, разумеется, недостаточно, и сисадминша ходила и гавкала на сотрудников, снижая суммарный объем позитива во Вселенной, что абсолютно недопустимо :)