# ISP Config 3 Migration



## Teris Cooper (20. Nov. 2014)

Hier haben ich ein Shell-Script, weleches es ermöglicht, ISPConfig 3 inklusive aller Daten auf einen neuen Server zu migrieren.

https://github.com/teris/Debian-ISPConfig3-migration

Bitte beachtet, dass die User / Groups und UNIX-Kennwörter manuell eingefügt werden müssen.

Es werden vom alten Server die Zugangsdaten gespeichert. Dies befindet sich unter dem Verzeichnis /root/old-server/.
(passwd und group)
Die Originale findet Ihr unter /etc/passwd und /etc/group. Diese einfach mit einem editor bearbeiten (vi oder nano)
Beispiel:
*cat /root/old-server/passwd*
Ausgabe:
*replicator:x:1002:1002:,,,:/home/replicator:/bin/bash*
Dies einfach kopieren und in die originale einspeichern:
_nano /etc/passwd_
*root:x:0:0:root:/root:/bin/bash
replicator:x:1000:1000:,,,:/home/replicator:/bin/bash*
FERTIG!


----------



## florian030 (20. Nov. 2014)

> Bitte beachtet, dass die User / Groups und UNIX-Kennwörter manuell eingefügt werden müssen.


Warum exportierst Du nicht einfach nur die relevanten Daten (web*, ispconfig, ispapps)? Und wenn bspw. www-data auf dem neuen Server eine andere UID hat, müssen auch noch ein paar Rechte neu gesetzt werden. Sonst aber eine schöne Idee.


----------



## Teris Cooper (20. Nov. 2014)

Grund dafür ist ja, dass man eben einfach nur den Server umziehen kann, aufgrund besserer Leistung oder so, jedoch nicht alle UID's erneuern muss und die Kunden, sofern man welche hat, nicht neue Passwörter vergeben muss. Darum habe ich das gebaut^^


----------



## Till (20. Nov. 2014)

Es kann aber sein dass sich die UID's unterscheiden, z.B. wenn Du eine andere Installationsreihenfolge der Applikationen verwendet hast. Daher ist es wichtig das zumindest zu kontrollieren.


----------



## Teris Cooper (20. Nov. 2014)

Es kann nicht nur sein, es wird sogar so sein. Aus diesem Grund, habe ich in dem Script das so eingebaut, dass die UIDs vom alten Server in /root/old-server/ gesaved wird. Grund dafür, wenn die Datein überschrieben werden, kommt man nicht mal mehr mit dem ROOT benutzer auf den Server und das wollen wir ja nicht.


----------



## florian030 (21. Nov. 2014)

Und deswegen ist es auch ausreichend, die oben genannten UIDs auf dem alten Server zu exportieren und auf dem neuen zu importieren. Die UID für root ändert sich übrigens nicht und mit dem alten Paßwort kannst Du dich dann problemlos anmelden.


----------



## tom.1 (16. März 2015)

