Сегодня я хотел бы познакомить читателя с Windows Server Core 2008 R2.

Как показывают мои личные наблюдения, многие администраторы его боятся. Причина проста: в головах прочно засело Windows=GUI, а вот GUI-то в нем как раз и нет. Как следствие все воспринимают Server Core как «не такой» Windows. Он действительно не такой, но ничего страшного в нем нет. Более того, в нем есть свои плюсы и прелести. Из очевидных — экономия ресурсов. Из не очевидных — отсутствие возможности тыкать во все места дисциплинирует и заставляет разбираться в том что хочешь сделать.

Меньшая требовательность к ресурсам позволяет эффективнее распределять оные при виртуализации серверов.
Поясню:
Есть, положим, сервер (не важно физический или виртуальный). На нем Windows Server 2008R2, AD (не основной контроллер), WSUS. Чтобы это хоть как-то ворочалось минимум нужно 2GB памяти. Вместо него можно сделать две виртуалки с Server Core, на одной AD, на второй WSUS. При этом обе эти виртуалки будут жить с полугигом памяти и прекрасно себя чувствовать. При этом лишаемся мы только GUI, которым я, например, и так не пользуюсь практически, по крайней мере с консоли сервера.

Summary: Пост рассказывает о том, что такое снапшоты в облаке, как их использовать, и как они устроены.

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

Хочу предупредить, что статья будет очень сложная. Я сначала расскажу про простые вещи — как с этим работать и какая от этого польза, а потом расскажу как это устроено внутри. И если с удобством и понятностью на «пользовательском» уровне мы, я надеюсь, справились, то вот с описанием устройства… Так сказать, мужайтесь или пропускайте.

Как использовать снапшоты?

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

Снапшот может быть выполнен в любой момент времени, на включенной или выключенной машине. В момент выполнения снапшотов дисковая активность машины слегка приостанавливается (речь идёт о чём-то порядка секунды), после чего продолжается «как ни в чём ни бывало».

В этой короткой статье я опишу процесс настройки функций для переключения маршрутов между двумя провайдерами в случае, если физический линк присутствует и даже есть наличие локальной сети провайдера, но нет самого интернета.
Рассмотрим пример с 2 провайдерами:

• ISP1
  interface IP 1.1.1.100
  gateway IP 1.1.1.1
  netmask 255.255.255.0
  interface name ge-0/0/2.0
• ISP2
  interface IP 2.2.2.200
  gateway IP 2.2.2.1
  netmask 255.255.255.0
  interface name ge-0/0/2.0

Конфигурирование будет состоять из двух этапов:

1. Настройка rpm — который проверяет доступность выбранных хостов
2. Настройка ip-monitoring — который непосредственно выполняет переключения рутинга

Этап 1

Как правило выбираются хосты изначально постоянно доступные для icmp-ping в моем примере. Для примера, а не для подражания возьмем для мониторинга IP крупных провайдеров: 213.180.193.3, 209.85.148.104. Я беру 2 IP для мониторинга так как по одному возможны ложные срабатывания. В реальной обстановке можно мониторить и сеть провайдера и хопы после его граничных маршрутизаторов.
Заходим в режим редактирования конфигурации из командной строки.

Учитывая, что в операционной системе Junos используется довольно стандартный демон ssh, я осмелился предположить, что организация ssh туннелей в нём реализована. И хотя в документации о таком применении коммутаторов, маршрутизаторов или межсетевых экранов не удалось найти упоминания — это работает. Мало того, ssh туннели разрешены по умолчанию.

Приведу пример, позволяющий продемонстрировать, где это может пригодиться.

В статье я расскажу о том, как мы (небольшой региональный провайдер) настраиваем коммутаторы уровня доступа.

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

Доброе время суток, хабраграждане!

Спешу с Вами поделиться одной из своих вещиц, которые были призваны облегчить работу мне, как системного администратора, который разбирается в, доставшимся ему по наследству, хламе в Active Directory.
Самые проблемные из доставшегося добра, по моему мнению, это группы. О них и пойдет речь в данной статье.
А именно: заходим в Active Directory, бороздим просторы подразделений и видим группы, совершенно с безликими названиями (например Ugin, Vassa, Opel, www etc) и без описания. Внимание вопрос: определите для чего нужны эти группы.

Чем дальше развиваются технологии виртуализации, тем больше разнообразных «грандов ИТ технологий» выходит на рынок. Несмотря на то, что проект Xen как таковой довольно давно существует в виде open source решения, такая операционная система с интегрированным гипервизором как Citrix XenServer относительно недавно привлекла внимание клиентов Enterprise уровня. Изначально ОС была ориентирована на low/mid-end предприятия и предназначалась для решения проблем минимизации затрат на мультисерверную архитектуру. Но в процессе развития, компания Citrix интегрировала в свой гипервизор такие жизненно важные вещи как High Availability и Likewise интеграцию c Active Directory. Таким образом, на данный момент существуют коммерческие версии Citrix XenServer позиционирующиеся как реальная альтернатива VMWare ESX/ESXi. Но, как известно, к гипервизорам предъявляются особые требования безопасности. Это обусловлено тем, что при захвате гипервизора наиболее вероятно, что компания потеряет не только его, но и все виртуальные машины.

