VRA Ubuntu 26.04 Server Template — Kompletná šablóna pre vRealize Automation

Posted on By Martin Hasin

Ubuntu 26.04 LTS ako šablóna pre vRealize Automation (resp. VMware Aria Automation) je základný stavebný kameň pre automatizované nasadzovanie linuxových serverov v podnikovom vSphere prostredí. Tento návod pokrýva kompletnú prípravu Ubuntu 26.04 Server šablóny — od nastavenia VMware VM, cez optimalizáciu OS pre klonovanie, konfiguráciu cloud-init, automatické aktualizácie pomocou unattended-upgrades, až po sealing skript a verifikáciu po deploye z VRA blueprintu.

Cieľ je dosiahnuť šablónu, ktorá po klonovaní spoľahlivo regeneruje machine-ID, SSH host kľúče a sieťové parametre, automaticky preberá konfiguráciu z VRA blueprintu (cez VMwareGuestInfo datasource alebo manuálnu customizáciu) a sama si drží OS bezpečnostné záplaty bez ručného zásahu. Pre desktop variantu šablóny (s GUI a xRDP) pozri samostatný návod VRA Ubuntu 26.04 Desktop Template.

1. VMware VM custom attributes

Pred inštaláciou OS nastav vo vSphere na novej VM tieto Advanced Configuration parametre (Edit Settings → VM Options → Advanced → Edit Configuration). Robíme to pred bootom, niektoré z nich sa po prvom štarte už ťažšie menia.

sched.swap.vmxSwapEnabled    false
disk.EnableUUID              true
tools.guest.desktop.autolock false
  • sched.swap.vmxSwapEnabled = false — vypína vmx swap súbor v datastore (.vswp). Pri šablónach kde je dostatok RAM sa zbytočne spotrebúva diskový priestor a IO na hostiteľovi.
  • disk.EnableUUID = true — exponuje stabilné disk UUID do guest OS. Bez toho Ubuntu LVM/initramfs môže pri klonoch pomenúvať disky nekonzistentne.
  • tools.guest.desktop.autolock = false — vypína auto-lock VMware Tools session (relevantné aj pre headless server kvôli vmtoolsd timeoutom).

2. Update + base balíčky

Po inštalácii Ubuntu 26.04 Server sa najprv pripoj cez SSH (alebo konzolu) ako sudo používateľ a ako prvé urob plný update systému plus inštaláciu základných nástrojov.

sudo apt update
sudo apt upgrade -y
sudo apt autoremove -y
sudo apt install -y mc htop ssh ntpsec net-tools util-linux-extra curl wget gnupg
sudo systemctl enable ssh ntpsec

Poznámka k vyradeným balíčkom: Oproti starším verziám tohto návodu zámerne nepridávame xinetd ani ifupdown — na Ubuntu 26.04 sú obe obsolete. Sieť rieši Netplan + systemd-networkd, super-server inetd takmer nikto reálne nepoužíva. Ak ich aplikačne potrebuješ, doinštaluješ ich neskôr.

Poznámka k chrony → ntpsec swap-u: Ubuntu 26.04 server má ako default time daemon chrony. Inštalácia ntpsec ho automaticky odstráni (konflikt — oba poskytujú virtual package time-daemon). Apt pri tom zobrazí varovanie typu „ubuntu-server-minimal depends on chrony | time-daemon“ — je to transient dpkg warning počas swap-u, závislosť meta-packagu sa korektne splní keď ntpsec dokončí setup (sám poskytuje time-daemon). Stačí nechať dobehnúť, výsledný stav je v poriadku.

3. Reset machine-ID parametra

Klony šablóny by zdieľali rovnaký /etc/machine-id, čo láme DHCP DUID-LL (všetky VM by žiadali rovnakú IP), systemd journal cieľovanie a prípadne licenčnú väzbu. Tu nastavíme symlink a vynulujeme — finálny reset urobí sealing skript (sekcia 11).

sudo rm /var/lib/dbus/machine-id
sudo ln -s /etc/machine-id /var/lib/dbus/machine-id
echo "" | sudo tee /etc/machine-id

