Kritik bzgl. Ende des Self-Hostings

andrea.schulz

@michaelg da ist ein super Tipp. Das kann man ja auf jeden Fall machen wobei der Churchtools Finder auch vielen sehr weiterhilft.

teleharry

Liebes ChurchTools-Team,

vor über 7 Jahren haben wir ChurchTools in unserer Gemeinde eingeführt. Hier gab es insbesondere kontroverse Diskussionen mit Geschwistern zum Datenschutz. Letztlich hat die Möglichkeit der Datenresidenz in Form eines Selfhosters uns dazu verholfen für viele kritische Stimmen einen Kompromiss zu finden. Wir betreiben den Server in unserer eigenen Gemeinde neben anderen Diensten. Dabei nutzen wir Verschlüsselung auf Filesystemebene, um selbst beim Einbruch/Diebstahl vorbeugen zu können. Bei einem Datenleck oder Schwachstelle in dem nunmehr nur noch zentralistisch möglichen Hosting durch Hetzner ist das Angriffspotentiel durch die geteilte übergreifende Umgebung auf alle Churchtools-Nutzer enorm.

Die Argumentation, daß viele Installationen nicht aktualisiert werden, oder unqualifizierte Supportanfragen hohen Aufwand generieren mag durchaus nachvollziehbar sein. Dennoch geiselt die daraus nun entstandene Entscheidung kein SelfHosting mehr anzubiten alle potentiell vorbildlich betriebene Umgebungen als SelfHoster.

Zu vielen Themen gibt es auch weniger radikale Lösungen, zum Beispiel:

Die Bereitstellung von ChuchTools ausschließlich als Container wie es bei vielen Anbietern allmählich zum Standard wird. Hier existiert auch geringere Streuwirkung von Fehlern durch das Gastsystem oder Fehler in der Bereitstellung. Natürlich erhöht dies auch die Komplexität aber damit wird es auch umso wahrscheinlicher, daß die Lösung entsprechend qualifiziert betrieben und zum Support zugearbeitet werden kann.
Auch sollte es ein leichtes sein deutliche Hinweise bis zu Funktionseinschränkungen für alte und nicht unterstützte Versionen global einblenden zu lassen oder gar Supportanfragen über die Churchtools-Oberfläche davon abhängig zu gestalten.
Wenn Supportaufwendungen bei SelfHoster tatsächlich höher sind, könnte man dies auch in unterschiedlichen Preisen umlegen.

In Summe reift hierzu vielmehr die persönliche Einschätzung, daß durch die enge Verzahnung zwischen einem Webhoster (Hetzner) und Churchtools darüber hinausgehende strategisch wirtschaftliche Ziele verfolgt werden.
Das an sich allein ist auch durchaus in Ordnung, es ist nur traurig daß dabei so wenig Rücksicht auf Nutzer in Minderheit genommen wird, da es sich nach wie vor um eine Lösung für christliche Einrichtungen handelt.

Meine Hoffnung bleibt hierbei noch einmal zu einem transparent und allseitig dienlichen Lösungsprozess anregen zu können.

Viele Grüße und Gottes Segen

sirdud

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

Zum Thema eigene Domain:

Ich würde argumentieren, dass eine eigene Domain bei CT nicht nötig ist. Für eine Webseite ist das etwas anderes, aber wenn man ein Tool einer Firma nutzt ist es ziemlich normal, dass dieses nicht unter der eigenen Domain läuft. Di meisten User wissen am Schluss eh nicht welche Domain sie gerade nutzen und was eine Domain überhaupt ist.
Eine Weiterleitung der alten auf die neue Domain für Rückwärtskompatibilität ist natürlich sinnvoll. Die Lösung mit dem Proxy ist nicht optimal, aber die Alternative dazu ist, dass wir Zertifikate für eure Domains ziehen müssen und das macht unsere Infrastruktur wieder komplizierter und Fehleranfälliger für ein Feature, das wenig gewünscht wird und aus meiner Sicht nicht wirklich nötig ist.

