Não é novidade que, nos últimos anos, alguns ajustes de ambiente e sistema vem sendo aplicados com intuito de otimizar a inicialização e gerência de serviços no Linux. Acredito que, o Ubuntu, de certa forma, deu o primeiro passo com o projeto Upstart. Em paralelo, engenheiros de software da Red Hat começaram a concentrar em outro framework, conhecido como Systemd. Não sei quem começou. Mas, algumas características de software e sistema sofreram alterações que levaram a dependência do systemd. Logo, a gerência de serviços das demais distribuições está migrando para este novo padrão.

Segundo a wikipedia, a partir de 2015, a maioria das distribuições têm adotado systemd como seu sistema de inicialização padrão. Sua crescente adoção tem sido controversa, com críticos argumentando que o software tenha violado a filosofia Unix, tornando-se cada vez mais complexo, e que as distribuições foram obrigadas a adotá-lo devido à dependência de vários outros softwares, como o GNome 3 (por exemplo).

Por este motivo, a partir do Ubuntu 15, o Upstart deixou de ser padrão – ainda está disponível no repositório principal. É um excelente projeto, mas, com a dependência e avanço do systemd, sua utilização tende cair em desuso. Confesso que, as vezes, isto irrita! (risos)

Segundo a documentação do Archlinux, “Systemd é um sistema e gerenciador de serviços para Linux, compatível com os scripts de inicializações SysV e LS. Systemd fornece recursos de paralelização agressivos, usa socket e ativação D-Bus para iniciar serviços, oferece o início de daemons on-demand, mantém o registro de processos usando grupos de controle Linux, suporte snapshotting e restauração do estado do sistema, preserva pontos de montagens e automontagens e implementa uma lógica de controle elaborado transacional baseada em dependência de serviço“.

Até pouco tempo, a gerência de serviços, no padrão Debian, costumava ser feita com rcconf ou update-rc.d. Conforme exposto, a tendência é que estes ajustes passem a ser feitos via systemctl.

Em uma instalação firewall, minha primeira conduta é verificar quais serviços estão ativos e desabilitar o que não for necessário ou indispensável para o funcionamento do sistema.

root@firewall:~# netstat -ntlup
Conexões Internet Ativas (somente servidores)
Proto Recv-Q Send-Q Endereço Local          Endereço Remoto         Estado       PID/Program name
tcp        0      0 0.0.0.0:8443            0.0.0.0:*               OUÇA       15862/webauth.mod [
tcp        0      0 0.0.0.0:3322            0.0.0.0:*               OUÇA       1230/sshd       
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               OUÇA       18282/(squid-1) 
tcp        0      0 0.0.0.0:80              0.0.0.0:*               OUÇA       10855/apache2   
tcp        0      0 0.0.0.0:81              0.0.0.0:*               OUÇA       15861/webauth.mod [
tcp        0      0 10.0.0.1:53             0.0.0.0:*               OUÇA       1586/named      
tcp        0      0 127.0.0.1:53            0.0.0.0:*               OUÇA       1586/named      
tcp        0      0 0.0.0.0:3128            0.0.0.0:*               OUÇA       18282/(squid-1) 
tcp        0      0 127.0.0.1:953           0.0.0.0:*               OUÇA       1586/named      
udp        0      0 10.0.0.1:53             0.0.0.0:*                           1586/named      
udp        0      0 127.0.0.1:53            0.0.0.0:*                           1586/named      
udp        0      0 0.0.0.0:53065           0.0.0.0:*                           18282/(squid-1)

No caso da resolução de nomes, tenho feito dois ajustes: Desfaço o link simbólico do arquivo /etc/resolv.conf e desabilito o serviço resolvconf:

# 1. Desfazendo o link simbólico
cp /etc/resolv.conf /tmp/
rm /etc/resolv.conf
mv /tmp/resolv.conf /etc/

# 2. Desabilitando o serviço resolvconf
systemctl disable resolvconf.service

Existe um mito de que o Ubuntu mudou drasticamente a resolução de nomes do sistema, impedindo o controle direto sobre o arquivo resolv.conf. Na prática, o sistema continua trabalhando sob o padrão estabelecido pela glibc. A diferença é que, no Ubuntu, o arquivo resolv.conf é um link simbólico para “../run/resolvconf/resolv.conf“, que é controlado por um framework próprio (network-manager). É uma forma de garantir que o resolv.conf seguirá as definições em /etc/network/interface. Quebrando o link simbólico, o controle sobre o arquivo volta a ser manual.

Em relação aos serviços… para saber quais serviços estão ativos:

systemctl list-unit-files | grep ".service" | more

Como adoto uma solução de firewall própria (FwGuardian), costumo remover a instalação do ufw (purge para remoção dos scripts internos). Também removo o controle de acesso mandatório AppArmor porque defino o acesso ao firewall extremamente restritivo, tanto por regras de INPUT quanto por limites de acesso PAM.

dpkg --purge ufw
dpkg --purge apparmor

ou

apt-get purge ufw
apt-get purge appamor

Para efeito de curiosidade, o controle de inicialização (runlevels) também é feito via systemctl.

- Como o mapeamento é feito
┌──────────┬───────────────────┐
│ Runlevel │ Target            │
├──────────┼───────────────────┤
│ 0        │ poweroff.target   │
├──────────┼───────────────────┤
│ 1        │ rescue.target     │
├──────────┼───────────────────┤
│ 2, 3, 4  │ multi-user.target │
├──────────┼───────────────────┤
│ 5        │ graphical.target  │
├──────────┼───────────────────┤
│ 6        │ reboot.target     │
└──────────┴───────────────────┘
# 1. Consultando o nível padrão
systemctl get-default

# 2. Definindo multi-user.target (runlevel 2,3,4)
systemctl enable multi-user.target
systemctl set-default multi-user.target