AnsibleUndefinedVariable: 'postgres_password' is undefined

[sanatsathaye]

Got this when running both lemmy.yml and lemmy-almalinux.yml

TASK [Add the config.hjson] 
/********************************************************************************************************************************
task path: /home/sanat/lemmy-ansible/lemmy-almalinux.yml:140
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ansible.errors.AnsibleUndefinedVariable: 'postgres_password' is undefined. 'postgres_password' is undefined
fatal: [127.0.0.1]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: 'postgres_password' is undefined. 'postgres_password' is undefined"}

I believe this is happening because our vars.yml is inside inventory/host_vars/{{ domain }}/ rather than inventory/host_vars/ itself as per documentation.

I already have a fix for this in my local machine:

vars_files:
    - inventory/host_vars/{{ domain }}/vars.yml

That said I'm not sure if there are plans to change anything around variable centralisation again, or if anyone else has a suggestion to solve this in a different way so creating an issue for discussion.

[codyro]

Can you show me what your inventory looks like? This likely relates to a concern @ticoombs brought up in that PR. The file should automatically be imported--assuming the inventory hostname matches your {{ domain }}. Ansible would then autoload host_vars/inventory/<inventory hostname>/*.yml,etc.

For example, in testing, I use foss.ly. My inventory and directory tree looks like the following (and works):

hosts

[lemmy]
foss.ly ansible_user=root domain=foss.ly letsencrypt_contact_email=cody@blahblah.com lemmy_base_dir=/srv/lemmy

$ tree  inventory/host_vars/foss.ly
inventory/host_vars/foss.ly
├── config.hjson
├── customPostgresql.conf
├── passwords
│   └── postgres.psk
└── vars.yml

The assumption I was making was the hostname in the inventory would match {{ domain }} most of the time, however, that appears not to be the case.

As such, we should avoid making this assumption or document things accordingly.

Mea culpa @ticoombs :(

[sanatsathaye]

Oh lol, I was running this completely locally on my Windows machine using WSL and Vagrant. I just kept my PC's name in the inventory and something random as the domain as I thought that wouldn't matter, and I've setup workarounds to bypass certificates ¯\_(ツ)_/¯

sanat@HOMEPC:~/lemmy-ansible$ cat inventory/hosts
[lemmy]
# to get started, copy this file to `inventory` and adjust the values below.
# - `myuser@example.com`: replace with the destination you use to connect to your server via ssh
# - `ansible_user=root`: replace `root` with your the username you use to connect to your ssh server
# - `domain=example.com`: replace `example.com` with your lemmy domain
# - `letsencrypt_contact_email=your@email.com` replace `your@email.com` with your email address,
#                                              to get notifications if your ssl cert expires
# - `lemmy_base_dir=/srv/lemmy`: the location on the server where lemmy can be installed, can be any folder
#                                if you are upgrading from a previous version, set this to `/lemmy`
# - `lemmy_version`: <Optional> The back end version.
# - `lemmy_ui_version`: <Optional> overrides the front end version.
homepc ansible_user=vagrant domain=test.in  letsencrypt_contact_email=your@email.com  lemmy_base_dir=/srv/lemmy #Ubuntu
127.0.0.1 ansible_user=vagrant domain=test.in  letsencrypt_contact_email=your@email.com  lemmy_base_dir=/srv/lemmy ansible_port=23 #Alma

[all:vars]
ansible_connection=ssh

I can confirm this worked after doing a host entry to my machine as the domain name I chose and configuring that domain name in the inventory/hosts file...

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateHosts = false
127.0.0.1       localhost test.in
127.0.1.1       HOMEPC. HOMEPC

[sanatsathaye]

I'm not sure if the current setup will work on more... let's say exotic installs, like if someone decides to deploy a lemmy instance which is load balanced across servers. I mean I have no idea if the rest of the lemmy infrastructure can actually handle this setup but let's assume it can :D

I haven't tried this out much, but maybe instead of host_vars you can make use of group_vars? We have lemmy hardcoded as the group name so inventory/group_vars/lemmy can be created as part of the installation instructions and the vars moved there, with warnings in documentation to absolutely not touch that group name.

Not sure how that will affect the rest of the files already in host_vars though, that will need looking at. And using group_vars would mean all servers in that group will have the same config such as passwords which has its own pros and cons I suppose.

[RedKrieg]

I spent some time on this today and I believe there are some issues with the new vars.yml system for existing installs of lemmy-ansible.

1. The postgres password file is renamed from passwords/postgres to passwords/postgres.psk in a8c859d. This was done to prevent ansible from trying to parse it as yaml, but it should be documented and the README should be updated accordingly (it currently still says users should use the passwords/postgres path when migrating).
2. Prior to 31631d2 user names were expected to be part of the host name in the hosts file, meaning that the built-in inventory vars system was looking in the wrong place (user@domain instead of just domain) for host_vars.

Obviously ansible_user is a better choice here, and moving more variables in to inventory is good, but existing users will expect that a git pull and a check of the upgrading docs is all they should need to do when upgrading.

For those seeing the error in the title, change your hosts file to use ansible_user instead of user@ (see examples/hosts). After that, rename inventory/host_vars/<your_domain>/passwords/postgres to inventory/host_vars/<your_domain>/passwords/postgres.psk.

[codyro]

The Upgrading documentation could be improved to reflect that change--it looks like I missed it in the original PR. I've made an issue at #170 if you have time to provide feedback and or submit a PR to address it.

[ticoombs]

These are not exotic installs but regular installs which we have no control over. As @RedKrieg also surmised we were never using host_vars correctly before and always imported the various variables that we needed. The folder "host_vars" was never used for the hosts.

Forcing our ansible code to be on a single-homed host also reduces the flexibility of the code. Sure at the moment we are non-HA, but with the changes pictrs is making, we could easily be HA after that (assuming people don't use our postgres and use a hosted db service which others already do). While there isn't a plan set forth it is worth having it in the back of the mind.

I like @sanatsathaye 's idea on using group vars. To build on that instead of lemmy I would like to have it as {{ domain }}. (A required manual change that people need to do as part of the cp example/vars.yml group_vars/{{ domain }}/vars.yml.

That would:

• make it easier for people to deploy to multiple domains (add all the servers to a new section in the inventory file).
• allow for logical segmentation of our various variables (per domain as a folder)
• allow for people to deploy to many servers (in the future)

---

So I propose a 3 step solution:

1. Quickly fix all current ansible solution is to (as OP said) add:

I already have a fix for this in my local machine:

vars_files:
    - inventory/host_vars/{{ domain }}/vars.yml

This ensures that we no longer break existing ansible installs and people can get back to doing what they do best.

2. Fix our documentation, and create new version tags.

We also need to update the documentation and possibly at this point in time start versioning our pushes to main. I suggest making the previous commit (31631d2) v1.1.0
We then update the documentation to always show the latest stable and anything that is not backwards compatible we increase the major release version. (Following semver.org)

We need to start versioning to ensure we don't break peoples ci/cd pipelines.
This will allow us to merge to main without having to worry about creating breaking changes or worry about creating hotfixes.

3. Migrate from host_vars to group_vars for allowing future proofing (and the possibility of multi-server deployments)

host_vars are fine but group_vars is 👌
drake-meme hostvars vs group_vars

This can be scheduled as our (lemmy-ansible) next major release with notes on upgrading. Also as it currently stands we can easily backport the "version" fixes.

@dessalines and @Nutomic have more than enough on their plates and is most likely the reason they added us to the lemmy-ansible repo.

---

I know I've gone slightly off topic here but it seems as good as any place.

[sanatsathaye]

+1 on the versioning of this installation guide, along with a documented changelog. These scripts have changed a lot in the past month and it would be quite problematic for people using this solution to upgrade existing installs if they're not made aware of the exact changes. Without that most would simply use a git pull and expect this to work every time, and it wouldn't be their fault.

[dessalines]

Yep I'd very much appreciate if someone could PR Upgrading subsections.

[codyro]

I'm going to close this in favor of #171 which was created from the discussion above.