Schlagwort-Archive: Linux

BitBastelei #349 – VPN mit Wireguard

BitBastelei #349 - VPN mit Wireguard

(186 MB) 00:37:55

2019-09-08 10:00 🛈

In perfekten Netzen könnte jeder mit jedem kommunizieren, in der Praxis sieht es oft anders aus. Mittels VPN kann man ein “virtuelles Netzwerkkabel” zwischen zwei PCs oder Routern aufbauen. Eine solche VPN-Software ist Wireguard, welches für alle gängigen Betriebssysteme verfügbar und vergleichsweise einfach einzurichten ist.

Inhalt

  • 00:10 Was ist ein VPN
  • 05:42 Klassische VPN-Lösungen
  • 08:26 Wireguard
  • 10:04 Installation & Konfiguration unter Debian Linux (CLI)
  • 18:00 Installation & Konfiguration unter Arch Linux (CLI)
  • 24:45 Zugriff auf’s Internet: Forwarding & NAT
  • 27:51 Installation & Konfiguration unter Arch Linux (NetworkManager)
  • 29:59 Installation & Konfiguration unter Windows
  • 32:30 Installation & Konfiguration unter Android

Links

BitNotice #145 – Inkscape-Standardeinstellungen ändern

BitNotice #145 - Inkscape-Standardeinstellungen ändern

(9 MB) 00:01:48

2019-03-27 17:30 🛈

Inkscape präsentiert bei jedem Öffnen erst mal ein DIN A4-Blatt – nicht gerade hilfreich, wenn man eher mit anderen Formaten wie z.B. dem bei Videos verbreiteten 16:9 arbeitet. Einen offensichtlichen Weg um die Vorgaben zu ändern scheint es nicht zu geben, mit etwas Wissen zur korrekten Schraube lässt sich das Ziel dennoch erreichen.

  • *nix: ~/.config/­inkscape/
  • Windows: %userprofile%\­Application Data\­Inkscape\

BitBastelei #277 – PXE: PCs ohne HDD über Netzwerk starten (Arch, ISOs, etc)

BitBastelei #277 - PXE: PCs ohne HDD über Netzwerk starten (Arch, ISOs, etc)

(311 MB) 00:41:34

2018-03-25 10:00 🛈
Wenn man einen PC startet lädt dieser das Betriebssystem von der internen Festplatte oder SSD – oder bei Installationen von einer CD bzw. einem USB-Stick. Fast alle modernen PCs beherrschen aber noch eine Methode: PXE. Hiermit lassen sich Rechner ganz ohne lokale Medien von einem zentralen Server starten. Dies kann z.B . eine NAS oder ein OpenWRT-Router sein. Mit passenden Menüs hat man so alle gängigen Rettungssysteme und Installationsmedien immer zur Hand und muss nicht die passenden Sticks suchen.

Weiterführende Links:

BitBasics – ESP8266 – 1b: Arduino Installation und Einrichtung unter Linux

BitBasics - ESP8266 - 1b: Arduino Installation und Einrichtung unter Linux

(34 MB) 00:09:03

2018-02-25 11:30 🛈
Um mit dem ESP8266 zu starten benötigen wir eine Programmierumgebung. In meiner Serie werde ich auf Arduino aufbauen, eine der verbreitetsten Systeme für den ESP und viele andere Mikrocontroller. In diesem Video zeige ich die Installation der Arduino-Umgebung und der nötigen Zusätze für den ESP8266 unter Ubuntu Linux. Weiterhin gebe ich einige Tipps, wie die Einrichtung auch unter anderen Linux-Distributionen funktionieren sollte.

Links:

Linux: Optisches Laufwerk RAW über Netzwerk einbinden

(Hinweis: Der Artikel lag schon etwas rum – möglicherweise sind die verwendeten Tools nicht mehr aktuell)

Hmmm – ungünstig. Das einzige optische Laufwerk steckt in einem Linux-Server, ich möchte die Discs jedoch auf einem anderen Gerät verwenden. Üblicherweise reicht hier ein File-Share wie Samba, NFS o.Ä. aus, wenn man jedoch beispielsweise kopiergeschützte DVDs abspielen möchte ist eine solche Freigabe nicht ausreichend. Glücklicherweise können wir hier einen alten Bekannten bemühen: iSCSI. Dies hatten wie bereits für Festplatten besprochen, kann aber auch für optische Laufwerke genutzt werden.

Server / Target

