Bananapi

Na jednodeskové servery s oblibou používám distribuci Armbian. U desek bananapi je z mého pohledu mizerná softwarová podpora výrobce. V praxi to pro mě znamená, že tam kde nepoběží Armbian, tak je pro mě nepoužitelné jako server.

• Banapi-R1 už není podporován, je potřeba kompilace Armbianu
• Wiki k Banana Pi R1

Pozor, rozlišovat desku Banana Pi R2 a Banana Pi R2 Pro. Chvíli jsem se natrápil s tím, že jsem si stáhnul komunitní build Banana Pi R2 Pro, který ale nešel nabootovat. Kdybych se pozorněji díval na procesor, tak se mi to nestane :)

Dále je třeba počítat s tím, že Banana Pi R2 má jádro 4.19., do kterého budou backportovány patch do prosince 2024. Pak podpora jádra skončí. Zároveň si nové jádro musím kompilovat sám - není automaticky připravováno v rámci distribuce. V minulosti jsem četl diskuse, že se nepodařilo přejít na jádro 5 a vyšší, takže nevidím ani naději, že se to změní a budu muset časem zařízení vyhodit.

• Wiki k Banana Pi R2 - s odkazem na řešení autozapínání
• Wiki k Banana Pi R2
• Wiki k Banana Pi R2 - Pro
• Automatické zapínání po připojení napájení - diskuse
• BPI-R2 Ethernet Switch
• BPI-R2 SATA interface a detailní dokumentace k dalším periferiím od výrobce výrobce
• Pinout

Bananapi R2 trpí neduhem - chováním, které bych u routeru neočekával. Pro zapnutí je potřeba podržet tlačítko power na cca 7 sec. Ošidné je, že jakmile to vypadá, že bananapi startuje a člověk pustí tlačítko power, tak se vypne. Tlačítko se musí chvíli předržet.

Každopádně když vypadne proud, tak router bez manuálního zapnutí nenastartu - což je u routeru nesmysl.

V diskusi je popsáno řešení, kde se připájí u tlačítka PWR PIN1 a PIN2. Deska se pak bude chovat, jako by někdo držet tlačítko power neustále zapnuté.

Tady na obrázku jsou vidět piny - popis pinů je u tlačítka RESET (u něj rozhodně nechci piny spojit).

Tlačítko POWER je blíže ke konci desky. Tady je vidět řešení propojení PINů 1 a 2 ze spodní strany desky, kde je to jednodušší na přístup:

Osobně jsem jako propojovač použil kousek drátku, který jsem připájel na obě nožičky a tím jsem PINy propojil.

Určitě to lze udělat hezčím způsobem, nicméně řešení mi funguje.

Pokud není možné využít komunitní obrazy https://github.com/armbian/community, nezbývá než se pustit do vlastní kompilace. Protože se při kompilaci musí nainstalovat a stáhnout hodně software, provádím kompilaci raději ve VirtualBoxu, abych si nezabalastil systém.

Pro kompilaci jádra jsem potřeboval kolem 27 GB místa na disku. Pro kompilaci celého OS image je potřeba víc. Odhaduji tak 35 GB, ale nemám to ověřené, protože mi došlo místo, takže jde čistě o odhad.

apt-get -y -qq install git
apt install sudo  
git clone --depth=1 --branch=v23.11 https://github.com/armbian/build  
cd build  
 
./compile.sh

Pro aktuální branch je pořeba se podívat do dokumentace: https://github.com/armbian/build.

Přidávám ještě odkaz na další parametry při instalaci.

Dále přihazuji screeny obrazovek z kompilace jádra.

Do not change the kernel configuration

Dole jsem zvolil Show CSC/WIP/EOS/TVB

Musím potvrdit I understand and agree

Zvolím konkrétní verzi desky. Banana Pi R1 má kódové označení „lamobo“.

Volba current

Kompilace Armbianu funguje tak, že se automaticky stahuje nejnovější stable jádro. Takže stejně skripty Armbianu o měsíc později zkompilují jinou verzi jádra. A to může být v některých případech problém.

Další potíž je v tom, že větev jádra 4.19 už nemá po kompilaci balíček linux-headers. Dle vývojářů už nebylo možné ho udržovat.

Věděl jsem, že v branchi armbianu 22.11 ještě kernel headers udržovali. Proto jsem nejprve zvolil konkrétní branch armbianu.

git clone --depth=1 --branch=v22.11 https://github.com/armbian/build  
cd build  

Následně jsem ale narazil na problém, že se stahuje poslední stabilní verze jádra. Bohužel nikde v dokumentaci nebylo napsáno, jak pevně nastavit verzi jádra, které chci zkompilovat.

Delším hledáním a zkoumáním skriptů jsem na to nakonec přišel. Konfigurační skripty jsou ve složce lib. Prohledal jsem všechny skripty a našel funkci fetch_from_repo(). Ta zajišťuje stažení zdrojových kódů z githubu. Funkce ale může sloužit na stažení i jiných dat, než linuxového jádra. Proto není řešení upravovat tuto funkci.

