Slowly rolling-out automatic updates, but allowing manual updates immediately, seems a great idea to me.

I am strongly against replacing the server in the current OpenVPN app.

However, it totally makes sense as a new, separate, app.

@marcusquinn said in What's coming in 6.0:

If I can add File Permissions management to the Wishlist for the nice new File Manager please.

Seeing the screenshot in girish's post here (more precisely the icons of the actions on the right), I think it's already done for the next version

@ruihildt said in Why not make Cloudron fully open source again?:

I'm sad not to be able to recommend Cloudron as the best open source paas since the license change.
It has in effect changed my relation to the project, from an invested advocate to a simple client.

I totally agree with this part. More than that, I would never have picked up Cloudron at all at the beginning if it weren't open source.

And as to contributions, I am the author of one of these rare contributions ^^ (to make the platform compatible with the OpenVPN app), and I would definitely not have contributed if it were not open source.

TLDR: I am 100% in favor of switching back to an open source licence.

(As for the precise licence, I do not really care, be it MIT, Apache, GPL, AGPL ... whatever.)

@jdaviescoates I would love that too It has been awaiting review for a while You can go ahead and try it right now !

@atrilahiji I have a Dockerfile with a working build

FROM cloudron/base:2.0.0

ARG MORNIN_FM_VERSION="master"
ARG NODE_VERSION="10.22.1"

RUN mkdir -p /usr/local/node-${NODE_VERSION}
RUN curl -L "https://nodejs.org/download/release/v${NODE_VERSION}/node-v${NODE_VERSION}-linux-x64.tar.gz" \
    | tar -xz --strip-components=1 -C /usr/local/node-${NODE_VERSION}

ENV PATH=/usr/local/node-${NODE_VERSION}/bin:$PATH

RUN mkdir -p /app/code/morninfm

# copy code
ADD start.sh /app/code/

RUN curl -L "https://github.com/fox-one/mornin.fm/archive/${MORNIN_FM_VERSION}.tar.gz" \
    | tar -xz --strip-components=1 -C /app/code/morninfm

WORKDIR /app/code/morninfm

# install packages
RUN npm install yarn -g
RUN yarn
RUN yarn build

CMD [ "/app/code/start.sh" ]

This file does not rely on "forking" the original app, but rather downloads its code from the upstream github repo, to make updates easier.

Also, I have only fixed the build, I have not even tried starting the app ^^

@rmdes I don't think the rate limit is less than once every 30 minutes ^^

However, the check could indeed be done at intervals depending on the situation. Like do the check immediately when the config is changed, do it every 30 minutes or so until it succeeds once, then only once every day, and try 3 times before printing a warning (it could just be a random network timeout)

As long as your re-touching the onboarding flow, I have a small suggestion : add a password.

More precisely, when the terminal tells you to go to the IP of your server on your browser, anyone who gets there before could basically take over the server, and could even reset the flow so you don't even notice. I know, the window of opportunity is small. It should basically be impossible as long as you go to the IP in question right then. But still...

A one-time password shown in the terminal, that the web interface would ask you for before allowing you to proceed with the setup would be pretty easy for the user, and would completely solve the issue.

(I must note that I have not gone through the setup and onboarding in a long time, what I am saying may be completely obsolete)

