Normale Ansicht

Received before yesterday

Upgrade auf Nextcloud 31

18. April 2025 um 04:00

Heute möchte ich kurz erzählen, welche Schwierigkeiten ich beim Upgrade auf Nextcloud 31 Hub 10 zu bewältigen hatte.

Das Upgrade auf Nextcloud 31 war in meinem Fall mal wieder von einigen Hürden umstellt. Meine ersten Versuche, die Nextcloud auf Version 31.0.0 Stable zu heben, waren zwar von Erfolg gekrönt, jedoch sperrte ich damit meinen WebAuthn-Zugang zu meinen Daten. Weitere Versuche bei den Neuerscheinungen 31.0.1 und 31.0.2 liefen ebenfalls ins Leere.

Nun, mit Version 31.0.3, wurde das WebAuthn-Problem jedoch gefixt. Nach der Reparatur der Datenbank und dem Einspielen fehlender Indizes blieb noch eine zu beseitigende Fehlermeldung übrig. Es handelt sich um ein falsches Zeilenformat in der Datenbank.

Falsches Zeilenformat in deiner Datenbank gefunden. ROW_FORMAT=Dynamic bietet die beste Datenbankleistung für Nextcloud. Bitte aktualisiere das Zeilenformat in der folgenden Liste: oc_authtoken, oc_notifications_settings, oc_circles_event, oc_bookmarks_root_folders, oc_vcategory_to_object, oc_vcategory, oc_richdocuments_assets, oc_calendar_rooms, oc_calendar_invitations, oc_webauthn, oc_deck_cards, oc_circles_mountpoint, oc_users, oc_collres_accesscache, oc_talk_internalsignaling, oc_mail_attachments, oc_talk_attendees, oc_external_options, oc_oauth2_access_tokens, oc_twofactor_totp_secrets, oc_deck_assigned_users, oc_mail_trusted_senders, oc_external_config, oc_storages, oc_group_folders_manage, oc_mail_aliases, oc_activity_mq, oc_jobs, oc_bookmarks_folders, oc_deck_board_acl, oc_whats_new, oc_deck_attachment, oc_group_user, oc_twofactor_u2f_registrations, oc_share_external, oc_calendarobjects, oc_accounts_data, oc_mail_accounts, oc_calendarchanges, oc_text_sessions, oc_notifications_pushhash, oc_appconfig, oc_bookmarks_folders_public, oc_user_status, oc_mail_provisionings, oc_circles_mount, oc_bookmarks_tree, oc_richdocuments_direct, oc_calendarsubscriptions, oc_accounts, oc_external_mounts, oc_login_flow_v2, oc_mail_message_tags, oc_calendar_resources_md, oc_comments_read_markers, oc_deck_assigned_labels, oc_mail_tags, oc_mounts, oc_text_documents, oc_flow_checks, oc_mimetypes, oc_group_admin, oc_deck_boards, oc_groups, oc_bookmarks_shares, oc_group_folders_acl, oc_ratelimit_entries, oc_circles_member, oc_migrations, oc_notifications, oc_direct_edit, oc_group_folders_trash, oc_twofactor_providers, oc_files_trash, oc_collres_collections, oc_federated_reshares, oc_talk_commands, oc_addressbookchanges, oc_user_transfer_owner, oc_authorized_groups, oc_share, oc_mail_mailboxes, oc_circles_token, oc_talk_bridges, oc_directlink, oc_circles_circle, oc_twofactor_backupcodes, oc_flow_operations_scope, oc_mail_recipients, oc_calendar_appt_bookings, oc_oauth2_clients, oc_circles_remote, oc_group_folders_groups, oc_bookmarks, oc_dav_shares, oc_cards, oc_addressbooks, oc_mail_local_messages, oc_storages_credentials, oc_activity, oc_bookmarks_tags, oc_external_applicable, oc_recent_contact, oc_filecache, oc_file_locks, oc_mail_messages, oc_flow_operations, oc_known_users, oc_text_steps, oc_collres_resources, oc_richdocuments_wopi, oc_mail_coll_addresses, oc_bookmarks_shared_folders, oc_circles_membership, oc_group_folders, oc_systemtag, oc_comments, oc_systemtag_object_mapping, oc_trusted_servers, oc_privacy_admins, oc_dav_cal_proxy, oc_calendar_appt_configs, oc_talk_rooms, oc_deck_stacks, oc_calendar_rooms_md, oc_cards_properties, oc_properties, oc_calendar_resources, oc_calendar_reminders, oc_preferences, oc_circles_share_lock, oc_bruteforce_attempts, oc_filecache_extended, oc_schedulingobjects, oc_systemtag_group, oc_deck_labels, oc_talk_sessions, oc_profile_config, oc_calendars, oc_calendarobjects_props. Weitere Informationen findest du in der Dokumentation ↗.

Dieser Konflikt kann aber schnell gelöst werden, indem man ein Skript mit folgendem Inhalt erstellt und dieses im Nachgang im Home-Verzeichnis ausführt. Dazu wechselt man in dieses:

cd ~/

Dann öffnet man den Editor:

sudo nano database.sh

fügt folgenden Inhalt ein und speichert mit Ctrl + o:

#!/bin/bash

# Prompt for database credentials
read -p "Enter Database Name: " DB_NAME
read -p "Enter Username: " DB_USER
read -s -p "Enter Password: " DB_PASS
echo

# Generate ALTER TABLE statements and execute them
mysql -u "$DB_USER" -p"$DB_PASS" -e "
SELECT CONCAT('ALTER TABLE `', TABLE_NAME, '` ROW_FORMAT=DYNAMIC;') 
FROM INFORMATION_SCHEMA.TABLES 
WHERE TABLE_SCHEMA = '$DB_NAME' 
AND ENGINE = 'InnoDB';
" -B -N | while read -r sql; do
    mysql -u "$DB_USER" -p"$DB_PASS" -e "$sql" "$DB_NAME"
done

Mit Ctrl + x verlässt man den Editor wieder. Nun wird das Skript mit

sudo chmod +x database.sh

ausführbar gemacht und mit

sudo ./database.sh

gestartet. Während der Ausführung werden Datenbankname, Benutzername und Passwort abgefragt. Sind die Eingaben richtig, sind die Datenbank am Ende gefixt und die Fehlermeldung verschwunden.

Der Beitrag Upgrade auf Nextcloud 31 erschien zuerst auf intux.de.

Pi-hole 6.1 erschienen: Verbesserungen in mehreren Bereichen

Von:MK
01. April 2025 um 11:30

Die beliebte Open Source Software Pi-hole hat knapp 6 Wochen seit Version 6 nun ein umfassendes Update erhalten. Pi-hole dient als Werbe- und Tracking-Blocker und kann bei Bedarf auch als DHCP-Server im Netzwerk genutzt werden. Durch die Konfiguration als DNS-Server im Router schützt Pi-hole alle Geräte im Heimnetzwerk oder über eine VPN-Verbindung sogar unterwegs. Die […]

Der Beitrag Pi-hole 6.1 erschienen: Verbesserungen in mehreren Bereichen erschien zuerst auf fosstopia.

Einspielen eines Backups mit Statusanzeige

18. März 2025 um 13:06

Beim Wiederherstellen eines Backups zurück auf eine MicroSD unter Linux ist der Befehl dd ein bewährtes Werkzeug. Jedoch fehlte in der Vergangenheit die Anzeige des Fortschritts, sodass der Benutzer nicht genau wusste, wie lange der Vorgang noch dauert. Mit der Option status=progress ändert sich das. In diesem Artikel zeige ich, wie man ein Backup komfortabel mit dd auf eine MicroSD schreibt und dabei den Fortschritt im Blick behält.

Der Befehl im Detail

Um das Image backup.img aus dem Home-Verzeichnis von intux auf die MicroSD zu schreiben, wird folgender Befehl genutzt:

sudo dd if=/home/intux/backup.img of=/dev/mmcblk0 bs=1M status=progress

Die Eingabe muss natürlich an die Gegebenheiten des eigenen Systems (Verzeichnisse) angepasst werden.

Hier eine kurze Erläuterung der Parameter:

  • sudo – Da dd direkten Zugriff auf die Speichergeräte benötigt, sind Administratorrechte erforderlich.
  • if=/home/intux/backup.img – Das if (input file) gibt das Image an, das auf die Karte geschrieben werden soll.
  • of=/dev/mmcblk0 – Das of (output file) gibt das Zielgerät an. Hier ist es die MicroSD (/dev/mmcblk0).
  • bs=1M – Die Blockgröße beträgt 1 Megabyte. Dies beschleunigt das Schreiben im Vergleich zur Standardblockgröße.
  • status=progress – Zeigt während des Kopiervorgangs den Fortschritt an.

Fortschrittsanzeige in Echtzeit

Einer der größten Nachteile von dd war lange Zeit das fehlende Feedback über den aktuellen Status. Durch die Option status=progress erhalten wir eine dynamische Anzeige, die kontinuierlich angibt, wie viele Daten bereits übertragen wurden.

Während der Kopiervorgang läuft, wird eine Zeile mit der Anzahl der geschriebenen Bytes und der aktuellen Transferrate ausgegeben. Das könnte dann so aussehen:

16280190976 bytes (16 GB, 15 GiB) copied, 1071 s, 15,2 MB/s
dd mit Fortschrittsanzeige
dd mit Fortschrittsanzeige

Diese Anzeige aktualisiert sich in regelmäßigen Abständen, sodass man jederzeit sieht, wie weit der Vorgang fortgeschritten ist.

Fazit

Dank status=progress ist dd nicht mehr die Blackbox, die es früher war. Die Live-Anzeige sorgt dafür, dass man stets über den aktuellen Fortschritt informiert bleibt. Wer regelmäßig Backups auf MicroSDs schreibt, sollte diesen praktischen Zusatz unbedingt nutzen.

Der Beitrag Einspielen eines Backups mit Statusanzeige erschien zuerst auf intux.de.

Raspberry Pi Raid

06. März 2025 um 15:38

Heute möchte ich über ein Thema schreiben, das sicher den einen oder anderen Leser meines Blogs beschäftigt. Es geht um die Frage, wie man auf einer auf einem Raspberry Pi installierten Nextcloud ein RAID-System aufbaut, um Daten redundant auf dem Massenspeicher abzulegen.

Als Vorlage diente mir hierbei eine Anleitung von Daniel von der Firma apfelcast, die ich in Teilen etwas abgeändert habe.

Installation

Zuerst wird die Software mdadm auf dem Raspberry Pi installiert.

sudo apt-get install mdadm

Um diese zu aktivieren, muss der Raspberry Pi nach der Installation von mdadm neu gestartet werden.

sudo reboot

Danach schaut man nach den angeschlossenen Datenträgern. Ich setze voraus, dass man sich zuvor ausreichend mit dieser Materie auseinandergesetzt hat. Ein RAID-Level 1 erfüllt in unserem Fall alle Voraussetzungen für dieses Unterfangen.

Wenn zwei baugleiche SSDs mit identischer Speicherkapazität (z. B. 1 TB) angeschlossen sind, können diese mit folgendem Befehl identifiziert werden:

sudo lsblk

Beide Laufwerke werden als /dev/sda und /dev/sdb ausgegeben.

RAID-System

Raid-System
Raid-System

Nun werden alle Daten und Partitionen der SSDs gelöscht. Hierzu werden beide Befehle nacheinander ausgeführt:

sudo parted /dev/sda "rm 1"
sudo parted /dev/sdb "rm 1"

Ein abschließender Check gibt Gewissheit.

sudo lsblk

Bei Festplatten < 2 TB werden nun die MSDOS-Partitionstabellen erstellt.

sudo parted /dev/sda "mklabel msdos"
sudo parted /dev/sdb "mklabel msdos"

Bei Festplatten > 2 TB verwendet man hingegen folgende Befehle für GPT-Partitionstabellen.

sudo parted /dev/sda "mklabel gpt"
sudo parted /dev/sdb "mklabel gpt"

Anschließend werden die ext4-Partitionen auf beiden Datenträgern erstellt.

sudo parted /dev/sda "mkpart primary ext4 1M -1"
sudo parted /dev/sdb "mkpart primary ext4 1M -1"

Nun wird RAID auf beiden Partitionen aktiviert.

sudo parted /dev/sda "set 1 raid on"
sudo parted /dev/sdb "set 1 raid on"

Anschließend kann der Status überprüft werden (siehe Screenshot).

sudo parted -s /dev/sda print
sudo parted -s /dev/sdb print
Check des Status nach Aktivierung der einzelnen Raid-Partitionen
Check des Status nach Aktivierung der einzelnen Raid-Partitionen

Jetzt wird ein RAID-Level 1 erstellt, sodass beide Laufwerke zu einem zusammengeführt und so die Daten redundant gespeichert werden können. Falls eine SSD ausfällt, sollten somit keine Daten verloren gehen.

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

Alternativ könnte ein RAID 0 eingerichtet werden, um beide SSDs hintereinander zu verknüpfen. Dabei würde sich die Speicherkapazität verdoppeln.

Eine letzte Überprüfung zeigt nun den aktuellen Zustand.

lsblk
Eingehängte Raid-SSDs
Eingehängte Raid-SSDs

Einrichtung des Dateisystems

Nun kann das Dateisystem für das RAID eingerichtet werden.

sudo mkfs -t ext4 /dev/md0

Der Fortschritt wird mit den folgenden Befehlen überprüft (siehe Screenshots).

cat /proc/mdstat
Überprüfung des Fortschritts
Überprüfung des Fortschritts
sudo mdadm --detail /dev/md0
Details des Raid-Systems
Details des Raid-Systems

Das Mountverzeichnis wird erstellt und der Datenspeicher darauf gemountet.

sudo mkdir /media/ssd
sudo mount /dev/md0 /media/ssd

Nun wird die Datei /etc/fstab bearbeitet, damit der Datenträger nach einem Neustart weiterhin mit unserer Nextcloud verbunden bleibt.

sudo nano /etc/fstab/

Dort fügt man folgende Zeile hinzu und speichert die Datei ab:

/dev/md0 /media/raid ext4 4,nofail 0 0
Konfigurations-Datei /etc/fstab
Konfigurationsdatei /etc/fstab

Die Bearbeitung der crontab sorgt dafür, dass das RAID-System beim Neustart korrekt eingebunden wird.

sudo crontab -e

Dort wird folgender Eintrag hinzugefügt:

@reboot sleep 5; sudo mount /dev/md0 /media/raid

Datenverzeichnis verschieben

Das vorhandene Datenverzeichnis wird von der MicroSD auf das RAID-System verschoben.

sudo mv /var/www/html/nextcloud/data /media/ssd

Anschließend muss der Nextcloud noch mitgeteilt werden, wo sich das Datenverzeichnis befindet. Dazu wird die Konfigurationsdatei geöffnet.

sudo nano /var/www/html/nextcloud/config/config.php

Der folgende Eintrag wird angepasst und von

'datadirectory' => '/var/www/html/nextcloud/data',

in

'datadirectory' => '/media/ssd/data',

geändert.

Damit ist die Einrichtung des RAID-Systems für die Nextcloud auf dem Raspberry Pi abgeschlossen!

Der Beitrag Raspberry Pi Raid erschien zuerst auf intux.de.

Nextcloud auf dem RasPi – Teil 9

22. Dezember 2024 um 08:47

Mit diesem Artikel möchte ich meine Nextcloud-Serie schließen. Um die installierte Cloud nun noch mit einer Videokonferenz-Funktion zu erweitern, möchte ich heute zeigen, wie man einen TURN-Server auf das bestehende System aufsetzt. Dies hatte ich im Mai diesen Jahres im Artikel „Coturn TURN-Server für Nextcloud Talk“ zwar schon erklärt, aber es gehört aus meiner Sicht einfach in diese Artikelserie hinein.

Installation

Ein TURN-Server wird von Nextcloud Talk benötigt, um Videokonferenzen zu ermöglichen. Der TURN-Server bringt die Teilnehmer, welche sich in verschiedenen Netzwerken befinden, zusammen. Nur so ist eine reibungslose Verbindung unter den Gesprächspartnern in Nextcloud Talk möglich.

Wer bisher meinen Anleitungen zur Installation von Nextcloud auf dem Raspberry Pi gefolgt ist, kann nun die eigene Cloud für Videokonferenzen fit machen. Zu bedenken gilt aber, dass ein eigener TURN-Server nur bis maximal 6 Teilnehmer Sinn macht. Wer Konferenzen mit mehr Teilnehmern plant, muss zusätzlich einen Signaling-Server integrieren.

Nun zur Installation des TURN-Servers. Zuerst installiert man den Server mit

sudo apt install coturn

und kommentiert folgende Zeile, wie nachfolgend zu sehen in /etc/default/coturn aus.

sudo nano /etc/default/coturn

Dabei wird der Server im System aktiviert.

#
# Uncomment it if you want to have the turnserver running as
# an automatic system service daemon
#
TURNSERVER_ENABLED=1

Nun legt man die Konfigurationsdatei zum TURN-Server mit folgendem Inhalt an.

sudo nano /etc/turnserver.conf
listening-port=5349
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=geheimespasswort
realm=cloud.domain.tld
total-quota=100
bps-capacity=0
stale-nonce
no-loopback-peers
no-multicast-peers

Hier werden u.a. der Port und das Passwort des Servers sowie die Domain der Cloud eingetragen. Natürlich muss hier noch der Port im Router freigegeben werden. Ein starkes Passwort wird nach belieben vergeben.

Hierbei kann das Terminal hilfreich sein. Der folgende Befehl generiert z.B. ein Passwort mit 24 Zeichen.

gpg --gen-random --armor 1 24

Jetzt wird der Server in den Verwaltungseinstellungen als STUN- und TURN-Server inkl. Listening-Port sowie Passwort eingetragen.

Nextcloud - Verwaltungseinstellungen - Talk
Nextcloud – Verwaltungseinstellungen – Talk
Eintrag der Domain für STUN- und TURN-Server (sowie Passwort)
Eintrag der Domain für STUN- und TURN-Server (sowie Passwort)

Damit der TURN-Server nach einem Reboot auch zuverlässig startet, müssen ein paar Einstellungen am Service vorgenommen werden. Mit

sudo systemctl edit coturn.service

wird der Service des Servers editiert. Folgender Eintrag wird zwischen die Kommentare gesetzt:

### Editing /etc/systemd/system/coturn.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Service]
ExecStartPre=/bin/sleep 30

### Lines below this comment will be discarded

### /lib/systemd/system/coturn.service

Dies ermöglicht den TURN-Server (auch nach einem Upgrade) mit einer Verzögerung von 30 Sekunden zu starten.

Zum Schluss wird der Service neu gestartet.

sudo service coturn restart

Ein Check zeigt, ob der TURN-Server funktioniert. Hierzu klickt man auf das Symbol neben dem Papierkorb in der Rubrik TURN-Server der Nextcloud. Wenn alles perfekt läuft ist, wird im Screenshot, ein grünes Häkchen sichtbar.

Check TURN-Server
Check TURN-Server
Check bestanden
Check bestanden

Damit endet die Artikelserie Nextcloud auf dem RasPi. Viel Spaß beim Nachbauen!

❌