@FrankM
Hallo Frank,

Die Bridge selber ist recht einfach.
Allerdings wenn ich das Netzwerkinterfaces vom Rock zusammen mit denen der i350 Karte konfigurieren, dann gibt es Performance Probleme.
Ich muss mal die Performance der RTL messen. Eventuell ist hier das Bottleneck.

Ich werde das ganze zuerst mal nur als Switch einsetzen.
Die Performance vom RockPro64 brauche ich nicht. Ich habe aber nix anderes gefunden mit PCIe. Oder gibt es da eine kleinere SBC Lösung?

Den kleinsten Anschluss den die Telekom hat, also 50mb/10mb. Der Rest ist mir zu teuer. Komme von Vodafone Kabel Max mit 1 Gigabyte mit gleichen Preis (40€ / Monat). ArchLinux updates dauern merklich länger aber sonst ist es okay.

edit

Das WAN6 interface kann weg. Im Wiki steht sinngemäß bei PPPoE wird das ipv6 interface automatisch angelegt. Sieht man auch oben WAN_6.

Dann kann man nur hoffen das OpenWrt den R5S bald Unterstützt.

@FrankM sagte in Manjaro KDE Plasma 21.2.6:

Nächste Herausforderung 😉

Nachdem ich den NanoPi R5S nun als Router & NAS nutze, Samba liefert die Daten aus, stellte ich fest das nach einem Reboot die Verzeichnisse nicht gemountet wurden.

Bei mir schauen die Network-Storages so aus in der fstab:

jessie:/mnt/alpha /mnt/alpha nfs4 _netdev,users,noauto,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min,x-systemd.requires=network.target

Funktioniert absolut unauffällig seit Jahren.

Warum wollte iich unbedingt mal endlci Python 3.10 ausprobieren? Wegen dem Match-Case Statement. Ich wollte mal ausprobieren, ob das angenehmer zu programmieren ist, als diese verschachtelten if-else Statements.

Aus der Anleitung

match subject: case <pattern_1>: <action_1> case <pattern_2>: <action_2> case <pattern_3>: <action_3> case _: <action_wildcard>

Einen schönen Beitrag habe ich auch im Internet gefunden. Ok, hier mal ein Beispiel.

match_list = [backup_data[row].rest, bool(backup_data[row].password)] match match_list:

Ich erzeuge eine Liste, mit zwei Variablen.

backup_data[row].rest - 0/1 backup_data[row].password - password/keines gesetzt

Das kann man dann abfragen mit

case ["0", False]:

Dann gibt es in meinem Fall noch

case["0", True]: case["1", False]: case["1", False]:

Dann könnten man noch das hier machen

case _:

Der fängt alles ab, was vorher nicht erfolgreich war.

Ich finde das recht praktisch, weil es doch um einiges angenehmer zu lesen ist.

Ich bin ja jetzt wegen ein paar Problemen mit VSCode bzw. VSCodium bei Pycharm gelandet. Thread zu den Problemen.

Kopierter Text aus dem o.g. Thread.

Was ist mir positiv aufgefallen?

Wenn ich VSCodium neu installiert habe, habe ich unheimlich mit Python Versionen, pipenv usw. zu kämpfen gehabt. Bis da mein Projekt wieder lief, konnte schon mal was Zeit vergehen.

Mit Pycharm Ordner ausgewählt, angeklickt das man dem Coder vertraut. Noch eine Python Version ausgewählt, danach fragt er das er eine pipenv Umgebung gefunden hat und diese nutzen möchte. Ja angeklickt und fertig. Keine zwei Minuten und das Projekt lief wieder 🤓

Erster Git Commit ging auch sofort und ohne Murren.

Schon mal ganz viele Pluspunkte gesammelt.

Was mich aktuell beschäftigt, ist der Tab Problems, da hatte ich vorher deutlich weniger. Da muss ich mich noch was einarbeiten und schauen, wo man das alles einstellen kann.

Neuer Inhalt

Ich habe jetzt ein wenig Pycharm kennen gelernt und ein paar nützliche Dinge gefunden.

Man kann unter .pylintrc folgendes eintragen

# List of note tags to take in consideration, separated by a comma. notes=FIXME, XXX, TODO

Wenn man diese Worte in den Quellcode als Kommentar einträgt, kann man z.B. nicht commiten, weil man noch nicht fertig ist 🙂 Sehr praktisch, da ich ja immer gerne im Code einfach mal rum teste.

1c1bbcea-8677-4a97-9182-4db9bf399112-image.png

bc515074-66de-43eb-9795-42d9da54a71e-image.png

Ich habe auch ein nettes Template gefunden, was mich an VSCodium erinnern soll 😉

c3f1471b-37ce-449e-b33b-078c3e4a3edd-image.png

Wird hier sicherlich ergänzt, wenn ich mal wieder was cooles finde.

Hallo zusammen,
nach langem testen möchte ich nun mein eigenes custom build für den NanoPi R4S veröffentlichen. Vielen Dank nochmal an FrankM für die beiden NanoPi's 😊
Längste Laufzeit war bei ca. 14 Tagen, dann musste ich wegen Update neustarten. Ich konnte bisher keine Fehler feststellen.

