— GPG Proofs —

This is an OpenPGP proof that connects my OpenPGP key to this Lemmy account. For details check out https://keyoxide.org/guides/openpgp-proofs

[ Verifying my OpenPGP key: openpgp4fpr:27265882624f80fe7deb8b2bca75b6ec61a21f8f ]

  • 0 Posts
  • 46 Comments
Joined 2 years ago
cake
Cake day: July 10th, 2023

help-circle



  • pezhore@infosec.pubtoTechnology@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    15
    arrow-down
    1
    ·
    22 days ago

    When I bought my Hyundai they pushed fucking hard to sign up for their Blue link product. Free for life! Look, map updates! You can personalize your driver profile pic! Want to remote start your car over the Internet?

    Luckily, my VIN wasn’t working for registration (I guess it hadn’t quite gone through fast enough that the car was purchased). I’ve gone two months without BlueLink and I’m hoping that’s saving me from some of the info gathering (or at least it’s not directly linked to me.





  • Yeah, that’s the other thing to keep in mind, since the KVM APIs are different from the vSphere APIs, you can’t just swap providers without changes. But if you were going from a test vSphere stack to a prod, you could update the endpoint and be just fine.

    Hashicorp has caught some shit in the past about claiming the code covers multiple providers. Technically, it can if you do weird shit with modules, but in reality there isn’t a clean way to have a single, easily understandable project that can provision to multiple platforms.


  • nothing about it is common or portable, so if you change your VM host, it might all fall apart.

    Disclaimer, I’m pretty much elbow deep into terraform daily and have written/contributed to a few providers.

    A lot of this is highly dependent upon the providers (the thing that allows the Terraform engine to interface with APIs for AWS, Proxmox, vSphere, etc. The Telmate Proxmox provider in particular is/was quite awful with not realizing a provisioned VM had moved to a new host.

    Also, the default/tutorial code tends to be not very flexible. The game changer for me was using the built-in functions for decoding yaml from a config file (like yamldecode(file(config.yml)) in a locals block. You can then specify your desired infrastructure with yaml and (if you write your Terraform code correctly) you can blowout hundreds of VMs, policies, firewall rules, dns records etc with a single manifest. I’ve also used the local_file resource with a Terraform file template to dynamically create an Ansible inventory file based on what’s deployed.





  • Not really, but I can give you my reasons for doing so. Know that you’ll need some shared storage (NFS, CIFS, etc) to take full advantage of the cluster.

    1. Zero downtime for patching. Taking systems offline to update Proxmox sucks, especially if the upgrade fails for some reason. A cluster means I can evacuate one host, upgrade it, and move on to the next with no downtime for the hosted VMs.
    2. Critical service resiliency. I have a couple of critical systems in my home lab that, if they unexpectedly go down, will make for a very bad day. For instance, my entire home network (and lab) is configured to use a PowerDNS cluster for DNS. I can put the master PowerDNS server on one host and the slave on a second host - if I have a hardware failure, I won’t lose DNS. I have a similar setup for my Kubernetes cluster’s worker nodes.
    3. Experimentation. A cluster gives me a larger shared pool of CPU/Memory than my single host could offer. This means I can spin up new VMs, LXC containers, etc and just play with new software and services. Heck that’s how I got started with my Kubernetes cluster - I had some spare capacity so I found a blog post that talked about Kubes on LXC containers and I spun it up.

    I hope that helps give some reasons for doing a cluster, and apologies for not replying immediately. I’m happy to share more about my homelab/answer other questions about my setup.






  • Sorry, I wasn’t clear - I use PowerDNS so that I can more easily deploy services that can be resolved by my internal networks (deployed via Kubernetes or Terraform). In my case, the secondary PowerDNS server does regular zone transfers from the primary in order to ensure it has a copy of all A, PTR, CNAME, etc records.

    But PowerDNS (and all DNS servers really), can either be authoritative resolvers or recursors. In my case, the PDNS servers are authoritative for my homelab zone/domain and they perform recursive lookups (with caching) for non-authoritative domains like google.com, infosec.pub, etc. By pointing my PDNS servers to PiHole for recursive lookups, I ensure that I have ad blocking while still allowing for my automation to handle the homelab records.


  • pezhore@infosec.pubtoSelfhosted@lemmy.worldHow do you host your DNS sinkhole/resolver?
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    edit-2
    2 months ago

    This is overkill.

    I have a dedicated raspberry pi for pihole, then two VMs running PowerDNS in Master/Slave mode. The PDNS servers use the Pihole as their primary recursive lookup, followed by some other Internet privacy DNS server that I can’t recall right now.

    If I need to do maintenance on the pihole, power DNS can fall back to the internet DNS server. If I need to do updates on the PowerDNS cluster, I can do it one at a time to reduce the outage window.

    EDIT: I should have phrased the first sentence: “My setup is overkill” rather than “This is overkill” - the Op is asking a very valid question and the passive phrasing of my post’s first sentence could be taken multiple ways.