Systemd scripts on boot CentOS 7

Systemd

O Systemd é responsável por gerenciar sistemas e serviços de alguns OS Linux. Foi desenvolvido para ser compatível com os scripts init do SysV e disponibiliza vários recursos, como a iniciar serviços em paralelo ao linux no momento do boot, a ativação por demanda de daemons ou a lógica de controle de serviço baseada em dependência. Um exemplo no CentOS 7 assim como em sistemas baseados em Red Hat , o systemd substitui o Upstart como o sistema init padrão.

O conceito de unidades systemd, são representadas por arquivos de configuração de unidade localizados em um dos diretórios listados na tabela abaixo,“Localizações de arquivos da unidade Systemd” e disponibilizam informações sobre serviços do sistema e outros objetos que são importantes para o sistema init, este será mencionado a seguir. Para ter acesso a mais informações sobre a lista completa dos tipos de unidade systemd disponíveis, confira na lista a seguir,“Tipos de unidade systemd disponíveis”.

Tipos de unidade systemd disponíveis
Tipo de Unidade	Extensão de Arquivo	Descrição
Unidade de serviço	.service	Um serviço do sistema.
Unidade alvo	.target	Um grupo de unidades systemd.
Unidade de montagem automática	.automount	Um ponto de montagem automática do sistema de arquivos.
Unidade do dispositivo	.device	Um arquivo de dispositivo reconhecido pelo kernel.
Unidade de montagem	.mount	Um ponto de montagem do sistema de arquivos.
Unidade de caminho	.path	Um arquivo ou diretório em um sistema de arquivos.
Unidade de escopo	.scope	Um processo criado externamente.
Unidade de fatia	.slice	Um grupo de unidades organizadas hierarquicamente que gerenciam processos do sistema.
Unidade de instantâneo	.snapshot	Um estado salvo do gerenciador do systemd.
Tomada de unidade	.socket	Um soquete de comunicação entre processos.
Unidade de swap	.swap	Um dispositivo de troca ou um arquivo de troca.
Unidade de temporizador	.timer	Um temporizador systemd.

Localizações dos arquivos da unidade Systemd
Diretório	Descrição
/usr//lib/systemd/system/	Arquivos unitários do Systemd distribuídos com pacotes RPM instalados.
/run/systemd/system/	Arquivos unitários do Systemd criados no tempo de execução. Esse diretório tem precedência sobre o diretório com arquivos da unidade de serviço instalados.
/etc/systemd/system/	Arquivos unitários do Systemd criados por systemctl enable arquivos de unidade adicionados para estender um serviço. Esse diretório tem precedência sobre o diretório com arquivos de unidade de tempo de execução.

Agora que foi feita uma breve abordagem do Systemd, será descrito a seguir um pouco do antecessor, init.

No sistema operacional Linux, init é a forma simplificada de Initialization. O init é um processo daemon que inicia no boot do servidor e continua em execução até que ele seja encerrado. O init é o primeiro processo que começa quando seu servidor inicializa, tornando-o o pai de todos os outros processos em execução direta ou indiretamente e normalmente é atribuído e identificado nos processos como "pid=1".

Se ocorrer algum erro e o daemon init não puder iniciar, nenhum dos demais processos serão inicializados e o sistema no boot irá apresentar falhas normalmente identificada como “Kernel Panic”. init é geralmente referido como Sistema de V (abreviado, SysV ou System Five) de inicialização. O System V é o primeiro sistema operacional UNIX comercial projetado e o uso do init na maior parte do Linux Distribution de hoje é idêntico ao System V OS com algumas exceções, como o Slackware usando estilo BSD e o Gentoo usando init customizado.

A demanda para substituição do init por algo melhor foi identificada no momento que foram desenvolvidas, algumas das substituições do init nativa da distro, segue algumas:

Upstart - Um daemon de substituição de init implementado no Ubuntu GNU / Linux e projetado para iniciar o processo de forma assíncrona.

Epoch - Um daemon de substituição de init criado em torno da simplicidade e do gerenciamento de serviços, projetado para iniciar o processo de thread único.

Mudar - Um daemon de substituição de init escrito em Python, implementado no Pardus GNU / Linux e projetado para iniciar o processo de forma assíncrona.

systemd - Um daemon de substituição de init projetado para iniciar o processo em paralelo, implementado em um número de distribuição padrão - Fedora, OpenSuSE, Arch, RHEL, CentOS, etc.

Analisando essas mudanças e observando que surgem algumas dúvidas no caso do CentOS 7, o habito de fazer uso do rc.local para inicialização de scripts customizados no boot do servidor, etc.

A seguir será apresentado duas formas de trabalhar com essas mudanças, a inicio será criado no systemd para no boot iniciar o seu script, no caso do laboratório será usado um script bash como exemplo, em segundo ambiente de estudo, será descrito como ativar no systemd para que carregue o rc.local do Linux.