Zum Sichern und Rücksichern der von ISP Config angelegten Benutzer und Gruppen habe ich in meinem Backupskripten immer folgenden Code genutzt (Pfade anpassen, sonst geht's nicht):

*Backup:*

```
echo "# Backup User Accounts"
umask 007
grep ^web /etc/passwd > $backupdir/passwd.ISPusers
grep ^web /etc/shadow > $backupdir/shadow.ISPusers
grep ^client /etc/group > $backupdir/group.ISPusers
echo "Done"
```
*Restore:*

```
cp /etc/passwd /tmp/passwd.bak
umask 007
grep -v ^web /etc/passwd > /tmp/pass.tmp
grep ^web /path-to/passwd.ISPusers >> /tmp/pass.tmp
mv /tmp/pass.tmp /etc/passwd

cp /etc/shadow /tmp/shadow.bak
grep -v ^web /etc/shadow > /tmp/shad.tmp
grep ^web /path-to/shadow.ISPusers >> /tmp/shad.tmp
mv /tmp/shad.tmp /etc/shadow
chown shadow:root /etc/shadow

cp /etc/group /tmp/group.bak
grep -v ^client /etc/group > /tmp/grp.tmp
grep ^client /path-to/group.ISPusers >> /tmp/grp.tmp
mv /tmp/grp.tmp /etc/group
```
Beim Backup werden mittels grep die Benutzer, deren Name mit "web" beginnt und die Gruppen, die mit "client" beginnen in Dateien gespeichert.
Beim Restore werden die originalen Dateien passwd, shadow und group erst in /tmp/ gesichert. Dann werden noch einmal Kopien angelegt, aus welchen die "web..." und "client...-Einträge herausgefiltert werden - falls es schon ISP Config Benutzer auf dem neuen System gab. Der Umzug funktioniert ja nur, wenn man ISP Config 1:1 überträgt. Zusammenführen geht nicht, deshalb können/müssen diese Einträge soweit vorhanden auch weg. Die weiteren Kopien werden dann mit den gesicherten Daten zusammengeführt und nach /etc kopiert.

Einen einzigen Fallstrick bei dieser Methode gibt es, wenn man einen regulären (nicht ISP Config-)Benutzer hat, dessen Benutzername mit web beginnt. Dieser wird beim Backup mitgenommen und beim Restore aus den Dateien des neuen Servers herausgefiltert. Letzteres kann ein Problem werden und muss deshalb manuell kontrolliert werden. Gleiches gilt für reguläre (nicht ISP Config-)Gruppen, die mit "client" beginnen.

Die Code-Schnipsel stammen aus einem Backup-Skript von djTremors aus irgendeinem Forum (ist schon eine Weile her), aller Dank geht deshalb an ihn.


----------



## Till (16. März 2015)

Zitat von tom.1:


> grep ^web /etc/passwd > $backupdir/passwd.ISPusers grep ^web /etc/shadow > $backupdir/shadow.ISPusers


Nur als Hinweis: Dieser grep Befehl lässt aber die shelluser aus, die Du in ISPConfig für die Webseiten angelegt hast. Hast Du keine Shelluser angelegt, geht es so.


----------



## tom.1 (16. März 2015)

Das stimmt. Die Shell-User werden nach dem Muster [client_id]xyz angelegt.

Für ein Backup gibt es leider keine einfache Standardlösung. Für passwd und group könnte man es an der UID/GID festmachen, die ist ja immer >5000. Dann sind im Backup aber auch die ISPConfig "Systembenutzer" dabei. Ist es richtig, dass sich deren Anzahl sich auch in Zukunft nicht ändert? Bei mir beginnen die web-User mit GID 5005 und UID 5004. D.h. man könnte für ein Backup theoretisch mit diesen Werten arbeiten. Bleibt noch shadow.  An der Stelle fehlt mir eine einfache Idee - man könnte die auszulesenden Einträge mit den zuvor aus passwd und group ausgelesenen abgleichen. Fühlt sich aber nach einigem Programmieraufwand an. Da hab ich die paar Shell-User schneller per Hand exportiert. Bei mir sind es 0, das geht noch schneller 

Am sichersten wäre es wohl, diese Funktionalität in ISPConfig selbst zu integrieren. Das System sollte ja "wissen", welche Benutzer es selbst erstellt hat, d.h. welche für das Backup/den Umzug exportiert werden müssen.


----------



## Till (16. März 2015)

Zitat von tom.1:


> Das stimmt. Die Shell-User werden nach dem Muster [client_id]xyz angelegt.


Das ist ein mögliches Schema. Das Schema ist aber frei konfigurierbar, daher können die Uernamen nahezu beliebig sein.

Das Ganze ist an sich recht einfach zu lösen, denn wie ich oben geschrieben habe teilen sich diese shell user die UID (also die numerische ID) mit den web* Usern. Was ,an also machen muss ist folgendes:

1) Alle web* user mit grep extrahieren in eine temporäre Datei.
2) die Liste der user durchgehen und dann für jede enthaltene UID ein grep auf die passwd Datei machen.


----------



## florian030 (17. März 2015)

Könnte man nicht web_domain um die GID und UID erweitern? Zumindest solange connect_userid_to_webid gesetzt ist?


----------



## Till (17. März 2015)

Könnte man generell machen, ich denke aber ads wäre einfach nur doppelte Datenhaltung denn man kann die UID des Users ja in php mittels posux Funktionen abfragen oder auch eifach mittels grep aus der passwd Datei abfragen.


----------



## florian030 (17. März 2015)

Ich dachte dabei mehr an die Möglichkeit, bei einem Umzug die User dann per resync anlegen zu können.


----------



## Till (17. März 2015)

