Kopano4S (Zarafa 2.0)

[Andy+]

Werden die Tabellen überhaupt angelegt?

 

[pcmartino59]

ja diese werden angelegt

 

[pcmartino59]

@tosoboso
Wenn man mich fragen würde , würde ich sagen: wenn ein lauffähiges Package am Start ist sollte man alles zusammenlegen und ein hauptpackge zur Verteilung bereitstellen. So hätte man kein Stress mehr mit der source. Die jeder anpackt. Wäre das nicht eine Idee?

 

[Andy+]

Hast Du das auf allen DS?

 

[pcmartino59]

Ja eine ist die produktive und die anderen zum testen ob es läuft.
Aber auf allen außer der produktiven hat es geklappt. Hatte gedacht aus meinen vergangen Fehlern gelernt zu haben aber es sind anscheinend nicht genug Test Maschinen

 

[Andy+]

Die Frage ist nach den Plattformen, da nicht gesagt ist, dass alle funktionieren. Allerdings nehme ich mal an, dass die v0.8.3 auf dem Produktivsystem bereits gelaufen ist. Insofern solltest Du mal in den Tiefen des Systems nach Resten der v0.8.5 suchen und diese löschen, bevor Du neu installierst.

 

[pcmartino59]

Habe die komplette ds auf den Kopf gestellt. Die packendes alle Dinst. Und alles neu inst. Von Pearl bis dB... ist immer das gleiche.
Wenn ich eine neue ds konfiguriert bei einer neu inst. DS ist das Problem von Anfang an präsent. Bin schon soweit eine ds zum testen für tosoboso bereitzustellen wenn es ihm helfen sollte.

 

[Andy+]

Also hat Kopano noch nie darauf funktioniert. Welche DS ist das?

 

[pcmartino59]

Die ds ist eine ds918+ auf dieser ist z4h und auch Kopano bis jetzt prod gelaufen. Das Update hat auch funktioniert. Aber da ich wie du auch alles lösche und dann das packet neu sauber inst. Ist dieser Fehler aufgekommen.

 

[Tosoboso]

Bin schon soweit eine ds zum testen für tosoboso bereitzustellen wenn es ihm helfen sollte.

Hi, ich hab wie man an der Signatur erkennt genug DSen zu Testen, vDSM nicht eingerechnet. Das Problem ist Zeit für Regressiontests und neue Überaschungen von der Community Beta Nightly Build, die ich erst im nächsten Build berücksichtigen kann, was in der Urlaubszeit logischerweise länger dauert Ist eben Kopano Beta.. Das Supported Paket funktioniert 'astrein'. Insofern: ich kann nicht alle Überaschungen der Nightly Build Beta sofort adjustieren und empfehle dem Zarafa / Kopano Liebhaber eine Kopano Base Subscription zu ~80€ (ich hab etes.de als Reseller gewählt).
EDIT
Zurück zum Thema Test-DS: Felix Bartels (fbartels) könnte eine gebrauchen, um Synology Details nachvollziehen zu können und mit vDSM ist das technisch vertetbar möglich, man muss 'nur' einen sauberen DMZ Gast Lan Modus aufsetzen.
-TosoBoso

 

[Andy+]

Hast Du mit der DS918+ ein Update durch? Weil das könnte auch einen Einfluss haben.

 

[pcmartino59]

Alle sind auf dem neusten stand

 

[Tosoboso]

@tosoboso, wenn ein lauffähiges Package am Start ist sollte man alles zusammenlegen und ein hauptpackge zur Verteilung bereitstellen. So hätte man kein Stress mehr mit der source. Die jeder anpackt.

Grundsätzlich d'acord, die Tücke liegt in der Logistik und die Planunung zur Optimierung hab ich schon benannt; das kommt im nächsten Release nach den Sommerferien.
Logistik: 1) Docker Hup läuft auf meinem TosoBoso Account und da gilt das Highlander Prinzip (Uploads nur von mir). Docker Automated Builds sind nicht möglich, denn dann müsste jemand seine SNR sichtbar machen für die Supported Edition. Da das ist nun mal ein Dual-Package ist, geht das nicht. Die SNR im Docker Image nicht zu 'exposen' war übrigens nicht trivial....
2) Das k4s SPK durchläuft ein Review bevor es auf dem Community Package Hub sogniert bereitgestellt wird, was 0.5-2 Tage dauert und völlig OK ist, aber damit ist das Docker Image zum Laden festgelegt.
Lösung: Entkoppeln des k4s SPK von den Docker Images, indem einfach das neuste Docker Image geladen wird statt dem konfigurierten zum Zeitpunkt der Erstellung des SPK. Das bedarf ein wenig Skripting inkl. Resillance (kein Image älter als das im SPK), aber hey.. Im aktuellen Problemfall könnte eine neue k4s SPK das pasende Docker Image laden und erst im worst case in den locally build package by nightl build zurückfallen. Wenn also ein Problem auffällt, kann ich entweder eine neues Docker Image hochladen und das alte Löschen, oder erstmal nur das alte Löschen und das Vorgänger Docker Image wird geladen. Das Alles setzt natürlich vorraus, dass alle Images und SPKs kompatibel sind und dieser stabile Zustand stellt sich jetzt langsam ein. Hoffe das hilft als Ausblick.
-TosoBoso

 

[pcmartino59]

Das hilft wirklich ein Licht am Ende vom Tunnels. Ich habe auch nur soviel ds‘s hier stehen damit ich testen kann. Damit wäre es für mich en ersparniss an Geräten die bei mir auf Standby sind. LOL auf jedenfalls ist das alles ein top Job tosoboso danke für Einsatz hier

 

[pcmartino59]

habe mir gerade eine liz gekauft.... bin gespannt ob es klappt

 

[Dufooy]

@tosoboso
Wie immer, danke für Deinen Einsatz...
Ich würde mir auch eine Lizenz kaufen, alleine um kopano was zurück zu geben...
Frage dazu, sind dort Plugins, wie Files und Webmeetings drin?
Gruß D. udn einen schönen Urlaub nebenbei

PS: Wir könnten ja auch mal sammeln und fbartels eine Syno zukommen lassen...so als Ide

 

[Andy+]

Ich habe nun von der v0.8.3 ein Update gemacht auf v0.8.5. Das hat auch funktioniert, jedoch bleibt der Container derselbe, wie zur v0.8.3 und läuft.

 

[Andy+]

In der WebAPP steht im Teil Einstellungen aber dann "WebApp: 3.4.15.1490+852.1", dagegen das Dockerimage scheint die v3.4.14 vorzuhalten.

 

[pcmartino59]

Also hat zwar etwas Zeit gekostet aber ich habe es zum fliegen gebracht. Inst. 0.83 dann starten Kopano nach dem ersten Abbruch im docker das Abbild und den Container löschen. Packes wieder starten dauert etwas länger aber docker erstellt alles neu und es läuft

 

[Andy+]

Dann scheint das ein Timeoutproblem gewesen zu sein. Hattest Du mal versucht, das Image vorzuladen und dann die Installation des SPK´s zu starten?