Meet the systemd, or short introduction

April 10th, 2016 No comments

systemd – is initialization system for other demons to Linux, which came to replace the previously used /sbin/init. Its special feature is the intensive parallelization while start services at boot time, which can significantly speed up the launch of the operating system.
The name comes from the Unix suffix «d» to the demon (c) Wikipedia. In this article, we will speak only about CentOS, but of course, this will also be true for other systems.

A problem often encountered in systemd, when even with seemingly correct configuration, the service does not start. Looking through the logs, you can understand that mistakes are usually standard – for the example of httpd he can not listen to the port, or resolve ldap user. After many experiments, we found the optimal configuration scripts that run in servers correctly.
All startup scripts are in the directory /lib/systemd/system


The file is called httpd.service. The problem is that he did not work until until network subsystem will not loaded and resolving ldap users. For Apache start, and must be loaded before Apache. It is easy to understand, if you take a look on config file below:

Description = The Apache HTTP Server
After =
Documentation = man: httpd (8)
Documentation = man: apachectl (8)

Type = notify
EnvironmentFile = /etc/sysconfig/httpd
ExecStart = /usr/sbin/httpd $ OPTIONS -DFOREGROUND
ExecReload = /usr/sbin/ httpd $ OPTIONS -k graceful
ExecStop = /bin/kill -WINCH $ {MAINPID}
KillSignal = SIGCONT
PrivateTmp = true

WantedBy =

Configuring Apache additional instances in systemd

In order to configure Apache to work on multiple ports at once (additional instances or “profiles”), you need to do a little creative action.

Create Apache configs

Additional Apache will listen to another port, so we need an another config file, which will be described. For example, here is this one.

Include conf/Includes/ *. Conf
Include conf/hosting/ *. Conf
Include conf/vhosts/ *. Conf

CustomLog "/var/log/apache/access1.log" combined env =! Dontlog
ErrorLog "/var/log/apache/error1.log"

User apache
Group apache

PidFile /var/run/httpd/

You must specify a folder with our configs, by analogy with the standard the httpd.conf, be sure to rename the name of the log, enter the user/group of the web server and the pid-file. In fact nothing more is needed for configuration. Let’s call httpd1.conf file for port 8001, httpd2.conf for port 8002 and then more, by analogy, if you need more.

Edit files with parameters

To get started, copy a file from the folder / etc / sysconfig

# Cp httpd httpd1

If you need to do more profiles, copy as needed.
Next, edit the copied a file. Do not touch the default file. All that should be in it, it’s two lines:

OPTIONS = -f conf / httpd1.conf

More, in fact, do not need anything. As you guessed, conf / httpd1.conf is a workpiece Apache config, which we did in the preceding paragraph.

Make and run the service

So, go to the folder with start scripts systemd

# Cd /lib/systemd/system

Copy the current service and a file called names by analogy with configs and files from the sysconfig

# Cp httpd.service httpd1.service.

Edit the config file which we COPIED before, leaving intact a default one

# EnvironmentFile = /etc/sysconfig/httpd

Replace the created us

# EnvironmentFile = /etc/sysconfig/httpd1

Save, switch service on

# Systemctl enable httpd1

Run it

# Systemctl start httpd1.service

Or so – also fulfills

# Systemctl start httpd1

So, you have additional instance Apache.


nginx.service adjusted by analogy – the main thing that against official documentation in “After” was present Also, it is important (applies also, and apache) option – any occurred after loading it as a Web server files can take, for example, GlusterFS.

Description = The NGINX HTTP and reverse proxy server
After =

Type = forking
PIDFile = /run/
ExecStartPre = /usr/sbin/nginx -t
ExecStart = /usr/sbin/nginx
ExecReload = /bin/kill -s HUP $ MAINPID
ExecStop = /bin/kill -s QUIT $ MAINPID
PrivateTmp = true

WantedBy =


Similarly configs web server, you need to change in the default script

After =
After =


For easy management, systemd has a large number of commands. Know all of them is not necessarily, but here is a list of basic and necessary good to know.


In the case if you edited boot scripts and other components systemd, you can restart it by command:

systemctl daemon-reload

Generate a report on the boot systemd and put it in a file (by the way, it is very useful for understanding the operation of systemd)

