курс адміністрування linux?

| щоденник, комп'ютери, linux, навчання, проєкт

натрапив, прочитав, злякався… треба спробувати, поки є вільна машина: інтенсивний екстремальний курс адміністрування linux (чи радше задачник) на reddit’івському r/linuxadmin.

страшний задачник з адміністрування linux

поновлення (2020-08-14). дійшли руки, мабуть, взятися за цей проєкт самонавчання. очі бояться, руки роблять? побачимо. замість додавати новий допис, вирішив продовжити цей. ну все, понеслась…

зміст

/i\ щодо нотації команд та інших позначок:

  • #> — команда від root’а (або з sudo);
  • $> — команда від кристувача;
  • ## або # — коментар;
  • /i\ ― заувага;
  • /!\ ― проблема.

0. підготовка

0.1. тестовий стенд

як планував, за навчальний стенд беру купований на kijiji за 20$ asus cm6340 — побачимо, чи вистачить його:

  • процесор: intel core i5-3470;
  • пам’ять: 16 гб (4×4 гб)
  • диски:
    • ssd 120 гб (kingston sv300s3)
    • hdd 500 гб (western digital wd5000aakx)
    • hdd 500 гб (western digital wd5000aakx)
  • мережа:
    • ethernet: realtek rtl8111/8168/8411 (інтегрований)
    • wifi: ralink rt3090 (802.11n)
    • ethernet: intel expi9301ctblk (доставив, аби не лежало без діла)

під питанням, чи цього вистачить.

налаштування тестового стенду

↖ до змісту

0.2. встановлення debian

все зрозуміло і знайомо, за винятком… розподілу дисків специфічно під задачу (гіпервізор на kvm’і) — як краще? готових рецептів не знайшов, лише підказки. ось перша спроба, подякую за критику:

  • ssd 120 гб (sda):
    • 512 мб — efi (fat32, прапорці boot та esp, sda0);
    • 32 гб — swap (sda1);
    • 87 гб — корінь (/, ext4, sda2);
  • hdd 500 гб (sdb):
    • 500 гб — фізичний том lvm (sdb1);
  • hdd 500 гб (sdc):
    • 500 гб — фізичний том lvm (sdc1).

два диски по 500 гб об’єднав lvm’ом у групу (roku_vg0) і віддав під один терабайний логічний розділ (ext4, roku_lv0), куди монтується /var (віртуальні машини kvm наче будуть у /var/lib/libvirt).

на користувацьких машинках звик виділяти окремий розділ для /home, але тут не бачу сенсу цього робити. щодо свопа — думав, чи потрібно стільки на сервері… але нехай буде: все-одно ssd завеликий для простої хост-машини під kvm.

розподіл дисків під гіпервізор kvm

для чистоти експерименту не встановлюю стільницю (потрібно прибрати галочку біля debian desktop environment не етапі software selection, інакше затягнеться gnome за замовчуванням), лише сервер ssh.

↖ до змісту

0.3. налаштування «дрібничок»

після перезавантаження тестовий сервер майже готовий… але ще рано відключати монітор: потрібен доступ по ssh, але за якою адресою? за замовчуванням debian питає dhcp, і вдома для простоти я уникаю статичних адрес, тож найперший крок — занотувати адреси mac обох мережевих адаптерів (cm6340 має eth та wifi) і зафіксувати x.x.x.6/24 для сервера (roku — шість японською).

з інших необхідних налаштувань:

традиційне поновлення пропускаю (бо встановлював з образу netinst, він тягне все нове):

#> apt-get update && apt-get upgrade

sudo — встановити й додати себе до відповідної групи (знадобиться вийти/зайти):

#> apt-get install sudo && adduser tivasyk sudo

path — «з коробки» debian 10 має «криве» налаштування path, і команди з /usr/sbin не знаходяться (зокрема, fdisk); лікується додаванням рядка до ~/.bashrc:

PATH=$PATH:/usr/sbin

ssh — «з коробки» дозволяє підключення root’а, бажано одразу «поремонтувати» (PermitRootLogin no в конфігу /etc/ssh/sshd_config) і перезавантажити сервіс:

#> systemctl restart sshd

lf — (опційно) простий і вже звичний для мене файловий мереджер для консолі (увага! розпаковування першого ліпшого бінарника просто до /usr/bin — прямий шлях до нехороших наслідків):

$> wget -qO- https://github.com/gokcehan/lf/releases/latest/download/lf-linux-amd64.tar.gz | sudo tar -C /usr/bin -zxvf -

tcpdump ― (опційно?) гадаю, що знадобиться на якомусь етапі, щоби траблшутити мережу з віртуальними машинами… враховуючи, що в мене до цього часу був лише куций досвід з iptables:

#> apt-get install tcpdump

drill — (опційно?) ще один інструмент, який може знадобитися (аналог nslookup, віндузятники):

#> apt-get isntall ldnsutils

здається, це все про підготовку: є доступ по ssh, можна відключити монітор і братися до першого завдання.

↖ до змісту

1. гіпервізор з kvm

задача: «1. Set up a KVM hypervisor» (reddit).

1.1. встановлення гіпервізора

перевірку підтримки віртуалізації можу пропустити, але для повноти картини:

#> if [[ $(grep "vmx\|svm" -c /proc/cpuinfo) -gt 0 ]]; then echo "OK"; fi
OK

гуглив якусь зрозумілу (не примітивну) підказку зі встановлення kvm в debian’і — знаходяться переважно злизані індійськими одмінами одне в одного «сутри», де бракує пояснень і важливих деталей, і починаються з пропозиції зробити apt-get install kvm, що є повна маячня в сучасному debian’і… більше довіри маю до вікі debian.

встановлення лише потрібного, без «рекомендацій» (які намагаються затягнути купу непотребу для стільничого середовища, зайві 230 мб):

#> apt-get install --no-install-recommends qemu-kvm libvirt-clients libvirt-daemon-system virtinst

/i\ згодом виявиться (див. 1.2.7.спроба встановлення віртуальної машини), що потрібен ще qemu-utils.

перевірка, чи працює демон libvirt (повинен бути active (running)):

#> systemctl status libvirtd

дати доступ собі (не root) до консолі гіпервізора (virsh):

$> sudo adduser $USER libvirt

перевірка доступу:

$> virsh --connect qemu:///system list --all

команда працює; очікувано, перелік порожній: віртуальних машин ще немає. здається, це був найпростіший крок з усього задачника.

/i\ ще розбираюся з усім цим, але… якщо забути про --connect qemu:///system, вірш працює з контекстом (сесією) поточного користувача.

↖ до змісту

1.2. налаштування віртуальної мережі

на цьому етапі я сильно задумався, вивчаючи варіанти налаштування віртуальної мережі для тестовго стенду… найдетальнішою підказкою з переліку видається «libvirt networking handbook»; з перелічених там п’яти варіантів, вагаюся між натованою і маршрутизованою мережами: найбільшого бубна вимагає (і обіцяє найдовшу бороду) натована мережа — отже, це найцікавіше.

/i\ довідник arch linux тішить детальною статтею про налаштування мережевих мостів на linux: brctl не потрібен (тому й не йде з debian тепер) — достатньо нового «швейцарського ножика» ip:

## brctl addbr br0 (застаріло, але працює, якщо встановити bridge-utils)
#> ip link add name br0 type bridge && ip link set br0 up

вихідні дані:

  • домашня мережа — 192.168.1.0/24 (але може бути будь-яка, для цього й обрав nat-ований варіант, щоби не торкатися конфігурації зовнішньої відносно тестлабу мережі);
    • сервер віртуалізації ― 192.168.1.6/24 (roku.lan, інтерфейс enp3s0);
    • шлюз (default route) — 192.168.1.1 (router.lan);
    • сервер dns (upstream) — 192.168.1.5 (pihole.lan);
  • віртуальна мережа — 192.168.101.0/24;
    • сервер віртуалізації / віртуальний маршрутизатор — 192.168.101.1/24 (інтефейс/міст virbr101);
    • віртуальні машини — 192.168.101.101..254.

накидав чернетку мережної схеми, час спробувати.

план віртуальної мережі

↖ до змісту

1.2.1. відключити мережу default?

за підказкою, найперше — відключити мережу default, яку libvirt (менеджер віртуалок на qemu/kvm) створює за замовчуванням. але видалити її не можна:

перевірка:

$> virsh --connect qemu:///system net-list --all
 Name      State      Autostart   Persistent
----------------------------------------------
default   inactive   no          yes

спроба видалення:

$> virsh --connect qemu:///system net-destroy default
error: Failed to destroy network default
error: Requested operation is not valid: network 'default' is not active

за потреби можна скасувати автостарт (але з коробки він відключений):

$> virsh --connect qemu:///system net-autostart --disable default

↖ до змісту

1.2.2. віртуальний міст з фіксованою mac-адресою

щоби обійти проблему з «випадковою» mac-адресою віртуального моста після перезавантаження (тиць), можна щоразу першим підключати «підставний» (dummy) інтерфейс з фіксованим mac-ом.

генеруємо випадковий mac (один раз); перші три байти 52:54:00 зафіксовано (стандартно для kvm), наступні три з /dev/urandom:

#> hexdump -vn3 -e '/3 "52:54:00"' -e '/1 ":%02x"' -e '"\n"' /dev/urandom
52:54:00:89:24:f2

створюємо «підставний» інтерфейс virbr101-dummy (можна не «піднімати»):

#> ip link add virbr101-dummy address 52:54:00:89:24:f2 type dummy

створюємо віртуальний міст virbr101, першим підключаємо до нього цей «підставний» інтерфейс і піднімаємо:

#> ip link add name virbr101 type bridge
#> ip link set virbr101-dummy master virbr101
#> ip link set virbr101 up

перевірка (див. mac-адресу моста virbr101):

$> ip link list type bridge
7: virbr101: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:89:24:f2 brd ff:ff:ff:ff:ff:ff

наступна проблема в тому, що всі ці налаштування діють лише до перезавантаження сервера; щоби зробити їх персистентними, потрібно додати ці налаштування до /etc/network/interfaces, або (краще) створити файл /etc/network/interfaces.d/virbr101 і додати все це туди:

# підставний інтерфейс для фіксування mac-адреси мосту virbr101
auto virbr101-dummy
iface virbr101-dummy inet manual
    pre-up /sbin/ip link add virbr101-dummy type dummy
    up /sbin/ip link set virbr101-dummy address 52:54:00:89:24:f2
# міст virbr101 для віртуальних машин kvm
auto virbr101
iface virbr101 inet static
    pre-up /sbin/ip link set virbr101-dummy up
    pre-up /sbin/ip link add virbr101 type bridge
    up /sbin/ip link set virbr101-dummy master virbr101
    address 192.168.101.1
    netmask 255.255.255.0

/i\ підказка використовує brctl для маніпуляцій з мостом — довелося переписати під ip.

після перезапуску сервера міст virbr101 повинен бути up і з фіксованою mac-адресою (type bridge опційно):

$> ip link list type bridge
5: virbr101: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:89:24:f2 brd ff:ff:ff:ff:ff:ff

↖ до змісту

1.2.3. маршрутизація ipv4

перевірка на сервері віртуалізації, чи ввімкнно маршрутизацію (мене цікавить лише ipv4):

$> cat /proc/sys/net/ipv4/ip_forward
0

альтернативно можна так:

$> sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

нулик в обох випадках означає, що маршрутизацію вимкнено. вмикаємо «на льоту» (не сплутати sysctl з systemctl):

#> sysctl -w net.ipv4.ip_forward=1

/i\ в підказці радять одразу ввімкнути параметр, що відповідає за маршрутизацію на всіх мережевих інтерфейсах — але схоже, що debian це робить сам, коли перемикати ip_forward, тож нема потреби робити руками (хіба що в інших дистрибутивах це налаштовано інакше з міркувань безпеки?):

#> sysctl -w net.ipv4.conf.all.forwarding=1

знадобиться зробити цю зміну персистентною (інакше — до перезавантаження), розкоментувавши відповідний рядо в /etc/sysctl.conf:

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

гаразд, на цьому етапі машина roku має три активних мережевих інтерфейси:

* локальна петля lo (127.0.0.1/24);
* фізичний enp3s0 (192.168.1.6/24);
* віртуальний міст virbr101 (192.168.101.1/24).

↖ до змісту

1.2.4. трансляція адрес (nat-ування) за допомогою iptables

чи не найцікавіший короткий, але досить детальний посібник з iptables знайшовся на booleanworld.com.

debian має netfilter/iptables «з коробки», але конфігурація порожня (за винятком стандартної політи ки accept) — все відкрито, без nat-ування ані маршрутизації:

#> iptables -t filter -L -v
#> iptables -t nat -L -v
#> iptables -t mangle -L -v
#> iptables -t raw -L -v

послідовність застосування таблиць/ланцюжків iptables

за трансляцію адрес ip (nat) відповідає, питомо, таблиця nat. найперше, забороняю nat-ування для мультикасту (224.0.0.0/24) та броадкасту (255.255.255.255/32):

#> iptables -t nat -A POSTROUTING -s 192.168.101.0/24 -d 224.0.0.0/24 -j RETURN
#> iptables -t nat -A POSTROUTING -s 192.168.101.0/24 -d 255.255.255.255/32 -j RETURN

налаштовую nat-ування для решти вихідних пакетів на всі адреси, крім віртуальної мережі (! -d 192.168.101.0/24); підказка дає три правила: для tcp, для udp і одне загальне… але хіба не достатньо одного, третього?

#> iptables -t nat -A POSTROUTING -s 192.168.101.0/24 ! -d 192.168.101.0/24 -j MASQUERADE

/i\ є різниця між snat та masquerade: перший швидший, другий універсальніший (працює з динамічним ip на зовнішньому інтерфейсі).

саме час щось випробувати — наприклад, чи працює nat-ування. скидаємо в нуль лічильники пакетів iptables для таблиці nat і перевіряємо нулики:

#> iptables -t nat -Z ; iptables -t nat -L POSTROUTING -v
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all  --  any    any     192.168.101.0/24     base-address.mcast.net/24 
    0     0 RETURN     all  --  any    any     192.168.101.0/24     255.255.255.255     
    0     0 MASQUERADE  all  --  any    any     192.168.101.0/24    !192.168.101.0/24

пінгуємо щось зовнішнє (приміром, google’івський dns 8.8.8.8) з адреси у віртуальній мережі (192.168.101.1):

$> ping -c 1 -I 192.168.101.1 8.8.8.8

…і перевіряємо дві речі: а) пінг проходить, і б) лічильник натованих пакетів збільшився на 1 (до речі, навіть якщо пакетів icmp пройшло більше, ніж один — спробувати -c 10 в ping’у, результат той самий; я маю розібратися, чому):

#> iptables -t nat -L POSTROUTING -v
Chain POSTROUTING (policy ACCEPT 7 packets, 758 bytes)
pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all  --  any    any     192.168.101.0/24     base-address.mcast.net/24 
    0     0 RETURN     all  --  any    any     192.168.101.0/24     255.255.255.255     
    1    84 MASQUERADE  all  --  any    any     192.168.101.0/24    !192.168.101.0/24 

якщо завчасу запустити tcpdump (в сусідньому терміналі) на зовнішньому інтерфейсі сервера (enp3s0), можна побачити цей nat-ований пакет і відповідь:

