Beiträge von cloudron

    Ok zumindes bei mir habe ich nun den Fehler gefunden. Es ging überhaupt nicht einfach aus der Dokumentation unter https://ccp.netcup.net/run/web…endpoint.php#Dnsrecordset hervor. Das Problem war nicht der record an sich, sondern das zusätzliche property dnsrecords


    Soweit ich das vom PHP code her gelesen habe, fehlt auch dort dieses.

    Ich habe das selbe Problem. Ich versuche die DNS Automatisierung für Cloudron zu bauen und dabei habe ich nun schon alle möglichen DNS record Kombinationen probiert. Immer mit dem gleichen "The DNS records are not in valid format." Fehler.


    Es ist für mich auch nicht ganz ersichtlich von der Dokumentation, ob man immer alle DNS Einträge mit jedem "updateDnsRecords" Aufruf angeben muss oder nur die, welche geändert werden sollen.


    Unabhängig davon allerdings, selbst mit einer leeren Zone, finde ich nicht die richtig Kombination an JSON properties um nur einen einfach A record anzulegen. Wäre gut wenn jemand ein erfolgreiches Beispiel posten könnte.


    Danke.

    Das stimmt, Joomla ist leider immer noch nicht geplant. Vor Allem auch weil PHP apps wie joomla extrem schwierig sind Updates anzubieten, da Plugins und auch user oft zu stark ins System eingreifen. Wir werden allerdings, wie auch bei WordPress, eine Lösung erarbeiten sobald auch Joomla von mehr usern angefragt wird, das war bisher noch nicht der Fall.

    Version 4.1 bringt hauptsächlich Verbesserungen bei Verwaltung der Applikationen mit.


    Zur besseren Übersicht wurde der Konfigurationsdialog überarbeitet. Man kann nun allen Apps im Dashboard eigene Icons geben, sowie seit Version 4 eigene Labels und Tags.

    Auch kann man nun beliebig viele Redirect Domains pro App konfigurieren.


    Alle Verbesserungen kann man im Blog nachlesen: https://cloudron.io/blog/2019-06-21-cloudron-4.1.html

    Hallo netcup Community!


    Wir haben im Laufe der letzten Woche Version 4 von Cloudron veröffentlicht. Details dazu gibts im Release Blog Post


    Eine kurze Übersicht über Neuerungen:

    • Isolierter SFTP Zugang zu App Daten
    • App Tags und Labels - dies vereinfacht vor Allem das wiederfinden von Apps wenn viele installiert sind
    • Vereinfachter Email Import zur Migration
    • Zeitnahe App Update Benachrichtigung
    • Datensicherung, welche für ein App Update gemacht worden sind, werden länger vorgehalten um ein spätes Rollback zu ermöglichen.
    • Community/Unstable Apps. Dies ermöglicht schnelleres Testen von neuen Apps
    • Unterstützung von Email Relays ohne Authentication (meist IP range restricted) und/oder self-signed certificates
    • Cloudron Updates können nun auch ohne Backup durchgeführt werden. Dies hilft in Situationen wo ein Update ein Backup Problem behebt.
    • Möglichkeit Email senden für eine bestimmte Domain auf Platform Level zu unterbinden

    Server, die das vorinstallierte Cloudron Image benutzen, updated sich, wie auch manuelle Installationen automatisch. Wenn nicht einfach melden.

    Sehr gerne beantworte ich Fragen dazu und freue mich über Feedback.


    Johannes

    Wie schon erwähnt, für Ghost wirst du einen eigenen vserver benötigen. Da Ghost auch im Cloudron app Katalog dabei ist, kannst du ja das Netcup Cloudron image auf einem vserver ausprobieren. Dabei hilft dir die Plattform bei der Ghost Installation und auch der kontinuierlichen Updates.

    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.

    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.

    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 )

    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