Nach dem Aufruf von targetcli sollten wir die altbekannte Textkonsole erhalten, welche auf der Root (/) der Konfiguration startet. Im ersten Schritt registrieren wir das physikalische Laufwerk /dev/sr0 als Backstore und aktivieren es für iSCSI. Sofern nicht bereits vorhanden wird automatisch eine TPG erzeugt.

/> cd backstores/pscsi
/backstores/pscsi> create name=cdrom_backend dev=/dev/sr0
Note: block backstore recommended for SCSI block devices
Created pscsi storage object cdrom_backend using /dev/sr0
/backstores/pscsi> cd cdrom_backend
/backstores/p...cdrom_backend> /iscsi create
Created target iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.

Nun müssen wir noch eine LUN erstellen um Clients den Zugriff zum Gerät zu ermöglichen. Diese Konfiguration findet im Kontext der TPG statt, die nötige ID wurde ja weiter oben angezeigt. Da nur ein Backstore verfügbar ist wird dieser automatisch ausgewählt. Da es sich um ein Testnetz handelt verzichte ich auf eine Absicherung und alle alle Clients zu – bei CD-Laufwerken ein überschaubares Risiko.

/backstores/p...cdrom_backend> cd /iscsi/iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b/tpg1/
/iscsi/iqn.20...e8a7999b/tpg1> cd luns
/iscsi/iqn.20...99b/tpg1/luns> create /backstores/pscsi/cdrom_backend
Created LUN 0.
/iscsi/iqn.20...99b/tpg1/luns> cd ..
/iscsi/iqn.20...e8a7999b/tpg1> set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 cache_dynamic_acls=1
Parameter cache_dynamic_acls is now '1'.
Parameter authentication is now '0'.
Parameter generate_node_acls is now '1'.
Parameter demo_mode_write_protect is now '0'.
/iscsi/iqn.20...e8a7999b/tpg1>

Zuletzt wird die Konfiguration gespeichert, so ist sie z.B. auch nach einem Neustart noch vorhanden

/iscsi/iqn.20...e8a7999b/tpg1> cd /
/> saveconfig
Last 10 configs saved in /etc/target/backup.
Configuration saved to /etc/target/saveconfig.json
/> exit
Global pref auto_save_on_exit=true
Last 10 configs saved in /etc/target/backup.
Configuration saved to /etc/target/saveconfig.json

Client / Initiator

Auf der Clientseite benötigen wir ebenfalls eine Userspace-Software. Ich nutze zur Konfiguration iscsiadm aus dem Paket open-iscsi. Hier wird erst über Discover geprüft welche LUNs auf der TPG/Ziel-IP verfügbar sind. Über Login werden diese dann verbunden.

# iscsiadm --mode discoverydb --type sendtargets --portal 10.11.12.13 --discover
10.11.12.13:3260,1 iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b
# iscsiadm --mode node --login
Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b, portal: 10.11.12.13,3260] (multiple)
Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.3299e9a7999b, portal: 10.11.12.13,3260] successful.

Das Ergebnis ist ein zusätzliches Blockdevice, welches wie ein Lokales angesteuert werden kann.

# dmesg | tail
[269195.457603] Loading iSCSI transport class v2.0-870.
[269196.464444] iscsi: registered transport (tcp)
[269243.373172] scsi host5: iSCSI Initiator over TCP/IP
[269243.636444] scsi 5:0:0:0: CD-ROM TSSTcorp DVD+-RW TS-H653B D300 PQ: 0 ANSI: 5
[269243.668795] sr 5:0:0:0: [sr1] scsi-1 drive
[269243.669219] sr 5:0:0:0: Attached scsi CD-ROM sr1

 

BTRFS: Dateisystem mit mehreren Festplatten vergrößern

Das ist jetzt doof – Platte voll. Und das auf einem Multi-Device/RAID BTRFS-System. Die unterliegenden LUNs zu vergrößern ist kein wirkliches Problem, aber btrfs zeigte sich etwas widerspenstig: Die meisten Anleitungen empfehlen folgendes:
btrfs filesystem resize max /mnt/data

Leider scheint es bei multi-device keine reaktion zu geben. Der Trick: Dieser Befehl lässt nur die erste Festplatte wachsen. Hat man mehrere muss man den Befehl für jede LUN separat ausführen, die Plattennummer wird dabei als ID mitgegeben:
btrfs filesystem resize 2:max /mnt/data

Die IDs aller beteiligten Platten kann man mit

btrfs filesystem show /mnt/data
anzeigen. Wurden alle Platten vergrößert kann man natürlich auch eine bash-Schleife bemühen um den Befehl für alle abzusetzen.
for i in {1..8} ;do btrfs filesystem resize $i:max /mnt/data/ ;done