systemd-analyze plot> /home/vtorov/boot.svg

Take a look what services are loaded in systemd, or enabled while system start

systemctl list-units --type service

As above, but more and shows the “Target”

systemctl list-units

Switching on and off, reload/restart the service, or other actions (see them below)

systemctl <action> <object>

That is, for example,

systemctl restart httpd

Where restart is an action, but httpd is an object. The list of actions below.



By the way, old chkconfig, redirecting their actions into systemd, but because it will soon be expelled from the CentOS, then to use it is not necessary to devote more time and systemd.

mmonit: monitoring / response system

November 6th, 2015 No comments

mmonit – server monitoring system, able to perform at an event specified in the config scripts. For example, restart the service \ daemon when it drops or stops working, send notifications, run the daemon with a certain parameter and more.


Installation is simple. For FreeBSD:

# cd /usr/ports/*/monit

Add to autostart:

# echo 'proftpd_enable="YES"' >> /etc/rc.conf

For CentOS:

# yum install monit -y

Add to autostart:

# chkconfig monit on

Next, we have to set monitoring objects. For each service has own configuration, because different services are monitored in different ways. This can be checked by .pid-file approach to the url or checking port availability, type telnet commands, and more.

Configs for different services

Main file that describes the monitoring objects – it monitrc_local. Let’s divide it into two parts content: first part – mandatory, which must be everywhere, including our settings. The second part – according to the description of the service that you want to monitor. The first part of the config:

set daemon 120 with start delay 5 # time, after monit starts checking
set logfile /var/log/monit.log # log file
set mailserver, localhost # your mail-server

set alert # your admin mail. monit will send you notofications

set httpd port 2812 and # protocol and monit's web-interface
use address srv21.domain.local # server's hostname (use own one)
signature disable
allow localhost # allow localhost 🙂
allow # allow acces from this subnetworks
allow @users # allow this @group
allow monit:monitadmin # allow user:password

Next, in this file below, you can find monitoring policies. For each servers they are different.

For Apache

We will see for Apache via .pid and page availability (url).
Config for this:

check process apache with pidfile /var/run/ # check .pid-файл
group www # monitoring group 
start program = "/usr/local/etc/rc.d/apache22 start" with timeout 50 seconds # command for start cervice
stop program = "/usr/local/etc/rc.d/apache22 stop" with timeout 50 seconds # command for stop service
if failed host port 8000 # if url will not available /monit/token on port 8000 then
protocol HTTP request "/monit/token" with timeout 30 seconds then restart # restart service after 30 seconds

For nginx

Monitoring for nginx almost the same like for Apache. Difference only in service port.

check process nginx with pidfile /var/run/ # check .pid-файл
group www # monitoring group
start program = "/usr/local/etc/rc.d/nginx start" # command for start service
stop program = "/usr/local/etc/rc.d/nginx stop" # command for stop service
if failed host port 80 # if url will not available /monit/token on port 8000 then
protocol HTTP request "/monit/token" with timeout 20 seconds then restart # restart service 30 second

For redis

redis monitored much more interesting than the web server: it comes to telnet on redis port, enters commands and expects definite answer. If the answer is yes, monit does not perform any action. If the answer is no, monit will restart redis. Here is config file:


check process redis.service match "redis-server" # looking for processes with name
group db # monitoring group
start program = "/usr/local/etc/rc.d/redis start" with timeout 50 seconds # command for start service
stop program = "/usr/local/etc/rc.d/redis stop" with timeout 50 seconds # command for stop service
if failed
port 6379 # port redis
send "SET MONIT-CHECK ok\r\n" # send message
expect "OK" # wait for answer
send "EXISTS MONIT-CHECK\r\n" # send message
expect ":1" # wait for answer
then restart # restart
if 5 restarts within 5 cycles then timeout # timeout after 5 restarts and 5 cycles

For Gearman

check process gearmand with pidfile /var/run/gearmand/
group gearmand
start program = "/usr/local/etc/rc.d/gearmand start"
stop program = "/usr/local/etc/rc.d/gearmand stop"
if failed host port 4730 then restart
if 5 restart within 5 cycles then timeout
Categories: IT-bullshit, System administration Tags:

Настройка репозитория FreeBSD poudriere