#> sudo tcpdump -nn -v -i enp3s0 icmp
tcpdump: listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:53:05.305188 IP (tos 0x0, ttl 64, id 20676, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.6 > 8.8.8.8: ICMP echo request, id 9271, seq 1, length 64
15:53:05.308152 IP (tos 0x0, ttl 118, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.1.6: ICMP echo reply, id 9271, seq 1, length 64

/i\ справді, лише перший пакет icmp «клікає» лічильник nat-ованих пакетів iptables…

↖ до змісту

1.2.5. фільтрація трафіка між віртуальною та фізичною мережами за допомогою iptables

налаштовую фільтрацію пакетів (це опційно для домашнього тестлабу, ізольваного від злих хакерів домашнім шлюзом) між віртуальною (virbr101, 192.168.101.0/24) і зовнішньою (домашньою) мережами:

## дозволити вхідний трафік за встановленими підключеннями
#> iptables -t filter -A FORWARD -d 192.168.101.0/24 -o virbr101 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
## дозволити весь вихідний трафік для мережі 192.168.101.0/24
#> iptables -t filter -A FORWARD -s 192.168.101.0/24 -i virbr101 -j ACCEPT
## дозволити весь трафік між віртуальними машинами
#> iptables -t filter -A FORWARD -i virbr101 -o vrbr101 -j ACCEPT
## заборонити все інше з/до віртуальної мережі
#> iptables -t filter -A FORWARD -i virbr101 -j REJECT
#> iptables -t filter -A FORWARD -o virbr101 -j REJECT

/i\ мені здається, що обмежувати все настільки сильно (лише одна мережа 192.168.101.0/24 на віртуальному мості) — зайве для тестлабу: складніше розбиратися, якщо коли щось піде не так… я би спробував зробити простіше, помінявши порядок для надійности (але поки що залишу варіант за підказкою вище):

## дозволити весь внутрішній трафік у віртуальній мережі
#> iptables -t filter -A FORWARD -i virbr101 -o virbr101 -j ACCEPT
## дозволити вхідний трафік за встановленими підключеннями
#> iptables -t filter -A FORWARD -o virbr101 -m conntrack --ctstate RELATED, ESTABLISHED -j ACCEPT
## дозволити весь (!) вихідний трафік
#> iptables -t filter -A FORWARD -i virbr101 -j ACCEPT
## заборонити весь неврахований вхідний трафік
#> iptables -t filter -A FORWARD -i virbr101 -j REJECT

перевірка:

#> iptables -t nat -L -v
#> iptables -t filter -L -v

якщо щось пішло не так — скинути і переробити:

#> iptables -t nat -F
#> iptables -t filter -F

↖ до змісту

1.2.6. персистентна конфігурація iptables

все це прекрасно, але налаштування iptables «живуть» до перезавантаження сервера. найпростіший спосіб для debian — встановити iptables-persistent і зберегти налаштовані правила до файлу /etc/iptables/rules.v4 (для ipv4) за допомогою iptables-save:

#> apt-get install iptables-persistent
...
#> iptables-save > /etc/iptables/rules.v4

/i\ на centos 6 робиться інакше.

друга команда працює від root’а, але для sudo треба інакше:

$> sudo sh -c 'iptables-save > /etc/iptables/rules.v4'

тепер після перезавантаження — всі правила на місці.

далі підказка радить опційно запустити dhcp та dns (dnsmasq) для віртуальної мережі — але я навмивно цього не робитиму: обидва сервіси є в задачнику (див. задачу 3). також поки що не морочитимуся із прокиданням портів до віртуальних машин. тож… на цому етапі гіпервізор з віртуальною мережею має бути готовий.

↖ до змісту

1.3. керування гіпервізором

1.3.1. спроба встановлення віртуальної машини

спробую запустити віртуалку за підказкою, починаючи з кроку 4.

найперше — знайти поточний образ centos 7 замість згаданого у підказці. далі — завантажую до /var/lib/libvirt/boot/:

#> cd /var/lib/libvirt/boot/
#> wget wget https://mirrors.edge.kernel.org/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-2003.iso

спробую встановити:

#> virt-install \
--virt-type=kvm \
--name centos7 \
--ram 2048 \
--vcpus=1 \
--os-variant=rhel7 \
--hvm \
--cdrom=/var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso \
--network bridge=virbr101,model=virtio \
--nographics \
--disk path=/var/lib/libvirt/images/centos7.qcow2,size=16,bus=virtio,format=qcow2

отримую помилку:

ERROR    Couldn't create storage volume 'centos7.qcow2': 'internal error: creation of non-raw file images is not supported without qemu-img.'

гаразд, принаймні зрозуміло, чого бракує: qemu-img (з пакунка qemu-utils) для підтримки формату qcow2 (детальніше про форати вже бачив у «kvm virtualization cookbook»):

#> apt-get install qemu-utils

пробую ще раз — отримую, серед іншого, попередження:

WARNING  CDROM media does not print to the text console by default, so you likely will not see text install output. You might want to use --location. See the man page for examples of using --location with CDROM media

…і, як обіцяли, отримую мовчазну консоль після такого:

Starting install...
Allocating 'centos7.qcow2'                                                                                                                                           |  16 GB  00:00:03     
Connected to domain centos7
Escape character is ^]

/!\ що відбувається? встановлення з локального образу iso, підключеного як оптичний диск (--cdrom=...), не підтримує вивід в текстову консоль. што?! в тенетах пишуть, що можна спробувати --location і шлях до локального файлу (або навіть до образу онлайн) як альтернативний метод, і що це працює для centos 7.

але спершу треба «прибрати сміття». підглядаю, чи невдало створена віртуалка centos7 ще крутиться:

$> virsh --connect qemu:///system list --all
Id   Name      State
--------------------------
-    centos7   shut off

підглядаю (якщо забув), в якім файлі вона зберігається:

$> virsh --connect qemu:///system dumpxml --domain centos7 | grep 'source file'
    <source file='/var/lib/libvirt/images/centos7.qcow2'/>

в моєму випадку машину зупинено, але якби крутилася — довелося б зупинити (чемно — командою shutdown, примусово — destroy):

$> virsh --connect qemu:///system destroy centos7

коли віртуалка shut off, видаляю:

$> virsh --connect qemu:///system undefine centos7
Domain centos7 has been undefined

залишиться прибрати файл centos7.qcow2 з теки /var/li/libvirt/images/, але я спробую зараз перевикористати його для нової спроби, з –location:

#> virt-install \
--virt-type=kvm \
--name centos7 \
--ram 2048 \
--vcpus=1 \
--os-variant=rhel7 \
--hvm \
--location=/var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso \
--network bridge=virbr101,model=virtio \
--nographics \
--disk path=/var/lib/libvirt/images/centos7.qcow2,size=16,bus=virtio,format=qcow2

і отримую ще одне попередження:

WARNING  Did not find 'console=ttyS0' in --extra-args, which is likely required to see text install output from the guest.

гуглю, знаходжу згадки про --extra-arguments console=ttyS0 для перенаправлення текстового виводу, з поясненням щодо недоступности параметра для джерела --cdrom. зупиняю, видаляю, пробую ще раз:

#> virt-install \
--virt-type=kvm \
--name centos7 \
--ram 2048 \
--vcpus=1 \
--os-variant=rhel7 \
--hvm \
--location=/var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso \
--network bridge=virbr101,model=virtio \
--nographics \
--disk path=/var/lib/libvirt/images/centos7.qcow2,size=16,bus=virtio,format=qcow2 \
--extra-args console=ttyS0

нарешті, цього разу анаконда жере мою консоль! отримую текстовий інсталятор centos в консолі!

встановлення centos 7 в текстовій консолі на гіпервізорі qemu/kvm

продовжую:

  • налаштування мережі:
    • інтерфейс: eth0;
    • ім’я вузла (hostname): vm0;
    • адреса ip: 192.168.101.100 (маска 255.255.255.0);
    • шлюз (gateway): 192.168.101.1 (адреса севера roku на мості virbr101);
    • сервери dns: 8.8.8.8,8.8.4.4 (google для простоти).
  • (віртуальний) диск для встановлення:
    • диск: vda (16 гб) — створений за допомогою --disk... з макс. розміром size=16 під час встановлення;
    • розподіл: весь диск (use all space), простий розділ (можна lvm, але lvm thin provsioning не працюватиме з libvirt, кажуть)

решта самодокументоване (не забути пароль root’а і додати користувача). через деякий час анаконда каже: installation complete, і після перезавантаження віртуалки бачу запрошення залогінитися.

перевірки:

$> uname -a
$> ip address 
$> ping -c 1 8.8.8.8

…і, нарешті, з сервера roku (мій сервер віртуалізації) логінюся до vm0 (192.168.101.100) по ssh — все працює. зупиняю тестову віртуалку, щоби звільнити ресурси:

$> virsh --connect qemu:///system shutdown centos7

на цьому перший пункт задачника з адміністрування linux виконано: гіпервізор qemu/kvm встановлено й налаштовано.

встановлення centos 7 в текстовій консолі на гіпервізорі qemu/kvm

↖ до змісту

1.3.2. аварія: випадково видалив віртуальну машину

/!\ сьогодні моя звичка друкувати швидко позбиткувалася з мене: видаляючи вчергове тестову віртуальну машину, замість vm3 надрукував… vm2:

roku #> virsh --connect qemu:///system undefine vm2

на vm2 в мене вже був сервер dhcp/dns… що робити?

на щастя, машина крутилася в цей час (зупинена була третя, а видалив визначення другої) — і продовжила крутитися, просто з persistent вона стала transient; такі машини існують до зупинки, або до перезавантаження сервера віртуалізації. машину можна відновити, якщо експортувати визначення (xml), поки вона не зупинилася:

roku #> virsh --connect qemu:///system dumpxml vm2 > /tmp/vm2.xml
roku #> virsh --connect qemu:///system define /tmp/vm2.xml

перевірка: машина повинна з’явитися у переліку персистентних:

roku #> virsh --connect qemu:///system list --all --persistent

опційно: не забути видалити vm2.xml у тимчасовій теці.

↖ до змісту

2. сервер spacewalk

задача: «2. inside of that kvm hypervisor, install a spacewalk server. use centOS 6 as the distro for all work below. (for bonus points, set up errata importation on the centos channels, so you can properly see security update advisory information)» (r/linuxadmin)

/i\ проект spacewalk зупинено в травні 2020, а centos 6 застарів (реліз 2011, підтримка лише до листопада 2020). але я принаймні спробую встановити згадані в задачнику версії; якщо ж не вийде — оберу новіший дистрибутив і якийсь інший інструмент автоматичного конфігурування для linux.

2.1. встановлення centos 6

мінімальні системні вимоги для сервера spacewalk (за документацією):

  • оперативна пам’ять 2 гб;
  • дисковий простір — 27 гб (округлюю до 30 гб):
    • система — 3 гб (3× мінімум для centos 6)
    • база данних ― 9 гб (3×1 гб на типовий «канал», 20×250 кб на клієнтську машину)
    • сховище пакунків — 15 гб (3× мінімум для типового каналу redhat/centos)

/i\ в задачнику згадано 21 віртуальну машину, включаючи сервер spacewalk; здається, треба завчасу думати про 32 гб оперативної пам’яті на тестовому сервері…

шукаю й завантажую мінімальний образ centos 6 (на roku):

#> cd /var/lib/libvirt/boot/
#> wget https://mirrors.edge.kernel.org/centos/6/isos/x86_64/CentOS-6.10-x86_64-minimal.iso

встановлюю centos 6 як vm1 з диском 30 гб у файлі vm1.qcow2:

#> virt-install \
--virt-type=kvm \
--name vm1 \
--ram 2048 \
--vcpus=1 \
--os-variant=rhel6 \
--hvm \
--nographics \
--location=/var/lib/libvirt/boot/CentOS-6.10-x86_64-minimal.iso \
--network bridge=virbr101,model=virtio \
--disk path=/var/lib/libvirt/images/vm1.qcow2,size=30,bus=virtio,format=qcow2 \
--extra-args console=ttyS0

інсталятор centos 6 не додає користувача (лише root) і не намагається налаштувати мережу… тож після перезавантаження доведеться «допиляти напилком» — тому не закриваю консоль і логінюся root’ом; найперше, мережа…

міняю hostname на vm1.lab (омфг, чому я не вивчив vi? в мінімальному centos 6 немає nano) у файлі /etc/sysconfig/network:

HOSTNAME=vm1.lab

перевіряю, що з мережевими інтерфейсами — маю eth0, але не налаштований, без адреси:

#> ip address

ремонтую, редагуючи файл /etc/sysconfig/network-scripts/ifcfg-eth0 (ключові поля — onboot=yes і далі):

DEVICE=eth0
HWADDR=52:54:00:7A:DA:A1
TYPE=Ethernet
UUID=a64b72f6-4736-4faa-9dc8-e4c422d727f2
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=none
IPADDR=192.168.101.101
PREFIX=24
GATEWAY=192.168.101.1
NAME="System eth0"

«пересмикую» мережевий сервіс:

#> service network restart

додаю гуглівські сервери dns та (опційно) локальний домен (lab) до /etc/resolv.conf:

domain lab
search lab
nameserver 8.8.8.8
nameserver 8.8.4.4

перевіряю, чи спрацювало (чи встановлено ip, чи пінгується шлюз (roku) і чи працює визначення доменних імен з гуглівськими dns’ами):

#> ip address
#> ping 192.168.101.1
#> ping google.com

все працює.

/i\ здається, конфігурацію dns та домену можна помістити а) до /etc/sysconfig/network-scripts/ifcfg-eth0, б) до /etc/sysconfig/network або до в) /etc/resolv.conf. хз, як найкраще; залишив те, що вже працює.