4. Cloud-init — dve cesty

Existujú dva osvedčené prístupy ako sa popasovať s cloud-init v šablóne pre VRA. Vyber si jeden podľa toho, ako je postavený tvoj VRA blueprint.

Cesta A — úplne odstrániť cloud-init

Vhodné keď VRA blueprint nepoužíva cloud-init injection a všetky parametre (hostname, IP, DNS, users) si zadáva cez vCenter Guest OS Customization Spec alebo manuálne po deploye. Najmenej „magického“ správania, predvídateľný prvý boot.

sudo apt purge -y cloud-init network-manager
sudo apt autoremove -y
sudo rm -rf /etc/cloud /var/lib/cloud

Cesta B — ponechať cloud-init s VMwareGuestInfo datasource (odporúčané pre VRA)

Cloud-init zostáva nainštalovaný, ale presunieme ho na VMwareGuestInfo datasource. Vďaka tomu VRA blueprint dokáže pri prvom boote injektovať hostname, SSH kľúče, prvotné users, alebo run-once user-data skripty cez vmx guestinfo properties.

# obmedziť datasource_list iba na VMware (poradie = priorita)
sudo tee /etc/cloud/cloud.cfg.d/99-vmware-guestinfo.cfg >/dev/null <<'EOF'
datasource_list: [ VMwareGuestInfo, NoCloud, ConfigDrive, OVF, None ]
EOF

# vyčistiť stav z install image — povinné pred sealingom
sudo cloud-init clean --logs

Rozšírenie root partície pri prvom boote — nepridávame cloud-initramfs-growroot. Cloud-init má vlastné moduly growpart + resizefs ktoré robia presne to isté natívne počas init fázy (nie z initramfs hooku). Sú v default cloud-init konfigurácii zapnuté, takže žiadny extra balíček netreba. Naviac sa tým vyhneme problémovému swap-u na Ubuntu 26.04: cloud-initramfs-growroot má hard dependency na initramfs-tools, ale Ubuntu 26.04 má ako default initramfs generator dracut — apt by ho preto pri inštalácii odstránil a nahradil initramfs-tools. Riskantná operácia na už-nainštalovanom systéme bez reálneho benefitu.

Ak chceš overiť že growpart modul cloud-initu je aktívny:

grep -E "growpart|resizefs" /etc/cloud/cloud.cfg
# malo by ukázať tieto moduly v cloud_init_modules: alebo cloud_config_modules: sekcii

Pri tomto prístupe vo VRA blueprinte definuješ cloudConfig sekciu (YAML) ktorá sa pri klonovaní zapíše do guestinfo.userdata — cloud-init si ju pri prvom boote prečíta a aplikuje.

5. Sieť a DNS

Šablóna by nemala niesť žiadnu fixnú sieťovú konfiguráciu — tú dodá VRA blueprint alebo cloud-init pri prvom boote. Odstránime preto default netplan súbor a hardcoded fallback nameservery.

