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.

@girish

Thanks. I don't see an image hash. Rather it fails on a GPG key.

Here is the build output

Step 1/26 : FROM cloudron/base:2.0.0@sha256:f9fea80513aa7c92fe2e7bf3978b54c8ac5222f47a9a32a7f8833edf0eb5a4f4
 ---> afa4cfc125b4
Step 2/26 : RUN mkdir -p /app/code
 ---> Using cache
 ---> e07f49f6451d
Step 3/26 : WORKDIR /app/code
 ---> Using cache
 ---> 97eeefe5d9eb
Step 4/26 : RUN apt-get -y update && apt install -y cron apache2-dev php-imagick && rm -rf /var/cache/apt /var/lib/apt/lists
 ---> Running in a5881c83ada4
Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Get:2 http://dl.yarnpkg.com/debian stable InRelease [17.1 kB]
Get:3 http://ppa.launchpad.net/ondrej/php/ubuntu bionic InRelease [20.8 kB]
Get:4 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]
Err:2 http://dl.yarnpkg.com/debian stable InRelease
  The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>
Get:5 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 Packages [1421 kB]
Get:6 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 Packages [510 kB]
Get:7 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages [2263 kB]
Get:8 http://security.ubuntu.com/ubuntu bionic-security/multiverse amd64 Packages [26.7 kB]
Get:9 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:10 http://ppa.launchpad.net/ondrej/php/ubuntu bionic/main amd64 Packages [158 kB]
Get:11 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Get:12 http://archive.ubuntu.com/ubuntu bionic/restricted amd64 Packages [13.5 kB]
Get:13 http://archive.ubuntu.com/ubuntu bionic/multiverse amd64 Packages [186 kB]
Get:14 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages [1344 kB]
Get:15 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages [11.3 MB]
Get:16 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 Packages [39.4 kB]
Get:17 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 Packages [544 kB]
Get:18 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages [2699 kB]
Get:19 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages [2196 kB]
Get:20 http://archive.ubuntu.com/ubuntu bionic-backports/main amd64 Packages [11.3 kB]
Get:21 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 Packages [11.4 kB]
Reading package lists...
W: GPG error: http://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>
E: The repository 'http://dl.yarnpkg.com/debian stable InRelease' is not signed.
The command '/bin/bash -c apt-get -y update && apt install -y cron apache2-dev php-imagick && rm -rf /var/cache/apt /var/lib/apt/lists' returned a non-zero code: 100

Here is the docker file:

FROM cloudron/base:2.0.0@sha256:f9fea80513aa7c92fe2e7bf3978b54c8ac5222f47a9a32a7f8833edf0eb5a4f4

RUN mkdir -p /app/code
WORKDIR /app/code

# required for compiling rpaf
RUN apt-get -y update && apt install -y cron apache2-dev php-imagick && rm -rf /var/cache/apt /var/lib/apt/lists

# configure apache
RUN rm /etc/apache2/sites-enabled/*
RUN sed -e 's,^ErrorLog.*,ErrorLog "|/bin/cat",' -i /etc/apache2/apache2.conf
COPY apache/mpm_prefork.conf /etc/apache2/mods-available/mpm_prefork.conf
COPY apache/lamp.conf /etc/apache2/sites-enabled/lamp.conf
RUN echo "Listen 80" > /etc/apache2/ports.conf
RUN a2disconf other-vhosts-access-log
RUN a2enmod rewrite headers rewrite expires cache

# configure mod_php
RUN crudini --set /etc/php/7.3/apache2/php.ini PHP upload_max_filesize 64M && \
    crudini --set /etc/php/7.3/apache2/php.ini PHP post_max_size 64M && \
    crudini --set /etc/php/7.3/apache2/php.ini PHP memory_limit 128M && \
    crudini --set /etc/php/7.3/apache2/php.ini Session session.save_path /run/app/sessions && \
    crudini --set /etc/php/7.3/apache2/php.ini Session session.gc_probability 1 && \
    crudini --set /etc/php/7.3/apache2/php.ini Session session.gc_divisor 100

RUN mv /etc/php/7.3/apache2/php.ini /etc/php/7.3/apache2/php.ini.orig && ln -sf /app/data/php.ini /etc/php/7.3/apache2/php.ini && \
    mv /etc/php/7.3/cli/php.ini /etc/php/7.3/cli/php.ini.orig && ln -sf /app/data/php.ini /etc/php/7.3/cli/php.ini

# install RPAF module to override HTTPS, SERVER_PORT, HTTP_HOST based on reverse proxy headers
# https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-web-server-and-reverse-proxy-for-apache-on-one-ubuntu-16-04-server
RUN mkdir /app/code/rpaf && \
    curl -L https://github.com/gnif/mod_rpaf/tarball/669c3d2ba72228134ae5832c8cf908d11ecdd770 | tar -C /app/code/rpaf -xz --strip-components 1 -f -  && \
    cd /app/code/rpaf && \
    make && \
    make install && \
    rm -rf /app/code/rpaf

# configure rpaf
RUN echo "LoadModule rpaf_module /usr/lib/apache2/modules/mod_rpaf.so" > /etc/apache2/mods-available/rpaf.load && a2enmod rpaf

# phpMyAdmin
RUN mkdir -p /app/code/phpmyadmin && \
    curl -L https://files.phpmyadmin.net/phpMyAdmin/4.9.4/phpMyAdmin-4.9.4-all-languages.tar.gz | tar zxvf - -C /app/code/phpmyadmin --strip-components=1
COPY phpmyadmin-config.inc.php /app/code/phpmyadmin/config.inc.php

# configure cron
RUN rm -rf /var/spool/cron && ln -s /run/cron /var/spool/cron
# clear out the crontab
RUN rm -f /etc/cron.d/* /etc/cron.daily/* /etc/cron.hourly/* /etc/cron.monthly/* /etc/cron.weekly/* && truncate -s0 /etc/crontab

# ioncube. the extension dir comes from php -i | grep extension_dir
# extension has to appear first, otherwise will error with "The Loader must appear as the first entry in the php.ini file"
RUN mkdir /tmp/ioncube && \
    curl http://downloads.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz | tar zxvf - -C /tmp/ioncube && \
    cp /tmp/ioncube/ioncube/ioncube_loader_lin_7.3.so /usr/lib/php/20170718 && \
    rm -rf /tmp/ioncube && \
    echo "zend_extension=/usr/lib/php/20170718/ioncube_loader_lin_7.3.so" > /etc/php/7.3/apache2/conf.d/00-ioncube.ini && \
    echo "zend_extension=/usr/lib/php/20170718/ioncube_loader_lin_7.3.so" > /etc/php/7.3/cli/conf.d/00-ioncube.ini

# configure supervisor
ADD supervisor/ /etc/supervisor/conf.d/
RUN sed -e 's,^logfile=.*$,logfile=/run/supervisord.log,' -i /etc/supervisor/supervisord.conf

# add code
COPY start.sh index.php crontab.template credentials.template phpmyadmin_login.template /app/code/

# lock www-data but allow su - www-data to work
RUN passwd -l www-data && usermod --shell /bin/bash --home /app/data www-data

# make cloudron exec sane
WORKDIR /app/data

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

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