Ok, ja. dafür kann es Sinn machen. Das ist aber gerade bei multiuser systemen ein echtes Problem denn dazu müsste der slave ja die uid's von shell usern in der master DB ändern können, wenn dann mal ein slave gehacked wird dann kann man da sehr viel Schaden auf allen nodes anrichten. Und bei connect_userid_to_webid servern könnte dar rsync die ID's ja sowieso berechnen.


----------



## florian030 (17. März 2015)

Bei einem connect user - web geht das. Ich hab bei mir keine Shell-User. Haben die dann immer die gleiche ID wie die dazugehörige Website? Dann dürfte es nicht so kompliziert sein, dass dem resync-tool dann auch noch beizubringen.


----------



## Till (18. März 2015)

Zitat von florian030:


> Haben die dann immer die gleiche ID wie die dazugehörige Website?


Linux USERID = min userid + web ID

Die min userid ist standard 1000 und unter System > server config > Start ID for userid/webid connect definiert.


----------



## Till (18. März 2015)

Ein Problem gäbe es an sich nur wenn jemand die min userid ändert nachdem das erste web angelegt wurde. Das führt aber immer zu Fehlern wenn jemand versuchen sollte sie zu verkleinern (vergrößern ist ok), sollten wir ggf. noch als fehlermeldung abfangen, falls jemand das versuchen sollte.


----------



## florian030 (19. März 2015)

Stellt sich nur die Frage, wie man das anlegen der user bei einem resync realisiert - als eigenes plugin oder die vorhandenen plugins erweitern bzw. useradd dort anpassen und die uid mitgeben.


----------



## Till (19. März 2015)

An sich müsste das bereits jetzt schon so sein, denn wenn connect angeschaltet ist wird ja beim anleen der user die uid übergeben, sollte also auch beim resync gehen.


----------



## florian030 (19. März 2015)

Dann kann man sich bei einem Umzug ja das Sichern von passwd und group sparen. Einfach nach der Installation (bei nur einem Server einen Dump von dbispconfig einspielen und) einen kompletten Resync laufen lassen.


----------



## nowayback (19. März 2015)

Zitat von Teris Cooper:


> Hier haben ich ein Shell-Script, weleches es ermöglicht, ISPConfig 3 inklusive aller Daten auf einen neuen Server zu migrieren.
> 
> https://github.com/teris/Debian-ISPConfig3-migration
> 
> ...


Führst du das Script auf dem neuen oder auf dem alten Server aus?

```
echo "Installation von Rsync auf dem Remote Server..."
    ssh $main_server "$install_rsync"
```
liest sich als würde es auf dem alten ausgeführt werden und auf dem neuen rsync installiert werden.


```
ssh $main_server "mysqldump -u root -p$mysqlext --all-databases > fulldump.sql"
```
liest sich als würde es auf dem neuen Server ausgeführt werden, der sich die Daten vom alten holt


----------



## Teris Cooper (4. Mai 2015)

Nowayback: Das script wird komplett auf dem neuen Server ausgeführt.

Mitlerweile habe ich das Script angepasst und verbessert.

Download:
http://sv03.ns3.orga-consult.com
Kundennumer: FREE
Lizenz: ISPconfig

oder auch per wget:
wget http://sv03.ns3.orga-consult.com/download.php?lizenz=ISPconfig
chmod 777 migration.sh
./migration.sh

Alles auf dem neuen ROOT Server ausführen.


----------



## Ovidiu (7. Okt. 2015)

Hi,

ich stehe auch gerade vor dieser Aufgabe einen ISPCFG3 Server auf einen neuen zu migrieren und wollte mal nachfragen ob das Skript von Teris noch funktioniert und ob jemand noch Erfahrungen damit gemacht hat oder Bemerkungen dazu hat bevor ich den Sprung wage?
Ich habe auch noch ein anderes Skript gefunden das scheint aber älter zu sein: 
h**ps://gist.github.com/yorch/9410737 

P.S. der Download link zu Teris' Skript geht gerade auch nicht


----------



## florian030 (7. Okt. 2015)

Ich würde den Server von hand migrieren. Ich habe noch nie einen Server per Script migriert. Das wäre mir dann doch zu heikel. Und so extrem viele Schritte sind das ja nun auch wieder nicht.


----------



## Ovidiu (7. Okt. 2015)

