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

Алоха граждане!

ПрогуГливаясь в инетах от делать нечего, наткнулся на одну утилиту.
А если быть точнее то это набор утилит которые нам всем очень хорошо знакомы:

Ping, Ping6, Traceroute, Traceroute6, NSlookup, WHOIS, HostInfo

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

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

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

Интро

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

Вопрос номер 0 — зачем?

В посте про pnp4nagios я писал «Nagios/Pnp4Nagios не замена комплексу сбора статистики о состоянии системы». Почему я так думаю? Потому что 1) статистика состояния системы обширна и включает множество показателей 2) не всегда есть смысл их мониторить, точнее генерировать алерты. Например, знать сколько сколько операций ввода-вывода делает диск или происходит переключений контекста неплохо, но почти никогда не критично. Ну и кроме того, Nagios просто не предназначен для этого. В данной статье я не буду делать полное описание системы, ограничусь лишь особенно интересными, с моей точки зрения, моментами.

Вопрос номер 1 — почему collectd?

Основные моменты почему из Munin, Cacti и прочих я выбрал collectd:

1. Масштабируемость
2. Легковесность
3. Концепция — всё есть плагины
4. Сбор и запись данных разделены
5. Количество собираемых показателей
6. Расширяемость

Новый выпуск Chef принёс с собой поддержку Windows и Scientific Linux в качестве клиента, более корректную поддержку FreeBSD, поддержку Ruby 1.9, а также множество исправлений.

Всем рекомендую обновиться, так как исправлена одна серьёзная уязвимость.

Update: в этом выпуске также обнаружено несколько недоработок (самая критичная — не совсем корректное изменение логики работы шаблонов), так что в течение ближайших дней можно ожидать ещё одной версии.

#include

Зачастую, краеугольным камнем производительности работы сервера является скорость работы файловой системы. Её можно увеличить с помощью создания дисковых массивов RAID0 — запись/чтение побитово производится на оба диска, однако рано или поздно слоты под диски заканчиваются, надёжность RAID0 оставляет желать лучшего — при выходе одного из дисков, рушится вся система. RAID10 опять же упираемся в количество дисков.

Как альтернатива, использование сетевых фс. Наибольшее распространение получила NFS, но для боевых задач с её скоростью и неочевидностью настройки прав доступа практически непригодна.
«Сравнивать GPFS и LustreFS — это как сравнивать IBM и SUN.»
Анонимус из интернетов.
В ТОП-300 суперкомпьютеров Мира половина из первых 50 используют LustreFS, которая очень проста в первоначальной настройке.

Часто перед системными администраторами, как впрочем и перед множеством других околоайтишных людей, возникает необходимость в написании статей, кратких руководств и рецептов настройки оборудования и разного рода софта. В огромном числе подобного рода публикаций можно встретить упоминания о ip-адресах и доменных именах; при этом, фантазия авторов не знает границ, встречаются все виды невозможных с точки зрения двоичной арифметики адресов вроде «120.340.560.780/22» и доменов, к примеру «domen.ru», «test.net» и др.

Хочется предостеречь авторов от подобной практики, посколько это вносит сумятицу в документацию, особенно в случае правки статьи, составленной несколькими людьми, а так-же впрямую противоречит рекомендациям комитета IETF, имеющего на этот счет вполне четкие и формализованные рекомендации:

• Согласно RFC 2606 в качестве доменных имен для примеров в документации допустимо использование доменов и поддоменов: .example, example.com, example.net и example.org
• Согласно RFC 5735 в качестве «белых» ip-адресов для примеров в документации допустимо использование ip-диапазонов: 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24

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

Чем различается скрипт и программа? Вовсе не используемым языком или наличием интерфейса.

Главная разница — в наличии у программы обширнейшей оболочки, не связанной «содержимым» программы. В зависимости от платформы, это могут быть страницы руководства, поддержка нескольких языков, наличие функционала по установке/удалению, исполнение соглашений об интерфейсе (командной строки, или иных средств взаимодействия), интерфейсы в общем реестре и т.д… Программа должна уметь работать в любой документированной среде, предусматривать различные ситуации (круче всего с этим у программ под unix, которые используют ./configure для определения, собственно, где они, что можно, а что нельзя на этой (очередной) платформе).

Скрипт же, в строго обратном смысле: он предназначен для решения конкретной проблемы «здесь и сейчас». Никто не ожидает от скрипта, который отсылает статистику, способности делать это одновременно на solaris'е, freeBSD и windows embedded standard с cygwin'ом на борту.

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

Разница между скриптом и программой — административная.

Любой linux администратор наверняка наблюдал аномальные пики на RRD графиках. Пики появляются вследствие нарушения процесса сбора отслеживаемой величины и портят картину на графике. Это нормальное явление для RRD.

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

Под катом будет рассказано о настройке отказоустойчивого кластера, для запуска биллинговой системы NetUР UTM5, настройке шифрования и резервного копирования «ценных» данных.

Я часто задаюсь вопросом: бывает ли у сантехников такой момент в их карьере, когда после очистки очередного засорившегося водостока они начинают ненавидеть свою профессию? Ненавидеть трубы. Ненавидеть шпатлёвку. Ненавидеть все уловки, которые они выучили за годы, ненавидеть учиться новым. Ради бога, это ведь всего лишь сантехника: соединять трубы и пускать по ним жидкость. Неужели это может быть сложно?

