Kopano4s auf GitHub - Entwickler-Ecke

[Tosoboso]

Hallo zusammen,

ich habe Kopano4s nun auf Github gestellt unter https://github.com/TosoBoso/Kopano4s und mit entsprechendem Aufwand die Strukturen, Files etc. in der Readme beschrieben.
Es würde mich Freuen, wenn an dieser Stelle / diesem Post so etwas wie eine Entwickler Ecke ensteht mit Fragen, Anregungen, Einlesen in die Struktur etc. und Frickel Fragen sind ausdrücklich ok (=>F@H).
Ihr könnt natürlich auch den Quelltext von GitHub Clonen und Push Requests stellen; ich halte es aber für hilfreich, wenn wir Diese hier besprechen und Denke da ist erst noch die Hürde zu überwinden, das Paket zu verstehen.

EDIT Bei der Gelegenheit möchte ich darauf verweisen, daß man Kopano4S 'modden' kann, ohne gleich auf GitHub Erweiterungen zu Pushen: Im Verzeichnis /etc/custom befinden sich 2 Dateien: postbuild.sh und dpkg-add, die nach jedem Contaier Build / Reset aufgerufen werden. In der ersten Datei kann man beliebige Kommandos packen, ggf. zusätzliche Plugins Nachladen und in der zweiten Datei kann man Debian Pakete angeben, die Nachgeladen werden (ein Bespiel: vim-tiny). In der dpkg-add muss man natürlich den passenden Paket-Namen wählen (siehe https://packages.debian.org/search).
Dieser Schritt wird übrigens vor Postbuild.sh ausgeführt, so das man dort nachgelagerte Konfigurations-Schritte machen kann.

-TosoBoso

 

[FricklerAtHome]

@Tosoboso

Glück Auf

Bin erst heute auf die "EntwicklerEcke" gestossen. Super Sache! Da werde ich mich mal vertieft einlesen. Aktuell frickel ich weiter an einer 2 Faktoren Authentifizierung und fail2ban.

Wird aber noch etwas dauern bis ich "Frickel-Fragen" oder Anregungen haben. Danke für die vertiefende Quelle!

Gruss Der Frickler@Home

 

[Andy+]

An der Stelle einmal die Frage, ob es Potential gibt, für DS-Plattformen, die etwas "holprig" sind, so wie scheinbar die DS3617xs. Wie könnte dazu eine angepasste Lösung aussehen?

 

[FricklerAtHome]

Hallo Andy+

ich vermute du erwägst einen entsprechenden Zukauf / Austausch in Richtung ds*17. Mein Tip zu diesem Thema: "Hör dir das Ding vollbestückt zuerst an!" Die dicken Dinger sind deutlich lauter als deine DS1815. Ich musste bei kontinuierlichen Lärmbeschwerden meiner besseren Hälfte erstmal eine geräuschgedämmte Unterbringung finden.

--- immer ein Licht bei der Nacht
Der Frickler@Home

 

[Andy+]

Das glaube ich gerne, alle DS´n aber im Keller, daher kein Thema.

 

[FricklerAtHome]

@Tosoboso

Herzlichen Dank für deine Arbeit! Da hast du wirklich ein dickes Brett gebohrt.
So langsam habe ich mich eingelesen. --- Direkter Nutzen für mich: Ich habe beim Password-Addon nun auch die Verion 1.5 laufen, die Fetchmail-Integration der WEB-APP werde ich zumindest in der betreuten Nachbarschaft vorstellen. Bisher machen wir das im "OLD-STYLE". Fail2Ban habe ich ebenso zentral über APACHE gelöst. Hier habe ich keine GUI. Der Kopano-Admin bekommt eine E-MAIL. Für Korrekturen etc muss er ins Terminal. ---- Da bei mir ein PRTG-Monitor läuft, der Fail2Ban bei Kopano und nextCloud abfragt und "grafisch" darstellt haben wir an deinen Weg gar nicht gedacht.
Im Script Common in Zeile 414 steht K_SPAMD="OF". --- Müsste das nicht K_SPAMD="OFF" heißen?
Ansonsten ist es schon viel zu lesen und zu verstehen, grundsätzlich geht das aber gut. Aktuell versuche ich genau zu begreifen welchen Ubuntu18.04 Anteil du in die Community Version einschleußt. Grundsätlich habe ich das verstanden, ich suche aber noch nach einigen Details.

Schöne Ostertage und ....

--- immer ein Licht bei der Nacht
Der Frickler@Home

 

[FricklerAtHome]

Z-push 2.5.0

@TOSOBOSO

Ich habe heute mal wieder mein Kopano incl. Z-Push und Debian 9 "upgedatet". Soweit lief es zunächst unauffällig. Jedoch kamen Probleme mit Z-PUSH auf 2.5.0. In der /usr/lib/php/.. wurde nach z-push.log keine mapi.so gefunden. Die von z-push vorgeschlagene Lösung z-push-admin -a fixstates führte zum gleichen Ergebnis. Innerhalb von Kopano (Mail, WebApp etc.) läuft alles. Kopano ist auch intern vollkommen ok, sogar der Zugriff per Z-Push von aussen funktioniert. Aber was das Senden oder empfangen von Mails geht noch nicht. Weder über die Phones nach innen oder nach aussen, noch über die WebApp. ---- Beim Update wurde auch ziemlich viel bei Postfix und seiner Einbindung "erneuert".

Das Problem tritt bei mir bei einem Update in der VM von Core 8.7.80:926 auf 8.7.80:936 (Z-Push ist in der 926 noch auf 2.4.5) auf. --- Ich werde also da mal "nach"-frickeln!
Produktiv wie immer kein Problem. Vor dem update Snapshot, nach dem update Snapshot zurückgesetzt. -- Alles Gut.

nur als Erfahrungswert!

Glück Auf --- und immer ein Licht bei der Nacht
Der Frickler@Home

 

[FricklerAtHome]

Update zur Letzten Meldung:

Scheinbar war ich nur zu ungeduldig. Jetzt läuft alles trotz merkwürdiger Rückmeldung währen des Updates. Debian 9 hat bei mir den Kernel, MariaDB inklusiv aller Anbindungen an Postfix etc, und noch etlich andere Pakete erneuert.
Nach dem obligatorischen Reboot, hat es nur erheblich länger gedauert bis alle Dienste wieder syncron liefen. Somit als weitere Info der gestrige Muttertags-Build läuft.

Der Frickler@Home

 

[Andy+]

Ich habe mir zur v1.0.1 vom Github die ZIP geladen und daraus eine SPK zusammenkopiert und auf meiner DS415+ installiert, es wurde dafür als Image die D-Core angezogen. Die anderen standen nicht zur Auswahl

D-Core-8.6.9.0_Webapp-3.5.0_Z-Push-2.4.5_WMeet-0.29.5
M-Core-8.4.5.0_Webapp-3.4.2_Z-Push-2.4.5
S-Core-8.7.1_Webapp-3.5.5_Z-Push-2.5.0_WMeet-0.29.5
C-Core-8.7.80_Webapp-3.5.6_Z-Push-2.5.0_WMeet-0.29.5

Leider bleibt der Container nicht stabil am Laufen. Da sind wohl noch diverse Aktionen erforderlich.

 

[Andy+]

Diesen ersten Versuch habe ich manuell zusammengesetzt. Ein Script gibt es in dem ZIP jedoch auch, aber das scheint nicht so einfach:

........./Kopano4s-master/build_spk.sh
Fakeroot is not installed; using sudo, you might need to give pwd at initial call when archive wil be build..
fatal: Not a git repository (or any parent up to mount point /volume1/Software)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: Not a git repository (or any parent up to mount point /volume1/Software)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

Also geht doch nur manuell...

 

[Andy+]

So ganz schlau werde ich nicht. Im Github gibt es neue Softwareteile, sicherlich um die seit gestern im Docker Hub geladenen Images zu laden. Aber wo wähle ich, welches Image geladen wird?

 

[FricklerAtHome]

das Script build_docker.sh fragt nach der Edition !

immer ein Licht bei der Nacht
Der Frickler@Home

 

[Andy+]

............/Kopano4s-master/build_spk.sh
Fakeroot is not installed; using sudo, you might need to give pwd at initial call when archive wil be build..
fatal: Not a git repository (or any parent up to mount point /volume1/Software)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: Not a git repository (or any parent up to mount point /volume1/Software)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set)....

