[Intranet] Install cloudron in a corporate network environment

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 ?

nebulon

The setup token here would be sent to the Cloudron backend on the VM and that will attempt to verify it calling api.cloudron.io so I guess that connection does not work. Not sure what would need to be configured to make the box nodejs process use the proxy...

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