Wo ist das Problem mit dem Ziehen der Zertifikate? Es gibt genug Scriptbeispiele zum automatisierten Zertifikatshandling z.B. mit LetsEncrypt. Klar, es ist natürlich viel einfacher mit nur einem Wildcard Zertifikat für *.church.tools zu arbeiten. Da hat man mit den Zertifikaten für die Subdomains nichts mehr am Hut... Aber den riesen Supportauffwand dürfte das nicht darstellen

Klar, ich kann die User die mit der Website arbeiten per Redirect auf meinegemeinde.church.tools weiterleiten. Was ist aber mit den Usern, die die App nutzen? Da dürfte die Weiterleitung nicht funktionieren, oder?

Wie ich unseren Datenschutzkritikern antworten soll, dass zukünftig dann die Daten aller Mitglieder und Freunde der ChurchTools Kunden Gemeinden an einer zentralen Stelle von einem Unternehmen gehostet werden und damit dann Hackern oder wem auch immer auf dem Silbertablett zur Verfügung gestellt werden, weiß ich nicht. Ein Stichwort dass in dem Zusammenhang gefallen ist, war Christenverfolgung... Da gehen mir dann ehrlich gesagt auch die Gegenargumente aus.

Da wir als Gemeinde tatsächlich ChurchTools momentan nur für die Besetzung von Aufgaben während der Gottesdienste nutzen, sowie Kalender und Ressourcenverwaltung, stelle ich mir ernsthaft die Frage, ob wir uns nicht doch eine Alternative überlegen sollten. Vor unserer ChurchTools Zeit hat das auch funktioniert...

Andi 1

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

@davidschilling sagte in Kritik bzgl. Ende des Self-Hostings:
Ein Stichwort dass in dem Zusammenhang gefallen ist, war Christenverfolgung...

Das war/ist bei uns vereinzelt auch ein Thema.

narnitz

Disclaimer: Ich schreibe hier jetzt nicht als ChurchTools Mitarbeiter sondern als ehrenamtlicher CT Admin und Betreiber der IT Infrastruktur meiner Kirchengemeinde!

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

Wo ist das Problem mit dem Ziehen der Zertifikate? Es gibt genug Scriptbeispiele zum automatisierten Zertifikatshandling z.B. mit LetsEncrypt. Klar, es ist natürlich viel einfacher mit nur einem Wildcard Zertifikat für *.church.tools zu arbeiten. Da hat man mit den Zertifikaten für die Subdomains nichts mehr am Hut... Aber den riesen Supportauffwand dürfte das nicht darstellen

Zwei Punkte zur Automatisierung aus Sicht von mir:

Eine jede Automatisierung muss auch zur restlichen Infrastruktur eines Gesamtsystems kompatibel gemacht und gehalten werden -> Mit einem 0815 Certbot ist es also vermutlich nicht erledigt
Wenn man dann eine der Infrastruktur kompatiblen Automatisierung gebaut hat, hat man noch ein Problem: Die Endnutzer. Ja, nicht jeder Endnutzer ist wie unten beschrieben. Aber leider sind die Supportkontaktaufnahmen nach meinen Erfahrungen bei einem ehemaligen Arbeitgeber, meist wie folgt:

"Was ist dieses DNS?"
"Ja und wo muss ich diesen 'A-record' denn jetzt anlegen?"
"Seit gestern ist die Website nicht mehr erreichbar" "Es sieht so aus, als wäre Ihre Domain ausgalaufen" "Oh, ja das haben wir gekündigt :)"
[...]
Ergo: Ein riesen Support Aufwand (zumindest nach meiner Erfahrung).

Klar, ich kann die User die mit der Website arbeiten per Redirect auf meinegemeinde.church.tools weiterleiten. Was ist aber mit den Usern, die die App nutzen? Da dürfte die Weiterleitung nicht funktionieren, oder?

In der App müssten die Benutzer entweder die *.church.tools URL angeben, oder man müsste die Redirect Funktionalität noch implementieren.