Продолжаю тему создания нетривиальных bat-файлов для тривиальных задач, начатую здесь.

Наверняка многие сталкивались с задачей, когда для каких-либо целей в ОС Windows необходимо создать задание, выполняемое по расписанию (scheduled task).
Для этих целей имеется простой графический интерфейс. Однако как поступить, если задание должно создаваться автоматически?
Попробуем решить эту задачу с использованием примитивного bat-скрипта, который будет выполняться в практически любой версии Windows.

Регулярно читаю отчеты различных ИТ-изданий о росте рынка ЦОД в России, нехватке площадей и грандиозных перспективах отрасли. Не хочется категоричных заявлений, но, ИМХО, вышесказанное актуально, в первую очередь, для монстров индустрии. Кроме того, в отечественной блогосфере превалируют мнения об отсталости и дороговизне коммерческих центров обработки данных в России. Малый и средний бизнес не доверяет российским дата-центрам по ряду причин, многие из которых сильно преувеличены. Предлагаю посмотреть на ситуацию с объективной точки зрения и развенчать, или, наоборот, утвердить некоторые мифы о ДЦ.

Дефицитность

Недавно в руки попал какой-то журнальчик из тех, что бесплатно разносят по офисам. Там, черным по белому, было написано, что найти дата-центр в России для размещения хотя бы 15 стоек – практически невозможно. Устраиваем эксперимент и отправляем запрос по нескольким вариантам из выдачи Яндекса.

Вот наши счастливчики:

• «Оверсан »
• TEL Hosting
• E-Style Telecom
• Agava
• MSM

Проверяю конспиративный e-mail на следующее утро. Получил ответ от всех компаний, кроме E-Style Telecom. Зато «Оверсан», TEL Hosting, Agava и MSM с радостью готовы разместить мои «виртуальные» 15 шкафов. По-моему, выводы напрашиваются сами собой. Расценки у всех примерно на одном уровне, в районе 50 тысяч рублей за стойку.

Захотелось поделится с хабросообществом парой способов провести инвентаризацию техники быстро и без особых усилий. Сподвигла меня вот эта статья, но как сторонник UNIX-way я расскажу способы сделать всё то же самое и даже больше без необходимости окружать себя гомогенной сетью из одинаковых рабочих станций или привязки к одной технологии.

Что мы хотим?

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

Протокол RDP является протоколом прикладного уровня и поэтому для его защиты идеально подходит TLS, который работает над транспортным уровнем.

В данном топике с помощью open source приложений OpenSSL и sTunnel мы защитим RDP-соединения по протоколу TLS c поддержкой российских шифрсьютов (GOST2001-GOST89-GOST89), клиентская аутентификация по ГОСТ-вым сертификатам будет проводиться аппаратно на борту USB-токена Рутокен ЭЦП с выработкой ключа согласования по схеме VKO GOST 34-10.2001. При этом ключ аутентификации является неизвлекаемым и его невозможно украсть. Так же Рутокен ЭЦП будет использоваться в качестве аппаратного ДСЧ.

Для случая аутентификации на терминальном сервере об Active Directory по сертификатам RSA мы обернем TLS по RSA в TLS по ГОСТ. Таким образом, мы получим двухуровневый TLS — RSA с клиентской аутентификацией будет идти внутри канала, защищенного ГОСТами.

Описание “жизненного пути” от программного инструмента к аппаратному решению.

Прошлое

С 2008 года начал работать дома. Очень важный для работы с моими клиентами вопрос голосовой / телефонной связи решился установкой на ноутбук софтфона и подключения к рабочей IP АТС по SIP. “Аппаратно” это решалось самой простой проводной гарнитурой и дополнительным USB аудиоадаптером, т.к. используемые Macbook-и не имели микрофонного входа.

Нравились следующие особенности:

• “Свобода рук” — возможность полноценной работы на компьютере во время телефонного разговора. Актуально при консультации клиентов с необходимостью что-то писать в CRM или искать информацию в документации.
• Набор номера копированием из CRM или какого-либо текстового источника (сайта).
• Компактность, что важно при выездах из дома в офис.

Сегодня на рынке информационных технологий имеется большое количество различных решений, позволяющих пользователю работать с удаленным рабочим столом — терминальный доступ от Microsoft, XenApp от Citrix, Leostream, Quest Software и т. п., либо же решения с применением средств виртуализации — VMware View, XenDesktop и другие.

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

