Posts Tagged ‘Debian’

Mittwoch, 2. August 2023

unifi-video unter Debian Bullseye installieren

ACHTUNG: Wie ich erst nach der Installation von unifi-video und dem Verfassen des Blog-Beitrags realisiert habe, wurde UniFi Video eingestellt (End-of-Life EOL) (Quelle). Das Nachfolgeprodukt is UniFi Protect, welches ausschliesslich auf UniFi-Hardware läuft. Dann wird es dann wohl doch einfach eine Wyze Cam

Momentan evaluiere ich für einen Bekannten UniFi Protect Videokameras.

Im Einführungs-Video What do I need to run Unifi Protect? (in diese Web-Seite eingebettet) zu UniFi Protect (der Produktlinie von Ubiquiti UniFi Videokameras) wird einem gesagt, dass man einen UniFi Cloud Key (UCK-G2-Plus), eine UniFi Dream Machine Pro (UDM-Pro) oder eine Ubiquiti Network Video Recorder-Appliance (UNVR) kaufen muss, um das LAN mit Network Video Recording-Fähigkeiten auszurüsten.

Ich habe aber meinen UniFi-Controller als Software-Paket auf einem Lenovo-Laptop mit Debian Bullseye laufen.

Tatsächlich ist auch ein Debian Package namens unifi-video verfügbar. Dieses lässt sich auch unter Bullseye installieren.

Entweder mit einem Bash-Script von Glenn Rietveld. Das Herunterladen von Bash-Scripts aus dem Internet und ausführen als root sagt mir aber nicht wirklich zu. Berufskrankheit.

Es geht aber auch anders, für Debianistas ganz „normal“: Mit apt-get install unifi-video. Wie man das macht, ist aber im Internet schlecht dokumentiert. Mit etwas pröbeln habe ich es soeben geschafft:

Zuerst fügt man den GPG-Key des Repositories hinzu:

# curl -fsSL http://www.ubnt.com/downloads/unifi-video/apt-3.x/unifi-video.gpg.key | apt-key add -

Anschliessend fügt man folgende Zeile in /etc/apt/sources hinzu:

...
deb         http://www.ubnt.com/downloads/unifi-video/apt-3.x stretch ubiquiti
...

WICHTIG: Obwohl ich bullseye am Laufen habe, kennt das Repository nur stretch. Dennoch funktioniert danach ein …

# apt-get update
# apt-get install unifi-video

… problemlos.

Danach läuft das Teil auch schon:

# ps ax | grep unifi-video
3629722 ?        Ss     0:00 unifi-video -cwd /usr/lib/unifi-video -user unifi-video -home /usr/lib/jvm/java-1.8.0-openjdk-amd64 -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi-video/lib/airvision.jar -pidfile /var/run/unifi-video/unifi-video.pid -procname unifi-video -Dav.tempdir=/var/cache/unifi-video -Djava.security.egd=file:/dev/./urandom -Xmx941M -Xss512K -XX:+UseG1GC -XX:+UseStringDeduplication -XX:MaxMetaspaceSize=1024M -Djava.library.path=/usr/lib/unifi-video/lib -Djava.awt.headless=true -Djavax.net.ssl.trustStore=/usr/lib/unifi-video/data/ufv-truststore -Dfile.encoding=UTF-8 com.ubnt.airvision.Main start
3629724 ?        Sl     0:32 unifi-video -cwd /usr/lib/unifi-video -user unifi-video -home /usr/lib/jvm/java-1.8.0-openjdk-amd64 -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi-video/lib/airvision.jar -pidfile /var/run/unifi-video/unifi-video.pid -procname unifi-video -Dav.tempdir=/var/cache/unifi-video -Djava.security.egd=file:/dev/./urandom -Xmx941M -Xss512K -XX:+UseG1GC -XX:+UseStringDeduplication -XX:MaxMetaspaceSize=1024M -Djava.library.path=/usr/lib/unifi-video/lib -Djava.awt.headless=true -Djavax.net.ssl.trustStore=/usr/lib/unifi-video/data/ufv-truststore -Dfile.encoding=UTF-8 com.ubnt.airvision.Main start
3632137 ?        Sl     0:05 bin/mongod --config /usr/lib/unifi-video/conf/mongodv3.0+.conf
3633173 ?        Sl     0:00 bin/evostreamms /usr/lib/unifi-video/conf/evostream/config.lua

Das Web-Interface öffnet man über 1.2.3.4:7443 (https nicht vergessen, mit http klappt es nicht).

Versucht man stattdessen, anstelle von stretch das Paket für den Release bullseye herunterzuladen, erhält man folgende Fehlermeldung:

...
Ign:8 https://dl.ui.com/unifi-video/apt-3.x bullseye InRelease
Err:9 https://dl.ui.com/unifi-video/apt-3.x bullseye Release
  404  Not Found [IP: 13.224.100.217 443]
Reading package lists... Done
E: The repository 'http://www.ubnt.com/downloads/unifi-video/apt-3.x bullseye Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Konsultierte Web-Seiten:

Tags: , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Montag, 3. Juli 2023

ConBee II USB-Stick wird nach Debian-Update nicht mehr erkannt

