[Intranet] Install cloudron in a corporate network environment

rmdes

for the sake of showing my docker pull worked and the script chain properly to start.sh

cloudron@cloudron:/home/yellowtent/box$ sudo ./scripts/installer.sh
2024-03-28T18:47:09 ==> installer: Updating from # release version. do not edit manually to # release version. do not edit manually
/usr/bin/docker
/usr/bin/node
npm verb cli /usr/local/node-18.16.0/bin/node /usr/bin/npm
npm info using npm@9.5.1
npm info using node@v18.16.0
npm verb title npm rebuild
npm verb argv "rebuild" "--unsafe-perm"
npm verb logfile logs-max:10 dir:/root/.npm/_logs/2024-03-28T18_47_10_305Z-
npm verb logfile /root/.npm/_logs/2024-03-28T18_47_10_305Z-debug-0.log
npm info run cpu-features@0.0.9 install node_modules/cpu-features node buildcheck.js > buildcheck.gypi && node-gyp rebuild
npm info run ssh2@1.15.0 install node_modules/ssh2 node install.js
npm info run ssh2@1.15.0 install { code: 0, signal: null }
npm info run cpu-features@0.0.9 install { code: 0, signal: null }
npm info run tldjs@2.3.1 postinstall node_modules/tldjs node ./bin/postinstall.js
npm info run tldjs@2.3.1 postinstall { code: 0, signal: null }
rebuilt dependencies successfully
npm verb exit 0
npm info ok 
2024-03-28T18:47:14 ==> installer: downloading new addon images
2024-03-28T18:47:14 ==> installer:      Pulling docker images: registry.docker.com/cloudron/base:4.2.0@sha256:46da2fffb36353ef714f97ae8e962bd2c212ca091108d768ba473078319a47f4 registry.docker.com/cloudron/graphite:3.4.3@sha256:75df420ece34b31a7ce8d45b932246b7f524c123e1854f5e8f115a9e94e33f20 registry.docker.com/cloudron/mail:3.12.1@sha256:f539bea6c7360d3c0aa604323847172359593f109b304bb2d2c5152ca56be05c registry.docker.com/cloudron/mongodb:6.0.0@sha256:1108319805acfb66115aa96a8fdbf2cded28d46da0e04d171a87ec734b453d1e registry.docker.com/cloudron/mysql:3.4.2@sha256:379749708186a89f4ae09d6b23b58bc6d99a2005bac32e812b4b1dafa47071e4 registry.docker.com/cloudron/postgresql:5.2.1@sha256:5ef3aea8873da25ea5e682e458b11c99fc8df25ae90c7695a6f40bda8d120057 registry.docker.com/cloudron/redis:3.5.2@sha256:5c3d9a912d3ad723b195cfcbe9f44956a2aa88f9e29f7da3ef725162f8e2829a registry.docker.com/cloudron/sftp:3.8.6@sha256:6b4e3f192c23eadb21d2035ba05f8432d7961330edb93921f36a4eaa60c4a4aa registry.docker.com/cloudron/turn:1.7.2@sha256:9ed8da613c1edc5cb8700657cf6e49f0f285b446222a8f459f80919945352f6d
registry.docker.com/cloudron/base@sha256:46da2fffb36353ef714f97ae8e962bd2c212ca091108d768ba473078319a47f4: Pulling from cloudron/base
Digest: sha256:46da2fffb36353ef714f97ae8e962bd2c212ca091108d768ba473078319a47f4
Status: Image is up to date for registry.docker.com/cloudron/base@sha256:46da2fffb36353ef714f97ae8e962bd2c212ca091108d768ba473078319a47f4
registry.docker.com/cloudron/base:4.2.0@sha256:46da2fffb36353ef714f97ae8e962bd2c212ca091108d768ba473078319a47f4
4.2.0: Pulling from cloudron/base
Digest: sha256:46da2fffb36353ef714f97ae8e962bd2c212ca091108d768ba473078319a47f4
Status: Image is up to date for registry.docker.com/cloudron/base:4.2.0
registry.docker.com/cloudron/base:4.2.0
registry.docker.com/cloudron/graphite@sha256:75df420ece34b31a7ce8d45b932246b7f524c123e1854f5e8f115a9e94e33f20: Pulling from cloudron/graphite
Digest: sha256:75df420ece34b31a7ce8d45b932246b7f524c123e1854f5e8f115a9e94e33f20
Status: Image is up to date for registry.docker.com/cloudron/graphite@sha256:75df420ece34b31a7ce8d45b932246b7f524c123e1854f5e8f115a9e94e33f20
registry.docker.com/cloudron/graphite:3.4.3@sha256:75df420ece34b31a7ce8d45b932246b7f524c123e1854f5e8f115a9e94e33f20
3.4.3: Pulling from cloudron/graphite
Digest: sha256:75df420ece34b31a7ce8d45b932246b7f524c123e1854f5e8f115a9e94e33f20
Status: Image is up to date for registry.docker.com/cloudron/graphite:3.4.3
registry.docker.com/cloudron/graphite:3.4.3
registry.docker.com/cloudron/mail@sha256:f539bea6c7360d3c0aa604323847172359593f109b304bb2d2c5152ca56be05c: Pulling from cloudron/mail
Digest: sha256:f539bea6c7360d3c0aa604323847172359593f109b304bb2d2c5152ca56be05c
Status: Image is up to date for registry.docker.com/cloudron/mail@sha256:f539bea6c7360d3c0aa604323847172359593f109b304bb2d2c5152ca56be05c
registry.docker.com/cloudron/mail:3.12.1@sha256:f539bea6c7360d3c0aa604323847172359593f109b304bb2d2c5152ca56be05c
3.12.1: Pulling from cloudron/mail
Digest: sha256:f539bea6c7360d3c0aa604323847172359593f109b304bb2d2c5152ca56be05c
Status: Image is up to date for registry.docker.com/cloudron/mail:3.12.1
registry.docker.com/cloudron/mail:3.12.1
registry.docker.com/cloudron/mongodb@sha256:1108319805acfb66115aa96a8fdbf2cded28d46da0e04d171a87ec734b453d1e: Pulling from cloudron/mongodb
Digest: sha256:1108319805acfb66115aa96a8fdbf2cded28d46da0e04d171a87ec734b453d1e
Status: Image is up to date for registry.docker.com/cloudron/mongodb@sha256:1108319805acfb66115aa96a8fdbf2cded28d46da0e04d171a87ec734b453d1e
registry.docker.com/cloudron/mongodb:6.0.0@sha256:1108319805acfb66115aa96a8fdbf2cded28d46da0e04d171a87ec734b453d1e
6.0.0: Pulling from cloudron/mongodb
Digest: sha256:1108319805acfb66115aa96a8fdbf2cded28d46da0e04d171a87ec734b453d1e
Status: Image is up to date for registry.docker.com/cloudron/mongodb:6.0.0
registry.docker.com/cloudron/mongodb:6.0.0
registry.docker.com/cloudron/mysql@sha256:379749708186a89f4ae09d6b23b58bc6d99a2005bac32e812b4b1dafa47071e4: Pulling from cloudron/mysql
Digest: sha256:379749708186a89f4ae09d6b23b58bc6d99a2005bac32e812b4b1dafa47071e4
Status: Image is up to date for registry.docker.com/cloudron/mysql@sha256:379749708186a89f4ae09d6b23b58bc6d99a2005bac32e812b4b1dafa47071e4
registry.docker.com/cloudron/mysql:3.4.2@sha256:379749708186a89f4ae09d6b23b58bc6d99a2005bac32e812b4b1dafa47071e4
3.4.2: Pulling from cloudron/mysql
Digest: sha256:379749708186a89f4ae09d6b23b58bc6d99a2005bac32e812b4b1dafa47071e4
Status: Image is up to date for registry.docker.com/cloudron/mysql:3.4.2
registry.docker.com/cloudron/mysql:3.4.2
registry.docker.com/cloudron/postgresql@sha256:5ef3aea8873da25ea5e682e458b11c99fc8df25ae90c7695a6f40bda8d120057: Pulling from cloudron/postgresql
Digest: sha256:5ef3aea8873da25ea5e682e458b11c99fc8df25ae90c7695a6f40bda8d120057
Status: Image is up to date for registry.docker.com/cloudron/postgresql@sha256:5ef3aea8873da25ea5e682e458b11c99fc8df25ae90c7695a6f40bda8d120057
registry.docker.com/cloudron/postgresql:5.2.1@sha256:5ef3aea8873da25ea5e682e458b11c99fc8df25ae90c7695a6f40bda8d120057
5.2.1: Pulling from cloudron/postgresql
Digest: sha256:5ef3aea8873da25ea5e682e458b11c99fc8df25ae90c7695a6f40bda8d120057
Status: Image is up to date for registry.docker.com/cloudron/postgresql:5.2.1
registry.docker.com/cloudron/postgresql:5.2.1
registry.docker.com/cloudron/redis@sha256:5c3d9a912d3ad723b195cfcbe9f44956a2aa88f9e29f7da3ef725162f8e2829a: Pulling from cloudron/redis
Digest: sha256:5c3d9a912d3ad723b195cfcbe9f44956a2aa88f9e29f7da3ef725162f8e2829a
Status: Image is up to date for registry.docker.com/cloudron/redis@sha256:5c3d9a912d3ad723b195cfcbe9f44956a2aa88f9e29f7da3ef725162f8e2829a
registry.docker.com/cloudron/redis:3.5.2@sha256:5c3d9a912d3ad723b195cfcbe9f44956a2aa88f9e29f7da3ef725162f8e2829a
3.5.2: Pulling from cloudron/redis
Digest: sha256:5c3d9a912d3ad723b195cfcbe9f44956a2aa88f9e29f7da3ef725162f8e2829a
Status: Image is up to date for registry.docker.com/cloudron/redis:3.5.2
registry.docker.com/cloudron/redis:3.5.2
registry.docker.com/cloudron/sftp@sha256:6b4e3f192c23eadb21d2035ba05f8432d7961330edb93921f36a4eaa60c4a4aa: Pulling from cloudron/sftp
Digest: sha256:6b4e3f192c23eadb21d2035ba05f8432d7961330edb93921f36a4eaa60c4a4aa
Status: Image is up to date for registry.docker.com/cloudron/sftp@sha256:6b4e3f192c23eadb21d2035ba05f8432d7961330edb93921f36a4eaa60c4a4aa
registry.docker.com/cloudron/sftp:3.8.6@sha256:6b4e3f192c23eadb21d2035ba05f8432d7961330edb93921f36a4eaa60c4a4aa
3.8.6: Pulling from cloudron/sftp
Digest: sha256:6b4e3f192c23eadb21d2035ba05f8432d7961330edb93921f36a4eaa60c4a4aa
Status: Image is up to date for registry.docker.com/cloudron/sftp:3.8.6
registry.docker.com/cloudron/sftp:3.8.6
registry.docker.com/cloudron/turn@sha256:9ed8da613c1edc5cb8700657cf6e49f0f285b446222a8f459f80919945352f6d: Pulling from cloudron/turn
Digest: sha256:9ed8da613c1edc5cb8700657cf6e49f0f285b446222a8f459f80919945352f6d
Status: Image is up to date for registry.docker.com/cloudron/turn@sha256:9ed8da613c1edc5cb8700657cf6e49f0f285b446222a8f459f80919945352f6d
registry.docker.com/cloudron/turn:1.7.2@sha256:9ed8da613c1edc5cb8700657cf6e49f0f285b446222a8f459f80919945352f6d
1.7.2: Pulling from cloudron/turn
Digest: sha256:9ed8da613c1edc5cb8700657cf6e49f0f285b446222a8f459f80919945352f6d
Status: Image is up to date for registry.docker.com/cloudron/turn:1.7.2
registry.docker.com/cloudron/turn:1.7.2
2024-03-28T18:47:33 ==> installer: stop box service for update
Stopping cloudron
2024-03-28T18:47:36 ==> installer: calling box setup script