Wenn gewünscht kann ich auch ein Stable Release 22.03 raushauen.
Für Kritik bin ich immer offen. Leider kann ich selbst keine großen Änderungen am Code durchführen, da ich kein Coder bin.

Basierend auf OpenWrt SNAPSHOT r20572-7abf69cb36 / LuCI Master git-22.245.77360-10bcb22

Vorinstallierte Pakete:

collectd collectd-mod-sensors ddns-scripts htop luci luci-app-sqm nano wireguard complete package list

Unter der Haube geändert:

SquashFS 1024 MB (bitte passende SD-Card >=1GB) Realtek r8168 linux driver 8.050.03 source u-boot patches von Friendlyarm Unterstützung des NanoPi R4S 1GB source Ändern der Load Balance. IRQ an A72 cores und queues gehen an alle 6 cores. source Kernel 5.15 support. Merged open PR CPU Gov zu "performance" geändert. Um hohe Pings zu vermeiden. Stromverbrauch und Temperatur steigen dadurch nicht.

Release
GitHub Repo

Ich habe da jetzt gestern stundenlang mit rum gespielt, insbesondere Deinstallation, Neuinstallation, VSCode Installation usw. Das ging einfach nicht.

Irgendwo meine ich dann gelesen zu haben, das VSCode auf python 3.9 festgenagelt ist und deswegen so einige Dinge nicht gehen.

Nagelt mich darauf nicht fest, ich bin in dieser Coding Welt kein Profi.

Dann fiel mir ein, das ich schon vor einigen Monaten mal kurz einen Blick in Pycharm geworfen hatte. Gefiel mir damals gar nicht.

Das habe ich heute mal auf die Platte geworfen um zu schauen, ob das vernünftig mit dem o.g. Problem umgehen kann.

6f1c3906-05a3-4126-81d4-7fdf6aa27faa-grafik.png

Puuuh, da kann man ja noch viel mehr einstellen als bei VSCode, oder mindestens ähnlich viel. Das kann einen ganz schön überfordern. Also Stück für Stück die nächsten Tage.

Was ist mir positiv aufgefallen?

Wenn ich VSCodium neu installiert habe, habe ich unheimlich mit Python Versionen, pipenv usw. zu kämpfen gehabt. Bis da mein Projekt wieder lief, konnte schon mal was Zeit vergehen.

Mit Pycharm Ordner ausgewählt, angeklickt das man dem Coder vertraut. Noch eine Python Version ausgewählt, danach fragt er das er eine pipenv Umgebung gefunden hat und diese nutzen möchte. Ja angeklickt und fertig. Keine zwei Minuten und das Projekt lief wieder 🤓

Erster Git Commit ging auch sofort und ohne Murren.

Schon mal ganz viele Pluspunkte gesammelt.

Was mich aktuell beschäftigt, ist der Tab Problems, da hatte ich vorher deutlich weniger. Da muss ich mich noch was einarbeiten und schauen, wo man das alles einstellen kann.

Ich halte euch auf dem Laufenden..

Vielleicht fliegt ja das VSCo** Zeug runter!? Mal sehen..

Da ich heute mal wieder Startprobleme hatte, musste ich mich mit der Installation eines Zertifikates intensiver beschäftigen.

Im Ausgangs Thread habe ich einen wichtigen Installationsschritt vergessen, das Zertifikat muss auch noch installiert werden. Das habe ich heute oben so ergänzt. Jetzt sollte es hoffentlich komplett sein.

Der 5. Point Release für Debian Bullseye ist veröffentlicht.

Das Debian-Projekt freut sich, die fünfte Aktualisierung seiner Stable-Distribution Debian 11 (Codename "Bullseye") ankündigen zu dürfen. Diese Zwischenveröffentlichung behebt hauptsächlich Sicherheitslücken der Stable-Veröffentlichung sowie einige ernste Probleme. Es sind bereits separate Sicherheitsankündigungen veröffentlicht worden, auf die, wenn möglich, verwiesen wird.

Außerdem ist noch 10.13 released worden.

https://www.debian.org/News/2022/2022091002

@Dude Danke für die Tipps. Die Tools waren mir bekannt, auch wenn ich sie noch nicht selber getestet habe. Man kann ja nicht alles ausprobieren 🙂

Unbound bot sich hier einfach als Test für die LXC Container an.

Es geht weiter, der erste ☕ und ich bin mit der Lösung nicht so richtig zufrieden, also suchen.

Als erstes habe ich heute Morgen ein frisches SD-Karten Image mit Docker von FreindlyWrt genommen und auf meinem Test NanoPi R5S installiert. Dort mal die Config angeschaut um zu sehen, ob der Eintrag standardmäßig gesetzt ist. Doch dort taucht dann einmal eine ganz ander Config auf 🙄