Nach einer Stunde debugging, USB-Stick ausstöpseln, einstöpseln und dutzende Male Firmware flashen entdecke ich endlich After a sudo apt update && sudo apt full-upgrade and a reboot deconz no longer connects to the conbee 2:

Das heute Vormittag eingespielte Debian-Update löscht /dev/serial/by-id/*. Dies verhindert offenbar, dass deCONZ Phoscon den USB-Stick findet. Das Problem erkennt man auch daran, dass folgender Befehl nichts findet:

# GCFFlasher_internal -l
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path             | Vendor | Product | Serial     | Type
-----------------+--------+---------+------------+-------

Auf einem Raspberry Pi mit existierendem /dev/serial/by-id/* schaut das hingegen noch so aus:

# GCFFlasher_internal -l
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path             | Vendor | Product | Serial     | Type
-----------------+--------+---------+------------+-------
/dev/ttyAMA0     | 0x0000 | 0x0000  |            | RaspBee 
/dev/ttyACM0     | 0x1CF1 | 0x0030  | DE1234567  | ConBee II

Die Lösung: In deconz.service einfach noch das USB-Device mitgeben: ExecStart=/usr/bin/deCONZ ... --dev=/dev/ttyACM0. ttyACM0 ersetzt man mit dem tatsächlichen Device (findet man mittels dmesg gleich nachdem man es eingestöpselt hat).

Danach den Service stoppen, neu starten — und dann sollte die ZigBee-Welt wieder in Ordnung sein (der Ausfall des USB-Sticks während zwölf Stunden machte es nötig, dass ich bei vielen Sensoren kurz den Knopf manuell drücken musste, um sicherzustellen, dass die Verbindung und Datenanlieferung noch funktioniert …)

Wichtig: dmesg muss den USB-Stick erkennen …

...
[55209365.334638] usb 2-3: new full-speed USB device number 15 using xhci_hcd
[55209365.488837] usb 2-3: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[55209365.493029] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[55209365.497062] usb 2-3: Product: ConBee II
[55209365.501528] usb 2-3: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[55209365.505835] usb 2-3: SerialNumber: DE1234567
[55209365.512617] cdc_acm 2-3:1.0: ttyACM3: USB ACM device
...

… und mit lsusb muss er auch aufgeführt sein — sonst könnte ein anderes Problem vorliegen:

...
Bus 002 Device 013: ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]
...

In der Zwischenzeit hatte ich alles ausprobiert, insbesondere dutzende Male das Firmware geflashed. Hierzu habe ich die ZIP-Datei des neuesten (Beta) Release 4.0.4 von gcfflasher heruntergeladen und auf zwei Linux-PCs sowie macOS entpackt.

Um den Flasher zu kompilieren, installiert man unter Debian zuerst die benötigten Pakete (unter macOS geht’s gleich weiter zur Kompilation):

# apt-get install pkg-config build-essential libgpiod-dev

Danach kompiliert man das Binary:

./build_posix.sh

Anschliessend lädt man die neueste Firmware vom offiziellen Server in das Flasher-Verzeichnis herunter, und gibt dann unter Linux ein:

# ./GCFFlasher -d /dev/ttyACM3 -t 60 -f ./deCONZ_ConBeeII_0x26780700.bin.GCF

Unter macOS lautete der Befehl:

# ./GCFFlasher -d /dev/cu.usbmodemDE1234567 -t 60 -f ~/tmp/deCONZ_ConBeeII_0x26780700.bin.GCF

Auch hier wieder beachten, das effektive Device (unter Linux war es bei mir auf einem Laptop /dev/ttyACM0, auf dem anderen /dev/ttyACM3; unter macOS war es /dev/cu.usbmodemDE24421441) mitzugeben. Dass der Flasher richtig funktioniert, seht ihr, wenn folgende Ausgabe erscheint:

read file success: ./deCONZ_ConBeeII_0x26780700.bin.GCF (163244 bytes)
flash firmware
command reset done
query bootloader id V1
bootloader detected (60)
 100 %ding ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
done, wait validation...
firmware successful written

Manchmal auch

read file success: ./deCONZ_ConBeeII_0x26780700.bin.GCF (163244 bytes)
flash firmware
command reset done
query bootloader id V1
bootloader detected (60)
bootloader syned: unlock! READY
 100 %ding ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
done, wait validation...
firmware successful written

Den Diskussionsforen entnehme ich zudem, dass es vorkommen kann, dass das System den USB-Stick „vergisst“. In dem Fall startet man den Firmware-Update-Befehl bevor man den USB-Stick überhaupt eingestöpselt hat. Während sich die Meldungen à la retry connect bootloader /dev/cu.usbmodemDE1234567 auf dem Bildschirm stapeln, stöpselt man den USB-Stick ein, und dann sollte das Firmware-Update umgehend beginnen.

Links

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. März 2023

Die Log-Syntax zu geöffneten root sessions in auth.log hat sich geändert

Ich verwende monit extensiv, um viele Aspekte meines Linux-Server Fuhrparks zu überwachen.

Ein detektivischer „Sicherheitscheck“, den ich mit monit abdecke, sind Alarme zu frisch geöffneten root Sessions (der Informationssicherheits-Mensch in mir erhofft sich damit, irgendeines Tages so einen Angreifer zu entdecken):

check file su_root with path /var/log/auth.log
  if match "session opened for user root by" then alert

Ich kriege jedes Mal ein Email, wenn jemand eine root-Session eröffnet. Denn in auth.log findet sich dann jeweils folgender Eintrag:

Mar 26 13:33:16 localhost sudo: pam_unix(sudo:session): session opened for user root by pi(uid=0)

Seit einiger Zeit sind diese Emails für einige meiner Debian-Server verstummt (konkret: die x86er, während die Raspberry Pis fröhlich vor sich hermelden).

Heute machte ich mich daran, das Problem zu erforschen und zu lösen.

Erkenntnis: Die Syntax hat sich leicht geändert:

Mar 26 13:33:05 SERVER su: pam_unix(su-l:session): session opened for user root(uid=0) by mario(uid=0)

Deshalb habe ich die monit-Konfiguration angepasst:

check file su_root with path /var/log/auth.log
  if match "session opened for user root" then alert

Jetzt kommen die Alarme wieder …

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Montag, 2. Januar 2023

Ein Apple SuperDrive unter Linux zum Laufen bringen

Die Feiertage sind für mich auch immer der Zeitpunkt, um mal wieder so richtig aufzuräumen. Dieses Jahr — ein Jahr nach dem Umzug — war der Keller dran. Unter anderem ging es Bundesordnern mit Unterlagen seit Mitte 1990er bis 2011 an den Kragen.

Mit meinem Fujitsu ScanSnap iX 1500 wurden alle Blätter gescannt, danach lief mit ABBYY FineReader PDF for Mac die OCR-Texterkennung darüber, und schlussendlich habe ich die PDFs auf dem lokalen Laufwerk abgelegt.

Ein Ordner enthielt auch CDs und DVDs für Web-Projekte der späten 1990er und frühen 2000er. Zum Glück hatte ich mir — in weiser Voraussicht — vor einiger Zeit ein Apple SuperDrive (A1379) gekauft, welches mit USB an beliebige Computer angeschlossen werden kann.

Bevor ich also die CDs und DVDs entsorgte, wollte ich die Daten damit ebenfalls auf den lokalen Computer sichern.

Erkenntnis: Von ungefähr einem Dutzend CDs und DVDs waren alle (!) noch lesbar. Bei zwei Datenträgern motzte macOS aber, dass diese ein „nicht unterstützes Format“ aufweisen (Nachtrag: Vermutlich weil unter Mac OS 9 gebrannt).

Ich entschied mich, noch nicht aufzugeben, und das Laufwerk an einen Linux-Laptop anzuschliessen. Das war aber gar nicht so einfach: Das Laufwerk machte zwar kurz ein Geräusch, nachdem es an USB angeschlossen wurde, doch die CD wurde nicht eingezogen.

Am USB-Bus wurde das Gerät angezeigt:

# lsusb
...
Bus 002 Device 011: ID 05ac:1500 Apple, Inc. SuperDrive [A1379]
...

Nach etwas Recherche dann die Lösung:

  • (einmalig) # apt-get install sg3-utils
  • (jedes Mal, nachdem das Laufwerk an USB angeschlossen wurde) # sg_raw /dev/sr1 EA 00 00 00 00 00 01 (WICHTIG: Wie ich erst später bemerkte, hätte das Lenovo ThinkPad eigentlich bereits einen DVD-Leser eingebaut gehabt. Dieses Gerät befindet sich unter /dev/sr0, weshalb das Apple-Laufwerk /dev/sr1 erhält)
  • Jetzt sollte man die CD/DVD einschieben können, und das Laufwerk zieht sie ein
  • Mittels # blkid kann man sich die Datenträgerinformationen anzeigen lassen; bei mir bspw. /dev/sr1: BLOCK_SIZE="2048" UUID="2001-02-02-16-03-16-00" LABEL="anzeiger wangen" TYPE="iso9660" PTTYPE="mac"
  • (einmalig) # mkdir /mnt/mac
  • # mount -t iso9660 /dev/sr1 /mnt/mac (falls das nicht klappt, kann man mit dem Parameter -t noch andere Dateisysteme testen, bspw. udf, hfs oder hfsplus Quelle)
  • Nun sollten sich die Ordnerstruktur und die Dateien unter /mnt/mac auflisten lassen
  • Backup, bspw. mit rsync
  • # umount /mnt/mac um das Filesystem zu unmounten
  • # eject /dev/sr1 um die CD auszuwerfen (das Laufwerk verfügt über keinen physischen Auswurfs-Knopf) (Quelle im Kommentar von Korhan Tınaztepe) (Fun fact: # eject /dev/sr0 öffnet die Schublade des ThinkPad-eigenen DVD-Laufwerks)

Quelle: Apple’s SuperDrive tweak for use with Linux, Use Apple’s USB SuperDrive with Linux,

Tags: , , , , , , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 27. November 2022

UniFi kommt auf einem Debian 11 Bullseye nicht hoch

Da am Freitag die SSD in einem meiner Lenovo-Laptops das Zeitliche gesegnet hat, musste ich das System komplett frisch aufsetzen.

Ich verwende diesen Laptop als Site-to-Site OpenVPN-Endpunkt. Mit der Zeit habe ich dort auch andere Software draufgeknallt, zum Beispiel den UniFi Controller zum Management der Netzwerk-Komponenten in der Aussenstation.

Bei der Installation des UniFi Controllers das erste Problem: Debian 11 Bullseye bietet kein MongoDB-Paket (mehr) an:

# apt-get install unifi
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 unifi : Depends: mongodb-server (>= 2.4.10) but it is not installable or
                  mongodb-10gen (>= 2.4.14) but it is not installable or
                  mongodb-org-server (>= 2.6.0) but it is not installable
         Depends: mongodb-server (< 1:4.0.0) but it is not installable or
                  mongodb-10gen (< 4.0.0) but it is not installable or
                  mongodb-org-server (< 4.0.0) but it is not installable
E: Unable to correct problems, you have held broken packages.

Auf einem Referenzsystem war folgende MongoDB installiert:

# dpkg --list | grep -i mongo
ii  mongo-tools                          3.4.14-4                       amd64        collection of tools for administering MongoDB servers
ii  mongodb-clients                      1:3.2.11-2+deb9u2              amd64        object/document-oriented database (client apps)
ii  mongodb-server                       1:3.2.11-2+deb9u2              amd64        object/document-oriented database (server package)

Mittels packages.debian.org fand ich dann rasch heraus, dass diese Pakete in Debian 9 Stretch enthalten waren. Damit ich diese installieren konnte, musste ich /etc/apt/sources.list anpassen:

...
deb         https://debian.ethz.ch/debian/ stretch main non-free
deb-src     https://debian.ethz.ch/debian/ stretch main non-free
...

Damit klappte die Installation von MongoDB und des UniFi Controllers.

Leider kam UniFi nach der Installation aber nicht hoch. Wenn ich die auf dem funktionierenden System gespeicherte URL ansurfte, erschien eine HTTP Status 404 – Not Found Fehlermeldung im Java-Layout:

Nach etwas Recherche und dem Vergleich mit einem baugleichen System an einer anderen Aussenstelle dann die Erkenntnis: Der UniFi Controller läuft ausschliesslich mit Java 8 (Running Unifi Controller on Java 9, 10 and 11). Auf dem neuen Debian hatte ich aber Java 17 (?) installiert gehabt.

Obwohl How can I install Java 8 on Debian 11 (Bullseye)? Hinweise gibt, wie man Java 8 zum Laufen kriegt, wählte ich den einfachsten Weg — über ein offizielles Debian-Paket: Ich hatte nämlich Glück: Den Zugang zu einem offiziellen Java 8-Paket hatte ich mir über die obigen Anpassungen von apt.sources bereits etabliert. Das Paket installierte ich folgendermassen:

# apt-get update
# apt-get install openjdk-8-jre-headless

Da ich noch eine Java 17-Installation auf dem System existieren hatte, war diese als Standardversion eingestellt:

# java --version
openjdk 17.0.4 2022-07-19
OpenJDK Runtime Environment (build 17.0.4+8-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.4+8-Debian-1deb11u1, mixed mode, sharing)

Da ich Java 17 nicht brauchte, entfernte ich das Paket kurzerhand:

# apt-get remove openjdk-17-jre-headless

Wer aber auch auf dieses Paket angewiesen ist, kann folgendermassen Java 8 als Standard auswählen:

# update-java-alternatives --list
java-1.17.0-openjdk-amd64      1711       /usr/lib/jvm/java-1.17.0-openjdk-amd64
java-1.8.0-openjdk-amd64       1081       /usr/lib/jvm/java-1.8.0-openjdk-amd64
# update-alternatives --config java

Anschliessend kam der UniFi Controller hoch. Nun nur noch ein Backup einspielen, und der Controller funktionierte wieder wie vor dem Festplattendefekt.

Tags: , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Samstag, 12. März 2022

Was, wenn man noch eine Weile auf der alten UniFi Controller-Version bleiben möchte?

Kürzlich:

Get:1 http://security.debian.org bullseye-security InRelease [44.1 kB]
Get:2 http://debian.ethz.ch/debian bullseye-backports InRelease [44.2 kB]                      
Hit:3 http://phoscon.de/apt/deconz buster InRelease                                            
Hit:4 https://debian.ethz.ch/debian bullseye InRelease                                         
Hit:5 https://deb.nodesource.com/node_16.x bullseye InRelease                                  
Get:6 https://debian.ethz.ch/debian bullseye-updates InRelease [39.4 kB]                  
Get:7 http://packages.cloud.google.com/apt cloud-sdk-bullseye InRelease [6,772 B]              
Hit:8 https://debian.ethz.ch/debian buster InRelease                                           
Get:10 http://debian.ethz.ch/debian bullseye-backports/main Sources.diff/Index [63.3 kB]
Get:11 http://debian.ethz.ch/debian bullseye-backports/main amd64 Packages.diff/Index [63.3 kB]
Get:12 http://debian.ethz.ch/debian bullseye-backports/main Sources T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [715 B]
Get:12 http://debian.ethz.ch/debian bullseye-backports/main Sources T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [715 B]
Get:13 http://debian.ethz.ch/debian bullseye-backports/main amd64 Packages T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [17.3 kB]
Get:13 http://debian.ethz.ch/debian bullseye-backports/main amd64 Packages T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [17.3 kB]
Get:9 https://dl.ubnt.com/unifi/debian stable InRelease [3,038 B]                             
Reading package lists... Done  
E: Repository 'https://dl.ubnt.com/unifi/debian stable InRelease' changed its 'Codename' value from 'unifi-6.5' to 'unifi-7.0'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

Die relevante Zeile:

E: Repository 'https://dl.ubnt.com/unifi/debian stable InRelease' changed its 'Codename' value from 'unifi-6.5' to 'unifi-7.0'

Es war aber spätabends und ich war auf keine Experimente mit meinem WLAN aus.

Wie macht man, dass diese Meldung weggeht, und die restlichen, nicht-UniFi Pakete trotzdem aktualisiert werden? Ganz einfach: In /etc/apt/sources.list ersetzt man in der Unifi-Zeile „stable“ mit „oldstable“:

...
deb         http://www.ubnt.com/downloads/unifi/debian oldstable ubiquiti
...

Tags: , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 23. Februar 2022

dhcpd: Unable to add forward map from X to 1.2.3.4: SERVFAIL

Ich habe meine lokalen DHCP-Server so konfiguriert, dass Geräte mit ihrem lokalen DNS-Namen auch in named (BIND9) registriert werden.

Gelegentlich treffe ich folgendes Problem an:

Feb 23 01:15:15 SERVER dhcpd[2746174]: Unable to add forward map from apple-tv.domain.tld. to 10.1.2.3: SERVFAIL

Wie ich mittlerweile nach unzähligen verbratenen Stunden herausgefunden habe hängt dies mit diesem beschissenen AppArmor zusammen. Obwohl ich es jeweils deinstalliere, taucht es nach Updates wieder im System auf.

Die Lösung:

# apt-get remove apparmor
# systemctl stop apparmor
# systemctl disable apparmor

Quelle: How to disable and remove AppArmor in Ubuntu and Debian

Je nach Tageslaune ist dann auch noch ein Reboot nötig.

Mittlerweile habe ich eine monit-Regel eingerichtet, die mich alarmiert, wenn ein solcher Log-Event in /var/log/dhcp.log auftaucht.

(Auf meiner Todo-Liste steht, die Installation mittels apt zu verbieten)

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. September 2021

Wie man unter Debian „E: Broken packages“ am einfachsten löst

Release-Upgrades von Debian GNU/Linux-Kisten sind immer so eine Sache. Bei der Migration von Stretch auf Bullseye stand ich vor folgendem Problem:

# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  apt apt-utils cpp gcc libmariadb-dev
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
# apt upgrade apt
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 apt : Depends: libapt-pkg6.0 (>= 2.2.4) but it is not going to be installed
       Depends: libstdc++6 (>= 9) but 8.3.0-6 is to be installed
 apt-utils : Depends: apt (= 1.8.2.3) but 2.2.4 is to be installed
E: Broken packages

Wie ich endlich, nach all den Jahren herausgefunden habe, löst man solche Probleme am einfachsten mit dem Downgrade eines oder mehrerer Pakete. Dies, indem man apt-get install %paketname%=%versionsnummer% ausführt.

Welches Paket man im obigen Fall downgraden muss? Gar nicht so einfach. Irgendeinmal hatte ich es dann doch herausgefunden:

# apt-get install gcc-10-base=10.2.1-6

Danach flutschte apt-get upgrade durch.

Nachtrag 1

Gerade wieder ein solches Problem:

# apt-get dist-upgrade
...
The following packages have been kept back:
  locales
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

Manueller Versuch:

# apt-get upgrade locales
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libc-bin : Depends: libc6 (> 2.32) but 2.31-13+deb11u2 is to be installed
E: Broken packages

Von welcher Version sprechen wir?

# dpkg --list | grep -i locales
...
ii  locales                        2.31-17                        all          GNU C Library: National Language (locale) data [support]
...

Welche Version ist stable für meine aktuelle Distribution?

# cat /etc/debian_version 
11.1

Debian 11 ist Bullseye, also gehen wir rüber zu packages.debian.org und sehen, dass die aktuelle stabile Version Package: locales (2.31-13+deb11u2) ist. Somit:

# apt-get install locales=2.31-13+deb11u2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be DOWNGRADED:
  locales
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 1 not upgraded.
Need to get 4,082 kB of archives.
After this operation, 2,048 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://debian.ethz.ch/debian bullseye/main amd64 locales all 2.31-13+deb11u2 [4,082 kB]
Fetched 4,082 kB in 0s (11.1 MB/s)
Preconfiguring packages ...
dpkg: warning: downgrading locales from 2.31-17 to 2.31-13+deb11u2
(Reading database ... 139926 files and directories currently installed.)
Preparing to unpack .../locales_2.31-13+deb11u2_all.deb ...
Unpacking locales (2.31-13+deb11u2) over (2.31-17) ...
Setting up locales (2.31-13+deb11u2) ...
Generating locales (this might take a while)...
  en_US.UTF-8... done
Generation complete.
Processing triggers for man-db (2.9.4-2) ...

Und Feierabend.

Nachtrag 2

Kürzlich ist das Problem wieder einmal aufgetreten:

# apt-get upgrade libfido2-1
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libfido2-1 : Depends: libc6 (>= 2.33) but 2.31-13+deb11u2 is to be installed
E: Broken packages
# dpkg --list | grep libfido2-1
ii  libfido2-1:amd64               1.9.0-1                        amd64        library for generating and verifying FIDO 2.0 objects

Nun, da schauen wir mal, welche Version dieses Pakets aktuell ist: packages.debian.org meldet für Debian Bullseye (11) Version 1.6.0-2 als aktuell. Somit downgrade initiieren:

# apt-get install libfido2-1=1.6.0-2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  libcbor0.8
Use 'apt autoremove' to remove it.
The following additional packages will be installed:
  libcbor0
The following NEW packages will be installed:
  libcbor0
The following packages will be DOWNGRADED:
  libfido2-1
0 upgraded, 1 newly installed, 1 downgraded, 0 to remove and 1 not upgraded.
Need to get 77.3 kB of archives.
After this operation, 37.9 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://debian.ethz.ch/debian bullseye/main amd64 libcbor0 amd64 0.5.0+dfsg-2 [24.0 kB]
Get:2 https://debian.ethz.ch/debian bullseye/main amd64 libfido2-1 amd64 1.6.0-2 [53.3 kB]
Fetched 77.3 kB in 0s (436 kB/s)      
Selecting previously unselected package libcbor0:amd64.
(Reading database ... 145105 files and directories currently installed.)
Preparing to unpack .../libcbor0_0.5.0+dfsg-2_amd64.deb ...
Unpacking libcbor0:amd64 (0.5.0+dfsg-2) ...
dpkg: warning: downgrading libfido2-1:amd64 from 1.9.0-1 to 1.6.0-2
Preparing to unpack .../libfido2-1_1.6.0-2_amd64.deb ...
Unpacking libfido2-1:amd64 (1.6.0-2) over (1.9.0-1) ...
Setting up libcbor0:amd64 (0.5.0+dfsg-2) ...
Setting up libfido2-1:amd64 (1.6.0-2) ...
Processing triggers for libc-bin (2.31-17) ...
[ Rootkit Hunter version 1.4.6 ]
File updated: searched for 180 files, found 147

libc-bin war auf demselben System auch störrisch:

# apt-get upgrade libc-bin
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libc-bin : Depends: libc6 (> 2.33) but 2.31-13+deb11u2 is to be installed
E: Broken packages
# dpkg --list | grep libc-bin
ii  libc-bin                       2.31-17                        amd64        GNU C Library: Binaries

packages.debian.org meldet als aktuelle Version 2.31-13+deb11u2, somit auch hier ein Downgrade:

# apt-get upgrade libc-bin=2.31-13+deb11u2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be DOWNGRADED:
  libc-bin
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Need to get 817 kB of archives.
After this operation, 1,024 B disk space will be freed.
Do you want to continue? [Y/n] y
Get:1 https://debian.ethz.ch/debian bullseye/main amd64 libc-bin amd64 2.31-13+deb11u2 [817 kB]
Fetched 817 kB in 0s (3,055 kB/s)
dpkg: warning: downgrading libc-bin from 2.31-17 to 2.31-13+deb11u2
(Reading database ... 145105 files and directories currently installed.)
Preparing to unpack .../libc-bin_2.31-13+deb11u2_amd64.deb ...
Unpacking libc-bin (2.31-13+deb11u2) over (2.31-17) ...
Setting up libc-bin (2.31-13+deb11u2) ...
Processing triggers for man-db (2.9.4-2) ...
[ Rootkit Hunter version 1.4.6 ]
File updated: searched for 180 files, found 147

Tags: , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Sonntag, 19. September 2021

Von Stretch nach Bullseye mit gravierenden Problemen

Gestern lüpfte ich einen zweiten OpenVPN-Server von Debian Stretch auf Bullseye.

Das erfolgte leider nicht kurz- und schmerzlos. Ich kämpfte mit und debuggte während 16 Stunden (abzüglich 7 Stunden Schlaf) an folgenden Problemen:

Konsolen-, SSH- und Telnet-Logins dauern 1min30sec

D.h. nach Eingabe des Passwortes scheint das System zu hängen. Wer sich in Geduld übt, landet nach eineinhalb Minuten in der gewohnten Shell.

Bei mir bildeten sich in diesen ersten 90 Sekunden bereits viele Schweissperlen, denn wie flickt man ein Debian GNU/Linux, wenn man sich nicht mehr einloggen kann? Mittels grub in den Single User/Recovery Mode zu booten wäre ein noch grösserer Alptraum geworden …

Meldungen in syslog:

...
Sep 18 22:40:43 OPENVPN2 systemd[1]: Starting User Manager for UID 1000...
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Main process exited, code=exited, status=1/FAILURE
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Killing process 89451 (gpgconf) with signal SIGKILL.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Killing process 89452 (awk) with signal SIGKILL.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Killing process 89457 (dirmngr) with signal SIGKILL.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Killing process 89452 (awk) with signal SIGKILL.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Killing process 89457 (dirmngr) with signal SIGKILL.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Failed with result 'exit-code'.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Unit process 89452 (awk) remains running after unit stopped.
Sep 18 22:42:13 OPENVPN2 systemd[1]: user@1000.service: Unit process 89457 (dirmngr) remains running after unit stopped.
Sep 18 22:42:13 OPENVPN17 systemd[1]: Failed to start User Manager for UID 1000.
...

Die Lösung:

# apt-get remove gpgconf
...
The following packages will be REMOVED:
  dirmngr duplicity gnupg gnupg-agent gnupg2 gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm libgmime-2.6-0 libgpgme11
  libnotmuch4 mutt python3-gpg samba-dsdb-modules scdaemon

Die vielen zu deinstallierenden Pakete liessen mich kurz zweifeln, aber das System lief nach deren Deinstallation problemlos weiter.

Quelle: WireGuard Bounce Server Setup

Wobei, wenn ich die Kommentare so lese: Eventuell war gpgconf gar nicht das Problem, sondern der Nameserver, der nicht reagierte (siehe unten).

Netzwerkprobleme

Probleme mit named und localhost

BIND 9 ist zwar an localhost (127.0.0.1) gebunden und lauscht auf dem Interface …

# lsof -i :53
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
named   653 bind   23u  IPv4  15673      0t0  UDP localhost:domain 
named   653 bind   24u  IPv4  15679      0t0  UDP localhost:domain 
named   653 bind   25u  IPv4  15680      0t0  TCP localhost:domain (LISTEN)
named   653 bind   27u  IPv4  15681      0t0  TCP localhost:domain (LISTEN)
named   653 bind   29u  IPv4  15682      0t0  UDP 10.1.2.3:domain 
named   653 bind   30u  IPv4  15683      0t0  UDP 10.1.2.3:domain 
named   653 bind   31u  IPv4  15684      0t0  TCP 10.1.2.3:domain (LISTEN)
named   653 bind   32u  IPv4  15685      0t0  TCP 10.1.2.3:domain (LISTEN)

… aber die Namensauflösung funktioniert nicht. Wenn man mit telnet 127.0.0.1 53 eine Session aufbauen will, hängt die Verbindung.

Mittels strace analysierte ich dann was im Hintergrund genau vor sich ging, und verglich die Ausgabe mit einem strace auf einem Server, bei dem die Namensauflösung funktionierte:

Defekter Server:

# strace ping -c 1 emeidi.com
...
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 5
setsockopt(5, SOL_IP, IP_RECVERR, [1], 4) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
clock_gettime(CLOCK_REALTIME, {tv_sec=1631995746, tv_nsec=794103764}) = 0
poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "{\311\1\0\0\1\0\0\0\0\0\0\6emeidi\3com\0\0\1\0\1", 28, MSG_NOSIGNAL, NULL, 0) = 28
poll([{fd=5, events=POLLIN}], 1, 1000)  = 0 (Timeout)
clock_gettime(CLOCK_REALTIME, {tv_sec=1631995747, tv_nsec=795739261}) = 0
poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "{\311\1\0\0\1\0\0\0\0\0\0\6emeidi\3com\0\0\1\0\1", 28, MSG_NOSIGNAL, NULL, 0) = 28
poll([{fd=5, events=POLLIN}], 1, 1000)  = 0 (Timeout)
close(5)                                = 0
...

Funktionierender Server:

# strace ping -c 1 emeidi.com
...
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 5
setsockopt(5, SOL_IP, IP_RECVERR, [1], 4) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "UK\1\0\0\1\0\0\0\0\0\0\6emeidi\3com\0\0\1\0\1", 28, MSG_NOSIGNAL, NULL, 0) = 28
poll([{fd=5, events=POLLIN}], 1, 1000)  = 1 ([{fd=5, revents=POLLIN}])
ioctl(5, FIONREAD, [463])               = 0
recvfrom(5, "UK\201\200\0\1\0\1\0\r\0\r\6emeidi\3com\0\0\1\0\1\300\f\0\1"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, [28->16]) = 463
poll([{fd=5, events=POLLOUT}], 1, 999)  = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "W}\1\0\0\1\0\0\0\0\0\0\6emeidi\3com\0\0\34\0\1", 28, MSG_NOSIGNAL, NULL, 0) = 28
poll([{fd=5, events=POLLIN}], 1, 998)   = 1 ([{fd=5, revents=POLLIN}])
ioctl(5, FIONREAD, [278])               = 0
recvfrom(5, "W}\201\200\0\1\0\0\0\0\0\r\6emeidi\3com\0\0\34\0\1\1a\fr"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, [28->16]) = 278
close(5)                                = 0
...

Macht man dasselbe mit der internen IP des Servers (bspw. 10.1.2.3) kann eine Session aufgebaut werden. Die Namensauflösung konnte ich nicht durchführen, weil mir der oder die Befehle nicht geläufig waren — im Nachhinein aber las ich dann, dass es sich bei DNS-Abfragen nicht um Klartextkommandos handelt.

Nun gut, dies bewog mich zu einem Workaround, ohne das eigentliche Problem zu beseitigen. Ich passte kurzerhand meine /etc/resolv.conf an:

#nameserver 127.0.0.1
nameserver 10.1.2.3

options timeout:1
options single-request

Ich vermutete zuerst Probleme in systemd-resolved. Installieren resp. entfernen tut man das Paket mit:

# apt-get install libnss-resolve
# apt-get remove libnss-resolve

Ist das Paket installiert, hat man neben /etc/resolv.conf auch noch Konfigurationen in /etc/systemd/resolved.conf und /run/systemd/resolve/resolve.conf. Typischer systemd-Wahnsinn. (siehe dazu Ubuntu – 18.04 Unable to connect to server due to “Temporary failure in name resolution” sowie Ubuntu 18.04 DNS resolution fails after a while)

Als ich systemd-resolved mit meinen Pröbelein zerschossen hatte, tauchten in /var/log/syslog noch folgende Fehlermeldungen auf:

Sep 18 20:35:04 localhost dbus-daemon[329]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.15' (uid=0 pid=2015 comm="resolvectl ")
Sep 18 20:35:04 localhost dbus-daemon[329]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.

Siehe auch Activation via systemd failed for unit ‚dbus-org.freedesktop.resolve1.service‘: Unit dbus-org.freedesktop.resolve1.service not found

Site-to-site OpenVPN erlaubt Pings in nur eine Richtung

Die Sache wurde immer mysteriöser: Aus dem entfernten Subnetz, in welchem der hier Probleme verursachende Server steht, konnte ich problemlos zur anderen Site pingen. Sowohl den VPN-Endpunkt, als auch alle anderen IPs im Subnetz hier. Das funktionierte auch von anderen Geräten im entfernten Subnetz aus.

Doch im Umkehrschluss funktionierte das nicht; d.h. von meinem Heimnetzwerk konnte ich nur den OpenVPN-Endpunkt pingen, aber nichts im entfernten Subnetz. Die ICMP-Pakete kamen zwar beim Zielgerät an (bspw. dem Internet-Router), dieser antwortete, aber das Antwortpaket wurde dann von auf dem entfernten OpenVPN-Endpunkt nicht von eth0 auf tun0 weitergeleitet.

Immerhin lernte ich für das Debugging nützliche tcpdump-Befehle kennen:

# tcpdump -n icmp and host 10.1.2.1
# tcpdump -i tun0 -n icmp and host 10.1.2.1
# tcpdump -i eth0 -n icmp and host 10.1.2.1

Die Ausgabe ist auch deshalb hilfreich, weil derselbe ping-Prozess immer dieselbe id trägt. Und die Sequenznummern sieht man auch gleich angezeigt. So konnte man isolieren, wo genau die ICMP-Pakete „verloren“ gingen respektive noch durchkamen.

Ausserdem kann man iptables so konfigurieren, dass sie verarbeitete Pakete ins syslog loggen (eine Regel iptables -I FORWARD -i eth0 -o tun0 -j ACCEPT existiert dabei schon und ist aktiv):

# iptables -I FORWARD -i eth0 -o tun0 -j LOG --log-prefix "OUTGOING "
# iptables -I FORWARD -i tun0 -o eth0 -j LOG --log-prefix "INCOMING "

Das Logging wird deaktiviert, indem man die Regel wieder entfernt:

# iptables -D FORWARD -i eth0 -o tun0 -j LOG --log-prefix "OUTGOING "
# iptables -D FORWARD -i tun17 -o eth0 -j LOG --log-prefix "INCOMING "

In dmesg entdeckte ich dann auch noch folgende Fehlermeldungen, was mich bewog, den Kernel zu aktualisieren:

...
cgroup2: unknown option "nsdelegate,memory_recursiveprot"
...

Die finale Lösung: Aktualisiere von Kernel-Version 4.9.0-16 auf 5.10.46-4, und Neustart.

# apt-get install linux-image-amd64

Tags: , , , , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 1. April 2021

Das nervende „You have mail.“ beim SSH-Login loswerden

Gestern habe ich auf allen meinen Linux-Systemen /etc/motd geleert, um bei SSH-Logins kein grosses Login-Banner mehr angezeigt zu bekommen.

Jetzt aber ist mir auf verschiedenen Systemen die folgende Zeile markanter ins Auge gestochen:

Linux GRIFFINDOR 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1 (2020-01-20) x86_64
You have mail.
Last login: Thu Apr  1 15:13:36 2021 from 10.1.2.3

Wie wird man diesen Hinweis los? Ganz einfach:

  1. $ mail
  2. d1-%Anzahl Emails in INBOX%
  3. q

Quelle: Safely get rid of “You have new mail in /var/mail” on a Mac?

Der Befehl d1-100 weist mail an, die ersten hundert Emails zu löschen. q bedeutet „quit“.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen