Wichtig: K4S neue Pakete, Default Stable vs. Beta Community und Migration / Downgrade

[Tosoboso]

Hallo zusammen,

Es gibt neue Pakete für K4s und da gibt es einiges zu Beachten, um Überraschungen zu vermeiden.
In der Vergangenheit konnte man aus einem Paket die Community, oder die Supported Auswählen und Verwenden, letzteres nur wenn eine Subscription und SNR hatte.

Die Pakete sind nun auch so geändert, dass Community Beta von den Stable Versions getrennt sind und es gibt nun ähnlich wie bei Kopano4UCS eine getestete Version, die ich Default nenne.Diese Version benötigt keine SNR, ist 3-9 Monate alt, aber eben stabiler und ohne die Überraschungen einer ständig ändernden Community Edition von den Nightly Builds. Siehe auch hier: https://www.synology-forum.de/showth...l=1#post831456

Bei einer Neuinstallation mit leerer Datenbank ist alles einfach und ich empfehle die Default Stable zu verwenden, um sich diverse Überraschungen der Nightly Beta Builds zu ersparen.
Man kann jedoch NICHT die SPK Stable mit K4S Default per Upgrade auf eine alte Community Installieren. Beim Upgrade warnt k4s und bricht ab. Sollte man jedoch k4s Community de-installieren, die Datenbank behalten und Versuchen die Stable zu installieren, dann scheitert das im Sinne von 'nice try', denn die Version ist in Datenbank hinterlegt und bei 'Mismatch' bricht Kopano ab.

Ich empfehle trotzdem auf die Default Stable zu wechseln, was aber mit etwas Aufwand verbunden ist und man die Reihenfolge der Migrations-Schritte beachten muss. Konkret:
1. User Exportieren mit einer laufenden Beta-Community via >kopano-backup. (nicht kopano4s-backup!) 2. Un-Install mit Datenbank NICHT behalten, aber Kopano Volume behalten, wo ja das Backup aller User liegt.
3. Stable-Default Installieren mit frischer Datenbank und alle User Importieren via >kopano4s-restore-user all. Zu den Aktionen werden im Backup-Verzeichnis Log-Files hintelegt.
Bei der Gelegenheit kann man auch komfortabel auf die Option Attachements im Filesystem wechseln, denn die alten Versionen haben trotzt Menu-Auswahl immer die Datenbank für Attachments genutzt.
-TosoBoso

 

[Tosoboso]

Hallo zusammen,
Beide Versionen k4s 1.01 & 1.01b sind nun seit gestern 22:00 auf CPHUP verfügbar (danke Matthieu).
Man bekommt also nun im SPK Beta Steam die Kopano Community Edition und im Stable Stream die von Kopano durch getesteten Supported, 1x latest mit SNR, 1x ~9m alt frei, die neue Default.
Beide SPKs sind in Funktionalität identisch, nur die Menu Auswahl leitet auf die entsprechende Edition. Da es beim Upgrade keine Menu Auswahl gibt nochmals wichtiger Hinweis zum einfachen Weiterarbeiten geht der Upgrade Vorgängerversion k4s mit Community, was die meisten von euch haben, nur im Beta Channel mit k4s 1.0.1b. Dann kann man sich mit dem Downgrade, wie im letzten Post beschrieben beschäftigen. Und das mit dem Downgrade ist ein Kopano Feature und an sich nachvollziehbar, um Inkompatibilitäten zu vermeiden. Das Script kopano4s-restore-user habe ich übrigens geschrieben, um den Umstieg zu erleichtern. Es ruft in einer Loop über alle gesicherten User im Backup Verzeichnis (die durch kopano-backup angelegt wurden) kopano-backup --restore userx auf und legt den User in der leeren Datenbank an, falls er nicht existiert. Man muss danach im kopano-admin das Passwort der User zurücksetzen. Alternativ legt man in der leeren Hülle Default Version vor dem Restore alle User mit Passwort etc. erstmal an und fährt dann den Restore. Ich hoffe das hilft.
- TosoBoso

 

[FricklerAtHome]

Hallo Tosoboso

wenn ich das richtig verstanden habe läuft es jetzt so: Alle K4S-User die bereits lizensiert mit einer Seriennummer arbeiten, können die K4S 1.01 einsetzen. Die Übrigen betreiben eine K4S die auf der Community Edition und damit den Nighly Builds aufsetzt. Seit dem Core 8.70.81 und höher laufen diese Community-Cores aber nicht mehr ausreichend stabil für ein SPK. Das kann ich bestätigen. Also bietest du für einen stabilen SPK Einsatz eine Default / Stable Version an, die so vermute ich, aus einem von dir getesteten Nighly-Community-Build besteht. Der ist deutlich älter als der jeweils tagesaktuelle, dafür aber eben laufstabil.
Der von dir für diese Default / Stable Version Core ist aber älter als das letzte aktuelle Nightly-Build, bzw. wird es zukünftig immer sein. Um auf diesen Default / Stable (K4S 1.01) zu kommen muss man mit Hilfe der K4S 1.01beta zunächst sein System "normalisieren" und downgraden (wie oben beschrieben).
Das ganze ist notwendig, da aktuell in den Nightly-Builds viele Veränderungen stecken, denen du ansonsten fast täglich mit Anpassungen im SPK hinterherrennen müsstest. Das umgehst du durch längere, dafür aber stabilere Update-Intervalle. Für alle die neu mit dem Thema K4S starten empfiehlst du die K4S 1.01.

Habe ich das so richtig verstanden? -- Wenn ja, ist der eingeschlagene Weg aktuell der einzig mögliche. Auch ich habe mit den Nightly-Builds (vor allem die Core-Komponenten) meine Probleme und deshalb unsere Installationen auf Core 8.70.80 eingefroren. Statt nun täglich irgendwelche Böcke zu suchen, frickel ich jetzt an einer Debian 10 VM, die vollständig neu für Kopano aufgesetzt wird. Da ist dann auch das noch nicht restlos geklärte PHP 7.2 gelöst. Meine betreute Nachbarschaft wir zukünftig nur noch 1 mal im Jahr ein Update in der Anwendung Kopano erhalten. Das Betriebssystem und die benötigte Rahmensoftware ( bei uns Apache, MariaDB, fail2ban, Spamassassin, postfix etc. ) werden per auto-update aktuell gehalten. Faktisch entspricht das genau deiner Lösung. So ab Herbst bin ich, nach einem langen Sommerurlaub, wahrscheinlich auch in der Lage zu sagen auf welchen Nightly-Build ich unsere Installationen jeweils fixe. Kann ja bei der Auswahl auf deiner Seite nicht schaden.

Immer ein Licht bei der Nacht
Der Frickler@Home

 

[Tosoboso]

HIer die Erläuterungen und Danke fürs Nachfragen..

1) ..wenn ich das richtig verstanden habe läuft es jetzt so: Alle K4S-User die bereits lizensiert mit einer Seriennummer arbeiten, können die K4S 1.01 einsetzen. Die Übrigen betreiben eine K4S die auf der Community Edition..

Nein zu 1), Anders: Auch Ohne SNR kann die Stable Default für "Home User" verwendet werden und lediglich für die Supported latest & greatest benötigt man eine Subscription mit SNR. Man kann also ohne Subscription im Schnupper und Privat Modus mit einer Tested Stable starten, die etwas älter ist; ein pragmatischer Ansatz mit / von Kopano. Power User, Firmen und überzeugte Anwender sollten aber eine Subscripton machen und die Supported benutzen, die kosted weniger als 100€ für 5 User im Jahr (siehe z.B. https://www.etes.de/kopano/kopano-editionen/)

2).. Seit dem Core 8.70.81 und höher laufen diese Community-Cores aber nicht mehr ausreichend stabil für ein SPK.. Also bietest du für einen stabilen SPK Einsatz eine Default / Stable Version an..

Jain zu 2) Ich konnte die 8.7.82 Community wieder stabil ans Laufen bekommen, nachdem ich u.a. ALLE init.d Daemon Skripte (/etc/init.d/kopano-*) überarbeitet hatte; Kopano pflegt dies Vorgehensweise seit ca. 1 Jahr nicht mehr; (systemd friss oder reverse engineere). Natürlich gibt es auch so immer mal Überraschungen mit dem Nightly Builds, daher der Ansatz mit Kopano, eine ältere geteste Stable in K4S zur Verfügung zu stellen (ähnlich zu Zarafa 4 Home).

3).. Um auf diesen Default / Stable (K4S 1.01) zu kommen muss man mit Hilfe der K4S 1.01beta zunächst sein System "normalisieren" und downgraden (wie oben beschrieben)

