Cloudron Forum

Thanks @blanghoff, @BrutalBirdie and @james for your responses. I'm going to work through this information and see what I can come up with. I will report back on my progress. Thanks again.

I have just discovered that from Guacamole application package 2.0.0, the password token no longer works for RDP connections if using OIDC to log into Guacamole. I'm using an external LDAP directory (AD server) which is synced to Cloudron.
When configuring an RDP connection in Guacamole, you can use tokens to pass the current users credentials to RDP. ${GUAC_USERNAME} still seems to pass the correct username to RDP, but ${GUAC_PASSWORD} results in an authentication failure (as confirmed by the Guacamole and Windows Event Logs). I proved that it is only the password token (and that everything else was still working), by leaving ${GUAC_USERNAME} in place and saving my actual password in the RDP connection, which connected successfully.
Application package Version 2.0.0 was when OIDC was introduced. From what I can tell, the Guacamole version is 1.5.5 in package 1.8.6 and 2.0.0. The tokens work fine in package 1.8.6. The next Guacamole update to 1.6.0 isn't until package 2.5.0.
I found a reddit thread saying that passing the credentials can't be done with OpenID.
Is anyone else having this issue? Both my deployments have the same problem. Having my remote users log in once with their AD credentials to access their own RDP session is the whole reason I have Cloudron. Any help would be much appreciated.

Hi @james, yes, I think so. Correct me if I am wrong, but Guacamole is configured to use Cloudron's OIDC Provider, so it makes sense that it would automatically take you to the OpenID login page. If you wanted to give less technically able users (like me) a choice, I'm assuming an option could be put under the Access Control section of the Guacamole app settings?

@nebulon thanks for your response. I wasn't sure if this was a Cloudron thing or a Guacamole thing, so as a paying customer I thought I would ask here first. Now focusing on the Guacamole documentation, I found the solution - its actually very easy! Not sure why I didn't stumble upon it sooner.

To redirect users immediately to the OpenID identity provider (Cloudron in this case) instead of going to the default Guacamole authentication method, requires a 1 line configuration change in the guacamole.properties file.

To do this, go to the File Manager for the Guacamole app and open the guacamole.properties file. Add a new line as shown below:

extension-priority: openid

Save and close the file, then restart the Guacamole app.

Now when browsing to the your normal Guacamole URL, you will be redirected to the OpenID login page

https://guacamole.apache.org/doc/gug/openid-auth.html#automatically-redirecting-all-unauthenticated-users
https://guacamole.apache.org/doc/gug/configuring-guacamole.html#guacamole-properties
https://docs.cloudron.io/apps/#file-manager

@james Thanks for your suggestion.
I currently have very basic custom branding applied, but still wasn't able to work out a solution - this is currently outside of my abilities. To confuse matters, I attempted to apply the example branding as linked in the documentation (to prove that changes were applying), but it didn't work.