Wie ich unseren Datenschutzkritikern antworten soll, dass zukünftig dann die Daten aller Mitglieder und Freunde der ChurchTools Kunden Gemeinden an einer zentralen Stelle von einem Unternehmen gehostet werden und damit dann Hackern oder wem auch immer auf dem Silbertablett zur Verfügung gestellt werden, weiß ich nicht. Ein Stichwort dass in dem Zusammenhang gefallen ist, war Christenverfolgung... Da gehen mir dann ehrlich gesagt auch die Gegenargumente aus.

Ich hatte in meiner Gemeinde auch schon ähnliche Diskussionen. Meist sind aber genau diese Leute ganz vorne bei der Nutzung von Office 365 o.ä. dabei.
Insgesamt ist auch die Frage: "Benutzt du WhatsApp oder Facebook?" ein gutes Totschlagargument.

Ebenfalls habe ich die internen IT-Dienste von mehreren Kirchengemeinden gesehen und da ist von Sicherheit oft leider nur wenig die Rede. Von Webspaces mit Standardpasswort bis hin zu 'JesusIstUnserHerr2002' (nur ein erfundenes Beispiel) oder einer komplett fehlenden .htaccess Datei (inkl. Datenbankzugangsdaten im Klartext ) habe ich da schon einiges zu Augen bekommen.
Dementsprechend würde ich hier die Wahrscheinlichkeit höher sehen, "Daten auf einem Silbertablett" vor zu finden.

Und letztendlich verstehe ich nicht ganz , warum es für bestimmte "Datenschutzkritiker" einen großen Unterschied macht, ob der PHP Code von CT nun auf einem von CT, 1&1 oder einem Hobby-Admin verwalteten Server läuft.
Ist 1&1 oder der Feld-Wald-Wiesen-Shared-Webhost nicht ebenfalls eine gewinnorientierte Firma?

All in all kann ich als Ehrenamtlicher Admin bei uns sagen: Ich bin heidenfroh, das ich mich um einen Dienst weniger kümmern muss und für einen Dienst weniger sicherstellen muss, dass personenbezogene Daten DSGVO-konform gespeichert, gesichert und ggf. wieder gelöscht werden.
(Okay, dieser Punkt liest sich vielleicht etwas Paradox, weil ich Befruflich an der App arbeite, aber ich denke Ihr versteht was ich meine ^^)

Andi 1

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

Und letztendlich verstehe ich nicht ganz , warum es für bestimmte "Datenschutzkritiker" einen großen Unterschied macht, ob der PHP Code von CT nun auf einem von CT, 1&1 oder einem Hobby-Admin verwalteten Server läuft.

Ich sehe schon einen gewissen Unterschied. Sofern man ein Interesse an möglichst vielen persönlichen Daten von Christen hat (warum auch immer), ist es doch wesentlich attraktiver, den/die CT-Server anzugeifen und auf einen Schlag tausende Daten zu erhalten (inkl. hunderte Daten von Leitern), als sich mit jeder Gemeinde einzeln zu beschäftigen.

Oder anders ausgedrückt: bevor ich versuche 1000 Leuten 100 Euro zu stehlen, sprenge ich lieber einen Geldautomaten in die Luft.

Auch wenn CT um ein Vielfaches sicherer als die eigene Webseite ist (über WhatsApp und Co brauchen wir nicht sprechen), sehe ich ebenfalls die größte Gefahr darin, dass eben so viele schützenswerte Daten an einem Ort gespeichert sind.

aschild

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

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

Und letztendlich verstehe ich nicht ganz , warum es für bestimmte "Datenschutzkritiker" einen großen Unterschied macht, ob der PHP Code von CT nun auf einem von CT, 1&1 oder einem Hobby-Admin verwalteten Server läuft.

Ich sehe schon einen gewissen Unterschied. Sofern man ein Interesse an möglichst vielen persönlichen Daten von Christen hat (warum auch immer), ist es doch wesentlich attraktiver, den/die CT-Server anzugeifen und auf einen Schlag tausende Daten zu erhalten (inkl. hunderte Daten von Leitern), als sich mit jeder Gemeinde einzeln zu beschäftigen.

Oder anders ausgedrückt: bevor ich versuche 1000 Leuten 100 Euro zu stehlen, sprenge ich lieber einen Geldautomaten in die Luft.