Genau zu 3)..Ich Prüfe gerade, ob ich das Automatisieren kann mit einem Skript kopano4s-downgrade, was dann Folgendes macht: 1) >kopano4s-backup (Datenbank-Dump als Notfall Plan, wenn das Skript nicht durchläuft) 2) >kopano-backup (brick level, wenn es noch kein User backup gibt bricht es ab mit Hinweis fahre bitte 1x backup vorher, um die Laufzeit zu verkürzen). 3) Umschiessen der Edition auf Default in der package.cfg, Leeren der Datenbank, Reset mit >kopano4s-init refresh (das Ersetzt den Un-Install, remove Database / Re-Install Default Stable wie Oben) 4) >kopano4s-restore-user all (das Importiert alle User, man könnte bereits mit dem System arbeiten und man muss die Passwörter für die User Ändern

4)..Für alle die neu mit dem Thema K4S starten empfiehlst du die K4S 1.01...

Genau zu 4,) Neutsart mit der K4s 1,0,1 Stable SPK und Default Edition. Hinweis am Rande: es gibt nun auch ein Skript: kopano4s-migration-zarafa, mit dem man in die Default Edition über Umweg der Migration Edition ein Zaraf / Zarafa4h Überführen kann, ohne mehrfach Un-Install Re-Install. Alles was man braucht, ist der aktuelle Zarafa Backup im Verzeichnis /volume1/kopano/backup oder eine Zarafa(4h) parallele Installation auf der gleichen Synology, die wird dan nerkannt eun ein Zarafa-Backup gezogen. Das Skript arbeitet u.a. mit User Export und Import und kann die Vorlage für kopano4s-downgrade sein. - Kurz eine Migration von Synology Zarafa nach Kopano gibt es jetzt wiederholbar und automatisiert.. Für Power-User kann man sogar die Zarafa(4h) Datenbank von Synology-1 repliziert in Sync halten mit einer Datenbank auf Ziel Synology-2 (=>kopano4s-replication), auf der dann Kopano läuft. Dan nkann man mit dem Skript kopano4s-migration-zarafa die Ziel-Migration immer wieder durchspielen. -Wer mehr über dieses Zarafa Migrationsverfahren wissen will sollte sich bei mir melden..

5)..Auch ich habe mit den Nightly-Builds (vor allem die Core-Komponenten) meine Probleme und deshalb unsere Installationen auf Core 8.70.80 eingefroren.. Statt nun täglich irgendwelche Böcke zu suchen...

Ja zu 5.) willkommen in der Leidensgemeinschaft, Man muss die Community natürlich im Auge behalten, wegen der Änderungen, die sich anbahnen, aber sollte es nicht den End-Usern antun. Insofern die Lösung mit der Default Old Stable, die ihc dem Nightly Build Einfrieren vorziehe...
-TosoBoso

 

[FricklerAtHome]

@Tosoboso

ich habe nun mit dem "Schwenk" meiner bisherigen VM von Debian 9.6 auf Debian 10 Buster begonnen. Erstaunlicherweise funktioniert dies sehr viel trivialer als das Upgrade von Debian 8 auf Debian 9.
Nach den Erfahrungen (Frickelei) hat sich aber auch mein Upgrade Verhalten verändert. Was ich diesmal gemacht habe? Ich habe Buster "light" (also die reine Netzwerkinstallation ohne Grafische Benutzeroberfäche) in einer neuen VM installiert. Danach habe ich alle benötigten Pakete (unkonfiguriert) nachinstalliert. In meinem Fall: Apache2, postfix, z-push, MariaDb, fetchmail, fail2ban, amavis-new, spamassassin, ufw etc.
Kopano wird in der von mir benötigten Komplexität ( Core, Webapp, MDM, Files ) als internes Repository vorbereitet (nochmal super Danke an dich und Felix) und ist dann ebenso mit mit apt-get update / upgrade und install verfügbar.
Bis auf den Kopano-Core und Postfix laufen bereits alle Dienste (jedoch noch nicht in der benötigten Konfiguration). Ein erster Hieb war der Umstand im Repo-Bau das Files noch nicht für Debian 10 existiert. Musste ich anpassen, geht jetzt aber.
Bis zu diesem Zeitpunkt habe ich noch keine individuellen Config Dateien bzw. Einträge in /etc/... durchgeführt. Das kommt jetzt. Die neue VM und die produktive Kopano VM können über eine gemeinsame Netzfreigabe kommunizieren. Einfach die alten Config Dateien und bzw /etc/ Einträge nach in die neue VM kopiert. Dann die Benutzer-Konten (Attachments im File-System) mit Kopano-Mittel und entsprechend den Tips von Felix importiert. Was soll ich sagen: "läuft bei mir!" Ist die VM so wie jetzt fertig, probiere ich alle paar Wochen die aktuellen "Nightly Builds". Funktioniert einer nicht wird halt die VM per Snapshot zurückgesetzt (das meinte ich mit Einfrieren).
Dein SPK Build ist wirklich gut und stable, was ich mache ist auch eigendlich außerhalb der Spezifikation "Synology Pakete". Ich werde hier weiter mitlesen / Testen und kommentieren. Denn soweit weg voneinander sind wir in den Aufgaben nicht.

