Как развернуть образ linux

Создание образа системы в Linux

Клонирование — создание точной копии исходного носителя.
В данном случае клонировать нужно корневую файловую систему Linux.
Клонированная копия и образ — одно и то же.

Зачем это надо?

Если вы администрируете парк компьютеров с одинаковой конфигурацией и хотите установить на них дистрибутив Линукс. Устанавливаем на одной машине, а на другие просто клонируем. Если система «накрылась», вы сможете восстановить её исходное состояние развертыванием образа, где всё уже установлено и настроено под ваши нужды

Как создать образ:

Во избежание недоразумений оговорим те разделы и диски, которые будем использовать

/dev/sda — жесткий диск с рабочей системой, его будем архивировать

/dev/sda1 — раздел, содержащий корневую фс

dev/sdb1 — раздел на внешнем жёстком диске для архивации

1.-Перезагрузитесь в однопользовательском режиме (single)

2.-Введите команду mount, чтобы узнать, какой раздел содержит корневую файловую систему (в примере используется /dev/sda1).Образ этого раздела и нужно сохранить на другом носителе. Например на внешнем жестком диске.

3.-Подмонтируйте внешний HDD

4.-Теперь перемонтируем корневую систему в режим «только для чтения» и создадим образ:

Как восстановить систему из созданного образа:

Нужно иметь под рукой: загрузочный компакт-диск любого дистрибутива Linux. При использовании простого диска (не LiveCD) для перехода на текстовую консоль нажмите Ctrl + Alt + F2.

При установке системы на пустой диск нужно создать разделы. При восстановлении после сбоя, ничего создавать не нужно. Лишь убедитесь в том, что раздел подкачки (Linux swap) создан.

Корнем становится каталог /install, к которому примонтирован новый HDD. В качестве командной оболочки выступает /bin/bash.
3.- Перезпишем загрузчик:

4.-Перезагрузим компьютер командой reboot. Копия системы восстановлена

Источник

Развертывание эталонного образа

Собираемся переходитьс с винды на Linux в организации. Проблемы, связанные с нашей специфической медицинской базой данных я решил.

Осталось понять как развернуть попроще образы. Есть подготовленный, установленный на отдельном разделе вариант Kubuntu 12.04 с нужным софтом, ярлычками и прочими мелочами. По идее можно тупо копировать на новый раздел и делать его загрузочным. Однако придется править как минимум fstab и grub2.

Собственно вопрос — как проще размножить настроенную систему на серию компов? Плюс время поджимает. Хотелось бы нацарапать пару несложных скриптов и запускать с внешнего носителя. Типа винт внешний с Линуксом и образом, который накатывается на внутренний HDD.

делаешь tar с содержимым винта, форматируешь винт на новом компе с укащанием старого UUID, распаковываешь tar, ставишь grub?

Перенос файлов раздела на новый раздел, и создание раздела на целевых машинах с нужным UUID решат проблему. Кроме того, можно поправить grub.cfg и fstab так, что-бы они использовали метки томов вместо UUID. В идеале всё, что вам нужно, можно сделать при помощи одного скрипта и архива файлов с донорского раздела. Образ не нужен. Но если охота, можете использовать Clonezilla или dd:)

какя-то фигня на л начинается
на сайте ubuntu.com на главной странице
или ман blkid sh dd busybox

Видимо, использовнаие относительных путей в fstab решит проблему. Осталось только утрамбовать это во вменяемый скрипт, который еще и груб поправит автоматом через chroot. Кстати, без понятия как управлять под чрутом. Он будет воспринимать команды скрипта? Я имею в виду grub-update сделать. Я так понимаю, надо установить дистрибутив на внешний винт и с него автоматом заливать на целевую машину.

Clonezilla не решит проблему с grub и fstab. пути не туда ведут. И в чем преимущество перед dd? Мне его проще использовать, но непонятно как править на конкретной машине. Не будет ли проблем с разделами.

Видимо, использовнаие относительных путей в fstab решит проблему.

Что вы под этим понимаете ?

В /etc/fstab для указания файловой системы, которую вы хотите смонтировать можно использовать:
Имя устройства (раздела или логического тома), например /dev/sda1, /dev/mapper/vg0-root
LABEL или UUID файловой системы, смотрите в выводе ‘blkid’
По ID связке устройства и раздела, например /dev/disk/by-id/ata-ST3320620AS_****-part1.