Auch wenn CT um ein Vielfaches sicherer als die eigene Webseite ist (über WhatsApp und Co brauchen wir nicht sprechen), sehe ich ebenfalls die größte Gefahr darin, dass eben so viele schützenswerte Daten an einem Ort gespeichert sind.
Das mit dem "Cloud is sicherer" oder "Grosse haben mehr Ressourcen zum Abwehren von Angriffen" wurde ja letztens ganz schön als Marketing BlahBlah entlarvt.

Bei Microsoft kam ja einer der Hauptschlüssel abhanden, so dass die Angreifer in sehr sehr viele MS Dienste eindringen konnten(können?).

Die Absolute Sicherheit werden wir nie haben, aber Shared Cloudlösungen sind halt ein lohnenswerteres Ziel als Einzelinstallationen...

narnitz

@andi-1

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

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

Und letztendlich verstehe ich nicht ganz , warum es für bestimmte "Datenschutzkritiker" einen großen Unterschied macht, ob der PHP Code von CT nun auf einem von CT, 1&1 oder einem Hobby-Admin verwalteten Server läuft.

Ich sehe schon einen gewissen Unterschied. Sofern man ein Interesse an möglichst vielen persönlichen Daten von Christen hat (warum auch immer), ist es doch wesentlich attraktiver, den/die CT-Server anzugeifen und auf einen Schlag tausende Daten zu erhalten (inkl. hunderte Daten von Leitern), als sich mit jeder Gemeinde einzeln zu beschäftigen.

Oder anders ausgedrückt: bevor ich versuche 1000 Leuten 100 Euro zu stehlen, sprenge ich lieber einen Geldautomaten in die Luft.

Auch wenn CT um ein Vielfaches sicherer als die eigene Webseite ist (über WhatsApp und Co brauchen wir nicht sprechen), sehe ich ebenfalls die größte Gefahr darin, dass eben so viele schützenswerte Daten an einem Ort gespeichert sind.

An diesem Punkt muss man sich meiner Meinung nach eine Kosten/Nutzen Analyse und Gedanken über OpSec (Operations Security) machen.
Das heißt: Inwiefern dürfen wir irgendwelche Daten von Christen bei cloudbasierten SaaS (Software as a Service) Anbietern speichern? Und da fällt z.B. die Landeskirche Baden sofort schon einmal raus, weil die z.B. Office 365 benutzen....

Bei unserer Gemeinde sind wir zu diesem Thema zum Schluss gekommen: Die Nutzen, die wir aus CT als Softwareplatform ziehen, sind größer als die Risiken (Datenschutz) die wir dabei eingehen und es ist unseren Gemeindegliedern lieber, das Ihre Daten auf deutschen Servern von einer Firma direkt um die Ecke (Karlsruhe) gespeichert und geschützt werden.

Andi 1

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

Bei unserer Gemeinde sind wir zu diesem Thema zum Schluss gekommen: Die Nutzen, die wir aus CT als Softwareplatform ziehen, sind größer als die Risiken (Datenschutz) die wir dabei eingehen

Sehe ich persönlich ja genauso
In diesem Thread geht es aber nicht um den Vergleich CT vs. MS 365, sondern um den Unterschied zwischen "CT auf einem zentralen Server" oder "CT auf einem eigenen / auf verteilten Servern". Und in diesem Punkt gehe ich mit, dass das Risiko enorm steigt, je mehr Daten gebündelt gespeichert werden. Die CT Server werden als Angriffsziel umso attraktiver, je mehr Gemeinden dort zu finden sind.

narnitz

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

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

Bei unserer Gemeinde sind wir zu diesem Thema zum Schluss gekommen: Die Nutzen, die wir aus CT als Softwareplatform ziehen, sind größer als die Risiken (Datenschutz) die wir dabei eingehen

Sehe ich persönlich ja genauso
In diesem Thread geht es aber nicht um den Vergleich CT vs. MS 365, sondern um den Unterschied zwischen "CT auf einem zentralen Server" oder "CT auf einem eigenen / auf verteilten Servern". Und in diesem Punkt gehe ich mit, dass das Risiko enorm steigt, je mehr Daten gebündelt gespeichert werden. Die CT Server werden als Angriffsziel umso attraktiver, je mehr Gemeinden dort zu finden sind.

