Tornando o self-configure do Linux na inicialização inicial

Question

Eu gostaria de criar um script de shell único que cria, inicia e configura uma imagem do VirtualBox com uma variante mínima e segura do Linux, sem interação manual ou software de automação.

Criar a imagem do VirtualBox é fácil, mas após a inicialização pela primeira vez, atualmente sou forçado a digitar o seguinte antes de executar o resto do meu script de configuração por SSH:

setup-alpine
reboot
ifconfig eth1 192.168.56.101
adduser joe

Eu pensei que poderia resolver isso copiando arquivos ou executando scripts do host, mas isso parece exigir "adições de convidados" que não estão disponíveis para o Alpine Linux, minha escolha atual.

Como faço para automatizar totalmente esse processo sem qualquer interação manual depois de iniciar o script inicial?

    

Answer 1

Sugiro adicionar seus comandos personalizados no final de:

/etc/rc.local

este é o primeiro arquivo que é executado depois que uma distro é inicializada.

    

Answer 2

Sua tarefa parece ser a automação de uma instalação de distribuição do Linux. Provavelmente seria mais eficiente modificar a imagem de instalação e incorporar seu script de automação.

Outras opções:

• De alguma forma, obtenha um console serial e espere que um shell de login esteja disponível. Em seguida, use expect para aguardar o console aparecer e emitir os comandos que você está digitando manualmente. (Com o QEMU isso pode ser feito, não tenho idéia de como o VBox lida com isso.)

• Crie um pequeno disco contendo seu script e dependências. Então tudo que você precisa digitar é algo como:

  mount /dev/sdb1 /mnt && /mnt/script.sh
  

• Verifique se você tem alguma conectividade de rede local na sua VM e faça algo como:

  curl 192.168.56.1 | sh
  

A mídia de instalação para algumas distribuições lê uma URL de configuração da linha de comando do kernel. Consulte a documentação da sua distribuição para detalhes.

    

Answer 3

Supondo que você tenha um conjunto de scripts que podem ser executados para configurar a máquina da maneira que você quer, você pode, como sugerido por ebal, executá-los no final de /etc/rc.local (ou o equivalente em sua distribuição). ). Esse script é executado no final do processo de inicialização, pouco antes de o getty ser gerado pelo init.

Eu sugiro que você adicione no final de /etc/rc.local algo como:

test -x /sbin/system-setup-step1.sh && /sbin/system-setup-step1.sh && reboot
test -x /sbin/system-setup-step2.sh && /sbin/system-setup-step2.sh && reboot
test -x /sbin/system-setup-step3.sh && /sbin/system-setup-step3.sh && reboot
# ... for however many steps are needed for your use case

Em seguida, no final de cada um desses scripts, remova o bit de execução como uma indicação de que ele não precisa mais ser executado (mas deixe o script no disco caso o usuário queira ver o que ele fez) e armazene-o o nome do script em algum lugar e, em seguida, verifique o script executado anteriormente na parte superior do próximo script na sequência. Por exemplo, aqui está o que o system-setup-step2.sh pode parecer:

#!/bin/bash

test $(cat /var/tmp/last-system-setup-step) = "system-setup-step1.sh" || exit 1

# ... do stuff ...

# indicate that this doesn't need to run again
/bin/chmod -x "$0"
printf '%s' $(basename "$0") > /var/tmp/last-system-setup-step
# finished successfully
exit 0

Ajuste a condição de teste perto do topo de cada script.

Desta forma, o sistema irá reiniciar no entanto muitas vezes são necessárias, e no final passará por todas as condições test e chegará a um prompt de login (ou qualquer outra coisa que você tenha configurado) porque nenhum dos scripts ter o bit de execução definido. Se algo der errado, o processo de configuração e reinicialização simplesmente parará.

Na imagem original, verifique se o / var / tmp / last-system-setup-step existe e está vazio, para evitar erros incômodos.

Observe que o acima não foi testado (escrito no navegador), mas deve transmitir a essência.

    

Answer 4

Para o registro, o pacote virtualbox-guest-additions estava disponível nos testes.

A partir de 24 de janeiro de 2017, eles estão disponíveis no repositório da comunidade, para a versão de borda.

Para usar o repositório de testes, você deve:

 export ALPINEVER=v3.5
 echo "http://dl-cdn.alpinelinux.org/alpine/$ALPINEVER/testing" >> /etc/apk/repositories

Claro, você deve alterar o ALPINEVER com a versão do alpine que você está realmente usando.

    

Answer 5

Se você está tentando configurar máquinas virtuais (particularmente no VirtualBox), você pode querer considerar o uso do Vagrant .

Você pode definir a VM em um arquivo de texto simples como este:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

    # Specify the base image or "box"
    config.vm.box = "ubuntu/xenial64"

    # Define networking
    config.vm.network "private_network", ip: "192.168.50.4"

    # Share folders between the host and the guest
    config.vm.synced_folder "../shared", "/shared"

    # Run "provisioners" that change the guest
    config.vm.provision :shell, :inline, "touch hello_world"
    config.vm.provision "shell", path: "script.sh"

    # You can even use tools like Ansible or Puppet:
    config.vm.provision "ansible" do |ansible|
        ansible.playbook = "playbook.yml"
    end
end

O Vagrant facilita o gerenciamento de redes em máquinas virtuais, mas também define facilmente como você deseja configurar sua máquina virtual. E como agora você tem um Vagrantfile para definir sua VM, você pode compartilhá-lo mais facilmente com os outros ou fazer backup dele (como em um sistema de controle de origem como o Git) em comparação com um OVA binário ou equivalente.

Isso fica ainda mais interessante quando você começa a olhar para configurações de várias máquinas onde você precisa de todos os convidados para poder se comunicar entre si.

Se você quiser usar o Alpine, então você vai querer dar uma olhada no vagrant-alpine plugin .