Thursday, June 4, 2020

Cronjob deaktivieren

Mitunter installieren Debianpakete Cronjobs in /etc/cron.*, um wiederkehrende Aufgaben auszuführen. Damit solch ein Cronjob ausgeführt wird, muss das Executable-Bit gesetzt sein. Entfernt man dieses, wird der Cronjob nicht mehr ausgeführt.

Mit dpkg-statoverride(1) kann man sich über Eigentümerschaft und Modus von Dateien hinwegsetzen und damit das Executable-Bit eines Cronjob entfernen:

dpkg-statoverride --add root root 644 /etc/cron.daily/tripwire
chmod 644 /etc/cron.daily/tripwire

Der Vorteil von dpkg-statoverride(1) ist, dass die Hinwegsetzungen auch Paket-Aktualisierungen und -Neuinstallationen überdauern. Was sonst, bei durch die Paketverwaltung verwalteten Dateien, nicht der Fall ist.

Mit dpkg-statoverride --remove <path/to/file> kann man auf diese Weise selbst gesetzte Eigentümerschaft und Modus wieder entfernen und dpkg-statoverride --list listet alle Hinwegsetzungen auf.

PS: Ich habe dies für /etc/cron.daily/tripwire getan, da ich zwar Tripwire installiert habe, damit aber nicht das lokale System überwachen will. Sondern Tripwire nur nutze, um lokal ein anderes entferntes System zu überwachen (diesen Server/Webspace hier) und mich die lokalen Tripwire Reports stören. Wofür der Cronjob da ist.
Zur Überwachung des entfernten Systems kopiere ich mittels SSH und Rsync die Dateien und lasse dann Tripwire drüber laufen, wie im Linux Security Cookbook von O’Reilly gezeigt. Was auch gleichzeitig noch ein Backup sein kann…
Alternativ könnte man wohl auch die lokale Tripwire Policy entsprechend erweitern. Aber das will ich nicht, da mein Workflow etwas anders ist.

Friday, August 9, 2019

NAS mit Samba: Verzeichnis im Netzwerk freigeben

Ein Verzeichnis mit dem Windows AD und SMB/CIFS Dateiserver für UNIX über das Netzwerk freigeben und Benutzern sowie Gästen Lese- und Schreibzugriff gewähren.

Dieses Setup für ein NAS mit Samba erlaubt neben Benutzern, auch Gästen Lese- und Schreibzugriff. So kann jeder auf das Netzlaufwerk zugreifen! Durch das Stiky-Bit ist jedoch sichergestellt, das niemand die Dateien eines anderen löschen oder überschreiben kann.

Verzeichnis anlegen und Samba konfigurieren

Das Verzeichnis für das NAS legt man am besten unterhalb von /srv an. Dieses Verzeichnis enthält betriebsspezifische Daten, die vom System bereitgestellt werden und folgt dem FHS.

# neues Verzeichnis erstellen
mkdir -p /srv/nas
# Benutzer, Dateirechte und StickyBit setzen
chown root:staff /srv/nas
chmod a+rwXt /srv/nas

Im Verzeichnis /srv/nas können nun alle Benutzer unter ihrer UID Dateien erstellen, ändern und löschen. Die Dateien anderer Benutzer können nur geöffnet, nicht aber geändert oder gelöscht werden. Will man dies erlauben, muss man mit Benutzergruppen (GID) arbeiten.

Um das Verzeichnis freizugeben, muss die Konfiguration smb.conf(5) um folgende Sektion erweitert werden:

cat <<! >>/etc/samba/smb.conf
[NAS]
	comment=NAS
	path=/srv/nas
	public = yes
	writeable = yes
	guest ok = yes
	guest account = nobody
	create mask = 0665
	directory mask = 0775
!

Mit testparm(1) kann die Konfigurationsdatei auf Syntaktische Korrektheit überprüft werden.

testparm

Benutzern den Zugriff erlauben

Damit Benutzer unter ihrer ID Dateien im NAS und auch im Benutzerverzeichnis ablegen können, muss für jeden ein Passwort in der Benutzerdatenbank von Samba einrichten sein. Ohne Passwort können Benutzer weder lesend noch schreibend auf ihr Benutzerverzeichnis zugreifen. Es besteht allerdings auch die Möglichkeit, Benutzer ohne Passwort zu aktiveren. Linux und Samba verwenden unterschiedliche Passwörter.

Zum Erstellen des Passworts in der Samba-Benutzerdatenbank smbpasswd(5) kann entweder pdbedit(8) oder smbpasswd(8) verwendet werden.

Hinweis: Will man $HOME nicht freigeben, empfiehlt es sich die Sektion [homes] in der smb.conf(5) auszukommentieren.

Passwort anlegen

Das Passwort für einen Benutzer wird mit smbpasswd -a <username> angelegt.

Wird smbpasswd(8) ohne Parameter aufgerufen, kann das Passwort des aktuellen Benutzers geändert werden.

Das anlegen des Passwords kann für neue Benutzerkonten auch während der Einrichtung passieren. Dazu legt man die Datei /usr/local/sbin/adduser.local an. Wenn die Datei existiert, wird sie nach der Einrichtung des Benutzerkontos ausgeführt, um lokale Einstellungen vorzunehmen.

cat <<! >/usr/local/sbin/adduser.local
#!/bin/sh
# An adduser.local werden die folgenden Argumente übergeben:
# Benutzername, UID, GID und Home-Verzeichnis.

user="$1"
uid="$2"
gid="$3"
home="$4"

# add new users to the local smbpasswd(5) file
smbpasswd -a "$user"

# Make sure that the script will "exit 0"
true
!
chmod -x /usr/local/sbin/adduser.local

Passwort entfernen

Um ein Benutzerkonto beim entfernen auch aus der Samba-Benutzerdatenbank auszutragen, kann die /usr/local/sbin/deluser.local analog zu adduser.local angelegt werden.

cat <<! >/usr/local/sbin/deluser.local 
#!/bin/sh
# An deluser.local werden die folgenden Argumente übergeben:
# Benutzername, UID, GID und Home-Verzeichnis.

user="$1"
uid="$2"
gid="$3"
home="$4"

# delete user from the local smbpasswd(5) file
smbpasswd -x "$user"

# Make sure that the script will "exit 0"
true
!
chmod -x /usr/local/sbin/deluser.local

Zur Verwaltung der Samba-Benutzerdatenbank bietet sich pdbedit(8) an. Damit kann u.a. abgefragt werden, für welche Benutzer in der Samba-Benutzerdatenbank ein Passwort vergeben wurde.

pdbedit -L

Netzlaufwerke einbinden

Unter Linux (GNOME), Microsoft Windows usw. sollte das NAS als Netzwerkfreigabe gefunden werden.

Für einen Datentransfer über Samba, wird eine Pfadangabe bzw. URI der folgenden Form benutzt:

smb://{hostname|ip}/NAS

Mailingliste abonnieren

Um Ankündigungen, wie z.B. Benachrichtigungen über neue Versionen und Bugs zu erfahren, sollte man zusätzlich die Samba Mailingliste abonnieren. Die Adresse ist unter https://lists.samba.org zu finden und es sollte mindestens samba-announce abonniert werden.

NAS mit SFTP

Ist SSH bzw. das Paket openssh-sftp-server installiert, kann auch via SSH auf das Benutzerverzeichnis zugegriffen werden. Und viele Dateimanager unterstützen das SSH-Protokoll SFTP.

Für einen Datentransfer über SSH an einem entfernten Rechner, benutzt man eine URI der Form:

sftp://[username@]{hostname|IP}[:port]/path/to/share

Alternativ können statt des Authority-Teil, auch die Aliasnamen aus ssh_config(5) verwendet werden.

Sunday, July 23, 2017

Debian 9 (Stretch): Predictable Network Interface Names – Umstellung auf das neue Verfahren zur Namensvergabe von Netzwerkschnittstellen

Spätestens ab Debian 10 (Buster) wird das alte Verfahren zur Namensvergabe von Netzwerkschnittstellen nicht mehr unterstützt, und das System muss auf das neue Verfahren umgestellt sein (Predictable Network Interface Names).

Bei einer Neuinstallation von Debian 9 (Stretch) passiert diese Umstellung automatisch. Bei einem Upgrade von Debian 8 (Jessie) muss hingegen manuell umgestellt werden.

Auf das neue Verfahren zur Namensvergabe von Netzwerkschnittstellen umstellen

Um auf das Verfahren Predictable Network Interface Names umzustellen, muss die Datei /etc/udev/rules.d/70-persistent-net.rules gelöscht werden:

mv /etc/udev/rules.d/70-persistent-net.rules{,.old}

Danach muss das System neu gestartet werden.

Dieser Schritt stellt eine entsprechend weitreichende Änderung am System da. Eventuelle Konfigurationsdateien müssen angepasst und getestet werden. Wer statt des NetworkManager(8) die Datei interfaces(5) und ifupdown nutzt, muss zumindest diese anpassen.

Siehe auch: https://www.debian.o … #new-interface-names, https://github.com/s … -builtin-net_id.c#L3 (Beschreibt nach welchen Regeln, die neuen voraussagbaren/vorhersagbaren Namen aufgebaut sind), https://www.freedesk … tworkInterfaceNames/, file:///usr/share/do … dev/README.Debian.gz

Benutzerdefinierte Namen für Netzwerkschnittstellen

In manchen Fällen ist es praktisch, eigene Namen für Netzwerkschnittstellen zu definieren.

Dies kann mittels zwei verschiedener Methoden erreicht werden. Einmal mittels Network Device Configuration: systemd.link(5) und einmal mittels Dynamic Device Management: udev(7), welche wesentlich mehr Möglichkeiten bietet.

In folgenden Beispielen, wird der Netzwerkschnittstelle mit der MAC-Adresse 00:a0:de:63:7a:e6, der feste Namen dmz zugewiesen:

  • Dynamic Device Management – udev(7):
    Beispielsweise kann /etc/udev/rules.d/76-netnames.rules erstellt und dort Netzwerkgeräte anhand beliebiger Attribute und Eigenschaften identifiziert und benannt werden.
    Hier ein Beispiel, um ein Gerät über die MAC-Adresse zu identifizieren und zu benennen:

    cat /etc/udev/rules.d/76-netnames.rules
    # identify device by MAC address
    SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:a0:de:63:7a:e6", NAME="dmz"
    

    Gegenüber systemd.link(5), bietet diese Methode auch die Möglichkeit Geräte anhand anderer Übereinstimmungsschlüssel, wie der Vendor/Model-ID oder des Gerätepfads zu Identifizieren. Siehe dazu auch die Handbuchseite udev(7), für die Dokumentation, wie man udev-Regeln schreibt.

  • Network Device Configuration – systemd.link(5):
    Alternativ geht auch eine Konfiguration ohne udev(7), mittels systemd.link(5) und des Name-Schlüssels:

    cat /etc/systemd/network/10-dmz.link
    [Match]
    MACAddress=00:a0:de:63:7a:e6
    [Link]
    Name=dmz
    

Damit diese Änderungen übernommen werden, ist ggf. eine Aktualisierung der initrd-Datei und ein Neustart des Systems erforderlich:

update-initramfs -u && reboot

Sunday, May 8, 2016

CyanogenMod auf dem Samsung Galaxy S4 mini GT-I9195 (serranoltexx) installieren

Habe CyanogenMod (CM) auf meinem Samsung Galaxy S4 mini GT-I9195 (serranoltexx) installiert. Das funktionierte problemlos.

Hier ein Gedächtnisprotokoll dazu. Die offizielle Dokumentation, Schritt-für-Schritt Anleitung usw. zu serranoltexx findet man hier: https://wiki.cyanoge … /w/Serranoltexx_Info.

Anstelle von ClockworkMod (CWM) und anderen, bietet CyanogenMod inzwischen ein eigenes Custom ROM an – die CyanogenMod Recovery (CMR).

Für Samsung Galaxy S Geräte muss allerdings weiterhin, statt des fastboot Befehl aus der Android Debug Bridge (ADB), die Heimdall Suite verwendet werden, um das ROM auf das Gerät zu flashen. Doch Heimdall kann mittlerweile aus den Debian-Paketquellen installiert werden: https://packages.deb … n.org/heimdall-flash.

Wer die Google Apps (OpenGApps) installieren möchte, findet diese hier: http://opengapps.org/. Es wird der Download für die Platform ARM benötigt. Das Google Apps .zip muss im selben Schritt wie das ClockworkMod .zip installiert werden. Ein nachträgliches installieren der Google Apps funktionierte hier nicht.
Wer die Google Apps nicht möchte, installiert später unter Android einfach das FDroid.apk von hier: https://f-droid.org/. Und hat damit einen alternativen App Store zur Verfügung stehen.

Wurde mit Heimdall das CyanogenMod Recovery ROM auf das Gerät geflasht, ist es wichtig das Gerät nicht neu zu starten. Sondern: Ausschalten und direkt den CyanogenMod Recovery-Mode starten. Da bei einem Neustart das Custom ROM wieder auf das Samsung original ROM zurückgesetzt wird, solange das CM-Build noch nicht installiert ist.

Ist das Gerät im CyanogenMod Recovery-Modus. Wählt man Facroty reset und danach dann Apply update, um zuerst das CyanogenMod .zip und danach das OpenGApps .zip zu installieren.
Mit Reboot system now neu starten… fertig.

Ergänzende Hinweise:

  • Unter Android in den Geräteinformationen nachlesen, welches Modell man hat
  • Mit vollem Akku und Netzstrom beginnen
  • Root-Rechte braucht es auf dem Gerät nicht, dafür besteht kein Grund (rooting)
  • Für adb muss unter Android, in den Entwickleroptionen der USB-Debugging-Modus aktiviert sein. Die .zip-Dateien können aber auch manuell via Dateimanager, ohne adb auf das Gerät kopiert werden

Friday, October 30, 2015

Autorestart: Eine systemd user-unit anlegen/erstellen/erzeugen

Programme wie Mail-Client und IM startet man i.d.R. über den Autostart der Desktopumgebung, damit diese bei der Anmeldung automatisch im Hintergrund starten und über neue Nachrichten informieren.

Ein Manko der Desktop Application Autostart Specification ist, dass diese Anwendungen nicht neu-starten, wenn sie versehentlich beendet wurden.

Eine Lösung bieten hier Systemd User-Units als ein Autorestart.

Eine Systemd User-Unit für den Mail-Client Thunderbird anlegen/erstellen/erzeugen

Alle Systemd User-Units werden unter $XDG_CONFIG_HOME/systemd/user/ bzw. $HOME/.config/systemd/user/ gespeichert. Abhängig davon, ob die Umgebungsvariable $XDG_CONFIG_HOME gesetzt ist.

Hier ein Beispiel für den Mail-Client Thunderbird:

mkdir -p ~/.config/systemd/user/
cat <<! >~/.config/systemd/user/thunderbird.service 
[Unit]
Description=Thunderbird

[Service]
Environment=DISPLAY=:0
ExecStart=/usr/bin/thunderbird
Restart=always

[Install]
WantedBy=basic.target
!

Damit eine Unit nach der Anmeldung ausgeführt wird, muss diese mittels systemctl(1) aktiviert werden:

systemctl --user enable thunderbird.service

Die Systemd User-Unit ersetzt dann den Autostart und systemd(1) überwacht den Prozess (PID) und startet diesen ggf. neu.

Wer die Leserechte des Benutzerverzeichnis eingeschränkt, oder eine restriktive Rechtemaske (umask) von bspw. 0077 gesetzt hat, kann den Start der Unit auch in den Autostart, oder in die Datei ~/.gnomerc eintragen:

systemctl --user start thunderbird.service

Dies startet die Unit manuell.