поновлюю систему:

#> yum update 

створюю собі користувача (tivasyk), додаю до групи wheel, і розкоментовую рядок %wheel ALL=(ALL) ALL в /etc/sudoers (канонічно — за допомогою visudo), щоби отримати шаманський бубен доступ до sudo:

#> adduser tivasyk
#> passwd tivasyk
#> usermod -aG wheel tivasyk
#> visudo

логінюсь із roku по ssh до нової віртуальної машини (192.168.101.101) як tivasyk, щоби перевірити, чи працює. перезавантажую віртуалку (суто заради доменного імені):

#> reboot

машина готова для спроби встановлення spacewalk.

↖ до змісту

2.2. встановлення spacewalk

2.2.1. перша спроба — гучний пшик!

за підказкою, додаю репозиторій spacewalk на щойно встановленій centos 6 (не переплутати версії системи, кутузов!):

vm1 #> yum install -y yum-plugin-tmprepo
vm1 #> yum install -y spacewalk-repo --tmprepo=https://copr-be.cloud.fedoraproject.org/results/%40spacewalkproject/spacewalk-2.10/epel-6-x86_64/repodata/repomd.xml --nogpg

встновлюю додаткові пакунки epel заради java (тільки якого біса підказка робить це за допомогою rmp, якщо канонічний шлях — yum?):

## rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm (краще за допомогою yum:)
vm1 #> yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm

за базу даних для spacewalk обираю найпростіший варіант — сервер postgresql, запакований спеціяльно для spacewalk:

vm1 #> yum -y install spacewalk-setup-postgresql

нарешті, пробую встановити власне сам spacewalk:

vm1 #> yum -y install spacewalk-postresql

тут centos на кільканадцять хвилин перемикається в режим пилосмока і затягує/встановлює купу всякого сміття (458 пакунків)… аж поки звітує: complete!

обов’язкове налаштування мережевого екрану (в тестлабі на roku все відкрито, але на віртуальній машині з centos все закрито «з коробки»). centos 6 використовує iptables (а пізніші версії — firewalld).

перевірка того, що вже є (--line-numbers додає номери):

vm1 #> iptables -t filter -L INPUT -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1      935 43462 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED 
2        0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            
3      687 41218 ACCEPT     all  --  lo     any     anywhere             anywhere            
4        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh 
5        0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited

для простоти можна було би видалити останнє правило (reject), але потреную навичку iptables, встромивши кілька правил перед останнім:

vm1 #> iptables -t filter -I INPUT 5 -p tcp --dport 80 -j ACCEPT
vm1 #> iptables -t filter -I INPUT 6 -p tcp --dport 443 -j ACCEPT
vm1 #> iptables -t filter -I INPUT 7 -p tcp --dport 5222 -j ACCEPT
vm1 #> iptables -t filter -I INPUT 8 -p udp --dport 69 -j ACCEPT

зберігаю зміни, щоби все було на місці після перезавантаження (робиться інакше, ніж для debian):

vm1 #> service iptables save

переходжу до налаштування spacewalk. перша ж заява підказки насторожує:

Your Spacewalk server should have a resolvable fully-qualified domain name (FQDN) such as ‘hostname.domain.com’. If the installer complains that the hostname is not the FQDN, do not use the –skip-fqdn-test flag to skip !

а от доменного імені віртуалка й не має: я використав гуглівський dns для налаштування мережі, котрий, звісно ж, не знає ні про який vm1.lab. пробую, тим не менш:

vm1 #> spacewalk-setup

…і все закінчується помилкою:

Tomcat failed to start properly or the installer ran out of tries.  Please check /var/log/tomcat6/catalina.out or /var/log/tomcat/catalina.$(date +%Y-%m-%d).log for errors.

здається, таки проблема у доменному імені (за звітом у /var/log/tomcat6/catalina.out):

2020-08-21 16:39:27,717 [main] ERROR net.sf.ehcache.Cache - Unable to set localhost. This prevents creation of a GUID. Cause was: vm1.lab: vm1.lab: Name or service not known
...

/!\ схоже, сервер dns в тестлабі знадобиться раніше за spacewalk — попри те, що в задачнику йде наступним пунктом. але ще погуглю трішки, перш ніж здаватися… як спроба надурити того котяру tomcat’а — додаю дещо до /etc/hosts:

127.0.1.1       vm1 vm1.lab
192.168.101.101 vm1 vm1.lab

тоді пробую ще раз, пропускаючи етап створення бази даних postgresql (бо інакше інсталятор сваритиметься):

vm1 #> spacewalk-setup --skip-db-install

/!\ знову помилка, але цього разу дещо інша:

Could not deploy SSL certificate.  Exit value: 1.
Please examine /var/log/rhn/rhn_installation.log for more information.

/!\ трохи потряс бубном (видалив пакунок rhn-org-httpd-ssl-key-pair-vm1.lab-1.0-1.noarch, на який скаржився конфігуратор), пробую ще раз — знову помилка tomcat6/catalina, але цього разу інша:

Aug 24, 2020 8:52:02 AM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type [null] (value [com.redhat.rhn.common.hibernate.ConnectionManager$1@4a7fd0c9]) and a value of type [null] (value [null]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
Aug 24, 2020 8:52:03 AM org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-127.0.0.1-8080

/!\ після цього сам сервіс spacewalk крутиться, але веб-сервер (httpd) — ні…

/usr/sbin/spacewalk-service status
postmaster (pid  4244) is running...
router (pid 4275) is running...
sm (pid 4283) is running...
c2s (pid 4291) is running...
s2s (pid 4299) is running...
tomcat6 (pid 4359) is running...                           [  OK  ]
httpd is stopped
osa-dispatcher dead but pid file exists
rhn-search is running (4537).
cobblerd (pid 4576) is running...
RHN Taskomatic is running (4603).

журнал каже, що йому бракує сертифікату spacewalk.crt, котрий я (баранисько) випадково видалив (не зберігши резервної копії) на попередньому етапі, намагаючись налаштувати spacewalk…

↖ до змісту

2.2.2. друга спроба

поки я ще відносно недалеко заблукав у нетрях, починаю встановлення сервера spacewalk від початку. зупиняю і видаляю віртуальну машину vm1, залишаючи файл vm1.qcow2:

roku #> virsh --connect qemu:///system destroy vm1
roku #> virsh --connect qemu:///system undefine vm1

далі за вже знайомою схемою:

  • перестворюю віртуальну машину vm1 і встановлюю centos 6;
  • налаштовую мережу (включно з vm1.lab до файлу /etc/hosts цього разу), користувача, тощо; поновлюю систему;
  • додаю необхідні репозиторії spacewalk;
  • встановлюю postgresql для spacewalk;
  • встановлюю spacewalk;
  • момент істини: запускаю конфігуратор spacewalk-setup

…і цього разу отримую:

Installation complete.
Visit https://vm1 to create the Spacewalk administrator account.

↖ до змісту

2.2.3. доступ до веб-інтерфейсу spacewalk

невеличка проблема в тому, що всередині тестлаба я не маю жодної машини з графічним інтерфейсом… як варіант — можу спробувати перенаправити запити на порти 80 (http) та 443 (https) зовнішнього мережевого інтерфейсу roku (192.168.1.6) до відповідних портів віртуальної машини vm1 (192.168.101.101):

roku #> iptables -t nat -A PREROUTING -d 192.168.1.6/32 -p tcp -m tcp --syn -m multiport --dports 80,443 -j DNAT --to-destination 192.168.101.101

заразом додам переадресацію порту 10122 до порту 22 віртуалки (ssh), щоби підключатся напряму (до цього підключався спершу до roku, а звідти — до віртуалки):

roku #> iptables -t nat -A PREROUTING -d 192.168.1.6/32 -p tcp -m tcp --syn --dport 10122 -j DNAT --to-destination 192.168.101.101:22

/i\ ще раз перевірити налаштування iptables на віртуалці vm1, бо centos «із коробки» досить закритий, як і личить корпоративному дистрибутиву на базі red hat.

і ось вона, магія шаманського бубна: https://192.168.1.6 в домашній мережі відповідає запрошенням spacewalk від щойно встановленої віртуалки vm1, з пропозицією налаштувати першого користувача.

веб-інтерфейс spacewalk, запрошення налаштувати користувача

↖ до змісту

2.3. налаштування spacewalk

найперше, як запропоновано — налаштовую користувача, котрий буде адміністратором spacewalk (тут головне — не забути пароль).

2.3.1. канали програмного забезпечення

далі, — за підказкою, — додаю два канали, і до кожного — основні репозиторії centos відповідної версії:

синхронізація репозиторіїв займає чимало часу; я, на жаль, запустив її з веб-інтерфейсу, і згодом намагався слідкувати, переглядаючи журнали (замість tail -F інколи зручніше less +G) — дуже дуже інформативно:

vm1 #> tail -F /var/log/rhn/reposync.log
vm1 #> tail -F /var/log/rhn/reposync/centos-7-parent.log

варто було для першої синхронізації скористатися консольним інструментом spacewalk-repo-sync. втім, рано чи пізно синхронізація закінчується, і spacewalk показує вміст каналів.

канали spacewalk після синхронізації репозиторіїв

/!\ тут виявилося, що 30 гб на диску під spacewalk було замало: канали пакунків відмовляються синхронізуватися, неможливо створити канал конфігурації, ба навіть встановити невеличкий додатковий інструмент (spacecmd) не вдалося через брак місця на диску:

vm1 #> sudo yum install spacecmd
...
Total download size: 246 k
Installed size: 1.2 M
Is this ok [y/N]: y
Downloading Packages:
Error Downloading Packages:
spacecmd-2.10.5-1.el6.noarch: Insufficient space in download directory /var/cache/yum/x86_64/6/spacewalk/packages
    * free   0 
    * needed 246 k

після перезавантаження postgresql звітує, що не може запуститися:

vm1 #> service postgresql status
postmaster is stopped

df каже, що диск заповнений на 100%:

vm1 #> df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
                    26G   26G     0 100% /

немає бази даних — не працює spacewalk, веб-інтерфейс, неможливо коректно видалити ані канал, ані завантажені пакунки, щоби звільнити трохи місця… дупа. перш ніж рухатися далі, час навчитися збільшувати розділи в файлах віртуальних машин.

↖ до змісту

2.3.2. збільшення дискового простору для віртуальної машини

по-перше, зупиняю vm1 (по-хорошому не хоче, зупинимо примусово):

roku $> virsh --connect qemu:///system destroy vm1 && virsh --connect qemu:///system list --all

для надійності — перевіряю, які файли образів використовує libvirt для віртуальної машини:

roku $> virsh --connect qemu:///system domblklist vm1
Target   Source
---------------------------------------------
vda      /var/lib/libvirt/images/vm1.qcow2
hda      -

інформація про файл vm1.qcow2:

roku #> qemu-img info /var/lib/libvirt/images/vm1.qcow2

трохи навчений, зберігаю копію образу vm1 (операція займає трохи часу):

roku #> cp /var/lib/libvirt/images/vm1.qcow2 /var/lib/libvirt/images/vm1.qcow2.bak

пробую збільшити розмір файлу (virtual size) qcow2 на 70 гб за допомогою qemu-img:

roku $> qemu-img resize /var/lig/libvirt/images/vm1.qcow2 +70G

на жаль, це лише початок. далі запускаю vm1 і перевіряю розмір віртуального диска (vda) — тепер 100 гб:

roku $> virsh --connect qemu:///system start vm1
roku $> ssh tivasyk@192.168.1.6 -p 10122
...
vm1 #> lsblk
NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0                        11:0    1 1024M  0 rom  
vda                       252:0    0  100G  0 disk 
├─vda1                    252:1    0  500M  0 part /boot
└─vda2                    252:2    0 29.5G  0 part 
├─VolGroup-lv_root (dm-0) 253:0    0 26.5G  0 lvm  /
└─VolGroup-lv_swap (dm-1) 253:1    0    3G  0 lvm  [SWAP]

мене цікавить отой VolGroup-lv_root, — це логічний том lvm lv_root, який належить до групи VolGroup і який змонтовано в корінь (/) віртуальної машини. де він фізично? з виводу lsblk можна здогадатися, що в розділі /dev/vda2 (фізичний том lvm), але перевірю:

vm1 #> pvscan
PV /dev/vda2   VG VolGroup        lvm2 [29.51 GiB / 0    free]
Total: 1 [29.51 GiB] / in use: 1 [29.51 GiB] / in no VG: 0 [0   ]

вгадав. детальніше про фізичний том:

vm1 #> pvdisplay /dev/vda2

розмір розділу — поки ще 29,51 гб. ще більше технічної інформації про розділ:

vm1 #> fdisk /dev/vda2

момент істини: спроба збільшити кореневий розділ віртуальної машини «на льоту» тепер за допомогою fdisk — для цього треба занотувати геометрію розділу, видалити його і перестворити на тому ж місці (first sector), але більшого розміру (last sector)…

vm1 #> fdisk /dev/vda

перелік розділів — p; занотовую переметри потрібного розділу (/dev/vda2):

Command (m for help): p
...
   Device Boot      Start         End      Blocks   Id  System
...
/dev/vda2            1018       62416    30944256   8e  Linux LVM

видаляю (d) другий (2) розділ і створюю наново (n) як primary (p) з тим самим номером (2):

Command (m for help): d
Partition number (1-4): 2

Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (1-208050, default 1): 1018
Last cylinder, +cylinders or +size{K,M,G} (1018-208050, default 208050): 
Using default value 208050

записую зміни на диск (w); fdisk попереджає про те, що ядро далі використовує застарілу копію таблиці розділів, і треба його повідомити про зміни. найпростіше — перезавантажитися. знову перевіряю, що каже lsblk про накопичувачі:

vm1 #> lsblk
NAME                        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0                          11:0    1 1024M  0 rom  
vda                         252:0    0  100G  0 disk 
├─vda1                      252:1    0  500M  0 part /boot
└─vda2                      252:2    0 99.5G  0 part 
├─VolGroup-lv_root (dm-0) 253:0    0 26.5G  0 lvm  /
└─VolGroup-lv_swap (dm-1) 253:1    0    3G  0 lvm  [SWAP]

розмір розділу /dev/vda2 тепер — 99,5 гб. але фізичний том lvm не збільшується автоматично (перевірка pvscan) — збільшую примусово:

vm1 #> pvresize /dev/vda2

і перевіряю:

vm1 #> pvscan
PV /dev/vda2   VG VolGroup        lvm2 [99.51 GiB / 70.00 GiB free]
Total: 1 [99.51 GiB] / in use: 1 [99.51 GiB] / in no VG: 0 [0   ]

група lvm автоматично збільшується разом з відповідним фізичним томом (перевірка vgdisplay). на черзі — збільшити розмір логічного тома lv_root так, щоби зайняти все вільне місце на фізичному томі (-l +100%FREE):

vm1 #> lvresize -l +100%FREE VolGroup/lv_root
Size of logical volume VolGroup/lv_root changed from 26.50 GiB (17920 extents) to 96.51 GiB (24706 extents).
Logical volume lv_root successfully resized.

залишилося тільки збільшити розмір файлової системи на логічному томі (бо я забув спробувати ключик -r для lvresize)…

vm1 #> resize2fs /dev/mapper/VolGroup-lv_root

підсумкова перевірка:

vm1 #> lsblk
NAME                        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0                          11:0    1 1024M  0 rom  
vda                         252:0    0  100G  0 disk 
├─vda1                      252:1    0  500M  0 part /boot
└─vda2                      252:2    0 99.5G  0 part 
├─VolGroup-lv_root (dm-0) 253:0    0 96.5G  0 lvm  /
└─VolGroup-lv_swap (dm-1) 253:1    0    3G  0 lvm  [SWAP]
...
vm1 #> df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
                    95G   26G   65G  29% /

перезапускаю машину, тримаючи кулаки, щоби все «піднялося»… здається, вдалося: веб-інтерфейс spacewalk знову працює.

веб-інтерфейс spacewalk знову доступний

/i\ не забути прибрати копію образу віртуальної машини (vm1.qcow2.bak), щоби не займала намарне місця:

vm1 #> rm /var/lib/libvirt/images/vm1.qcow2.bak

↖ до змісту

2.3.3. spacecmd — керування сервером spacewalk з командного рядка

гадаю, цей інструмент знадобиться згодом, щоби не пацькати руки щоразу веб-інтерфейсом (на centos 6 без python-argparse лається і не працює):

vm1 #> yum install spacecmd python-argparse

перевірка, чи працює (перший раз потребує автентифікації, зберігає логін та хеш пароля до ~/.spacecmd/vm1.lab/session):

vm1 $> spacecmd softwarechannel_list
INFO: Connected to https://vm1.lab/rpc/api as tivasyk
centos6

↖ до змісту

2.4. бонус: імпорт errata для centos до spacewalk

найперше — встановлюю wget на сервері spacewalk (здивований, що мінімальний centos 6 іде без цієї перлини):

vm1 #> yum -y install wget 

завантажую розумний perl-скрипт errata-import.pl від стіва мейєра:

vm1 #> wget https://github.com/stevemeier/cefs/raw/master/errata-import.pl

через веб-інтерфейс створюю користувача errata з простим паролем (qwerty згодиться) спеціяльно для скрипта; в налаштуваннях цьому користувачеві треба призначити роль «channel administrator».

/i\ знадобиться довстановити ще дещо із залежностей скрипта:

vm1 #> yum -y install perl-Frontier-RPC perl-Text-Unidecode perl-XML-Simple

пробний запуск:

vm1 #> env -i SPACEWALK_USER=errata SPACEWALK_PASS='qwerty' /root/bin/errata-import.pl --server localhost --errata errata.latest.xml --publish

/!\ …i отримую помилку: ERROR: errata.latest.xml is not an errata file! — само собою, я щось не врахував; перечитую ще раз (скупу) підказку з використання скрипта, і здогадуюсь: файл errata треба завантажувати окремо!

vm1 #> wget -N -O /root/errata.latest.xml https://cefs.steve-meier.de/errata.latest.xml
vm1 #> env -i SPACEWALK_USER=errata SPACEWALK_PASS='qwerty' /root/errata-import.pl --server localhost --errata /root/errata.latest.xml --publish

/i\ wget потребує опції -O, щоби примусово перезаписати файл errata.latest.xml, якщо вже існує (інакше створить копію, додавши .1, .2 тощо до назви); ключ -N змушує завантажувати лише поновлений файл повідомлень (менший трафік).

наприкінці скрипт звітує про помилку 500 read timeout (розібратися згодом?), але головне: веб-інтерфейс тепер показує перелік повідомлень про поновлення пз.

повідомлення errata для centos у веб-інтерфейсі spacewalk

залишилося автоматизувати періодичне (що п’ятниці о 23:00) поновлення цих повідомлень за допомогою crontab -e (і, опційно, звіт до /var/log/messages):

23 0 * * 5      wget -N -O /root/errata.latest.xml https://cefs.steve-meier.de/errata.latest.xml && env -i SPACEWALK_USER=errata SPACEWALK_PASS='qwerty' /root/errata-import.pl --server localhost --errata /root/errata.latest.xml --publish && logger "CentOS errata imported to Spacewalk (maybe)"

перевірка планувальника:

vm1 #> crontab -l

на цьому другий пункт задачника виконано.

↖ до змісту

3. сервер dhcp/dns

цитата: «create a vm to provide named and dhcpd service to your entire environment. set up the dhcp daemon to use the spacewalk server as the pxeboot machine (thus allowing you to use cobbler to do unattended os installs). make sure that every forward zone you create has a reverse zone associated with it. use something like “internal.virtnet” (but not “.local”) as your internal dns zone» (r/linuxadmin)

3.1. віртуальна машина vm2

основні параметри для віртуального сервера dhcp/dns на centos 6 (на основі мінімальних системних вимог):

  • оперативна пам’ять: 1 гб (згодом можна додати або відняти);
  • дисковий простір: 10 гб (мінімум 5 гб).

образ для встановлення вже завантажено; створюю нову віртуалку (vm2):

roku #> virt-install \
--virt-type=kvm \
--name vm2 \
--ram 1024 \
--vcpus=1 \
--os-variant=rhel6 \
--hvm \
--nographics \
--location=/var/lib/libvirt/boot/CentOS-6.10-x86_64-minimal.iso \
--network bridge=virbr101,model=virtio \
--disk path=/var/lib/libvirt/images/vm2.qcow2,size=10,bus=virtio,format=qcow2 \
--extra-args console=ttyS0

перезавантаження (поки що в консоль на roku), логін root’ом; налаштування мережі:

  • назва вузла: vm2.lab;
  • адреса ip: 192.168.101.102/24,
  • шлюз: 192.168.101.1;
  • dns: 8.8.8.8,8.8.4.4

додаю користувача tivasyk з правами sudo.

на сервері віртуалізації (roku) додаю переадресацію порту 10222 для ssh нової віртуальної машини (і зберігаю налаштування iptables):

roku #> iptables -t nat -A PREROUTING -d 192.168.1.6/32 -p tcp -m tcp --syn --dport 10222 -j DNAT --to-destination 192.168.101.102:22
roku #> iptables-save /etc/iptables/rules.v4

перевіряю підключення ssh всередині віртуальної мережі (з roku) та зі зовні (з іншої машини в зовнішній, домашній мережі).

↖ до змісту

3.2. реєстрація клієнта на сервері spacewalk

3.2.1. створення ключа активації

найперше — на сервері spacewalk (vm1) створюю загальний ключ активації, який буде загальний для всіх клієнтських машин на centos 6; замість лізти на веб-інтерфейс, зроблю за допомогою spacecmd (підказка про virtualization_host entitlement):

vm1 #> spacecmd activationkey_create
Name (blank to autogenerate): centos-6-multikey
Description [None]: CentOS 6 (x86_64) activation multikey
Base Channels
-------------
centos6
Base Channel (blank for default): centos6
virtualization_host Entitlement [y/N]: y
Universal Default [y/N]: y
INFO: Created activation key 1-centos-6-multikey

перевірка:

vm1 #> spacecmd activationkey_list
vm1 #> spacecmd activationkey_details 1-centos6-multikey

↖ до змісту

3.2.2. встановлення клієнта spacewalk

на майбутньому сервері dhcp/dns (vm2) — додаю репозиторій з клієнтом spacewalk для centos 6:

vm2 #> yum -y install https://copr-be.cloud.fedoraproject.org/archive/spacewalk/2.7-client/RHEL/6/x86_64/spacewalk-client-repo-2.7-2.el6.noarch.rpm

/i\ уважно з версіями; підказки часто дають посилання на centos 7 і не згадують шістку!

додаю репозиторій epel, встановлюю клієнт з необхідними залежностями й інструментами з epel:

vm2 #> yum -y install epel-release && yum -y update
vm2 #> yum -y install rhn-client-tools rhn-check rhn-setup rhnsd m2crypto yum-rhn-plugin

до файлу /etc/hosts додаю ім’я локального сервера spacewalk (vm1 та vm1.lab, можна з псевдонімом spacewalk та spacewalk.lab):

192.168.101.101  vm1 vm1.lab spacewalk spacewalk.lab

перевіряю, чи працює, за допомогою простого пінга:

vm2 $> ping spacewalk.lab

затягую сертифікат ssl просто з сервера spacewalk (на машині vm1 файл сертифікату й пакунок rmp можна знайти в /var/www/html/pub):

vm2 #> yum -y install http://spacewalk.lab/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm

↖ до змісту

3.2.3. реєстрація на сервері spacewalk

нарешті, пробую зареєструвати клієнта на сервері spacewalk з ключем активації 1-centos-6-multikey:

vm2 #> rhnreg_ks --activationkey 1-centos-6-multikey --serverUrl https://spacewalk.lab/XMLPRC

/!\ …і отримую помилку:

An error has occurred:
rhn-plugin: Error communicating with server. The message was:
Not Found
See /var/log/up2date for more information

дивно, але я спробував явно вказати файл сертифікату (на клієнті файл лежить в /usr/share/rhn) — і vm2 зареєструвався:

vm2 #> rhnreg_ks --serverUrl=https://spacewalk.lab/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1-centos-6-multikey

перевірка за допомогою spacecmd:

vm1 #> spacecmd system_list
INFO: Connected to https://vm1.lab/rpc/api as tivasyk
vm2.lab : 1000010000
...
vm1 #> spacecmd system_details vm2.lab

машину vm2 тепер видно й у веб-інтерфейсі spacewalk (systems > systems > all).

віртуальну машину vm2.lab зареєстровано на сервері spacewalk

/!\ але спроба поновити репозиторії на клієнтській машині перечіпляється через помилку:

vm2 #> yum update
Loaded plugins: fastestmirror, rhnplugin
...
Error: Cannot retrieve repository metadata (repomd.xml) for repository: centos6. Please verify its path and try again

за підказкою перевіряю, чи на місці файл repomd.xml для каналу centos6 на сервері spacewalk, — все виглядає добре:

vm1 #> ls -l ls /var/cache/rhn/repodata/centos6
filelists.xml.gz  other.xml.gz  primary.xml.gz  repomd.xml  updateinfo.xml.gz

за іншою підказкою пробую відключити https на користь http для up2date на клієнті vm2 (файл /etc/sysconfig/rhn/up2date):

## serverURL=https://spacewalk.lab/XMLRPC
serverURL=http://spacewalk.lab/XMLRPC

…і поновлення працює. отже, проблема десь із ssl? перевіряю ще раз все, що стосується ssl, у файлі конфігурації up2date за підручником… чомусь бракує рядка:

noSSLserverURL=http://spacewalk.lab/XMLRPC

додаю (повернувши рядок serverURL до початкового значення з https), пробую ще раз yum update — працює. гхм.

↖ до змісту

3.3. налаштування сервера dhcp/dns на базі dnsmasq

3.3.1. встановлення dnsmasq дистанційно зі spacewalk

бачу два поширених варіанти налаштування сервісів dhcp/dns:

  • bind + dhcpd — класична пара: більше можливостей, складніше налаштування;
  • dnsmasq — поєднує обидва сервіси (плюс tftp, pxe, але ці мають бути в мене на сервері spacewalk), простий в налаштуванні, але має чимало обмежень.

для початку спробую простіший dnsmasq (згодом, якщо знадобиться, заміню); «з коробки» в centos 6 немає, але встановлюється елементарно:

vm2 #> yum -y install dnsmasq

але! чому не спробувати встановити дистанційно, з сервера spacewalk? через веб-інтерфейс (systems > vm2.lab > software > install) планую поновлення репозиторіїв та встановлення dnsmasq — і чекаю (за замовчуванням, клієнти «чекіняться» на сервері що дві години).

заплановане поновлення репозиторіїв та встановлення dnsmasq для клієнта vm2

через півгодини обидві задачі опиняються в історії завдань (systems > vm2.lab > events > history) із зеленими галочками (виконано). можна братися до налаштування сервісів.

заплановане дистанційне встановлення пакунка на vm2 в переліку виконаних задач

↖ до змісту

3.3.2. налаштування dns з використанням dnsmasq

копія оригінального файлу з налаштуваннями dnsmasq, на випадок «аварії»:

vm2 #> cp /etc/dnsmasq.conf /etc/dnsmasq.conf.bak

налаштування; лише декотрі з рядків у /etc/dnsmasq.conf потребують зміни:

interface=eth0
listen-adress=::1,127.0.0.1,192.168.101.102
domain=lab
local=/lab/
address=/lab/127.0.0.1
expand-hosts
no-resolv
server=8.8.8.8
server=8.8.4.4

підсумкова перевірка файлу налаштувань:

vm2 #> dnsmasq --test
dnsmasq: syntax check OK.

видаляю зовнішні dns’и з /etc/resolv.conf — там повиннен залишитися лише один рядок з dns 127.0.0.1 (та ::1 для ipv6):

nameserver  127.0.0.1
nameserver  ::1

убезпечую /etc/resolv.conf від перезапису (network manager та деякі інші програми люблять таким займатися):

vm2 #> chattr +i /etc/resolv.conf

/i\ не всі файлові системи поважають прапорець -i (immutable), але ext4 серед слухняних. перевірка:

vm2 #> lsattr /etc/resolv.conf

гаразд, час запустити сервіс:

vm2 #> /etc/init.d/dnsmasq start

автозапуск на centos 6 налаштовується інакше, ніж на сучасних системах із systemd:

vm2 #> chkconfig --add dnsmasq
vm2 #> chkconfig dnsmasq on

перевірка (рівні 2-5 повинні бути on):

vm2 #> chkconfig --list | grep dnsmasq

перевіряю локально, на тій самій машині (знадобиться встановити ldns, щоби отримати доступ до drill; grep абсолютно опційний — аби скоротити вивід):

vm2 #> drill -4 google.com | grep -A1 "ANSWER SECTION"
;; ANSWER SECTION:
google.com.     42      IN      A       172.217.13.110

зворотній запис (-x):

vm2 #> drill -4 -x 192.168.101.101 | grep -A1 "ANSWER SECTION"
;; ANSWER SECTION:
101.101.168.192.in-addr.arpa.   0       IN      PTR     vm1.lab.

dnsmasq знає про google (та всі зовнішні ресурси), бо по все, що поза доменом lab, звертається до зовнішніх dns’ів (server=8.8.8.8); він знає про імена для адреси 192.168.101.101, бо я додав їх до /etc/hosts на цій машині (vm2), коли підключав її до spacewalk… але сам себе, приміром, не прорезолвить, бо цього запису немає в /etc/hosts! отже…

/i\ мірою додавання машин (зі статичними ip) до тестлабу, треба не забувати реєструвати їх (разом із псевдонімами) до /etc/hosts на віртуалці vm2:

192.168.101.1   router router.lab
192.168.101.101 vm1 vm1.lab spacewalk spacewalk.lab
192.168.101.102 vm2 vm2.lab dns dns.lab

/i\ локальні запити працюють, — але для запитів з інших машин потрібно відкрити порт 53 (dns) для протоколів tcp і udp (dns може використовувати обидва) на vm2. мене цікавить лише таблиця input (бо вихідна — відкрита на centos 6):

vm2 #> iptables -t filer -L INPUT --line-numbers
1    33963   42M ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED 
2        0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            
3       44  2602 ACCEPT     all  --  lo     any     anywhere             anywhere            
4        1    60 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh 
5        2   112 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited 

додаю два правила перед останнім reject‘ом, і зберігаю:

vm2 #> iptables -t filter -I INPUT 5 -p tcp --dport 53 -j ACCEPT
vm2 #> iptables -t filter -I INPUT 6 -p udp --dport 53 -j ACCEPT
vm2 #> service iptables save

перевірка з іншої машини в тестлабі — наразі в мене є лише vm1 (spacewalk) — answer section має містити ip ресурса (172.217.13.110), а поле server у частині additional section ― ip сервера dns (192.168.101.102):

vm1 #> drill -4 @192.168.101.102 google.com

працює; залишаю 192.168.101.102 єдиним сервером dns у файлі /etc/resolv.conf на машині vm1 (spacewalk). простий dns на базі dnsmasq готовий.

↖ до змісту

3.3.3. налаштування dhcp з використанням dnsmasq

dhcp вимагатиме відкритого порту 67/udp:

vm2 #> iptables -t filter -L INPUT -v --line-numbers
vm2 #> iptables -t filter -I INPUT 7 -p udp --dport 67 -j ACCEPT
vm2 #> service iptables save

налаштування dhcp — в тому ж файлі /etc/dnsmasq.conf (лише те, що не налаштовано ще для dns):

## важливо! це єдиний dhcp в тестовій мережі
dhcp-authoritative
## типовий шлюз (default gateway) — сервер віртуалізації roku
dhcp-option=3,192.168.101.1
## dns для клієнтів dhcp — vm2 (опційно, бо dnsmasq анонсує себе)
dhcp-option=6,192.168.101.102
## діапазон для роздачі ipv4: 150-250/24
dhcp-range=192.168.101.150,192.168.101.250,24h

перевіряю конфігурацію і перезавантажую сервіс:

vm2 #> dnsmasq --test
vm2 #> /etc/init.d/dnsmasq restart

для перевірки — спробую створити найменшу можливу віртуальну машинку test на centos 6 (512 мб оперативки, 5 гб дискового простору) і отримати ip по dhcp… для цього єдине, що треба зробити після завантаження — поміняти рядок onboot у файлі /etc/sysconfig/network-scripts/ifcfg-eth0 на yes і перезапустити мережевий сервіс:

test #> service network restart
...
Bringing up interface eth0:  
Determining IP information for eth0... done.
[  OK  ]

машина отримала адресу по dhcp:

test #> ip address
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:d9:40:20 brd ff:ff:ff:ff:ff:ff
    inet 192.168.101.169/24 brd 192.168.101.255 scope global eth

файл /etc/resolv.conf також змінений клієнтом dhcp і містить посилання на мій dns:

cat /etc/resolv.conf
; generated by /sbin/dhclient-script
search lab
nameserver 192.168.101.102

/i\ цікаво було би зрозуміти, чому перша (і єдина наразі — перевірив у файлі /var/lib/dnsmasq/dnsmasq.leases) видана адреса — 169, якщо діапазон задано 150-250? відповідь, що схожа на правду, знайшлася на superuser.com: аби знизити ймовірність зміни адреси, якщо клієнт «спізнився» з поновленням (буває, якщо клієнтські машини вимикаються надовго) — dnsmasq враховує хеш клієнтської mac-адреси, коли вибирає ip. якщо справді потрібно цього уникнути, і радше роздавати адреси послідовно — є опція dhcp-sequential-ip.

↖ до змісту

3.4. мережеве завантаження (pxe)

3.4.1. кікстарт на сервері spacewalk

vm1 правує за сервер spacewalk, котрий вміє робити kickstart за допомогою cobbler. спробую налаштувати.

## завантажую centos 6 до /tmp
vm1 #> wget -P /tmp/ ttps://mirrors.edge.kernel.org/centos/6/isos/x86_64/CentOS-6.10-x86_64-minimal.iso
## монтую завантажений образ в теку
vm1 #> mkdir /mnt/centos-6-minimal
vm1 #> mount -o loop /tmp/CentOS-6.10-x86_64-minimal.iso /mnt/centos-6-minimal
## створюю теку для kickstart'а
vm1 #> mkdir /var/distro-trees/
## копіюю туди вміст iso
cp -r /mnt/centos-6-minimal /var/distro-trees/ 

у веб-інтерфейсі spacewalk створюю дистро kickstart (system > kickstart > distributions > create…), і…

/!\ пшик: «the kernel could not be found at the specified location…» — при цьому vmlinuz точно є там, де spacewalk хоче його знайти.

помилка налаштування дистро kickstart

пригадую, що на очі траплялася заувага щодо selinux для цієї теки… але для spacewalk потрібен інший контекст selinuxspacewalk_data_t. пробую:

vm1 #> /usr/sbin/semanage fcontext -a -t spacewalk_data_t "/var/distro-trees(/.*)?"
vm1 #> /sbin/restorecon -R /var/distro-trees

після цього spacewalk побачив ядро і створив мені дистрибутив для kickstart’у.

мінімальний дистрибутив centos 6 для kickstart'у за допомогою spacewalk

стврюю профіль для kickstart’у: centos-6-minimal-kvm, тип віртуалізації — kvm virtalized guest, типове розташування (/ks/dist/org/1/centos-6-minimal), вказую пароль для root’а на встановлених системах. далі отримую екран налаштування віртуальної машини (через вибір типу віртуалізації, мабуть); з важливого тут (на кожній сторінці треба тиснути «update kickstart», якщо щось змінюється):

  • kickstart details
    • details
      • тип віртуалізації — kvm virtualized guest;
      • оперативна пам’ять — 1024 гб (завжди можна поміняти згодом);
      • дисковий простір — 10 гб (безпечний мінімум);
      • віртуальний міст — virbr101;
  • system details
    • gpl & ssl
      • rhn-org-trusted-ssl-cert
  • activation keys
    • 1-centos-6-multikey

здається, це все на боці spacewalk? здається, ще ні, бо spacewalk показує попередження: «the following packages are not available in any of the channels associated to this kickstart profile: rhn-client-tools, rhnsd, dnf-plugin-spacewalk, rhnlib, spacewalk-koan, spacewalk-koan*. in order for all kickstart functionality to work correctly, these packages should be present in at least one channel associated to this profile».

попередження про брак пакунків для kickstart

далі курю мануал читаю підказку… мені потрібен підканал (child channel) з кількома додатковими пакунками. підказка підказує (с) завантажити необхідні rpm’и і додати до підканалу руками… але чому не зробити те, для чого й придумали spacewalk — додати репозиторій і дозволити програмі робити справу? пробую — і чекаю, поки spacewalk затягне потрібні пакунки.

/!\ чекав довго — не вичекав: перелік пакунків репозиторія centos6kickstart порожній. журнал taskomatic (/var/log/rhn/rhn_taskomatic_daemon.log) містить криптичні повідомлення про 0 пакунків у репозиторії, відповідного журналу для reposync () немає… хз, що відбувається. спроба запустити spacewalk-repo-sync вручну:

vm1 #> spacewalk-repo-sync --channel centos6kickstart --type yum
ERROR: attempting to run more than one instance of spacewalk-repo-sync Exiting.

отже, процес десь крутиться, але жодного відгуку від нього в журналах немає… ризикну «прибити» його і пробую ще раз руками, вказавши ще й джерело для надійности:

vm1 #> killall spacewalk-repo-sync
vm1 #> spacewalk-repo-sync --channel centos6kickstart --type yum -u http://mirrors.maine.edu/spacewalk/2.9-client/RHEL/6/x86_64/ 

в консолі бачу, що 74 пакунки завантажилися, що журнал reposync.log містить згадку про початок синхронізації, а reposync/centos6kickstart.log — про реєстрацію в базі даних… але далі скрипт «зависає», здається:

Importing packages to DB:
    Importing packages:     |######--------------------------------------------| 12.16% 

перезавантаження сервіса postgresql і перезапуск синхронізації, здається, допомогли:

vm1 #> service postgresq restart
vm1 #> vm1 #> spacewalk-repo-sync --channel centos6kickstart --type yum -u http://mirrors.maine.edu/spacewalk/2.9-client/RHEL/6/x86_64/

дуже дивно, і мені це не подобаться, — сподіваюся, не доведеться ніколи підтримувати spacewalk в продакшні. важливо, що потрібні пакунки затяглися до підканалу.

підканал centos-6-kickstart містить 74 пакунки для kickstart

↖ до змісту

3.4.2. опція dhcp-boot для dnsmasq

dnsmasq має інтегровані сервери pxe та tftp для мережевого завантаження, але вони мені не потрібні; формат опції dhcp-boot дозволяє вказати сторонній сервер; пробую таке:

dhcp-boot=pxelinux.0,spacewalk.lab,192.168.101.101

час спробувати? якщо я все налаштував як слід — треба лише замінити --location=... (шлях до iso) замінити на коротке --pxe:

roku #> virt-install \
--virt-type=kvm \
--name vm3 \
--ram 1024 \
--vcpus=1 \
--os-variant=rhel6 \
--hvm \
--nographics \
--pxe \
--network bridge=virbr101,model=virtio \
--disk path=/var/lib/libvirt/images/vm3.qcow2,size=30,bus=virtio,format=qcow2 \

…і тиша: переметр --extra-args знову недоступний, в консолі нічого від віртуальної машини немає. на гіпервізорі бачу, що машина «крутиться»:

roku #> virsh --connect qemu:///system list --all
Id   Name   State
----------------------
4    vm1    running
6    vm2    running
8    test   running
9    vm3    running

…а на сервері dhcp бачу, що їй видано адресу (242, без імені вузла):

vm2 #> cat /var/lib/dnsmasq/dnsmasq.leases 
1598798240 52:54:00:37:96:8d 192.168.101.242 * 01:52:54:00:37:96:8d
1598797973 52:54:00:d9:40:20 192.168.101.169 test *

але машина не пінгується. поки що не придумав, як підглянути, що відбувається насправді. або я щось зробив не як слід, або… я все зробив не так як треба. пройдуся з перевіркою…

1) чи відкрито порт 69/udp (tftp) на сервері pxe (vm1.lab)? — так (і лічильник пакунків показує два запити):