# The following settings require a restart of docker to take full effect, A reload will only have partial or no effect: # bip # blocked_interfaces # extra_iptables_args # device config globals 'globals' # option alt_config_file '/etc/docker/daemon.json' option enable '1' option data_root '/mnt/nvme_part2/docker' option log_level 'warn' option iptables '1' #list hosts 'unix:///var/run/docker.sock' # option bip '172.18.0.1/24' # option fixed_cidr '172.17.0.0/16' # option fixed_cidr_v6 'fc00:1::/80' # option ipv6 '1' # option ip '::ffff:0.0.0.0' # list dns '172.17.0.1' # list registry_mirrors 'https://<my-docker-mirror-host>' list registry_mirrors 'https://hub.docker.com' option remote_endpoint '0' # option bridge 'br-container' # Docker ignores fw3 rules and by default all external source IPs are allowed to connect to the Docker host. # See https://docs.docker.com/network/iptables/ for more details. # firewall config changes are only additive i.e firewall will need to be restarted first to clear old changes, # then docker restarted to load in new changes. config firewall 'firewall' option device 'docker0' list blocked_interfaces 'wan' option extra_iptables_args '--match conntrack ! --ctstate RELATED,ESTABLISHED' # allow outbound connections

Das interessiert uns jetzt

list blocked_interfaces 'wan' option extra_iptables_args '--match conntrack ! --ctstate RELATED,ESTABLISHED' # allow outbound connections

Wenn ich das jetzt alles richtig verstehe, muss WAN geblockt sein, weil sonst der Docker Host offen im Netz steht (Hierbei bin ich mir nicht 100% sicher)
Die zweite Zeile ist eine iptables Regel, die es den Containern dann ermöglicht das Internet zu erreichen.

Das habe ich jetzt so eingestellt und getestet.

root@b9ffae24913a:/# ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=17.151 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=16.553 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=20.630 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=13.948 ms ^C--- 1.1.1.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 13.948/17.071/20.630/2.382 ms root@b9ffae24913a:/# ping google.de PING google.de (142.250.185.195): 56 data bytes 64 bytes from 142.250.185.195: icmp_seq=0 ttl=58 time=23.797 ms 64 bytes from 142.250.185.195: icmp_seq=1 ttl=58 time=16.953 ms 64 bytes from 142.250.185.195: icmp_seq=2 ttl=58 time=19.441 ms ^C--- google.de ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 16.953/20.064/23.797/2.829 ms

Ich hoffe mal das ich diese Thema jetzt zu den Akten legen kann.

Wenn was falsch ist, bitte hier kommentieren, damit ich das ändern kann.

Heute kam dann das erste Update auf die Version 2.15 und die Frage "Wie aktualisiert man das?"

Entwarnung, das ist furchtbar einfach und wird auch klasse erklärt.

Upgrading Portainer

Upgrade Docker Standalone Backup anlegen

80951fd0-ac5f-42e9-ac8a-7378962f7aa5-grafik.png

Docker Container austauschen

docker stop portainer
docker rm portainer
docker pull portainer/portainer-ce:latest
docker run -d -p 8000:8000 -p 9443:9443 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Portainer Agent

Wenn man einen Agent laufen hat, so wie ich auf meinem NanoPi R5S, dann ist dieser jetzt auch dran 😉

docker stop portainer_agent docker rm portainer_agent docker pull portainer/agent:latest docker run -d -p 9001:9001 --name portainer_agent --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker/volumes:/var/lib/docker/volumes portainer/agent:latest Fazit

Wirklich einfach und alles ohne Probleme. Im Prinzip wird nur der Docker Container ausgetauscht, die vorhandenen Daten im Fall des Standalone Portainer werden ja nicht angefasst und sind nach der Neuinstallation natürlich wieder vorhanden.

@hase567 Moin,

ich verwende "leider" Apache und kann den Fehler daher nach reproduzieren. Vielleicht kannst du die genannte Option einmal auskommentieren, den Fehler reproduzieren und hier posten? Dann schaue ich mir das gerne mal an.

Beste Grüße!

Ich wollte ja eigentlich auf dem NanoPi R5S auch checkmk als Docker Container laufen lassen, so hätte ich das alles an einem Ort, aber.....

checkmk wird leider nur für eine Architektur released 😞

3ea5ce2a-b04b-444c-b3a4-f56496ba83fb-grafik.png

Dann läuft der halt auf meinem Haupt-PC so nebenbei mit...

Wie ich gerade im Quartz64 Development Chat lese, ist PCIe für den rk3568 gemerged. Kommt dann wohl mit Kernel 6.1. Und das sollte auch mit diesen OpenWrt Images helfen.

Mit der Einführung der Kompression in Restic v0.14.0 ist das Verlangen groß auch zu sehen, welche Version das Repo hat. E gibt die alte Version v1 und die neue mit Kompression v2.

Das hat mich natürlich auch interessiert und es gibt da auch keine direkte Anzeigemöglichkeit für. Im Forum wurde mir dann geraten, das mit

restic cat config

zu machen. Das habe ich nun so eingebaut, das in der Übersicht die Version angezeigt wird. Da das je nach Ort des Repos ein wenig dauern kann, habe ich die Funktion als QThread integriert mit dem bekannten Spinner.

b3f1ed1a-b943-4d90-9f8b-70aba9a9eed6-grafik.png