Samstag, 17. Juni 2023
Das geht, aber erfordert DSM 7 sowie die Installation eines offiziellen, kostenlosen Pakets namens … exFAT Access:
Can I use exFAT external storage devices with my Synology NAS?
Eine unter macOS als exFAT formatierte USB-Festplatte wurde nach der Installation des Pakets umgehend erkannt und unter usbshare1 gemountet.
Samstag, 7. August 2021
Zum zweiten Mal innert neuen Monaten hat mein Synology NAS folgendes Problem:
(rsync, nächtlich auf meinem iMac laufend, welches iPhotos auf das NAS sichert)
... rsync: recv_generator: failed to stat "/var/services/homes/mario/Backup/imac-photos/resources/proxies/derivatives/3d/01/13dc2/UNADJUSTEDNONRAW_thumb_13dc2.jpg": Input/output error (5) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1307) [sender=3.2.2]
Die Lösung: Dateisystem flicken! Das geht folgendermassen:
Die Dateisystemreparatur startet nun (destruktiv!). Wer zuerst gefahrlos wissen möchte, was wirklich los ist, kann anstelle des letzten Befehls auch folgenden Befehl verwenden: e2fsck -v -n -f /dev/vg1000/lv
Im Dezember 2020 funktionierte das auf einen Rutsch, im August 2021 musste ich das NAS einmal neu starten, weil sonst folgende Fehlermeldung angezeigt wurde:
# e2fsck -v -f -y /dev/vg1000/lv /dev/vg1000/lv is in use. e2fsck: Cannot continue, aborting.
Die Informationen hier wurden aus folgenden Quellen zusammengeschustert (chronologisch, die besseren Quellen befinden sich somit am Ende der Liste):
Tags: ext2, ext4, fsck, Synology, vg, Volume Group
Labels: IT
Samstag, 25. November 2017
Mit dem Synology DiskStation Manager DSM 6.0 kam es zu Sicherheitsanpassungen beim SSH-Login: Selbst wenn ein Administrator auf einem Synology NAS SSH aktiviert, können sich normale Benutzer per SSH nicht auf dem NAS einloggen. Dies ist nur mit Benutzern möglich, die der Administrator-Gruppe zugeteilt sind.
Um diese Anpassung im Namen der Sicherheit rückgängig zu machen, bin ich dem Blog-Artikel Howto: (re-)Enable SCP/SSH Login on Synology DSM 6.0 for non admin users [UPDATE] gefolgt. Der Grund ist trivial: Synology setzt für normale Benutzer in /etc/passwd ein unbrauchbares Login-Shell: /sbin/nologin
Die Lösung: Ein auf dem NAS hinterlegtes bash-Script wird mittels Cron-Job unter root laufend alle fünf Minuten ausgeführt und ersetzt die Login-Shell ausgewählter Benutzer mit /bin/sh.
#!/bin/bash
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^dagobert\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^donald\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^daisy\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^huey\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^dewey\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^louie\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
exit 0
Tags: /sbin/nologin, Admin, Benutzer, SSH, Synology
Labels: Uncategorized
Sonntag, 23. Juli 2017
Auf meinem iPhone habe ich Google Authenticator installiert, welcher mir Einmalpasswörter für eine Ladung von Geräten in meinem Heimnetzwerk (Synology NAS, Anleitung hier) sowie Web-Services (Gmail, Rainloop Webmail, WordPress etc.) liefert. Im Fachjargon nennt man das Time-based One-time Password Algorithm TOTP.
Da ich zu Hause manchmal das Smartphone in einem anderen Raum liegenlasse und ich mir in solchen Fällen den Fussweg zum Telefon sparen möchte, habe ich mich nach einer Desktop-Variante von Google Authenticator umgesehen. In einem Artikel werden einige Varianten erläutert, doch bei den meisten handelt es sich um Google Chrome-Extensions. Solche möchte ich nicht verwenden, da ich verhindern möchte, dass Google meine geheimen Schlüssel erfährt und sie zwischen allen Chrome-Instanzen hin- und hersynchronisiert.
Leider funktioniert JAuth 2 unter macOS Sierra nicht (verlangt nach dem nicht installierten Java 6, RLY?), weshalb ich mich nach anderen Lösungen umsehen musste.
Plötzlich die zündende Idee — moment mal, ich habe ja 1Password auf meinem iPhone, iPad sowie meinem MacBook wie auch meinem Mac mini installiert. Kann die Software nicht auch mit TOTP umgehen?
Und tatsächlich: 1Password bringt alles an Bordmitteln mit, um QR-Codes einzulesen und dann in Echtzeit im jeweiligen Zugangsdaten-Eintrag die sechsstelligen Zahlen anzuzeigen. Halt einfach ein wenig versteckt. Doch weiss man einmal, wo suchen, geht es Ruckzuck und der QR-Code ist in der App im jeweiligen Eintrag der Credentials gespeichert.
Natürlich bedeutet das aber auch, dass wer meine 1Password-Datenbank stehlen kann, neben Benutzernamen und Passwort auch gleich den zweiten Faktor zum Login in sensitivere Konten besitzt.
Zum Glück laufen meine spezialisierten TOTP-Apps für die wirklich kritischen (und wertvollen) Anwendungen (sprich: Online-Banking) in eigenen, schön abgeschottenen Containern auf dem iPhone: Credit Suisse SecureSign und Raiffeisen PhotoTAN. Bei Postfinance verwende ich übrigens Swisscoms Mobile ID; d.h. der zweite Faktor ist hier in Hardware ausgelagert, was Vor- und Nachteile hat.
Mittwoch, 31. August 2016
Obwohl ich vorher gar keine Tests gefahren bin, habe ich folgende Konfigurationseinstellung gleich nach der Installation von El Capitan aktiviert:
[default] signing_required = no
Quelle: OS X 10.11 El Capitan: Langsame SMB-Verbindungen!
Motto: Nützt’s nüt, schadt’s nüt.
Tags: El Capitan, nsmb, OS X, Samba, smb, Synology
Labels: Apple
Dienstag, 30. August 2016
Synology verfügt Out-of-the-Box über einen SNMP-Server, welchen man mittels weniger Klicks aktivieren kann. Diesen SNMP-Daemon verwende ich im Heimnetzwerk mit dem Tool cacti, um Vitaldaten meines NAS aufzuzeichnen.
Damit man auch die Informationen über die Festplattenbelegung des NAS aufzeichnen kann, muss man in cacti in der Device-Ansicht des vorgängig eingerichteten Synology-NAS im Abschnitt Associated Data Queries das Data Query mit dem Namen „SNMP – Get Mounted Partitions“ hinzufügen, welches den SNMP-Baum hrStorageTable (.1.3.6.1.2.1.25.2.3) abfrägt.
Im Gegensatz zum Data Query „ucd/net – Get Monitored Partitions“ (SNMP-Baum dskTable (.1.3.6.1.4.1.2021.9)) findet die SNMP-Version entsprechende Werte.
Dies, weil Synology die HOST-RESOURCES-MIB verwendet, um Informationen über Partitionen und Festplattenbelegung zu teilen:
Via: Monitoring disk stats with Cacti
Tags: cacti, HOST-RESOURCES-MIB, SNMP, Synology
Labels: IT
Sonntag, 15. Mai 2016
Gestern musste ich feststellen, dass meine Synology Diskstation seit ein paar Wochen eine extrem hohe CPU-Auslastung und Linux Load Average aufwies. Cacti ist für eine Analyse sehr nützlich, da die Werte historisiert und in Graphen ausgegeben werden können:
Wieso sich diese Änderung urplötzlich ergeben hat, konnte ich bis jetzt nicht eruieren.
Über SSH und mit Hilfe von top stellte ich rasch fest, dass der Prozess /usr/bin/nmbd -D permanent alle verfügbare CPU-Kapazität auffrass. Was zum Teufel?
Ein Blick in /var/log/samba/log.nmbd, welches mehrere MBs umfasst, zeigte die Ursache des Übels: Die Log-Datei war voller Einträge in der folgenden Form, und mehrmals pro Sekunde kamen neue identische Einträge dazu:
... ../source3/nmbd/nmbd_incomingrequests.c:213: [2016/05/15 01:00:37.670697, all 0, pid=18689] process_name_registration_request process_name_registration_request: unicast name registration request received for name XEROX PHASER 32<20> from IP 10.1.2.3 on subnet UNICAST_SUBNET. Error - should be sent to WINS server ...
Die NetBIOS-Komponente in unserem Xerox Phaser 3250DN muss von wahrlichen Profis programmiert worden sein …
Sobald ich den Drucker ausschaltete, beruhigte sich die Diskstation sofort und die CPU-Auslastung wie auch die Load Average sanken auf den langfristig tiefen Wert.
Das Problem löste ich mit folgenden Kniffen:
Auf einem Intel NUC, der mir hier als Linux-Server dient (Beispiel-IP: 10.1.2.4), installierte ich Samba und konfigurierte es folgendermassen, damit Samba sich neu als WINS-Server im Netzwerk anpreist:
... [global] netbios name = SERVERNAME server string = Samba %v on (%L) workgroup = WORKGROUP wins support = yes dns proxy = no local master = yes os level = 34 preferred master = yes ...
Quelle: Chapter 7. Name Resolution and Browsing sowie Using Samba: 4.4 Server Configuration
... option netbios-name-servers 10.1.2.4; ...
Anschliessend musste der DHCP-Server noch frisch gestartet werden:
# systemctl stop isc-dhcp-server # systemctl start isc-dhcp-server
Die Desktop-Clients erhielten den neuen WINS-Server mittels eines „Renew DHCP Lease“ frisch über; beim Drucker führte ich einen Kaltstart durch, um auf Nummer sicher zu gehen.
Tags: cacti, CPU, DHCP, Diskstation, Load Average, nmbd, Samba, Synology
Labels: Linux
Mittwoch, 18. September 2013
Als Gedankenstütze nachfolgend einige Lösungen für Probleme, die sich mir in den Weg stellten:
$ ssh-keygen -t rsa -b 2048 -f id_rsa_dashboard_vault
Die Aufforderung, ein Passwort für den Private Key zu generieren, bestätigt man mit ENTER — der Private Key wird so nicht zusätzlich mit einem Passwort geschützt, weil dies den automatisierten Login von Raspberry Pi auf die DiskStation verhindern würde.
Der Befehl erstellt zwei Dateien:
Als erstes richtet man sich über die Web-Oberfläche einen normalen Benutzer dashboard ein, in dessen Home-Verzeichnis die Backup-Daten geschrieben werden.
Hierzu müssen dem Benutzer Schreibrechte auf /homes gegeben werden. Ansonsten sieht man sich beim Starten des Backup-Scripts (s. unten) mit folgender Fehlermeldung gegenüber:
ERROR: module is read only
Quelle: Rsync over ssh: “ERROR: module is read only” suddenly appeared
Wichtig ist weiter, dass der SSH-Zugang über die Web-Oberfläche aktiviert wurde.
Dem neu erstellten Benutzer müssen wir nun eine gültige Login-Shell zuweisen:
... dashboard:x:1029:100::/var/services/homes/dashboard:/bin/ash
Erfasst man hier ein nicht existierendes Login-Shell, kriegt man beim Debugging des publickey SSH-Logins folgende komische Infos ans Gesicht geworfen:
... Authentication succeeded ... Permission denied ...
Um sicher zu gehen, dass die Login-Shell richtig konfiguriert ist, macht man als auf der DiskStation eingeloggter User root folgendes:
# su dashboard
Wechselt man in ein neues Shell, ist /etc/passwd korrekt konfiguriert.
In dieser Datei legen wir den Public Key ab (id_rsa_dashboard_vault.pub).
Wahrscheinlich müsste man hier gar nichts anpassen, beim Debugging habe ich es dann doch getan (wohl unnötigerweise):
$ cat sshd_config | grep -v "^#" | sort
AllowTcpForwarding no
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
ChrootDirectory none
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_rsa_key
LogLevel INFO
Match User root
AllowTcpForwarding yes
Protocol 2
PubkeyAuthentication yes
Subsystem sftp internal-sftp -f DAEMON -u 000
SyslogFacility AUTH
UseDNS no
UsePAM yes
Host vault Hostname 10.0.44.44 User dashboard IdentityFile ~/.ssh/id_rsa_dashboard_vault
In der Datei ~/.ssh/id_rsa_dashboard_vault legt man den Private Key ab.
Dies sollte nun ohne Eingabe eines Passwortes möglich sein:
$ ssh vault
Bei einer Fehlermeldung helfen die Optionen -v, -vv und -vvv weiter:
$ ssh -v vault
Folgendes Script sichert / (root) des Raspberry Pis auf den Host vault in den Pfad /volume1/homes/dashboard/backups/. Auf dem Raspberry Pi nicht mehr vorhandene Dateien werden auf der DiskStation gelöscht.
#!/bin/sh RSYNC=`which rsync` if [ ! -e "$RSYNC" ] then echo "rsync binary not found: '$RSYNC'" exit 1 fi TODAY=`date +"%F_%T"` SNAPSHOTFILE="/var/log/rsync/$TODAY.snapshot.txt" #touch "$SNAPSHOTFILE" echo "$TODAY" > "$SNAPSHOTFILE" if [ ! -f "$SNAPSHOTFILE" ] then echo "Could not create snapshotfile '$SNAPSHOTFILE'" else echo "Snapshotfile created at:" ls -l "$SNAPSHOTFILE" fi LOGFILE="/var/log/rsync/$TODAY.log.txt" EXCLUDEFILE="/usr/local/bin/backup-exclude.txt" SOURCE="/" DEST="vault:/volume1/homes/dashboard/backups/" echo "Running rsync ..." $RSYNC -avz --log-file="$LOGFILE" --exclude-from="$EXCLUDEFILE" --delete -e ssh "$SOURCE" "$DEST" echo "Backup complete." exit 0
proc/* sys/* dev/* tmp/* run/* mnt/*
Quelle: Can a Raspberry Pi be used to create a backup of itself?
... 4 0 * * * root /usr/local/bin/backup.sh
Hiermit wird das Backup-Script täglich um 4 Uhr morgens ausgeführt.
Tags: Linux, Raspberry Pi, rsync, SSH, Synology
Labels: Linux
Mario Aeby, geboren am 25. September 1980 in Bern, Schweiz
Ein Weblog über IT (Linux, OSS, Apple), Heim-Automation; mein mittlerweile abgeschlossenes Geschichtsstudium; Erkenntnisse aus meiner aktuellen Tätigkeit in der Informationssicherheit, meine Erfahrungen als IT-Berater, IT-Auditor, Web-Developer und IT-Supporter; die Schweiz, den Kanton Bern, meine ursprüngliche und auch wieder aktuelle Wohngemeinde Neuenegg, meine vorherige Wohngemeinde Bern, über lokale, regionale und globale Politik; meine Reisetätigkeit und Erfahrungen mit anderen Kulturen; und zu Guter letzt auch das Älter werden.
Alle in diesem Blog gemachten Aussagen und Meinungen sind persönlich und nicht als Ansichten meines aktuellen und/oder meiner bisherigen Arbeitgeber zu verstehen.
 |