@christiaan There is absolutely no need to be on the official docker.io paid apps thing. It has to be a specific docker image for cloudron (see https://cloudron.io/documentation/custom-apps/tutorial/ )

I'm actually working on it, in a package with a bunch of other stuff in the same app so it can actually be useful (Transmission to download stuff, SickChill to auto-download TV Shows, and a custom file manager). I'd love feedback if you want to check it out : https://git.cloudron.io/mehdi/river/

My 2 cents here : I think the correct approach to implement this into Cloudron would be to build a OpenFass app, that would use https://github.com/openfaas/faasd/ under the hood

@Lonk I am quite curious, as I am not very familiar with Wordpress : what is the advantage of running a single Wordpress install in Multisite mode, versus having multiple wordpress installs, one for each site ?

I completely understand that such a setup was probably way easier to install and maintain in a "traditional" installation, where everything is run on bare metal. But in an environment like Cloudron, where you can setup another Wordpress install in literally < 1min, I must admit it does not seem obvious to me.

Just to make something explicit : if you leave the location field empty you can set up one top-level domain that is not a redirect.

@Lonk Here's the code : https://git.cloudron.io/cloudron/box

I think the cloudron team still accepts Merge Requests, even if it's not Open Source, as long as you sign a contributor's agreement (https://cla.cloudron.io/)

@oj It seems both of these are front-ends for the same back-end audio-conferencing server, with Mornin being a little more feature-rich, and Kraken being more minimalistic. Not 100% sure though, it's really not very clear.

In any case, they both seem more like a fun coding experiment someone did over a week-end, more than apps meant to be used in production...

@wu-lee said in Cloudron server restore is "Waiting for DNS of my.<hostname>":

What you seem to suggest is that if I had been using a supported DNS service, the cloudron installer would go right ahead and re-configure the DNS records to resolve to the new host.

Yes.

Although obviously this wouldn't work immediately, because of the propagation delay...

I believe cloudron configures the DNS with a short TTL, so that propagation does not take long, to avoid these issues. Not 100% sure though.

Leaving me with two installations, and the DNS records resolving unpredictably to one or the other...

The DNS would resolve to the new one, it would not be unpredictable. Why would it?

Or worse, if the restore failed at some point after the DNS reassignment, I could be left with the DNS records unpredictably resolving to a broken instance.
Surely that isn't really what anyone would want?

However, if you turn the old instance back on, it would re-configure the DNS on itself, so there would be no problem.

I would be interested to know whether this is possible or not - and in any case what I should expect the restore process to do, in what order?

I do not know of any way of doing what you are asking for, but you can mitigate most of these problems by setting a low TTL time, which would basically remove all DNS propagation problems. Then you can restore to the new instance with minimal downtime.

@mehdi, is this something you can speak authoritatively on?

I cannot speak authoritatively on anything, I'm just another cloudron user

@jdaviescoates Sure

However, I feel I have to mention that this app uses a very non-standard build system, that has not been maintained for 2+ years.

So, while the app itself looks sleek and modern, I must say I am not very optimistic about its future.

@wu-lee If you go to the link I gave in my previous message, it says

With the manual DNS provider, you have to setup DNS records prior to installing Cloudron and also prior to installing each app.

I do believe that to be quite clear.

However, I do agree that it could be useful to be able to fully restore to another instance before switching the DNS. I don't think it's currently possible, but it would definitely be valuable for someone who wants to keep a ready-to-go backup instance.

@atrilahiji I have a Dockerfile with a working build

FROM cloudron/base:2.0.0

ARG MORNIN_FM_VERSION="master"
ARG NODE_VERSION="10.22.1"

RUN mkdir -p /usr/local/node-${NODE_VERSION}
RUN curl -L "https://nodejs.org/download/release/v${NODE_VERSION}/node-v${NODE_VERSION}-linux-x64.tar.gz" \
    | tar -xz --strip-components=1 -C /usr/local/node-${NODE_VERSION}

ENV PATH=/usr/local/node-${NODE_VERSION}/bin:$PATH

RUN mkdir -p /app/code/morninfm

# copy code
ADD start.sh /app/code/

RUN curl -L "https://github.com/fox-one/mornin.fm/archive/${MORNIN_FM_VERSION}.tar.gz" \
    | tar -xz --strip-components=1 -C /app/code/morninfm

WORKDIR /app/code/morninfm

# install packages
RUN npm install yarn -g
RUN yarn
RUN yarn build

CMD [ "/app/code/start.sh" ]

This file does not rely on "forking" the original app, but rather downloads its code from the upstream github repo, to make updates easier.

Also, I have only fixed the build, I have not even tried starting the app ^^

@atrilahiji I have given it a try too, and I must admit it is indeed quite confusing... I have never seen something break in this way with a new node version.

However, you can quite easily install another node version in the app container, take a look at https://git.cloudron.io/mehdi/river/-/blob/master/Dockerfile#L22