Homeserver Update Problem

Posted by quark007 | Posted in Computer & IT, Programmieren / Coden | Posted on 09-06-2015-05-2008

0

Da ich es nicht lassen kann und immer wieder am rumspielen und ausprobieren bin, ist mir heute etwas komisches passiert. Nun aber nach einander.

Postfix als Relay-Server einrichten

Ich habe den Postfix Mail-Relay eingerichtet (das hatte bei mir lange nicht funktioniert). Nach dieser Anleitung bin ich vorgegangen und habe alles korrekt eingerichtet. Da ich das ganze über meinen Posteo-Account laufen lassen wollte habe ich folgende Werte angegeben:

Hostname: ServerName [Bei mir war dabei wichtig, dass es eine öffentlich registrierte Internetdomain ist. Sonst gab es einen Fehler]
SMTP-Relay: "[posteo.de]:587"

In der main.cf habe ich diese vorgegebenen Werte ergänzt und die vorigen Eingaben kontrolliert.

Die Datei /etc/postfix/sasl_password mit dem korrekten Inhalt wird mit folgendem Befehl erstellt:

sudo echo "posteo.de [Benutzername]@posteo.de:[Passwort]" > /etc/postfix/sasl_password

Nachdem ich dann den Postfix-Server neugestartet hatte, konnte ich wirklich Mails versenden und die kamen auch an. Ohne das “@posteo.de” im Benutzernamen gab es einen Authentifizierungsfehler. Wurde lediglich posteo.de als Relayserver angegeben, wurde mir der Zugriff verweigert.

Unbekannter Fehler mit falscher Lösung

Mein Smartphone besser gesagt DavDroid meldete auf einmal, dass es ein Synchronisationsproblem gegeben habe. Also den Sync nochmal neu gestartet, aber die Meldung kam wieder. Also versucht mich in OwnCloud einzuloggen: 403 Fehler beim Laden der Seite. Naja dachte ich mir, schau ich mir halt mal nginx-Config an. Sah alles normal aus und auch ein Neustart von nginx hat nichts gebracht.

Da mir im Openmediavault Forum schon einmal sehr weiter holfen wurde und ich erfahren habe, dass der Befehl

sudo apt-get install --reinstall openmediavault

meine Konfiguration beibehält aber Fehler dennoch beseitigen konnte (damals ein Fehler mit nicht mehr auffindbarer env.conf), habe ich diesen Befehl einfach mal ausgeführt. Doch das verschlimmerte alles nur. Meine Plugins (Nginx, Mysql, OMVextras etc.) waren alle weg. Ich habe den Server dann erstmal neu gestartet in der Hoffnung, dass er beim Start die Konfig-Dateien vielleicht doch findet und wieder einbindet, aber war nix. Zu allem Überfluss konnte ich mich auch per SSH nicht mehr einloggen und auch die SMB-Shares waren nicht erreichbar. Die Services waren gestartet, aber das Symbol dafür war rot, also lag ein Fehler vor. Aber welcher?

Das weiß ich bis eben auch noch nicht. Ein ändern der Konfiguration, deaktivieren, speichern und wieder neu aktivieren hat das Problem dann aber beseitigt.

Also habe ich alle Plugins wieder installiert und eingerichtet (was ein act, wenn man die Konsole gewöhnt ist und sich jetzt im Webinterface zurecht finden muss). Dabei ist mir aufgefallen, dass in der Menüleiste ein Feld für das Owncloud-Interface ist. Da ich mein OwnCloud aber manuell in einem Server installiert habe brauche ich das nicht.

Menüpunkt in OMV entfernen

Dazu gehen wir in folgendes Verzeichnis

cd /var/www/openmediavault/js/omv/module

Darin sind 3 Ordner zu finden für die verschiedenen Usertypen. Da ich nur als Admin Änderungen vornehmen kann und das Plugin sonst keinem User sichtbar ist, gehe ich in den Ordner admin/.
Dort sind jetzt alle Überkategorieren des Webinterfaces als eigener Ordner aufgeführt. Die mich störende Fläche war im Bereich Dienste (also Services). Deshalb in den Ordner service/ wechseln.

Dort habe ich dann den Übeltäter gefunden: es existiert noch ein Ordner namens owncloud, obwohl ich das Plugin bereits deinstalliert habe. Mit einem beherzten

sudo rm -r /var/www/openmediavault/js/omv/module/admin/service/owncloud/

wird der Ordner und damit die Schaltfläche gelöscht. Nun muss nur noch der JS-Cache geleert werden

source /usr/share/openmediavault/scripts/helper-functions && omv_purge_internal_cache

und schon können wir unser Ergebnis bestaunen.

Da ich gerade dabei war, habe ich außerdem gleich mal etwas aufgeräumt: /var/www/ war von einigen vorangegangenen OwnCloud Installationen ziemlich vollgemüllt. Außerdem habe ich anschließend auf meiner SystemSSD noch gleich weitere Ordner gelöscht. Als ich dann aber Owncloud wieder öffnen wollte erhielt ich die Meldung, dass das Datenverzeichnis nicht gefunden werden kann.

