If you’re sure you’ve got a DNS entry for the Pihole FQDN pointing at Traefik, open the dev panel in your browser (F12), switch it to the Network tab, and visit the pihole URL.
See if you get anything back and especially take note of the HTTP status codes.
Can you see the router and service in the Traefik dashboard and do they show any errors there?
I think you’re close.
You need to change service: pihole-rtr to service: pihole-svc.
Do I have to redefine all of the same information I did in my Traefik yml but in this separate config.yml?
No, you just need to reference it like you have. Define once, reference many.
No worries for the question. It’s not terribly intuitive.
The configs live on the Traefik server. In my static traefik.yml config I have the following providers section, which adds the file provider in addition to the docker provider which you likely already have:
providers:
docker:
endpoint: "unix:///var/run/docker.sock"
exposedByDefault: false
file:
directory: /config
watch: true
And in the /config folder mapped into the Traefik container I have several files for services external to docker. You can combine them or keep them separate since the watch: true setting tells it to read in all files (and it’s near instant when you create them, no need to restart Traefik).
Here is my homeassistant.yml in that folder (I have a separate VM running HASS outside of Docker/Traefik):
http:
routers:
homeassistant-rtr:
entryPoints:
- https
service: homeassistant-svc
rule: "Host(`home.example.com`)"
tls:
certResolver: examplecom-dns
services:
homeassistant-svc:
loadBalancer:
servers:
- url: "http://hass1.internal.local:8123"
Hope this helps!
I use the Traefik file provider for this.
https://doc.traefik.io/traefik/providers/file/
It picks up all my .yml configs in the watched folder which define the routers and services external to Docker.
FYI, making you the product is only a tiny part of their stated reasoning:
What the fuck are you on about? Are people traveling with an entire Lowe’s warehouse in their fucking luggage?
That’s good advice, especially when traveling internationally.
Also when traveling to another country, always check the state department’s travel advisory for your destination(s).
Obviously this is the US state department, but it is still good info and I’d assume other countries have something similar.
Their country, their rules. One bullet can still kill someone. Play stupid games, win stupid prizes.
Most likely it was a password stuffing attack. If they used the same password on multiple sites, there is a good chance one of those other sites was compromised and the attackers took the compromised credentials and tried them on other sites like Instagram. It could have been something more advanced like a stolen cookie, but usually the simplest explanation is most likely.
Always use a different password for each service, enable MFA where possible, and use a password vault like Bitwarden.
In that case, if CF is taking to Traefik and not the actual origin server, you just need to forget about the origin certs altogether and use LE certs in Traefik.
If you, Traefik, and your origin server are on the same network, then it’s going to be one hop regardless of whether you’re hitting the Traefik proxy or the origin server. If Traefik is serving up the origin server’s cert and not the LE cert, then Traefik is misconfigured to pass through instead of proxy, but I’m still not sure that’s the case as it’s almost harder to configure it that way than the correct way as a proxy.
What IP:port is your origin server listening on, what IP:port is Traefik listening on, and how is Traefik configured to reach the origin server?
You said Traefik is getting certs from Cloudflare, but do you mean it’s getting Let’s Encrypt certs using a CF DNS challenge? And if that is the case, then your browser should trust the Traefik endpoint since LE certs are publicly trusted.
Are you sure you’re hitting Traefik when you get a cert warning? You need to update your internal DNS if not.
Third. The first thing I mention when one of my clients asks anything about PCI is to offload as much card processing onto third parties as possible.
And if you have nothing in place yet, then 100% offloaded should be possible (with the possible exception of secure payment terminals if you need to process physical cards).
That said, it is still possible to use your own hosted WordPress storefront and offload the payment processing via tokenization or redirection. But a turnkey solution like Shopify might be better if you lack the experience.
Can we just skip to that? Pretty please??
Adding my vote for Zabbix. It was a bit of a bear to set up and I had to write custom scripts to install the agents with TLS settings that were secure enough for me, but once it’s all set up it’s amazingly easy and intuitive to use and incredibly customizable.
FWIW I use it every day and it still works perfectly. I’m not sure what updates everyone is expecting, but things seem perfectly normal to me.
This is the answer. Although you may need to look up the IP address (a lot of them use 192.168.100.1) and you may need to reconfigure your gateway/firewall/router to route that subnet out its WAN interface while still performing NAT.
https://mrdoob.com/lab/javascript/effects/solitaire/
Enjoy!