Осталось только утрамбовать это во вменяемый скрипт,

А почему не использовать parted, можно посмотреть clonezilla или Ping Is Not Ghost ?

Кстати, без понятия как управлять под чрутом.

Точно так же как и обычным скриптом:

Если использовать fsarchiver, то UUID раздела будет сохранен и править fstab нужно будет только для других разделов.

а) настраиваем систему на sda1 и создает файл образ с помощью fsarchiver.

б) разворачиваем образ на новый ПК также на sda1

г) с помощью blkid узнаем UUID остальных разделов (если они есть) и прописываем в fstab

И в чем преимущество перед dd?

dd снимает полный посекторный образ, т.е. если раздел у вас 200 Gb, на нём файловая система, на которой занято всего 20 Гб данных, то dd вы будете снимать образ размером в 200 Гб, а не 20. Что бы уменьшить размер образа его можно сжимать, но с диска в любом случае будет прочитано 200 Гб данных, да и записано на другой диск так же 200 Гб, даже в случае сжатия и распаковки. Вы можете конечно предварительно перед снятием образа файловой системы уменьшить её размер, к примеру до 21 Гб, а заодно и размер раздела. Затем при переносе создать раздел нужного размера, развернуть на раздел файловую систему размером в 21 Гб и затем выполнить «resize» этой файловой системы на весь размер раздела. Как видите действий с ‘dd’ больше, чем вы себе представляли.

Я бы на вашем месте внимательней на него посмотрел. Можно разворачивать как по сети, так и бегая с флэшкой от компа к компу.

Можете конечно таскать винты с каждого компа и втыкать в один и клонить dd 🙂 (Я так понимаю на остальных компах винда.)

Да вот по сети было бы совсем идеально, но боюсь, что подготовка времени займет больше, чем миграция. Спасибо за советы, я пороюсь. Спрошу, если что. Поиздеваюсь над виртуальными машинами пока))

Там по идее будет вообще неразмеченная область. Разделы будут уничтожаться под ноль. Ценной информации локально не хранится. Как корректнее в данном случае? И нужно ли узнавать UUID, если можно использовать относительные пути? Хотя это потенциально может создать проблему при перестановке винтов, насколько я понимаю.

если можно использовать относительные пути?

Ещё раз, что вы понимаете под относительными путями ?

Поднимаете tftp сервер и dhcp, кладёте образ ядра и initramfs PING или clonezilla в директорию, обслуживаемую tftp сервером, пишете простенький конфиг. Загружаетесь по сети, готово.

Да ничего там сложного нет, на сайте все подробно написано, единственное с чем можете столкнуться, если компы сильно старые — не все сетевые карты поддерживают netboot.

На старые компы ставить Kubuntu . да вы что.

Источник

Бэкап Linux и восстановление его на другом железе

Я работаю в организации с маленьким штатом, деятельность тесно связана с IT и у нас возникают задачи по системному администрированию. Мне это интересно и частенько я беру на себя решение некоторых.

На прошлой неделе мы настраивали FreePBX под debian 7.8, нанимали фрилансера. В процессе настройки оказалось, что сервер (да, я так называю обычный PC) не хочет грузится с HDD при подключенных USB 3G модемах, которые мы используем для звонков на мобильные, колупание BIOSа не помогло. Непорядок. Решил, что нужно перенести его на другую железяку. Так появилось сразу две связанные задачи:

• сделать бэкап сервера;
• восстановить бэкап на другом железе.

Гугление не дало внятных ответов, как это сделать, пришлось собирать информацию кусками и пробовать. Всякие acronis’ы отбросил сразу, ибо не интересно.

Опыт общения с linux-системами у меня небольшой: настройка VPN сервера на open-vpn, ftp-сервера и еще пара мелочей. Сам себя я характеризую как человека умеющего читать маны и править конфиги 🙂

Ниже я описываю свой частный случай и почему я поступил именно так. Надеюсь, новичкам будет полезно, а бородатые админы улыбнутся вспомнив молодость.

Начинаем копать теорию:

Второй способ требует наличия внешнего жесткого диска объемом не меньше раздела, который архивируем. Да и что с ним потом делать, непонятно, хранить на полочке? Остановился на tar, чуть сложнее в реализации, нужно будет создать MBR, но время создания/восстановления архива существенно меньше, хранить бэкап проще, полтора гига можно закинуть в облако и скачать, когда будет нужно. Записывать его можно на ту же live-флэшку, с которой буду грузиться.

