🐛 How to create a temporary in background and check the tunnel domain?

[fscarmen]

Describe the bug I created a temporary tunnel in linux via cloudflared tunnel --no-autoupdate --url http://localhost:8080, giving the tunnel as "https://basis-continually-variables-trips. trycloudflare.com"

1. what variables can I add that will run in the background?
2. In what way can I look up the name of the current temporary tunnel?

To Reproduce Steps to reproduce the behavior:

1. Configure '...'
2. Run 'cloudflared tunnel --no-autoupdate --url http://localhost:8080'
3. See error

If it's an issue with Cloudflare Tunnel:

4. Tunnel ID :
5. cloudflared config:

Expected behavior I want to run it in background. And find out what tunnel domain name is being used by means of the command line.

Environment and versions

• OS: [Linux]
• Architecture: [AMD]
• Version: [cloudflared version 2023.2.1 (built 2023-02-03-1221 UTC)]

Logs and errors If applicable, add logs or errors to help explain your problem.

Additional context Add any other context about the problem here.

[DevinCarr]

If you are looking to run cloudflared in the background, I would recommend that you investigate how systemd services are run. By default, if you install cloudflared via https://pkg.cloudflare.com/ it will install a cloudflared.service that you should be able to configure and run.

To retrieve the tunnel domain that is issued by the quick tunnel run, you will need to:

1. Set the metrics port that cloudflared exposes for diagnostic information. You can update your command to look like this: cloudflared tunnel --no-autoupdate --metrics localhost:55555 --url http://localhost:8080
2. Make a request to http://localhost:55555/quicktunnel which will return a response that will look like: {"hostname":"basis-continually-variables-trips.trycloudflare.com"}

Further information on how to run systemd services: https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units

[fscarmen]

This is the result I wanted. I have two more questions.

1. Apart from quicktunnel, what other features are there (https://localhost:55555/??????) ?
2. Argo tunnel runs on yml file cloudflared tunnel --edge-ip-version auto --config . /tunnel.yml --metrics localhost:55555 --url http://localhost:8080 run or runs on token cloudflared tunnel --edge-ip-version auto --metrics localhost:55555 run --token ${ARGO_TOKEN}. When running wget -qO- http://localhost:55555/quicktunnel, it does not get the hostname (domain), it shows the following {"hostname":""}. How do I find the corresponding tunnel domain name.

[DevinCarr]

For your first question, we probably don't have it in the docs anywhere since it's mostly for helping customer's debug cloudflared issues, but maybe we should document them a bit. We change them around every once in a while, and add new ones, so I would consider them beta (not finalized, subject to change, blah, blah, blah...).

You can see some of them here: https://github.com/cloudflare/cloudflared/blob/master/metrics/metrics.go#L36

But at a high level overview:

• /debug: is the standard pprof endpoint (https://pkg.go.dev/net/http/pprof)
• /metrics: reports a wide range of prometheus metrics from cloudflared's process
• /healthcheck: standard 200 OK if it's running
• /ready: returns the if cloudflared has connections to the edge and can serve traffic and the connectorID
• /quicktunnel: as I described above
• /config: If the tunnel is remotely managed by Cloudflare, it will return the active config as JSON

For your second question, if you are running with a config that points to a tunnel, then it's not a quick tunnel, so the /quicktunnel endpoint will not be populated. A quick tunnel is a bit different than a tunnel that you use with the run --token ${TOKEN}.

In short a quick tunnel is a temporary tunnel that only exists while cloudflared is running. We provide this as a way for users to try out Cloudflare Tunnels without requiring them to create an account. (More details can be found here: https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/do-more-with-tunnels/trycloudflare/)

If you want to figure out which routes are served by your Tunnel, you can look in the dash to figure out which hostnames point to your tunnel, or you can use the API to look at your DNS records for your zones and find which ones point to a record that looks like <tunnel-id>.cfargotunnel.com: https://developers.cloudflare.com/api/operations/dns-records-for-a-zone-list-dns-records

[fscarmen]

Can you explain in detail what '--no-autoupdate' does? Or a page with instructions.

[DevinCarr]

--no-autoupdate is a way for you to allow cloudflared to check for and update in-place. I would recommend that you leverage your OS's package manager to handle cloudflared updates since it is more standardized and easier to manage the downtime.

https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/install-and-setup/tunnel-guide/local/local-management/arguments/#no-autoupdate

[fscarmen]

I do shell scripts to build argo tunnels for users quickly. I used the download and execute method for the reason that I don't have to think about the various linux systems debian /ubuntu/centos/arch. There are 3 ways I build them.

1. quick: . /cloudflared tunnel --edge-ip-version auto --no-autoupdate --url http://localhost:8080
2. json: . /cloudflared tunnel --edge-ip-version auto --config /root/tunnel.yml --url http://localhost:8080 run
3. token: . /cloudflared tunnel --edge-ip-version auto run --token

My question is, does --no-autoupdate work in the above 3 ways without using OS's package installation? The 2nd and 3rd methods have a fixed tunnel domain. So I didn't add it because even if it is automatically updated, it will be the original domain name. The first one has --no-autoupdate because I want to avoid the automatic upgrade that will cause the temporary tunnel domain to change and affect the usage. Am I understanding this correctly?

I also have a suggestion to add something like --origincert to the cloudflared login to specify the output path of the cert.pem file.

[DevinCarr]

My question is, does --no-autoupdate work in the above 3 ways without using OS's package installation?

By omitting --no-autoupdate from 2. and 3. you described, should perform a daily check for updates and attempt to update the cloudflared binary in-place across a few OSes. Some OSes have different capabilities and restrictions so I always recommend that you leverage the OS's package management system to install cloudflared since it's the easiest solution for maintaining frequent and consistent upgrades.

The first one has --no-autoupdate because I want to avoid the automatic upgrade that will cause the temporary tunnel domain to change and affect the usage.

Correct, quick tunnels are expected to be transient, so a restart could not bring back the same hostname for the tunnel. We don't expect that quick tunnels should be around for extended periods of time, that's what the normal tunnels are for (2. and 3.).

I also have a suggestion to add something like --origincert to the cloudflared login to specify the output path of the cert.pem file.

The cert.pem is used to perform operations on Cloudflare Tunnels or perform other API operations and isn't needed to run the tunnel (this is a common misconception that I want to clarify). You are welcome to submit a PR for said contribution if you feel that you need to have more granular control over where the cert.pem is being stored from cloudflared login.

[fscarmen]

Thank you very much for your patience, I have no further questions for now.