inicializar script com o sistema

[pentestbox]

Ola pessoal, gostaria de saber como colocar um script para inicializar com o sistema operacional, criei um script com regras no iptables e preciso fazer o mesmo inicializar com o sistema, a um tempo atrás, eu configurava o arquivo rc.local com o caminho completo do script e o mesmo inicializava com o sistema, ao tentar fazer isso no lubuntu 16.10 não encontrei o arquivo rc.local no sistema, existe alguma outra maneira de fazer o script inicializar ao sistema? coloquei o script no /etc/init.d e coloquei permissão de execução, me disseram que era possível inicializar o script na inicialização com o comando systemctl, tentei mais não consegui, utilizei $ sudo systemctl enable <nome do script> e deu erro, enfim como poderia fazer o script inicializar ao sistema? E onde encontro o arquivo rc.local no ubuntu 16.10?
Desde já Agradeço.

[druidaobelix]

Até funciona usar o init como sempre se fez, porém já agora nos tempos do systemd precisa ver se seu script não possui dependências dos demais processos, porque aí até vai chamar o script, mas acaba não fazendo o que se pretende.

[pentestbox]

Até funciona usar o init como sempre se fez, porém já agora nos tempos do systemd precisa ver se seu script não possui dependências dos demais processos, porque aí até vai chamar o script, mas acaba não fazendo o que se pretende.

Então, fiz algo bem ridículo para ver se funcionava, fiz so isso:

#!/bin/bash
iptables -P INPUT DROP

Somente isso no script, e nada do mesmo inicializar com o sistema, antes era tudo mais fácil, so passava o caminho no arquivo /etc/rc.local, agora pelo visto esse arquivo não está mais vindo presente nas distros não sei pq.

[druidaobelix]

Isso pode ser interessante até para consolidar a questão aqui no Fórum.
Vamos primeiro fazer pelo método que sempre se fez, que é usar o init e depois, se o caso, evoluímos.
Obviamente sempre seria possível fazer usando os "Aplicativos iniciais de sessão", mas deixemos isso para o final, se nada mais funcionar.
Vou detalhar os passos do método initi e faço o post aqui daqui a pouco.

[druidaobelix]

Pensando melhor, na verdade o rc.local como ferramenta integrada do SysVinit já está configurado para execução no runlevel 5, então não está é funcionando mesmo quando há relações de dependência resolvidas pelo systemd, mas como o objetivo é também didático, vamos testar a hipótese fazendo um simples experimento, antes de partir para refazer todo o processo manualmente.

Primeiro ao invés de incluir diretamente os comandos no rc.local vamos criar um script separado dentro do /bin, o que nos permitirá avaliar a execução e eventuais mensagens de erros através do journalctl, também incluindo nele expressamente a PATH para assegurar que ele na execução encontre o iptables e, finalmente, ao invés do bash vamos usar o sh (=dash).

Apenas para padronizar num teste posterior de configuração manual no init.d, como a execução é léxica nos rc, então vamos dar ao nosso script o nome de zarruda.sh, claro que poderia ser qualquer outro desde que colocado no ponto adequado, mas por enquanto não vamos usar isso já que o primeiro teste é mesmo com o rc.local.

Fica algo assim:

Código Selecionar Expandir

sudo gedit /bin/zarruda.sh

Cole o seguinte conteúdo:

#! /bin/sh -e

#Tópico ubuntuforum-br
#autor do tópico: pentestbox
#https://ubuntuforum-br.org/index.php/topic,122190.msg671563.html#new


PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MYNAME=/bin/zarruda.sh

iptables -P INPUT DROP

#controle de execução (depois retiramos)
#comandos extras podem ser apagados se o script funcionar:

echo "Registro para ver se o script fuciona no boot" >> /testescriptboot.txt
echo "Horário que o script foi executado:" >> /testescriptboot.txt
date >> /testescriptboot.txt
echo >> /testescriptboot.txt

Salvar e sair

Tornar o script executável:

Código Selecionar Expandir

sudo chmod +x /bin/zarruda.sh


Crie agora um arquivo de controle de execução na raiz do sistema:

Código Selecionar Expandir

sudo touch /testescriptboot.txt

Deixe o arquivo como propriedade do usuário do sistema:

Código Selecionar Expandir

sudo chown $USER /testescriptboot.txt


Acrescente a chamada do script no rc.local:

Código Selecionar Expandir

sudo gedit /etc/rc.local

antes do exit 0, acrescente assim:

/bin/zarruda.sh

Salvar e sair.