Итак, план действия:

1. Создание бэкапа

Грузимся с live-флэшки, у меня это debian-live-7.8.0-amd64-standard.

Переключаемся на root:

Монтируем раздел, который будем архивировать, у меня это sda1, чтобы случайно не наломать дров, монтируем только для чтения. Посмотреть все свои разделы можно при помощи команд ls /dev | grep sd или df -l

Наша флэшка уже примонтирована, но в режиме только чтения, нужно перемонтировать для чтения-записи, чтобы писать туда бэкап.

Все готово для создания архива

Здесь у нас параметры: c — создать архив, v — выводить информацию о процессе, z — использовать сжатие gzip, p — сохраняем данные о владельцах и правах доступа, f — пишем архив в файл, путь к файлу, —exclude — исключаем из архива каталог (я исключил каталоги с записями разговоров и каталог с бэкапами FreePBX), /mnt/ — каталог, который архивируем.

Ждем… у меня вся подготовка и создание архива заняли 10 минут. Будь флэшка быстрее, уложился бы в 7-8 минут.

Складываем архив в надежное место за пределами офиса.

Восстановление бэкапа на другом железе

2. Размечаем диск, создаем файловую систему

Грузимся с live-флэшки, у меня все та же debian-live-7.8.0.

Переключаемся на root:

Размечаем диск. Мне понравилась утилита с псевдографическим интерфейсом cfdisk. Там все просто и понятно.

Удаляем все имеющиеся разделы. Я создал два новых раздела, один на 490 Gb под / (sda1) и 10 Gb под swap (sda2) в конце диска, т.к. он практически не будет задействован. Проверим типы разделов. Который под систему должен иметь тип 83 Linux, второй — 82 Linux swap / Solaris. Помечаем системный раздел загрузочным (bootable), сохраняем изменения и выходим.

Cоздаем файловую систему на первом разделе.

3. Распаковываем архив.

Монтируем отформатированный раздел

Распаковываем архив прямо с флэшки

Параметр —same-owner — сохраняет владельцев у распаковываемых файлов, x — извлекаем из архива, v — выводить информацию о процессе, p — сохраняем права доступа, f — указываем файл, который распаковываем, C — распаковываем в категорию.

4. Создаем MBR на новом диске.

Чтобы корректно создать загрузочную запись, монтируем рабочие каталоги к нашему будущему root-каталогу, у меня это /mnt. Каталоги /dev и /proc сейчас используются live-системой, используем параметр bind, чтобы они были доступны сразу в двух местах:

Переключаемся на новую систему используя chroot:

Делаем swap-раздел для новой системы:

Подключаем его же:

Чтобы grub работал, нужно указать ему правильные UUID разделов в fstab, сейчас там прописаны разделы предыдущей системы:

Открываем второй терминал (Alt+F2) под root:

И видим текущие UUID разделов.

Вручную переписываем их в fstab переключаясь между Alt+F1 и Alt+F2. Да, муторно, но попытки копировать занимали у меня больше времени, чем переписывание. Сохраняем fstab.

Устанавливаем grub2. У меня один физический диск, поэтому ставим его на sda:

На чистый диск должно встать без ошибок. Обновляем информацию из fstab:

Возвращаемся в Live-систему:

Размонтируем все каталоги:

Если вылазят процессы, которые используют эти каталоги, убиваем их используя fuser.

Все, поехали. Грузимся с жесткого диска:

Здесь статья должна была закончиться, но у меня возникли проблемы с подключением к интернету. Сервер видит сеть, видит компьютеры в ней, но в интернет не ходит… а это как бы важно для телефонии.

5. Тестирование и устранение неполадок.

Показывет интерфейсы eth1 и lo, гугление сказало, что gateway можно прописать только подключению eth0, остальные рассчитаны только на работу внутри сети.

Похоже, отсутствие eth0 вызвано способом переноса системы. Находим файл, который отвечает за нумерацию интерфейсов, смотрим туда:

Действительно, там два активных интерфейса, определенных MAC’ами. Комментируем первый, второму прописываем eth0.

Перезапуск /etс/init.d/networking не помог, поэтому перезагружаемся:

Подключаем донглы, проверяем, все работает.
Спасибо за внимание.