U funkce byl nápovědou třetí parametr, který se ukládá do proměnné $ref. Při podrobnějším zkoumání jsem zjistil, že pokud je do parametru ref předána proměnná branch:linux-4.19.y, dojde ke stažení nejaktuálnější stabilní verze jádra. Pokud je do proměnné předána hodnota tag:v4.19.265, dojde ke stažení konkrétní verze jádra.

V dalším kroku jsem v souboru build/config/boards/bananapir2.csc dočetl, že mám BOARDFAMILY=„mt7623“. Následně jsem editoval soubor config/sources/families/mt7623.conf, který bylo potřeba upravit. Ze začátku jsem zakomentoval původní KERNELBRANCH a nastavil tak, jak jsem potřeboval:

case $BRANCH in

        legacy)

                #KERNELBRANCH='branch:linux-4.19.y'
                KERNELBRANCH='tag:v4.19.262'

                ;;

esac

Pak už stačilo spustit kompilaci standardním způsobem a stáhla se konkrétní verze jádra a podařilo se mi provést její kompilaci.

dd if=Armbian_22.11.0-trunk_Bananapir2pro_kinetic_edge_6.0.7.img of=/dev/sda bs=8M status=progress

• USB2Serial-Adapter (e.g. CP2102 or FTDI, known problems with Profilic- and ch340g-Chipsets)
• using Uart-Pins (not 40-pin-connector)
• each TX ⇒ RX (r2 tx to rx of usb2serial, tx of usb2serial to r2 rx)
• application for PC:
  • Linux: minicom
  • Windows: putty
• settings: 115200 8N1 FlowControl: off

Minicom je jednou z možností, jak komunikovat skrze sériovou linku.

sudo apt-get install minicom
sudo minicom -s

          +-----[configuration]------+
          | Filenames and paths      |
          | File transfer protocols  |
          | Serial port setup        |  <<<<<<<<<<<<
          | Modem and dialing        |
          | Screen and keyboard      |
          | Save setup as dfl        |
          | Save setup as..          |
          | Exit                     |
          | Exit from Minicom        |
          +--------------------------+

  +-----------------------------------------------------------------------+
  | A -    Serial Device      : /dev/ttyUSB0                              |
  | B - Lockfile Location     : /var/lock                                 |
  | C -   Callin Program      :                                           |
  | D -  Callout Program      :                                           |
  | E -    Bps/Par/Bits       : 115200 8N1                                |
  | F - Hardware Flow Control : No                                        |
  | G - Software Flow Control : No                                        |
  |                                                                       |
  |    Change which setting?                                              |
  +-----------------------------------------------------------------------+

• save as .dfl
• Exit from Minicom

zdroj: https://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:debug-uart

Přípdně by mělo jít použít i následující příkaz, kde nadefinuji všechno potřebné v příkazové řádce.

minicom --device /dev/ttyUSB0 --baudrate 115200

Je další možností jak komunikovat se sériovou linkou.

screen /dev/ttyUSB0 115200

Ovládání screenu je trochu podobné jako ovládání minicomu. Detaily popisuje tento článek.

Screen lze mimo jiné používat i na serveru. Spustím nějaký proces na serveru, zmáčknu Ctrl-A a potom d a mohu se odpojit od serveru. Pro načtení screenu po připojení spustím screen s parametrem

screen -r

Pokud mám spuštěných více sezení, tak si vypíšu všechna sezení například takto:

screen -ls
screen -r 1

Ukončení screenu provedu pomocí kombinace Ctrl-A a potom K. Vypsání nápovědy je možné pomocí zkratky Ctrl-A a ?.

Zařízení po bootu čeká na síťová zařízení, až budou online. Nezkoumal jsem do hloubky, jak to má fungovat. Každopádně mám připojený ethernetový kabel a nemá smysl, aby se kvůli tomu 1,5 minuty nebo déle čekalo na něco, co se nezmění. Zde je o příčině popsáno více. V disku jsem našel řešení:

systemctl disable systemd-networkd-wait-online.service

A podle všeho pro úplné vypnutí (možná se po aktualizaci systemd zase zapne a proto je potřeba ještě zamaskovat):

systemctl disable systemd-networkd-wait-online.service

Stejně se teď potýkám s chybovým kódem v logu:

Dec 11 06:29:58 bananapir2 systemd-networkd-wait-online[6552]: Event loop failed: Connection timed out
Dec 11 06:29:58 bananapir2 apt-helper[6550]: E: Podproces /lib/systemd/systemd-networkd-wait-online vrátil chybový kód (1)

Při hledání řešení jsem našel způsob, jak pohodlně editovat konfigurační soubory služeb v systemd.

systemctl edit --full systemd-networkd-wait-online.service

Rovnou to vyzkouším a nastavím timeout na 10 sec editací tohoto řádku:

ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --timeout=10

Nezapomenout pak na:

systemctl daemon-reload