with this part commented since I already have /home/yellowtent/
ready with the latest box version

# ensure we are not inside the source directory, which we will remove now
#cd /root

#log "switching the box code"
#rm -rf "${box_src_dir}"
#mv "${box_src_tmp_dir}" "${box_src_dir}"
#chown -R "${user}:${user}" "${box_src_dir}"

For the start.sh script to finish with success I had to (keep unbound stopped)
and then inside /box/ run once npm install to have all the node_modules installed so that the migration can run properly.

rmdes

box.service

cloudron@cloudron:/home$ sudo systemctl status box.service
● box.service - Cloudron Admin
     Loaded: loaded (/etc/systemd/system/box.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2024-03-28 18:48:33 UTC; 4min 56s ago
   Main PID: 34909 (node)
      Tasks: 11 (limit: 77024)
     Memory: 56.7M (max: 400.0M available: 343.2M)
        CPU: 2.002s
     CGroup: /system.slice/box.service
             └─34909 node /home/yellowtent/box/box.js

Mar 28 18:48:33 cloudron systemd[1]: Started Cloudron Admin.
Mar 28 18:48:34 cloudron sudo[34941]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=808)
Mar 28 18:48:34 cloudron sudo[34941]: pam_unix(sudo:session): session closed for user root
Mar 28 18:48:34 cloudron sudo[34947]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=808)
Mar 28 18:48:34 cloudron sudo[34947]: pam_unix(sudo:session): session closed for user root

