Kritik bzgl. Ende des Self-Hostings

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz Nein, müsst ihr nicht. Wieso solltet ihr sowas tun müssen?

Wenn das DNS kaputt ist, dann muss eben die Hosting-Domain direkt genutzt werden, und gut is.
Tatsächlich regelt das LE bzw. Certbot AFAIK schon sehr vorteilhaft, denn man bekommt meines Wissens bei einer unvollständigen Validierung trotzdem ein Cert, nur sind da dann eben nur die Domains drin, bei denen es funktioniert hat.

Wenn ihr besonders cool sein wollt, könnt ihr für eure Kunden eine UI basteln, über die man (eine) eigene Domain(s) eintragen und entfernen und das Cert neu anfragen kann.
Das müsst ihr aber nicht, ihr könnt das im Fehlerfall auch einfach ignorieren.

Kannst du mir bitte nochmal erklären, wo du diesen "vergleichsweise hohen Mehraufwand" siehst?

Vorab: "Einfach die Hosting Domain verwenden" ist nicht so einfach, mit kaputtem DNS kann dabei kein Redirect etc. passieren, d.h. wenn Gemeindeglied XY jede woche churchtools.mustergemeinde.de eingebe und das plötzlich nicht mehr funktioniert kommt Gemeindeglied XY vermutlich nicht auf die Idee mustergemeinde.church.tools aufzurufen, ohne darauf hingewiesen zu werden.

Vielleicht habe ich mich etwas kryptisch ausgedrückt, sorry dafür:
Um das ganze Thema auch aus Produkt- und Kundensicht sauber abzubilden wäre genau diese UI, das du beschreibst, etwas was IMO nötig wäre.

D.h.

Es würde eine Managementoberfläche aus Kundensicht benötigen inkl. Verbindung der Zertifikatinfrastruktur und dem Backend -> Arbeitsaufwand 1
Es würde ein Monitoring benötigen für zwei Dinge (welches dann auch wieder mit dem Management und ggf. E-Mail Alerts verbunden ist)
1. Passen die DNS Records aller Installationen die eine Custom Domain nutzen?
2. Haben alle Custom Domain Instanzen ein valides Zertifikat (das ist zum Glück ein Thema das sich gut automatisieren lässt) -> Arbeitsaufwand 2

Dazu gehören dann: Produkt- und UI-Konzeption, Einplanung, Entwicklung und langfristiges maintainen dieses Features.

Und an diesem Punkt bin ich mir unsicher, inwiefern das wirtschaftlich für CT sein würde.

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

Vielleicht wäre ja ein Weg, wie bei anderen SaaS Anbietern, einen mtl. Preis für custom Domains und deren durchschnittlichen Arbeitsaufwand für die Infra und DEV Teams einzuführen?

Und nein, das ist leider keine Lösung, denn wir (und vmtl. so ziemlich alle in einer vergleichbaren Situation) betreiben CT ja nicht über eine dedizierte public suffix domain sondern als Subdomain.

Domain oder Subdomain ist technisch gesehen jetzt eher ein geringfügiger Unterschied (einziger unterschied: Subdomains können CNAME Records, was das ganze doch wieder etwas einfacher machen würde, wobei "root-domains" das nicht können), welchen Ich im Kopf schon mit dabei hatte, aber nicht aufgeschrieben hatte. Sorry dafür.
Subdomains waren natürlich auch mit vorgesehen.

milux

@narnitz Aber genau dieses Problem gibt es doch auch, wenn der Admin den Redirect via mod_rewrite, den 301-Redirect oder was auch immer vergeigt?
Und wieso sollten die Gemeindemitglieder in der Situation überhaupt euer Problem sein? Die wenden sich doch in aller Regel nicht direkt an euch, sondern an ihre Admins/GL/whatever, wodurch das ganze sowieso erst beim Sysadmin aufschlägt, der ja dann bitte hoffentlich weiß, was er verbockt hat?

Und diesbezüglich:
@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

D.h.

Es würde eine Managementoberfläche aus Kundensicht benötigen inkl. Verbindung der Zertifikatinfrastruktur und dem Backend -> Arbeitsaufwand 1

Es würde ein Monitoring benötigen für zwei Dinge (welches dann auch wieder mit dem Management und ggf. E-Mail Alerts verbunden ist)

Passen die DNS Records aller Installationen die eine Custom Domain nutzen?

Haben alle Custom Domain Instanzen ein valides Zertifikat (das ist zum Glück ein Thema das sich gut automatisieren lässt) -> Arbeitsaufwand 2