I have 2 Cloudron instances which are synced with on-premise AD servers. I have the Guacamole app installed with the location set to use the bare domain. Prior to Guacamole V2.0 package update, users would browse to the Cloudron domain, login with their AD credentials at the login page shown, and were taken straight to Guacamole. From V2.0 package update onwards, the new OIDC login feature requires users to click a tiny link in the bottom corner of the initial login page, which takes them to another login page (OpenID Login page), to then log in with their AD credentials. (To clarify for those that aren't aware, using AD credentials at the first login page no longer works).
Not sure if I am missing something - but is it possible to set the default login page for Guacamole as the OpenID login page? Or is it possible to set the default login page to use the OpenID credentials? I've had a look through the GUI settings, checked the forums and google, but come up empty. Any help is appreciated.

Hi @girish
I ran the commands suggested and it has fixed the issue - thank you. Looking at the logs, the issue occurred when the update to version 7.5.2 was started. For the record, I did do a search in the forum for this issue, but didn't come across the article you referenced. Thanks again for your help.

Hi @girish

Thanks for your response. Below is the steps I completed as per the guide you provided. Unfortunately I still have the domain setup page. Clicking the restore button still results in the same behavior as described earlier.

Domain: working
Nginx: running
start .sh: See extract below. Most notably "[ERROR] AssertionError" leading to "DB migration failed".
systemctl: running

Thanks for your help so far,

Justin

start .sh extract

administrator@phvculs:~$ sudo /home/yellowtent/box/setup/start.sh
[sudo] password for administrator:
2023-10-03T23:19:11 ==> start: Cloudron Start
media: x:500:
2023-10-03T23:19:12 ==> start: Configuring docker
Synchronizing state of apparmor.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable apparmor
2023-10-03T23:19:13 ==> start: Ensuring directories
2023-10-03T23:19:13 ==> start: Configuring journald
2023-10-03T23:19:13 ==> start: Setting up unbound
2023-10-03T23:19:15 ==> start: Adding systemd services
Synchronizing state of unbound.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable unbound
Synchronizing state of cron.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable cron
2023-10-03T23:19:19 ==> start: Configuring sudoers
2023-10-03T23:19:19 ==> start: Configuring collectd
2023-10-03T23:19:19 ==> start: Configuring sysctl
2023-10-03T23:19:19 ==> start: Configuring logrotate
2023-10-03T23:19:19 ==> start: Adding motd message for admins
2023-10-03T23:19:19 ==> start: Configuring nginx
2023-10-03T23:19:20 ==> start: Starting mysql
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
Warning: Since password will be sent to server in plain text, use ssl connection to ensure password safety.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
2023-10-03T23:19:20 ==> start: Migrating data
Ignoring invalid configuration option passed to Connection: driver. This is currently a warning, but in future versions of MySQL2, an error will be thrown if you pass an invalid configuration option to a Connection
[ERROR] AssertionError [ERR_ASSERTION]: ifError got unwanted exception: Duplicate entry 'sftp_rsa_private_key' for key 'blobs.PRIMARY'
at /home/yellowtent/box/node_modules/db-migrate/lib/commands/on-complete.js:15:14
at tryCatcher (/home/yellowtent/box/node_modules/bluebird/js/release/util.js:16:23)
at Promise.successAdapter (/home/yellowtent/box/node_modules/bluebird/js/release/nodeify.js:22:30)
at Promise._settlePromise (/home/yellowtent/box/node_modules/bluebird/js/release/promise.js:601:21)
at Promise._settlePromiseCtx (/home/yellowtent/box/node_modules/bluebird/js/release/promise.js:641:10)
at _drainQueueStep (/home/yellowtent/box/node_modules/bluebird/js/release/async.js:97:12)
at _drainQueue (/home/yellowtent/box/node_modules/bluebird/js/release/async.js:86:9)
at Async._drainQueues (/home/yellowtent/box/node_modules/bluebird/js/release/async.js:102:5)
at Async.drainQueues [as _onImmediate] (/home/yellowtent/box/node_modules/bluebird/js/release/async.js:15:14)
at process.processImmediate (node:internal/timers:476:21)
at Packet.asError (/home/yellowtent/box/node_modules/mysql2/lib/packets/packet.js:728:17)
at Query.execute (/home/yellowtent/box/node_modules/mysql2/lib/commands/command.js:29:26)
at Connection.handlePacket (/home/yellowtent/box/node_modules/mysql2/lib/connection.js:456:32)
at PacketParser.onPacket (/home/yellowtent/box/node_modules/mysql2/lib/connection.js:85:12)
at PacketParser.executeStart (/home/yellowtent/box/node_modules/mysql2/lib/packet_parser.js:75:16)
at Socket.<anonymous> (/home/yellowtent/box/node_modules/mysql2/lib/connection.js:92:25)
at Socket.emit (node:events:513:28)
at addChunk (node:internal/streams/readable:324:12)
at readableAddChunk (node:internal/streams/readable:297:9)
at Readable.push (node:internal/streams/readable:234:10)
at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
2023-10-03T23:19:21 ==> start: DB migration failed

Hello,

For seemingly no reason, 1 of my Cloudron installations appears to have reverted to default last month. Looking at the logs it seems that I am currently running version V7.5.2.

When accessing apps, it says its not responding. When accessing the Cloudron setup (via my.domain.com), it comes up with the Domain Setup screen.

I attempted to use the restore link at the bottom of the Domain Setup screen (as per the restore clourdon instructions), but it just quickly takes me to a blank screen and then back to the Domain Setup screen.

I can see in the var/backups location I have 3 backups. Below is an extract from box.log since last restart, which mentions an error related to a bad field (no idea what that means). The local CLI is showing a cloud-int[1423] Used fallback datasource warning.

I had a look around with how to recover without the web interface, and it seems it might be possible with the Cloudron CLI, but I didn't find any instructions (in a post from 2017, it said there would be a future post on how to migrate a whole server, but I can't find it).