girish

@rmdes Did you check the box logs already as to why it's failing to start the containers?

I guess somehow the docker containers must also proxy all the http calls via the proxy.

rmdes

the box log is pretty silent actually, not much happening
when I restart the box service and check the box.log

I see this /home/yellowtent/platformdata/logs/box.log


2024-03-29T10:22:45.608Z box:box Received SIGTERM. Shutting down.
2024-03-29T10:22:45.609Z box:platform uninitializing platform
2024-03-29T10:22:45.613Z box:tasks stopAllTasks: stopping all tasks
2024-03-29T10:22:45.613Z box:shell stopTask /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all
2024-03-29T10:22:49.622Z box:server ==========================================
2024-03-29T10:22:49.623Z box:server            Cloudron # release version. do not edit manually
2024-03-29T10:22:49.623Z box:server ==========================================
2024-03-29T10:22:49.623Z box:platform initialize: start platform
2024-03-29T10:22:49.656Z box:tasks stopAllTasks: stopping all tasks
2024-03-29T10:22:49.657Z box:shell stopTask /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all
2024-03-29T10:22:49.749Z box:platform start: not activated. generating IP based redirection config
2024-03-29T10:22:49.755Z box:reverseproxy writeDefaultConfig: writing configs for endpoint "setup"
2024-03-29T10:22:49.756Z box:shell reload /usr/bin/sudo -S /home/yellowtent/box/src/scripts/restartservice.sh nginx