Danke für die Antwort,
ich stimme prinzipiell schon zu, so habe ich das bisher auch immer gemacht. Bin noch dabei den neuen aufzusetzen, hast du eventuell ein Paar Tips/Links dazu? Wollte meine Fragen diesbezüglich nicht in diesem Thread stellen, wenn ich nicht weiter komme mache ich einen eigenen auf aber für Tips bin ich dankbar.


----------



## florian030 (7. Okt. 2015)

Ich setze die Server immer nach den Tutorials von Howtoforge auf. Anpassen kann man immer noch, wenn man was anderes braucht. Grundsätzlich läuft es damit aber sauber. Wenn Du einen Server migrierst, brauchst Du im Prinzip nur Teile von passwd, group und shadow aus /etc. Den Rest macht der Installer. Danach kannst Du die alten Datenbank importieren und lässt den Resync laufen (ich meine, im Multiserver-Setup musst Du noch ein paar Daten manuell auf die Slaves kopieren / einfügen) und kopierst web- und mail-domains.


----------



## Ovidiu (7. Okt. 2015)

das mit den Tutorials, ist klar.
Anpassen auch, mache da immer extras mit drauf.
passwd/group ist auch klar.
DBs hab ich bisher immer alle (also die von ISPCFG und den Kunden) exportiert und wieder importiert.
web folder manuell transferiert.
emails migriert per imapsync.

Alles ein Haufen Arbeit und logischer weise fehleranfällig bei Unachtsamkeit.

Multiserver-Setup hab ich noch nie angefasst, hab kurz in die Anleitung geschaut, kannst du mich aufklären was genau Multiserver-Setup einfacher macht? Vor allem, wenn das alles migriert ist, kann man den alten Server einfach abschalten oder muß ich dieses Multiserver-Setup irgendwie noch ändern auf dem neuen Server? Ist das jetzt mehr zu lernen als einfach alles händisch machen?


----------



## florian030 (7. Okt. 2015)

Du brauchst die Mails nicht mit imapsync zu kopieren, wenn Du nicht von COurier zu Dovecot o.ä. wechselst. Die Kunden-DBs brauchst Du natürlich. Du kannst aber auch ein mysqldump von allen Datenbanken machen, auf dem neuen Server importieren, ggf. system-user-paßwörter anpassen (debian-sys-maint o.ä.) und gut ist. Dann geht ein neues install aber nur, wenn Du vorher dbispconfig umbenennst.
Das ist etwas Arbeit, aber bei einem Single-Server dauert das kaum länger als ne Stunde, wenn man mal das Kopieren von Web und Mail weglässt. Das ist übrigens ein Grund, warum meine Server immer virtualisiert sind - und das ist effekiv ein MUltiserver-Setup. Da kann man nämlich einfach mal so einen Server auf eine andere Hardware kopieren - so ganz ohne neues Setup o.ä.


----------



## Ovidiu (9. Okt. 2015)

Danke für all die Tips, hast du noch nen Tip/Link zu Virtualisierung? Ich sitze auf einem Strato Root Server d.h. ich hab nur 2 IPs, bin mir da nicht ganz so sicher was für eine Netzwerkkonfiguration da überhaupt laufen könnte. Theoretisch wäre ja die 1. IP for den Host, z.b. Proxmox möglich und die 2.IP für die virtuelle Maschine. 
Und ja, 2IPs reichen, das ist eine ganz kleine Umgebung.


----------



## nowayback (10. Okt. 2015)

ob du nun proxmox, xenserver, vmware, hyper-v oder openvz nutzt ist eigentlich egal. ist hauptsächlich eine "glaubensfrage" und die des eigenen geldbeutels ;-)
Mit 2 IP's brauchst du nicht NAT-ten, daher nimm was du willst - 1. ip host, 2. ip guest und fertig.

Mach es nicht komplizerter als nötig, sonst ärgerst du dich irgendwann selbst drüber


----------



## Ovidiu (10. Okt. 2015)

danke, dacht ich mir auch so, einfach halten.

P.S. Falls jemand von den Moderatoren hier mitliest, sämtliche "Notification" Emails von howtoforge.de bzgl. neuer Antworten im Forum landen in meinem Gmail SPAM Verzeichnis... Ich markier die zwar als HAM aber na ja...
Die von howtoforge.com landen ganz normal in der Inbox.


----------



## robotto7831a (10. Okt. 2015)

Dann schau doch mal in den Mailheader ob dort etwas drin steht warum diese als Spam markiert werden.


----------



## Ovidiu (10. Okt. 2015)