vm1 #> iptables -t filter -L INPUT -v --line-numbers
Chain INPUT (policy ACCEPT 9 packets, 3576 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
...
8        2   136 ACCEPT     udp  --  any    any     anywhere             anywhere            udp dpt:tftp 

/i\ деякі підказки згадують 69/tcp, але це, гхм, дивно.

2) чи поновив я ключ активації centos-6-multikey, що його використовує kicktart centos-6-minimal, коли додав підканал/репозиторій для kickstart’у? — ні. хз, чи це допоможе, але — fixed.

3) чи працює сервіс tftp на сервері spacewalk (vm1.lab)? — так:

vm1 #> service xinetd status
xinetd (pid  1232) is running...

конфігурація (/etc/xinitd/tftp) підказує, що роздається тека /var/lib/tftpboot. вміст теки:

drwxr-xr-x. 2 root root 4096 Aug 28 18:50 aarch64
drwxr-xr-x. 2 root root 4096 Aug 28 18:50 etc
drwxr-xr-x. 2 root root 4096 Aug 28 18:50 grub
drwxr-xr-x. 3 root root 4096 Aug 28 18:50 images
drwxr-xr-x. 2 root root 4096 Aug 28 18:50 ppc
drwxr-xr-x. 2 root root 4096 Aug 28 18:50 pxelinux.cfg
drwxr-xr-x. 2 root root 4096 Aug 28 18:50 s390x

