Установочный диск Ubuntu Server 18.04 для архитектуры amd64 бывает в двух вариантах: основной, например ubuntu-18.04.1.0-live-server-amd64.iso (далее - live-server), и "альтернативный", например ubuntu-18.04.1-server-amd64.iso (далее - alt-server). Live-server на реальной машине что-то вообще не захотел стартовать, поэтому его мы рассмотрим вскользь и на примере виртуалки. Да и не понравился он мне. "Альтернативный" установщик сохраняет традиции установки предыдущих версий, занимает меньше, да и вообще конечный результат более толковый, на мой взгляд. Так что я рекомендую пользоваться именно этим вариантом, хотя попробуй его еще найди на официальном сайте.
Вариант установки: live-server (виртуальная машина)
Установщик предоставляет якобы графический интерфейс, но принцип работы с ним все равно как у текстового. По крайней мере в виртуальной машине мышь не захотела работать. Первые 3 шага установки системы - настройки языка, клавиатуры и выбор варианта установки.
Виртуальные сетевые адаптеры определяются и включаются сразу. Забегая вперед, это выливается в двухминутное ожидание при загрузке ОС. С помощью меню можно углубиться в настройки, но по большому счету это не требуется - DHCP рулит. Следующими шагами будут указание прокси и ссылки (зеркала) репозитория.
Переходим к разбиению диска. Вдохновившись примером CentOS, в виртуалках решил посмотреть, каким образом установщики предлагают разбить диск с использованием LVM (logical volume management). Этот самый менеджмент, между прочим, очень крутая штука - как я без нее раньше жил, не представляю (на самом деле сначала страдал фигней с какой-то aufs, а потом просто страдал, распределяя файлы вручную). Вкратце, LVM позволяет объединять жесткие диски (точнее разделы) суммируя объем, а также относительно легко эти самые диски добавлять и заменять в случае чего. А как же JBOD или RAID? - скажете вы, и отчасти будете правы. Тем не менее, мне LVM кажется более надежным и удобным по сравнению с JBOD (хотя, если честно, на практике я с таким и не сталкивался), а с RAID-0 по-моему вообще лучше не связываться.
Итак, среди способов - весь диск, весь диск с LVM и ручной - выбираем второй вариант, а затем - конкретный жесткий диск (в виртуалке он один).
Способ разбиения предлагается немного странный (по-моему хуже, чем в CentOS): 1 мегабайт (!) для загрузчика, 1 гигабайт для /boot (как в Centos), остальное под LVM, причем 4 гигабайта для / (root), оставшееся место свободно.
Впрочем выделение раздела для BIOS, видимо, даже лучше установки GRUB в MBR (забегая вперед, такой вариант предлагает альтернативный установщик). LVM, конечно, потом можно несколькими командами перераспределить, но я решил сразу занять все доступное место:
Так-то лучше. Для перехода к следующему шагу необходимо подтвердить настройку диска:
На очередном этапе указываем имя компьютера и создаем пользователя. Хотелось бы отметить преимущество: можно сразу же импортировать ключ SSH с GitHub или Launchpad. Думаю, эти сайты в представлении не нуждаются.
Затем live-server предлагает выбрать какие-то совершенно непонятные пакеты. Я не стал ничего выбирать.
Наконец мы попадаем в журнал установки, по окончании которой появится кнопка Reboot now. Однако перед самой перезагрузкой будет предложено извлечь установочный диск.
После установки live-server при первой загрузке вываливается какая-то дичь (отсутствуют авторизованные ключи SSH):
Зато этот самый OpenSSH предустановлен и доступен. Как я упоминал выше, в случае виртуальной машины и двух сетевых адаптеров, возникает непонятно чем обоснованное двухминутное ожидание получения настроек сети. Чтобы это исправить, надо изменить (в режиме суперпользователя) настройки некоего netplan - в файле /etc/netplan/50-cloud-init.yaml второй адаптер (enp0s8) делаем опциональным (optional: true).
Крупным помолом - как, собственно, отредактировать:
$ sudo -i # apt-get install mc # mcedit /etc/netplan/50-cloud-init.yaml
Существенная часть файла должна стать такой (пробелы важны):
network: ethernets: enp0s3: addresses: [] dhcp4: true enp0s8: addresses: [] dhcp4: true optional: true version: 2
F2 для сохранения, двойной ESC для выхода.
# netplan generate # netplan apply
Подробности письмом (т.е. в разделе первоначальной настройки ниже).
Вариант установки: alt-server (виртуальная машина)
При загрузке выбираем язык (English) и Install Ubuntu Server:
Запускается текстовый установщик.
Язык и клавиатура
В варианте Alt-server этому процессу по-моему уделено слишком уж много внимания - целых 9 экранов! Язык (English - English), 3 экрана для выбора страны (other - Europe - Russian Federaion), локаль (en_US.UTF-8), запрос на определение клавиатуры (нет), 3 экрана настройки клавиатуры (Russian - Russian - Control + Shift).
Настройки сети и пользователей
Выбираем первый сетевой адаптер как используемый по умолчанию. Затем поэтапно вводим имя компьютера (hostname), "настоящее" имя пользователя, логин и пароль с подтверждением.
Наконец, подтверждаем (или выбираем) часовой пояс.
Разбиение диска
Сначала нужно отмонтировать используемые разделы (Yes) и выбрать диск для разбиения.
Поскольку alt-server я бессовестным образом устанавливал после live-server на ту же виртуалку, появляются запросы на удаление существующих логических томов (LVM, которые) и записи изменений на диск:
Далее задаем объем группы томов (весь диск). Получаем, как мне кажется, более осмысленный вариант: примерно 533 мегабайта раздела подкачки, а оставшееся место выделено для корневого раздела. Поскольку все это объединено в группу томов, получается, grub умеет загружать ОС на LVM даже без вспомогательного загрузочного раздела /boot. Подтверждаем предлагаемую настройку диска и вновь записываем изменения.
Завершение установки
У "альтернативного сервера" окончание установки (по сравнению с live) длиннее. Указываем (при наличии) прокси-сервер и отключаем автоматические обновления - предпочитаю периодически обновлять вручную.
Как и в live-варианте, можно выбрать некоторые пакеты для установки, однако в отличие от live их здесь немного, да и назначение их вполне очевидно. OpenSSH нужно выбрать обязательно, а насчет остального - по желанию. LAMP и Samba установлены на реальном сервере, поэтому на скриншоте они тоже выбраны.
Наконец, подтверждаем установку Grub в MBR, если, конечно, Ubuntu - единственная ОС, иначе могут быть нюансы. Хотя в виртуалке-то ОС как раз единственная, это больше относится к реальным машинам с мультизагрузкой. Уходим на перезагрузку после извлечения установочного диска.
Включение второго сетевого адаптера
В отличие от live-server, в таком варианте установки работает только первый адаптер, который обеспечивает лишь доступ в интернет. На этот раз настройки второго адаптера нужно дописать целиком, причем без помощи буфера обмена. Да и сам файл немного другой - /etc/netplan/01-netcfg.yaml
network: version: 2 renderer: networkd ethernets: enp0s3: dhcp4: yes enp0s8: dhcp4: yes optional: true
Здесь enp0s3 и enp0s8 - стандартные идентификаторы сетевых адаптеров в VirtualBox. В общем случае получить идентификаторы адаптеров (а заодно проверить их состояние) можно командой:
$ ifconfig -a
Последовательность остальных команд в целом та же. Не забываем про netplan generate и netplan apply
Особенности реального сервера
Начальный этап
Для установки на физический сервер я сделал загрузочную флешку с помощью UNetbootin. Возможно не самая лучшая идея, но болванку прожигать что-то не хотелось. Кстати это было в мае 2018, тогда 18.04 только вышел и не имел ".1" в конце. Впрочем на процесс установки как таковой это никоим образом не влияет - шаги абсолютно те же самые.
Фотографировать дисплей - так себе идея, все получается кривовато, не совсем четко и т.д. Так что виртуальная машина в этом смысле очень выручает, и я рад, что можно оставить фотографии только тех этапов, в которых есть отличия.
Перед выбором сетевого адаптера вылезло предупреждение о потенциальной глючности Unetbootin (на практике не подтвердилось).
Настройка диска
Это, пожалуй, наиболее ответственный и отчасти сложный этап в случае имеющихся файловых систем. Как и в виртуалке, отключаем используемые разделы, но выбираем ручное разбиение.
Ситуация с дисками была следующей: терабайтный "системный" WD Se, из них скорее всего 128 GiB (поскольку на экране было отражено 137.4 GB - какая-то неровная цифра) под собственно систему (root), а также два WD Red по 3 терабайта. К этому моменту я уже заморочился и перешел на LVM. Точнее дело было так: сначала был куплен компьютер на базе Ryzen 5 2600 с диском на 4 терабайта, да и на "зеленом" сколько-то места оставалось. Это позволило скопировать данные с красных дисков и построить из них логический том, соответственно, на 6 терабайт. Времени 5 - 5,5 терабайт туда-сюда копировать занимает немало, но что поделаешь - дурная голова, как говорится...
Начинаем с системного диска. Выбираем раздел "ровно" на 137,4 GB (sda1), проверяем: Use as - Ext4, format - yes (я собирался установить 18.04 с нуля, а не обновлять), точка монтирования - /, bootable flag - on. Остальное вроде бы по умолчанию.
Второй раздел на этом диске (sda2) форматировать как раз не надо. Зато нужно куда-то смонтировать, я решил сделать это в старом стиле - в /mnt, т.е. в данном случае /mnt/storage
На фотографии, кстати, можно заметить несколько предопределенных точек монтирования - при сильном желании операционную систему можно распределить по разным разделам или дискам.
Аналогичным образом смонтируем логический том в /mnt/lvmred
Проверяем, что получилось, и подтверждаем форматирование системного раздела.
Исправление загрузки (nomodeset)
Все шло хорошо ровно до момента первой загрузки ОС, которого, собственно говоря, не произошло. Неспроста live-server на загружался, ой, неспроста... Дело оказалось в некоем конфликте с видюшкой, интегрированной в процессор. О том, как запретить переход в графический режим при загрузке, я написал отдельную заметку.
Права доступа к точкам монтирования
Точки монтирования, созданные при установке (/mnt/storage и /mnt/lvmred) получили стандартные права папок (755) и владельца (root). Это означает, что для всех, кроме root, содержимое примонтированных файловых систем доступно только для чтения. Поскольку супербезопасность на домашнем сервере вроде как не требуется, необходимо разрешить запись путем установки прав 777 на сами точки монтирования:
# chmod 777 /mnt/storage # chmod 777 /mnt/lvmred
Чуть более подробно о правах доступа я рассказывал в статье про настройку Ubuntu 14.04.
На этом специфика закончилась. Переведем дух и, надеюсь, наконец разберемся, что к чему.
Начальная настройка
На всякий случай сразу предупреждаю, что в linux пароли вводятся "в пустоту" - т.е. при запросе пароля в консоли никаких звездочек или еще чего по мере ввода отображаться не будет.
Файловый менеджер
Итак, вне зависимости от способа установки, первым делом предлагаю установить Midnight Commander. Иначе, как я уже говорил в другой статье, ни по файловой системе толком не походишь, ни конфиги толком не отредактируешь. Nano-то оно конечно да, но комбинации клавиш там очень уж непривычные.
$ sudo apt-get install mc
Здесь, выше и ниже - если в начале команды стоит #, значит команду выполняет root, а если $ - пользователь.
Небольшой "курс молодого бойца", если позволите - все-таки статья "базовая", как я ее в анонсе охарактеризовал. root - unix'овый суперпользователь. Однако в Ubuntu при установке создается "обычный" пользователь, хоть и с правом выполнения команды sudo. Эта команда как раз повышает привилегии. Поскольку большинство мало-мальски ответственных действий выполняется именно с правами суперпользователя, каждый раз набирать sudo лично меня утомляет. Вопреки всем рекомендациям, я в таких случаях перехожу в root на постоянной основе:
$ sudo -i
Таким образом, с помощью повышения привилегий (sudo), мы скомандовали системе управления пакетами (apt, в командах apt-get пишут скорее по традиции) установить (install) пакет mc (т.е. в данном случае - программу Midnight commander). Большинство актуальных дистрибутивов linux именно пакетные - это значит, что программы рекомендуется устанавливать из централизованных хранилищ (репозиториев). Значки $ и # взяты из консоли - они выводятся в "приглашении командной строки" (воспользуюсь скорее DOS/Windows-формулировкой) для пользователя и root соответственно.
Надеюсь, теперь внесение изменений в настройки виртуальных сетевых адаптеров и загрузчика стало не таким загадочным. mcedit, как вы наверняка догадались - текстовый редактор из комплекта поставки "полуночника".
Обновление системы
Стандартными командами являются:
# apt-get update # apt-get upgrade # apt-get autoremove
Где update - обновление списка пакетов, upgrade - собственно обновление, autoremove - удаление устаревших и неиспользуемых пакетов. Однако может случиться так, что при вызове команды upgrade некоторые пакеты не будут обновлены, например:
The following packages have been kept back: linux-generic linux-headers-generic linux-image-generic lxd lxd-client netplan.io
Такое происходит, если в обновленных версиях существующих пакетов появились новые зависимости и, в частности, при обновлении ядра linux. Чтобы обновить такие пакеты, вместо upgrade используется команда install (как и при установке новых). Можно (или даже скорее нужно) перечислить (через пробел) все необходимые пакеты для установки/обновления:
# apt-get install linux-generic linux-headers-generic linux-image-generic lxd lxd-client netplan.io
Вручную мало-мальски большой список не введешь, поэтому лучше заходить по SSH (PuTTY), чтобы пользоваться буфером обмена. Главное не захватывать символ перевода строки.
Командами перезагрузки и выключения являются reboot и poweroff соответственно, выполняемые с правами суперпользователя.
Панель управления Webmin
Помимо консоли с файловым менеджером я привык к веб-панели управления. Обычно я устанавливал Webmin из пакета, однако на этот раз предлагаю добавить репозиторий. Несмотря на то, что на сайте инструкция для Debian, к Ubuntu она применяется практически без изменений.
Редактируем с правами суперпользователя файл /etc/apt/sources.list - в конец добавляем строчку:
deb https://download.webmin.com/download/repository sarge contrib
Несмотря на то, что Ubuntu 18.04 применительно к пакетам имеет кодовое имя bionic, ничего менять не требуется (кстати sarge - это "позывной" очень старой версии Debian). Далее скачиваем и добавляем ключ электронной подписи репозитория:
# cd ~ # wget http://www.webmin.com/jcameron-key.asc # apt-key add jcameron-key.asc
Здесь cd ~ обозначает переход в домашний каталог. По инструкции предлагается установить поддержку транспорта https для apt, но в нашем случае это не требуется. Поэтому обновляем список пакетов и устанавливаем:
# apt-get update # apt-get install webmin
В отличие от CentOS/Fedora, больше никакого "шаманства" не требуется - можно открывать Webmin в браузере и заходить. Например, для виртуальной машины https://192.168.56.107:10000/, а реальный сервер даже отзывается по имени хоста: https://servpc:10000/
Заключение
На этом базовая настройка, на мой взгляд, завершена, а дальнейшие действия зависят от назначения сервера. Хм... Где-то я это уже писал? Вообще-то я "задолжал" продолжение статьи о настройке Убунты на домашнем сервере. Наверное в этом направлении и будем планировать следующий материал.
И напоследок: для "групповой" установки пакетов, подобно одному из этапов "альтернативной" установки, предназначена команда:
$ sudo tasksel