Immer ein Licht bei der Nacht
Der frickler@home

 

[XaverMuc]

Hallo TosoBoso,

erst mal vielen Dank für die Bereitstellung des Kopano4s Pakets. Ich habe bisher Zarafa auf einer DS411slim benutzt und will umsteigen auf Kopano4s. Da ich bisher mit der Beta-Version experimentiert habe, wollte ich - wie von Dir beschrieben - auf K4S Default migrieren. Leider komme ich beim Restore, so wie Du es beschrieben hast, nicht ganz weiter:

3. Stable-Default Installieren mit frischer Datenbank und alle User Importieren via >kopano4s-restore-user all.

Das Skript kopano4s-restore-user finde ich nicht in der K4S Admin GUI (K-Cmds) und über die SecureShell erhalte ich die Meldung "Command not found". Was mache ich falsch? Bzw. wo muss die Anweiung eingeben?

Gruß
Xaver

 

[Tosoboso]

Hi XaverMuc,
wenn du noch auf Zarafa bist, dann ist kein Downgrade nötig, sondern stattdessen eine Migration mit dem passenden Skript (s.o.Punkt 4 auf F@Hs Fragen in Eintrag #4 https://www.synology-forum.de/showt...tion-Downgrade&p=831578&viewfull=1#post831578).
Aber du wirst wohl zum Umstieg auf Kopano4s die Synology wechseln müssen (du hast ne ARM aber bruachst Intel-CPU =>https://github.com/SynoCommunity/spksrc/wiki/Architecture-per-Synology-model)
Also: 1) zarafa-backup auf Quell Synology Auführen. 2) Kopano4s Default auf der Ziel-Synology installieren 3) zarafa-dump auf die Ziel Synology rüberkopieren nach /volum1/kopano-backup 4) Skript starten: >kopano4s-migration-zarafa
Ich empfehle das Migrations-Skript via Synology Aufgabenplaner (Task-Manager) als einmaligen Task zu planen unter dem User Root und es dann Auszuführen, das verhindert den Frust, wenn die Migration in ssh-Konsolen Timeout Läuft.
Ich empfehle auch auf der Ziel-Synology alle User vor der Migration Anzulegen. Das Automatische Anlegen als Teil des Skripts >kopano4s-rstore user all funktioniert noch nicht optimal (im nächsen Release behoben); der Import aber ist fein.

PS: kopano4s-restore-user ist absichtlich nicht in der GUI hinterlegt, denn es sollte von der Kommandozeile via ssh Shell bzw. als Planned Task ausgeführt werden. Wenn der Befehl nicht gefunden wird, es ist ein Softlink in /usr/local/bin auf: /var/packages/Kopano4s/scripts/addon/kopano4s-restore-user.sh
-TosoBoso

 

[Tosoboso]

Achtung: Probleme beim Downgrade via User Export

Hallo zusammen,
bitte erstmal vom Downgrade Community / Supported auf Default wie beschrieben Abstand nehmen. Weitere Tests von mir haben ergeben, dass Export der User Kopano 8.7x via kopano-backup und Import in Kopnao 8.6.9 (Default) zu Problemen führt beim Import der Attachments. Irgendwas ist da nicht kompatibel und zwar nicht nur in der Datenbank, sondern auch in kopnao-mapi-backup. Damit bleibt wohl m.W. nur der Export / Import via pst und Outllok als zuverlässige Lösung.
-TosoBoso

 

[Andy+]