Any help you can provide would be appreciated.

Thanks,

Justin

box.log Extract

2023-10-02T23:01:14.576Z box:server ==========================================
2023-10-02T23:01:14.576Z box:server Cloudron 7.5.2
2023-10-02T23:01:14.576Z box:server ==========================================
2023-10-02T23:01:14.576Z box:platform initializing platform
2023-10-02T23:01:14.661Z box:tasks stopAllTasks: stopping all tasks
2023-10-02T23:01:14.661Z box:shell stopTask spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all
2023-10-02T23:01:14.839Z box:shell stopTask (stdout): All tasks stopped

2023-10-02T23:01:14.905Z box:platform onActivated: starting post activation services
2023-10-02T23:01:14.906Z box:platform startInfra: checking infrastructure
2023-10-02T23:01:14.913Z box:platform startInfra: updating infrastructure from 49.4.0 to 49.5.0
2023-10-02T23:01:14.913Z box:locker Acquired : infra_start
2023-10-02T23:01:14.913Z box:platform removeAllContainers: removing all containers for infra upgrade
2023-10-02T23:01:14.913Z box:shell removeAllContainers exec: docker ps -qa --filter 'label=isCloudronManaged' | xargs --no-run-if-empty docker stop
2023-10-02T23:01:14.939Z box:shell removeAllContainers (stdout): null
2023-10-02T23:01:14.939Z box:shell removeAllContainers (stderr): null
2023-10-02T23:01:14.939Z box:shell removeAllContainers exec: docker ps -qa --filter 'label=isCloudronManaged' | xargs --no-run-if-empty docker rm -f
2023-10-02T23:01:14.956Z box:shell removeAllContainers (stdout): null
2023-10-02T23:01:14.956Z box:shell removeAllContainers (stderr): null
2023-10-02T23:01:14.956Z box:platform createDockerNetwork: recreating docker network
2023-10-02T23:01:14.956Z box:shell createDockerNetwork exec: docker network rm cloudron || true
2023-10-02T23:01:15.283Z box:shell createDockerNetwork (stdout): cloudron

2023-10-02T23:01:15.283Z box:shell createDockerNetwork (stderr): null
2023-10-02T23:01:15.283Z box:shell createDockerNetwork exec: docker network create --subnet=172.18.0.0/16 --ip-range=172.18.0.0/20 --gateway 172.18.0.1 --ipv6 --subnet=fd00:c107:d509::/64 cloudron
2023-10-02T23:01:15.387Z box:shell createDockerNetwork (stdout): 888a45f70a162a5aaaed4f2acefddf2b520684fdeff952d389ce9020616fe3c7

