Cloudron Forum

@luckow => here is my slight riff on your great work.

I don't like composer.json and composer.lock to be at the cloudron data root /app/data

So I removed this bullet from the instruction:

* move everything from inside recommended-project into the root of /app/data
mv recommended-project/* . & mv recommended-project/.* .

And then I changed
rm -rf public & ln -s web public
to
rm -rf public & ln -s recommended-project/web public

I find it much easier to manage version control this way.

Your pioneering work made it so much easier for me. Thanks.

@girish Thanks so much for the great answers.

I look forward to installing the cloudron cli on my computer running Linux Mint .

@girish THANK YOU! I followed your instructions and all good now.

@girish I successfully migrated my Cloudron from one server to another. I followed your directions and updated Cloudron to v 6.0.0 before making my final backup of the old server.

Thank you.

I'm planning to move my 14-app Cloudron to a new server.

All of the apps use Cloudron's amazing automated remote DNS record creation/deletion service... except for one app.

There could be a delay of a few days or a week before I can get the person who has access to the DNS records for me to walk him through changing the DNS for the one manual app..

I don't want to wait a week to migrate.

Can I have 13 apps running on the new server and the 1 app running on the old server for a week. Will that work? Thoughts?

@murgero I had downloaded the zip archive, pushed it to the Cloudron and then unzipped it. I got to the installer by just navigating to the site url. With the original method I never succeeded or figured out what the problem was.

However, I started over and this time used Piwigo's netinstaller option where I only push one php file and then navigate to that file... the install went perfectly, no problems connecting to db.

My next step is to manually go into the config file and replace the credentials there with Cloudron environment variables.

Thanks to you and @scooke and @JLX89 who responded with helpful suggestions.

@girish @murgero,

The problem was the GPG key for yarn.

By adding the following on line 5 of Dockerfile the problem was fixed:

RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -

That line did generate the following warning; you tell me if it is of concern:

Warning: apt-key output should not be parsed (stdout is not a terminal)

I've successfully installed the app on my Cloudron. Now I'm configuring the two dbs.

@girish Thanks so much for the great service! I'm a happy customer.

@girish thx. It was really helpful for you to say that you didn't think the problem was with the cert. It got me thinking outside that box.

The problem was that I hadn't properly set up Nat loopback support on the new router (the config for that was different from the one on the old router).

I had to un-tick the box "Stop DNS Rebind" in order to get my site to resolve on my local computers (access from outside my network was fine --which I hadn't realized at first).

There was a big warning when I unticked that setting. Any thoughts on this. It's possible that I have some other local network or router setting that isn't quite right.

Thx.

@nebulon Great. Thanks. That info should be put into Multiple Databases with Lamp instructions.

• I installed the Cloudron Collabora app.
• I set the Nextcloud domain at the Collabora domain
• In Nextcloud I installed the Collabora online connector app
• In Nextcloud I set the URL of the Collabora instance at: /settings/admin/richdocuments
• When clicking "Save" there I get "Could not establish connection to the Collabora Online server."
• I can successfully connect to a demo server.

Any ideas?

@girish wrote "I remember mentioning NAT loopback in https://blog.cloudron.io/installing-cloudron-on-a-home-server/."

That is indeed where I learned about it and was diligent when I set up the old router... but forgot about it it completely when setting up the new one. Always a good idea to work from docs and not just your own head.

I had the same problem and searched the forum.

Got the solution here, thanks! @alkomy

Since finding where to add the white-listed IP on Namecheap can cause you to pull your hair out, I thought I'd document it here for others:

Direct URL: https://ap.www.namecheap.com/settings/tools/apiaccess/

Via the UI: account => profile => tools => Business & Dev tools => Namecheap API access (click "Manage") and then click "Edit" across from "Whitelisted IPs".

Yesterday I was having trouble with a cert. It turns out the underlying problem may have been Let's Encrypt being down for some time. Which is probably a pretty rare event.

In my troubleshooting attempts I tried switching to a staging cert. It was after I made that switch that Let's Encrypt seemed to come back on line. And so I got a staging cert. Which was of no help since the site was actually a production site and the browser warnings are ominous.

The log message when I clicked "Renew all certs" was that no cert was issued because one already existed. I had already edited the domain and chosen "wildcard prod" but that didn't make a difference.

In fact, deleting the domain from from my.example.com/#/domains and re-adding (also with Wildcard prod) did nothing.

Then I ssh-ed into the Ubuntu 20.04 server Cloudron runs on and went to: /home/yellowtent/boxdata/certs

and I

sudo rm exampleapp.com*
sudo rm _.exampleapp.com*

I went back to my.example.com/#/domains and clicked "Renew all certs" and all was good.

While I was in /home/yellowtent/boxdata/certs I noticed that any domain that I had previously deleted still had certs there.

Is this by design? If so, why?

Also, how is one supposed to replace a staging cert with prod one?

Yes, that was the problem. I was logged in under a second test user account that I had assigned admin role. Logged out and back in as my original cloudron owner account and all good on that front. Thanks.

I haven't done this in awhile. I did remember to add AWS domain id to the "policy" which gives permissions to API calls to Route53.

But I don't remember where to get the Access Key ID or the Secret access key. I clicked on "Users" at IAM and nothing looks right there. I have several domains whose DNS is at AWS so I've done this before. I can see the access_id used on those other domains but I can't find a secret associated with that access_Id. Uggh, it's a problem when you don't do this stuff very often.

Thanks for the help.

sudo systemctl status unbound
Unit unbound.service could not be found.

@girish

unbound-anchor -a /var/lib/unbound/root.key
systemctl restart unbound

That solved it. Thank you.

When I try to remove a domain from /#/domains I'm getting the error message,
Domain is in use in an app's location

But it is not being used as an app's location.

What do I do now?

Thanks

I found that I was using that domain name as an alias for another app.