Nginx, box, docker services are all running and appear to be fine, but nothing is happening
also nginx error log keeps showing that there is missing dist/ folder inside /box/dashboard/
as if it hadn't been built in the first place

regarding docker proxy :
I'm able to pull any image from docker.io through the proxy
using /etc/systemd/system/docker.service.d/http-proxy.conf

[Service]
Environment="HTTP_PROXY=http://iproxy:8080"
Environment="HTTPS_PROXY=http://iproxy:8080"
Environment="NO_PROXY=localhost,127.0.0.1"

I have a custom.conf for the unbound systemd service working now
meaning, I can have cloudron-firewall, unbound enabled and running and still maintain
an internet access to the outside network

server:
  # this disables DNSSEC
  val-permissive-mode: yes

  # Specify your internal domains
  private-domain: "local.domain"
  domain-insecure: "local.domain"

  # Hardcode the Cloudron dashboard address
  local-data: "my.cloudron.local.domain. IN A 10.200.116.244"
  #local-data: "cloudron.local.domain. IN A 10.200.116.244"

# Forward all queries to the internal DNS servers
forward-zone:
  name: "."
  forward-addr: 10.200.X.X
  forward-addr: 10.200.X.X
  forward-addr: 10.200.X.X
  forward-addr: 10.200.X.X

