• 0 Posts
  • 320 Comments
Joined 1 year ago
Cake day: February 15th, 2025
  • HelloRoot@lemy.loltoSelfhosted@lemmy.world•Proxmox Homelab - Docker Swarm Still Viable? Using Different Distros as VMs?English
    21·
    2 days ago

    I’ve been running it for 2 years.

    The swarm support integration is first class, but there is not much to do in the gui, you can add nodes and see basic info about them and thats it basically.

    Most of the stuff happens in the compose files where you can define how many copies of a container you run and what nodes you want to restrict them to. etc.

    I’m not sure about the moving features tbh. It should move them automatically when a node is down. In my setup I don’t use that at all, all my containers are pinned to specific nodes by feature flags (one node has lots of hdd storage, another has more ram, another has a gpu).

    You can see the container logs, but you have to select “swarm” in a dropdown when the container is not on your master node.

    And also when deploying a new app you have to select “Compose” and then in a further dropdown “Swarm”.

  • HelloRoot@lemy.loltoSelfhosted@lemmy.world•How to self-host Wordpress site on Njalla domain?English
    3·
    25 days ago

    Sounds good.

    Hmm next you probably should confirm ports 80 and 443 are actually reachable from the internet.

    Use an online port checker like https://canyouseeme.org/

    After that you should check your apache config like somebody else already suggested. I haven’t used apache in a while but if I remember correctly:

    Ensure it says: Listen 80 NOT: Listen 127.0.0.1:80

    (and same with 443)

    Also check your VirtualHost — it should look something like:

    <VirtualHost *:80>
    ServerName yourdomain.com
    DocumentRoot /var/www/wordpress
    # ... other settings
</VirtualHost>

    (and same with 443)

  • HelloRoot@lemy.loltoSelfhosted@lemmy.world•How to self-host Wordpress site on Njalla domain?English
    72·
    25 days ago

    Njalla’s default TTL for DNS records is 3600 seconds (1 hour). If you just created or modified the A record, it can take up to that full hour for the change to propagate across the internet, which would perfectly explain why Certbot is connecting to the right IP but failing to fetch the file (the request might be hitting an old IP or a cached null response).

    Before changing any more configurations, you should verify what the rest of the internet is actually seeing for your domain right now.

    Check the current DNS record

    You can usedig to see exactly what IP your domain is resolving to, and importantly, the remaining TTL on that record.

    From your local machine (or any computer), run:

    dig yourdomain.com +noall +answer

    This will output something like:

    yourdomain.com.    3412    IN      A       203.0.113.45

    The second column (3412) is the remaining TTL in seconds. If that number is counting down from 3600, the record is still propagating. If the IP address shown there doesn’t match your server’s current public IP, the change hasn’t taken effect yet for that DNS server.

    Check from a different perspective

    To ensure it’s not just your local ISP or router cache serving an old record, query an external public DNS server directly:

    dig yourdomain.com @1.1.1.1 +noall +answer
dig yourdomain.com @8.8.8.8 +noall +answer

    If these external servers show the correct IP but Certbot still fails, the DNS is fine, and the problem is somewhere in your network routing or web server config. If they show a wrong IP or no record at all, you simply need to wait for the TTL to expire.