Esetemben adott volt egy bare metal dedikált szerver hosting, ami nagyon kedvező feltételek mellett megkeresett, hogy szívesen tehermentesítené a tárcámat egy közösségi projektem hostolása kapcsán. Ez a lehetőség kapóra jött, mivel pont kerestem egy barátibb konfigot CI szervernek. Igen ám, de ahogy minden túl kecsegtető ajánlat, ez is hordozott magában egy kis csavart. Az elmúlt évek során a Debian/Ubuntu szerverek iránti imádatom átvándorolt a Fedora Server felé, így egyértelmű volt, hogy a leendő szerveren is Fedora fog futni.
Ám a hosting oldalát jobban áttanulmányozva nincs sehol lehetőség egyedi lemezképről telepíteni a vasat, az elérhető operációs rendszereik közt pedig sajnos a Debiantól a CentOS-on át a Windows Server 2019-ig minden volt, csak Fedora nem. Ami persze érthető, a legtöbb szervert bérlő cég (sajnos) nem a friss csomagokkal rendelkező és alaposan felkonfigurált, SELinuxos Fedorát fogja választani, hanem az ősrégi csomagokkal megáldott Debiant... 
Ilyenkor szoktam a B tervhez folyamodni, az összes hosting, amivel eddig dolgom volt biztosított egy rescue debian rendszert, ami RAM-ból fut. Ez azért jön kapóra, mert nem használja a diszkeket egyáltalán, amik így újraírhatóak teljesen, ha valamilyen úton-módon betölthető a Fedora telepítő. Ezt én a következő módon szoktam megtenni (példámban Fedora ISO-t bootolunk, de mással is működhet a dolog):
Letöltjük a kívánt lemezképet, mehet bárhova, ahol elfér:
wget https://download.fedoraproject.org/pub/fedora/linux/releases/32/Server/x86_64/iso/Fedora-Server-dvd-x86_64-32-1.6.iso -O lemezkep.iso
Aztán a trükk, hogy indítok egy qemu kvm virtualizált gépet, aminek felcsatolom mindkét SSD-m (ide fogjuk írni az operációs rendszert), a telepítő lemezképet, illetve megadok neki kellő mennyiségű RAM-ot és egy VNC elérést, amelyre később még szükség lesz:
Hirdetés
apt update && apt install qemu-system-x86
qemu-system-x86_64 -net nic -net user -m 2048M -enable-kvm -cpu kvm64,+nx -smp 2 -device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 -k en-us -cdrom lemezkep.iso -drive file=/dev/sda,format=raw -drive file=/dev/sdb,format=raw -vnc 127.0.0.1:0 -boot d
A parancsot ízlés szerint lehet paraméterezni, nem Szentírás. Iránymutatás céljából van beszúrva. 
Majd egy SSH port forwarddal a távoli SSH hoszton egyszerűen elérhető az 5900-as porton futó VNC session, amit egy tetszés szerint választott VNC klienssel bátran elérhetünk a localhost:5900 címen. Innentől pedig a telepítő bebootol, és elindul a normál telepítési folyamat. A korábban hozzáadott SSD-k kiválaszthatóak és egész nyugodtan felülírhatóak. A telepítési folyamat végeztével pedig bátran ki lehet lépni a telepítőből, be lehet zárni a VNC klienst és Ctrl+C-vel ki lehet lépni a qemu folyamatból is. Majd visszatérve a rescue Debian shellbe, egy reboot parancsot követően már az újonnan telepített OS-nak kell, hogy induljon.
Ez volt az elképzelés és tucatszor csináltam már ilyet. Sikerült is találni egy rescue Debiant a korábban említett hosting oldalán, de elakadtam. Ugyanis a qemu csak és kizárólag akkor működhet használható sebességgel, ha be van töltve a kernelbe a kvm modul. Viszont a host letiltotta a külső modulok támogatását, azaz esélytelennek tűnt a KVM boot. Ezek mellett nem is ramból futott, hanem egy read-only csatolás volt, 0 üres hellyel. A helyproblémát természetesen tucatnyi bindmounttal, vagy egy tmpfs-be tett írható chroottal ki lehetett volna küszöbölni, de mindezt minek, ha nem tudom a telepítőt elindítani.
Így a rescue mód lehetőségét kilőttem. Gondolkoztam sokat, hogy hogyan lehetne a helyzetemben megoldást találni. Adott 16 GB RAM, 2*480GB SSD RAID1-ben, amire telepíthetek Debiant, CentOS-t, Ubuntut. Az kizárt, hogy én bármit is netbootoljak, hiszen a host ad VNC elérést, de a bios-ra nincs rálátásom, PXE-t pedig csak úgy nem tudok bootolni. Bár privát hálózatot lehet létrehozni, a DNS szerver mindig a hostingé lesz, tehát a netboot ténylegesen esélytelen. Telepíthetnék mondjuk egy Ubuntut, SSH-n belépve letölthetném a Fedora lemezképet, szerezhetnék egy vmlinuz és initrd fájlt, majd egy extra grub configgal bootolhatnám a telepítőt, hiszen van VNC hozzáférésem és a grub bootot meg tudom már állítani. Az ISO pedig betölthető teljesen a RAM-ba, így az SSD-k felülírhatók. Ez a megoldás jónak is hangzott, viszont a VNC-n keresztüli telepítés nem volt éppen sikeres, mivel egér támogatás nincs és kényelmetlen lett volna a telepítés több perifériából fakadó egyéb hiba miatt.
Utólag eszembe jutott egy másik lehetséges út is, amit sajnos nem sikerült tesztelnem, de talán járható. Ebben az esetben kihasználnám, hogy RAID1-ben van 2 SSD-m a futó rendszer alatt. Debian fel a dedikált szerverre, majd apt install mdadm. Következhet egy rövid rátekintés a tömbökre a cat /proc/mdstat paranccsal, aztán lecsatolom az egyik szabadon választott array membert egy szimpla mdadm --fail /dev/sdxy paranccsal. A Debianom ettől még elvileg működőképes, tehát mehet neki a fentebb ecsetelt módon a qemu-s telepítés, annyi különbséggel, hogy itt csak 1 diszkkel, hiszen a Debiant még nem tudom felülírni. Viszont amiikor a telepítő lehetőséget ad rá, akkor a / partíciót RAID1-ként adom meg, egyelőre 1 db lemezzel. Majd a Debianba visszalépve a grub konfigot át tudom írni, hogy bootoljon a most készült Fedora-s partícióról, ahonnan boot után hozzá tudom adni a másik lemezt is az eddig egyszemélyes RAID1 "tömbömhöz".
De utólag okos az ember! Valószínűleg a legutóbbi megoldás sikerrel járhatott volna, csak nem jutott eszembe. Így maradt az eredeti elképzelés. Valahogy el kell érnem, hogy az OS a RAM-ban legyen, mindezt egy már SSD-ről bebootolt, futó rendszerből.
És akkor jöjjön a lényegi rész, a ténylegesen működő megoldás!
Egy rendszergazda barátom linkelte annak idején a takeover.sh nevű projektet, amely pontosan azt ígéri, amire nekem szükségem van. Egy bármilyen futó rendszert képes teljesen lecsatolni (természetesen a kernel megtartásával), majd egy RAM-ba töltött fájlrendszert indítani helyette. Ígéretes, de nem tűnt valami bőbeszédűnek a leírás és tele volt mindent saját felelősségre figyelmeztetéssel a Github oldal. 
Viszont ez a megoldás kivitelezhetőnek hangzott.
Tehát el is kezdtem a dedikált szerver telepítését. Kezdeti operációs rendszernek elvileg bármely telinit-et támogató linux disztribúció megtette volna, de az elsőként választott Ubuntum pont nem akart működni a telinit szkripttel (csak a 20.04 nem támogatja, a 18.04 még jó), így a végső választás a Debianra esett. Felment, a host megküldte az SSH belépési adatokat, sikerült is a belépés root SSH-n.
Tehát akkor szokásos friss Debian alatti package cache helyretevős parancsok:
apt update && apt upgrade -y
Majd el kell döntenünk, hogy tulajdonképpen mit szeretnénk a RAM-ba tölteni. Nekem a választásom a Debianra esett, ha már Debiant bootoltunk. Szerencsére van olyan lemezképe, amit kicsomagolva tudunk chrootként is használni. De első körben derítsük ki, hanyas Debian fut a vason, hanyasat érdemes letölteni:
root@localhost:~# cat /etc/os-release | grep VERSION
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
10-es buster Debian. Akkor keressük ki a megfelelő standard iso-t innen, hiszen ez a legfrissebb a cikk írása pillanatában: [link]
Meg is van a direkt link:
Töltsük is le a szerverre, majd csatoljuk fel:
cd ~ && wget https://cdimage.debian.org/mirror/cdimage/release/current-live/amd64/iso-hybrid/debian-live-10.4.0-amd64-standard.iso -O lemezkep.iso && mount lemezkep.iso /mnt
Ezután célszerű körülnézni a csatolásban:
root@localhost:~# ls /mnt/
boot d-i dists EFI isolinux live pool
root@localhost:~# ls /mnt/live/
config-4.19.0-9-amd64 initrd.img-4.19.0-9-amd64 vmlinuz-4.19.0-9-amd64
filesystem.squashfs System.map-4.19.0-9-amd64
root@localhost:~# du -sh /mnt/live/filesystem.squashfs
611M /mnt/live/filesystem.squashfs
Meg is van, amit kerestünk, a filesystem.squashfs fogja tartalmazni a számunkra szükséges Debian fájlrendszert. Most hozzunk létre egy mappát, ahova ki szeretnénk csomagolni:
mkdir /takeover
Csatoljunk rá egy tmpfs-t, hiszen a továbbiakban RAM-ban szeretnénk a fájlrendszert tárolni. Majd ellenőrizzük a méretét. Én 8 GB-ot adok neki, hiszen a következőekben kicsomagolt Debian jócskán felemészt majd 2 GB-ot, és majd a végleges ~3 GB méretű Fedora lemezképet is tárolni kell valahol. Mivel RAM van bőven, a 8 GB elégnek hangzik.:
root@localhost:~# mount -t tmpfs tmpfs /takeover -o size=8G
root@localhost:~# df -h /takeover
Filesystem Size Used Avail Use% Mounted on
tmpfs 8.0G 0 8.0G 0% /takeover
Most tegyük fel a squashfs-tools csomagot:
apt install squashfs-tools
És bontsuk ki a Debian fájlrendszert a /takeover mappába:
root@localhost:~# cd /takeover && unsquashfs -d ./ -f /mnt/live/filesystem.squashfs
Parallel unsquashfs: Using 24 processors
73619 inodes (80450 blocks) to write
[===========================================================\] 80450/80450 100%
created 64457 files
created 7687 directories
created 8637 symlinks
created 8 devices
created 0 fifos
root@localhost:/takeover# ls
bin etc initrd.img.old lib64 mnt root srv usr vmlinuz.old
boot home lib libx32 opt run sys var
dev initrd.img lib32 media proc sbin tmp vmlinuz
Csatoljuk le a Debian lemezt a /mnt elérési útról:
umount /mnt
Eddig minden rendben ment. 
A szkript leírása ezen a ponton javaslatot tesz a /lib/modules teljes eltávolítására, hiszen erre nem lesz szükség és sok helyet foglal (ha idegen kernelre van a modul, azaz a magic number nem egyezik, akkor be se fog töltődni, nekünk pedig mindvégig a host által eredetileg adott Debian kernelünk van betöltve, tehát a RAM-os rendszer moduljaival nem tudunk mit kezdeni):
rm -rf /takeover/lib/modules/*
Egy pillanat erejéig lépjünk be a kicsomagolt fájlrendszerre, hogy megbizonyosodhassunk, a dolog tényleg működőképes:
root@localhost:/takeover# chroot /takeover
root@localhost:/# exit
exit
root@localhost:/takeover#
Remek, ez is megvan! Lépjünk vissza a chrootba (nem is kötelező az előző lépésben kilépni), tegyünk fel SSH-t, hogy később be tudjunk lépni az új rendszerre (a parancsok soronként, egyesével lettek kiadva):
chroot /takeover
dhclient
apt update
apt install openssh-server -y
mkdir /run/sshd
sed -i s"|#PermitRootLogin prohibit-password|PermitRootLogin yes|" /etc/ssh/sshd_config
exit
Ezzel fent lesz az SSH a RAM rendszeren is és remélhetőleg majd működni is fog. Most, ahogy a takeover.sh leírás javasolja, töltsünk le egy megfelelő busybox binárist, innen: [link]
wget https://www.busybox.net/downloads/binaries/1.26.2-defconfig-multiarch/busybox-x86_64 -O /takeover/busybox && chmod +x /takeover/busybox
A következő feladat a takeover.sh letöltése, amit a következő parancsok sorban kiadásával lehet megtenni:
cd /takeover
apt install git -y
git clone https://github.com/marcan/takeover.sh ./takeover
mv ./takeover/* ./
mv ./takeover/.* ./
rm ./takeover/ -rf
A következő lépésben eltérek a takeover által javasolt úttól, ugyanis a takeover működéséhez le kell fordítani a fakeinit.c fájlt, amihez ők a gcc chrooton belüli használatát javasolják, hogy biztosan kompatibilis legyen a lefordított bináris a kívánt RAM-ból futó rendszerrel. Mivel a gcc nincs telepítve Debianra alapból és csak értékes RAM-ot rabolnék el magamtól, illetve pontosan tudom, hogy Debian 10 x64-ről fordítok Debian 10 x64-re, ezért elméletben nem kell aggódnom, a host is megfelel.
Tehát adjuk ki ismét sorban:
cd /takeover
apt install gcc -y
gcc fakeinit.c -o fakeinit -static
Végezetül adjuk ki a következő parancsot, ami szerkeszti magát a takeover.sh-t. Sajnos Debian host alatt erre mindenképpen szükség van a sikeres tty átirányítás miatt:
sed -i 's|^./busybox mount -t devpts devpts dev/pts|./busybox mount --bind /dev/pts dev/pts|' /takeover/takeover.sh
És kész is vagyunk, indulhat a szkript futtatása:
root@localhost:/takeover# sh /takeover/takeover.sh
Please set a root password for sshd
New password:
Retype new password:
passwd: password updated successfully
Setting up target filesystem...
Mounting pseudo-filesystems...
Checking and switching TTY...
Type 'OK' to continue
> OK
Preparing init...
Starting secondary sshd
ssh-keygen: generating new host keys: DSA
You should SSH into the secondary sshd now.
Type OK to continue
>
Remélhetőleg eddig a pontig semmi nem szorul magyarázatra, de ahogy a szkript is írja, itt mindenképp célszerű csatlakozni az új SSH-ra. Az IP ugyanaz, viszont a másodlagos SSH a 80-as porton fog futni. A felhasználónév root, a jelszó pedig amit a szkript első promptjában megadtunk.
You should SSH into the secondary sshd now.
Type OK to continue
> OK
About to take over init. This script will now pause for a few seconds.
If the takeover was successful, you will see output from the new init.
You may then kill the remnants of this session and any remaining
processes from your new SSH session, and umount the old root filesystem.
Init takeover successful
Pivoting root...
Chrooting and running init...
root@localhost:/takeover#
Innentől kezdve a régi SSH-ra nincs is szükség. Remek. Sikerrel járt a folyamat! Zárjuk is be a régit.
root@localhost:~# ls /
LICENSE dev initrd.img libx32 proc sys vmlinuz
README.md etc initrd.img.old media root takeover.sh vmlinuz.old
bin fakeinit lib mnt run tmp
boot fakeinit.c lib32 old_root sbin usr
busybox home lib64 opt srv var
root@localhost:~# ls /old_root/
bin home lib64 opt sbin tmp vmlinuz.old
boot initrd.img lost+found proc srv usr
dev initrd.img.old media root sys var
etc lib mnt run takeover vmlinuz
Látható, hogy az új SSH rendszere a RAM-ból fut. Ha szükséges a későbbiekben debuggoláshoz stb és van elég szabad hely, akkor a /run/modules átmásolható a régi rendszerről, de ez a lépés teljesen opcionális:
cp -ar /old_root/run/modules /run
Nekem nem lesz szükségem a modulokra, hiszen a kvm már be van töltve, más modulra pedig nincs és nem is lesz vélhetően szükséges:
root@localhost:~# lsmod | grep kvm
kvm_intel 233472 0
kvm 749568 1 kvm_intel
irqbypass 16384 1 kvm
Rendben, most lőjük ki elsőként a megmaradt régi SSH szervert:
root@localhost:~# lsof -i | grep ssh
sshd 678 root 3u IPv4 19650 0t0 TCP *:ssh (LISTEN)
sshd 678 root 4u IPv6 19652 0t0 TCP *:ssh (LISTEN)
Nekem a 678-as porton fut, így azt fogom kilőni:
kill -9 678
Végezetül szaladjunk át az összes folyamaton, amit az lsof kilistáz és lőjük ki hasonlóan a régi SSH-hoz:
kill -9 `lsof -t +D /old_root`
A lényeg, hogy a végére ne maradjon futó folyamat, amely igénybe venné a diszket:
root@localhost:~# lsof /old_root
root@localhost:~#
Most elvileg semmilyen folyamat nem használja a diszket már, viszont maradt nekünk a RAID1 tömbünk, amit még szét kell szedni, illetve egy meglepetés LVM konfig is:
root@localhost:~# fdisk -l | grep sectors | grep Disk
Disk /dev/sda: 447.1 GiB, 480103981056 bytes, 937703088 sectors
Disk /dev/sdb: 447.1 GiB, 480103981056 bytes, 937703088 sectors
Disk /dev/md2: 28 GiB, 29996482560 bytes, 58586880 sectors
Disk /dev/md4: 409.9 GiB, 440102879232 bytes, 859575936 sectors
Disk /dev/mapper/vg00-usr: 10 GiB, 10737418240 bytes, 20971520 sectors
Disk /dev/mapper/vg00-var: 10 GiB, 10737418240 bytes, 20971520 sectors
Disk /dev/mapper/vg00-home: 10 GiB, 10737418240 bytes, 20971520 sectors
Ellenőrizzük, hogy van-e swap felcsatolva a rendszeren:
root@localhost:~# free -h
total used free shared buff/cache available
Mem: 15Gi 181Mi 12Gi 2.0Gi 2.9Gi 13Gi
Swap: 18Gi 0B 18Gi
Esetemben van, tehát csatoljuk le:
swapoff -a
Mindenekelőtt csatoljuk le a régi rootot:
umount -R /old_root
Ez a lépés valószínűleg el fog térni, host és Debian telepítő specifikus, az én hostom LVM-et is alkalmazott. Így ezt kell eltávolítani először, majd mehet a RAID szétszedés is:
apt install lvm2 -y
lvremove /dev/mapper/vg00-usr
lvremove /dev/mapper/vg00-var
lvremove /dev/mapper/vg00-home
Szedjük szét a RAID tömböt:
apt install mdadm -y
mdadm --stop --scan
Ellenőrizzük a sikerességét:
root@localhost:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
Nincs itt semmi, így sikerrel jártunk! Kezdődhet a tényleges OS telepítés!
Töltsük le a telepítőt mondjuk a root home könyvtárába:
wget https://download.fedoraproject.org/pub/fedora/linux/releases/32/Server/x86_64/iso/Fedora-Server-dvd-x86_64-32-1.6.iso -O lemezkep.iso
Majd futtassuk le a cikk elején említett két parancsot, de előtte győződjünk meg arról, hogy nyitottunk egy SSH port forwardot az 5900-as portra:
apt update && apt install qemu-system-x86
qemu-system-x86_64 -net nic -net user -m 2048M -enable-kvm -cpu kvm64,+nx -smp 2 -device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 -k en-us -cdrom lemezkep.iso -drive file=/dev/sda,format=raw -drive file=/dev/sdb,format=raw -vnc 127.0.0.1:0 -boot d
Majd egy tetszés szerint választott VNC klienssel (én a VNC Viewer-t tudom ajánlani, vagy a Remmina-t) lépjünk be a localhost:5900 VNC szerverre, ahol már fogad is a telepítő. Esetemben valahogy így:
A telepítés innentől kizárólag rajtatok áll és semmiben nem különbözik egy hagyományos CD-s telepítéstől, kivéve hogy VNC-n keresztül zajlik. Ha kész, lépjünk ki a telepítőből, illetve a qemu folyamatból Ctrl+C-vel, majd indítsuk újra a masinát:
sync
reboot -f
És az új rendszer fog várhatóan elindulni.
Megjegyzés magamnak: Ha a Fedora telepítése a bootloader telepítésnél ismeretlen hibával elhasal, az valószínűleg azért van, mert mindkét lemezen szükség van a boot partíció meglétére.
És ennyi lenne. Kérdéseket, kommenteket, kioktatást szívesen fogadok hozzászólások formájában! Kellemes konfigolást kívánok!
Belevágni a projektbe kizárólag saját felelősségére érdemes és egy olyan rendszeren, ahol van fizikai hozzáférés/OS újratelepítési lehetőség biztosított, arra az esetre, ha valami balul sülne el!
Készült: 2020. 07. 15, Szerda
