Início / server / Perguntas / 633683
Accepted
DTK
Asked: 2014-10-06 09:06:50 +0800 CST

Preparando um dispositivo virtual

  • 772

Antes de converter uma máquina virtual em execução em um OVA (dispositivo virtual redistribuível), o que é preciso fazer para garantir que ela esteja pronta para que as instâncias do OVA não tragam resíduos desnecessários ou potencialmente perturbadores do processo de construção? Isso é o que eu tenho até agora. Estou perdendo alguma coisa? Se isso já foi respondido ou se existe um documento de Melhores Práticas Comuns, gostaria de receber uma indicação na direção certa. Obrigado.

#################################
##
## Obtenha todos os pacotes atualizados e
## limpe qualquer sujeira no
## pacotes locais
##
#################################
atualização yum -y;
yum limpa tudo;


#################################
##
## Livre-se dos sinais que eu estava
## mexendo nisso
##
#################################
[[ -a /etc/issue-original,v ]] && unlink /etc/issue-original,v ;
[[ -a /etc/issue,v ]] && unlink /etc/issue,v ;
ci -u /etc/issue ;



#################################
##
## Remova as chaves de host para eles
## será regenerado quando o
## nova VM é iniciada
##
## Certifique-se também de remover qualquer
## chaves pessoais eu posso ter sido
## usando durante a configuração
##
#################################
localize /etc/ssh/*host* |xargs unlink ;
find /root/.ssh/ -type f |xargs unlink ;
find /home/*/.ssh/ -type f |xargs unlink ;



#################################
##
## Livre-se do uso de UUID em
## FSTAB e qualquer configuração de NIC
## para que a nova VM possa encontrar quando
## os UUIDs são regenerados
##
## Como usamos LVM, apenas o /boot
## fatia é uma referência de fatia direta
## o resto são volumes lógicos
##
#################################
sed -i -e 's/UUID=[0-9a-f-]*\s/\/dev\/sda1\t/' /etc/fstab ;
sed -i -e '/^UUID=[0-9a-f-]*.*/d' /etc/sysconfig/network-scripts/ifcfg-eno* ;
sed -i -e '/^UUID=[0-9A-F-]*.*/d' /etc/sysconfig/network-scripts/ifcfg-eno* ;
encontre /etc/udev/rules.d/ -iname '70*net*' |xargs unlink ;


#################################
##
## Informe o daemon NTP para
## espere um grande salto no tempo, então
## ele não surta. Também deixe
## ele sabe que se as paredes derreterem,
## é o ácido, falando e
## ele vai ficar bem
##
#################################
[[ -a /etc/ntp.conf ]] && \
  [[ "$(head -1 /etc/ntp.conf)" == "tinker panic 0" ]] || \
  sed -i -e '1itinker panic 0\n' /etc/ntp.conf ;



#################################
##
## Trunar os históricos de comandos
## porque o processo de aprendizagem
## pode conter alguns embaraçosos
## erros, alguns dos quais são
## também opsec ruim
##
#################################
>/root/.bash_history ;
>/home/*/.bash_history ;
>/root/anaconda-ks.cfg ;



#################################
##
## Por fim, instrua o sistema operacional a refazer
## a configuração inicial e colocar de volta
## aquele cheiro de máquina nova
##
#################################
sys-unconfig ;
linux

1 respostas

  1. Best Answer

    Não tenho acesso ao nosso script de limpeza atual agora, mas uma das coisas que levamos em consideração é que o dispositivo pode ser implantado sem executar as etapas de personalização adequadas. Isso significa, por exemplo, que o nome do host na imagem original pode permanecer e deve ser redefinido antes de fechar. Normalmente definimos o nosso como localhost.

    Com isso em mente, estas são etapas extras que você pode precisar cuidar

    • limpar /etc/hosts, /etc/resolv.conf, /etc/sysconfig/networkde quaisquer valores personalizados
    • além de remover os arquivos ifcfg, não se esqueça de remover quaisquer arquivos de rota ( /etc/sysconfig/network-scripts/route-eno*), se você os tiver
    • gire e limpe cada arquivo de log, log de auditoria e o arquivo wtmp (não remova o arquivo wtmp, apenas cat /dev/null > /var/log/wtmp), para que eles iniciem vazios
    • limpar /var/tmpe/tmp
    • limpe o log de provisionamento do vmware, se você o tiver (iirc, /var/log/vmware-imc/*)
    • se você registrou seu modelo em algo como RH Satellite, SpaceWalk, SuSE Manager ou o próprio RHN, certifique-se de restaurar /etc/sysconfig/rhnou similar de volta aos valores padrão. Por experiência própria, rmfazer isso é uma má ideia. Normalmente, fazemos apenas um backup ao criar a imagem pela primeira vez e o recuperamos ao fechá-la. O mesmo vale para /etc/sysconfig/osad, se o seu ambiente o usar.
    • remova todos os usuários extras que possam ter sido criados e TODAS as senhas no arquivo shadow
    • certifique-se de que os scripts de inicialização, primeira inicialização e personalização pós-implantação estejam realmente configurados para serem executados na primeira inicialização.

    Por último, mas não menos importante, você pode zerar cada sistema de arquivos mais o espaço VG extra não utilizado, para que você possa compactar melhor a imagem. Temos um script que entra em cada sistema de arquivos, dd é um monte de zeros até encher e, em seguida, remove o arquivo. O mesmo para um VG com espaço vazio, crie um LV que preencha 100% GRÁTIS, zere-o e remova-o. Depois de terminar essas últimas etapas (as últimas antes de desligar), você pode usar um truque dependendo do tipo de imagem que está criando:

    • Para VMWare, clone a imagem em uma nova VM, com o destino definido como thin provisioning. Ao fazer isso, todos os zeros contíguos serão convertidos em nada
    • Para imagens openstack/kvm, você pode querer convertê-las usando qemu-img para qcow2 (se seu provedor suportar) e habilitar o sinalizador de compactação:qemu-img convert -f raw -O qcow2 -c source.raw destination.qcow2

    Uma coisa que tiramos desse processo é que, toda vez que executamos um novo ciclo de imagens, descobrimos algo novo que poderíamos ter adicionado, geralmente somente após o envio. Isso é adicionado ao próximo ciclo e assim por diante.

    EDIT: no espírito do "toda vez que aprendemos algo novo", as seguintes etapas foram adicionadas da última vez:

    • yum história nova
    • yum reinstalar basesystem -y
    • 4

relate perguntas