Das wäre in der Tat sinnvoll, und man könnte es direkt in ChurchTools selbst in den Admin-Einstellungen integrieren. Dann braucht man keine extra Oberfläche und vor allem keine extra Authentisierung. Entwicklungsaufwand ist vorhanden, aber überschaubar.
Sehe ich nicht so, ihr seid null in der Pflicht hier irgendwas außerhalb eurer eigenen Domain zu monitoren. Aber wenn du unbedingt meinst, dass das sein muss: Mit Uptime Kuma (https://github.com/louislam/uptime-kuma) lässt sich in 5 Minuten eine Statusseite realisieren, die das alles kann. "Aufwand 2" damit praktisch gleich null.

Das Traurige ist, dass ich eigentlich nicht mehr erwarte, dass hier von deiner/eurer Seite noch ein Einsehen kommt. Am Ende wird es vermutlich ein 301-Redirect werden, weil alles andere eigentlich Quatsch ist, insbesondere der Reverse-Proxy, den ihr offiziell kommuniziert habt.
Manchmal frage ich mich schon, ob es bei 1,7 k€ pro Jahr (für unsere Kirche allein) wirklich zu viel verlangt ist, minimalen Effort zu investieren, um den erzwungenen Umzug in eure Cloud ein wenig angenehmer zu gestalten.

milux

@narnitz Diese Antwort ergibt AFAIK keinen Sinn. Wie willst du denn eine Subdomain nebst Administration an uns verkaufen, wenn die übergeordnete Domain bei irgendeinem Provider oder Registrar rum gammelt?

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz Diese Antwort ergibt AFAIK keinen Sinn. Wie willst du denn eine Subdomain nebst Administration an uns verkaufen, wenn die übergeordnete Domain bei irgendeinem Provider oder Registrar rum gammelt?

Subdomain Kunde zeigt auf CT-Server -> CT hat zusätzlichen Aufwand wegen Management etc. -> Kunde bezahlt dafür. (Was bei anderen SaaS Produkten auch so geregelt wird)

Das war meine Idee und dabei ist es irrelevant ob es sich um eine Sub- oder normale Domain handelt.

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

Das Traurige ist, dass ich eigentlich nicht mehr erwarte, dass hier von deiner/eurer Seite noch ein Einsehen kommt. Am Ende wird es vermutlich ein 301-Redirect werden, weil alles andere eigentlich Quatsch ist, insbesondere der Reverse-Proxy, den ihr offiziell kommuniziert habt.
Manchmal frage ich mich schon, ob es bei 1,7 k€ pro Jahr (für unsere Kirche allein) wirklich zu viel verlangt ist, minimalen Effort zu investieren, um den erzwungenen Umzug in eure Cloud ein wenig angenehmer zu gestalten.

Bitte wende dich hiermit an den Support.
Ich kann da letztendlich nix tun und habe auch nur mit Vorschlägen/Erklärungen versucht die Entscheidung von CT etwas verständlicher zu Machen.

milux

@narnitz Also ist das bloß eine persönliche Meinung von dir und völlig losgelöst von dem, was deine Kollegen denken?
Es wäre etwas müßig, ein Ticket aufzumachen, wenn die Antwort ohnehin feststeht.

milux

OK, "monatlicher Preis für Custom Domain" hatte sich angehört, als wolltet ihr die Domain dann verwalten, was ja Sinn ergeben hätte.

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz Diese Antwort ergibt AFAIK keinen Sinn. Wie willst du denn eine Subdomain nebst Administration an uns verkaufen, wenn die übergeordnete Domain bei irgendeinem Provider oder Registrar rum gammelt?

Subdomain Kunde zeigt auf CT-Server -> CT hat zusätzlichen Aufwand wegen Management etc. -> Kunde bezahlt dafür. (Was bei anderen SaaS Produkten auch so geregelt wird)

Das war meine Idee und dabei ist es irrelevant ob es sich um eine Sub- oder normale Domain handelt.

Ich dachte, das würde nicht gehen, wegen zu viel Aufwand, wenn die Domain ausläuft oder die DNS-Records falsch gesetzt sind? Ja was denn jetzt?
Oder willst du damit sagen, wenn wir nochmal ein bisschen mehr Geld einwerfen (neben den 143,20 € monatlich für XL) wäre es dann doch möglich?

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz Also ist das bloß eine persönliche Meinung von dir und völlig losgelöst von dem, was deine Kollegen denken?
Es wäre etwas müßig, ein Ticket aufzumachen, wenn die Antwort ohnehin feststeht.

Was meine Kollegen denken können sie, aber müssen sie nicht hier selbst schreiben.
Aber ja, ist meine persönliche Meinung.

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

OK, "monatlicher Preis für Custom Domain" hatte sich angehört, als wolltet ihr die Domain dann verwalten, was ja Sinn ergeben hätte.

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

@narnitz Diese Antwort ergibt AFAIK keinen Sinn. Wie willst du denn eine Subdomain nebst Administration an uns verkaufen, wenn die übergeordnete Domain bei irgendeinem Provider oder Registrar rum gammelt?

Subdomain Kunde zeigt auf CT-Server -> CT hat zusätzlichen Aufwand wegen Management etc. -> Kunde bezahlt dafür. (Was bei anderen SaaS Produkten auch so geregelt wird)

Das war meine Idee und dabei ist es irrelevant ob es sich um eine Sub- oder normale Domain handelt.

Ich dachte, das würde nicht gehen, wegen zu viel Aufwand, wenn die Domain ausläuft oder die DNS-Records falsch gesetzt sind? Ja was denn jetzt?
Oder willst du damit sagen, wenn wir nochmal ein bisschen mehr Geld einwerfen (neben den 143,20 € monatlich für XL) wäre es dann doch möglich?

Ich habe es nie verneint, das es technisch möglich ist, Custom (Sub-)Domains anzubieten, was ich anzweifelte war ob es wirtschaftlich ist, eine solche Funktionalität generell oder ohne Aufpreis (analog zum Sync z.B.) anzubieten.

Was ich vorgeschlagen habe ist ein möglicher Weg. Der ist aber nur eine Idee von mir.

Wenn du da offiziell Feedback geben willst oder ein Statement haben willst, melde dich bitte beim Support.

milux

@narnitz Sorry, aber falls wir von ctldap reden, das ist ein ganz blödes Beispiel.
Diese Anwendung verbraucht quasi null Server-Ressourcen und wurde von euch mit minimalem Aufwand so erweitert, dass man mit einer einzigen Instanz beliebig viele Kunden (ergo alle) bedienen kann.
Wenn das für irgendetwas ein Beispiel ist, dann dafür, dass die CT Inno GmbH viel von der Vermarkung von FOSS profitiert, der Community aber erstaunlich wenig zurück gibt. Siehe Ende des Self-Hostings.

narnitz

@milux
Ich habe nicht von ctldap geredet, sondern den Sync als Beispiel angeführt.

Wenn du konstruktive Kritik an solchen Dingen hast, wende dich bitte an den Support.
Die können das Intern über die korrekten Wege weiter geben, sodass ggf. darüber gesprochen werden kann.

Ich werde jetzt hierzu nichts mehr sagen, weil zumindest wir zwei bei diesem Thema vermutlich auf keinen gemeinsamen Nenner kommen werden.

milux

@narnitz sagte in Kritik bzgl. Ende des Self-Hostings:

@milux
Ich habe nicht von ctldap geredet, sondern den Sync als Beispiel angeführt.

Was für einen "Sync" meinst du denn? Könntest du bitte konkreter werden?

Wenn du konstruktive Kritik an solchen Dingen hast, wende dich bitte an den Support.
Die können das Intern über die korrekten Wege weiter geben, sodass ggf. darüber gesprochen werden kann.

Das hört sich so an, als wärt ihr ein fettes Enterprise mit zigtausend Angestellten, bei dem man nicht einfach mit den Kollegen auf dem kurzen Dienstweg sprechen kann.
Nur um das klarzustellen: Ich hab absolut kein Problem damit, dass ihr ctldap für die Kunden gegen Aufpreis hostet. Wenn ihr sie, z.B. beim Einrichten von NextCloud oder dergleichen, gelegentlich supported, sind die 9 € pro Monat bestimmt gut investiert.

Danke für deinen Rat, ich werde es via Support versuchen.

Ich werde jetzt hierzu nichts mehr sagen, weil zumindest wir zwei bei diesem Thema vermutlich auf keinen gemeinsamen Nenner kommen werden.

Darauf musst du mich nicht hinweisen, du bist inhaltlich schon länger nicht mehr wirklich darauf eingegangen.

narnitz

@milux sagte in Kritik bzgl. Ende des Self-Hostings:

Was für einen "Sync" meinst du denn? Könntest du bitte konkreter werden?

Den ChurchTools Sync, mit dem man Daten zwischen verschiedenen CT-Instanzen und/oder Drittsoftwares synchronisieren kann. (Siehe z.B. im Lizenz-Tab deiner Installation)

Das hört sich so an, als wärt ihr ein fettes Enterprise mit zigtausend Angestellten, bei dem man nicht einfach mit den Kollegen auf dem kurzen Dienstweg sprechen kann.

Natürlich könnte ich das dem kurzen Dienstweg klären, aber gerade bei Produkt Fragen ist es sinnvoll, den "offiziellen" Weg zu gehen, um sicher zu gehen, das es auch passend in Planungsmeetings etc. mit rein kommt.

milux

@narnitz Da steht nix von einem "Sync".

Andrej

@milux hier ist das Sync Modul beschrieben: https://www.church.tools/de/product/sync

Und hier die entsprechenden Preise: https://www.church.tools/de/pricing

milux

@andrej Ah, gut, danke. Hab das sicherlich mal irgendwo erwähnt gesehen, aber es jetzt an den erwarteten Orten einfach nicht mehr gefunden.

sctech

Bisher hatte ich hier still mitgelesen, nun melde ich mich auch zu Wort. Einige Beweggründe für diese Umstellung verstehe ich – einiges bereitet mir aber "Bauchschmerzen" und ich kann den kritischen Stimmen absolut beipflichten. Mit meinem Post hier teile ich lediglich (ergänzende) Gedanken.

Für uns war die Möglichkeit des Self-Hostings mitunter der Grund, warum wir uns vor einigen Jahren für ChurchTools entschieden hatten. Auf dem Markt gibt es viele gute Church Management Tools – das Self-Hosting war/ist aber ein Alleinstellungsmerkmal von ChurchTools - jedenfalls in der Liga.

Ich wage mal zu behaupten, dass ein Grossteil der Self-Hosting-Kunden noch aus Zeiten der Community Edition (v2.x) stammt und gerade diese Gruppe heute auch die meisten Supportaufwände generiert. Bestellt aber heute jemand ChurchTools in der Self-Hosting-Variante (was ja gar nicht mehr offensichtlich geht), sind das wohl eher Profis, die explizit nachfragen und was vom Handwerk verstehen bzw. auch ein Anliegen zum Thema Datenschutz/Datensicherheit haben. Die Installation erfolgt dann nicht auf einem gewöhnlichen Webspace. Die technischen Anforderungen umzusetzen, liegt vollumfänglich in der Verantwortung des Self-Hosters und für Support bzgl. der Installation könnte ggf. auch eine Gebühr erhoben werden. Die grossen Anbieter machen es vor: Im Umfeld von Enterprises sind On-Premise-Lösungen nicht wegzudenken.

Dann gibt es eine weitere Hürde: Für einige Kirchgemeinden könnte nun ChurchTools als Option entfallen, weil Daten mit Behörden ausgetauscht werden und diese wiederum ein Self-Hosting erfordern (Thema Datenstandort).

Idee (wurde oben schon mal erwähnt): Warum für ChurchTools nicht ein offizielles Docker Image anbieten, womit die Konfigurationsparameter direkt von ChurchTools beeinflusst werden können?

Insgesamt habe ich mich nun aber bereits darauf eingestellt, dass ChurchTools in die zentrale Cloud geht. Ich schätze auch den verantwortungsbewussten Umgang von ChurchTools zum Thema Datenschutz.

Dann möchte ich auch kurz auf die Sache bzgl. Domain eingehen. Für mich ist es wichtig, die eigene Domain weiterhin zu nutzen, nach Möglichkeit natürlich ohne Proxy (Nachteile wurden genannt).

In meiner Gemeinde stellen wir alle Applikationen je unter einer eigenen Sub-Domain zur Verfügung. Dazu folgende Anmerkungen aus der Praxis:

Es entsteht ein einheitliches Bild (Branding).
Das Muster xyz.meinegemeinde.com ist einprägsam. Ja, die Leute tippen auch heute noch Domains "von Hand" ein.
Heute ist man sensibler geworden und gerade kritische Personen schauen genauer hin. Beispiel: Würde mich eine Bank fürs Login zum E-Banking auf eine externe URL weiterleiten, wäre ich erstmal kritisch. Vielleicht ist der Vergleich zu extrem - aber bei ChurchTools geht es immerhin um die zentrale Drehscheibe aller Personendaten.

So würde ich mir also auch eine direkte Implementierung inkl. Bezug des SSL-Zertifikats wünschen. Meiner Ansicht nach könnte dies auf Sub-Domains beschränkt werden, sodass ein einfacher CNAME-Eintrag ausreicht. Als Beispiel: Die Church Online Platform macht vor, wie einfach dies für den Benutzer geht - sogar kostenlos. Apropos "kostenlos": Ich wäre bei ChurchTools sogar dazu bereit, einen kostenpflichtigen Lizenzzusatz für die eigene Domain zu bezahlen.

@milux du hast dich mit deinem Anliegen an den Support gewendet? Gibt es neue Erkenntnisse daraus?