====== Bananapi ====== Na jednodeskové servery s oblibou používám distribuci [[https://armbian.com|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. ===== Banana Pi R1 ===== * [[https://forum.armbian.com/topic/20213-bananapi-r1-lamobo-r1-images/|Banapi-R1 už není podporován, je potřeba kompilace Armbianu]] * [[https://wiki.banana-pi.org/Banana_Pi_BPI-R1|Wiki k Banana Pi R1]] ===== Banana Pi R2 ===== 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. * [[https://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:hardware|Wiki k Banana Pi R2 - s odkazem na řešení autozapínání]] * [[https://wiki.banana-pi.org/Banana_Pi_BPI-R2|Wiki k Banana Pi R2]] * [[https://wiki.banana-pi.org/Banana_Pi_BPI-R2_Pro|Wiki k Banana Pi R2 - Pro]] * [[https://forum.banana-pi.org/t/bpi-r2-boot-power-suppy/3647/57|Automatické zapínání po připojení napájení - diskuse]] * [[https://forum.banana-pi.org/t/bpi-r2-ethernet-switch/4134/4|BPI-R2 Ethernet Switch]] * [[https://bananapi.gitbook.io/banana-pi-bpi-r2-open-source-smart-router/chapter1/bpi-r2-sata-interface| BPI-R2 SATA interface a detailní dokumentace k dalším periferiím od výrobce výrobce]] * [[https://wiki.banana-pi.org/Banana_Pi_BPI-R2#BPI-R2_GPIO_Pin_define| Pinout ]] ==== Automatické zapnutí po připojení napájení ==== 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 [[https://forum.banana-pi.org/t/bpi-r2-boot-power-suppy/3647/54|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). {{:it:jednodeskove-pocitace:pasted:20221117-192646.png}} 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: {{:it:jednodeskove-pocitace:pasted:20221117-192741.png}} 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. {{:it:jednodeskove-pocitace:img_20221117_182908.jpg?400|}} Určitě to lze udělat hezčím způsobem, nicméně řešení mi funguje. ===== Kompilace ===== Pokud není možné využít komunitní obrazy [[https://github.com/armbian/community]], nezbývá než se pustit do vlastní [[https://docs.armbian.com/Developer-Guide_Build-Preparation/|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ě [[https://docs.armbian.com/Developer-Guide_Build-Options/|odkaz na další parametry při instalaci]]. Dále přihazuji screeny obrazovek z kompilace jádra. {{:it:jednodeskove-pocitace:pasted:20221113-151705.png}} **Do not change the kernel configuration** {{:it:jednodeskove-pocitace:pasted:20221113-151724.png}} Dole jsem zvolil **Show CSC/WIP/EOS/TVB** {{:it:jednodeskove-pocitace:pasted:20221113-151815.png}} Musím potvrdit **I understand and agree** {{:it:jednodeskove-pocitace:pasted:20221113-151839.png}} Zvolím konkrétní verzi desky. Banana Pi R1 má kódové označení "lamobo". {{:it:jednodeskove-pocitace:pasted:20221113-151959.png}} Volba **current** {{:it:jednodeskove-pocitace:pasted:20221113-152043.png}} ===== Kompilace konkrétní verze jádra ===== 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 [[https://github.com/armbian/build/issues/6094|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. ===== Zapsání obrazu na SD kartu ===== dd if=Armbian_22.11.0-trunk_Bananapir2pro_kinetic_edge_6.0.7.img of=/dev/sda bs=8M status=progress ===== BananaPi R2 - Debug-UART ===== * 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 {{:it:jednodeskove-pocitace:pasted:20221112-180040.png}} ==== Minicom ==== 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 ==== Screen ==== 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 [[https://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/|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 **?**. ===== Problémy po nabootování ===== ==== systemd-networkd-wait-online ==== 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í. [[https://askubuntu.com/questions/1421785/a-start-job-is-running-for-wait-for-network-to-be-configured-because-ipv6-blocke|Zde]] je o příčině popsáno více. V [[https://askubuntu.com/questions/972215/a-start-job-is-running-for-wait-for-network-to-be-configured-ubuntu-server-17-1|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 ==== Failed to start Entropy - based on the HAVEGE algorithm ==== Při bootování jsem se setkal s touto chybou: [FAILED] Failed to start Entropy Da…based on the HAVEGE algorithm. V [[https://forum.openmediavault.org/index.php?thread/42572-failed-to-start-entropy-daemon-after-update-to-omv-6-0-19/|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é [[https://forum.armbian.com/topic/19166-cannot-start-havegedservice-and-sysstatservice-failed/|ř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í. ===== Změna MAC adresy ===== 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/ ===== Nastavení sítě ===== 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ů. ==== NetworkManager ==== 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 ==== Systemd Network ==== 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í [[https://www.linode.com/docs/guides/systemd-networkd/|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. ==== Konfigurace /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 ==== Nastavení vm.min_free_kbytes ==== 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 ==== Další konfigurace po čerstvé instalaci ==== 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 ===== log2ram a journald ===== 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/ ===== Nová instalace a řada fuckupů ===== 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 [[https://www.armbian.com/bananapi-r2/|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**. ==== mt7623-wifi.service ==== 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 ==== další služby a zdržování při bootování ==== 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 ==== SSH běžící na jiném portu ==== 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. ==== Nastasvení sítě systemd/interfaces/NetworkManager ==== 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 ==== Dnsmasq nestartoval po spuštění. Musel jsem postupovat podle pokynů výše na této stránce. ==== SSMTP ==== 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 ==== Nastavení firewallu pomocí UFW ==== Z původního systému jsem mohl překopírovat obsah adresáře **/etc/ufw/**. Je také potřeba přenést (editovat) soubor **/etc/default/ufw**. Na to jsem zapomněl a pěkně jsem se potrápil. ==== AIDE ==== Instalaci jsem prováděl podle dřívějšího návodu [[it:server:monitoring: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 ==== změna velikosti zRAM na logování ==== 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 ==== Instalace Logcheck ==== 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 [[https://regex101.com/|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: [[it:server:monitoring:logcheck|]] ==== Rsyslog ==== 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 [[https://www.baeldung.com/linux/syslog-change-date-format|č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 ==== Logwatch ==== Vycházel jsem z dřívějšího návodu: [[it:server:monitoring:logwatch|]] ==== Instalace Softether ==== 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 [[it:software:softether|]]. ==== Wireguard ==== apt install wireguard-tools === Generování klíčů === **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 === Vytvoření WireGuard konfiguračního souboru === root@bananapir2:/etc/wireguard# touch wg0.conf