Obarun e S6
O S6 - Skarnet.org’s Small & Secure Supervision Software Suite inclui um init, um dos vários projectos que se rebelaram contra o SystemD afirmando que havia maneiras melhores e/ou mais simples de fazer a mesma coisa.
Apesar de a implementação oficial do S6 ter começado por ser no Alpine Linux, por alguma razão o autor agora colabora com o Adélie Linux, que já explorei antes.
No entanto, a expressão mais madura do S6-init encontra-se no Obarun, uma distribuição baseada em Arch e, tanto quanto sei, sem a colaboração do autor do S6, apesar de serem todos franceses. Isto porque o S6 ainda não definiu uma maneira de organizar as dependências entre os serviços (e sendo zelota do “Caminho do UNIX”, talvez nunca o venha a fazer), o que significa que alguém tem de fazê-lo; a contribuição do Obarun é um conjunto de scripts chamado 66
Por isso, para experimentar o S6 tive de instalar o Obarun; sendo baseado em Arch, temi o pior, mas comparado com o Adélie até foi relativamente simples.
Notas de instalação
- O locale PT-UTF8 causa erros de caracter na consola texto (configuração errada no
grub.cfg?)
Refiz a instalação no locale en_GB-UTF8 e funcionou. - Em modo minimal, o NAT do VirtualBox fornece o valore da opção nameserver (opção DHCP 5) que é escrita em
/etc/resolv.conf, mas em NATnetwork não, é necessário editar o/etc/resolv.confà mão. Bug do VirtualBox? A “NAT Network” ainda tem muitos bugs, e talvez um deles seja que as opções DHCP não são transmitidas, mas não cheguei a usar um packet sniffer para verificar…
S6/66 (v.6.3+)
O 66, como disse, é uma camada de gestão sobre o sistema S6, que se baseia na criação de um conjunto de árvores, que são criadas pelo utilizador e que são um meio-termo entre a ordem numérica/alfabética do SysV-init e o grafo dinamicamente actualizado do SystemD.
Exemplo: instalar SSHD
O serviço sshd instala-se com
|
|
66 fase 1: service script
O service script que controla o serviço openssh não é instalado automaticamente; tem de ser criado, ou obtido dos scripts que existem no repositório observice. Os service scripts existentes neste repo podem ser listados com
|
|
Para instalar o service script,
|
|
Para que o sistema saiba que o serviço foi adicionado,
|
|
Agora já podemos ver o conteúdo do service script com
|
|
Name : sshd
Version : 0.2.1
In tree :
Status :
Type : classic
Description : ssh daemon
Source : /usr/lib/66/service/sshd
Live : /run/66/scandir/0/sshd
Dependencies : sshd-log
External dependencies : None
Optional dependencies : None
Start script :
foreground { exec ssh-keygen -A }
execl-cmdline -s { /usr/sbin/sshd -f ${conf_file} ${cmd_args} }
Stop script : None
Environment source : /etc/66/conf/sshd/0.2.1
Environment file :
environment variables from: /etc/66/conf/sshd/0.2.1/.sshd
conf_file=!/etc/ssh/sshd_config
cmd_args=!-D
Log name : sshd-log
Log destination : /var/log/66/sshd
Log file : None
66 fase 2: configurar as dependências
No entanto, os serviços antes de serem iniciados têm de ser adicionados a uma tree, que codifica as dependências dos serviços.
Para ver e manipular as trees, usa-se o comando 66-intree (a partir da versão 0.6x do 66)
Acho muito útil a opção -g que mostra a estrutura de dependências dos serviços que se encontram configurados nas trees.
|
|
Name : boot
Initialized : yes
Enabled : no
Starts after : None
Current : no
Allowed : root
Symlinks : svc->source db->source
Contents : /
├─(144,Enabled,classic) tty-earlier@tty12
├─(up,Enabled,oneshot) system-hostname
├─(up,Enabled,oneshot) mount-run
├─(up,Enabled,oneshot) populate-run
├─(up,Enabled,oneshot) mount-tmp
├─(up,Enabled,oneshot) populate-tmp
├─(up,Enabled,oneshot) mount-proc
├─(up,Enabled,oneshot) mount-sys
├─(up,Enabled,oneshot) populate-sys
├─(up,Enabled,oneshot) mount-dev
├─(up,Enabled,oneshot) mount-pts
├─(up,Enabled,oneshot) mount-shm
├─(up,Enabled,oneshot) populate-dev
├─(up,Enabled,oneshot) mount-cgroups
├─(up,Enabled,bundle) 00
├─(up,Enabled,bundle) all-Mount
├─(up,Enabled,oneshot) system-hwclock
├─(up,Enabled,oneshot) modules-kernel
├─(up,Enabled,oneshot) system-random
├─(up,Enabled,oneshot) modules-system
├─(up,Enabled,oneshot) system-sysctl
├─(184,Enabled,longrun) udevd-log
├─(359,Enabled,longrun) udevd
├─(up,Enabled,oneshot) udevadm
├─(up,Enabled,oneshot) system-fontnkey
├─(up,Enabled,oneshot) system-fsck
├─(up,Enabled,oneshot) mount-fstab
├─(up,Enabled,bundle) all-System
├─(up,Enabled,oneshot) mount-rw
├─(up,Enabled,oneshot) mount-netfs
├─(up,Enabled,oneshot) local-loop
├─(up,Enabled,oneshot) local-sethostname
├─(up,Enabled,oneshot) local-time
├─(up,Enabled,oneshot) local-authfiles
├─(up,Enabled,oneshot) local-tmpfiles
├─(up,Enabled,oneshot) local-dmesg
├─(up,Enabled,bundle) all-Local
├─(up,Enabled,oneshot) all-Runtime
├─(up,Enabled,bundle) All
├─(580,Enabled,longrun) tty-rc@tty1
├─(579,Enabled,longrun) tty-rc@tty2
└─(up,Enabled,module) boot@system
Name : root
Initialized : yes
Enabled : yes
Starts after : None
Current : yes
Allowed : root
Symlinks : svc->source db->source
Contents : /
├─(567,Enabled,classic) dhcpcd-log
└─(566,Enabled,classic) dhcpcd
Para activar o serviço e iniciá-lo na altura correcta do processo de arranque, criamos uma nova tree net (que correrá serviços que dependem de a rede estar configurada) a seguir à tree root (onde neste momento está o serviço dhcpcd que configura a rede):
|
|
66-tree: info: Created successfully tree: net 66-tree: info: Enabled successfully tree: net 66-tree: info: Ordered successfully tree: net starts after tree: root
Depois de criar a nova tree, adiciona-se o serviço sshd a essa tree:
|
|
66-enable: info: Enabled successfully: sshd
E finalmente activam-se todos os serviços da tree:
|
|
66-all: info: Initialized successfully: sshd-log 66-all: info: Initialized successfully: sshd 66-all: info: Initialization: no atomic services into tree: net 66-all: info: sshd-log: started successfully 66-all: info: sshd: started successfully
E agora já nos podemos ligar ao Obarun por SSH.
Podemos ver as alterações que foram feitas repetindo o comando 66-intree -g
Name : boot
Initialized : yes
Enabled : no
Starts after : None
Current : no
Allowed : root
Symlinks : svc->source db->source
Contents : /
├─(144,Enabled,classic) tty-earlier@tty12
├─(up,Enabled,oneshot) system-hostname
├─(up,Enabled,oneshot) mount-run
├─(up,Enabled,oneshot) populate-run
├─(up,Enabled,oneshot) mount-tmp
├─(up,Enabled,oneshot) populate-tmp
├─(up,Enabled,oneshot) mount-proc
├─(up,Enabled,oneshot) mount-sys
├─(up,Enabled,oneshot) populate-sys
├─(up,Enabled,oneshot) mount-dev
├─(up,Enabled,oneshot) mount-pts
├─(up,Enabled,oneshot) mount-shm
├─(up,Enabled,oneshot) populate-dev
├─(up,Enabled,oneshot) mount-cgroups
├─(up,Enabled,bundle) 00
├─(up,Enabled,bundle) all-Mount
├─(up,Enabled,oneshot) system-hwclock
├─(up,Enabled,oneshot) modules-kernel
├─(up,Enabled,oneshot) system-random
├─(up,Enabled,oneshot) modules-system
├─(up,Enabled,oneshot) system-sysctl
├─(184,Enabled,longrun) udevd-log
├─(359,Enabled,longrun) udevd
├─(up,Enabled,oneshot) udevadm
├─(up,Enabled,oneshot) system-fontnkey
├─(up,Enabled,oneshot) system-fsck
├─(up,Enabled,oneshot) mount-fstab
├─(up,Enabled,bundle) all-System
├─(up,Enabled,oneshot) mount-rw
├─(up,Enabled,oneshot) mount-netfs
├─(up,Enabled,oneshot) local-loop
├─(up,Enabled,oneshot) local-sethostname
├─(up,Enabled,oneshot) local-time
├─(up,Enabled,oneshot) local-authfiles
├─(up,Enabled,oneshot) local-tmpfiles
├─(up,Enabled,oneshot) local-dmesg
├─(up,Enabled,bundle) all-Local
├─(up,Enabled,oneshot) all-Runtime
├─(up,Enabled,bundle) All
├─(580,Enabled,longrun) tty-rc@tty1
├─(579,Enabled,longrun) tty-rc@tty2
└─(up,Enabled,module) boot@system
Name : root
Initialized : yes
Enabled : yes
Starts after : None
Current : yes
Allowed : root
Symlinks : svc->source db->source
Contents : /
├─(565,Enabled,classic) sshd-log
├─(567,Enabled,classic) dhcpcd-log
├─(566,Enabled,classic) dhcpcd
└─(564,Enabled,classic) sshd
Name : net
Initialized : yes
Enabled : yes
Starts after : root
Current : no
Allowed : root
Symlinks : svc->source db->source
Contents : /
├─(565,Enabled,classic) sshd-log
└─(564,Enabled,classic) sshd
Conclusão
Sim, as “árvores” do 66 permitem gerir as dependências dos serviços de forma ligeiramente mais intuitiva do que os clássicos scripts numerados do SysV-init, mas estão muito longe da facilidade de utilização dos service units do SystemD, que são declarativos.
Além disso, a instalação e configuração dos service units é muitas vezes automatizada pelos package managers das distribuições que suportam SystemD, e como são declarativos, basta criar o service unit e depois o SystemD se encarregará de extrair as dependências e paralelismos nos serviços configurados. Apesar de o 66 suportar o arranque paralelo de serviços através do uso das trees, tem de ser o administrador a definir exactamente a ordem de arranque de cada serviço.
Para quem quiser mais controlo do que aquele que o SystemD oferece por defeito, é óptimo, ou pelo menos melhor que o SysV-init, mas é igualmente (ou mais) trabalhoso. Os scripts 66 ajudam um pouco, mas não muito.
Claro que o que falta ao S6, OpenRC, Runit, etc, é as milhares de horas de programação que foram investidas no SystemD e a quantidade neste caso tem uma qualidade em si mesma. Em comparação, todos estes inits são um bolo ao qual falta o fermento para subir.
Se estiver interessado em contribuir para este projecto, eles precisam de si.