Está pronto, agora é só testar reiniciando o sistema.
Se funcionar a cada reinício estará gravada uma entrada no arquivo /testescriptboot.txt

Como se sabe, para ver o conteúdo do arquivo basta fazer:

Código Selecionar Expandir

cat /testescripboot.txt

Faça aí, vamos ver o resultado e depois desenvolvemos a próxima solução.

[druidaobelix]

[...] ao tentar fazer isso no lubuntu 16.10 não encontrei o arquivo rc.local no sistema,  E onde encontro o arquivo rc.local no ubuntu 16.10?

Êpa, um aparte, só agora é que "caiu a ficha", você está usando o Lubuntu 16.10, não tem rc.local nele! 
O post que fiz foi inútil, embora creio que talvez baste criar o rc.local em /etc, mas preciso subir um aqui e ver os links.

O raciocínio vale para quem estiver com a versão 16.04

Pior que isso, a versão 16.10 já está fora de linha, está descontinuada. não tem mais suporte. 

[druidaobelix]

Então, @ pentestbox, você já é antigo aqui no Fórum e talvez mais ainda no Linux, mais que certamente sabe da programação de versões do Ubuntu e derivados.

O Ubuntu e derivados versão 16.10 é uma versão transitória, portanto, não é algo para ser usado em produção real.

Em produção se usa versão LTS, Long Term Support, cujo prazo do suporte é de 5 anos.
As LTS atuais são as versões 14.04 e 16.04.
Versões transitórias extinguem-se em apenas 9 meses, é só confusão, é apenas experimento.
O que funciona bem é aproveitado numa próxima versão LTS, o que não funciona é descartado, é assim que funciona.

Isso na essência significa que **não** se deve usar uma versão transitória para assuntos sérios e instalações de produção no dia a dia de trabalho, sendo mais adequado optar sempre por versões LTS.

Na identificação numérica das versões os dois primeiros números referem-se ao ano, os dois últimos ao mês, assim, 14.04 é lançamento de abril de 2014, e então 16.04 é lançamento em abril de 2016 e assim por diante. O terceiro e último número, quando existe, refere-se ao release (14.04.5 ou 16.04.3).

Versões LTS são suportadas por 5 anos, versões  chamadas Regular (=Provisória) são suportadas por 9 meses.

Para entender melhor o calendário geral de validade e suporte de todas as versões

Ubuntu releases calendar

https://wiki.ubuntu.com/Releases

Complementarmente também esse:

https://wiki.ubuntu.com/LTS

Mais especificamente aqui:

https://www.ubuntu.com/info/release-end-of-life

De toda sorte, também não se deve usar versão já vencida, que não tem mais manutenção de nenhuma espécie, nem mesmo as de segurança.

Além do que um enorme esforço é despendido pelas equipes de desenvolvimento na manutenção e atualização das versões, sempre fazendo evoluir a distribuição e o próprio Linux.

Consertar ou trabalhar em cima de versão vencida é dar tiro em cachorro morto, não faz sentido. 

[druidaobelix]

Não tenho uma versão 16.10 imediatamente disponível para poder concretamente verificar, mas muito possivelmente nesse particular aspecto do rc.local deve estar qual a atual versão 17.04, também transitória, questão de ver.

No Ubuntu versão 17.04 igualmente não existe mais o rc.local, o qual foi transformado em um serviço definido em /lib/systemd/system/rc.local.service, que nada mais é que um script o qual é executado se o arquivo /etc/rc.local existir, ou em outras palavras, é o gatilho para a execução do rc.local tradicional.

Assim sendo, quando se quer acrescentar algo basta criar um arquivo rc.local dentro do etc, não tenho muito certeza do conteúdo, isto é, se precisa igualmente terminal em exit 0, mas creio não deverá ter problemas se fizer dessa forma, como sempre foi.

[pentestbox]

O ubuntu 16.10 esta sendo rodado em uma VM, eu sei que a versão ja perdeu suporte, eu a usei como exemplo pois parece que o rc.local deixou de existir nessa versão, logo todas as próximas versões até as LTS não irão vir mais com o rc.local, então independente de qual versão for o fato é que teremos que esquecer o rc.local e aprender outras maneiras de colocar nossos scripts para inicializar durante o boot.

[pentestbox]

Não tenho uma versão 16.10 imediatamente disponível para poder concretamente verificar, mas muito possivelmente nesse particular aspecto do rc.local deve estar qual a atual versão 17.04, também transitória, questão de ver.

No Ubuntu versão 17.04 igualmente não existe mais o rc.local, o qual foi transformado em um serviço definido em /lib/systemd/system/rc.local.service, que nada mais é que um script o qual é executado se o arquivo /etc/rc.local existir, ou em outras palavras, é o gatilho para a execução do rc.local tradicional.

