Вопросы Теги

Prepping виртуальное устройство

Прежде, чем преобразовать рабочую виртуальную машину в OVA (распространяемое виртуальное устройство), что нужно сделать для обеспечения, это находится в состоянии готовности, таким образом, экземпляры OVA не взяли с собой ненужный или потенциально разрушительный хлам от процесса сборки? Это - то, что я имею до сих пор. Я пропускаю что-нибудь? Если бы это уже было ответом или существует Лучший Общий документ Методов, я ценил бы указатель в правильном направлении.Спасибо. 


#################################
##
## 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 ;
6
задан 19 February 2015 в 13:32
1 ответ

У меня сейчас нет доступа к нашему текущему сценарию очистки, но одна из вещей, которые мы принимаем во внимание, это то, что устройство может быть развернуто без выполнения соответствующих шагов настройки. Это означает, например, что имя хоста в исходном образе может существовать и должно быть сброшено перед закрытием. Обычно мы устанавливаем наш localhost .

Имея это в виду, это дополнительные шаги, которые могут потребоваться для

  • очистки / etc / hosts , ] /etc/resolv.conf , / etc / sysconfig / network любых настроенных значений
  • в дополнение к удалению файлов ifcfg, не забудьте удалить все файлы маршрутов ( / etc / sysconfig / network-scripts / route-eno * ), если они у вас есть
  • , поверните и очистите каждый отдельный файл журнала, журнал аудита и файл wtmp (не удаляйте файл wtmp, просто cat / dev / null> / var / log / wtmp ), поэтому они запускаются пустыми
  • clean up / var / tmp и / tmp
  • clean вверх журнал инициализации vmware, если он у вас есть (iirc, / var / log / vmware-imc / * )
  • , если вы зарегистрировали свой шаблон в чем-то вроде RH Satellite, SpaceWalk, SuSE Manager или RHN не забудьте восстановить / etc / sysconfig / rhn или аналогичные значения по умолчанию. По опыту rm это плохая идея. Обычно мы просто делаем резервную копию при первом создании образа и возвращаем его обратно при закрытии. То же самое касается / etc / sysconfig / osad , если он используется в вашей среде.
  • удалите всех дополнительных пользователей, которые могли быть созданы, и КАЖДЫЙ ЕДИНЫЙ пароль для теневого файла
  • убедитесь, что сценарии инициализации, первой загрузки, после развертывания и настройки фактически настроены на запуск при первой загрузке.

И последнее, но не менее важное: вы можете обнулить каждую файловую систему плюс дополнительное неиспользуемое пространство VG, чтобы вы могли лучше сжать образ . У нас есть сценарий, который входит в каждую файловую систему, dd - это набор нулей, пока он не заполнится, а затем удаляет файл. То же самое для VG с пустым пространством, создайте LV, который заполняется на 100% БЕСПЛАТНО, обнулите его и удалите. После завершения этих последних шагов (последних перед выключением питания) вы можете использовать трюк в зависимости от типа создаваемого образа:

  • Для VMWare клонируйте образ в новую виртуальную машину с установкой места назначения как тонкого подготовка .. При этом все смежные нули будут преобразованы в ничто
  • Для образов openstack / kvm вы можете захотеть преобразовать их с помощью qemu-img в qcow2 (если ваш провайдер поддерживает это) и включить флаг сжатия : qemu-img convert -f raw -O qcow2 -c source.raw destination.qcow2

Одна вещь, которую мы извлекли из этого процесса: каждый раз, когда мы запускаем новый цикл изображений, мы узнаем о что-то новое, что мы могли бы добавить, обычно только после того, как оно было отправлено. Это добавляется к следующему циклу и т. Д.

РЕДАКТИРОВАТЬ: в духе «каждый раз, когда мы узнаем что-то новое», в прошлый раз были добавлены следующие шаги:

  • yum history new
  • yum повторно baseystem -y
4
ответ дан 3 December 2019 в 00:35

Теги

Похожие вопросы