Cloudron Forum

@girish I haven't yet found out about the PHP compatibility of bootstrap3.
Were you able to track down the packaging issue?

Hi all,

Thank you for the default pages fix. I was just about to test it, when I noticed that the recent update broke (at least) the bootstrap3 theme, which is a very popular one.

Package Version where the error was introduced: org.dokuwiki.cloudronapp@1.13.0-1 (also broken in org.dokuwiki.cloudronapp@1.13.1)

Bootstrap3 theme is not working anymore since this Update. In the log I catch the following:

Feb 01 10:04:39 [Wed Feb 01 09:04:39.781873 2023] [php:error] [pid 71] [client 172.18.0.1:50560] PHP Fatal error: Uncaught Error: Undefined constant "DOKU_INC" in /app/data/templates/bootstrap3/css.php:84\nStack trace:\n#0 {main}\n thrown in /app/data/templates/bootstrap3/css.php on line 84, referer: https://<url>/lib/exe/css.php?t=bootstrap3&tseed=<seed>
Feb 01 10:04:39 <IP> - - [01/Feb/2023:09:04:39 +0000] "GET /lib/tpl/bootstrap3/css.php?f=bootstrap.css HTTP/1.1" 500 - "https://<url>/lib/exe/css.php?t=bootstrap3&tseed=<seed>" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0"
Feb 01 10:04:39 <IP> - - [01/Feb/2023:09:04:39 +0000] "GET /lib/exe/taskrunner.php?id=start%3Adocumentation%3Alearning%3Anetwork%3Ainterconnect&1675242279 HTTP/1.1" 200 42 "https://<url>/start/documentation/learning/network/interconnect?do=admin&page=config" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0"
Feb 01 10:04:39 [Wed Feb 01 09:04:39.954388 2023] [php:error] [pid 71] [client 172.18.0.1:50568] PHP Fatal error: Uncaught Error: Undefined constant "DOKU_INC" in /app/data/templates/bootstrap3/iconify.php:65\nStack trace:\n#0 {main}\n thrown in /app/data/templates/bootstrap3/iconify.php on line 65, referer: https://<url>?do=admin&page=config
Feb 01 10:04:39 85.195.207.88 - - [01/Feb/2023:09:04:39 +0000] "GET /lib/tpl/bootstrap3/iconify.php?prefix=mdi&icons=check-circle HTTP/1.1" 500 - "https://<url>?do=admin&page=config" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0"

Probably unrelated, but I also noticed these entries in the log:

Feb 01 09:54:13 <IP> - - [01/Feb/2023:08:54:13 +0000] "GET /start HTTP/1.1" 200 3301 "https://<url>/start" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0"
Feb 01 09:54:20 [Wed Feb 01 08:54:20.371996 2023] [php:warn] [pid 68] [client 172.18.0.1:42250] PHP Warning: Undefined array key "gidnumber" in /app/data/plugins/authldap/auth.php on line 238, referer: https://<url>/start
Feb 01 09:54:20 [Wed Feb 01 08:54:20.372042 2023] [php:warn] [pid 68] [client 172.18.0.1:42250] PHP Warning: Trying to access array offset on value of type null in /app/data/plugins/authldap/auth.php on line 238, referer: https://<url>/start

It seems that pages like:

• Playground
• Formatting Syntax
• Welcome to your new DokuWiki
• DokuWiki

Will reappear after an app restart even if they have been deleted.
This behaviour is unwanted, as those pages are only needed for first use and can be deleted afterwards.

This helped me as well in 7.2.5 after a system restore.

@girish So after the upgrade to 7.2.2 the problem vanished. Closing the Ticket.
Thank you for the help!

Thx for your answers!
@nebulon There are no OOM notifications visible in the dashboard.
@girish It's 7.1.4. I would love to upgrade, but a recent backup prior to the upgrade would be nice. It would be great if the issue will disappear on 7.2.2.

Hi all

The backups in my Cloudron fail repeatedly with the following message:

Backup failed: Could not pipe http://172.18.0.5:3000/databases/<omitted>/backup?access_token=<omitted> to /home/yellowtent/appsdata/<omitted>/mongodbdump: Request timedout. Logs are available here.

In the last 7 days the backup failed 5 times.

Usually, it is enough to restart the mongodb service and initiate a backup right after the service has started up. Unfortunately, this workaround stopped to work and the backups fail anyway.

Memory wise I already upgraded mongodb two times (it is now 8GB!):

I somehow doubt increasing the memory further will be a longterm solution.

The app that is causing the mongodbdump timeout is a Rocketchat instance.

Any ideas on how to tackle and solve this?

@girish To me it looks like mysql is taking too long to start and box is giving up eventually. I had to wait a long time until mysql was ready and listening. That was the moment I kicked the restart of the box service, which got stuff running (still slowly, but moving forward). My apps are now configuring / starting, so it looks fine. Maybe that information helps a bit. Here some box.log output:

Mar 17 21:56:51 box:services Waiting for mysql
Mar 17 21:56:51 box:services Attempt 1 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.0.3:3000
Mar 17 21:57:06 box:services Attempt 2 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.0.3:3000
Mar 17 21:57:21 box:services Attempt 3 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.0.3:3000
Mar 17 21:57:36 box:services Attempt 4 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.0.3:3000
Mar 17 21:57:51 box:services Attempt 5 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.0.3:3000
Mar 17 21:58:06 box:services Attempt 6 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.0.3:3000
Mar 17 21:58:21 box:services Attempt 7 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.0.3:3000
Mar 17 21:58:36 box:services Attempt 8 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.0.3:3000
Mar 17 21:58:51 box:services Attempt 9 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.0.3:3000
Mar 17 21:58:53 box:shell statusNginx exec: systemctl is-active nginx
Mar 17 21:58:53 box:shell statusUnbound exec: systemctl is-active unbound
Mar 17 21:58:53 box:shell statusNginx (stdout): active
Mar 17 21:58:53 box:shell statusNginx (stderr): null
Mar 17 21:58:53 box:shell statusUnbound (stdout): active
Mar 17 21:58:53 box:shell statusUnbound (stderr): null
Mar 17 21:59:06 box:platform Failed to start services. retry=false (attempt 0): Network error waiting for mysql: connect ECONNREFUSED 172.18.0.3:3000
Mar 17 21:59:06 box:cloudron Startup task at index 3 failed: Network error waiting for mysql: connect ECONNREFUSED 172.18.0.3:3000
Mar 17 22:01:14 box:locker Lock unreleased platform_start

I use it, in combination with DANE for certificate pinning in DNS.
mehdi is sort of right - clients dont really use it, some mail providers do. But I know of no one that enforces it (by dropping e-mails or traffic).

I use a browser add on in Firefox that displays me the DNSSEC and DANE status of webpages I'm visiting. With the add on I know at least something is odd when it fails on my own pages / domains.

@girish As i'm using Sogo for calendars - nope, that's not possible to migrate... And as it does not start, it's also not possible to download the data and start from scratch via import. Anyway, no need for me to put extra efforts in it - but for Businesses this would not be a good situation I guess.

Are there other apps that have been silently replaced with a new version which is not updatable and will be deprecated? Did I miss communication about it or was there none? Probably an indicator in the GUI would help, like a (!) top right at the App tile, where you find more information about the app being deprecated and you need to migrate (or a migration routine in cloudron directly would be preferred i think).

@girish That works, yes. But my question was if there is a way to rollback a complete cloudron upgrade (so including the box part). In some cases this is the fastest path when you need the services up and running quickly.

I just saw that Sogo is not responding. Restore the backup and restart the app did not help. The logs say the following:
Mar 14 20:19:14 => Convert the sql schema
Mar 14 20:19:14 Converting c_content from TEXT to LONGTEXT in the sogo_user_profile table
Mar 14 20:19:14 mysql: [Warning] Using a password on the command line interface can be insecure.
Mar 14 20:19:14 ERROR 2026 (HY000): SSL connection error: unknown error number

Thx @girish, that solved it!
Should the line be activated after everything is up and running again?

BTW: I was looking for an option to rollback the upgrade to the previous release - is it somehow possible to rollback the whole cloudron to a backup without setting up everything from scratch?

Hello
I upgraded from 6.1.2 to 6.2.4. After the upgrade, following apps are stuck in " Restarting - Waiting for Cloudron to initialize":

• Invoice Ninja
• Bitwarden
• Sogo
• Gitlab
• Rocketchat (2x)
• Matrix
• Monica
• Paperwork
• FreshRSS
• Nextcloud
• Wekan

Following Apps could start:

• Shaarli
• Collabora
• Trillium
• Riot / Element
• Simple Torrent
• Rainloop

I assume it could be a DB issue.

I did already reboot the server, restart box, restart mysql, mongodb & postgresql, no success so far.

That seemed to solve it, even if a server reboot did not solve it. I also got a mail, that this was also visible from other mail-servers (not just from my mail client), as I use DANE for certificate pinning.
Thx girish!

@girish Just checked, yes i'm already on 5.6.1.
And good to know, thx

I also got SSL errors after the upgrade, but in Thunderbird. It seems like the default self signed Cert is used.

A possibility to postpone updates for like 2 weeks would be nice, to not run into such things.

My whole cloudron was not really working after the update. I did a reboot, nothing really changed, System looked like this:

After the fix from @girish and restart of box everything worked again.

Hope you push a hotfix pretty soon for all others. Still wish for a GUI option to choose if i want auto or manually install system updates, just for cases like this (this exists for the apps and has existed for the cloudron itself in the past). Auto updates always have this bitter aftertaste of waking up next day and it could work or not work.

Hi @fbartels

Thank you for your great work! This is definitely on a good path

Some few things I noticed:

• Saving a config throws a Error saving config: IOError. I also checked with a reboot and it seems it really can't be saved right now. (also smtp wouldn't be possible without this fixed)
• When accessing the admin panel when not logged into cloudron, you get a password prompt. A 403 HTTP would probably be more suitable and secure

And as a small Bonus: As the app is getting in a pretty good shape, it is time for a logo =D
here you go: https://github.com/bitwarden/brand/blob/master/icons/256x256.png

You're welcome

I hope this pr is going to be merged into bitwarden_rs soon: https://github.com/dani-garcia/bitwarden_rs/pull/396

It would make it a lot easier for the user management. Currently registration is open to the world until you set ENV SIGNUPS_ALLOWED=false, which only makes sense after you created a first account. After setting it you could work with invites, but the invitation model sucks (you can just invite when having an Organisation or you can do it in the admin panel, but you have to set another env variable to access it and you can't save stuff there).

So currently not really usable for the normal user. As far as I understood, with the ldap integration accounts / invites will be synced for all ldap users, which is exactly what we want. I also hope the admin panel gets some love, as in my eyes the token system to log in there isn't really easy to handle. And there seems to be a problem saving the settings you set there, but that's probably a problem in the cloudron integration.

@fbartels It works now with the fix from my colleague m4rg4sh (he submitted a pull request). Also there is a new version 1.8.0 - I just updated to it and everything looks great so far