Pular para o conteúdo principal

Como colocar script para iniciar com Linux


Para um programa/script específico ser executado na inicialização do sistema, pode-se editar o arquivo “/etc/rc.local”. Nele, deve-se colocar o caminho completo do script e finalizar a linha com & (e comercial), para executar em background, logo antes do “exit 0”.
Existem formas diferentes conforme o sistema de inicialização utilizado: Systemd ou System V (ou Sysvinit). Uma variação. Uma das principais razões para o Debian mudar do SysV para o systemd é a popularização de computadores com mais de um núcleo, de modo aproveitar melhor o paralelismo do que a tentativa realizada pelo Upstart (da Canonical, que mantém o Ubuntu).
O systemd é compatível com o SysV e Scripts de init LSB (Linux Standard Base), mas possui padrões diferentes para conter basicamente a mesma informação. O comando service é uma ferramenta de “compatibilidade” para ajudar as pessoas a migrar de sysvinit para systemd. É um programa que tenta descobrir seu sistema de inicialização atual e chamará as chamadas sysvinit, upstart ou systemd, conforme necessário.
Systemd (systemctl)
É baseado na notação de sete tipos diferentes de unidades (ou units), cujo nome é composto de uma identificação e o seu tipo como sufixo (se não for especificado, o systemctl assumirá .service):
  • service – daemons que podem ser iniciados, parados, reiniciados e recarregados.
  • socket – encapsula um socket no sistema de arquivos ou na Internet; sockets são programas responsaveis pela comunicação ou interligação de outros programas que atuam na camada de transporte, como os “Stream Sockets” (usado no telnet) e os “Datagram Sockets” (usam UDP em vez de TCP).
  • device – encapsula um dispositivo na árvore de dispositivos do Linux; se é marcado através de regras no udev, ele será exposto a um dispositivo de unidade no systemd.
  • mount – encapsula um ponto de montagem na hierarquia do sistema de arquivos.
  • automount – encapsula um ponto de montagem automático na hierarquia do sistema de arquivos; cada unidade automount, tem uma unidade mount correspondente, que é iniciada(montada) assim que o diretório automount é acessado.
  • target – usada para agrupamento lógico de unidades, referenciando outras unidades que podem ser controladas então de forma conjunta (por exemplo, “multi-user.target” é uma unidade que basicamente equivale a regra do run-level 5 no clássico SysV).
  • snapshot – similar a unidade target, a unidade snapshot não faz nada por si so a não ser referenciar outras unidades.
O arquivo do exemplo a seguir deve ser colocado dentro de /etc/systemd/system/ (preferencialmente) ou /usr/lib/systemd/system/ e ter a extensão .service, com o seguinte formato:
Depois de editado, torne o arquivo executável (chmod +x) e teste usando o seguinte comando:
Ela também pode ser parada (stop), reiniciada (restart) ou ter sua configuração recarregada (reload). O seguinte comando recarrega o systemd, scaneando por units novas e modificadas, além de habilitar a unit para ser iniciada na inicialização
Por fim, seu status pode ser verificado com “sudo systemctl status exemplo.service” e reiniciado com “sudo systemctl reload-or-restart exemplo.service”. Para estar funcionando, deve estar com status “loaded” e “active (running)”.
System V (SysV ou sysvinit)
Também é possível colocar o script diretamente no diretório “/etc/init.d” – lembrando de dar permissão de execução através do comando “sudo chmod 755 nome_do_script”. Nesse caso, executar “sudo update-rc.d nome_do_script defaults” para criar o link simbólico de modo a executá-lo na inicialização – para removê-lo, utilize “remove” em vez de “defaults”.
Um script LSB (Linux Standard Base) Init tem como principal finalidade a execução de comandos na inicialização do sistema operacional seguindo uma padronização. Para isso, ele deve ter suporte para as seguintes ações: start, stop, restart, force-reload, e status. Além disso, deve retornar uma saída de erros apropriada e ter as “run-time dependencies”: um cabeçalho padrão no início do script com as informações necessárias ao seu funcionamento. Cada linha tem sua função:
  • Provides: especifica qual é a facility executada por este script Init (o nome deve ser único);
  • Required-start: especifica o conjunto de facilities que deve ser iniciado antes de começar este serviço. Além de nomes “reais” de programas (postgresql, por exemplo), também existem alguns nomes para facilities “virtuais”, iniciados por cifrão: local_fs, remote_fs, network, named, portmap, syslog, time e all;
  • Required-Stop: especifica a lista de facilities que devem ser paradas depois de parar esta facility.
  • Default-Start e Default-Stop: definem os níveis de execução em que o serviço deve ser iniciado ou parado. Veja mais sobre o init e os runlevels no post sobre Linux Debian.
  • Short-Description e Description: apresentam a descrição do serviço.