# Odstrániť default netplan config
sudo rm -f /etc/netplan/*.yaml

# Hardcoded resolv.conf (fallback ak systemd-resolved zlyhá)
sudo unlink /etc/resolv.conf 2>/dev/null || true
printf '%s\n' 'nameserver 192.168.3.2' 'nameserver 192.168.16.16' 'nameserver 8.8.8.8' | sudo tee /etc/resolv.conf >/dev/null

# ak nepotrebuješ systemd-resolved (pri Ceste A z predchádzajúcej sekcie)
sudo systemctl disable --now systemd-resolved 2>/dev/null || true

Pri Ceste B (cloud-init zostáva) systemd-resolved ponechaj zapnutý — cloud-init s ním štandardne počíta.

6. Optimalizácia OpenVMtools

Default open-vm-tools.service sa štartuje pred cloud-init-local.service a pred dbus.service, čo na bootu spôsobuje race condition — vmtoolsd občas zatuhne na 30–60 sekundách. Patch posunie štart za dbus a zakomentuje konfliktný tmpfiles entry.

sudo sed -i 's|Before=cloud-init-local.service|After=dbus.service|g' \
    /lib/systemd/system/open-vm-tools.service

sudo sed -i 's|^D /tmp 1777 root root -|#D /tmp 1777 root root -|g' \
    /usr/lib/tmpfiles.d/tmp.conf

sudo systemctl daemon-reload

7. Časová zóna a NTP

Časová zóna sa nastaví na Europe/Bratislava. Primárny NTP server je ntp.tuke.sk (označený modifikátorom prefer), ako záloha sú pridané verejné pooly sk.pool.ntp.org a europe.pool.ntp.org. Tri zdroje stačia na detekciu falseticker-a (NTP majority voting).

sudo timedatectl set-timezone Europe/Bratislava

sudo tee /etc/ntpsec/ntp.conf >/dev/null <<'EOL'
driftfile /var/lib/ntpsec/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# Primárny NTP server
pool ntp.tuke.sk prefer iburst

# Záložné verejné pooly
pool 0.sk.pool.ntp.org iburst
pool 1.europe.pool.ntp.org iburst

restrict default kod nomodify notrap nopeer noquery limited
restrict 127.0.0.1
restrict ::1
EOL

sudo systemctl restart ntpsec
ntpq -p

Príkaz ntpq -p by mal po pár sekundách ukázať vybrané peer-y so synchronizovaným stavom — pri ntp.tuke.sk by mal byť znak * (vybraný ako system peer), pri ostatných + (kandidát). Ak ostane všade x alebo prázdno, skontroluj firewall na port 123/UDP.

8. SSH server setup

SSH host kľúče sa musia regenerovať pri prvom boote každého klonu. Toto rieši kombinácia rc.local (regenerácia ak chýbajú) plus finálne zmazanie kľúčov v sealing skripte (sekcia 11).

sudo tee /etc/rc.local >/dev/null <<'EOL'
#!/bin/sh -e
test -f /etc/ssh/ssh_host_rsa_key || dpkg-reconfigure openssh-server
exit 0
EOL
sudo chmod +x /etc/rc.local

sudo tee /etc/systemd/system/rc-local.service >/dev/null <<'EOL'
[Unit]
Description=/etc/rc.local Compatibility
ConditionPathExists=/etc/rc.local

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target
EOL

sudo systemctl daemon-reload
sudo systemctl enable rc-local

SSH konfigurácia — povolenie root loginu (interný admin prístup) a zákaz default vmware účtu zo subiquity inštalátora:

sudo sed -i '/^#PermitRootLogin/c\PermitRootLogin yes' /etc/ssh/sshd_config
echo 'DenyUsers vmware' | sudo tee -a /etc/ssh/sshd_config
sudo systemctl restart ssh

Bezpečnostná poznámka: PermitRootLogin yes je vhodné kombinovať s PasswordAuthentication no + povinnými SSH kľúčmi. Pre VRA-deployovanú VM kde root prístup tečie cez VPN/jump host to akceptujeme; pre exposed hosty zvážiť aj limit cez AllowUsers alebo presne túto sekciu prerobiť na key-only.

9. Automatické aktualizácie — unattended-upgrades

Automatické bezpečnostné záplaty sú pre šablóny must-have — bez nich VM po deploy-i niekoľko mesiacov visí so zraniteľnosťami kým sa k nej niekto neprihlási. Predtým sme to v starších verziách šablóny riešili custom first-boot-update.sh skriptom s reboot counterom; pre Ubuntu 26.04 odporúčam unattended-upgrades — je to štandardná Canonical cesta s lepšou integráciou (ESM, kernel cleanup, proper reboot scheduling).

sudo apt install -y unattended-upgrades apt-listchanges

Hlavný enable — /etc/apt/apt.conf.d/20auto-upgrades:

printf '%s\n' \
  'APT::Periodic::Update-Package-Lists "1";' \
  'APT::Periodic::Unattended-Upgrade "1";' \
  'APT::Periodic::AutocleanInterval "7";' \
  'APT::Periodic::Verbose "1";' \
| sudo tee /etc/apt/apt.conf.d/20auto-upgrades >/dev/null

Allowlist a reboot policy — /etc/apt/apt.conf.d/50unattended-upgrades (prepíše default, ktorý povoľuje iba -security). Heredoc s uvozovkovaným terminátorom <<'EOL' — apostrofy zaisťujú že znaky ${...} sa neexpandnú v shelle (apt parser si ich rieši sám) a zároveň prežije copy-paste z prehliadača bez mangling-u.

sudo tee /etc/apt/apt.conf.d/50unattended-upgrades >/dev/null <<'EOL'
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
    "${distro_id}:${distro_codename}-updates";
};

Unattended-Upgrade::Package-Blacklist {
    // sem dať balíčky ktoré nikdy nechceš auto-aktualizovať
    // napr.: "linux-image-generic";
};

Unattended-Upgrade::DevRelease "auto";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::Remove-Unused-Dependencies "false";

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Unattended-Upgrade::SyslogEnable "true";
Unattended-Upgrade::SyslogFacility "daemon";
EOL

Validácia a sledovanie — overenie že timer-y sú aktívne, dry-run čo by sa nainštalovalo, a kde čítať logy:

# dry-run - vypíše čo by upgrade urobil
sudo unattended-upgrade --dry-run -d

# stav timer-ov
systemctl list-timers apt-daily apt-daily-upgrade

# log z dnešného behu
sudo journalctl -u unattended-upgrades --since today

# detailnejší apt log
sudo cat /var/log/unattended-upgrades/unattended-upgrades.log

Po aplikácii bude šablóna pri každom deploye automaticky:

  • denne sťahovať balíčkové listy a aplikovať -security aj -updates repá
  • autoremove-ovať staré kernely a nepoužívané závislosti
  • reštartovať sa o 04:00 ráno keď je potrebný reboot (typicky kernel update)
  • logovať do journalctl + /var/log/unattended-upgrades/

10. Optimalizácie pre vSphere a mass-deployment

Šablóna z ktorej sa môže klonovať aj 150 VM zaslúži pár optimalizácií navyše — vypnutie nepotrebných služieb, rozumné limity pre logy, virtual-guest tuning a randomizácia automatických aktualizácií aby ti 150 strojov nezačalo súčasne sťahovať balíčky.

Vypnutie multipathd (default voľba pre vSphere VM)

Pre čisté vSphere VM bez in-guest iSCSI/FC initiátora je multipathd v hostiteľskom OS nadbytočný — vSphere rieši cesty k storage na úrovni ESXi hosta (Round Robin, Fixed, MRU policy), guest vidí jeden virtuálny disk a žiadne alternatívne cesty. Spustený multipathd v guest OS:

  • Zbytočne spotrebúva pamäť a CPU pri každom boote (mapping pokus)
  • Občas konfliktuje s LVM/initramfs počas update-initramfs
  • Spomaľuje boot o niekoľko sekúnd kým detekuje že nemá čo mapovať
# Zastaviť, vypnúť a odstrániť (typicky nie je nainštalovaný, kontrola pre istotu)
sudo systemctl disable --now multipathd multipathd.socket 2>/dev/null || true
sudo apt purge -y multipath-tools 2>/dev/null || true

Výnimka — keď multipathd potrebuješ: ak v guest VM bežia in-guest iSCSI alebo FC initiátory (typicky Veeam Hardened Repository, databázový server s direct LUN cez open-iscsi, alebo SAP HANA s ASM diskmi), multipathd doinštalovať s blacklist regex pre sda/nvme/hd*. To je ale špeciálny prípad — pre default VRA šablónu vypneme.

Tuned profile virtual-guest

Tuned je daemon ktorý aplikuje pripravené ladiace profily — pre VMware/KVM guest má virtual-guest profil ktorý nastaví správny I/O scheduler (mq-deadline pre virtio/pvscsi), vm.dirty_ratio, transparent hugepages a CPU governor. Bez tuned-u zostávajú defaulty navrhnuté pre desktop, ktoré pre serverové VM nie sú optimálne.

sudo apt install -y tuned
sudo systemctl enable --now tuned
sudo tuned-adm profile virtual-guest
tuned-adm active

Vypnutie motd-news (zbytočný network call pri každom logine)

Default Ubuntu posiela pri každom SSH logine HTTP request na motd.ubuntu.com aby zobrazil "What's new" reklamy a Pro upgrade lure. Pri 150 VM je to 150 zbytočných HTTPS requestov pri každom prihlásení.

sudo sed -i 's/^ENABLED=1/ENABLED=0/' /etc/default/motd-news
sudo systemctl disable --now motd-news.timer motd-news.service 2>/dev/null || true

Limit veľkosti journald

Pre šablónu z ktorej sa generujú efemérne VM (priemerná životnosť dní/týždňov, nie roky) drž žurnál malý — default 4 GB cap je pre takéto stroje plytvanie. 200 MB pokrýva niekoľko týždňov histórie pre debug.

sudo mkdir -p /etc/systemd/journald.conf.d
printf '%s\n' \
  '[Journal]' \
  'SystemMaxUse=200M' \
  'SystemMaxFileSize=20M' \
  'ForwardToSyslog=no' \
| sudo tee /etc/systemd/journald.conf.d/00-template.conf >/dev/null

sudo systemctl restart systemd-journald
systemctl status systemd-journald

Pozn. Time-based MaxRetentionSec sme zo configu vynechali zámerne — pri šablóne je storage cap (SystemMaxUse=200M) jediná zmysluplná retencia. Storage rotuje staré záznamy keď sa naplní 200 MB, čo je spoľahlivejšie ako čas-based retention pri VM s nedeterministickými boot časmi.

Randomizácia apt-daily timer-ov pre 150 VM cluster

Default systemd apt-daily.timer a apt-daily-upgrade.timer majú už zabudovanú náhodnú odchýlku (RandomizedDelaySec 12h pre apt-daily, 60min pre apt-daily-upgrade). Pre 150 VM klonovaných z rovnakého template to znamená, že bezpečnostné aktualizácie sa rozložia v čase — bez randomizácie by všetky stroje začali ťahať balíčky súčasne v ten istý moment a tvoj apt mirror, NTP server a uplink by to nepekne pocítili.

# overenie randomizácie (default je už zapnutá)
systemctl cat apt-daily.timer | grep -i Randomized
systemctl cat apt-daily-upgrade.timer | grep -i Randomized

# ak chceš ešte väčší rozptyl pre veľký cluster (napr. 4h pre apt-daily-upgrade):
sudo mkdir -p /etc/systemd/system/apt-daily-upgrade.timer.d
printf '%s\n' '[Timer]' 'RandomizedDelaySec=4h' \
| sudo tee /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf >/dev/null
sudo systemctl daemon-reload

Pri default 60-min jitteri sa 150 VM rozloží približne na ~2.5 stroja za minútu — pre väčšinu prostredí akceptovateľné. Pri širšom 4h okne je to ~0.6 stroja za minútu, čo apt mirror prakticky nezacíti.

11. Sealing skript seal-template.sh

Konsolidovaný skript ktorý spustíš tesne pred konverziou VM na šablónu. Nahrádza desiatky ručných príkazov z pôvodnej verzie návodu jediným sudo /usr/local/sbin/seal-template.sh.

sudo tee /usr/local/sbin/seal-template.sh >/dev/null <<'EOL'
#!/bin/bash
# Spusť pred konverziou VM na šablónu, potom poweroff.
set -e

echo "=== Sealing template ==="

# Cloud-init reset (ak je nainštalovaný)
if command -v cloud-init >/dev/null; then
    cloud-init clean --logs --machine-id
fi

# SWAP off + zakomentovať v fstab
swapoff --all || true
sed -ri '/\sswap\s/s/^#?/#/' /etc/fstab

# Force IPv4 pre apt (ipv6 občas zlyháva v exotickej sieti)
echo 'Acquire::ForceIPv4 "true";' > /etc/apt/apt.conf.d/99force-ipv4

# Truncate logy
for f in /var/log/audit/audit.log /var/log/wtmp /var/log/lastlog /var/log/btmp \
         /var/log/syslog /var/log/auth.log /var/log/kern.log; do
    [ -f "$f" ] && truncate -s 0 "$f"
done

# Vyčistenie persistent rules a tmp
rm -f /etc/udev/rules.d/70-persistent-net.rules
rm -rf /tmp/* /var/tmp/*

# SSH host kľúče - regenerujú sa pri prvom boote (sekcia 8)
rm -f /etc/ssh/ssh_host_*

# Machine-ID wipe (regeneruje sa pri prvom boote)
echo "" > /etc/machine-id
[ -L /var/lib/dbus/machine-id ] || echo "" > /var/lib/dbus/machine-id

# APT cache cleanup
apt clean

# History
history -c
> ~/.bash_history
[ -f /root/.bash_history ] && > /root/.bash_history

# fstrim - vynuluje voľné bloky vo file systéme, dramaticky zmenší výslednú VMDK
# (pri thin-provisioned diskoch môže ušetriť desiatky GB pri 150 klonoch)
fstrim -av || true

echo "=== Done. Now: sudo poweroff ; convert to template in vCenter. ==="
EOL

sudo chmod +x /usr/local/sbin/seal-template.sh

12. Konverzia na šablónu a verifikácia

Záverečné kroky na zdrojovej VM:

sudo /usr/local/sbin/seal-template.sh
sudo poweroff

Vo vCenter:

  1. Right-click na VM → Template → Convert to Template
  2. Premenuj template (napr. tpl-ubuntu-2604-server) a presuň do template foldera
  3. V Aria Automation Cloud Assembly pridaj template ako Cloud Template Image Mapping

Po prvom deploye z VRA blueprintu na novej VM overiť:

# Cloud-init stav (iba ak ide o Cestu B)
cloud-init status
cloud-init analyze show

# Logy z prvého bootu
sudo tail -200 /var/log/cloud-init.log
sudo tail -200 /var/log/cloud-init-output.log

# Boot performance
systemd-analyze
systemd-analyze blame | head -10

# Tuned profil je aktívny
tuned-adm active        # malo by ukázať "Current active profile: virtual-guest"

# Multipathd vypnutý
systemctl is-enabled multipathd 2>&1 | grep -E "disabled|not-found"

# Unattended-upgrades je aktívny + randomizácia funguje
systemctl status apt-daily.timer apt-daily-upgrade.timer
systemctl list-timers apt-daily*
sudo unattended-upgrade --dry-run -d

# Journald limit funguje
journalctl --disk-usage     # <= ~200 MB

# Uniqueness — nesmie byť identické s template
cat /etc/machine-id
hostname
ip a
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Časté problémy a kde hľadať:

  • cloud-init status ukazuje error → /var/log/cloud-init.log ; najčastejšie nedostal žiadne guestinfo properties z VRA blueprintu (chyba v cloud-config YAML šablóny)
  • Stále sa pripájaš ako root cez password ale nemáš → skontroluj /etc/ssh/sshd_config a journalctl -u ssh
  • Machine-ID identický s template → sealing skript zlyhal alebo sa nespustil; ručne echo "" > /etc/machine-id && reboot
  • Unattended-upgrades sa nespúšťa → systemctl list-timers apt-daily*, prípadne systemctl unmask apt-daily.service
  • systemd-journald.service zlyhá s Error: code: 117 (Structure needs cleaning) — poškodené žurnálové súbory (typicky po VM snapshot/pause incident, alebo prerušenom IO na datastore). Žurnál nie je možné opraviť, treba ho zmazať a nechať journald vytvoriť nový: sudo rm -rf /var/log/journal/* /run/log/journal/* && sudo systemctl restart systemd-journald

Súvisiace návody

CEO at  | martin.hasin@gmail.com | Website |  + posts

Odborník na kybernetickú bezpečnosť, správu Azure Cloud a VMware onprem. Využíva technológie, ako Checkmk a MRTG, na monitorovanie siete a zvyšovanie efektívnosti a bezpečnosti IT infraštruktúry. Kontakt: hasin(at)mhite.sk

Automation Tags:,