Selfhosted

60911 readers

927 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

Be civil.
No spam.
Posts are to be related to self-hosting.
Don't duplicate the full text of your blog or readme if you're providing a link.
Submission headline should match the article title.
No trolling.
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago

MODERATORS

curbstickle@anarchist.nexus

curbstickle_lw@lemmy.world

Uptime-kuma & Docker: Timeouts when monitoring services on same host (lemmy.world)

submitted 3 years ago by outcide@lemmy.world to c/selfhosted@lemmy.world

8 comments fedilink hide all child comments

Hello.

Pretty sure I'm doing something stupid, but I can't find it.

I have Caddy and Uptime-kuma installed as Docker containers. They are on the same Docker bridge network. Both work fine (with the below exception).

I'm trying to monitor Caddy virtual hosts from Uptime-kuma and getting a timeout.

If I exec into the Uptime-kuma container, I can ping the host name I want to monitor (and the DNS is resolving correctly to the Docker hosts external IP).

But I can't reach port 80/443 using telnet or openssl.

Any suggestions for what I might be doing wrong?

Thanks!

you are viewing a single comment's thread
view the rest of the comments

[–] restlessyet@discuss.tchncs.de 2 points 3 years ago (1 children)

It matters only if "the docker hosts external IP" your dns resolves is a public IP. In that case packets travel to the router which needs to map/send them back to the docker hosts LAN IP (NAT-Reflection). With cgnat this would need to be enabled on the carrier side, where you set up the port forwarding. If that's not possible, split-DNS may be an alternative.

If "the docker hosts external IP" is actually your docker hosts LAN IP, all of that is irrelevant. Split-DNS would accomplish that.

[–] outcide@lemmy.world 1 points 3 years ago

Sorry I'm being stupid. I'm on CGNAT at home but this is actually on a VPS.