Při bootování jsem se setkal s touto chybou:

[FAILED] Failed to start Entropy Da…based on the HAVEGE algorithm.

V diskusi jsem našel a aplikoval řešení:

mkdir -p /etc/systemd/system/haveged.service.d
echo -e '[Service]\nSystemCallFilter=uname' > /etc/systemd/system/haveged.service.d/syscall.conf

Druhé řešení, které jsem neověřoval je zakomentovat pořádky začínající SystemCallFilter v souboru

/lib/systemd/system/haveged.service

Druhé řešení jsem kombinoval s prvním a ukázalo se, že v kombinaci s prvním to řešení není.

Pokud by bylo potřeba změnit MAC adresu síťové karty, pomůže příkaz

sudo ip link set dev eth0 address XX:XX:XX:XX:XX:XX

zdroj: https://itsfoss.com/change-mac-address-linux/

Aktuálně mám trochu zmatek v tom, proč je v distribuci tolik network managerů na nastavení sítě - třeba se k pochopení dostanu později. Můj cíle je nakonfigurovat Bananapi R2 jako router. 4 ethernetové porty budou tedy switch pro interní síť. 1 ethernetový portu bude sloužit pro připojení k internetu. V této části neřeším routování packetů - pouze nastavení LAN portů.

U NetworkManagera chceme zajistit, aby nenastavoval žádné síťové zařízení. To zajistil již nachystaný soubor /etc/NetworkManager/conf.d/10-ignore-interfaces.conf

[keyfile]                                                                                                                                                                                                          
unmanaged-devices=interface-name:eth*,interface-name:wan*,interface-name:lan*,interface-name:br*

Toto se hodí, pokud wifi karta nebude stabilní. Může to být z důvodu úsporného režimu a toto zajistí vypnutí úsporného režimu na wifi kartě. Soubor /etc/NetworkManager/conf.d/20-override-wifi-powersave-disable.conf:

[connection]                                                                                                                                                                                                       
wifi.powersave = 2

Defaultně byly všechny ethernetové porty v bridgi. Potřeboval jsem jeden port oddělit pro Internet a zbytek v bridgi nechat. Tady se odehrává hlavní nastavení:

root@bananapir2:/etc/systemd/network# ls -l 
celkem 32
-rw-r--r-- 1 root root 30 26. srp  2021 10-br0.netdev
-rw-r--r-- 1 root root 70 17. lis 09.38 10-br0.network
-rw-r--r-- 1 root root 39 17. lis 09.52 10-eth0.network
-rw-r--r-- 1 root root 40 26. srp  2021 10-lan0.network
-rw-r--r-- 1 root root 40 26. srp  2021 10-lan1.network
-rw-r--r-- 1 root root 40 26. srp  2021 10-lan2.network
-rw-r--r-- 1 root root 40 26. srp  2021 10-lan3.network
-rw-r--r-- 1 root root 51 17. lis 09.56 10-wan.network

Když budu procházet jednotlivé soubory, tak 10-br0.netdev vytvoří zařízení br0 typu síťový most (bridge).

root@bananapir2:/etc/systemd/network# cat 10-br0.netdev 
[NetDev]
Name=br0
Kind=bridge

Síťovému mostu je třeba přidělit statickou IP adresu. Ta bude výchozí bránou pro vnitřní síť. Dále pak vypnout DHCP.

root@bananapir2:/etc/systemd/network# cat 10-br0.network 
[Match]
Name=br0
 
[Network]
#DHCP=yes
DHCP=no
Address=192.168.0.1/24

Pro zařízení eth0 jsem raději vypnul přidělování IP adresy skrze DHCP. Nejsem si jistý, k čemu jinak slouží eth0 - třeba to zjistím později.

root@bananapir2:/etc/systemd/network# cat 10-eth0.network 
[Match]
Name=eth0
 
[Network]
#DHCP=yes

Jednotlivé ethernetové porty budou sloužit jako switch a budou zapojeny do bridge:

root@bananapir2:/etc/systemd/network# cat 10-lan0.network 
[Match]
Name=lan0
 
[Network]
Bridge=br0
 
 
root@bananapir2:/etc/systemd/network# cat 10-lan1.network 
[Match]
Name=lan1
 
[Network]
Bridge=br0
 
 
root@bananapir2:/etc/systemd/network# cat 10-lan2.network 
[Match]
Name=lan2
 
[Network]
Bridge=br0
 
 
 
root@bananapir2:/etc/systemd/network# cat 10-lan3.network 
[Match]
Name=lan3
 
[Network]
Bridge=br0

Jeden ethernetový port - v mém případě to odpovídá síťovému zařízení WAN bude sloužit pro připojení k internetu. Chci ho tedy vyřadit z bridge a nechat mu přidělovat IP adresu skrze DHCP.

root@bananapir2:/etc/systemd/network# cat 10-wan.network 
[Match]
Name=wan 
 
[Network]
DHCP=ipv4
#Bridge=br0