Ich komme da nicht weiter. Wie, wo und in welcher Reihenfolge werden die Scripte ausgeführt, damit das hinhaut.

 

[Tosoboso]

Moin, zum Thema build_spk und build_docker von Github:
1) GIT muss installiert sein z.B. auf Synology durch Installation des Synology GIT Server Packets
2) Eigenes Repo Anlegen und dorthin Clonen: > mkdir -p ~/repo && cd ~/repo && git clone https://github.com/TosoBoso/Kopano4s
3) Zum Bauen: im Verzeichnis ~repo/Kopano4s ./build_spk.sh oder ./build_docker.sh Aufrufen.
Für build_spk.sh muss zwingend GIT installiert sein, und ein Repo existieren, sonst funktioniert es nicht. Bür build docker kann man K_EDITION exportieren, dann wird man nicht immer danach gefragt.Wenn man aber die Edition Supported, oder Migration Bauen will, braucht man eine Subskription für K_SNR.
Zur statischen Code-Analyse kann man dann check_scripts.sh verwenden, wobei man den Paramater Docker braucht, wenn shellcheck nicht Installiert ist, was auf der Synology der Fall ist. Das Ergebnis steht dann in check_scripts.out und hilft bei Fehlersuche und Sauberen Coden..
4) Zum Aktualisieren des Clones vom Gihub: im Verzeichnis ~repo/Kopano4s >git fetch origin && git pull Ausführen
Hoffe das hilft. Weiteren GIT Befehle incl. Pull Request auf das TosoBoso Repo bei eigenen Erweiterungen sollte man sich Anlesen. Hier empfehle ich das eBook: "A Practical Guide to Git and Github for Windows Users"
Ich werde weiterhin die SPKs bauen und auf dem Community Package Hub bereitstellen; die Github Variante ist nur zur Transparenz und um selbst Hand Anlegen.
-TosoBoso

 