A segunda parte do script deve conter um “case” para ações diferenciadas ao receber o argumento “start”, “stop” ou outros. Veja um exemplo do arquivo “/etc/init.d/firewall” para executar o shell script “firewall.sh”:
Por ser um shell script, o arquivo “firewall.sh” deve ter “#!/bin/bash” na primeira linha, indicando que será executado através do binário “/bin/bash”. Sua inicialização deve indicar o caminho completo do arquivo ou uma mudança para esse diretório. Aqui também inclui o redirecionando das saídas 1 (padrão) e 2 (erros) para um arquivo de log, além de ser executado em background (último “e comercial”). O comando “pkill -f” permite encerrar todos os processos que contenham o padrão “firewall” em seus nomes.
Execute o comando “update-rc.d firewall defaults”. Caso apareça uma mensagem do tipo “insserv: warning: current start runlevel(s) (2 3 4 5) of script”, execute “update-rc.d firewall remove” e “update-rc.d firewall defaults” depois.
Obs.: Caso o script executado imprima mensagens na tela (saída de uma comunicação serial, por exemplo), você também pode redirecionar a saída padrão para uma outra tela/console. Para isso, inclua “1> /dev/tty1”, por exemplo, na linha de execução do script para enviar o texto para outra tela, e assim não ficar imprimindo um monte de coisas na tela onde vocês está trabalhando. Caso tenha mais de um script, pode direcionar para outra tela (tty2, etc).
Para iniciar o serviço, execute o comando “/etc/init.d/firewall start” ou reinicie o computador.
Crontab
O serviço de agendamento de tarefas do Linux também pode ser usado para iniciar um script na inicialização. O texto a seguir pode ser incluído no crontab do usuário através do comando “crontab -e”:
Ao reiniciar o computador, deve aparecer o texto “Monolito Nimbus” escrito no arquivo “teste.txt” – ou alguma mensagem de erro, se for o caso. Veja mais sobre Agendamento de tarefas no crontab clicando no link.
Fontes

Comentários

Postagens mais visitadas deste blog

Upgrading Iomega ix2-200 to Cloud Edition

You just got your ix2-200 from eBay and there are no disks inside the NAS. Or you have a brand new ix2-200 -yet you could not afford Cloud Edition. No problem. With just a USB stick and a SATA adapter or desktop PC, you will easily upgrade your ix2-200 to ix2-200 Cloud Edition. Not only your ix2-200 will have a brand new interface and Cloud options, but also will become Mac OS X Lion compatible! What do we need? Decrypted! ix2-200 Cloud Edition Firmware 3.1.12.47838 S endSpace or RapidShare * USB Flash Drive with at least 2 GB capacity and LED indicator** SATA to USB adapter or desktop PC Toothpick or paperclip Preparing Hard Drives Preparing hard drives is the first step because you have to wipe all the data inside the hard drives and make them just like brand new. We used 2 x Seagate 2 TB 5900 RPM Drives. Backup any files if you have and then remove both disks from ix2-200 and attach them to SATA to USB adapter or your desktop PC's SATA port. Using

Cuckoo com Vmware Esxi

Cuckoo is an open-source malware analysis platform using sandboxing technology. The tool allows people like us to analyze malicious binaries in an isolated environment. Since Cuckoo is commonly used with Oracle VirtualBox as its virtualization platform, a majority of online documentation is focused on configuration using VirtualBox. PlantainStan and I decided to test running Cuckoo on ESXi and document our success. This guide will help with the basic configuration of ensuring Cuckoo properly interacts with ESXi. We will continue to update this post as we make continue to make an even more baller Cuckoo environment! Note: In order to successfully interact with vSphere's API, you will need the VMWare ESX Standard license. API functionality is required for Cuckoo to work with ESX. Configure ESX Since this guide is not a "how to" on installing ESXi, we will assume that you have successfully installed the hypervisor on your system. There

CentOS7 with Snort Barnyard2 Snorby PulledPork SElinux

This post is about how to install Snort "stack" on CentOS7 with potentially all the latest libs an stuff. Here I will install and configure everything to run Snort as IDS. I will write another post shortly how to run it as IPS - INLINE. System details: [ root@nfsec-ids-01 ~ ] # cat /etc/redhat-release CentOS Linux release 7.3.1611 ( Core ) [ root@nfsec-ids-01 ~ ] # uname -a Linux nfsec-ids-01.nfsec.co.uk 3.10.0-514.2.2.el7.x86_64 #1 SMP Tue Dec 6 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Snort 2.9.9.0 Installation of snort is very basic: yum install https://www.snort.org/downloads/snort/daq-2.0.6-1.centos7.x86_64.rpm yum install https://www.snort.org/downloads/snort/snort-2.9.9.0-1.centos7.x86_64.rpm Register at Snort and download registered rule set: mkdir /usr/local/src/snortrules cd /usr/local/src/snortrules wget https://www.snort.org/rules/snortrules-snapshot-2990.tar.gz?oinkcode = < oinkcode > tar -zxvf snort