The lack of version is the problem. Syntax has changed over time, so when someone finds or has an older compose file, there is no hint it won’t work with the current version of docker-compose until you get errors and no graceful way to handle it.
Compose doesn’t have a versioned standard, it did for a bit iirc, which also means you can’t always just grab a compose file and know it will always just work.
Most self hosted works fine with giant all in one containers, even for complex apps, it’s when you need to scale you usually hit problems with an all in one container approach and have to change.
If Phillips wrote the plugin it might but all the plugins I have looked at are written by the community. Most plugins are only polling based, so they are scraping data into HAs recorder plugin.
By syncing data, it isn’t all data, just that it requires non-local resources, ie cloud/API, to function. You do have to look at each integration to see what it is doing, I would expect a Spotify integration is just hitting the Spotify API and maybe can interact with local devices that Spotify can stream to (ie a Chromecast)
It’s anything acidic from what I have found/read, the pamphlet that comes with mine mentions it. You can get a strong and longer lasting effect if you take calcium carbonate (aka antacids) around the same time.
The main benefits to paying for certs are
The only thing that matters to most people is that they don’t get cert errors going to/using a web site, or installing software. Any CA that is in the browsers, OS and various language trust stores is the same to that effect.
The rules for inclusion in the browsers trust stores are strict (many of the Linux distros and language trust stores just use the Mozilla cert set), which is where the trust comes from.
Which CA provider you choose doesn’t change your potential attack surface. The question on attack surface seems like it might come from lacking understanding of how certs and signing work.
A cert has 2 parts public cert and private key, CAs sign your sites public cert with their private key, they never have or need your private key. Public certs can be used to verify something was signed by the private key. Public certs can be used to encrypt data such that only the private key can decrypt it.
That would still technically be a math problem. I’m not sure if it falls in combinatorics, statistics/probability, or scheduling, but I’ve had problems like this on math and cs exams.
I’ve been dealing with lawyers and court recently, they may be above average in terms of intelligence and drive but most wouldn’t be extremely above that average. I’ve had to explain fairly basic math, with easy numbers (fractions like 1/2 and 1/3 regarding pay structure), several times already. Ie
Still had to explain that bonus is 1/3 total not 1/2 total.
Taxes on $300k in a year would make it impossible. Would probably have to make $400k in a year to have a chance with expenses and living frugally or 2-3 years @ $300k/year.
Short answer no, but you can add the source IP as part of the http header https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/ then you have to log that bit of the header at the app level.
There can be ways of your are using ipv6, basically turning your cloud host into a router, but but ipv4 you would have to have a 1:1 mapping and setup the routing carefully to make it work.
I’m at 56g for connect (+9g for Lemmy and +35g for boost) in the same time period. The last time period had me at 81g for boost, so I am fairly sure I am the problem in my case 😅
You can add net_admin to the user running podman, I have added it to the ambient capability mask before, which acts like an inherited override for everything the user runs.
Wildcard DNS entries are not part of an RFC afaik, so the behavior is completely determined by the dns software in use. AD and I think bind state to only use them in an otherwise empty zones, though one case I have at work we have to have the wild and an A record in the zone. Hit strange intermittent failures to resolve without the record in for some reason.
Rereading what you have in the zone file, if that is a standard bind zone file, a subzone definition would look like
` ; sub-domain definitions $ORIGIN local.example.com.
What you have might work, but doesn’t follow the dns RFCs the dns label is “*.local” in the “example.com” zone/domain.
This may come up after you get the API to the public DNS provider working, as the software will add/update a “_acme-challenge” label in the zone you point it to which would be “example.com”
If the dns provider makes setting up a proper subzones hard, you can work around it by adding a cname record
_acme-challenge.local in CNAME _acme-challenge.example.com
I assume you have purchased as public domain (the example.com bit) and have it setup to be publicly resolvable, even if the records are hosted on cloudflare or something.
You don’t need any A records for the dns01 challenge from lets encrypt. You need a text record for _acme-challenge.local.example.com that you can update with what ever challenge string let’s encrypt replies with when you request the *.local.example.com certificate.
Guessing the error is from caddy and it is saying it can’t find the public provider of that zone to update the txt record for the challenge. Even if you have the correct provider configured, does local.example.com exist in the public DNS server config?
As a side note, after the cert is issued the _acme-challenge txt record can be deleted, just be aware all issued public certs are easily searchable by domain name.
Modern UEFI in boxes has http boot options generally, and ipxe has supported http boot a long time. though I still get the grub2 bootloader bits over tftp, then http for kernel and initrd.