November 6th, 2015 No comments

Poudriere (фр. пороховая бочка) – удобное средство для полной автоматизации репозитория FreeBSD. Работает как с pkg_* так и с pkgng. Все пакеты poudriere собирает во временных клетках, что бы не навредить целевой системе. Работает только на мастер-серверах из-за использования jail. Из дополнительных возможностей – возможность поддерживать одновременно репозитории для разных версий и архитектур FreeBSD.


Устанавливается из портов. Особых замечаний нет, всё происходит по-умолчанию.

# cd /usr/ports/ports-mgmt/poudriere
# Make install clean


Директории pouriere. Их две, первая /usr/local/poudriere содержит данные (клетки, порты, откомпилированные пакеты) вторая – настройки и /usr/local/etc/poudriere.d. Далее настраиваем основной конфиг /usr/local/etc/poudriere.conf. Он хорошо закомментирован, однако лучше я напишу несколько пояснений.

NO_ZFS=yes # Не использовать ZFS - да, не использовать
FREEBSD_HOST= # Пакеты берём отсюда
RESOLV_CONF=/etc/resolv.conf # Файл resolv
BASEFS=/usr/local/poudriere # Папка с данными
USE_PORTLINT=no Использовать portlint или нет
USE_TMPFS=yes # Использовать tmpfs
DISTFILES_CACHE=/usr/ports/distfiles # Кеш дистфайлов
CHECK_CHANGED_OPTIONS=verbose # проверять изменены ли опции сборки пакетов (если да, то будет пересборка пакета при изменении опций)
CHECK_CHANGED_DEPS=yes # проверять изменялись ли зависимости пакета
PKG_REPO_SIGNING_KEY=/etc/ssl/keys/repo.key # Ключик. Можно и без него
PREPARE_PARALLEL_JOBS=4 # Число параллельных операций (сборок, билдеров)
NOLINUX=yes # Без Linux 

Алгоритм работы poudriere примерно такой: создаётся отдельное дерево портов, и клетка. Далее происходит сборка пакетов в соответствии с выбранным портом. Если порт не указан, то будет использоваться по-умолчанию.
Создаём дерево портов и клетку

Как сказано выше, пакеты собираются в клетках с указанием дерева портов. Имена клетки и портов обязательно должны совпадать, будьте внимательны при их создании! Если в будущем при сборке не указывать название дерева портов, то сборка будет происходить из стандартных портов poudriere. По этому, если они ещё не созданы, их будет необходимо создать.
Создание дерева портов

Ключ -c означает создать, -p имя порта

# poudriere ports -c -p FreeBSD-10.1

Создадим дерево портов по-умолчанию:

# poudriere ports -c -p default

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

Ключ -c означает создать, -j означает имя клетки, -v – версия FreeBSD, -a – архитектуру

# poudriere jail -c -j FreeBSD-10.1 -v 10.1-RELEASE -a amd64

Настройка собираемых пакетов

Poudriere позволяет делать сборку как всего дерева портов, так и по отдельности. Все порты нам пока не нужны (однако далее я всё-таки напишу как это сделать).
Что собирать

Соберём только то, что нам необходимо для работы. Для этого создадим файл

# touch /usr/local/etc/poudriere.d/pkglist.txt

И на каждой новой строчке вставим имена необходимых пакетов. Например, правильное содержание файла:


То есть, правильный формат файла – порт/имя_пакета . Никакие другие параметры вписывать нельзя.
Настройка опций компиляции

Само собой, опции компиляции по-умолчанию много кому не подойдёт. Для этого у Poudriere предусмотрена специальная утилита, которая позволяет задавать параметры сборки на каждый пакет. Сделать это необходимо один раз, после чего в папке /usr/local/etc/poudriere.d/ появится папка options, которая будет содержать параметры компиляции для каждого собираемого порта (будущего пакета). Если этого не делать, то компиляция может происходить каждый раз. Нам же нужно, что бы это происходило только тогда, когда обновился порт для определённого пакета.

Для того, что бы задать параметр сборки для отдельного пакета. При выполнении команды, описанной ниже, появится диалоговое псевдо-графическое окно, аналогичное make config. Для этого нужно выполнить:

# poudriere options -c lang/php56-extensions

Однако, мы имеем файл со списком пакетов, и задавать вручную на каждый пакет опции командой не совсем удобно. Для этого, укажем для poudriere options файл, и нам будет предложено ввести параметры сборки для каждого указанного в файле пакета. Параметр -c означает предлагать ввести параметры в любом случае, даже если они уже заданы.

# poudriere options -сf /usr/local/etc/poudriere.d/pkglist.txt

Обновление портов и сама сборка пакетов

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

Обновим порты. Параметр -p означает название дерева портов, -u – update

# poudriere ports -p FreeBSD-10.1 -u

Начнём сборку пакетов. Опция -f означает, что мы будем собирать пакеты, указанные в нашем файле, который мы подготовили в предыдущих шагах. Параметр -p означает имя дерева портов, -j имя джейла. Имена клетки и портов обязательно должны совпадать, будьте внимательны при их создании!

poudriere bulk -f /usr/local/etc/poudriere.d/pkglist.txt -p FreeBSD-10.1 -j FreeBSD-10.1

После выполнения этой команды начнётся сборка. За её прогрессом можно наблюдать из консоли, вывод достаточно информативен. Если не хватает информации, и хочется больше – можно нажать сочетание клавиш Ctrl+t. После отработки команды, poudriere выдаст небольшой отчёт о количестве собранных пакетов, о пакетах с ошибками, если они есть и прочую необходимую информацию.

Когда сборка закончится, все пакеты будут доступны в папках /usr/local/poudriere/data/packages/{имя клетки которая была создана для сборки в poudriere }. Папка будет в точности повторять структуру официального репозитория FreeBSD, и включать необходимые для клиентов файлы – meta.txz, packagesite.txz и другие. Эти файлы будут генерироваться при каждой сборке. Для обновления клиентов вполне достаточно сделать эту папку видимой из веб сервера, настроив autoindex в Apache или nginx. При использовании опции -f <file> пакеты будут собираться при условии, если они не были до этого собраны, или если обновилось соответствующая ветка порта. Можно использовать параметр -c который будет собирать пакеты в любом случае, однако по непонятной причине очень часто после использования опции -c при сборке, в следующий раз будет пересобираться весь список пакетов. По этому пользоваться опцией я рекомендую с осторожностью.
Настройка веб-интерфейса

Poudriere по умолчанию содержит удобный и функциональный веб-интерфейс, который будет удобно для контроля сборки пакетов, просмотра статуса, и выгрузки ошибок. Для его настройки не нужно ничего качать, настраивать и конфигурировать – нужно просто настроить конфиг для веб-сервера. Не нужен даже php, система работает на html + динамической выгрузке данных из json. Работающий пример можно посмотреть тут:

Конфиг для nginx:

server {


# Point to the web-fronted
location / {
root /usr/local/share/poudriere/html/;
index index.html index.htm;

error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/local/www/nginx-dist;

# This location is used by the web-interface
location /data {
alias /usr/local/poudriere/data/logs/bulk;
autoindex on;

# Use this as the base URL to serve packages via http
location /packages {
root /usr/local/poudriere/data/;
index index.html;


Автоматизировать процесс

Поскольку все пакеты заранее сконфигурированы, то сборку можно автоматизировать, добавив задание в /etc/crontab на обновление и сборку портов:

0 0 * * * root /usr/local/bin/poudriere ports -p FreeBSD-10.1 -u
0 0 * * * root /usr/local/bin/poudriere bulk -f /usr/local/etc/poudriere.d/pkglist.txt -p FreeBSD-10.1 -j FreeBSD-10.1

Полезные команды и опции

Poudriere хоть и работает с jail, но jls тут бесполезен. Для просмотра имеющихся джейлов для сборки пакетов, можно ввести команду:

# poudriere jail -l

Аналогично для просмотра портов:

# poudriere ports -l

Как обновляться

Для настройки репозитория на конечной системе (пока только 10.1):


# ee /etc/pkg/FreeBSD.conf

FreeBSD: {
enabled: true,

После этого сделать:

# pkg upgrade

Или если не хочется отвечать на вопрос, можно сделать автоматически:

# env ASSUME_ALWAYS_YES=YES /usr/sbin/pkg bootstrap

Система полностью готова к работе с репозиторием, можно ставить и обновлять из него пакеты.

Categories: IT-bullshit, System administration Tags:

Setup policy cfengine policy hub

September 20th, 2015 No comments

CFEngine – configuration management system written in c ++ language and it is running on * BSD, Linux, Windows and others OS. This article describes how to install FreeBSD policies server on your server. Installing on Linux OS will be similar, but with the use of one or another package manager. All actions within cfengine similar like in FreeBSD, and on Linux too, with the exception of the location of files and classes os_name ::

Installing policy hub

СPolicy Server or in another policy hub – cfengine service, which is responsible for the distribution of rules, policies and changes. Simply put – the “main server” in this case.

So let’s install cfengine package from the FreeBSD ports:

# cd /usr/ports/sysutils/cfengine
# make install clean

Make rehash:

# rehash

Once installed, go to the directory cfengine. His working directory – always /var/cfengine. Use the command, for that would go into a folder, create a directory bin/ and copy the binaries:

# cd /var/cfengine && mkdir bin && cp /usr/local/sbin/cf-* bin/

cfengine server authenticates and authorizes itself by RSA keys, similar to the ssh, and works as usual, in a pair. To generate them, use a special command:

# cf-key

No need to do anything, the keys are generated and are in their home directory – / var / cfengine / ppkeys, files localhost.priv – the private key, and – is a public one.

After installing cfengine as a port and as a package, to work it is not ready yet. master files should be downloaded that contain “file promises” – the master file, which describes the links on the policy. Files can be taken with git-hub project, but due to frequent changes and updates FreeBSD Ports policy, these files may not work with the build of of cfengine, located in the ports. We take them from a special archive. Download the master files:

# fetch


# tar xzvf masterfiles-3.6.5.tar.gz

Remove archive:

# rm masterfiles-3.6.5.tar.gz

Now the server is ready to work, and all postinstall conditions was completed. To the server started to work as a policy hub, we have to run a command, for start synchronisation between masterfiles and input folder of the hub. The IP must be the same ip as your policy hub’ server. So we do it for server itself (important).

# cf-agent -B -s

In case of successful bootstrap, you will receive a log, where you can see what everything is ok. is in our case is IP of the server where we do it. The message will be something like this:

# notice: Bootstrap to '' completed successfully!

Just in case check how works cf-serverd:

# sockstat

You will see something like that:

root cf-serverd 14731 3 stream -> ??
root cf-serverd 14731 5 stream -> ??
root cf-serverd 14731 6 tcp4 6 *:5308 *:*
root cf-serverd 14731 7 dgram -> /var/run/logpriv

And on the other server (on client) check the port availability and nothing  not blocking the daemon:

# nc -v 5308
Connection to 5308 port [tcp/cfengine] succeeded!

This means that everything is is ok. Congratulations – you are beautiful. Make sure that all components are present cfengine to /etc/rc.conf:

# echo 'cf-serverd_enable="YES"' >> /etc/rc.conf
# echo 'cf_monitord_enable="YES"' >> /etc/rc.conf
# echo 'cf_execd_enable="YES"' >> /etc/rc.conf

The other components, such as cf-execd and cf-monitord run themselves, after the cf-serverd will started. Good luck. In the future, I will write about CFEngine more.

Categories: cfengine, System administration Tags:

Disable Selinux in Centos and RHEL

March 27th, 2015 No comments


So, probably, many of you faced with the fact that the installation of any software causes you need to disable selinux on CentOS. In fact, selinux is a very useful, flexible and secure. You should read the documentation and understand it. However, not everyone has enough time to read the selinux documentation. And i would advice you do not turn off it, but i think that you found this article in google only because of one goal: I NEED TURN OFF FUCKING SELINUX!!!
Ok then, i’ll say you how to do it…
So, for that would disable the selinux, you first need to go to the server via ssh (of course, you can go to the server and do all the following steps with the keyboard :))


All described in the following steps must be done as root user. Edit the necessary config:

# nano /etc/sysconfig/selinux

Then find in the string file called “SELINUX =” and replace them with the value to “disable”, instead of “permissive” available there. That’s it, i can congratulate you – we have disabled selinux on CentOS and RedHat.