Nakonec jsem ještě musel řešit oříšek, protože jsem potřeboval přidělit statickou IP adresu. Tu jsem přidělil, ovšem systém neustále zlobil - byl problém s překladem adres na IP adresy. Soubor /etc/resolv.conf byl prázdný a neobsahoval žádné DNS servery. Takže jsem soubor v /etc/systemd/network editoval a dopsal jsem tam i nastavení DNS serverů.

[Match]
Name=wan 
 
[Network]
#DHCP=ipv4
DHCP=no
Address=10.10.10.2/24
DNS=212.96.161.6 212.96.160.7 8.8.8.8 1.1.1.1
Gateway=10.10.20.1
#Bridge=br0

Po tomto nastavení je třeba restartovat síť:

systemctl restart systemd-networkd

Další informace o nastavení lze čerpat zde: https://medium.com/100-days-of-linux/working-with-systemd-networkd-e461cfe80e6d

Po rebootu bohužel si zařízení wan nenačetlo adresu z DHCP serveru dokud jsem neprovedl restart systemd-networkd. Pak se zařízení aktivovalo a adresu si natáhlo. Nakonec jsem problém vyřešil ještě skrz konfiguraci /etc/network/interfaces.

root@bananapir2:/etc/network# cat interfaces
source /etc/network/interfaces.d/*
# Network is managed by Network manager
auto lo
iface lo inet loopback
 
 
auto wan
iface wan inet dhcp

Pokud budu chtít nastavit statickou IP adresu, tak změním údaje o zařízení wan takto:

auto wan
iface wan inet static
	address 84.42.251.238
	netmask 255.255.255.248
	gateway 84.42.251.233

Editací souboru /etc/network/interfaces jsem už zajistil, že zařízení wan má po bootu přidělenou IP adresu.

A protože jsem zjistil, že když nemám připojené žádné zařízení v LAN, tak se nepřidělí žádná IP adresa zařízení br0, přidal jsem do souboru ještě tyto řádky. Jinak mi služba dnsmasq při startu bananapi nebyla schopna nastartovat.

auto br0
iface br0 inet static
        address 192.168.0.1
        netmask  255.255.255.0

Pak jsem zjistil, že služba nenastartovala ještě z jiného důvodu po nabootování. Tady je vidět výpis chyby.

root@bananapir2:/home/nosek# systemctl status dnsmasq                                                                                                                                                       [35/35]
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server                                  
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)         
     Active: failed (Result: exit-code) since Sun 2022-11-20 16:35:02 CET; 17min ago
    Process: 1376 ExecStartPre=/etc/init.d/dnsmasq checkconfig (code=exited, status=0/SUCCESS)
    Process: 1488 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=2)
        CPU: 134ms                                                                                       
 
lis 20 16:35:00 bananapir2 systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
lis 20 16:35:02 bananapir2 dnsmasq[1488]: dnsmasq: failed to create listening socket for 10.112.235.1: P>
lis 20 16:35:02 bananapir2 dnsmasq[1488]: failed to create listening socket for 10.112.235.1: Požadovano>
lis 20 16:35:02 bananapir2 dnsmasq[1488]: FAILED to start up                                             
lis 20 16:35:02 bananapir2 systemd[1]: dnsmasq.service: Control process exited, code=exited, status=2/IN>
lis 20 16:35:02 bananapir2 systemd[1]: dnsmasq.service: Failed with result 'exit-code'.
lis 20 16:35:02 bananapir2 systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS serv>

Nakonec mi pomohla tato diskuse: https://ask.fedoraproject.org/t/dnsmasq-fails-on-initial-startup-succeeds-on-restart-unknown-interface-or-failed-to-create-listening-socket/16893/3

Musel jsem editovat soubor /lib/systemd/system/dnsmasq.service a zakomentovat a přidat řádek takto:

#After=network.target
After=network-online.target

Seznam přidělencý IP adres je v souboru:

/var/lib/misc/dnsmasq.leases

Pokud se rozhodnu, že změním IP adresu zařízení, které už je zapsané v tomto souboru, často se děje, že se ještě nějakou dobu přiděluje stará IP adresa. Je proto potřeba vymazat starý záznam v tomto souboru.

Ještě mi pomohlo vypnout systemd-resolvd:

systemctl stop systemd-resolvd
systemctl disable systemd-resolvd
systemctl daemon-reload

Ukázalo se, že tento způsob není trvalý. Po aktualizaci systemd došlo k přepsání soubor /lib/systemd/system/dnsmasq.service a problém se opakoval.

Aby se změny v `dnsmasq.service` nepřepisovaly po aktualizacích systému, je potřeba vytvořit přepsání systemd jednotky namísto úpravy souboru v `/lib/systemd/system/`.

Prvním krokem je vytvoření přepisovacího souboru pro systemd. Spusť:

sudo systemctl edit dnsmasq

Tento příkaz otevře editor pro přepsání konfigurace služby, aniž by byl upraven původní soubor.

Do editoru vlož tento obsah:

[Unit]
After=
After=network-online.target

Tímto způsobem se přepíše původní hodnota `After=network.target` na `After=network-online.target`, ale hlavní jednotkový soubor v `/lib/systemd/system/` zůstane beze změny. Po vložení konfigurace ulož soubor a ukonči editor.

Aby se změny projevily, je nutné načíst novou konfiguraci:

sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl restart dnsmasq

Od této chvíle už žádná aktualizace nepřepíše tuto změnu.

Ověření, zda se změna skutečně uplatnila, provedeme příkazem:

systemctl cat dnsmasq

Pokud je změna správně aplikována, měl by výstup obsahovat:

# /etc/systemd/system/dnsmasq.service.d/override.conf
[Unit]
After=
After=network-online.target

📌 Prázdný řádek `After=` je důležitý! Systemd tímto způsobem nejprve odstraní všechny existující `After=` direktivy a poté nastaví pouze `After=network-online.target`.

Nyní se `dnsmasq.service` už nebude přepisovat při aktualizacích, protože úprava je bezpečně uložena v `override.conf`.

Defaultní nastavení virtuální paměti v Armbianu je malé. Stávalo se mi pak, že po čase systém havaroval a hledal jsem příčinu. Takto vypadá nastavení virtuální paměti po instalaci:

root@cubieboard2:/home/nosek# cat /proc/sys/vm/min_free_kbytes
3442

Protože mám dostatek paměti RAM, tak jsem hodnotu navýšil editací souboru /etc/sysctl.conf a přidání řádku:

vm.min_free_kbytes=67584

Tady je více o chybě, se kterou jsem se setkával bez úpravy parametru: https://access.redhat.com/solutions/90883. Další informace k vm.min_free_kbytes lze nastudovat zde: https://linuxhint.com/vm_min_free_kbytes_sysctl/

Dále jsem pak nastavil, aby systém používal swapování pouze, když už nemá jinou možnost - opět přidáním řádku do souboru /etc/sysctl.conf:

#A swappiness setting of zero means that the disk will be avoided unless absolutely 
##necessary (you run out of memory), while a swappiness setting of 100 means that 
##programs will be swapped to disk almost instantly.
vm.swappiness=0

Pro načtení nových hodnot bez restartování počítače je potřeba použít příkaz:

sysctl -p

Všimnul jsem si, že je nainstalovaná OpenVPN. Nevyužívám, proto jsem odinstaloval.

apt --purge remove openvpn 

Dále byl spuštěn rpcbind, který také nepotřebuji.

systemctl stop rpcbind
systemctl stop rpcbind.socket
systemctl disable rpcbind

Narazil jsem na problém, že se rychle zaplňoval disk /var/log. Zkouším nastavení dle článku: https://github.com/azlux/log2ram/issues/174. Editoval jsem soubor /etc/systemd/journald.conf:

SystemMaxUse=10M
RuntimeMaxUse=10M
MaxRetentionSec=1day
MaxFileSec=1day

Log u konkrétní služby:

journalctl -u systemd-networkd-wait-online

Tady další zdroje na zmenšení journalu:

• https://askubuntu.com/questions/1238214/big-var-log-journal
• https://www.loggly.com/ultimate-guide/managing-journal-size/
• https://www.debugpoint.com/systemd-journald-clean/
• https://www.debugpoint.com/systemd-journalctl/

Tohle se mi zase jednou nepovedlo. Nepřenesl jsem si systém do paměti Bananapi a přes noc došlo patrně k nějaké chybě na kartě a poškodily se bootovací soubory. Takže nádhera a navíc jsem si nevytvořil ani zálohu SD karty. Takže paráda, celá instalace od začátku.

Našel jsem si stránku s Bananapi R2 a obrazem na SD kartu. Použil jsem Armbian Bookworm.

Když jsem používal program minicom na připojení k bananapi a chtěl jsem editovat textové soubory pomocí nano, nebylo to kvůli rozhození zobrazení možné. Pomohlo mi použít tmux a v něm spustit nano.

Při bootování se systém pokoušel nastartovat mt7623-wifi.service. Nicméně vestavěna Wi-Fi karta je zabugovaná, tak mi nedávalo smysl ji používat a služba zdržovala start systému. Několik minut trvalo, než timeout vypršel. Podařilo se mi službu vypnout.

systemctl edit mt7623-wifi.service

Tyhle služby mě při bootování opravdu dráždí. Chtěl jsem zkrátit timeout na 10 sec.

[**    ] (1 of 2) Job chrony-wait.service/start running (2min 3s / 3min 16s)
[   ***] (2 of 2) Job ifupdown-wait-online.s…tart running (2min 19s / no limit)

Editace služeb přes systemd musí probíhat takto:

systemctl edit chrony-wait

U editace je důležité vložit konfigurace přesně před řádek:

### Lines below this comment will be discarded

Pod tím řádkem je vidět použitá konfigurace. Cokoli co dám před ten řádek, tak ve výsledné konfigurace přepíše defaultní konfiguraci.

### Editing /etc/systemd/system/chrony-wait.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Service]
TimeoutStartSec=10

### Lines below this comment will be discarded

### /lib/systemd/system/chrony-wait.service
# [Unit]
# Description=Wait for chrony to synchronize system clock
# Documentation=man:chronyc(1)
# After=chronyd.service
# Requires=chronyd.service
# Before=time-sync.target
# Wants=time-sync.target
# 
# [Service]
# Type=oneshot
# # Wait for chronyd to update the clock and the remaining
# # correction to be less than 0.1 seconds
# ExecStart=/usr/bin/chronyc -h 127.0.0.1,::1 waitsync 0 0.1 0.0 1
# # Wait for at most 3 minutes
# TimeoutStartSec=180
# RemainAfterExit=yes
# StandardOutput=null
# 
# CapabilityBoundingSet=
# DevicePolicy=closed
# DynamicUser=yes
# IPAddressAllow=localhost
# IPAddressDeny=any
# LockPersonality=yes
# MemoryDenyWriteExecute=yes

Nesmím zapomenout restartovat systemd.

systemctl daemon-reload

Pokud vše proběhlo v pořádku, tak by mělo být vytvořeno překrytí originálního souboru:

cat /etc/systemd/system/chrony-wait.service.d/override.conf 
[Service]
TimeoutStartSec=10

Podobně jsem pracoval s další službou.

systemctl edit NetworkManager-wait-online.service

### Editing /etc/systemd/system/NetworkManager-wait-online.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Service]
Environment=NM_ONLINE_TIMEOUT=10

### Lines below this comment will be discarded

systemctl daemon-reload

Dříve jsem měnil port na kterém běží SSH pomocí editace souboru:

/etc/ssh/sshd_config

Tohle mi ale nefungovalo. Změnil jsem port v souboru a neprojevilo se to. To bylo hodně frustrující. Po delším hledání jsem zjistil, že změním přes editaci systemd.

systemctl edit ssh.socket 

A vložení konfigurace se změnou portu:

[Socket]
ListenStream=4444

systemctl daemon-reload

Konfigurace zafungovala.

V nastavování sítě je docela zmatek. Alespoň pro mě. Dříve jsem byl zvyklý nastavovat síť pomocí souboru /etc/network/interfaces a nechápal jsem, proč je tolik možností konfigurace sítě. Aby nedocházelo k problémům, je možné využít pouze jednu z možností konfigurace sítě:

• /etc/network/interfaces → přímo v souboru je napsané, že se nepoužívá, ale místo toho se používá NetworkManager. Tento soubor je tradičním způsobem konfigurace sítě v Debianu a odvozených distribucích. Je to vhodné pro statické konfigurace, ale nemá funkce pro snadné spravování dynamických sítí jako Wi-Fi.
• systemd-networkd → Je to součást systemd, což je systém a služba manager pro Linux. systemd-networkd je vhodný pro jednoduché až středně složité statické konfigurace sítě, ale není tak pohodlný pro dynamické síťové prostředí jako je Wi-Fi. Původně jsem měl konfiguraci tam, ale po instalaci systému jsem zjistil, že je služba zamaskovaná. Tak to asi má důvod a proto jsem se rozhodl pro použití NetworkManager.
• NetworkManager - Je to více uživatelsky přívětivé řešení, které je ideální pro stolní prostředí a dynamické síťové konfigurace (jako jsou Wi-Fi sítě). NetworkManager může být konfigurován pomocí grafického uživatelského rozhraní nebo pomocí příkazové řádky (např. nmcli).

Tady je konfigurace, kterou jsem měl původně v systemd-networkd. 4 ethernetové porty jsem měl v bridgi a routoval jsem je na wan:

br0.netdev:

[NetDev]
Name=br0
Kind=bridge

br0.network:

[Match]
Name=br0
 
[Network]
DHCP=no
Address=192.168.1.1/24

eth0.network:

[Match]
Name=eth0
 
[Network]
DHCP=no

lan0.network:

[Match]
Name=lan0
 
[Network]
Bridge=br0

lan1.network:

[Match]
Name=lan1
 
[Network]
Bridge=br0

lan2.network:

[Match]
Name=lan2
 
[Network]
Bridge=br0

lan3.network:

[Match]
Name=lan3
 
[Network]
Bridge=br0

wan.network:

[Match]
Name=wan
 
[Network]
DHCP=no
Address=....
DNS=212.96.161.6 212.96.160.7 8.8.8.8
Gateway=.....

Konfigurace jsem potřeboval dostat do NetworkManagera. Postupoval jsem podle tohoto návodu:

1. Vytvoření bridge (br0)

nmcli con add type bridge con-name br0 ifname br0

2. Přidání rozhraní LAN (lan0, lan1, lan2, lan3) do Bridge (br0):

nmcli con add type bridge-slave con-name lan0 ifname lan0 master br0
nmcli con add type bridge-slave con-name lan1 ifname lan1 master br0
nmcli con add type bridge-slave con-name lan2 ifname lan2 master br0
nmcli con add type bridge-slave con-name lan3 ifname lan3 master br0

3. Konfigurace Rozhraní eth0:

Pokud eth0 jiš existuje, tak změnit nastavení:

nmcli con mod eth0 ipv4.method disabled

Pokud neexistuje tak:

nmcli con add type ethernet con-name eth0 ifname eth0 ipv4.method disabled

4. Nastavení Rozhraní br0:

nmcli con mod br0 ipv4.addresses 192.168.1.1/24 ipv4.method manual

5. Konfigurace Rozhraní WAN:

nmcli con add type ethernet con-name wan ifname wan
nmcli con mod wan ipv4.addresses 84...../24 ipv4.gateway 255.255. ipv4.dns "212.96.161.6,212.96.160.7,8.8.8.8" ipv4.method manual

Nastavení je pak uložené v /etc/NetworkManager/system-connections. Nicméně toto ještě nestačilo.

Zjistil jsem, že networkmanager nemohl řídit síťová zařízení. Zjistil jsem to pomocí příkazu:

root@bananapir2:# nmcli device
DEVICE          TYPE      STATE                   CONNECTION 
lo              loopback  connected (externally)  lo         
wlp1s0          wifi      disconnected            --         
p2p-dev-wlp1s0  wifi-p2p  disconnected            --         
br0             bridge    unmanaged               --         
eth0            ethernet  unmanaged               --         
lan0            ethernet  unmanaged               --         
lan1            ethernet  unmanaged               --         
lan2            ethernet  unmanaged               --         
lan3            ethernet  unmanaged               --         
wan             ethernet  unmanaged               --   

Musel jsem zakomentovat jeden řádek v souboru pro ignoraci všech zařízení a přidal jsem ignoraci pouze wifi:

root@bananapir2:# cat /etc/NetworkManager/conf.d/10-ignore-interfaces.conf 
[keyfile]
#unmanaged-devices=interface-name:eth*,interface-name:wan*,interface-name:lan*,interface-name:br*
unmanaged-devices=interface-name:wlp*

A pak restartovat NetworkManagera:

systemctl restart NetworkManager

Tohle zafungovalo:

root@bananapir2:# nmcli device
DEVICE          TYPE      STATE                   CONNECTION 
wan             ethernet  connected               wan        
br0             bridge    connected               br0        
lo              loopback  connected (externally)  lo         
lan0            ethernet  connected               lan0       
lan1            ethernet  connected               lan1       
lan3            ethernet  connected               lan3       
eth0            ethernet  disconnected            --         
wlp1s0          wifi      disconnected            --         
p2p-dev-wlp1s0  wifi-p2p  disconnected            --         
lan2            ethernet  unavailable             --        

Pak jsem experimentoval se zařízením eth0. Chtěl jsem ho také dát ignorovat, ale nefungovala mi síť. Nerozumím úplně vazbě, proč musí být eth0 spuštěné. V log souboru se mi vypisovala hlášení, že se snaží každých 5 minut připojit a neúspěšně. Tak jsem do souboru /etc/NetworkManager/system-connections/eth0.nmconnection přidal řádek autoconnect=false. Takto vypadá celý soubor:

[connection]
id=eth0
uuid=7f2fe052-fe35-4c10-ac16-a09e12d8b7f6
type=ethernet
autoconnect=false
interface-name=eth0
 
[ethernet]
 
[ipv4]
method=disabled
 
[ipv6]
addr-gen-mode=default
method=auto
 
[proxy]

Dnsmasq nestartoval po spuštění. Musel jsem postupovat podle pokynů výše na této stránce.

apt install ssmtp

Stačilo překopírovat původní nastavení.

Dále některé programy chtěla nainstalovaný program mail. Zkusil jsem to vyřešit instalací:

root@bananapir2:~# apt install bsd-mailx

Z původního systému jsem mohl překopírovat obsah adresáře /etc/ufw/.

Instalaci jsem prováděl podle dřívějšího návodu AIDE. Všechno se mi podařilo, až na jednu věc. Skript /etc/cron.daily/aide se nespouštěl. Po dalším náhledu jsem zjistil, že se spouští, ale neprobíhá dle očekávání.

Takto vypadá obsah:

#!/bin/sh
 
# Skip if systemd is running.
if [ -d /run/systemd/system ]; then
    exit 0
fi
 
SCRIPT="/usr/share/aide/bin/dailyaidecheck"
if [ -x "${SCRIPT}" ]; then
    if command -v capsh >/dev/null; then
        capsh --caps="cap_dac_read_search,cap_audit_write+eip cap_setpcap,cap_setuid,cap_setgid+ep" --keep=1 --user=_aide --addamb=cap_dac_read_search,cap_audit_write -- -c "${SCRIPT} --crondaily"
    else
        # no capsh present, run with full capabilities
        "${SCRIPT}" --crondaily
    fi
fi

Na začátku propadnu podmínkou kvůli systemd. Zjistil jsem, že je tato konfigurace žádoucí a o AIDE se v Debian Bookworm stará systemd.

systemctl status dailyaidecheck.service

Případně editace:

systemctl edit dailyaidecheck.service

Zdá se, že AIDE check se díky systemd spouští mimo Cron a v defaultní instalaci kolem 4 hodiny ranní.Zatím jsem nezkoumal, jak to přenastavit, ale přes Cron cesta nepovede.

Vynutit kontrolu lze restartem služby:

systemctl restart dailyaidecheck.service

Bohužel AIDE check mi pořád nefungoval a pak jsem našel v logu tohle:

Jan 31 04:25:10 bananapir2 dailyaidecheck[12877]: ln: pevný odkaz '/var/log/aide//aide.log.0' na '/var/log/aide/aide.log' nebylo možné vytvořit: Operace není povolena
Jan 31 04:25:10 bananapir2 dailyaidecheck[12868]: Error hardlinking /var/log/aide/aide.log to /var/log/aide//aide.log.0
Jan 31 04:25:10 bananapir2 systemd[1]: dailyaidecheck.service: Main process exited, code=exited, status=8/n/a
Jan 31 04:25:10 bananapir2 systemd[1]: dailyaidecheck.service: Failed with result 'exit-code'.
Jan 31 04:25:10 bananapir2 systemd[1]: Failed to start dailyaidecheck.service - daily AIDE check.

Ve zkratce je to tak, že systemd nechce spouštět AIDE s právy roota, ale spouští pod uživatelem _aide. Testoval jsem sice práva zápisu, že uživatel _aide může do složky /var/log/aide zapisovat a vytvářet symlinky, ale problém stále přetrvával. Nekonec jsem to vyřešil tak, že spouštím AIDE s právy roota.

systemctl edit dailyaidecheck.service

[Service]
User=root
Group=adm

A nezapomenout na:

sytemctl daemon-reload

V armbianu je zapnuta funkce, že se ukousne kousek paměti RAM a do ní se loguje, aby nedocházelo k zatěžování SD karty. Jakmile dojde k naplnění tohoto kousku do 75%, tak se jednorázově přenesou logy na SD kartu a uvolní se RAM paměť.

Můj systém loguje docela dost. Defaultně je nastavena velikost této logovací RAM na 50 MB. Když jsem ji chtěl zvětšit, tak je potřšeba editova záznam v souboru /etc/default/armbian-ramlog.

#SIZE=50M
SIZE=150M

apt install logcheck logcheck-database

A pak jsem si přenesl jeden soubor, ve kterém mám uživatelskou konfiguraci.

Narazil jsem ale na problém. Hodně mnou nadefinovaných pravidel přestalo fungovat. Při podrobnějším zkoumání jsem zjistil, že mám časovou značku ve formátu: „2024-01-30T22:02:11.658801+01:00“. Logcheck ale očekává formát: „Jan 30 23:05:07“. I když jsem se snažil pravidla přespat a v regex101 fungovala, tak mi stále propadávala a nemohl jsem přijít jak na to. Nakonec jsem problém vyřešil úpravou syslogu, kdy jsem změnil formát časové značky na standardní, jak je popsáno níže.

Pro otestování konfigurace jsou pak informace zde: Logcheck

Musel jsem změnit čsaovou značku při logování, aby byla v klasickém formátu „Jan 30 23:05:07“. Vycházel jsem z článku a přidal jsem do /etc/rsyslog.conf dle instrukcí řádek $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat:

sudo cat /etc/rsyslog.conf
...truncated...
##########################
#### GLOBAL DIRECTIVES ####
###########################
...truncated...
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
...truncated...

systemctl restart rsyslog

Vycházel jsem z dřívějšího návodu: Logwatch

root@bananapir2:~# apt install softether-vpnserver

Po dalším zkoumání jsem zjistil, že softether jsou 2 vývojové větve. Jedna je stable a druhá je develop. V rámci debian balíčku jsem nainstaloval verzi 5.01 Developer Edition - build 9674. Byla sestaven 16.10.2022. Paradoxně je starší, než verze Stable edition aktuálně verze 4.43, Build 9799 z data 31.8.2023.

Nepochopil jsem, proč stable a develop edition mají rozdílné číslování, které podle mě způsobuje zmatek. Třeba časem přijdu na to, jakou to má logiku.

Každopádně jsem se rozhodl verzi ze správce balíčků odinstalovat a zkompilovat si vlastní z verze stable podle návodu SoftEtherVPN.

apt install wireguard-tools

Server

root@bananapir2:/etc/wireguard# wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key

Klient

root@bananapir2:/etc/wireguard# wg genkey | sudo tee /etc/wireguard/client_private.key | wg pubkey | sudo tee /etc/wireguard/client_public.key

root@bananapir2:/etc/wireguard# touch wg0.conf