Assim sendo, quando se quer acrescentar algo basta criar um arquivo rc.local dentro do etc, não tenho muito certeza do conteúdo, isto é, se precisa igualmente terminal em exit 0, mas creio não deverá ter problemas se fizer dessa forma, como sempre foi.

Bom eu criei o arquivo rc.local no /etc o configurei passando o caminho completo do script e o script não foi executado durante o boot do sistema.

[pentestbox]

Acho que consegui resolver o problema, acabei de criar o rc.local no diretório /etc da seguinte maneira:

# vi /etc/rc.local

Conteudo do rc.local:

#!/bin/bash

/etc/init.d/firewall

exit 0

em seguida dei permissão de execução:

# chmod + x /etc/rc.local

ao reinicializar o sistema foi carregado as configurações do meu script /etc/init.d/firewall

Mais alguem poderia fazer esse teste e confirmar também?

[druidaobelix]

[...] ao reinicializar o sistema foi carregado as configurações do meu script /etc/init.d/firewall
Mais alguem poderia fazer esse teste e confirmar também?

Então, @pentestbox,


Aquela forma proposta no post #4 deveria funcionar, pelo menos em relação a produzir um registro no arquivo testescriptboot.txt na forma mencionada.
Quando fiz aqui usando uma versão 16.04.3 funcionou, vou testar novamente usando uma versão 17.04 para quer o que acontece.

De toda forma você próprio pode e deve incorporar aquele modelo ao script de nome "firewall" que criou e testar aí mesmo se está executando ou não.

A razão de criar aquela pequena rotina extra é exatamente para poder testar se a execução está passando pelo script de forma objetiva, produzindo um registro.

É só incorporar ao script firewall aquele conjunto de comandos e ver o que acontece, se produz uma linha no arquivo /testescripboot.txt ou não.
É uma forma primária de testar, porém é fácil de fazer e objetiva.

Além disso, verifique também fazendo:

Código Selecionar Expandir

journalctl | grep firewall

O que é que retorna desse comando?

[druidaobelix]

[...]o fato é que teremos que esquecer o rc.local e aprender outras maneiras de colocar nossos scripts para inicializar durante o boot.

Apenas para reforçar, como dito antes, o rc.local foi transformado em service na vigência do systemd, então ele não desapareceu, a funcionalidade continua a existir, quem quiser e precisar usar é só criar dentro do /etc que irá funcionar como sempre funcionou, se existir será chamado pelo /lib/systemd/system/rc.local.service.

[pentestbox]

[...]o fato é que teremos que esquecer o rc.local e aprender outras maneiras de colocar nossos scripts para inicializar durante o boot.

Apenas para reforçar, como dito antes, o rc.local foi transformado em service na vigência do systemd, então ele não desapareceu, a funcionalidade continua a existir, quem quiser e precisar usar é só criar dentro do /etc que irá funcionar como sempre funcionou, se existir será chamado pelo /lib/systemd/system/rc.local.service.

Que bom então que ainda é possível usar o rc.local, ele facilita e muito a execução de scripts, eu imaginei que ao criar o arquivo o problema iria se resolver, so que eu cometi 2 erros, eu não acrescentei a linha #!/bin/bash no rc.local e não dei permissão de execução: # chmod +x /etc/rc.local por isso não funcionou, acabei de fazer o teste com o seu exemplo salvo no arquivo rc.local, ao reinicializar o sistema duas vezes, exibi a informação do arquivo testescripboot.txt, o que me retornou:

Registro para ver se o script funciona no boot
Horário que o script foi executado:
sex set 1 15:15:43 -03 2017

Registro para ver se o script funciona no boot
Horário que o script foi executado:
sex set 1 15:18:15 -03 2017

Vlw mesmo, muito obrigado pela ajuda, suas dicas me ajudaram muito, muito obrigado.

[druidaobelix]

Pois bem, prezado @pentestbox,

Na verdade nem bem começamos a jornada, evidentemente se você tiver com disposição para percorrer esse caminho.

O que estou propondo, digamos assim, ao invés de um simples tutorial, é um "método socrático" para explorarmos essa questão, com vistas a um abordagem didática que possa ser útil principalmente aos iniciantes que frequentam aqui o Fórum, para que possam aprender com esse processo.

Claro que de antemão já se sabe a resposta final, mas o método tem o mérito de sedimentar o conhecimento.

Depois, no final, querendo, até se pode fazer um tutorial.