.... zum Umstieg auf Kopano4s die Synology wechseln müssen (du hast ne ARM aber bruachst Intel-CPU =>https://github.com/SynoCommunity/spksrc/wiki/Architecture-per-Synology-model)......

Vielleicht sollte das am Speicherort der beiden SPK präzisiert werden, denn da steht, dass alle Plattformen verwendet werden können. Wobei zB. auch die Intel basierte DS3617xs nicht gehen soll. Freilich schwer zu testen alles.

 

[Tosoboso]

Kopano4S hat die Abhängigkeit zum Docker Paket und das Docker Paket hat wiederum alle Plattformen gepflegt. Damit wird k4s NUR für Docker fähige Synologys mit X64 angeboten (die oben genannte Box ist eine x86 ohne Virtualisierung), denn es muss erstmal Docker installiert sein. Bei der manuellen Installation am Mechanismus angebotene Pakete vorbei moniert k4s wenn Docker fehlt. -Works as designed. Es wäre auch unnötiger Aufwand im k4s SPK die Plattformen immer nach zu pflegen. Das macht ja Synology für Docker schon. Ansonsten ist die X64 und Docker Abhängigkeit im Wiki und schon in der Paketbeschreibung erwähnt.
-TosoBoso

 

[Tosoboso]

bitte erstmal vom Downgrade auf Default wie beschrieben Abstand nehmen. Weitere Tests von mir haben ergeben, dass Export der User Kopano 8.7x via kopano-backup und Import in Kopnao 8.6.9 (Default) zu Problemen führt ..

Hi, die neue Version K4S unterstützt nun den Downgrade. Ich musste u.A. die Default Version auf 8.7.1.0 heben, damit kopano-backup auf allen Versionen identisch läuft. Man muss zerst die neste beta k4s 1.02b Einspielen, dann 1x >kopano-backup Ausführen, dann >kopano4s-downgrade und man ist auf der Default Version. Danach kann man die beta mit SPK Upgrade durch das Stable Paket Austauschen. Wenn es Probleme während des Downgrades ibt, dann nochmals die Beta Version installieren und mit >kopano4s-backup restore timestamp die Datenbank-Sicherung Einspielen, die als Fallback erstellt wurde.
-TosoBoso

 

[sky63]

Hallo zusammen,

ich bin ein bisschen verwirrt. Angeblich soll bei mir eine Version 0.98 laufen. Und wenn ich das richtig sehe soll das wohl auch eine Beta sein, obwohl ich bei den Einstellungen für die Paketquellen Beta garnicht ausgewählt habe.
Laut k4s-Admin ist Kopano4S Community_base-8.7.80_Web-3.5.3_Push-2.4.5 installed!

Wie kann ich denn jetzt zuverlässig herausfinden welche Version ich habe und wie ich auf die stable(aktuell 1.03?) update?

danke und gruss,
sky

 

[Andy+]

Dann klären wir mal auf.

Die Angabe im Paketzentrum für Beta-APPs gilt nur für Synology-APPs, jedoch nicht für Drittanbieter. Bei K4S gab es bis zur V0.9.9 nur Beta, da rein von der ungeschriebenen Gesetzmässigkeit bei der Softwareprogrammierung alles was < v1 ist, ohnehin als Beta gilt. Ab v1.0.1 gab es sowohl Beta, als auch Stable, insofern ebenso konforme Zustände.

Nun zum Wechsel. Wenn Du ein Update von v0.9.8 auf v1.0.3 machen möchtest, empfehle ich Dir wegen der Umstellung der Verzeichnisstrukturen bei v0.9.9 auf v1.0.0 eine Neuinstallation, da ich bezweifle, dass das Update dies richtig umstellen kann. Ausgeschlossen ist das jedoch nicht, ich habe es nicht getestet, da ich bis jetzt ohnehin immer neu installiert habe. Erst jetzt von v1.0.1 auf v1.0.2 und auf v1.0.3 habe ich das als Update erledigt und zudem als Neuinstallation getestet und das lief auch alles glatt.

Wenn Du trotzdem updaten und nicht neu installieren möchtest, einfach testen, vorher jedoch ein Backup nicht vergessen.

 

[sky63]

Hallo,

erstmal danke für die Antwort.

Auch eine Neuinstallation ist für mich insofern ein Update als das der Zielzustand ja sein muss das sämtlicher Inhalt erhalten bleiben muss. Dazu gehören dann auch die Anhänge die bei mir schon seit Ewigkeiten im Filesystem liegen. Wenn ich richtig gelesen habe ändert sich sowohl die DB Struktur als auch das Filesystem. Und da fehlt mir gerade der Migrationspfad. Der Weg über PST-Dateien kann ja allenfalls ein Notnagel sein.

gruss,
sky

 

[Andy+]

In diesem Falle kannst Du auch ein Backup des Filesystems machen, dann die v0.9.8 deinstallieren, indem Du alles löschen lässt, bis auf die Datenbank. Nach Installation der v1.0.3 speicherst Du das Filesystem wieder zurück an den passenden Ort. Ich weiss nicht mehr, welches Image die v0.9.8 verwendet hat, das steht ja im WebAdmin. Wenn die Coreversion < v8.7.1.0 wäre, dann könntest Du auch gleich zur Stable wechseln, anstatt zur Beta mit v8.7.82. Die Versionsunterschiede sind

mit K4S SPK v1.0.3 Beta : C-Core-8.7.82_Webapp-3.5.9_Z-Push-2.5.1_WMeet-0.29.5

mit K4S SPK v1.0.3 : D-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1_WMeet-0.29.5

damit also nicht so sehr weit auseinander.

 

[sky63]

Wenn sich die Verzeichnisstrukturen bei der v1.0.0 verändert haben kann ich doch nicht einfach das den Inhalt des Filesystems wieder zurückschieben. Oder meintest du du dabei nur das Attachments-Verzeichnis?
Hat sich an der DB Struktur nicht auch was verändert? Dann kann die doch nicht bleiben.

*wieder verwirrt*

gruss,
sky

 

[Andy+]

Das Attachments-Verzeichnis gibt es weiterhin, ich meine sogar mit der gleichen location, und sollte diese anders sein, wird das in der Datenbank auch angepasst. Ich kann mir nicht vorstellen, dass das ein Problem ist. Ansonsten hilft nur testen.

 

[sky63]

So, nach dem Wochenende kann man sich wieder mit den unwichtigen Dingen beschäftigen.

"Testen" ist ja nicht wirklich ein Migrationspfad. Und wenn sich sowohl in der DB Dinge ändern als auch in der Verzeichnisstruktur und es dann auch noch heisst das die älteren Versionen die Attachments in der DB gespeichert haben obwohl Verzeichnis aktiviert war(was aber definitiv nicht stimmt, ich hab die Attachments schon immer im Filesystem) dann bin ich wieder da das mir nicht ganz klar ist wie denn die Migration stattfinden soll. Wie sieht denn da der geplante Weg aus?

Vom Weg aus Post 1 wird in Post 8 wieder abgeraten. Den Weg aus Post 11 verstehe ich in sofern nicht, als das mir nicht klar ist wie ich eine beta k4s 1.02b einspielen kann. Wo soll ich die denn herholen wenn ich auf cphub nur noch die 1.04 angeboten bekomme? Kann ich die 1.04 nehmen?
Abgesehen davon ist mir Post 11 einigermaßen unklar. Wenn ich Post 1 richtig verstehe ist "stable" = "default". In Post 11 heisst es nach einem kopano4s-downgrade ist man auf "default" (=stable?) und danach kann man die beta durch stable (=default?) austauschen. Was bedeutet denn in dem Zusammenhang austauschen? Was muss ich machen um das Paket auzutauschen(falls das denn überhaupt notwendig ist weil ja nach kopano4s-downgrade ja möglicherweile schon stable erreicht ist)?

Fragen über Fragen

Dazu kommt das ja ein Backup der Daten möglicherweise nutzlos geworden ist wenn ich z.B. die Version 0,98 lösche, die aber möglicherweise gar nicht mehr installieren kann(weil ich sie ja nirgendwo mehr bekomme). Das würde dann möglicherweise bedeuten ein Restore der kompletten Synology, auch nicht schön weil groß.

gruss,
sky

 

[Andy+]

Abgesehen von Post 8 gibt es inzwischen die D-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1_WMeet-0.29.5, in welcher Fehler behoben sind. Klar ist auch, dass Du auch die v1.0.4b nehmen kannst. Nach dem Downgrade wird dann nach meinem Verständnis nur die v1.0.4 drüberinstalliert.

Wieviel Postfächer hast Du denn und wie gross ist Deine Datenbank?

 

[sky63]

....Wieviel Postfächer hast Du denn und wie gross ist Deine Datenbank?

Ist alles nicht die Welt, hängt nur Familie dran, sind also lediglich 4 Postfächer. Größe weiss ich nicht, aber die sind teilweise uralt.

gruss,
sky