girish

@rmdes it seems nginx is not restart. Does systemctl restart nginx work ?

rmdes

Appears to be the case :


journalctl -u nginx -f
Mar 29 10:43:29 T00MID01 systemd[1]: Stopping A high performance web server and a reverse proxy server...
Mar 29 10:43:29 T00MID01 systemd[1]: nginx.service: Deactivated successfully.
Mar 29 10:43:29 T00MID01 systemd[1]: Stopped A high performance web server and a reverse proxy server.
Mar 29 10:43:29 T00MID01 systemd[1]: Starting A high performance web server and a reverse proxy server...
Mar 29 10:43:29 T00MID01 systemd[1]: Started A high performance web server and a reverse proxy server.

                                                                                                                                                                                             cloudron@T00MID01 ~ [SIGINT]> sudo systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/nginx.service.d
             └─cloudron.conf
     Active: active (running) since Fri 2024-03-29 10:43:29 UTC; 23s ago
       Docs: man:nginx(8)
    Process: 18291 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 18292 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 18293 (nginx)
      Tasks: 11 (limit: 77024)
     Memory: 21.9M
        CPU: 74ms
     CGroup: /system.slice/nginx.service
             ├─18293 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─18294 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
             ├─18295 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
             ├─18296 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
             ├─18297 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
             ├─18298 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
             ├─18299 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
             ├─18300 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
             ├─18301 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
             ├─18302 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
             └─18303 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""

Mar 29 10:43:29 T00MID01 systemd[1]: Starting A high performance web server and a reverse proxy server...
Mar 29 10:43:29 T00MID01 systemd[1]: Started A high performance web server and a reverse proxy server.

girish

@rmdes did the restart command itself work? I think that's where the box code is getting stuck.

rmdes

I think so, I'm not seing any diff behavor compared to one of my (armada) (not intranet) cloudron

girish

@rmdes said in [Intranet] Install cloudron in a corporate network environment:

2024-03-29T10:22:49.623Z box:server Cloudron # release version. do not edit manually

This line is also worrying. Looks like something is wrong with the VERSION file.

So, systemctl restart box just keeps getting stuck in that line? Something is making the nginx restart command just get stuck. Not sure what though.

rmdes

Perhaps related to how (see first post) I had to comment the "check version" part of the cloudron-setup and manually set the box_src_dir and the version (7.7.1)

requestedVersion="7.7.1"
version="7.7.1"

Perhaps something should have been done to that VERSION thing when it's retrieved via the api ?

rmdes

@girish said in [Intranet] Install cloudron in a corporate network environment:

So, systemctl restart box just keeps getting stuck in that line?

yes correct, nothing happens after that and I can explore of the logs files I can get my hands on, I don't see any root issues

rmdes

if anyone have any idea on what I could do to get this done, I'm all ear

With ups and downs, I got all the parts of all the scripts to run properly and install what they must
but still, even tho "box.js" is running and that box.service is running, same for docker etc..
I'm not seing cloudron starting as it should

Once I get it up and running I want to make a blog post about this and replicate the entire install procedure (with the added bonus now I know how I can configure my unbound service to work from the get go)

This means minimal modification of the original cloudron-setup and an easy way to replicate this install even in other proxy environnements/intranets.

rmdes

Damn, finally !

rmdes

There is still something odd with the public IP detected by the cloudron (it does not exist)
and instead of using my ens160 network card IP it uses a local IP but I'm progressing