Linux: Gerät wacht nach Suspend sofort wieder auf

Narf. Akku leer. Nur warum?
Tja, mein Laptop hatte sich entschieden nach meinem Klick auf “Suspend” sofort wieder aus dem Standby-Modus aufzuwachen. Reproduzierbar. Erste Vermutung: Die GUI ist Schuld. Wie immer. Aber auch ein systemctl suspend zeigt nicht wirklich eine Besserung. Auch die Logs zeigen nichts verwertbares. Na dann graben wir etwas tiefer:

Erst mal zur Klarstellung: Standby funktioniert – der Laptop schaltet die Geräte aus, die Power-LED blinkt wie erwartet, doch nach knapp einer Sekunde wacht wer direkt wieder auf. Entsprechend des Fehlers dürfte also die Aufwachquelle am ehesten Verantwortlich sein. Eine Liste aller Quellen findet sich in /proc/acpi/wakeup:

# cat /proc/acpi/wakeup
LID	  S4	*enabled  platform:PNP0C0D:00
SLPB	  S3	*enabled   platform:PNP0C0E:00
IGBE	  S4	*enabled   pci:0000:00:19.0
EXP2	  S4	*disabled  pci:0000:00:1c.1
XHCI	  S3	*enabled   pci:0000:00:14.0
EHC1	  S3	*enabled   pci:0000:00:1d.0

Die Liste sieht natürlich je nach Verbauter Hardware anders aus, hier die Zuordnung meines Gerätes:

LID -> Laptop-Deckel
SLPB/SBTN -> Standby-Button
IGBE -> Integrated Gigabit Ethernet
EXP2 -> ??
XHCI -> USB3
EHC1 -> USB(1/2)

Wie wir sehen können diverse Geräte ein Aufwachen verursachen, lediglich EXP2 ist nicht aktiv. Um das Ganze einzugrenzen heißt es also nun: Aufwachquelle abschalten, Suspend testen und hoffen, dass es was bringt. Über ein gezieltes echo kann der Zustand zwischen enabled und disabled gewechselt werden:

echo LID > /proc/acpi/wakeup

In meinem Fall stellte sich USB als Fehlerteufel heraus. Offenbar störte sich das System an einem USB-Stick – egal ob gemountet oder nicht. Wie auch immer, USB brauche ich ohnehin nicht zum aufwachen, Deckel und/oder Power-Button sollten ausreichen. Den “bösen” USB schalte ich beim Boot per Script nun ab.

[Gentoo] Apache 2.4.26 + WordPress: Invalid post type

Hmk? After the latest system updates on Gentoo I noticed WordPress was no longer able to open any kind of post list (“invalid post type”), edit posts (you do not have access to this kind of post) or create posts (form shown, but right sidebar missing). Not quite uncommon, but this time it was no broken plugin – I could reproduce the same behavior with several other WordPress instances with different versions – even a fresh install. That’s a new one.

After some probing around I’m fairly certain Apache 2.4.26 is the culprit, after downgrading to 2.4.25 the problem disappeared. All other downgrades like PHP 7.0.15 instead of PHP 7.0.19 didn’t show any effect. I yet have to confirm which combination ultimately triggers the error (FPM? Event-MPM?), but if you have similar errors: Here is your starting point…

BitNotice #108 – Rspamd: Server-SPAM-Filter mit Postfix

BitNotice #108 - Rspamd: Server-SPAM-Filter mit Postfix

(36 MB) 00:23:26

2017-04-30 10:30 🛈
Aktuell teste ich für einige meiner Server neue Setups, unter anderem zur SPAM-Abwehr. Einen recht soliden Eindruck macht hierbei Rspamd, ein in C geschriebener SPAM-Filter mit LUA-Modulen. Neben einer großen Liste an Header- und Contentfiltern für die Punktevergabe beherrscht er auch die üblichen Dinge wie SPF, DKIM, DCC und RBLs. Ergänzt durch einen selbstlernenden Bayes-Filter soll so der “Unrat” abgehalten werden. Ergänzt wird das Ganze durch ein Webinterfact, welches Statistiken bietet und Parametereinstellungen zulässt.

Zusammen mit Postfix und RMilter lässt sich so ein Setup erstellen, welches die Prüfung bereits während des Empfangs durchführt. So lässt sich die Mail unverzüglich ablehnen und man belästigt keine Dritten mit ungewolltem Backscatter.

Hier mal kurz und etwas Planlos die Installation des Rspamd mit Zubehör sowie die Integration in Postfix.

Edit: Je nach Setup muss der Postfix-User der Gruppe rmilter hinzugefügt werden