Ich war zu schnell, bitte jemand noch etwas hier kommentieren damit ich das nachschauen kann.
Google sagt schon was darüber aus aber sobald ich die Email als HAm markiere verschwindet das :-(


----------



## robotto7831a (10. Okt. 2015)

Nur ein E-Mailtest.


----------



## Ovidiu (11. Okt. 2015)

ok, hier ein Screenshot: http://screencast.com/t/KiKaBJXX2mk da steht bloss: die Email landete im SPAM weil sie so aussieht wie viele andere welche auch im SPAM landeten...

Hier mal die header:

```
Delivered-To: meine@email
Received: by 10.194.151.4 with SMTP id um4csp627824wjb;
        Sat, 10 Oct 2015 12:06:34 -0700 (PDT)
X-Received: by 10.194.48.81 with SMTP id j17mr20845901wjn.81.1444503994810;
        Sat, 10 Oct 2015 12:06:34 -0700 (PDT)
Return-Path: <info@projektfarm.de>
Received: from www.howtoforge.de (www.howtoforge.de. [144.76.77.104])
        by mx.google.com with ESMTP id ef7si9498515wjd.49.2015.10.10.12.06.34
        for <meine@email>;
        Sat, 10 Oct 2015 12:06:34 -0700 (PDT)
Received-SPF: neutral (google.com: 144.76.77.104 is neither permitted nor denied by best guess record for domain of info@projektfarm.de) client-ip=144.76.77.104;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 144.76.77.104 is neither permitted nor denied by best guess record for domain of info@projektfarm.de) smtp.mailfrom=info@projektfarm.de
Received: by www.howtoforge.de (Postfix, from userid 1002)
    id 67C013EE06; Sat, 10 Oct 2015 21:06:04 +0200 (CEST)
To: Ovidiu <meine@email>
Subject: ISP Config 3 Migration - Neue Antwort in einem beobachteten Thema
X-PHP-Originating-Script: 1002:Sendmail.php
From: Howtoforge Webmaster <info@projektfarm.de>
X-To-Validate: c6ad120d+meine@email
Message-Id: <ce83cc0bbf2c706288048eeb3a3916518e75c2dd@howtoforge.de>
Date: Sat, 10 Oct 2015 19:06:04 +0000
Content-Type: multipart/alternative;
boundary="=_cd6d714051a5b7ab735c7e093531e419"
MIME-Version: 1.0

--=_cd6d714051a5b7ab735c7e093531e419
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
```


----------



## mathschut (3. Nov. 2015)

HI,
ich möchte auch meinen Vserver kündigen und zu einen Root-Server wechseln. Könnt ihr mir ein paar Tipps oder Anleitung empfehlen, wie ich am schnellsten und saubersten das ISP auf einen neuen Server umziehen kann. 2th Frage, kann ich auch von Apache2 gleich auf nginx umstellen beim Umzug?

Mfg

Mathias


----------



## robotto7831a (3. Nov. 2015)

Wie viele Kunden / Webseiten müssen umziehen?


----------



## mathschut (4. Nov. 2015)

Es sind so ungefähr 15 Kunden die ich umziehen muss.


----------



## florian030 (4. Nov. 2015)

Die Anzahl der Kunden ist ziemtlich egal. Du müsstes im englischen Forum zahlreiche Posts dazu finden.


----------



## mathschut (4. Nov. 2015)

HI,
ja habe schon ein paar Posts gelesen, aber könnt ihr einen empfehlen?


----------



## Ovidiu (10. Nov. 2015)

hm, was macht man eigentlich wenn IDs unterschiedlich sind alt/neu z.b. 


```
sdiff passwd-alt passwd-neu
bind:x:110:114::/var/cache/bind:/bin/false                | bind:x:109:117::/var/cache/bind:/bin/false
postfix:x:106:109::/var/spool/postfix:/bin/false          | postfix:x:107:114::/var/spool/postfix:/bin/false
```


----------



## florian030 (10. Nov. 2015)

Gar nichts. Es geht nur um web* in passwd und shadow sowie um client und sshusers in group


----------



## Till (10. Nov. 2015)

Um Florians Antwort zu ergänzen: daher darfst Du auch nur die web* user und client* Gruppen umziehen und nicht die systemuser bzw keinesfalls die kompletten dateien rüber kopieren.


----------



## Ovidiu (10. Nov. 2015)

ach so, ich dachte bei den anderen Usern müßte man vielleicht auch was korrigieren. Danke für die Aufklärung.


----------



## Ovidiu (12. Nov. 2015)

:-( irgendwo ging hier doch was schief, mit den Passwörtern meine ich. Ich muß mich irgendwo ver-kopiert haben oder so. Ist alles nicht tragisch, der alte Server läuft noch ne Weile.

Ich hab Probleme mit allerlei Diensten (rund um Email bisher) die nicht auf MYSQL zugreifen können. Was wäre denn die einfachste Lösung deren Zugang wiederherzustellen? 

z.b.

```
Nov 12 00:14:10 alfred postfix/cleanup[30104]: warning: 57166525B6F: virtual_alias_maps map lookup problem for munin@alfred.ict-consult.co.za -- message not accepted, try again late
Nov 12 00:14:10 alfred postfix/cleanup[30104]: warning: proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf lookup error for "munin@alfred.ict-consult.co.za"
Nov 12 00:20:11 alfred postfix/proxymap[30508]: warning: connect to mysql server 127.0.0.1: Access denied for user 'ispconfig'@'localhost' (using password: YES)
Nov 12 00:20:11 alfred postfix/trivial-rewrite[30536]: warning: proxy:mysql:/etc/postfix/mysql-virtual_transports.cf lookup error for "*"
Nov 12 00:20:11 alfred amavis[30285]: (30285-01) (!)connect_to_sql: unable to connect to DSN 'DBI:mysql:database=dbispconfig;host=127.0.0.1;port=3306': Access denied for user 'ispconfig'@'localhost' (using password: YES)
```
und dazu noch das hier: `postconf: warning: /etc/postfix/main.cf: undefined parameter: virtual_mailbox_limit_maps`


----------



## florian030 (12. Nov. 2015)

Überprüfe mal das Paßwort in /etc/postfix/mysql-virtual_transports.cf für den DB-Zugang zu dbispconfig.


----------



## Ovidiu (12. Nov. 2015)

Danke, hatte ich gemacht. dachte halt das kann man irgendwie "globaler" machen. Ich hab das Passwort jetzt manuell in allen .cf Dateien geändert.

Jetzt muss ich nur noch rausfinden wo ich das amavis Passwort ändern kann:
'Nov 12 07:50:20 alfred amavis[4362]: (04362-01) (!)connect_to_sql: unable to connect to DSN 'DBI:mysql:database=dbispconfig;host=127.0.0.1;port=3306': Access denied for user 'ispconfig'@'localhost' (using password: YES)'

GEFUNDEN: /etc/amavis/conf.d/50-user


----------



## Ovidiu (12. Nov. 2015)

ich schon wieder, irgendwas lief hier schief, der neue Server läuft jetzt soweit, allerdings merke ich gerade im ISPCFG3 dashboard sind zwar alle Einstellungen da, wie auf dem alten Server aber die Datenbanken fehlen.

Ich hab jetzt versucht ne DB zu importieren da sagt er mir die existiert nicht:

```
mysql -u root -pMy$ql c1hs < c1hs.sql
Warning: Using a password on the command line interface can be insecure.
ERROR 1049 (42000): Unknown database 'c1hs'
```
Hab mal unter resync geschaut, und alles gesynct, da steht dann auch daß die webseiten, DBs und DB User gesynct wurden, passiert ist aber nichts.

Im ISPConfig Log sehe ich nach dem resync für jede einzelne Seite:

```
nginx did not restart after the configuration change for website l4sit.xxx. Reverting the configuration. Saved non-working config as /etc/nginx/sites-available/l4sit.xxx.vhost.err

Reason for nginx restart failure: Failed to get D-Bus connection: Unknown error -1
```
Ist das noch zu retten oder soll ich von vorne anfangen?
Wenn von vorne anfangen, gibts hier irgendwo ein How-To Migrate? Ich bin echt müde, ich mach das immer Abends nach einem harten Tag, hab ich bisher auch jahrelang immer hinbekommen aber gerade hakts :-(

Und mein Gmail Postfach läuft über mit Emails: 12.11.2015-21:32 - WARNING - Reason for nginx restart failure: Failed to get D-Bus connection: Unknown error -1

Schönen Abend noch.

Die nginx Geschichte gelöst weil in dem LXC systemd installeirt war, deinstalliert und schon ging alles.


----------