Мы разворачиваем множество различных продуктов на тестовой площадке DEPO Computers, и среди них было одно бесплатное решение по доставке рабочих столов, которое нам очень понравилось.

В процессе трудовой деятельности пришлось столкнуться с одной задачей. Есть некоторый продукт, работающий под Windows и состоящий из нескольких компонент — ядра, протокола, моста и канала доставки. Часть компонент написана на JAVA, часть на C++. Каналов доставки может быть от одного до двадцати. Каждый компонент использует свою БД (в качестве СУБД выступает MS SQL Server). Для компонент, написанных на JAVA, структура БД создается автоматически, для компонент, написанных на C++ структуру нужно создавать вручную SQL скриптом. Каждый компонент должен работать как сервис в системе. Все это добро должно быть тщательно протестировано. Для каждого теста необходимо пересоздавать БД и системные сервисы.

Проделав это дело один раз, я задумался, а как бы этот процесс можно было максимально автоматизировать (действия не сложные, но рутинные). Решение должно быть простым и не требующим установки какого-либо софта. Поэтому сразу же выбор пал на древний, но проверенный временем файл сценариев на встроенном командном языке — Bat. Заодно проверим, на что bat скрипты еще способны.

Эта статья нацелена на читателей, которые начинают или только хотят начать заниматься программированием модулей ядра Linux и сетевых приложений. А также может помочь разобраться с прозрачным проксированием HTTPS трафика.

Небольшое оглавление, чтобы Вы могли оценить, стоит ли читать дальше:

1. Как работает прокси сервер. Постановка задачи.
2. Клиент – серверное приложение с использованием неблокирующих сокетов.
3. Написание модуля ядра с использованием библиотеки Netfilter.
4. Взаимодействие с модулем ядра из пользовательского пространства (Netlink)

P.S. Для тех, кому только хочется посмотреть на прозрачный прокси-сервер для HTTP и HTTPS, достаточно настроить прозрачный прокси-сервер для HTTP, например, Squid с transparent портом 3128, и скачать архив с исходниками Shifter. Скомпилировать (make) и, после удачной компиляции, выполнить ./Start с правами root. При необходимости можно поправить настройки в shifter.h до компиляции.

Некоторое время назад в компании была развернута терминальная ферма.
Первым делом в неё были выселены пользователи некой желтой программы.
После чего отдел поддержки желтой программы спросил меня, можно ли отсылать сообщения пользователям фермы всем сразу. XaocCPS посоветовал мне играться в сторону WPF. Нужный скрипт был написан, но его работой я неудовлетворился:
1. Надо ставить внешний компонент PowerShellPack.
2. Компонент ставиться на сервера фермы (х64) отказался.
3. Распространять такое решение из за пункта 1 всем желающим не очень удобно.

Xaegr подсказал что я могу избавиться от прослойки WPF.
Писать можно, можно даже писать красиво. Скрипт выполняется везде где есть .Net Framework — XP, Win7 и скорее всего пойдет даже на х64 серверах фермы.
Как писать — под катом.

UPD по просьбам скрипт выложен на SkyDrive, ссылка в конце

Перевод небольшой заметки Джоэля Спольски (Joel Spolsky) "Let's Stop Talking About Backups". Джоэль — один из создателей stackoverflow.com и ведущий блога joelonsoftware.com.

Вы бэкапите данные со своей рабочей машины?

А с производственных серверов?

Вы храните бэкапы на том же диске, или переносите их на другую машину?

Переносите ли вы серверные бэкапы в другой дата-центр?

Всё это — стандартный набор вопросов для проверки квалификации системного администратора.

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

Ведь в этом случае выясняется, что:

После скучного рассказа о подключении к кошкам переходим к настройке сети. В этот раз темы будут для новичков сложные, для старичков избитые. Впрочем сетевым аксакалам едва ли удастся почерпнуть что-то новое из этого цикла. Итак, сегодня:
а) аккуратно впитываем теорию о коммутаторах, уровнях сетевой модели, понятии инкапсуляции и заголовков (не пугайтесь — еще не время),
б) собираем спланированную в нулевой части цикла сеть,
в) настраиваем VLAN'ы, разбираемся с access и trunk-портами и тегированными Ethernet-фреймами,
г) соотносим текущие знания со стеком протоколов TCP/IP и моделью OSI (да, наконец-то мы ее коснёмся).



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

Многим известны книги Томаса Лимончелли по системному администрированию, очень ценные для админа книжки. На его сайте тоже немало интересного, среди прочего нашёл такую статью: «A list of dumb things to check». На русском языке она, к сожалению, не нагуглилась, переводил сам. После допилинга под свои условия буду использовать как часть КМБ у себя в отделе, а первоначальный перевод выкладываю тут.

Задача

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

В статье для этой цели будут использованы Debian Linux, протокол CARP и утилита ucarp.