-
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. -
@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 boxjust keeps getting stuck in that line? Something is making the nginx restart command just get stuck. Not sure what though. -
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 ?
-
@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
-
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 shouldOnce 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.
-
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 progressingcloudron@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.3I 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 !
-
@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. -
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 tho2024-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 -
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
boxnodejs process use the proxy... -
@rmdes said in [Intranet] Install cloudron in a corporate network environment:
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 ?
just for the sake of leaving a trail about this :
I had to manually add 7.7.1 inside the VERSION file at /home/yellowtent/box
-
in line with different issues I was having earlier (no DIST folder inside ~/box/dashabord/dist)
I tested zipping and copying a dist folder from another cloudron to this intranet VM and that's when I managed to have the nginx service to run and the box to actually start, I searched for why the dist folder wasn't being built but I could not find a root cause, since I did manage to run each part of the cloudron-setup, in the end, even if I had to run the last part multiples times to get it done in full without any issues.$ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 68c9ba37e3fc registry.docker.com/cloudron/sftp:3.8.6 "/app/code/start.sh" 25 minutes ago Up 25 minutes 0.0.0.0:222->22/tcp sftp d2b73ebf372d registry.docker.com/cloudron/graphite:3.4.3 "/app/code/start.sh" 25 minutes ago Up 25 minutes 127.0.0.1:2003->2003/tcp graphite d92d85ddd963 registry.docker.com/cloudron/mongodb:6.0.0 "/app/code/start.sh" 26 minutes ago Up 26 minutes mongodb 7abb3c530b8e registry.docker.com/cloudron/postgresql:5.2.1 "/app/code/start.sh" 26 minutes ago Up 26 minutes postgresql 198524bd2eff registry.docker.com/cloudron/mysql:3.4.2 "/app/code/start.sh" 27 minutes ago Up 27 minutes mysql f3dd10277ac2 registry.docker.com/cloudron/turn:1.7.2 "/app/code/start.sh" 27 minutes ago Up 27 minutes turn 8381d2785cf4 registry.docker.com/cloudron/mail:3.12.1 "/app/code/start.sh" 27 minutes ago Up 27 minutes mail cloudron@T00MID01:/home/yellowtent$