Ich verstehe bei dieser Diskussion beide Seiten zu einem gewissen Grad.

Jedoch muss ich aus Sicht eines CT Mitarbeiters (welcher keine Ahnung von den wirtschaftlichen Dingen etc. hat, nur von der IT Infrastruktur und Entwicklung) auch sagen, dass ich den Standpunkt von CT auch sehr gut verstehe. Supportaufwand, zukünftige Features werden schwieriger zu implementieren die über den Standard PHP Webspace hinaus gehen, man müsste aufwändige Checks implementieren um überhaupt Fehlermeldungen sauber anzeigen zu können und ich weiß nicht ob sich dieser Aufwand eben für einen sehr kleinen Anteil an Installationen lohnt.

milux

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

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

Wo ist das Problem mit dem Ziehen der Zertifikate? Es gibt genug Scriptbeispiele zum automatisierten Zertifikatshandling z.B. mit LetsEncrypt. Klar, es ist natürlich viel einfacher mit nur einem Wildcard Zertifikat für *.church.tools zu arbeiten. Da hat man mit den Zertifikaten für die Subdomains nichts mehr am Hut... Aber den riesen Supportauffwand dürfte das nicht darstellen

Zwei Punkte zur Automatisierung aus Sicht von mir:

Eine jede Automatisierung muss auch zur restlichen Infrastruktur eines Gesamtsystems kompatibel gemacht und gehalten werden -> Mit einem 0815 Certbot ist es also vermutlich nicht erledigt

Wenn man dann eine der Infrastruktur kompatiblen Automatisierung gebaut hat, hat man noch ein Problem: Die Endnutzer. Ja, nicht jeder Endnutzer ist wie unten beschrieben. Aber leider sind die Supportkontaktaufnahmen nach meinen Erfahrungen bei einem ehemaligen Arbeitgeber, meist wie folgt:

"Was ist dieses DNS?"

"Ja und wo muss ich diesen 'A-record' denn jetzt anlegen?"

"Seit gestern ist die Website nicht mehr erreichbar" "Es sieht so aus, als wäre Ihre Domain ausgalaufen" "Oh, ja das haben wir gekündigt :)"
[...]
Ergo: Ein riesen Support Aufwand (zumindest nach meiner Erfahrung).

Wieso nicht? Was soll denn bitte die "restliche Infrastruktur des Gesamtsystems" in diesem Fall sein?
Alle Zertifikate, die ich aktuell auf den CT-Servern sehe, scheinen von Let's Encrypt zu kommen. Vermutlich kommt bereits Certbot oder ein vergleichbares Tool zum Einsatz, um sie automatisch zu erneuern.
Die weitergeleitete Domain könnte man easy mit der guten alten HTTP-01-Challenge (https://letsencrypt.org/docs/challenge-types/#http-01-challenge) validieren. Keine DNS-Spezialitäten oder sowas wären erforderlich.
Also ich bin absolut bei @sirdud, mir erschließt sich dieses Argument nicht im geringsten.

narnitz

@milux

Naja, man müsste in die Infrastruktur Mechanismen einbauen um sauber die DNS Einstellungen der eigen genutzten Domains zu checken, dann Benachrichtigungen falls diese nicht mehr passen.

Denn damit die HTTP-01 Challenge funktioniert, muss der DNS setup auch passen…
Das dann die Aquirierung eines Zertifikats eher trivial ist, ist mir klar.

Naja, es ist halt im Schnitt vermutlich erheblich mehr Support Aufwand diese DNS Geschichte unter Kontrolle zu halten.
Klar, für uns erschließt sich das super easy, aber das ist nicht für alle so.

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?

Weil sonst wird es vermutlich wirtschaftlich schwer rechtfertigbar für vergleichsweise sehr wenige Kunden einen vergleichsweise hohen Mehraufwand dauerhaft zu haben…

Aber das müsstet Ihr dann mit dem Support klären

milux

@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?

milux

@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.

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.