cloudron@T00MID01:/home/yellowtent/box/src/scripts$ sudo grc tail -f /home/yellowtent/platformdata/logs/box.log
2024-04-01T09:19:49.677Z box:mail upsertDnsRecords: records of cloudron.***.** added
2024-04-01T09:19:49.679Z box:provision setProgress: setup - Registering location my.cloudron.***.**
2024-04-01T09:19:49.680Z box:mailserver restartMailIfActivated: skipping restart of mail container since Cloudron is not activated yet
2024-04-01T09:19:49.684Z box:dns upsertDNSRecord: location my on domain cloudron.***.** of type A with values ["10.200.XXX.XXX"]
2024-04-01T09:19:49.685Z box:dns/manual upsert: my for zone ***.** of type A with values ["10.200.XXX.XXX"]
2024-04-01T09:19:49.687Z box:provision setProgress: setup - Waiting for propagation of my.cloudron.***.**
2024-04-01T09:19:49.688Z box:dns/waitfordns waitForDns: waiting for my.cloudron.***.** to be 10.200.XXX.XXX in zone ns1.***.**
2024-04-01T09:19:49.689Z box:dns/waitfordns waitForDns: nameservers are ["ns1.***.**","ns2.***.**","ns3.***.**"]
2024-04-01T09:19:49.691Z box:dns/waitfordns resolveIp: Checking if my.cloudron.***.** has A record at 172.16.64.5
2024-04-01T09:19:54.638Z box:box Received SIGHUP. Re-reading configs.
2024-04-01T09:21:04.763Z box:dns/waitfordns resolveIp: No A record. Checking if my.cloudron.***.** has CNAME record at 172.16.64.5
2024-04-01T09:22:19.837Z box:dns/waitfordns isChangeSynced: NS ns1.***.** (172.16.64.5) not resolving my.cloudron.***.** (A): Error: queryCname ETIMEOUT my.cloudron.***.**. Ignoring
2024-04-01T09:22:19.837Z box:dns/waitfordns waitForDns: my.cloudron.***.** at ns ns1.***.**: done
2024-04-01T09:22:19.845Z box:dns/waitfordns resolveIp: Checking if my.cloudron.***.** has A record at 172.16.64.3

I think I just need to define my A record to point to the VM IP and define a DNS record for cloudron.*. and I should be moving forward another step !

girish

@rmdes the default public IP detection works by curl https://ipv4.api.cloudron.io/api/v1/helper/public_ip . If this is not the case in your set up, you have to choose Manual IPv4 configuration in the networking . This is also available under Advanced options, when you set up DNS initially.

rmdes

this curl command does resolve but I guess it's detecting our F5 proxy/load-balancer not the actual IP of the VM on the intranet

I'm tyring to setup the dashboard but even tho I select manual and I specify the IP of the VM, it keeps expecting an A record with an internal 172.XXX.X.XXX IP in the logs

I do see this kind of log entries tho


2024-04-02T08:45:07.987Z box:dns/waitfordns waitForDns: my.cloudron.***.***.*** at ns .***.***.***: done
2024-04-02T08:45:07.988Z box:dns/waitfordns resolveIp: Checking if my.cloudron.***.***.*** has A record at NS
2024-04-02T08:45:07.990Z box:dns/waitfordns isChangeSynced: my.cloudron..***.***.*** (A) was resolved to 10.200.XXX.XX4 at NS .***.***.***  Expecting 10.200.XXX.XX4. Match true

girish

@rmdes Manual means it will still try to check if the DNS resolves to the IP address you have entered. You can choose noop if you want to skip that DNS check.

rmdes

I got it working, using the settings above in the screenshot, for some reason specifying the correct zone name helped
now I'm at

rmdes

Moving forward bit by bit

I had to manually register on the website and then take the setup token but for some reason, I can't get past to this step, it timeouts , I don't see much about this in the logs tho

Timeout of 30000ms exceeded

rmdes

I'm wondering if there a way I can tie a setup token from the CLI or from inside the VM ?

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

[Intranet] Install cloudron in a corporate network environment