Data directory (/media/[StorageID]/owncloud8/) is invalid
Please check that the data directory contains a file ".ocdata" in its root.

Verdammt. Ich hatte den Datenordner von Owncloud gelöscht. Durch den Namen owncloud8 dachte ich es wäre eine alte Installation.

Rettung und Wiederherstellung der Owncloud Daten

Ich habe es glücklicher Weise sofort gemerkt und angefangen nach einer Datenrettung zu suchen. Da ich als Dateisystem auf ext3 gesetzt habe, hat sich für mich extundelete angeboten. Da es in meinen Repository enthalten war musste ich es nur installieren:

sudo apt-get install extundelete

Da ich keinen eigenen Mountpunkt für das Verzeichnis angelegt habe, musste ich die ganze Partition nach gelöschten Daten durchsuchen lassen. Bei mir ging das mit folgendem Befehl:

extundelete --restore-all /dev/sdc3

Dadurch wurde ein Ordner mit dem Namen RECOVERED_FILES erstellt in dem alle gefundenen Dateien enthalten waren. Zum Glück war auch mein gelöschter Ordner dabei, den ich an den alten Platz zurück kopiert habe. Beim Wiederherstellen sind aber natürlich alle Rechte und Inhaberinformationen verloren gegangen.

Beim ersten Aufruf von Owncloud habe ich die gleiche Meldung wie oben erhalten. Da die Daten aber nun ja da waren, musste etwas mit der .ocdata nicht in Ordnung sein. Da ich die Datei aber nicht fand (zum Suchen sollte ls -a verwendet werden, sonst werden verstecke Dateien nicht angezeigt), habe ich in diesem Forum den Hinweis bekommen, dass es reicht eine leere Datei anzulegen. Mit

touch /media/[StorageID]/owncloud_data/.cdata

ging das sehr einfach und die Meldung ist verschwunden. Nachdem ich mich dann in OwnCloud einloggen konnte, habe ich folgende Meldung über der Dateiübersicht angetroffen:

"you don't have permission to upload or create files here"
bzw
"du hast keine berechtigung hier dateien hochzuladen oder zu erstellen"

Die Internetsuche nach den korrekten Rechten für diese Ordner ist fast ergebnislos verlaufen. Einzig dieser Blog-Beitrag hat mich weitergebracht.

su www-data
$ php /media/[StorageID]/nginx-owncloud8002/console.php files:scan --all

Damit durchsucht Owncloud den Datenordner komplett neu und setzt dabei auch gleich die richtigen Berechtigungen. Bei mir hat er dabei folgende Fehlermeldung ausgespuckt:

Home storage for user MichaelNiederle not writable

Bei genauerem Hinsehen ist mir aufgefallen, dass sowohl der Inhaber als auch die Rechte nicht korrekt waren und ihm wohl nicht ausreichtend. Nach diesen Befehlen

sudo chown -R www-data:www-data /media/[StorageID]/owncloud_data/
sudo chmod 775 /media/[StorageID]/owncloud_data

lief der Scan aber ohne Probleme durch und alles war wieder in Ordnung. Natürlich habe ich sogleich ein Backup angelegt und den Datenordner umbenannt. Anschließend in der Owncloud-Installation im Verzeichnis config den Pfad in der config.php ebenfalls anpassen.

Netzwerkbrücke einrichten

Durch die Probleme mit der SSH-Verbindung hatte ich auch meine Netzwerkeinstellungen zurückgesetzt. Die Netzwerkbrücke musste ich also wieder neu einrichten. Da der Server zwei Netzwerkkarten hat (eth0, eth1) und ich meinen Rechner auf der Hochebene nicht mit dem langsamen WLan verbinden will, habe ich vom Server zum Rechner auch noch ein LAN-Kabel gelegt. Den Server musste ich dabei als Netzwerkbrücke einrichten. Das funktioniert ganz einfach, wie im Ubuntu Wiki beschrieben ist. Die Netzwerkdatei öffnen

sudo nano /etc/network/interfaces

und folgende Zeilen dort einfügen

auto br0
iface br0 inet static
    address 192.168.169.2
    netmask 255.255.255.0
    gateway 192.168.169.1
    bridge_ports eth0 eth1
    bridge_fd 5

Anschließend noch die Netzwerkverbindung neu aufbauen lassen

sudo service networking restart

und fertig.

Fazit

Das ganze hat mich zwar wieder einmal fast 3 Stunden gekostet (mit Schreiben dieses Beitrags), dafür läuft wieder alles und ich hab meine Daten sicher!

Write a comment


Warning: Undefined variable $user_ID in /home/web5wipjw/html/httpdocs/wordpress/wp-content/themes/Stripey/comments.php on line 57