Preparando um dispositivo virtual

Question

Antes de converter uma máquina virtual em execução em um OVA (appliance virtual redistribuível), o que é necessário fazer para garantir que esteja em um estado pronto para que as instâncias do OVA não tragam problemas desnecessários ou potencialmente prejudiciais do processo de construção? Isso é o que eu tenho até agora. Estou faltando alguma coisa? Se isso já foi resposta ou há um documento de Melhores Práticas Comuns, eu apreciaria um ponteiro na direção certa. Obrigado.

#################################
##
## Get all packages up2date and 
## clean out any cruft in the 
## local packages
##
#################################
yum -y update ;
yum clean all ;


#################################
##
## Get rid of the signs I was 
## tinkering with this
##
#################################
[[ -a /etc/issue-original,v ]] && unlink /etc/issue-original,v ;
[[ -a /etc/issue,v ]] && unlink /etc/issue,v ;
ci -u /etc/issue ;



#################################
##
## Remove the host-keys to they
## will be regenerated when the
## new VM is spun-up
##
## Also make sure I remove any 
## personal keys I may have been
## using while setting up
##
#################################
find /etc/ssh/*host* |xargs unlink ;
find /root/.ssh/ -type f |xargs unlink ;
find /home/*/.ssh/ -type f |xargs unlink ;



#################################
##
## Get rid of the use of UUID in 
## FSTAB and any NIC configuration
## so the new VM can find then when
## the UUIDs are regenerated 
##
## Since we use LVM, only the /boot
## slice is a direct slice reference
## the rest are logical volumes
##
#################################
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* ;
find /etc/udev/rules.d/ -iname '70*net*' |xargs unlink ;


#################################
##
## Let the NTP daemon know to 
## expect a big jump in time, so 
## he doesn't freak out. Also let
## him know that if the walls melt,
## it is the acid, speaking and 
## he'll be alright
##
#################################
[[ -a /etc/ntp.conf ]] && \
  [[ "$(head -1 /etc/ntp.conf)" == "tinker panic 0" ]] || \
  sed -i -e '1itinker panic 0\n' /etc/ntp.conf ;



#################################
##
## Trunate the command-histories
## because the learning-process
## can contain some embarrassing
## mistakes, some of which are 
## also bad opsec
##
#################################
>/root/.bash_history ;
>/home/*/.bash_history ;
>/root/anaconda-ks.cfg ;



#################################
##
## Lastly, instruct the OS to redo
## the initial setup and put back
## that new-machine-smell
##
#################################
sys-unconfig ;

    

Answer 1

Atualmente, não tenho acesso ao nosso script de limpeza atual, mas uma das coisas que levamos em conta é que o appliance pode ser implantado sem executar as etapas de personalização adequadas. Isso significa, por exemplo, que o nome do host na imagem original pode estar ativo e precisa ser redefinido antes de fechar. Nós geralmente definimos o nosso para localhost .

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

• limpe /etc/hosts , /etc/resolv.conf , /etc/sysconfig/network de quaisquer valores personalizados
• além de remover os arquivos ifcfg, não se esqueça de remover os 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 sejam iniciados em branco
• limpe /var/tmp e /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 a própria RHN, restaure /etc/sysconfig/rhn ou similar de volta aos valores padrão. Da experiência, rm 'ing é uma má ideia. Normalmente, fazemos backup apenas quando criamos a imagem pela primeira vez, e voltamos quando a fechamos. 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 TODA ÚNICA senha no arquivo de sombra
• certifique-se de que os scripts de inicialização, de primeira inicialização e de personalização pós-implementação estejam definidos para serem executados na primeira inicialização.

Por último, mas não menos importante, você pode zerar todos os sistemas de arquivos e o espaço VG extra não utilizado, para que você possa comprimir melhor a imagem. Nós temos um script que entra em todo sistema de arquivos, o dd é um monte de zeros até que ele seja preenchido, então remove o arquivo. O mesmo para um VG com espaço vazio, crie um LV que preencha 100% de GRAÇA, zere-o e remova-o. Depois de terminar esses últimos passos (os últimos 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, convém convertê-las usando qemu-img para qcow2 (se o provedor suportar) e ativar 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 nos deparamos com um novo ciclo de imagens, aprendemos algo novo que poderíamos ter acrescentado, geralmente apenas depois de ter sido enviado. Isso é adicionado ao próximo ciclo e assim por diante.

EDIT: no espírito do "toda vez que aprendemos algo novo", os seguintes passos foram adicionados da última vez:

• histórico do yum novo
• yum reinstalar o sistema de bases -y