[FricklerAtHome]

Viele Hinweise für den Paketbau stehen in der CONTRIBUTING.md

immer ein licht bei der Nacht
Der Frickler@Home

 

[Andy+]

Das von Tosoboso beschriebene, habe dort nicht realisiert. Allerdings, das manuelle Zusammenbauen eines SPK´s schon. Mein Vorgang wie folgt

- den gesamten Verzeichnisinhalt aus SPK-APP habe ich ein "package.tar" gepackt, in eine "package.tgz" gespeichert und in das Verzeichnis SPK-PKG abgelegt.
- Diesen gesamten Inhalt habe ich dann in eine SPK gepackt, welche dann im Paketzentrum installiert werden kann.

Die Installation konnte auch abgeschlossen werden, leider nur konnte kein Image gewählt werden, vor allem aber, blieb der Container nicht am Durchlaufen und stoppte irgendwann.

 

[FricklerAtHome]

Ganz stumpf: "Kann funktionieren, muss es aber nicht", wahrscheinlich auch nur selten!

Halt dich an die Git-Hub Regeln. Ansonsten wird es schwer. --- Ich konnte bereits mehrfach ein gültiges / bzw. lauffähiges SPK mit dem Git-HUB Repository bauen.

Dein Weg ist so nicht nachvollziehbar.

immer ein Licht bei der Nacht
Der Frickler@Home

 

[Tosoboso]

