In the midst of deploying a new ApisCP server…
Does ApisCP support Cloudflare tunnels? Or would this be more of a ‘hack’?
Trying to determine if ApisCP can be behind NAT without port forwarding, using Cloudflare Tunnels…
Searching docs.apiscp.com and kb.apiscp.com, this page, https://kb.apiscp.com/ssl/lets-encrypt-behind-a-reverse-proxy/ was as close to an answer as I came…
ApisCP will attempt to detect NAT presence at installation and configure automatically if found. You can force NAT using cpcmd scope:set dns.ip4-proxy PUBLIC.IP.ADD.RESS where that’s your tunnel IP. ipinfo,nbaddrs would remain the address on the server. Beyond that I imagine it would behave similarly to AWS/GCP or any NAT-based configuration.
If you’re interested solely in website proxying, disable mail on the account and specify proxy:true in the DNS key.
Alright. I will see what happens.
Web traffic would be using the tunnel, the server’s own traffic (updates for example) would be using the NAT’d public IP. I wasn’t sure how ApisCP would handle it. 
Trying again right now…
This part in the “Requirements”, Cloudflare Tunnel seems to break though
Looks like that isn’t what is breaking the install though…
2022-10-29 23:53:32,012 p=16517 u=root n=ansible | fatal: [localhost]: FAILED! => {“attempts”: 2, “changed”: false, “failures”: [], “msg”: “Depsolve Error occured: \n Problem: problem with installed package bind9.16-utils-32:9.16.23-0.9.el8.1.x86_64\n - package bind9.16-utils-32:9.16.23-0.9.el8.1.x86_64 conflicts with bind-utils provided by bind-utils-32:9.11.36-5.el8.x86_64\n - package bind9.16-utils-32:9.16.23-0.5.el8.x86_64 conflicts with bind-utils provided by bind-utils-32:9.11.36-5.el8.x86_64\n - package bind9.16-utils-32:9.16.23-0.7.el8.x86_64 conflicts with bind-utils provided by bind-utils-32:9.11.36-5.el8.x86_64\n - package bind9.16-utils-32:9.16.23-0.9.el8.x86_64 conflicts with bind-utils provided by bind-utils-32:9.11.36-5.el8.x86_64\n - cannot install the best candidate for the job”, “rc”: 1, “results”: []}
2022-10-29 23:53:32,018 p=16517 u=root n=ansible | PLAY RECAP *********************************************************************
2022-10-29 23:53:32,019 p=16517 u=root n=ansible | localhost : ok=110 changed=0 unreachable=0 failed=1 skipped=68 rescued=0 ignored=0
Minimal install of RockyLinux 8 seems to be going better than CentOS 8 Stream…
Depends on the image you’re installing from I’d say. Make sure they do come with no extra packages installed, as it seems there’s an older bind9 version installed here already…
I’d try uninstalling bind-utils and re-running the bootstrapper, hopefully that does the trick.
Did you convert from C8 Stream to Rocky 8 or what’s the specific steps?
dnf autoremove
upcp -sbf
This will remove orphaned packages while reinstalling packages as needed for Rocky 8.
I downloaded the RockyLinux (8) ISO and reinstalled the server…
Provide the steps you’ve taken since installing Rocky 8 minimal to reproduce the error. Looks like BIND 9.16 is getting pulled in somewhere in your process. bind-utils, which is 9.11 is the default package for this OS release. I don’t see anything from a cursory Google that would indicate 9.16 is necessary with Cloudflare Tunnel.
I started with CentOS Stream 8, got the above error trying to install.
Reinstalled the server using RockyLinux 8 and ApisCP installed without issue.
Still playing with it but last night I finally got it working through Argo… Still exploring though to figure out what is best.
Take notes. If you run into a snag from Rocky, then it will give some guidance how best to proceed - think of it as breadcrumbs with Hansel and Gretel.
Indeed.
I am saving my console session logs for the time being. Once I get everything working, I’ll likely wipe it and start over, just to make sure that there are no left-overs from what didn’t work. 
Alright…
I setup a proxy server on the local network for the Cloudflare tunnel, it isn’t running on the local host…
This is what my Public Hostname page looks like,
example.com https://192.0.2.36
www.example.com https://192.0.2.36
example.com http://192.0.2.36
www.example.com http://192.0.2.36
server1.example.com https://192.0.2.36:2083
panel.example.com https://192.0.2.36:2083
Everything works except some of the tools from the panel…
Opening phpMyAdmin shows Page Not Found with a rocket… I suspect it is because it is trying to load sever1.example.com/phpMyAdmin//dummyset.php on port 443 rather than 2083 but Cloudflare is forcing it to use 2083?
Hints that I should be able to set sever1.example.com and sever1.example.com:2083 separately but either it can’t be done, my account can’t do it, or I am missing something completely with the configurations… I can’t set the listening port, only the forwarded-to port.
Trying sever1.example.com and sever1.example.com:2083 in my browser load the same pages…
Is there another way to get tools like phpMyAdmin to work?
Either go full-Cloudflare and use Cloudflare Access, or change httpd bind ports to suit your Argo Tunnel requirements…
Been doing severs for a long time… Cloudflare is very new to me, still trying to figure out what the requirements are to be honest.
Is it possible (simple) to set the admin portal (default on port 2083) to be based on FQDN instead of port?
To have portal.example.com and portal.example.org, portal.* to show the login page, example.com and example.org to load the website?
Or will this still have the same issue using tools like phpMyAdmin because it appears to drop to the root domain when launching them?
I may need to look for a “Cloudflare for Dummies” book… 
Right, and using the Cloudflare tunnel, it is forcing all traffic to server1.example.com to port 2083.
https://developers.cloudflare.com/fundamentals/get-started/reference/network-ports/
Hints that it might be possible, but also adds
Cloudflare Access does not support port numbers in URLs. Port numbers are stripped from requests for URLs protected through Cloudflare Access.
At the bottom.
Did you have much joy in getting CloudFlare Tunnels/cloudflared up and running with ApisCP?
No…
Some things worked but some things definitely did not.
The admin panel/portal running on TCP 2083 was fine but some of the tools in the admin panel connect using port 443, the tunnels basically drop the ports, breaking the tools. Everything through the tunnel trys to connect on the same port.