Источник

Разворачиваем рабочий образ linux с минимальным интерактивом

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

• Linux — based систему на машинах-клиентах;
• Тонкие/толстые однотипные клиенты на различном железе;
• Сетевое хранилище клиентских данных;
• Предустановленный регламентированный софт;
• Openvpn/rdp к серверам приложений.
• Плюшевый (мягкий и пушистый) мониторинг linux клиентов типа Nagios.

Речь пойдет о том, как с минимальными усилиями со стороны пользователя или штатного «эникейщика» установить на компьютер пользователя готовую систему с набором софта, настроенными сетевыми службами, предопределенными конфигами и т.д. Статья ориентирована в первую очередь на энтузиастов и начинающих линуксоидов, но приемы и скрипты вполне могут использоваться в боевом развёртывании группы из десятков машин ежедневно.

Для начала определимся с дистрибутивом. Это, конечно, зависит прежде всего от задач. Я выбрал xubuntu 14.04 по трем простым причинам:

1. ubuntu — deb based система с широчайшей поддержкой и огромным количеством форумов;
2. xubuntu — легковесный вариант без рюшек и понтов, который не тормозит на машинах от 512Мб ОЗУ (есть в моём парке и такие динозаврики);
3. 14.04 — это LTS (Long Term Support) вариант c поддержкой до 2019 года.

Есть, конечно, варианты быстрее и поменьше, но по ряду тех или иных причин выбор был сделан и сожалений на протяжении года с небольшим не вызывает.

Забегая вперед, отмечу: чтобы повторить описанное потребуется настроенный vpn сервер или «конфиг-мониторинг-сервер» в локальной сети, пара виртуальных или реальных машин, пара часов свободного времени и внимание к деталям.

Итак, первое, подготовка образа. Все этапы важны, но первый — это фундамент. Устанавливаем систему с cd/dvd/usb/сети и выбираем разметку дисков. Важно понимать, что наш образ не будет поддерживать динамического ресайза ДО развёртывания. А после, скорее всего такой ресайз и не потребуется. Под корень имеет смысл отдать 6-10 Гб.

Больший объем оправдан в случае, когда заведомо известно, что а) диски на клиентских машинах не будут меньше этого объема и б) действительно будет установлено много разных нужных пакетов.

Разметим /home и, наконец, swap разделы. В совокупности все три раздела у автора не вылезают за 30Гб (чтобы спокойно разместиться на ssd 30 Gb, это минимальная конфигурация по диску для моих клиентов). В случае, если заранее известен минимальный объём диска — приемника, имеет смысл подгонять разделы под него. Своп рекомендую размечать сразу за корнем диска, /home сразу за свопом, чтобы в случае ресайза не «возить их по диску в консоли», а сделать изящно одной командой. Устанавливаем локаль, имя пользователя, пароль, hostname и заходим в новоиспеченный Linux. Для продолжения потребуются пакеты x11vnc, ssh, rsync, openvpn, mc (обожаю mcedit, он мне родной, как нортон из девяностых).

В базу я на свой вкус добавил skype, icedove (thunderbird), iceweasel(firefox), chromium-browser, rdesktop калькулятор, монитор ресурсов, viber, libre office, wine и пару windows-приложений (гореть мне, конечно, за это в аду, но аналогов нет и не предвидится). Настраиваем медленно и неторопливо всё это дело. Проверяем, что всё запускается и работает.

Настраиваем vpn. У меня сеть распределенная, по два-три компьютера на одну геолокацию, больше 50 локаций по России, не наездишься. Создаем ssh-ключ к серверу и на сервере к клиенту (кому надо вводить эти пароли, подробности, к примеру, тут). На сервере создаем каталог безусловной синхронизации (для меня это рабочие скрипты, ключи openvpn, клиентский cron, служебные скрипты на python, бинарники С++). В рабочем примере это /var/sync/in, /var/sync/in/cron, /var/sync/out. В out будут логи и любая нужная нам информация с клиентов: скриншоты, отчеты по процессам, итд. В in как раз и будут скрипты синхронизации, задания cron, скрипты хартбитов для мониторинга, многочисленные конфиги системных служб (того же cups или openvpn).