Das von Tosoboso beschriebene, habe dort nicht realisiert. Allerdings, das manuelle Zusammenbauen eines SPK´s schon - den gesamten Verzeichnisinhalt aus SPK-APP habe ich ein "package.tar" gepackt, in eine "package.tgz" gespeichert und in das Verzeichnis SPK-PKG abgelegt. - Diesen gesamten Inhalt habe ich dann in eine SPK gepackt, welche dann im Paketzentrum installiert werden....vor allem aber, blieb der Container nicht am Durchlaufen und stoppte irgendwann.

Hi, zu 1) SPK bauen und 2) Container Abbruch 3) Releases Stable vs. Beta 4) Tücken im Detail

1) Man kann den Container von Hand zusammen bauen, aber dann kann man gleich den package.tgz im SPK Ablegen und muss nicht noch den beschriebenen Umweg gehen mit Kopieren nach SPK-PKG. Am besten wie gesagt installiert man Git und verwendet es. Aber ich werde weiter SPKs bauen und auf CPHUB hochladen (geplant dieses WE).

3) Ich habe nun die Pakete und Images aufgeteilt, so dass die Community nur noch im Beta Paket enthalten ist. Im anderen Paket gibt es die Supported, wo eine SNR benötigt wird und nun neu eine Default Edition, die frei ist, 3-6 Monate alt, aber eben Stable und getestet, womit ein produktiver Betrieb einfacher ist.
Ganau genommen können beide SPKs immer noch Alles, aber die Auswahl ist über die Wizzard Config Datei install_uifile beschränkt. Weiterhin ist in der common Datei Release ="Stable" oder "Beta" gesetzt, damit niemand einen Upgrade Stable auf eine COmmunity Beta macht, was nicht geht da dies ein Downgrade ist. Das als Hinergrund am Rande.
Thema Downgrade: ich empfehle auf die Stable Default zu wechslen, das bedeutet aber: 1. User Exportieren mit einer laufenden Beta-Community via >kopano-backup. (nicht kopano4s-backup!) 2. Un-Install mit Datenbank Löschen, aber Kopano Volume behalten, wo ja das Backup liegt. 3. Stable-Default Installieren mit frischer Datenbank und alle User Importieren via >kopano4s-restore-user all. Bei der Gelegenheit kann man auch komfortabel auf die Option Attachements im Filesystem wechseln,
4) Die Startscripte sind tückisch und haben mich viel Zeit gekostet, bis ich wieder ein laufähiges Community Paket zusammen hatte incl. Search etc..
Kopano hatte schon letztes Jahr beschlossen, nur noch systemd zu unterstützen und init.d / start-stop-daemon nicht mehr zu unterstützen. Dann werden / wurden schrittweise die Startskrippte entfernt, oder funktionieren nicht mehr. Auf den initd Startskripten ist der Kern von K4s aufgebaut und so war das erste Zarafa4h zusammen mit Felix konzipiert. Ganz neue Überraschung: seit ca. 1 Monat 8.7.x Community Release muss man die meisten Kopano Programme mit start-stop-daemon --background zwingen zu Laufen, damit nicht alle Skripte hängen bleiben (deswegen hatte bei deinen Tests der Container gestoppt). Kein Problem für Kopano, denn in dem Kopano Docker werden andere Start-Skripte verwendet (dass systemd mit Docker nicht geht hat man dann auch gemerkt..). Kurz es ist ein Hase Igel Spiel, auf das ich eigentlich keine Lust habe. Ich werde also mittelfristig auf die Kopano Docker Bauweise Umstellen, was aber ein erhebliches Refaktoring bedeutet. Kopano-Docker siehe hier: https://kopano.com/blog/building-docker-containers-for-kopano/
Naja erstmal sollten die Pakete wieder funktionieren und hoffenltich kann ich dann meine kostbare Zeit mit Verbesserungen verbringen, statt Reverse-Enginiering.
-TosoBoso