@girish Thanks so much for the great answers.

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

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

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

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

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

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?

I'd like to not use Nextcloud's encryption-at-rest.

So I would love to be able to provide users with server logs that would show anytime a file was accessed by someone who did not own it or have share-access to it.

In other words, I want to do more than promise, "I won't access user files."

Ideas? I know there is a Linux program Auditd. I wanted to get other folks perspectives before I dive into that.

@girish

Trying to understand your question. Are you referring to users somehow accessing the files via SSH'ing into your server? If not, how can someone access files they did not own?

My interest is in auditing admin access and making those audits transparent.

What is the username and pw for /_admin?

@subven thanks.

I followed the instructions Lamp App - Installing custom PHP extensions. I was not able to get mcrypt installed that way.

Mcrypt is a pecl extension. Pecl is installed. In the app terminal I ran
pecl and it returned Failed loading /app/data/mcrypt/mcrypt.c: /app/data/mcrypt/mcrypt.c: invalid ELF header.

If I run pecl install mcrypt
I get

Failed loading /app/data/mcrypt/mcrypt.c:  /app/data/mcrypt/mcrypt.c: invalid ELF header
WARNING: channel "pecl.php.net" has updated its protocols, use "pecl channel-update pecl.php.net" to update
Cannot install, php_dir for channel "pecl.php.net" is not writeable by the current user
root@4b54a6f7-bd10-4898-a1a8-6c13ffb94a11:/app/data# 

Any ideas?

Thanks.

I need to add the mcrypt extension to a Lamp 7.4 app.

mcrypt was no longer included with PHP since PHP 7.2

I'm presuming I would have to create a custom app to add it to a Lamp 7.4 install. Please confirm or tell me otherwise.

Thanks.

@girish is there any way to delete unwanted certs via the my.example.com Cloudron dashboard? Or is it the case that ssh'ing into the server and deleting them at /home/yellowtent/boxdata/certs is the only way?

Also, I suggest that the Cloudron cert documentation explicitly mention that switching to a prod cert from staging requires that the staging certs be deleted.

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?

I have a couple of drupal/civicrm sites that I'm migrating to one of my Cloudrons. I will be using the php 7.4 app. The typical setup is for Drupal and CiviCRM to each have their own database.

This snippet below is from the Cloudron php 7.4 docs; I can infer that it is possible to create more than one database from the comment "only set when using a single database, see below." However, later in the documentation there are no references that I found to adding another database. In both phpMyAdmin and via the MySQL terminal it is not possible to create a second database.

It is possible to run Drupal and CiviCRM on the same database using table prefixes, but I'd prefer to have two databases for a bunch of reasons.

Is it possible to create another database? And if so, how do I do it?

CLOUDRON_MYSQL_URL=            # the mysql url (only set when using a single database, see below)
CLOUDRON_MYSQL_USERNAME=       # username
CLOUDRON_MYSQL_PASSWORD=       # password
CLOUDRON_MYSQL_HOST=           # server IP/hostname
CLOUDRON_MYSQL_PORT=           # server port
CLOUDRON_MYSQL_DATABASE=       # database name (only set when using a single database, see below)

Is it possible to set an ignore list for files/directories that Cloudron backup would skip?

I've been able to create aliases for the Cloudron terminal by creating the file

/app/data/.bash_aliases

putting the aliases there and then running

source /app/data/.bash_aliases

every time I log into the terminal. I was assuming that adding a .bashrc file wouldn't do anything. Is there any way for me to be able to skip the "source" step?

I figured it out.

Git's inline help, upon not knowing who you are, makes the suggestions:

git config --global user.email <email>
git config --global user.name <name>

Cloudron's problem is "--global". It has no problem with setting the user.name and user.email for a particular /app.

So this solved my problem:

git config user.email <email>
git config user.name <name>

of course substituting my email address for "<email>" and my name for "<name>".

In the Cloudron terminal, after authenticating over https, I have had no trouble with

git pull

But I have not had success with

git commit
git push

Git requires that I identify who I am in order to commit (and therefore push). But the Cloudron terminal won't let me do that. I think that where Git wants to write my credentials is read only.