#125: Allow HTTP and HTTPS in lemmy.yml

[gigadani]

Fixes the issue #125 on Debian and Ubuntu, where letsencrypt thingie went nanners because the ports are closed.

[gigadani]

Tested. Works.

[sanatsathaye]

You don't really need that when condition btw because the playbook only runs on Debian/Ubuntu anyway.

[codyro]

As noted above, this isn't necessary as it's covered earlier in the playbook: https://github.com/LemmyNet/lemmy-ansible/blob/b6cb0ca9bb912723db9893408bd91299eeb29792/lemmy.yml#L72-L76C34

[codyro]

Would you mind updating the requirements.yml with the community.general collection?

https://github.com/LemmyNet/lemmy-ansible/blob/main/requirements.yml

I'm not as savvy with Debian/Ubuntu as I am with RHEL--does ufw ship pre-installed even on minimal installations? If not, we should only run the command(s) if the service is enabled.

[sanatsathaye]

Actually, I tested this out and it doesn't seem to work:

TASK [Allow HTTP and HTTPS in ufw] *************************************************************************************************************************task path: /home/sanat/lemmy-ansible/lemmy.yml:101
failed: [homepc] (item=http) => {"ansible_loop_var": "item", "changed": false, "commands": ["/usr/sbin/ufw status verbose", "/usr/bin/grep -h '^### tuple' /lib/ufw/user.rules /lib/ufw/user6.rules /etc/ufw/user.rules /etc/ufw/user6.rules /var/lib/ufw/user.rules /var/lib/ufw/user6.rules", "/usr/sbin/ufw --version", "/usr/sbin/ufw allow from http to any"], "item": "http", "msg": "ERROR: Bad source address\n"}
failed: [homepc] (item=https) => {"ansible_loop_var": "item", "changed": false, "commands": ["/usr/sbin/ufw status verbose", "/usr/bin/grep -h '^### tuple' /lib/ufw/user.rules /lib/ufw/user6.rules /etc/ufw/user.rules /etc/ufw/user6.rules /var/lib/ufw/user.rules /var/lib/ufw/user6.rules", "/usr/sbin/ufw --version", "/usr/sbin/ufw allow from https to any"], "item": "https", "msg": "ERROR: Bad source address\n"}

I had to change src to name to fix it (also, you don't need seperate Nginx HTTP/HTTPS rules with Nginx Full):

    - name: Allow HTTP and HTTPS in ufw
      when: (ansible_distribution == 'Debian') or (ansible_distribution == 'Ubuntu')
      community.general.ufw:
        rule: allow
        name: Nginx Full

[dessalines]

See comments above.

[codyro]

I'm not as savvy with Debian/Ubuntu as I am with RHEL--does ufw ship pre-installed even on minimal installations? If not, we should only run the command(s) if the service is enabled.

I just double checked, and it is not present on minimal installs. It looks like the ufw commands will run cleanly even if the service isn't running, so it would only error out if ufw wasn't installed at all. We should take that into account to ensure the playbook doesn't error out on minimal installs.

[ticoombs]

it is not present on minimal installs

Maybe managing firewall rules should be outside the scope of lemmy-ansible unless we have a generic way to handle it. Depending on how you setup your systems and especially if you want to run it locally (which others have expressed interest in), modifying firewall rules exposes those people to possible attacks.
Enforcing firewall rules would also encourages server-admins to host separate repos and do their own 3 way merge/pull-request every time a new version has been pushed. This may inadvertently cause issues for those admins, thus I think its safer to update the requirements rather than modify the firewalls.

Have a Debian/AlmaLinux 9-based server / VPS where lemmy will run.
Supported CPU architectures are x86-64 and ARM64.
Configure a DNS A Record to point at your server's IP address.
Allowing port 80/443 on the firewall for the automated certificate
Make sure you can ssh to it, with a sudo user: ssh @

[codyro]

it is not present on minimal installs

Maybe managing firewall rules should be outside the scope of lemmy-ansible unless we have a generic way to handle it. Depending on how you setup your systems and especially if you want to run it locally (which others have expressed interest in), modifying firewall rules exposes those people to possible attacks. Enforcing firewall rules would also encourages server-admins to host separate repos and do their own 3 way merge/pull-request every time a new version has been pushed. This may inadvertently cause issues for those admins, thus I think its safer to update the requirements rather than modify the firewalls.

Have a Debian/AlmaLinux 9-based server / VPS where lemmy will run.
Supported CPU architectures are x86-64 and ARM64.
Configure a DNS A Record to point at your server's IP address.
Allowing port 80/443 on the firewall for the automated certificate
Make sure you can ssh to it, with a sudo user: ssh @

The point of the playbooks is to get a Lemmy instance up from scratch. It should to be as frictionless as possible as most users will not be seasoned systems administrators. It's reasonable to assume that if you're running two of the stock firewalls of the supported distributions, the necessary ports for the software to run would be opened.

If I run a playbook that's installing a complete software stack with the assumption at the end I'll have a functioning piece of software, and it doesn't work--whether it be they can't reach their instance or that certbot fails out ungracefully, it leaves a lot to be desired. That is a bad user experience.

So, I'll have to disagree with your assumption in the context of this project. Punching http/https into ufw and firewalld will ensure a better UX for the majority of people using these playbooks.

IIt should be documented, though. Having a default variable that turns off punching seems reasonable to me. A middle ground could be punching on the initial installation if 80,443 aren't open already to ensure the application and certbot will run on the initial install.

Enforcing firewall rules would also encourages server-admins to host separate repos and do their own 3 way merge/pull-request every time a new version has been pushed. This may inadvertently cause issues for those admins, thus I think its safer to update the requirements rather than modify the firewalls.

What? I am not following this example, but I'll play along for kicks. Have you witnessed this in the wild or speculating?

EDIT I have some free time today. Let me make a PoC and see if you think it's a reasonable approach that would satiate both your thoughts and mine.

[codyro]

What are your thoughts on something simple like this? Another option is to use ansible.builtin.prompt to ask the user if they'd want to punch a hole in the firewall during the certificate retrieval or some combination of things.

Ultimately, I feel that most users using the playbooks to prop up an instance are looking for a seamless experience. I'd like to offer the ability for the playbook to go from nothing to a fully configured Lemmy install without additional intervention.

If you strongly feel this is a mistake, as long as we make it abundantly clear in the documentation that you'll want to ensure the proper ports are open prior to running the playbooks, we'll be okay.

@dessalines @Nutomic, if either of you have an opinion on this, please chime in.

[Nutomic]

I think opening firewall ports should definitely be included in the playbook, because the firewall is enabled by default on some vps as mentioned in the issue. I dont think a prompt is great, because some users wont understand it, so its an unnecessary hurdle. It would make more sense to check if the ufw package is installed, and if thats the case open the ports.

[ticoombs]

After thinking it over, I agree. Open the ports as part of the playbook.

Should we be using iptables instead of ufw? ansible.builtin.iptables vs community.general.ufw. Iptables would be consistent regardless of the firewall applications as unless i'm mistaken. Then we'd be able to use the same rules across all playbooks / instances regardless.

[dessalines]

If anyone wants to handle some of the firewall issues above, that can be done in a different PR.