Laboratório:

• Virtualbox v5.2.26
• OS - CentOS Linux Release 7.5.1804(Core)
• Memoria 1024 MB
• Disco 40GB

Este será criado no systemd para iniciar um script básico de firewall como um serviço comum do servidor.

Vá até o diretorio abaixo:

[root@labfreepbx ~]# cd /etc/rc.d/

Crie o seguinte arquivo:

[root@labfreepbx ~]# vim firewall.sh

Com o conteúdo:

#!/bin/bash
# Autor: Profº Kowalski
# Comunidade FreePBX Brasil

# Variaveis
LAN="enp0s3"
REDE_INTERNA="172.16.100.0/24"

# Limpa regras
iptables -t filter -F
iptables -t nat -F

# Policy default
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT

# Liberar interface lo e rede interna
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A INPUT -s $REDE_INTERNA -i $LAN -m comment --comment "REDE LOCAL" -j ACCEPT

Observações:
As variáveis “$LAN” e “$REDE_INTERNA” devem ser alteradas para as que atendam o seu ambiente de estudo, lembrando que este é apenas um script de estudo usado para simular uma necessidade diária, se for fazer uso deste em produção recomendo que revise e adeque as suas necessidades.

Após alimentar o script com as informações corretas do seu ambiente, salve e saia, se caso não souber no VIM usa-se ESC + :x! (Dois pontos, X minúsculo e exclamação), assim você salva e sai do arquivo forçando as alterações.

Agora será necessário a permissão de execução do script.

[root@labfreepbx ~]# chmod +x firewall.sh

Pronto, script criado, se for caso para não ter surpresas execute o mesmo somente para efeito de teste, e a seguir será criado o arquivo que o systemd inicie seu script no boot.

No caminho:

[root@labfreepbx ~]# cd /etc/systemd/system/

Crie o seguinte arquivo:

[root@labfreepbx ~]# vim firewall.service

Adicione o seguinte conteúdo abaixo:

[Unit]
After=network.target
[Service]
ExecStart=/etc/rc.d/firewall.sh
[Install]
WantedBy=default.target

Onde “After=network.target” significa que ele inicializará após o serviço de rede, “ExecStart” defini o caminho do nosso arquivo bash e o “WantedBy” em qual destino da inicialização ele será executado.

Após alimentar o arquivo, salve e saia, a seguir rode os comandos para recarregar o systemd e habilitar no boot a execução do seu serviço/script.

[root@labfreepbx ~]# systemctl daemon-reload

[root@labfreepbx ~]# systemctl enable firewall.service

Agora já pode reiniciar o seu servidor e veja se ao iniciar o mesmo executou o script como deve ser.

Até agora já abordamos como criar no systemd a inicialização dos seus serviços, correto! Mas Profº Kowalski se eu quiser utilizar o meu rc.local sem necessidade de criar para cada script um serviço no systemd, isso é possível? Sim, claro vamos lá! Você pode sim fazer desta forma, será descrito a seguir.

Desative seu atual serviço para não conflitar com as configurações a seguir ou se preferir pode remover.

Após alimentar o arquivo, salve e saia, a seguir rode os comandos para recarregar o systemd e habilitar no boot a execução do seu serviço/script.

[root@labfreepbx ~]# systemctl disable firewall.service

Assim seu script não será iniciado no boot.
Agora no caminho:

[root@labfreepbx ~]# /etc/rc.d/

Entre no arquivo rc.local existente dentro do diretorio acima.

[root@labfreepbx ~]# vim rc.local

Ao final do arquivo adicione o caminho do seu script:

sh /etc/rc.d/firewall.sh

Salve e saia.

Agora adicione a permissão de execução no arquivo rc.local:

[root@labfreepbx ~]# chmod +x rc.local

Agora no caminho:

[root@labfreepbx ~]# /etc/systemd/system/

Crie o seguinte arquivo:

[root@labfreepbx ~]# vim rc-local

Adicione o seguinte conteúdo:

[Unit]
Description=/etc/rc.d/rc.local Compatibility
ConditionFileIsExecutable=/etc/rc.d/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.d/rc.local start
TimeoutSec=0
RemainAfterExit=yes

Em seguinte salve e saia. Como no processo anterior será necessário dar um reload no systemd e habilitar no boot do server.

[root@labfreepbx ~]# systemctl daemon-reload

[root@labfreepbx ~]# systemctl enable rc-local.service

A seguir reinicie o seu servidor para validar seu procedimento, ao voltar rode o seguinte comando:

[root@labfreepbx ~]# systemctl status rc-local.service

Observe que o status deve está como “Active” sendo assim o systemd está executando o rc.local no boot corretamente.

Essa foi mais uma documentação para comunidade, não deixe de acompanhar as nossas mídias sociais, um forte abraço e até a próxima.

     

Fontes:
https://access.redhat.com/(Systemd)
https://access.redhat.com/(SysV)