Bananapi [Wiki]

Tato stránka je pouze pro čtení. Můžete si pouze prohlédnout zdrojový kód, ale ne ho měnit. Zeptejte se správce, pokud si myslíte, že něco není v pořádku.
====== 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.
<code bash>
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
</code> 

**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.

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

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:

<code>
case $BRANCH in

        legacy)

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

                ;;

esac
</code>

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 =====

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



===== 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.

<code bash>
sudo apt-get install minicom
sudo minicom -s
</code>

<code>
          +-----[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        |
          +--------------------------+
</code>

<code>
  +-----------------------------------------------------------------------+
  | 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?                                              |
  +-----------------------------------------------------------------------+
</code>

  * 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.

<code bash>
minicom --device /dev/ttyUSB0 --baudrate 115200
</code>

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

<code bash>
screen /dev/ttyUSB0 115200
</code>

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

<code bash>
screen -r
</code>

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

<code bash>
screen -ls
screen -r 1
</code>


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í:

<code bash>
systemctl disable systemd-networkd-wait-online.service
</code>

A podle všeho pro úplné vypnutí (možná se po aktualizaci systemd zase zapne a proto je potřeba ještě zamaskovat):
<code bash>
systemctl disable systemd-networkd-wait-online.service
</code> 

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

<code bash>
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)
</code>

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

<code bash>
systemctl edit --full systemd-networkd-wait-online.service
</code>

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

<code bash>
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --timeout=10
</code>

Nezapomenout pak na:

<code bash>
systemctl daemon-reload
</code>

==== Failed to start Entropy - based on the HAVEGE algorithm ====
Při bootování jsem se setkal s touto chybou:

<code bash>
[FAILED] Failed to start Entropy Da…based on the HAVEGE algorithm.
</code>

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í:

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


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 
<code bash>
/lib/systemd/system/haveged.service
</code>

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

<code bash>
sudo ip link set dev eth0 address XX:XX:XX:XX:XX:XX
</code>

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**

<code bash>
[keyfile]                                                                                                                                                                                                          
unmanaged-devices=interface-name:eth*,interface-name:wan*,interface-name:lan*,interface-name:br*
</code>

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**:

<code bash>
[connection]                                                                                                                                                                                                       
wifi.powersave = 2
</code>


==== 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í:

<code bash>
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

</code>

Když budu procházet jednotlivé soubory, tak **10-br0.netdev** vytvoří zařízení br0 typu síťový most (bridge).
<code bash>
root@bananapir2:/etc/systemd/network# cat 10-br0.netdev 
[NetDev]
Name=br0
Kind=bridge
</code>

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.
<code bash>
root@bananapir2:/etc/systemd/network# cat 10-br0.network 
[Match]
Name=br0

[Network]
#DHCP=yes
DHCP=no
Address=192.168.0.1/24
</code>


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.
<code bash>
root@bananapir2:/etc/systemd/network# cat 10-eth0.network 
[Match]
Name=eth0

[Network]
#DHCP=yes
</code>

Jednotlivé ethernetové porty budou sloužit jako switch a budou zapojeny do bridge:
<code bash>
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
</code>

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.
<code bash>
root@bananapir2:/etc/systemd/network# cat 10-wan.network 
[Match]
Name=wan 

[Network]
DHCP=ipv4
#Bridge=br0
</code>


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ů]].

<code bash>
[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
</code>

Po tomto nastavení je třeba restartovat síť:
<code bash>
systemctl restart systemd-networkd
</code>

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 ====

<code bash>
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
</code>

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

<code bash>
auto wan
iface wan inet static
	address 84.42.251.238
	netmask 255.255.255.248
	gateway 84.42.251.233
</code>

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. 

<code bash>
auto br0
iface br0 inet static
        address 192.168.0.1
        netmask  255.255.255.0
</code>


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

<code bash>
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>
</code>


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:

<code bash>
#After=network.target
After=network-online.target
</code>


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

<code bash>
/var/lib/misc/dnsmasq.leases
</code> 

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:

<code bash>
systemctl stop systemd-resolvd
systemctl disable systemd-resolvd
systemctl daemon-reload
</code>
==== 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:

<code bash>
root@cubieboard2:/home/nosek# cat /proc/sys/vm/min_free_kbytes
3442
</code>

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

<code bash>
vm.min_free_kbytes=67584
</code>  

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**:

<code bash>
#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
</code> 


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

<code bash>
sysctl -p
</code>


==== Další konfigurace po čerstvé instalaci ====
Všimnul jsem si, že je nainstalovaná OpenVPN. Nevyužívám, proto jsem odinstaloval.

<code bash>
apt --purge remove openvpn 
</code>

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

<code bash>
systemctl stop rpcbind
systemctl stop rpcbind.socket
systemctl disable rpcbind
</code>


===== 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**:

<code bash>
SystemMaxUse=10M
RuntimeMaxUse=10M
MaxRetentionSec=1day
MaxFileSec=1day
</code>

Log u konkrétní služby:
<code bash>
journalctl -u systemd-networkd-wait-online
</code>

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.

<code bash>
systemctl edit mt7623-wifi.service
</code>


==== 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. 

<code>
[**    ] (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)
</code>

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

<code bash>
systemctl edit chrony-wait
</code>

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

<code>
### Lines below this comment will be discarded
</code>

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. 

<code>
### 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

</code>

Nesmím zapomenout restartovat systemd.

<code bash>
systemctl daemon-reload
</code>


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

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

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

<code bash>
systemctl edit NetworkManager-wait-online.service
</code>

<code>
### 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
</code>

<code bash>
systemctl daemon-reload
</code>


==== SSH běžící na jiném portu ====

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

<code bash>
/etc/ssh/sshd_config
</code>

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. 

<code bash>
systemctl edit ssh.socket 
</code>

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

<code bash>
[Socket]
ListenStream=4444
</code>

<code bash>
systemctl daemon-reload
</code>

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**:

<code bash>
[NetDev]
Name=br0
Kind=bridge
</code>

**br0.network**:

<code bash>
[Match]
Name=br0

[Network]
DHCP=no
Address=192.168.1.1/24

</code> 


**eth0.network**:

<code bash>
[Match]
Name=eth0

[Network]
DHCP=no
</code>



**lan0.network**:

<code bash>
[Match]
Name=lan0

[Network]
Bridge=br0
</code>

**lan1.network**:

<code bash>
[Match]
Name=lan1

[Network]
Bridge=br0
</code>


**lan2.network**:

<code bash>
[Match]
Name=lan2

[Network]
Bridge=br0
</code>


**lan3.network**:

<code bash>
[Match]
Name=lan3

[Network]
Bridge=br0
</code>



**wan.network**:

<code bash>
[Match]
Name=wan

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

</code>



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

**1. Vytvoření bridge (br0)**

<code bash>
nmcli con add type bridge con-name br0 ifname br0
</code>


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

<code bash>
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
</code>


**3. Konfigurace Rozhraní eth0:**

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

<code bash>
nmcli con mod eth0 ipv4.method disabled
</code>

Pokud neexistuje tak:

<code bash>
nmcli con add type ethernet con-name eth0 ifname eth0 ipv4.method disabled
</code>


**4. Nastavení Rozhraní br0:**

<code bash>
nmcli con mod br0 ipv4.addresses 192.168.1.1/24 ipv4.method manual
</code>


**5. Konfigurace Rozhraní WAN:**

<code bash>
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
</code>

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:

<code bash>
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               --   
</code>

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

<code bash>
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*
</code>

A pak restartovat NetworkManagera:

<code bash>
systemctl restart NetworkManager
</code>

Tohle zafungovalo:

<code bash>
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             --        
</code>


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:

<code bash>
[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]

</code> 

==== Dnsmasq ====

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

==== SSMTP ====

<code bash>
apt install ssmtp
</code>

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í:

<code bash>
root@bananapir2:~# apt install bsd-mailx
</code>


==== Nastavení firewallu pomocí UFW ====

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

<adm warning>Je také potřeba přenést (editovat) soubor **/etc/default/ufw**. Na to jsem zapomněl a pěkně jsem se potrápil. </adm>


==== 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:

<code bash>
#!/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
</code>

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. 

<code bash>
systemctl status dailyaidecheck.service
</code>

Případně editace:

<code bash>
systemctl edit dailyaidecheck.service
</code>

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:

<code bash>
systemctl restart dailyaidecheck.service
</code>


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

<code bash>
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.
</code>

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. 

<code bash>
systemctl edit dailyaidecheck.service
</code>

<code bash>
[Service]
User=root
Group=adm
</code>

A nezapomenout na:

<code bash>
sytemctl daemon-reload
</code>


==== 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**.

<code bash>
#SIZE=50M
SIZE=150M
</code>



==== Instalace Logcheck ====

<code bash>
apt install logcheck logcheck-database
</code>

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**:

<code bash>
sudo cat /etc/rsyslog.conf
...truncated...
##########################
#### GLOBAL DIRECTIVES ####
###########################
...truncated...
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
...truncated...
</code>


<code bash>
systemctl restart rsyslog
</code>

==== Logwatch ====

Vycházel jsem z dřívějšího návodu: [[it:server:monitoring:logwatch|]]


==== Instalace Softether ====

<code bash>
root@bananapir2:~# apt install softether-vpnserver
</code> 

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 ====

<code bash>
apt install wireguard-tools
</code>

=== Generování klíčů ===

**Server**

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


**Klient**
<code bash>
root@bananapir2:/etc/wireguard# wg genkey | sudo tee /etc/wireguard/client_private.key | wg pubkey | sudo tee /etc/wireguard/client_public.key
</code>

=== Vytvoření WireGuard konfiguračního souboru ===

<code bash>
root@bananapir2:/etc/wireguard# touch wg0.conf
</code>