з сусідньої машини пробую забрати файл pxelinux.cfg/default — отримую permission denied:

roku $> tftp 192.168.101.101
tftp> get pxelinux.cfg
tftp: pxelinux.cfg: Permission denied

гхм, я намагаюся забрати файл до теки, куди я не маю права писати =) виправився:

roku $> tftp 192.168.101.101
Received 581 bytes in 0.0 seconds

дивлюся файл — схоже на меню завантаження:

DEFAULT menu
PROMPT 0
MENU TITLE Cobbler | http://fedorahosted.org/cobbler
TIMEOUT 200
TOTALTIMEOUT 6000
ONTIMEOUT local

LABEL local
        MENU LABEL (local)
        MENU DEFAULT
        LOCALBOOT 0

LABEL centos-6-minimal-kvm:1:Testlab
        kernel /images/centos-6-minimal:1:Testlab/vmlinuz
        MENU LABEL centos-6-minimal-kvm:1:Testlab
        append initrd=/images/centos-6-minimal:1:Testlab/initrd.img ksdevice=bootif lang=  kssendmac text  ks=http://127.0.1.1/cblr/svc/op/ks/profile/centos-6-minimal-kvm:1:Testlab
        ipappend 2

MENU end

чому там 127.0.1.1? дивно… здається, мені треба зробити перерву в експериментах і подумати:

  • знайти детальну, покрокову підказку щодо налаштування мережевого завантаження, щоби пройтися й перевірити замість блукати навпомацки?
  • як достукатися до інтерфейсу віртуальної машини на етапі, коли систему ще не встановлено і ані ssh, ані текстовий термінал не доступні?
  • спробувати виключити з рівняння spacewalk і налаштувати якийсь найпростіший варіант, суто на dnsmasq?

далі буде…

↖ до змісту

додатки

використані довідкові матеріяли

те, що мені видалося найкращим (найповніше, найзрозуміліше пояснено тощо) — позначив /!\.

віртуалізація з qemu/kvm
налаштування віртуальної мережі для qemu/kvm
зміна розміру розділів, фізичних та логічних томів lvm
налаштування iptables
spacewalk
dnsmasq: сервер dhcp/dns

оригінальний допис на r/linuxadmin

оригінальний допис на r/linuxadmin

перелік віртуальних машин

формат: задача: роль ×кількість

  • 2: spacewalk ×1
  • 3: dns/dhcp ×1
  • 4: ldap ×2
  • 6: postgress ×2
  • 7: puppet ×1
  • 8: nfs ×1
  • 9: bakula ×1
  • 10: httpd ×2
  • 11: tomcat/jboss ×2
  • 12: http loadbalancer ×1
  • 13: postfix ×1
  • 14: nagios ×1
  • 15: syslog ×1
  • 16: centos clients ×3

↖ до змісту