— 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
  • 38 Comments
Joined 2 years ago
cake
Cake day: July 10th, 2023

help-circle
  • I have a tech illiterate mother in law who I switched to Zorin OS (an Ubuntu fork).

    I installed a wireguard VPN client on her laptop and did drills over the course of 3 days to make sure that she understood how to connect. Anytime she needs help, I can tunnel through my wireguard server and log on with my own account - Heck, as long as she doesn’t change her password, I can log on as her as well.

    That has made remote troubleshooting significantly easier as she is located about a a 23-hour drive away.




  • Just to make sure.

    1. When on your home network, doing nslookup (or similar), your fqdn resolves to your public IP
    2. When on a hotspot, if you go to https://fqdn/ it does not connect (probably with the ERR_CONNECTION_TIMED_OUT that you mentioned below)
    3. When on hotspot, if you to telnet to port 443 on 206.x.x.x, it connects

    What happens if you, on the hotspot, try browsing to https://206.x.x.x? When you are on the same network as the portfolio, can you reach https://[internal ip]?

    What I’m leaning towards is a router/firewall that may be causing some issues. To help with troubleshooting, does your website server have any local firewalls (for ubuntu that would typically be ufw, but it could be iptables or firewalld)?


  • Try this command from a terminal on the system from which you’re attempting to connect:

    nslookup <yourfqdn>
    

    It should come back with something like this:

    ~  nslookup stronk.bond
    Server:         127.0.0.53
    Address:        127.0.0.53#53
    
    Non-authoritative answer:
    Name:   stronk.bond
    Address: 172.67.174.80
    

    If it says something like “can’t find” that means that your dns isn’t configured appropriately. Does your IP address start with 192.168, 10., or 172.? That would be a private IP address (something which isn’t accessible from the internet.

    Oh! And where is everything - is your workstation/laptop on the same network as your portfolio? Is the portfolio on a different network? That could effect things as well.


  • What does your nginx config look like for ssl? It should specify a certificate and key file - that certificate subject needs to match your fully qualified domain name (fqdn). Certificate can have subject alternative names (SAN) for other names and even IP addresses.

    For instance, you could have a single certificate for foo.bar with a SAN for just foo and an IP SAN for 192.168.1.30.

    Certificates also need to be signed by a certificate authority (CA), and in order for your browser to visit https://foo.bar/ without a warning your browser must trust that CA.

    If you did a self signed cert, this is most likely the problem you’re running into.

    It’s important to know that your communication is still encrypted because of SSL, but since your browser doesn’t trust the CA (or the subject doesn’t match the FQDN) the browser will say it’s not secure.



  • Not trying to be difficult, but that’s what get-member is for - it’ll dump all the properties for a given object.

    I get it - it’s way different from bash - speaking as someone who has been using Linux since Debian Hamm. Side note, net installers over dialup really sucked.

    I was originally forced to use powershell when I joined up with a virtualization team for work and they used PowerCLI.

    It was bonkers how easy it was to get reproducible scripts bundled up for the more junior engineers.




  • Speaking as someone who has recently taken on a far-remote (e.g. about 22 hour drive away) support for a MIL, the best thing you could do is set up a VPN.

    1. It works both ways (typically) so you can easily remote in to their system when they’re on the VPN for updates/troubleshooting
    2. it minimizes the hardware “on-site” at their location
    3. Depending on your VPN client, it can have an easy to use GUI, further lowering the barrier if your remote person is tech-inept

    For me, I’m still on Plex with a very old lifetime account with my MIL using a dedicated user account - that access is over the Internet. The VPN is to provide access to Overseerr so that she can do things like request specific movies/TV shows without having to email/call.

    It’s not perfect - one day I woke up to 26 seasons of “Into the Country”, but it works fairly well.

    I sat down with her one day while visiting about a year or so ago and walked her through connecting to the VPN, then getting to the hosted site, then disconnecting from the VPN - basically running drills and making her take notes until she felt she could do it by herself.






  • 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.




  • pezhore@infosec.pubtoSelfhosted@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    3 months ago

    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.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    edit-2
    3 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.