Cloudron

  • Was empfiehlst du denn, Ryker ?


    Die Wartung/Pflege spielt natürlich immer eine sehr große Rolle. Sowohl die Joomla Schulhomepage zeigt mir regelmäßig ein paar Zeilen SQL Fehlermeldung an, ist sicher nicht so angedacht, als auch die Seite des hess. Kultusministeriums (Drupal) zickt manchmal rum (direkte SQL Fehlermeldungen kamen hier glaube ich nicht).

  • Die Idee finde ich eigentlich interessant, nur die Unterscheidung zwischen Standard- und Premium-Apps kann ich nicht nachvollziehen, und die damit einhergehende Preisverdopplung.


    Standard-Apps sind dann sowas wie LAMP, Nextcloud, SOGo, openVPN und Gogs, welche ich auch kostenlos installieren kann (bis zu 2 halt oder ich zahle 15$/Monat). Sobald ich aber Gitlab will, soll ich direkt 30$/Monat (excl. VAT?) bezahlen =O

    Wobei der gefühlte Administrative Aufwand für Gitlab (und damit auch die Komplexität der Scripte von Cloudron ?) nicht sonderlich hoch ist, da sind andere Standard-Apps wesentlich komplexer, von daher erschließt sich mir nicht der Grund dieses krasses Preisunterschiedes. An der Funktionalität kann es nicht liegen, Gogs ist eine Standard-App und "die" alternative zu GitLab.


    Interessantes Konzept, für mich aber erst einmal preislich unattraktiv sofern man nicht 20 Apps hosten will. Ist aber auf jeden Fall spannend zu Verfolgen wo das ganze hin geht :) Bisher gibt es ja noch nicht so viel Apps, aber wenn dann noch Dinge wie Seafile, InfluxDB/Prometheus/Grafana etc. nachkommen, könnte man damit sicherlich einiges an Aufgaben erledigen.

  • Hi, co-founder von Cloudron hier. Ersteinmal vielen Dank fuer das Feedback!


    Zu den Punkten:


    - Inwiefern suggeriert die installation landing page, dass die netcup DNS API integriert ist? Wir werden diese aber hinzufuegen sobald Anfragen dazu kommen. So sind auch die bisherigen hinzugefuegt worden.


    - Das base image ist in der Tat relativ "alt", allerdings wird es auch nur erneuert wenn wirkilch Bedarf besteht. Es dient das ausschliesslich dazu Platz auf der disk zu sparen, da Docker images relativ schnell sehr gross werden koennen. Durch diesen Ansatz werden die Programme und Bibliotheken geteilt und nicht immer wieder neu installiert. Zusaetzlich flatten wir die entstehenden layer weiter im base image, was den Speicherverbrauch weiter minimiert (zb apt caches). Im Bezug auf Datenbanken (wie mongodb) sollte noch erwaehnt werden, dass Cloudron eine addon Architektur hat https://cloudron.io/developer/addons/ . Datenbanken werden ausserhalb der einzelnen apps gemanaged und je nach Bedarf zu dem jeweiligen app container gelinkt. Keine der Datenbanken oder Daemons sind so von aussen zugaenglich. Sie laufen mit den apps zusammen in einem separaten lokalen Netzwerk, jede app bekommt eigene, rotierbare credentials.


    - Das System an sich, sowie docker, unbound, nginx (als reverse proxy), ... werden durch Cloudron platform releases upgedated, oft verwenden wir dabei nicht die offiziellen Ubuntu Pakete, sondern explizit die Versionen die wir benoetigen. Der Hauptgrund hierfuer ist, dass uns ein stabiles System wichtiger ist als neue aktuelle Features. Der Ubuntu auto-updater kann dadurch nicht benutzt werden, auch weil wir solche updates nicht testen koennen, dazu kommen eigene apt mirrors der vps provider, welche nicht immer ideal sind. Als Beispiel dafuer kann man Postgresql nehmen, welches durch die letzten updates, von apps wie Wallabag und Owncloud noch nicht unterstuetzt werden/wurden. Sicherheits updates werden natuerlich automatisch eingespielt.


    - Welchen Aspekt des Email Servers siehst du in dem Fall als unzureichend oder fehlerhaft?

    Gerne beantworte ich weitere Fragen.


    Johannes

  • - Welchen Aspekt des Email Servers siehst du in dem Fall als unzureichend oder fehlerhaft?

    Ich glaub mit dem E-Mail Server bezog sich eher auf z.B. den Thread hier: E-Mails gehen nicht durch - Fehlermeldung "Block List"


    Microsoft blackholed immer wieder (besonders gerne?) netcup IPs was für Probleme sorgt, völlig unabhängig davon ob der Mailserver professionell eingerichtet ist (DMARC, SPF, gültige Certs...) oder nicht. Entblocken etc. bringt nicht immer was, endlose Geschichte... unbedarfte Nutzer kommen dann vielleicht nicht direkt dahinter dass das Problem nicht bei ihnen, sondern an Microsoft liegt und wundern sich warum die Mails nicht ankommen und melden sich dann hier ;)

  • Gerne beantworte ich weitere Fragen.

    Gibt es Pläne auch Seafile und Grafana/InfluxDB/Mosquitto (oder sonst einem MQTT Broker) zu integrieren? Ersteres als "Dropbox" Ersatz (Owncloud/Nextcloud ist mir persönlich zu langsam bei richtig großen Ordnern), zweiteres als Monitoring-Lösung?


    Wird euer Preismodell erst einmal so bleiben, sodass Gitlab oder sonstige "Premium-Apps" unumstößlich eine Premium-Lizenz erfordern? Gerade Gitlab benutze ich persönlich oft und hab das auch auf einigen Servern im Einsatz, weil es recht pflegeleicht ist und unendlich Features bietet (und damit quasi jeden Wunsch erschlägt). Nur wenn man auf 3 Kunden-Servern jeweils Gitlab hat ist man ja direkt bei Preisen wo man die Server auch selbst pflegen kann :(

  • Gibt es Pläne auch Seafile und Grafana/InfluxDB/Mosquitto (oder sonst einem MQTT Broker) zu integrieren? Ersteres als "Dropbox" Ersatz (Owncloud/Nextcloud ist mir persönlich zu langsam bei richtig großen Ordnern), zweiteres als Monitoring-Lösung?

    Wir paketieren apps je nach Nachfrage unserer User (siehe https://forum.cloudron.io/category/5/app-wishlist) oder wenn die app Entwickler direkt auf uns zu kommen. Ob wir mehr in Richtung Entwicklertooling wie Grafana/... als "app" gehen wissen wir noch nicht, aber auch hier richten wir uns hauptsaechlich an der Nachfrage danach. Somit vielen Dank fuer das Bekunden des Interesses daran.


    Am Preismodel wird sich vorerst nichts aendern, wir sind der Ansicht der Preis ist im Vergleich zum Zeitaufwand bei manuellen app updates fair. Premium apps sind hauptsaechlich die, welche relativ viel Aufwand beim Update erfordern (installation/data migration/tests/plugin update/testing....) Wir versuchen allerdings in den jeweiligen app Kategorien in beiden Sektionen apps zu haben (zb Gogs/Gitea vs. GitLab)

    Desweiteren contributen wir ueber die Subscription auch zu den apps (als ein Beispiel https://gitlab.com/commento/commento/merge_requests/87 )

  • Hallo Johannes,


    - Inwiefern suggeriert die installation landing page, dass die netcup DNS API integriert ist? Wir werden diese aber hinzufuegen sobald Anfragen dazu kommen. So sind auch die bisherigen hinzugefuegt worden.

    Beim Install-Script kann zwischen mehreren Providern gewählt werden (netcup, O*H, h*tzner, generic etc.)

    Hier kann eine Gedankengang sein, dass auch Domains von Netcup vollumfänglich unterstützt werden.


    Im Bezug auf Datenbanken (wie mongodb) sollte noch erwaehnt werden, dass Cloudron eine addon Architektur hat https://cloudron.io/developer/addons/ .

    Ein Blick in das Dockerfile verrät, dass es sich bei "Mongo" im Baseimage wirklich nur um den Shell Client handelt, und nicht um den DB Daemon selbst.

    Die Challenge-Response Mechanismen haben sich im Versionssprung von 2 auf 3 geändert, sodass es nicht möglich sein wird mit 2.x Clients auf >3.x Server zuzugreifen.


    Das System an sich, sowie docker, unbound, nginx (als reverse proxy), ... werden durch Cloudron platform releases upgedated, oft verwenden wir dabei nicht die offiziellen Ubuntu Pakete, sondern explizit die Versionen die wir benoetigen.

    Kann ich daraus Schlussfolgern, dass sich cloudron ähnlich tief in das System eingräbt wie z.B. Plesk?


    Welchen Aspekt des Email Servers siehst du in dem Fall als unzureichend oder fehlerhaft?

    DKIM, DMARC, SPF (DNSSEC, CAA) sind alles Features die im DNS eingetragen werden müssen.

    Wenn diese Einträge nicht gegeben sind, werden E-Mails von anderen Providern gerne abgelehnt.

    Wenn nun die Netcup DNS Api fehlt, ist es mit ein wenig Aufwand verbunden dies zum Laufen zu bringen.

    Aufwand, der für die Zielgruppe dieser Systeme recht schwierig umzusetzen ist.


    - Paul

  • Ein Blick in das Dockerfile verrät, dass es sich bei "Mongo" im Baseimage wirklich nur um den Shell Client handelt, und nicht um den DB Daemon selbst.

    Die Challenge-Response Mechanismen haben sich im Versionssprung von 2 auf 3 geändert, sodass es nicht möglich sein wird mit 2.x Clients auf >3.x Server zuzugreifen.

    Wie gesagt, Datenbanken werden nur upgedated, wenn auch die apps die neue Version unterstuetzen und wir dies auch wirklich als notwendig fuer unseren use-case sehen.

    Kann ich daraus Schlussfolgern, dass sich cloudron ähnlich tief in das System eingräbt wie z.B. Plesk?

    Das kann man so sagen. Unser Ziel ist, dass der Benutzer niemals SSH Zugriff benoetigt und auch so sollten keine zusaetzlichen Pakete oder services installiert werden, da dies getestete Updates unmoeglich macht.


    DKIM, DMARC, SPF (DNSSEC, CAA) sind alles Features die im DNS eingetragen werden müssen.

    Wenn diese Einträge nicht gegeben sind, werden E-Mails von anderen Providern gerne abgelehnt.

    Wenn nun die Netcup DNS Api fehlt, ist es mit ein wenig Aufwand verbunden dies zum Laufen zu bringen.

    Aufwand, der für die Zielgruppe dieser Systeme recht schwierig umzusetzen ist.

    Allerdings, fuer Nameserver die noch nicht automatisch unterstuetzt werden, prueft das Cloudron dashboard ob die email relevanten records korrekt sind und zeigt die genauen Daten dann auch an, welche manuell gesetzt werden sollen. Aber wie gesagt, wenn weitergehendes Interesse von Usern oder netcup direkt besteh, werden wir auch die API mit einbinden.

  • Ist geplant Joomla als APP aufzunehmen?

    Ich habe vor einer Woche auf dem CloudFest mit einigen Joomla Entwicklern darueber gesprochen, allerdings ist Joomla mehr eine Framework als eine eine konkrete app. Fuer solche Faelle haben wir eine LAMP stack app, mit der man derartige php apps installieren kann. Speziell unser naechstes platform release wird dafuer weitere Unterstuetzung mitbringen (zb verbesserten SFTP Zugriff auf Daten innerhalb der isolierten apps) Mehr dazu kann auch unter https://forum.cloudron.io/topic/1725/cloudron-3-6-new-plans gefunden werden.

  • Zitat

    Aber wie gesagt, wenn weitergehendes Interesse von Usern oder netcup direkt besteh, werden wir auch die API mit einbinden.

    Seitens netcup besteht Interesse. Der von unserer Seite zur Verfügung stehende Ansprechpartner ist ja bekannt :)

  • Ich habe vor einer Woche auf dem CloudFest mit einigen Joomla Entwicklern darueber gesprochen

    Ich tue mir offengestanden etwas schwer mit dem sinnerfassenden Lesen Deiner Anworttexte. (Umlaute, Artikel, Kleinschreibung von Eigennamen und Hauptwörtern).


    Was Joomla anbelangt, so ist es richtig, dass der Framework-Charakter in den letzten Versionen gestärkt worden ist. Der „Use Case“ von Joomla ist aber weiterhin, ein CMS, das sich insbesondere auch selbst updaten kann, zu sein. In dieser Hinsicht -die Entwickler werden das eventuell nicht gerne hören - ist es nicht anders als Wordpress.


    Welche Anwendungsszenarien sind konkret für diesen „LAMP app stack“ vorgesehen? Welche interaktiven Anpassungen sind dabei überhaupt möglich?

    Unser Ziel ist, dass der Benutzer niemals SSH Zugriff benoetigt und auch so sollten keine zusaetzlichen Pakete oder services installiert werden, da dies getestete Updates unmoeglich macht.


    Dieser an sich ja nutzerfreundliche Zugang birgt meines Erachtens Risiken, an denen schon andere Entwickler gescheitert sind:

    1. Getestete Updates bedeuten stets eine Zeitverzögerung beim Ausrollen. Auch, wenn die Container isoliert sind, macht mir das in Hinblick auf Zero-Day-Exploits Sorgen, denn die Daten innerhalb eines „LAMP app stacks“ werden naturgemäß so abgreifbar sein.

    2. Wie verhält es sich mit Auto-Update/Self-Update-Funktionen, wie sie zahlreiche Web-Apps heute mitbringen? Diese konterkarieren getestete Updates ohnehin.