Моё почтение! Недавно меня попросили рассказать о том, как контролируют потоки информации в Антарктиде. Немного посовещавшись сам с собой, я решил рассказать обо всех проблемах, связанных с компьютерами и связью. Рассказ будет касаться, в основном, ситуации в обсерватории Мирный, хотя большая часть проблем характерна и для остальных зимовочных станций. Про сезонные станции я вообще ничего не знаю в этом плане.

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

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

Тут я рассмотрел вопросы про ТК для windows-сетей, т.к. с ними я возился много больше. Частично советы касаются и linux-терминалов, но там, вероятнее всего, есть своя специфика.

Вопросы, которые вы должны для себя прояснить до покупки:
1) Порядок, сколько вам их нужно <20, 20-50, 50-100, 100+
2) Вы готовы к тонким клиентам со стороны сервера? Прощай сканеры, прощай банк-клиенты, прощай дешёвые host-based принтеры (включая струйный принтер у дизайнера), прощай PERSW у бухгалтеров.
3) Будут ли ТК за пределами достижимости специалистов? (филиалы, малые подразделения).

Если вы не готовы к ТК (п2), думайте дальше мимо этого текста. Разумеется, существуют гибридные решения (когда часть сотрудников на ТК, а часть на рабочих станциях полностью или совмещая работу с отдельными терминальными соединениями).

Перед покупкой вы должны полностью представлять себе, кто будет работать на ТК, кто не на ТК. Лучше всего перед этим сделать пару «самодельных» ТК (грубо говоря, винды с mstsc) и посмотреть на процесс работы их на разных рабочих местах. [на этом этапе я полагаю, что вопросы функционирования терминальных серверов вы решили, потому что это существенно более серьёзная работа].

Статья рассказывает об организации отказоустойчивого файлового сервера на базе пакета Samba. Для понимая материала нужно иметь общее представление об администрировании ОС Linux, а также иметь опыт работы с обычной версией Samba.



Samba – это сервис CIFS, разработанный для того чтобы обеспечить семантику протокола CIFS (и соответственно доступ с машин под управлением Windows) к среде, использующей POSIX файловую систему. Основная функция Samba – преобразовать богатую семантику, которую используют клиенты на базе Windows к значительно более бедной семантике файловой системы POSIX.

Доброго времени суток, уважаемые пользователи Хабра!

Случилось так, что появилась необходимость добавить оперативки в старый добрый HP Proliant 150 G2. К слову, в нем уже были установлены 2 модуля по 1ГБ памяти. Я был наслышан о проблемах с совместимостью «родных» и «неродных» модулей, однако проблему нужно было решать и ждать поставки было невозможно.

Уже давным давно по интернетам ходят ссылки на мифические тонкие клиенты по 50-60-70 баксов. Мол, если есть такие, зачем по $200-$500? Более того, несколько компаний у нас в стране их пытаются продавать, и даже двигают на рынок с привлечением тяжёлой артиллерии в форме презентаций, бесплатных фуршетов и роадшоу.

Итак, сначала рыночно-историческая часть, а потом подробно техническая.

История

Была фирма, ncomputing. И изобрела она свой путь изготовления терминальных решений. Подчёркиваю, решений, а не тонких клиентов. Про него подробнее во второй части. Это изобретение было не такое уж дешёвое — под $150. Состояло оно из железа и софта. Софт шёл «как бы бесплатно» (точнее, с железками шла лицензия для них в софт). Но ушлые китайцы… произвели творческое осмысление и сделали своё. Главное, что своего сервера они не написали, а вместо этого банальным образом хакнули старую версию софта. То, что продаётся по $50-70 — это оно. Без техсаппорта, без обновлений (а они ой как там нужны), с ломанной версией критически важной для работы программы. Другими словами, типичные музыкальные центры panafonic и sonny, спортивная одежда от pyma и riibook. Та самая «китайская подделка», от имиджа которой стремятся уйти китайцы.

Впрочем, куда интереснее посмотреть на сам ncomputing, потому что это действительно НЕ RDP, это НЕ цитрикс, и у них ВСЁ своё.

Техническая часть

Понадобилось реализовать управление выдачей IP в сети одного провайдера, увязав его с системой учёта и прочими «фишками». В качестве DHCP сервера стоял ISC DHCP 4.x на 9-м Ubuntu Server'е.

Для DHCPd нужно было реализовать:

1. добавление новой статичной резервации (по маку либо порту свитча — опция 82),
2. «привязка» юзера с IP выданным динамически (то есть из пула свободных IP) в статичную резервацию
3. удаление статичной резервации
4. удаление динамической лизы до истечения срока резервации
5. Различные отчёты по подсетям, мак-адресам, свободным и занятым аресам

Хочу поделиться информацией, собранной в процессе реализации, на какие подводные камни наткнулся, как обходил, что так и не обошёл. Возможно кому-то сэкономит несколько часов времени.

 

Чуть раньше я писал про тонкие клиенты. Мол, зачем они нужны, кому они нужны и какой с них прок.

А теперь немного грустной правды о том, что есть тонкий клиент на самом деле.

Сколько бы не завывали маркетологи про особые свойства ТК, это просто компьютер. Зачастую с обычным биосом, в котором вы можете взять и загрузить свою ОС. В особо запущенных случаях вам придётся к этой ОС собрать особое ядро или играться с параметрами ядра, но обычно — это просто компьютер. В формате mini-itx или меньше. Без вентиляторов. Такие компьютеры до выхода Атома были экзотикой, с момента появления Атома — практически «компьютер как компьютер», только меньше.

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