ZFS/ZOL: Pool UNAVAIL nach Reboot

Nicht schön. Nach dem Reboot eines Server musste ich feststellen, dass diverse Storages nicht mehr zugreifbar waren. Schnell stellte sich heraus, dass alle ZFS-Pools offline waren und die Geräte mit der Meldung “too many errors” als FAULTED markiert wurden.

 zpool import
   pool: tempstore
     id: xyz
  state: UNAVAIL
 status: One or more devices are faulted.
 action: The pool cannot be imported due to damaged devices or data.
 config:

        tempstore   UNAVAIL  insufficient replicas
          sdd       FAULTED  too many errors
          sde       FAULTED  too many errors

   pool: storage
     id: xyy
  state: UNAVAIL
 status: One or more devices are faulted.
 action: The pool cannot be imported due to damaged devices or data.
 config:

        storage     UNAVAIL  insufficient replicas
          sdb       FAULTED  too many errors

Nunja, Consumer-Platten traue ich ja viele defekte zu, aber drei unabhängige Platten gleichzeitig? Eher nein. Auch S.M.A.R.T. zeigte keine wirklich bedenkenswerten Werte. Aufschlussreicher ist da schon das Kernel-Log:

[  776.890127] Large kmem_alloc(131128, 0x1000), please file an issue at:
               https://github.com/zfsonlinux/zfs/issues/new
[  776.890129] CPU: 1 PID: 12969 Comm: vdev_open Tainted: P           O    4.4.39-gentoo-adlerweb #2
[  776.890130] Hardware name: LENOVO yxz/        , BIOS xyz 01/10/2012
[  776.890132]  0000000000000000 ffff880417a37bc0 ffffffff813545d8 000000000240c200
[  776.890134]  0000000000000000 ffff880417a37c00 ffffffffa0018af1 0000000017a37be0
[  776.890138]  0000000000000000 ffff88041626d480 ffff8804174ed660 0000000000004000
[  776.890139] Call Trace:
[  776.890144]  [<ffffffff813545d8>] dump_stack+0x4d/0x65
[  776.890148]  [<ffffffffa0018af1>] spl_kmem_zalloc+0x131/0x180 [spl]
[  776.890163]  [<ffffffffa0109aa8>] vdev_cache_stat_fini+0x258/0xcc0 [zfs]
[  776.890175]  [<ffffffffa010a3ba>] vdev_cache_stat_fini+0xb6a/0xcc0 [zfs]
[  776.890188]  [<ffffffffa014426a>] zio_data_buf_free+0x51a/0xdc0 [zfs]
[  776.890200]  [<ffffffffa014798f>] zio_nowait+0xaf/0x190 [zfs]
[  776.890215]  [<ffffffffa0104cce>] vdev_probe+0xfe/0x200 [zfs]
[  776.890228]  [<ffffffffa01059e0>] ? vdev_accessible+0x70/0x2b0 [zfs]
[  776.890240]  [<ffffffffa0107969>] vdev_open+0x3c9/0x4b0 [zfs]
[  776.890251]  [<ffffffffa0107bdd>] vdev_open_children+0x18d/0x1c0 [zfs]
[  776.890254]  [<ffffffffa001b8ec>] taskq_dispatch+0x3ac/0x5b0 [spl]
[  776.890257]  [<ffffffff810c1ed0>] ? wake_up_q+0x70/0x70
[  776.890261]  [<ffffffffa001b6e0>] ? taskq_dispatch+0x1a0/0x5b0 [spl]
[  776.890263]  [<ffffffff810b8c04>] kthread+0xc4/0xe0
[  776.890265]  [<ffffffff810b8b40>] ? kthread_park+0x50/0x50
[  776.890268]  [<ffffffff81a6a5df>] ret_from_fork+0x3f/0x70
[  776.890270]  [<ffffffff810b8b40>] ? kthread_park+0x50/0x50

*kick* Da war ja was. ZOL läuft wegen der Lizenzproblematik als Kernel-Modul. Ich hatte zuletzt am Kernel einige Treiber nachgezogen. Hierbei sind zwar Version und Ablageort gleich geblieben, offenbar ist aber die ABI etwas gewandert, sodass SPL/ZFS etwas verwirrt den Dienst quittierten.

Für Gentoo heißt das einmal Module neu Bauen, in meinem Fall

emerge -va spl zfs-kmod

 

Alternativ und in den meisten Fällen zuverlässiger ist es nach jeder Kernel-Änderung alle Module automatisch neu zu erstellen:

emerge -va @module-rebuild

Storage online, Admins glücklich, Update-Doku ergänzt. Passt.