Systemd – менеджер системы и сервисов в операционной системе Linux. При разработке eго стремились спроектировать обратно совместимым со скриптами инициализации SysV init и предоставить полезные функции, такие, как параллельный запуск системных сервисов во время загрузки, активацию демонов по требованию, поддержку снепшотов состояния системы и логику управления сервисами, основанную на зависимостях. В CentOS 7 systemd заменяет Upstart как систему инициализации по умолчанию.

В этой статье мы рассмотрим процесс управления сервисами в systemd для пользователя CentOS 7. Эти знания будут полезны и в других дистрибутивах, ведь systemd уже давно используется в Fedora и планируется в Ubuntu 14.10 и Debian 8. Хорошо это или нет — оставим за кадром.



В процессе чтения статьи вы можете попробовать systemd на классических VPS и облачных VPS от Infobox. Мы стремимся своевременно добавлять поддержку современных ОС, чтобы вы могли использовать последние технологии для более эффективной работы. Сама идея написания статьи родилась после очередного вопроса пользователей об использовании сервисов в CentOS 7.

Введение

Все началось с того, что я стал системным администратором у одного провинциального Интернет-провайдера. Помимо администрирования различного рода ресурсов, мне в присмотр достался один молодой, но бурно развивающийся ресурс. Ресурс представлял из себя классический LAMP проект. Сайт, на котором генераторами контента являлись обычные пользователи.
* К слову, в то время я ничего не понимал в *nix системах, хоть и все сервера которые мне достались, были именно на нем, разбирался я во всем этом достаточно быстро.

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

OpenVZ — это OpenSource-реализация технологии контейнерной виртуализации для ядра Linux, которая позволяет запускать на одной системе с ядром OpenVZ множество виртуальных окружений с различными дистрибутивами Linux внутри. За счет своих особенностей (контейнерная виртуализация идет на уровне ядра, а не железа) по ряду показателей производительности – плотности, эластичности, требованиям к размеру оперативной памяти, скорости отклика и т.д. – она работает лучше, чем другие технологии виртуализации. Например, тут можно посмотреть сравнения производительности OpenVZ с традиционными системами гипервизорной виртуализации. Но, помимо этого, в Linux и OpenVZ есть и масса вариантов тонкой настройки.
В данной статье мы рассмотрим нетривиальные варианты настроек контейнеров ядра OpenVZ, которые позволяют улучшить производительность всей системы OpenVZ.

HP и Intel объявили о сотрудничестве в программе стимулирования, по которой HP предоставляет бесплатно лицензии на использование хранилища HP StoreVirtual Virtual Storage Appliance (VSA) объёмом в 1 терабайт всем покупателям серверов на базе процессоров Xeon E5 v3 Intel.

Для популяризации программного обеспечения HP планирует распространить терабайтные лицензии на емкости суммарным объёмом более чем 72 петабайт. Это даст возможность пользователям оценить данное ПО, и, учитывая масштабы акции, есть основания полагать, что хранилище было проработано на совесть.

Однажды мне понадобилось в Zabbix сделать мониторинг потери пакетов между мастером и репликами (репликация плохо себя чувствует если канал не очень хороший). Для этого, в Zabbix есть встроенный параметр icmppingloss, на удаленный хост отправляется серия ICMP пакетов и результат фиксируется в системе мониторинга. И вот параметр добавлен, триггер настроен. Казалось бы задача выполнена, однако как говорится «Доверяй, но проверяй». Осталось проверить что триггер сработает когда потери действительно будут. Итак, как сэмулировать потерю пакетов? Об этом, да и не только, пойдет речь под катом.

Когда у нас появились сотрудники, работающие удаленно, пришлось думать над тем, как обеспечить им защищенный доступ к нашим хостинговым серверам, виртуальным выделенным серверам разработчиков Virtual Dedicated Server (VDS), сайтам обеспечения и сопровождения разработки и к другим ресурсам.

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

Выход нашелся довольно быстро — это использование технологии виртуальных частных сетей Virtual Private Network (VPN) и ее свободной реализации OpenVPN. Эта реализация доступна практически для всех распространенных платформ, в том числе для планшетов и смартфонов. История развития OpenVPN насчитывает уже 12 лет (компания OpenVPN Technologies, Inc. была создана Francis Dinha и James Yona в 2002 году), так что это надежное и проверенное временем решение.

В нашей компании сеть VPN позволила предоставить защищенный доступ сотрудников к VDS, играющей роль сервера OpenVPN. И уже для фиксированного IP этого сервера был разрешен доступ к другим ресурсам компании. Попутно на сервере OpenVPN был установлен прокси Squid, что решило все проблемы доступа сотрудников с динамическими IP к защищенным ресурсам компании.

Теме OpenVPN посвящены многочисленные статьи и сообщения на форумах. Тем не менее, нужную информацию мне пришлось собирать по частям из разных мест. Попутно приходилось разбираться с многочисленными терминами и технологиями. В качестве серверов OpenVPN были использованы VDS на базе FreeBSD и Debian Linux, в качестве клиентов — рабочие станции FreeBSD, Debian Linux, Ubuntu и Microsoft Windows.

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

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

В новой версии присутствует ранее продемонстрированная атака на Active Directory (Ldap Relay), функция Java Injection, эксплоит для уязвимости HeartBleed, Plugin Detector, но заострить внимание я хотел бы на совсем других вещах.

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

Итак, приблизительно с полгода назад, встала задача автоматизировать управление списком баз 1С (коих развелось уже более 20 штук) у пользователей домена.
Делалось это не только удобства ради, но и в рамках проекта по внедрению «ролевой модели доступа». Вкратце, смысл этой модели в том, что каждый пользователь в домене является членом определенной группы (именуемой согласно должности), которая имеет заранее определенный набор привилегий, в том числе и список информационных баз.

Т.к. у нас имеется домен Active Directory, логично использовать групповые политики для выполнения нашей задачи.
Гугление выдавало достаточно много реализаций (и даже платных), но все они, чаще всего, сводились к заранее сформированным файлам со списками баз (ibases.v8i). Нам же хотелось:
a) Централизованно управлять настройками подключения к информационным базам (у нас клиент-серверный вариант с SQL базами).
б) Централизованно управлять списком, доступных пользователю, информационных баз, согласно его «роли».

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

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

Apache 2.2 + PHP 5.4.4 + MySQL 5.5 + NGINX 1.2.1 + eAccelerator + memcached + vsftpd 3.0.2 + exim.

Все это чудо будет крутиться на Debian 7.

Начнем.

Для небольших компаний нередко применение всего двух-четырех серверов с виртуализацией, два Ethernet свитча порой даже с возможностью стекирования и Multi-chassis EtherChannel плюс СХД младшей серии — это вполне стандартная конфигурация инфраструктуры среднего бизнеса.
Таким предприятиям очень важно максимально задействовать все доступные технологии, чтобы максимально утилизировать своё оборудование и в этой статье пойдёт речь как этого добиться.

В большинстве современных серверов на борту как правило присутствует минимум два 1Gb интерфейса под данные и один 100Mb для менеджмента.

На СХД младшей серии NetApp FAS2240/FAS2220 на борту каждого контроллера помимо прочего присутствует 4х 1Gb порта.
Т.е. вполне логично использовать схему, где два свича в стеке используют Multi-chassis EtherChannel агрегируя линки идущие от каждого контроллера в каждый свитч для получения как отказоустойчивости так и утилизации пропускной способности всех этих линков. Такая-себе архитектура по образу и подобию FlexPod Express, но без модно-дорогой фичи vPC как у свитчей компании Cisco серии Nexus, в таком случае вместо интерлинков просто будет использован стек свичей. Да и вообще сервера и свитчи в такой схеме могут быть любого производителя. А если совсем всё туго с бюджетом, то можно использовать прямое включение в сервера, так если у сервера 2 порта на борту, можно будет подключить 4-ре сервера, а когда нужно будет добавить 5-й сервер, тут уж прийдётся покупать свитчи.


Схема подключения FlexPod Express.

Эти приемы были описаны во внутреннем проекте компании Google «Testing on the Toilet» (Тестируем в туалете — распространение листовок в туалетах, что бы напоминать разработчикам о тестах).
В данной статье они были пересмотрены и дополнены.