info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[1/2] notes on Debian Installer vs. generic system tools
50 views
Skip to first unread message
Ivan Shmakov
Jan 17, 2013, 4:49:12 PM1/17/13
to
Одним из способов установки Debian GNU/Linux на новую систему
(или же носитель) является загрузка специализированной
«системы-установщика», — Debian Installer (D-I.) В некоторых
случаях, e. g., при наличии только лишь загрузочного носителя с
D-I «под рукой», такой способ более чем оправдан, однако, можно
поспорить, что использование установленной Debian-системы
«общего назначения» взамен специализированной D-I может быть
удобнее, и, в некотором смысле, несет несколько меньший риск
получения в итоге скомпрометированной системы.
В качестве аргументов, ниже разобрана последовательность «шагов»
D-I, и указаны в известной степени равнозначные им действия с
точки зрения системы общего назначения. (Предполагается, что на
такую систему установлены все необходимые инструменты.)
Поскольку, очевидно, в процессе потребуется упомянуть и
некоторые особенности работы самой D-I-системы, предлагаемый
материал может оказаться полезным и тем, кто не предполагает
отказываться от использования D-I.
Отметим, что использование системы общего назначения
предполагает возможность подключения к ней целевого носителя.
Судя по личному опыту автора, вполне допустимо подключать НЖМД
интерфейса SATA к системе во время работы последней. (Стоит
отметить, что конструкция разъемов SATA проектировалась с учетом
возможности «горячего подключения.») Разумеется, можно
воспользоваться и многочисленными адаптерами USB to SATA (IDE) —
что, разумеется, более безопасно.
При подготовке данного материала автор использовал D-I для
Debian GNU/Linux 6.0.6. Не исключено, что D-I ожидаемого в
недалеком будущем Debian 7.0 будет существенно отличаться от
описываемого ниже.
(Напротив, в примерах команд, приводимых для случая установки с
использованием системы общего назначения, упоминаются именно
testing и Wheezy.)
Данная редакция является «рабочим черновиком»; многие из данных
в примерах командных строк не были проверены автором в сколь
угодно близкой к приведенной форме.
© 2013 Иван Шмаков <onei...@gmail.com>
Данный текст является свободным произведением и распространяется
на условиях лицензии Creative Commons Attribution-ShareAlike
(CC BY-SA.)
Получение образа D-I
Пожалуй, самым первым шагом при использовании D-I является
получение содержащего оный образа, включающего, как правило, и
некоторый набор пакетов. Наиболее «современным» способом
загрузки (позволяющим, помимо прочего, поучаствовать в
распространении образов всем желающим) является, несомненно,
использование равноранговой сети BitTorrent. E. g., используя
aria2c(1):
$ aria2c -- \
http://cdimage.debian.org/debian-cd/6.0.6/amd64/bt-cd/debian-6.0.6-amd64-netinst.iso.torrent
Учитывая, что большую часть образа составляет некий набор
предназначенных для установки на целевую систему пакетов (за
исключением, пожалуй, образов типа «businesscard», таких пакетов
не содержащих вовсе), можно было бы пожелать загрузить эти
пакеты с Debian-зеркал «общего назначения», загрузив с
http://cdimage.debian.org/ лишь только собственно D-I (и,
возможно, некие служебные данные.) Такую возможность
предоставляет Jigdo; e. g.:
$ cat < ~/.jigdo-lite
jigdo=''
debianMirror='http://http.debian.net/debian/'
nonusMirror=''
tmpDir='.'
jigdoOpts='--cache jigdo-file-cache.db'
wgetOpts='--passive-ftp --dot-style=mega --continue --timeout=30'
scanMenu=''
$ wget -x -- \
cdimage.debian.org/debian-cd/6.0.6/amd64/jigdo-cd/debian-6.0.6-amd64-netinst.jigdo \
cdimage.debian.org/debian-cd/6.0.6/amd64/jigdo-cd/debian-6.0.6-amd64-netinst.template
$ jigdo-lite --noask \
cdimage.debian.org/debian-cd/6.0.6/amd64/jigdo-cd/debian-6.0.6-amd64-netinst.jigdo
(При использовании HTTP-proxy, переменные окружения http_proxy=,
etc., должны быть, очевидно, установлены нужным образом.)
Наконец, можно получить образ непосредственно с зеркала —
возможность, которой не следует злоупотреблять. (Наилучшим
решением, пожалуй, будет получение лишь образов «businesscard»
и, возможно, «netinst.»)
Целостность образов
Загруженный как описано выше файл будет, как правило, в точности
соответствовать выпущенному проектом Debian. Однако, тем из
нас, кто привык уделять чуть больше внимания вопросам
«информационной безопасности», этому факту наверняка потребуется
подтверждение.
Проверить целостность образа можно по файлам *SUM, размещаемым
также на несущих установочные образы зеркалах Debian. E. g.:
$ wget -x -- \
cdimage.debian.org/debian-cd/6.0.6/amd64/iso-cd/SHA256SUM
$ grep -F -- debian-6.0.6-amd64-netinst.iso \
cdimage.debian.org/debian-cd/6.0.6/amd64/iso-cd/SHA256SUM \
| sha256sum -c
debian-6.0.6-amd64-netinst.iso: OK
$
Ясно, однако, что файлы *SUMS сами по себе могут быть повреждены
(подменены) при передаче. Для их проверки, в свою очередь,
можно использовать файлы электронной цифровой подписи (.sign)
OpenPGP (GnuPG.)
Здесь, однако, есть небольшая особенность: известно, что
открытые ключи Debian-архива и разработчиков Debian можно найти
в самой системе (пакеты debian-archive-keyring и debian-keyring,
соответственно; первый из этих пакетов почти наверняка окажется
установлен в конкретной Debian-системе, поскольку является
Priority: important.) Так, для проверки полученного с
произвольного зеркала .dsc-файла можно было бы выполнить, e. g.:
$ gpg --verify --keyring=/usr/share/keyrings/debian-keyring.gpg -- \
http.debian.net/debian/pool/main/h/hello/hello_2.8-2.dsc
Напротив, насколько известно автору, для проверки «подлинности»
*SUMS-файлов потребуется получить соответствующий ключ из
«незащищенного» источника (см., e. g., [1].)
[1] http://www.debian.org/CD/verify
При использовании для установки системы на целевой носитель
debootstrap(8), проверка целостности выполняется автоматически,
с использованием открытых ключей пакета debian-archive-keyring
установленной системы.
Следующим шагом, образ требуется записать на подходящий носитель
(CD, DVD+R, USB Flash, etc.), однако этот вопрос выходит за
рамки данных заметок.
Адаптация к окружению
Первые вопросы, которыми «встречает» пользователя D-I-система
будут следующие:
• параметры ядра и D-I — предпочтение автора остается за
«expert-режимом», что транслируется, по большему счету, в
передачу ядру (а через него — D-I и Debconf) опции
priority=low (AKA DEBIAN_PRIORITY=low), что заставляет Debconf
задать пользователю некоторые дополнительные вопросы, для
которых в противном случае будут выбраны умолчания; (автор
припоминает, что здесь же можно указать и расположение
т. н. preseed-файла, содержащего ответы на вопросы Debconf;
использование такого файла может значительно сократить время,
проводимое оператором при установке системы — вне зависимости
от использования D-I — однако, здесь не рассматривается);
• выбор локали («языка») — включая выбор страны, дополнительных
локалей подлежащих установке (подобно:
# dpkg-reconfigure locales; впрочем, на взгляд автора, лучше
сразу установить пакет locales-all вместо locales — при
установке «типичной Desktop-системы», FSVO, вклад данного
пакета в общее занятое «дисковое» пространство будет
неощутим), и, наконец, локали по-умолчанию для целевой системы
(/etc/default/locale);
• выбор раскладки клавиатуры;
• выбор дополнительных «модулей D-I» (пакетов .udeb) для
загрузки с установочного носителя (модули openssh-client-udeb
и parted-udeb вполне могут оказаться полезными);
• параметры сетевого интерфейса (с возможностью выбрать
использование DHCP) — будут продублированы в interfaces(5)
целевой системы;
• назначения пароля привилегированному пользователя целевой
системы; создание непривилегированного пользователя; (IOW,
passwd(1), adduser(8));
• настройка часового пояса (# dpkg-reconfigure tzdata);
• определение «дисковых» накопителей.
Ясно, что все эти вопросы не актуальны для установщика,
работающего под управлением (уже настроенной) системы общего
назначения. Однако, как отмечено выше, через эти вопросы
выполняется настройка также и целевой системы. В случае
установки с использованием системы общего назначения, впрочем,
сверяться с уже существующей конфигурацией куда как легче. Так,
для настройки interfaces(5) (предполагая, что корневая ФС
целевой системы подключена к /mnt), может подойти одна из
следующих команд:
# vim.tiny -- /mnt/etc/network/interfaces /etc/network/interfaces
# zile /mnt/etc/network/interfaces /etc/network/interfaces
Создание таблицы разделов
Пожалуй, один из наиболее ответственных этапов установки —
создание таблицы разделов и, возможно (или же, скорее, — крайне
желательно) настройка LVM на целевом носителе.
Автор предлагает следующую схему распределения пространства:
• использование таблицы разделов GPT — с одной стороны, это
позволяет избавится от некоторых «наследственных болезней» MBR
(в т. ч. использования лишенной в настоящее время смысла
CHS-адресации, и необходимости т. н. «extended»-разделов), а
также, потенциально, получить возможность создания до по
меньшей мере 128 разделов (разумеется, с поправкой на то, что
Linux поддерживает не более 15); с другой, использование GPT
необходимо для загрузки системы некоторыми из современных
BIOS, а также для систем, использующих вместо последнего UEFI
(особенности установки для последнего случая, впрочем, не
рассматриваются в настоящей редакции данного материала);
• порядка 1 MiB выделяется под раздел «BIOS GRUB» — в котором
хранится основная часть загрузчика GRUB; (при использовании
MBR, для этого используется следующая непосредственно за MBR
часть нулевого цилиндра, не доступная для распределения);
• (1% ÷ 5% от общей емкости носителя (но, пожалуй, в пределах
1 GiB ÷ 16 GiB), отводится под swap-раздел; такой раздел
является своеобразной «страховкой» на случай, если некие
процессы, по какой-либо причине, захотят «присвоить» себе
значительные объемы виртуальной памяти — необходимость
обращения к swap замедлит процесс выделения памяти и,
возможно, даст администратору время для принятия решительных
мер; (к сожалению, эвристика OOM Killer изредка дает сбои;
автор припоминает случай, когда оный попытался досрочно
завершить init-процесс — с очевидными последствиями);
• порядка 192 MiB ÷ 512 MiB отводится под отдельный /boot — тем
самым, сохраняется возможность переустановки загрузчика (GRUB)
даже при отсутствии доступа к LVM (e. g., с использованием
системы, отличной от GNU/Linux); для такого раздела можно, при
желании, использовать даже «упрощенную» ФС, такую, как, e. g.,
FAT32;
• некоторый объем, от порядка 512 MiB, выделяется как
«стратегический резерв» — создается неиспользуемый раздел, или
же это пространство не распределяется вовсе; такой резерв
может быть использован, e. g., если совершенно необходимо
создать отдельную ФС, но LVM использовать по каким-то причинам
нельзя (e. g., по причине сбоя LVM — для сбора на эту ФС
критической информации о состоянии LVM), или же для создания
временного физического тома LVM при заполненности основных (до
переноса данных, или удаления более ненужных), etc.;
• оставшееся пространство распределяется между двумя или более
физическими томами LVM; использование двух томов позволит, при
необходимости, выполнить «дефрагментацию» логических томов
через pvmove(8); (использование этой возможности для переноса
данных в пределах одного тома не допускается.)
NB: дальнейшие действия предполагают инициализацию служебных
областей некоторого носителя информации (НЖМД, ТТН, etc.)
Следует быть предельно внимательным, чтобы выполнить команды
в отношении нужного носителя, а не, к примеру, носителя, на
котором размещается основная система. Выяснить имена
/dev-файлов, соответствующих носителю (или носителям),
используемым основной системой, можно, в частности,
следующими командами:
# pvs
# parted /dev/sdQ unit mib print
$ cat -- /proc/mounts /proc/swaps
Ясно, что эти имена ни в коем случае не должны появится в
командах, подобных приводимым ниже.
Предлагаемую разметку можно реализовать подобно (предполагая
емкость целевого носителя порядка 500 GB и «чистую» таблицу
разделов GPT; команду # parted DEV unit mib print mklabel gpt
выполнить по-необходимости):
# parted /dev/sdX \
unit mib \
mkpart biosgrub 0% 1M set 1 bios_grub on \
mkpart boot 1M 512M \
mkpart swap 512M 11G set 3 swap on \
mkpart res-1 11G 16G \
mkpart small-1 16G 32G \
mkpart medium-1 32G 64G \
mkpart large-2 64G 128G \
mkpart large-3 128G 192G \
mkpart large-4 192G 256G \
mkpart large-5 256G 320G \
mkpart large-6 320G 384G \
mkpart medium-12 384G 416G \
mkpart medium-13 416G 448G \
mkpart tail 448G 100%
(Ясно, что параметры parted(8), подобные приведенным выше, можно
сформировать и тривиальным Shell-кодом.)
Проверить корректность созданной таблицы разделов можно
используя # parted /dev/sdX unit mib print (или же, как вариант,
unit s print — чтобы удостоверится, что границы разделов
выровнены по размеру физического блока носителя — 8 «секторов»
для НЖМД, 2097152 для ТТН, etc.)
На этом этапе также можно инициализировать swap-раздел и ФС
/boot, e. g.:
# mkswap /dev/sdX3
# mke2fs -j -- /dev/sdX2
Далее, чтобы избежать привязки к конкретному имени файла
раздела, несущего swap и ФС /boot, извлечем их UUID:
# blkid -- /dev/sdX[23]
/dev/sdX2: UUID="7bfad579-8e0f-4ef7-bc58-fad76f5fc83d" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdX3: UUID="d66d7d66-4382-4019-b420-1c47c29f7263" TYPE="swap"
#
Данные идентификаторы подходят как для «явного» использования в
команде # mount -U (# swapon -U), так и для fstab(5). Отметим,
однако, что при создании копии ФС на уровне образа (e. g.,
dd(1), # cp -- /dev/sdX2 /dev/sdYY, etc.) UUID сохраняется и для
различения ФС (исходной и ее копии) крайне желательно его
переназначить после копирования, e. g.:
# tune2fs -U random -- /dev/sdYY
--
FSF associate member #7257
(или же носитель) является загрузка специализированной
«системы-установщика», — Debian Installer (D-I.) В некоторых
случаях, e. g., при наличии только лишь загрузочного носителя с
D-I «под рукой», такой способ более чем оправдан, однако, можно
поспорить, что использование установленной Debian-системы
«общего назначения» взамен специализированной D-I может быть
удобнее, и, в некотором смысле, несет несколько меньший риск
получения в итоге скомпрометированной системы.
В качестве аргументов, ниже разобрана последовательность «шагов»
D-I, и указаны в известной степени равнозначные им действия с
точки зрения системы общего назначения. (Предполагается, что на
такую систему установлены все необходимые инструменты.)
Поскольку, очевидно, в процессе потребуется упомянуть и
некоторые особенности работы самой D-I-системы, предлагаемый
материал может оказаться полезным и тем, кто не предполагает
отказываться от использования D-I.
Отметим, что использование системы общего назначения
предполагает возможность подключения к ней целевого носителя.
Судя по личному опыту автора, вполне допустимо подключать НЖМД
интерфейса SATA к системе во время работы последней. (Стоит
отметить, что конструкция разъемов SATA проектировалась с учетом
возможности «горячего подключения.») Разумеется, можно
воспользоваться и многочисленными адаптерами USB to SATA (IDE) —
что, разумеется, более безопасно.
При подготовке данного материала автор использовал D-I для
Debian GNU/Linux 6.0.6. Не исключено, что D-I ожидаемого в
недалеком будущем Debian 7.0 будет существенно отличаться от
описываемого ниже.
(Напротив, в примерах команд, приводимых для случая установки с
использованием системы общего назначения, упоминаются именно
testing и Wheezy.)
Данная редакция является «рабочим черновиком»; многие из данных
в примерах командных строк не были проверены автором в сколь
угодно близкой к приведенной форме.
© 2013 Иван Шмаков <onei...@gmail.com>
Данный текст является свободным произведением и распространяется
на условиях лицензии Creative Commons Attribution-ShareAlike
(CC BY-SA.)
Получение образа D-I
Пожалуй, самым первым шагом при использовании D-I является
получение содержащего оный образа, включающего, как правило, и
некоторый набор пакетов. Наиболее «современным» способом
загрузки (позволяющим, помимо прочего, поучаствовать в
распространении образов всем желающим) является, несомненно,
использование равноранговой сети BitTorrent. E. g., используя
aria2c(1):
$ aria2c -- \
http://cdimage.debian.org/debian-cd/6.0.6/amd64/bt-cd/debian-6.0.6-amd64-netinst.iso.torrent
Учитывая, что большую часть образа составляет некий набор
предназначенных для установки на целевую систему пакетов (за
исключением, пожалуй, образов типа «businesscard», таких пакетов
не содержащих вовсе), можно было бы пожелать загрузить эти
пакеты с Debian-зеркал «общего назначения», загрузив с
http://cdimage.debian.org/ лишь только собственно D-I (и,
возможно, некие служебные данные.) Такую возможность
предоставляет Jigdo; e. g.:
$ cat < ~/.jigdo-lite
jigdo=''
debianMirror='http://http.debian.net/debian/'
nonusMirror=''
tmpDir='.'
jigdoOpts='--cache jigdo-file-cache.db'
wgetOpts='--passive-ftp --dot-style=mega --continue --timeout=30'
scanMenu=''
$ wget -x -- \
cdimage.debian.org/debian-cd/6.0.6/amd64/jigdo-cd/debian-6.0.6-amd64-netinst.jigdo \
cdimage.debian.org/debian-cd/6.0.6/amd64/jigdo-cd/debian-6.0.6-amd64-netinst.template
$ jigdo-lite --noask \
cdimage.debian.org/debian-cd/6.0.6/amd64/jigdo-cd/debian-6.0.6-amd64-netinst.jigdo
(При использовании HTTP-proxy, переменные окружения http_proxy=,
etc., должны быть, очевидно, установлены нужным образом.)
Наконец, можно получить образ непосредственно с зеркала —
возможность, которой не следует злоупотреблять. (Наилучшим
решением, пожалуй, будет получение лишь образов «businesscard»
и, возможно, «netinst.»)
Целостность образов
Загруженный как описано выше файл будет, как правило, в точности
соответствовать выпущенному проектом Debian. Однако, тем из
нас, кто привык уделять чуть больше внимания вопросам
«информационной безопасности», этому факту наверняка потребуется
подтверждение.
Проверить целостность образа можно по файлам *SUM, размещаемым
также на несущих установочные образы зеркалах Debian. E. g.:
$ wget -x -- \
cdimage.debian.org/debian-cd/6.0.6/amd64/iso-cd/SHA256SUM
$ grep -F -- debian-6.0.6-amd64-netinst.iso \
cdimage.debian.org/debian-cd/6.0.6/amd64/iso-cd/SHA256SUM \
| sha256sum -c
debian-6.0.6-amd64-netinst.iso: OK
$
Ясно, однако, что файлы *SUMS сами по себе могут быть повреждены
(подменены) при передаче. Для их проверки, в свою очередь,
можно использовать файлы электронной цифровой подписи (.sign)
OpenPGP (GnuPG.)
Здесь, однако, есть небольшая особенность: известно, что
открытые ключи Debian-архива и разработчиков Debian можно найти
в самой системе (пакеты debian-archive-keyring и debian-keyring,
соответственно; первый из этих пакетов почти наверняка окажется
установлен в конкретной Debian-системе, поскольку является
Priority: important.) Так, для проверки полученного с
произвольного зеркала .dsc-файла можно было бы выполнить, e. g.:
$ gpg --verify --keyring=/usr/share/keyrings/debian-keyring.gpg -- \
http.debian.net/debian/pool/main/h/hello/hello_2.8-2.dsc
Напротив, насколько известно автору, для проверки «подлинности»
*SUMS-файлов потребуется получить соответствующий ключ из
«незащищенного» источника (см., e. g., [1].)
[1] http://www.debian.org/CD/verify
При использовании для установки системы на целевой носитель
debootstrap(8), проверка целостности выполняется автоматически,
с использованием открытых ключей пакета debian-archive-keyring
установленной системы.
Следующим шагом, образ требуется записать на подходящий носитель
(CD, DVD+R, USB Flash, etc.), однако этот вопрос выходит за
рамки данных заметок.
Адаптация к окружению
Первые вопросы, которыми «встречает» пользователя D-I-система
будут следующие:
• параметры ядра и D-I — предпочтение автора остается за
«expert-режимом», что транслируется, по большему счету, в
передачу ядру (а через него — D-I и Debconf) опции
priority=low (AKA DEBIAN_PRIORITY=low), что заставляет Debconf
задать пользователю некоторые дополнительные вопросы, для
которых в противном случае будут выбраны умолчания; (автор
припоминает, что здесь же можно указать и расположение
т. н. preseed-файла, содержащего ответы на вопросы Debconf;
использование такого файла может значительно сократить время,
проводимое оператором при установке системы — вне зависимости
от использования D-I — однако, здесь не рассматривается);
• выбор локали («языка») — включая выбор страны, дополнительных
локалей подлежащих установке (подобно:
# dpkg-reconfigure locales; впрочем, на взгляд автора, лучше
сразу установить пакет locales-all вместо locales — при
установке «типичной Desktop-системы», FSVO, вклад данного
пакета в общее занятое «дисковое» пространство будет
неощутим), и, наконец, локали по-умолчанию для целевой системы
(/etc/default/locale);
• выбор раскладки клавиатуры;
• выбор дополнительных «модулей D-I» (пакетов .udeb) для
загрузки с установочного носителя (модули openssh-client-udeb
и parted-udeb вполне могут оказаться полезными);
• параметры сетевого интерфейса (с возможностью выбрать
использование DHCP) — будут продублированы в interfaces(5)
целевой системы;
• назначения пароля привилегированному пользователя целевой
системы; создание непривилегированного пользователя; (IOW,
passwd(1), adduser(8));
• настройка часового пояса (# dpkg-reconfigure tzdata);
• определение «дисковых» накопителей.
Ясно, что все эти вопросы не актуальны для установщика,
работающего под управлением (уже настроенной) системы общего
назначения. Однако, как отмечено выше, через эти вопросы
выполняется настройка также и целевой системы. В случае
установки с использованием системы общего назначения, впрочем,
сверяться с уже существующей конфигурацией куда как легче. Так,
для настройки interfaces(5) (предполагая, что корневая ФС
целевой системы подключена к /mnt), может подойти одна из
следующих команд:
# vim.tiny -- /mnt/etc/network/interfaces /etc/network/interfaces
# zile /mnt/etc/network/interfaces /etc/network/interfaces
Создание таблицы разделов
Пожалуй, один из наиболее ответственных этапов установки —
создание таблицы разделов и, возможно (или же, скорее, — крайне
желательно) настройка LVM на целевом носителе.
Автор предлагает следующую схему распределения пространства:
• использование таблицы разделов GPT — с одной стороны, это
позволяет избавится от некоторых «наследственных болезней» MBR
(в т. ч. использования лишенной в настоящее время смысла
CHS-адресации, и необходимости т. н. «extended»-разделов), а
также, потенциально, получить возможность создания до по
меньшей мере 128 разделов (разумеется, с поправкой на то, что
Linux поддерживает не более 15); с другой, использование GPT
необходимо для загрузки системы некоторыми из современных
BIOS, а также для систем, использующих вместо последнего UEFI
(особенности установки для последнего случая, впрочем, не
рассматриваются в настоящей редакции данного материала);
• порядка 1 MiB выделяется под раздел «BIOS GRUB» — в котором
хранится основная часть загрузчика GRUB; (при использовании
MBR, для этого используется следующая непосредственно за MBR
часть нулевого цилиндра, не доступная для распределения);
• (1% ÷ 5% от общей емкости носителя (но, пожалуй, в пределах
1 GiB ÷ 16 GiB), отводится под swap-раздел; такой раздел
является своеобразной «страховкой» на случай, если некие
процессы, по какой-либо причине, захотят «присвоить» себе
значительные объемы виртуальной памяти — необходимость
обращения к swap замедлит процесс выделения памяти и,
возможно, даст администратору время для принятия решительных
мер; (к сожалению, эвристика OOM Killer изредка дает сбои;
автор припоминает случай, когда оный попытался досрочно
завершить init-процесс — с очевидными последствиями);
• порядка 192 MiB ÷ 512 MiB отводится под отдельный /boot — тем
самым, сохраняется возможность переустановки загрузчика (GRUB)
даже при отсутствии доступа к LVM (e. g., с использованием
системы, отличной от GNU/Linux); для такого раздела можно, при
желании, использовать даже «упрощенную» ФС, такую, как, e. g.,
FAT32;
• некоторый объем, от порядка 512 MiB, выделяется как
«стратегический резерв» — создается неиспользуемый раздел, или
же это пространство не распределяется вовсе; такой резерв
может быть использован, e. g., если совершенно необходимо
создать отдельную ФС, но LVM использовать по каким-то причинам
нельзя (e. g., по причине сбоя LVM — для сбора на эту ФС
критической информации о состоянии LVM), или же для создания
временного физического тома LVM при заполненности основных (до
переноса данных, или удаления более ненужных), etc.;
• оставшееся пространство распределяется между двумя или более
физическими томами LVM; использование двух томов позволит, при
необходимости, выполнить «дефрагментацию» логических томов
через pvmove(8); (использование этой возможности для переноса
данных в пределах одного тома не допускается.)
NB: дальнейшие действия предполагают инициализацию служебных
областей некоторого носителя информации (НЖМД, ТТН, etc.)
Следует быть предельно внимательным, чтобы выполнить команды
в отношении нужного носителя, а не, к примеру, носителя, на
котором размещается основная система. Выяснить имена
/dev-файлов, соответствующих носителю (или носителям),
используемым основной системой, можно, в частности,
следующими командами:
# pvs
# parted /dev/sdQ unit mib print
$ cat -- /proc/mounts /proc/swaps
Ясно, что эти имена ни в коем случае не должны появится в
командах, подобных приводимым ниже.
Предлагаемую разметку можно реализовать подобно (предполагая
емкость целевого носителя порядка 500 GB и «чистую» таблицу
разделов GPT; команду # parted DEV unit mib print mklabel gpt
выполнить по-необходимости):
# parted /dev/sdX \
unit mib \
mkpart biosgrub 0% 1M set 1 bios_grub on \
mkpart boot 1M 512M \
mkpart swap 512M 11G set 3 swap on \
mkpart res-1 11G 16G \
mkpart small-1 16G 32G \
mkpart medium-1 32G 64G \
mkpart large-2 64G 128G \
mkpart large-3 128G 192G \
mkpart large-4 192G 256G \
mkpart large-5 256G 320G \
mkpart large-6 320G 384G \
mkpart medium-12 384G 416G \
mkpart medium-13 416G 448G \
mkpart tail 448G 100%
(Ясно, что параметры parted(8), подобные приведенным выше, можно
сформировать и тривиальным Shell-кодом.)
Проверить корректность созданной таблицы разделов можно
используя # parted /dev/sdX unit mib print (или же, как вариант,
unit s print — чтобы удостоверится, что границы разделов
выровнены по размеру физического блока носителя — 8 «секторов»
для НЖМД, 2097152 для ТТН, etc.)
На этом этапе также можно инициализировать swap-раздел и ФС
/boot, e. g.:
# mkswap /dev/sdX3
# mke2fs -j -- /dev/sdX2
Далее, чтобы избежать привязки к конкретному имени файла
раздела, несущего swap и ФС /boot, извлечем их UUID:
# blkid -- /dev/sdX[23]
/dev/sdX2: UUID="7bfad579-8e0f-4ef7-bc58-fad76f5fc83d" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdX3: UUID="d66d7d66-4382-4019-b420-1c47c29f7263" TYPE="swap"
#
Данные идентификаторы подходят как для «явного» использования в
команде # mount -U (# swapon -U), так и для fstab(5). Отметим,
однако, что при создании копии ФС на уровне образа (e. g.,
dd(1), # cp -- /dev/sdX2 /dev/sdYY, etc.) UUID сохраняется и для
различения ФС (исходной и ее копии) крайне желательно его
переназначить после копирования, e. g.:
# tune2fs -U random -- /dev/sdYY
--
FSF associate member #7257
Ivan Shmakov
Jan 17, 2013, 4:50:18 PM1/17/13
to
Формирование конфигурации LVM
Стоит, пожалуй, отметить, что создание таблицы разделов,
конфигурации LVM, и формирование ФС на разделах и логических
томах — представлены в D-I единым этапом. Этот же этап включает
и подготовку подходящего fstab(5) для целевой системы. С точки
зрения использования системы общего назначения, однако, эти
этапы разделены, и в данном разделе мы рассмотрим следующий из
них.
Инициализировать физические тома LVM и объединить их в группу
можно подобно (предполагая именем целевой системы
bakau.example.org; раздел №14 «tail» из примера parted(8) выше
оставляем в качестве еще одного, весьма скромного, резерва):
# pvcreate -- /dev/sdX{[5-9],1[0-3]}
…
# vgcreate -- vgbakau-i /dev/sdX{[5-9],1[0-3]}
…
#
Разумеется, вовсе не обязательно объединять в группу (или
группы) все физические тома данного носителя, или даже
инициализировать их. Однако, эти действия необходимы для
«появления» соответствующего пространства в списках # vgs и
# pvs (соответственно.)
Определенный интерес может представлять, однако, выделение
несущих системные ФС (/, /var) томов (и, следовательно, их
будущих «мгновенных копий», или snapshots, если таковые
потребуются) в отдельную группу. Отведем под нее GPT-раздел №6
«medium-1» и изменим вызов vgcreate(8) выше на:
# vgcreate -- vgbakau-sys-i /dev/sdX6
…
# vgcreate -- vgbakau-u-i /dev/sdX{[57-9],1[0-3]}
…
#
Включение в имя группы имени системы необходимо ровно по той
причине, что в противном случае, — при использовании имен вида
vg00, vg01, …, — группа vg00 вполне может оказаться существующей
на /установочной/ системе, так что /устанавливаемой/ придется
довольствоваться vg01. Также, для восстановления системы после
сбоя, может потребоваться подключить ее (системный) носитель к
другой системе, и представляется весьма желательным, чтобы имена
групп LVM этого носителя заведомо отличались от таковых для
носителей /восстанавливающей/ системы.
OTOH, объединение в одну группу физических томов, размещенных на
различных физических носителях, хотя и возможно, может оказаться
не лучшей идеей. (В случае, если рассматриваемая группа будет
содержать «системные» разделы, это особенно нежелательно,
поскольку любое обращение к логическим томам группы, а значит и
загрузка системы, окажутся невозможными при недоступности любого
из таких физических носителей — вне зависимости от того,
размещены ли на нем фактически данные искомых логических томов.)
Создание логических томов LVM и инициализация файловых систем
Создадим теперь логические тома LVM и инициализируем на них
нужные нам системные и пользовательские ФС, для чего
воспользуемся следующим несложным Shell-кодом:
# cat < mklv.sh
#!/bin/bash
set -e -x
## Usage:
## bash mklv.sh VOLUME-GROUP PHYSICAL-VOLUME [LOGICAL-VOLUME,SIZE]...
## Example:
## bash mklv.sh vgfoo-i /dev/sdXX lvbar,14G lvqux,42G
vg=${1}
pv=${2}
shift 2
for i ; do
lv=${i%%,*}
sz=${i#*,}
f=/dev/${vg}/${lv}.new
lvcreate -L "$sz" -n "$lv" "$vg" "$pv"
mke2fs -j -- "$f" \
|| break
lvrename "$f" "${f%.new}" \
|| break
done
vgs -- "$vg"
# bash mklv.sh vgbakau-i /dev/sdX7 lvroot,8G lvvar,4G lvhome,48G
…
#
Или же, если системные ФС вынесены на тома отдельной группы:
# bash mklv.sh vgbakau-sys-i /dev/sdX6 lvroot,8G lvvar,4G
…
# bash mklv.sh vgbakau-u-i /dev/sdX7 lvhome,56G
…
#
Вспомним, однако, что почти наверняка существенную часть
имеющегося на носителе пространства займут данные, которые
несложно тем или иным способом восстановить (получив с
HTTP-сервера, через сеть BitTorrent, или иначе). Создание
резервных копий этих данных не является столь уж важной задачей,
поэтому под их хранение можно выделить отдельную ФС:
# bash mklv.sh vgbakau-u-i /dev/sdX8 lvstorage,56G
…
#
которую можно сразу же расширить на соседний физический том:
# lvextend -L 120G -- /dev/vgbakau-u-i/lvstorage /dev/sdX8 /dev/sdX9
…
# resize2fs -- /dev/vgbakau-u-i/lvstorage
…
#
Впоследствии, для этой ФС можно будет реализовать особый
регламент резервирования.
(Возможность изменять размеры логических томов, наряду с
возможностью «на горячую» увеличивать размеры некоторых ФС,
включая Ext3+, является, по мнению автора, ключевой при
управлении долговременными носителями информации в современном
системном администрировании.)
Можно отметить, кроме того, что создание резервных копий для
/var/cache также может следовать иным, отличным от таковых для
/var, правилам, что может побудить к созданию еще одной ФС (на
которой, при необходимости, можно разместить и такие данные,
как, e. g., кэш Squid):
# bash mklv.sh vgbakau-u-i /dev/sdX9 lvvarcache,7G
Установка «основы» системы
Подключим созданные ФС, начиная с корневой, к иерархии /mnt,
e. g.:
# mount -- /dev/vgbakau-sys-i/lvroot /mnt
# mkdir -- /mnt/var
# mount -- /dev/vgbakau-sys-i/lvvar /mnt/var
# mkdir -- /mnt/var/cache
# mount -- /dev/vgbakau-u-i/lvvarcache /mnt/var/cache
# mkdir -- /mnt/home
# mount -o nodev -- /dev/vgbakau-u-i/lvhome /mnt/home
# mkdir -p -- /mnt/home/public/storage
# mount -o nodev -- /dev/vgbakau-u-i/lvstorage /mnt/home/public/storage
# mkdir -- /mnt/boot
# mount -o noexec,nosuid,nodev -U 7bfad579-8e0f-4ef7-bc58-fad76f5fc83d \
-- /mnt/boot
#
Разумеется, на этом этапе можно создать и fstab(5) целевой
системы, подобный:
## device mount point type options d p
/dev/vgbakau-sys-i/lvroot / ext3 defaults 0 1
tmpfs /tmp tmpfs defaults 0 0
/dev/vgbakau-sys-i/lvvar /var ext3 defaults 0 2
/dev/vgbakau-u-i/lvvarcache /var/cache ext3 defaults 0 2
/dev/vgbakau-u-i/lvhome /home ext3 nodev 0 2
/dev/vgbakau-u-i/lvstorage /home/public/storage ext3 nodev 0 2
UUID=d66d7d66-4382-4019-b420-1c47c29f7263 none swap sw 0 0
UUID=7bfad579-8e0f-4ef7-bc58-fad76f5fc83d /boot ro,noexec,nosuid,nodev 0 2
В случае, если есть желание использовать корневую ФС,
подключенную в режиме «только чтение» (что несколько повышает
устойчивость системы к некоторым сбоям), следует учесть, что вне
контекста задач установки и удаления программ (для чего,
очевидно, переподключение ФС в режиме «чтение и запись»
необходимо), может потребоваться запись в директорию /media/, а
также файлы /etc/mtab, passwd(5), shadow(5) (e. g., при работе
таких программ, как pmount(1), chfn(1), passwd(1), etc.)
При этом, директорию /media/ можно разместить на tmpfs:
tmpfs /media tmpfs mode=0755 0 0
в то время как файл /etc/mtab заменим символьной ссылкой на
/proc/mounts:
# ln -sf -- /proc/mounts /mnt/etc/mtab
Что же касается таких файлов, как passwd(5) и shadow(5) —
решением может быть применение LDAP и Kerberos, соответственно,
— тем более, что такие системы скорее всего потребуются в
многопользовательских окружениях и по другим причинам.
Далее, выполним установку «основы» системы используя
debootstrap(8), e. g.:
# debootstrap \
--keep-debootstrap-dir \
--arch=amd64 \
wheezy /mnt http://http.debian.net/debian/ \
2>&1 | tee -- "$(mktemp -- "/mnt/.debootstrap.XXXXXXXX")"
Включив в команду выше опцию --include= получим возможность
установить дополнительные пакеты, подобно:
…
--include=busybox,bzip2,diffutils,ed,file,less,patch,rsync,screen\
,time,tree,unzip,uuid-runtime,xutils-dev,xz-utils,zip,bc,dc,gawk \
…
Впрочем, этой опцией следует пользоваться с осторожностью,
поскольку она обрабатывается вне контекста APT. Куда надежнее
вызвать обычную # apt-get install после успешного завершения
debootstrap(8), чему посвящен следующий раздел.
APT устанавливаемой системы
Общий ход настройки APT целевой системы ничем не отличается от
такого для основной. В частности, если целевая система будет
эксплуатироваться в том же «окружении» (в той же сети, совместно
с тем же HTTP proxy, etc.), настройки можно попросту
скопировать.
Основой настройки APT является список источников, хранимый в
.list-файлах директории /etc/apt/sources.list.d/, e. g.:
$ ls -- /mnt/etc/apt/sources.list.d/
54-http.debian.net-wheezy.list
55-security.debian.org-wheezy-sec.list
$ tail -n3 -- /mnt/etc/apt/sources.list.d/*.list
==> /mnt/etc/apt/sources.list.d/54-http.debian.net-wheezy.list <==
deb http://http.debian.net/debian wheezy main
# deb-src http://http.debian.net/debian wheezy main
==> /mnt/etc/apt/sources.list.d/55-security.debian.org-wheezy-sec.list <==
deb http://security.debian.org/debian-security/ wheezy/updates main
# deb-src http://security.debian.org/debian-security/ wheezy/updates main
$
Также может быть полезно установить (создав один или более
файлов /mnt/etc/apt/apt.conf.d/) такие параметры, как, e. g.:
APT::Default-Release "testing";
APT::Install-Recommends "true";
Acquire::http::Proxy "http://proxy.example.org:3128/";
Acquire::http::Proxy::apt.example.org "DIRECT";
Чтобы предотвратить нежелательный на данном этапе запуск
init.d/-кода в процессе работы APT, создадим следующий
policy-rc.d-файл:
# cat < /mnt/usr/sbin/policy-rc.d
#!/bin/sh
echo NB: policy-rc.d called >&2
exit 101
# chmod -- 0755 /mnt/usr/sbin/policy-rc.d
#
Выполним теперь установку дополнительных пакетов (не забыв о
такой важной части системы, как ядро), e. g.:
# chroot /mnt apt-get install -V \
linux-image-amd64 \
busybox bzip2 diffutils ed file less patch rsync screen time \
tree unzip uuid-runtime xutils-dev xz-utils zip bc dc gawk
Возможность явно задать список пакетов для установки командой,
подобной представленной выше, выгодно отличает, на взгляд
автора, установку с использованием системы общего назначения от
установки с использованием D-I (в случае чего предложено было бы
воспользоваться tasksel.)
На данном этапе можно также сменить пароль привилегированного
пользователя (# chroot /mnt passwd), внести правки в passwd(5) и
group(5) целевой системы (текстовым редактором, или же
# chroot /mnt adduser, etc.), создать пользовательские домашние
(private) и public-директории, подобно:
# cat < /mnt/root/mkud.sh
#!/bin/sh
for u ; do
g=$(id -g -- "$u")
install -v -d -m 0700 -o "$u" -g "$g" -- /home/private/users/"$u"
install -v -d -m 0755 -o "$u" -g "$g" -- /home/public/users/"$u"
done
# chroot /mnt bash /root/mkud.sh jrh bloggs
(Здесь может иметь смысл вернуться к разделу «Адаптация к
окружению» и проверить, все ли из упомянутых в нем действий по
настройке целевой системы были в действительности выполнены?)
После завершения работы с APT (см., однако, следующий раздел, на
предмет еще одного пакета, подлежащего установке), файл
policy-rc.d следует удалить:
# rm -- /mnt/usr/sbin/policy-rc.d
Установка загрузчика
Заключительным этапом установки системы может быть установка
загрузчика GRUB. Проще всего, пожалуй, установить на целевую
систему загрузчик основной, подобно (где /dev/sdX — /целевой/
носитель):
# grub-install --root-directory=/mnt -- /dev/sdX
Также, следует создать конфигурационный файл grub.cfg, для чего
следует выполнить # chroot /mnt update-grub, установив
предварительно в целевой системе подходящий из содержащих GRUB
пакетов (grub-efi-amd64, grub-pc, etc.) Следует, однако,
отказаться от установки самого загрузчика из chroot-окружения,
т. к. последнее лишено необходимых для этого /dev-файлов
(поскольку udev основной системы обслуживает лишь директорию
/dev, но не /mnt/dev), а также из-за риска перезаписать таким
образом загрузчик основной системы (при неаккуратном обращении.)
Завершение работы с целевым носителем
Наконец, следует подготовить носитель к переносу на целевую
систему, для чего следует отключить все ФС и деактивировать
логические тома LVM:
# umount -- \
/mnt/boot \
/mnt/home/public/storage \
/mnt/home \
/mnt/var/cache \
/mnt/var \
/mnt
# vgchange -a n -- /dev/vgbakau-*
Если отключение носителя выполняется «на горячую», следует также
выполнить перевод носителя и порта интерфейса в «спящий» режим,
подобно:
# hdparm -Y -- /dev/sdX
# echo x > /sys/bus/scsi/devices/N:0:0:0/delete
(Где значение N можно выяснить изучив записи /var/log/kern.log,
соответствующие времени подключения носителя.)
В противном случае, работа системы завершается обычным образом.
Затем, носитель физически отключается от устанавливающей системы
и подключается к целевой. Можно надеяться, что после выполнения
описанных в этих заметках действий, новоустановленная система
будет в состоянии загрузится.
Стоит, пожалуй, отметить, что создание таблицы разделов,
конфигурации LVM, и формирование ФС на разделах и логических
томах — представлены в D-I единым этапом. Этот же этап включает
и подготовку подходящего fstab(5) для целевой системы. С точки
зрения использования системы общего назначения, однако, эти
этапы разделены, и в данном разделе мы рассмотрим следующий из
них.
Инициализировать физические тома LVM и объединить их в группу
можно подобно (предполагая именем целевой системы
bakau.example.org; раздел №14 «tail» из примера parted(8) выше
оставляем в качестве еще одного, весьма скромного, резерва):
# pvcreate -- /dev/sdX{[5-9],1[0-3]}
…
# vgcreate -- vgbakau-i /dev/sdX{[5-9],1[0-3]}
…
#
Разумеется, вовсе не обязательно объединять в группу (или
группы) все физические тома данного носителя, или даже
инициализировать их. Однако, эти действия необходимы для
«появления» соответствующего пространства в списках # vgs и
# pvs (соответственно.)
Определенный интерес может представлять, однако, выделение
несущих системные ФС (/, /var) томов (и, следовательно, их
будущих «мгновенных копий», или snapshots, если таковые
потребуются) в отдельную группу. Отведем под нее GPT-раздел №6
«medium-1» и изменим вызов vgcreate(8) выше на:
# vgcreate -- vgbakau-sys-i /dev/sdX6
…
# vgcreate -- vgbakau-u-i /dev/sdX{[57-9],1[0-3]}
…
#
Включение в имя группы имени системы необходимо ровно по той
причине, что в противном случае, — при использовании имен вида
vg00, vg01, …, — группа vg00 вполне может оказаться существующей
на /установочной/ системе, так что /устанавливаемой/ придется
довольствоваться vg01. Также, для восстановления системы после
сбоя, может потребоваться подключить ее (системный) носитель к
другой системе, и представляется весьма желательным, чтобы имена
групп LVM этого носителя заведомо отличались от таковых для
носителей /восстанавливающей/ системы.
OTOH, объединение в одну группу физических томов, размещенных на
различных физических носителях, хотя и возможно, может оказаться
не лучшей идеей. (В случае, если рассматриваемая группа будет
содержать «системные» разделы, это особенно нежелательно,
поскольку любое обращение к логическим томам группы, а значит и
загрузка системы, окажутся невозможными при недоступности любого
из таких физических носителей — вне зависимости от того,
размещены ли на нем фактически данные искомых логических томов.)
Создание логических томов LVM и инициализация файловых систем
Создадим теперь логические тома LVM и инициализируем на них
нужные нам системные и пользовательские ФС, для чего
воспользуемся следующим несложным Shell-кодом:
# cat < mklv.sh
#!/bin/bash
set -e -x
## Usage:
## bash mklv.sh VOLUME-GROUP PHYSICAL-VOLUME [LOGICAL-VOLUME,SIZE]...
## Example:
## bash mklv.sh vgfoo-i /dev/sdXX lvbar,14G lvqux,42G
vg=${1}
pv=${2}
shift 2
for i ; do
lv=${i%%,*}
sz=${i#*,}
f=/dev/${vg}/${lv}.new
lvcreate -L "$sz" -n "$lv" "$vg" "$pv"
mke2fs -j -- "$f" \
|| break
lvrename "$f" "${f%.new}" \
|| break
done
vgs -- "$vg"
# bash mklv.sh vgbakau-i /dev/sdX7 lvroot,8G lvvar,4G lvhome,48G
…
#
Или же, если системные ФС вынесены на тома отдельной группы:
# bash mklv.sh vgbakau-sys-i /dev/sdX6 lvroot,8G lvvar,4G
…
# bash mklv.sh vgbakau-u-i /dev/sdX7 lvhome,56G
…
#
Вспомним, однако, что почти наверняка существенную часть
имеющегося на носителе пространства займут данные, которые
несложно тем или иным способом восстановить (получив с
HTTP-сервера, через сеть BitTorrent, или иначе). Создание
резервных копий этих данных не является столь уж важной задачей,
поэтому под их хранение можно выделить отдельную ФС:
# bash mklv.sh vgbakau-u-i /dev/sdX8 lvstorage,56G
…
#
которую можно сразу же расширить на соседний физический том:
# lvextend -L 120G -- /dev/vgbakau-u-i/lvstorage /dev/sdX8 /dev/sdX9
…
# resize2fs -- /dev/vgbakau-u-i/lvstorage
…
#
Впоследствии, для этой ФС можно будет реализовать особый
регламент резервирования.
(Возможность изменять размеры логических томов, наряду с
возможностью «на горячую» увеличивать размеры некоторых ФС,
включая Ext3+, является, по мнению автора, ключевой при
управлении долговременными носителями информации в современном
системном администрировании.)
Можно отметить, кроме того, что создание резервных копий для
/var/cache также может следовать иным, отличным от таковых для
/var, правилам, что может побудить к созданию еще одной ФС (на
которой, при необходимости, можно разместить и такие данные,
как, e. g., кэш Squid):
# bash mklv.sh vgbakau-u-i /dev/sdX9 lvvarcache,7G
Установка «основы» системы
Подключим созданные ФС, начиная с корневой, к иерархии /mnt,
e. g.:
# mount -- /dev/vgbakau-sys-i/lvroot /mnt
# mkdir -- /mnt/var
# mount -- /dev/vgbakau-sys-i/lvvar /mnt/var
# mkdir -- /mnt/var/cache
# mount -- /dev/vgbakau-u-i/lvvarcache /mnt/var/cache
# mkdir -- /mnt/home
# mount -o nodev -- /dev/vgbakau-u-i/lvhome /mnt/home
# mkdir -p -- /mnt/home/public/storage
# mount -o nodev -- /dev/vgbakau-u-i/lvstorage /mnt/home/public/storage
# mkdir -- /mnt/boot
# mount -o noexec,nosuid,nodev -U 7bfad579-8e0f-4ef7-bc58-fad76f5fc83d \
-- /mnt/boot
#
Разумеется, на этом этапе можно создать и fstab(5) целевой
системы, подобный:
## device mount point type options d p
/dev/vgbakau-sys-i/lvroot / ext3 defaults 0 1
tmpfs /tmp tmpfs defaults 0 0
/dev/vgbakau-sys-i/lvvar /var ext3 defaults 0 2
/dev/vgbakau-u-i/lvvarcache /var/cache ext3 defaults 0 2
/dev/vgbakau-u-i/lvhome /home ext3 nodev 0 2
/dev/vgbakau-u-i/lvstorage /home/public/storage ext3 nodev 0 2
UUID=d66d7d66-4382-4019-b420-1c47c29f7263 none swap sw 0 0
UUID=7bfad579-8e0f-4ef7-bc58-fad76f5fc83d /boot ro,noexec,nosuid,nodev 0 2
В случае, если есть желание использовать корневую ФС,
подключенную в режиме «только чтение» (что несколько повышает
устойчивость системы к некоторым сбоям), следует учесть, что вне
контекста задач установки и удаления программ (для чего,
очевидно, переподключение ФС в режиме «чтение и запись»
необходимо), может потребоваться запись в директорию /media/, а
также файлы /etc/mtab, passwd(5), shadow(5) (e. g., при работе
таких программ, как pmount(1), chfn(1), passwd(1), etc.)
При этом, директорию /media/ можно разместить на tmpfs:
tmpfs /media tmpfs mode=0755 0 0
в то время как файл /etc/mtab заменим символьной ссылкой на
/proc/mounts:
# ln -sf -- /proc/mounts /mnt/etc/mtab
Что же касается таких файлов, как passwd(5) и shadow(5) —
решением может быть применение LDAP и Kerberos, соответственно,
— тем более, что такие системы скорее всего потребуются в
многопользовательских окружениях и по другим причинам.
Далее, выполним установку «основы» системы используя
debootstrap(8), e. g.:
# debootstrap \
--keep-debootstrap-dir \
--arch=amd64 \
wheezy /mnt http://http.debian.net/debian/ \
2>&1 | tee -- "$(mktemp -- "/mnt/.debootstrap.XXXXXXXX")"
Включив в команду выше опцию --include= получим возможность
установить дополнительные пакеты, подобно:
…
--include=busybox,bzip2,diffutils,ed,file,less,patch,rsync,screen\
,time,tree,unzip,uuid-runtime,xutils-dev,xz-utils,zip,bc,dc,gawk \
…
Впрочем, этой опцией следует пользоваться с осторожностью,
поскольку она обрабатывается вне контекста APT. Куда надежнее
вызвать обычную # apt-get install после успешного завершения
debootstrap(8), чему посвящен следующий раздел.
APT устанавливаемой системы
Общий ход настройки APT целевой системы ничем не отличается от
такого для основной. В частности, если целевая система будет
эксплуатироваться в том же «окружении» (в той же сети, совместно
с тем же HTTP proxy, etc.), настройки можно попросту
скопировать.
Основой настройки APT является список источников, хранимый в
.list-файлах директории /etc/apt/sources.list.d/, e. g.:
$ ls -- /mnt/etc/apt/sources.list.d/
54-http.debian.net-wheezy.list
55-security.debian.org-wheezy-sec.list
$ tail -n3 -- /mnt/etc/apt/sources.list.d/*.list
==> /mnt/etc/apt/sources.list.d/54-http.debian.net-wheezy.list <==
deb http://http.debian.net/debian wheezy main
# deb-src http://http.debian.net/debian wheezy main
==> /mnt/etc/apt/sources.list.d/55-security.debian.org-wheezy-sec.list <==
deb http://security.debian.org/debian-security/ wheezy/updates main
# deb-src http://security.debian.org/debian-security/ wheezy/updates main
$
Также может быть полезно установить (создав один или более
файлов /mnt/etc/apt/apt.conf.d/) такие параметры, как, e. g.:
APT::Default-Release "testing";
APT::Install-Recommends "true";
Acquire::http::Proxy "http://proxy.example.org:3128/";
Acquire::http::Proxy::apt.example.org "DIRECT";
Чтобы предотвратить нежелательный на данном этапе запуск
init.d/-кода в процессе работы APT, создадим следующий
policy-rc.d-файл:
# cat < /mnt/usr/sbin/policy-rc.d
#!/bin/sh
echo NB: policy-rc.d called >&2
exit 101
# chmod -- 0755 /mnt/usr/sbin/policy-rc.d
#
Выполним теперь установку дополнительных пакетов (не забыв о
такой важной части системы, как ядро), e. g.:
# chroot /mnt apt-get install -V \
linux-image-amd64 \
busybox bzip2 diffutils ed file less patch rsync screen time \
tree unzip uuid-runtime xutils-dev xz-utils zip bc dc gawk
Возможность явно задать список пакетов для установки командой,
подобной представленной выше, выгодно отличает, на взгляд
автора, установку с использованием системы общего назначения от
установки с использованием D-I (в случае чего предложено было бы
воспользоваться tasksel.)
На данном этапе можно также сменить пароль привилегированного
пользователя (# chroot /mnt passwd), внести правки в passwd(5) и
group(5) целевой системы (текстовым редактором, или же
# chroot /mnt adduser, etc.), создать пользовательские домашние
(private) и public-директории, подобно:
# cat < /mnt/root/mkud.sh
#!/bin/sh
for u ; do
g=$(id -g -- "$u")
install -v -d -m 0700 -o "$u" -g "$g" -- /home/private/users/"$u"
install -v -d -m 0755 -o "$u" -g "$g" -- /home/public/users/"$u"
done
# chroot /mnt bash /root/mkud.sh jrh bloggs
(Здесь может иметь смысл вернуться к разделу «Адаптация к
окружению» и проверить, все ли из упомянутых в нем действий по
настройке целевой системы были в действительности выполнены?)
После завершения работы с APT (см., однако, следующий раздел, на
предмет еще одного пакета, подлежащего установке), файл
policy-rc.d следует удалить:
# rm -- /mnt/usr/sbin/policy-rc.d
Установка загрузчика
Заключительным этапом установки системы может быть установка
загрузчика GRUB. Проще всего, пожалуй, установить на целевую
систему загрузчик основной, подобно (где /dev/sdX — /целевой/
носитель):
# grub-install --root-directory=/mnt -- /dev/sdX
Также, следует создать конфигурационный файл grub.cfg, для чего
следует выполнить # chroot /mnt update-grub, установив
предварительно в целевой системе подходящий из содержащих GRUB
пакетов (grub-efi-amd64, grub-pc, etc.) Следует, однако,
отказаться от установки самого загрузчика из chroot-окружения,
т. к. последнее лишено необходимых для этого /dev-файлов
(поскольку udev основной системы обслуживает лишь директорию
/dev, но не /mnt/dev), а также из-за риска перезаписать таким
образом загрузчик основной системы (при неаккуратном обращении.)
Завершение работы с целевым носителем
Наконец, следует подготовить носитель к переносу на целевую
систему, для чего следует отключить все ФС и деактивировать
логические тома LVM:
# umount -- \
/mnt/boot \
/mnt/home/public/storage \
/mnt/home \
/mnt/var/cache \
/mnt/var \
/mnt
# vgchange -a n -- /dev/vgbakau-*
Если отключение носителя выполняется «на горячую», следует также
выполнить перевод носителя и порта интерфейса в «спящий» режим,
подобно:
# hdparm -Y -- /dev/sdX
# echo x > /sys/bus/scsi/devices/N:0:0:0/delete
(Где значение N можно выяснить изучив записи /var/log/kern.log,
соответствующие времени подключения носителя.)
В противном случае, работа системы завершается обычным образом.
Затем, носитель физически отключается от устанавливающей системы
и подключается к целевой. Можно надеяться, что после выполнения
описанных в этих заметках действий, новоустановленная система
будет в состоянии загрузится.
0 new messages