Подготовка всего этого дела к тиражированию займет не многим больше времени, чем установка системы одному пользователю, но тщательная проработка деталей может существенно уменьшить время, которое админ в будущем потратит на скрипты «допиливающие» все образы в бою. Настроим openvpn на клиенте и убедимся, что пользовательский ключ[и] работа[ею]т. Не лишним будет и настроить grub2.

• Хинт1: Хорошо, когда хостнейм, ip в openvpn и сертификат юзера содержат свой уникальный id, к примеру user10.key, x.y.z.10 и vladivostok_10 в качестве хостнейма;
• Хинт2: Хорошо, когда копии этих файлов лежат под рукой, скажем /var/sync/hostname, /var/sync/id, /var/sync/location;
• Хинт3: Зарезервировать 5-10 адресов под незарегистрированных пользователей тоже будет полезным.

Файлы из Хинт2 мы создавать не будем сознательно, по их отсутствию будет понятно, когда «новенькие» подключатся к нашему vpn.

Итак, всё шуршит, офис работает, калькулятор запускается, для rdp с сервером приложений уже есть ярлычок на рабочем столе.

Пришло время делать образ.

Разрешу себе отвлечься. Способов сделать образ с готовой системой под тираж я перепробовал немало. Данная статья не претендует на звание лучшего способа, скажу лишь, что способ лучший для меня и очень кратко прокомментирую другие способы и их минусы.

Clonezilla — отличная вещь, но в интерактивном режиме вводит в ступор любого эникейщика за триста миль от админа.
dd if=/dev/sda of=img.img — волшебная вещь, но вместе с данными мы получим мусор с пустой части диска, объём и скорость метода ужасают.

Norton ghost — не поддерживает ext4.

Partition copy из gparted — классная вещь, но, увы, тоже не для начинающих.

Я долго спрашивал себя, каким я вижу идеальное развертывание. Тут мы подходим к теме статьи, от которой уже порядком отвлеклись.

• Образ должен помещаться на небольшой (в моем случае 2Гб) флешке;
• Образ должен ставиться нажатием одной-двух кнопок;
• После развертывания образ сам должен синхронизироваться и «докладывать» админу, что новая машина «в строю»;
• Регистрация новой машины не должна занимать много времени;
• (Важно!) Образ скорее всего будет записан на флешку из-под windows непрофессионалом по инструкции;
• (АрхиВажно!) Образ скорее всего будет развиваться версионно, и его нужно периодически доделывать и быстро распространять.

Пришлось изобретать маленький велосипед, а точнее — писать разворачивающий скрипт. Для вышеупомянутых задач был выбран дистрибутив PartedMagic. Для заворачивания образа потребуется unetbootin+partedmagic или любой live-cd(usb) с линуксом и tar+b[g]zip на борту. Будем считать, что образ мы загрузили PartedMagic «run from ram» и флешка монтирована в /media/sdb1 (FAT32).

• Ахтунг1 Напоминаю, раздел файла в fat32 не должен быть более 4Гб, следите за объёмом образа или выбирайте ext4 раздел.
• Ахтунг2 NTFS раздел флешки под linux хоть и работает, но забирает огромное кол-во процессорного времени.

После загрузки монтируем наш диск (скорее всего /dev/sda1) и жмём прямо с него всю нашу систему, не забываем и про /home раздел:

Затем сделаем архив со всем содержимым нашего диска:

Тоже самое и для /home раздела:

Затем дампим таблицу разделов в файл на нашу суперфлешку:

Таким образом, на флешке у нас появятся архивы и файл с таблицей разделов эталонного образа.

Ну и на сладкое. Ниже скрипт c говорящим названием, который собирался по частям с разных уголков интернета буквально по строчке.

Комментарии автора прямо в тексте скрипта. Ничего сверхъестественного, просто как на уроке информатики, однако отлаживался с кровавыми слезами, разок даже убил домашнюю систему флешкой с этим скриптом. Не рекомендую оставлять как есть, т.к. это его безусловная неинтерактивная версия.

cat /pmagic/pmodules/scripts/kill_your_hdd_data.sh (путь для автозагрузочного скрипта в PartedMagic)

Вместо эпилога:

Данный метод используется в Urban Software для заливки информационных сенсорных киосков c веб-приложениями под управлением linux. Чаще всего это бесклавиатурные машины, которые разворачиваются десятками вдали от цивилизации нашей техподдержки, поэтому важно изначально не создать проблем при их мониторинге и вводе в работу.

Источник