É possível adicionar uma variável através do prompt de boot ao instalador Debian, para que a variável possa ser usada em um arquivo de pré-configuração?
Em particular, estou tentando resolver o seguinte problema:
Temos um script de pós-instalação bastante extenso que geralmente é baixado de um servidor. Mas agora quero criar imagens do Packer e manter o script de pós-instalação no controle de versão junto com os outros arquivos do Packer. Para acessar o preseed, eu posso fazer "preseed / url = http: // {{.HTTPIP}}: {{.HTTPPort}} / preseed.cfg" no comando boot. Mas agora eu quero que o instalador faça o download do script de pós-instalação a partir desse mesmo local.
Atualmente, o gancho de pós-instalação é assim:
d-i preseed/late_command string wget -q -O /tmp/postinstall.sh http://our.public.server/postinstall.jessie.sh ; sh /tmp/postinstall.sh
Idealmente, gostaria de fazer algo como:
d-i preseed/late_command string wget -q -O /tmp/postinstall.sh http://{{ .HTTPIP }}:{{ .HTTPPort }}/postinstall.jessie.sh ; sh /tmp/postinstall.sh
Mas é claro que o instalador do Debian não irá substituir aqueles com os valores requeridos. Então, eu estava pensando que seria possível passar variáveis do tipo variável de ambiente para o instalador que podemos usar no arquivo preseed.
Quaisquer sugestões ou dicas são apreciadas!
EDIT: Tentei adicionar o comando late_ ao comando de inicialização, mas ele não foi atendido.
EDIT: Preseed / run tentado, mas é executado em um ambiente diferente que não permite o comando in-target.
EDIT: Isso pode ser uma solução alternativa: Como canalizar comandos juntos em um arquivo preseído do Debian? Mas prefiro ter o script em um arquivo separado. Se não for possível, não é possível, no entanto.
Ok, resolvi sozinho (com alguma ajuda de @lieter_). Não muito orgulhoso disso, mas funciona:
d-i preseed/late_command string wget -q -O /tmp/postinstall.sh http://'cat /proc/cmdline | sed 's/.*url=\([^ ]\+\).*//''/d-i/jessie/postinstall.sh ; sh /tmp/postinstall.sh
Isso faz o que eu preciso, já que sempre adicionamos um url = à nossa linha de comando durante a instalação.
Depende de qual sistema operacional você está usando, mas o kernel do Linux permitirá que você especifique variáveis de ambiente como parâmetros do kernel. A documentação do kernel Linux tem algumas boas informações em torno dela (parágrafo importante em negrito):
The argument list
The kernel command line is parsed into a list of strings (boot arguments) separated by spaces. Most of the boot arguments have the form:
name[=value_1][,value_2]...[,value_10]where 'name' is a unique keyword that is used to identify what part of the kernel the associated values (if any) are to be given to. Note the limit of 10 is real, as the present code handles only 10 comma separated parameters per keyword. (However, you can reuse the same keyword with up to an additional 10 parameters in unusually complicated situations, > assuming the setup function supports it.)
Most of the sorting is coded in the kernel source file init/main.c. First, the kernel checks to see if the argument is any of the special arguments 'root=', 'nfsroot=', 'nfsaddrs=', 'ro', 'rw', 'debug' or 'init'. The meaning of these special arguments is described below.
Then it walks a list of setup functions to see if the specified argument string (such as 'foo') has been associated with a setup function ('foo_setup()') for a particular device or part of the kernel. If you passed the kernel the line foo=3,4,5,6 then the kernel would search the bootsetups array to see if 'foo' was registered. If it was, then it would call the setup function associated with 'foo' (foo_setup()) and hand it the arguments 3, 4, 5, and 6 as given on the kernel command line.
Anything of the form 'foo=bar' that is not accepted as a setup function as described above is then interpreted as an environment variable to be set.
A (useless?) example would be to use 'TERM=vt100' as a boot argument.Any remaining arguments that were not picked up by the kernel and were not interpreted as environment variables are then passed onto PID 1, which is usually the init(1) program. The most common argument that is passed to the init process is the word 'single' which instructs it to boot the computer in single user mode, and not launch all the usual daemons. Check the manual page for the version of init(1) installed on your system to see what arguments it accepts.
Aqui está minha seção boot_command no meu construtor virtualbox-iso (para o Ubuntu 18.04):
boot_command:
- '<esc><esc><enter><wait>'
- '/install/vmlinuz noapic fb=false '
- 'auto=true '
- 'hostname={{.Name}} '
- 'url=http://{{.HTTPIP}}:{{.HTTPPort}}/ubuntu.seed '
- 'initrd=/install/initrd.gz '
- 'http_proxy={{user 'http_proxy'}} '
- 'packer_host={{.HTTPIP}} '
- 'packer_port={{.HTTPPort}} '
- 'hello=world '
- 'quiet --- <enter>'
Os parâmetros http_proxy , packer_host , packer_port e hello são completamente opcionais e serão convertidos em variáveis de ambiente pelo kernel.
No meu arquivo ubuntu.seed , tenho a seguinte linha para imprimir a variável de ambiente hello em um arquivo:
d-i preseed/late_command string echo $hello > /target/home/packer/hello
Quando importo e inicio o OVA, esse arquivo estará no meu diretório pessoal com world como seu conteúdo.
Enquanto procuramos resolver o mesmo problema, aprendi sobre mágica que é incorporada no debian-installer . Você pode usar preseed_fetch para extrair o URL se adicionar um /./ ao ponto no URL que deseja definir como rootpath para que outros comandos realizem suas buscas relativas.
Dado um servidor com uma pasta preseed e uma pasta de scripts com outros arquivos que você deseja usar, se você passar url=http://{{.HTTPIP}}:{{.HTTPPort}}/http/./preseed/ubuntu.seed você pode referenciar outros arquivos relativos ao caminho da raiz como preseed_fetch /scripts/somescript.sh /tmp/somescript.sh .
d-i preseed/late_command string preseed_fetch /scripts/late_script /tmp/late_script; \
log-output -t late_script sh /tmp/late_script