@buca Ambas opções têm prós e contras. Na cidade há a vigilância eletrônica, câmeras pra todo lado e tal. Já no interior, existe uma rede de inteligência e espionagem assustadora formada pelas senhorinhas que ficam nas janelas ou na rua varrendo as calçadas.
@xPandeMoniax Faça-se um grandessíssimo favor e instale um gerenciador de senhas, e deixe ele gerar e gerenciar senhas aleatórias e longas que você nunca vai precisar lembrar. Eu uso Vaultwarden (self-hosted) com os clientes do Bitwarden, mas o próprio Bitwarden tem um plano grátis bem respeitável. https://bitwarden.com/pricing/
@kaia I don't know if there are any differences in the specs, but there are also PCI-e versions of this chip. I have a Mini PCI-e one on a NUC doing person and object detection in Frigate, and it works fine.
For Syncthing, this is it: https://pastebin.com/Rn6K1U14 I'm not mapping ports in the Compose file because I have it routed through the reverse proxy with TCP/UDP streams. Also, that last label is something I'm still working on, not ready for release yet, but it basically automates the network conn. to the reverse proxy.
@mangeurdenuage@kaia It works well, and performance is better than using their public servers, but setting up the encryption key on every new client is a bit of a hassle.
@xPandeMoniax Se quiser vender a alma ao tinhoso, a Oracle oferece uma VPS free-tier sem limite de tempo. É uma máquina virtual ARM com Linux e IP público, dá pra instalar e servir qualquer coisa lá. Caso for por esse caminho, recomendo ler as letras miúdas pra não sair dos limites do free tier e receber cobrança. https://www.oracle.com/br/cloud/free/
I don't know when this change was implemented in PiHole, but sharing just in case it helps someone:
If you have previously used the dnsmasq workaround to have multiple conditional forwarders in PiHole, this feature is now directly supported in the UI, but the caveat is that the old workaround no longer works, you need to move it from the .conf files to the UI. #PiHole#DNS#SelfHosted
@hfaust As someone who has just done that, and following the "easy route" even (Mailcow), I wholeheartedly agree. There's so much that can go wrong even if you do everything right. It's like a rite of passage for computer-touchers, not your ordinary self-hosted service.
@cadusilva Trying to simplify a bit, imagine your server running Mailcow has the public IP 1.2.3.4, the fqdn mx.example.com, and a matching PTR.
You setup Mailcow with this as the hostname, then add the domains example.org and example.net. Both domains will need MX records pointing to mx.example.com.
When adding an account from one of these two domains to Thunderbird, it'll auto-populate the server field with that MX address instead of your domain.
@cadusilva One other thing to be aware of: if you're trying to keep your domains somewhat "secret" from each other, Mailcow adds all the names in the same certificate and uses this certificate for all domains.
@cadusilva I couldn't wait and ended up migrating over the other domain today too. One catch I didn't anticipate is that whatever you use as the MX record needs a matching PTR record, and you can only have one PTR, so all your domains will have the same MX (which doesn't even need to be in those domains, it can be associated with a 3rd unrelated domain). The only downside of this is that this MX host will be used everywhere for auto configuration, which is a bit annoying.