2023-10-02T23:01:15.387Z box:shell createDockerNetwork (stderr): null
2023-10-02T23:01:15.388Z box:platform markApps: reconfiguring apps
2023-10-02T23:01:15.388Z box:reverseproxy removeAppConfigs: removing app nginx configs
2023-10-02T23:01:15.409Z box:platform startInfra: Failed to start services. retry=false (attempt 0): ER_BAD_FIELD_ERROR: Unknown column 'apps.enableTurn' in 'field list'
2023-10-02T23:01:15.409Z box:platform BoxError: ER_BAD_FIELD_ERROR: Unknown column 'apps.enableTurn' in 'field list'
at Query.queryCallback (/home/yellowtent/box/src/database.js:91:38)
at Query.<anonymous> (/home/yellowtent/box/node_modules/mysql/lib/Connection.js:526:10)
at Query._callback (/home/yellowtent/box/node_modules/mysql/lib/Connection.js:488:16)
at Sequence.end (/home/yellowtent/box/node_modules/mysql/lib/protocol/sequences/Sequence.js:83:24)
at Query.ErrorPacket (/home/yellowtent/box/node_modules/mysql/lib/protocol/sequences/Query.js:92:8)
at Protocol._parsePacket (/home/yellowtent/box/node_modules/mysql/lib/protocol/Protocol.js:291:23)
at Parser._parsePacket (/home/yellowtent/box/node_modules/mysql/lib/protocol/Parser.js:433:10)
at Parser.write (/home/yellowtent/box/node_modules/mysql/lib/protocol/Parser.js:43:10)
at Protocol.write (/home/yellowtent/box/node_modules/mysql/lib/protocol/Protocol.js:38:16)
at Socket.<anonymous> (/home/yellowtent/box/node_modules/mysql/lib/Connection.js:88:28)
2023-10-02T23:06:14.937Z box:locker Lock unreleased infra_start
2023-10-02T23:11:14.959Z box:locker Lock unreleased infra_start
2023-10-02T23:16:14.986Z box:locker Lock unreleased infra_start
2023-10-02T23:21:14.996Z box:locker Lock unreleased infra_start
2023-10-02T23:26:15.004Z box:locker Lock unreleased infra_start

Yes, modifying the hosts file was my last option, which was successful - thanks for your suggestion. Once the hostname was found, I was able to save the configuration. Not sure why I couldn't get overall hostname resolution working, but at the end of the day it wont really matter. I guess this is still a bug, since I assume it should tell the user "server URL not found" and not reboot. Being able to resolve local hostnames out of the box would be great, even if the use case is probably the minority. I did discover that you can just use the IP address for the server URL - I didn't think that this was an option initially because it didn't work for me (because I had other settings wrong). Which leads me onto my next comment - there is very little feedback when you get the settings wrong. When your a top tier noob like me, it takes a lot of trail and error. For example, getting the Base DN wrong leads to the Server URL being highlighted red (even though the server url and credentials are correct). Looking at the log shows that the object wasn't found. For anyone else having issues getting the settings right, my example is below.

Thanks @nebulon for your help.

Given that the error said it couldn't find mydomain.local, I attempted to ping it, with no response. I was then taking a stab in the dark assuming that if I could get a response via a ping, it might then find the server and successfully connect. Google has told me that Ubuntu by default doesn't resolve windows hostnames, and that everyone else on the internet (except me) has resolved it using winbind. Example Here

@nebulon said in Configuring External Directory causes Cloudron to reboot:

/home/yellowtent/platformdata/logs/box.log

Not a whole lot from what I can see.

Although I have realised I can't ping local netbios names. I tried to get that going but have so far been unsuccessful (mucking around with winbind).

I am trying to configure an External Directory (Active Directory on Win Server 2016). I have been putting in the minimum amount of information to save the configuration, but get an error and a disconnection. Looking at the event log, each time this happens, there is a boot event.

This was happening with version 7.2.5, as well as the latest version 7.3.4.
Cloudron is hosted on premises - Latest version of Ubuntu on Hyper-V Host.
I'm not very experienced in this field, so not sure if I'm doing something wrong or what.

Thanks in advance.