[role:debops.apt] Get rid of the `if not FreeBSD` lines for facts gathering

[AnotherKamila]

On FreeBSD, I set apt__enabled to False, and therefore most tasks in debops.apt are not run, which is correct. However, the tasks related to gathering facts should be run: it is a fact that apt is not configured on the machine, so the /etc/ansible/facts.d data should reflect that.

Currently, if I let those two tasks run with setting apt__enabled to false, debops bootstrap fails.

To work around that, I have disabled the two tasks on FreeBSD. This is not correct though, as explained above. The right way to handle this would be to fix those two tasks, so that they can run with apt__enabled: false.

Therefore, the task is:

• Check whether upstream debops fails on a Debian host with apt__enabled: False.
• If yes: fix that in upstream; if not: find out what's broken and fix it in my repo.

[drybjed]

I can tell you that apt__enabled: False works as expected on a Debian host. What task fails? And please include the title of the task so it's easier to find.

[AnotherKamila]

Confirming: this only happens on FreeBSD hosts, even with my fork.

I am running debops bootstrap, so that's where debops.apt is being called from.

This is the error I am getting:

[...]
TASK [debops.apt : Make sure that Ansible local facts directory exists] **********************************
ok: [bsdops-test] => {"changed": false, "gid": 0, "group": "wheel", "mode": "0755", "owner": "root", "path": "/etc/ansible/facts.d", "size": 4, "state": "directory", "uid": 0}

TASK [debops.apt : Save APT local facts] *****************************************************************
fatal: [bsdops-test]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: Unable to look up a name or access an attribute in template string ({{ apt__default_sources_state if (apt__architecture in [\"armhf\"] and (\"cape_universal\" in ansible_cmdline) or (\"bone_capemgr\" in ansible_cmdline)) else \"absent\" }}).\nMake sure your variable name does not contain invalid characters like '-': argument of type 'StrictUndefined' is not iterable"}

PLAY RECAP ***********************************************************************************************
bsdops-test                : ok=3    changed=0    unreachable=0    failed=1   

I am also running into a separate issue (I think the recent debops.netbase changes may have broken things with VMs accessed over port forwarding on localhost, maybe?), investigating both.

[drybjed]

Hmm, missing ansible_cmdline variable in Ansible facts?

With debops.netbase, you might need to modify the netbase__domain to have:

ansible_ssh_host|d("0")

instead of

ansible_ssh_host

in the condition. I'm aware on the issue, fix will be pushed when I finish working on better Gitlab CI infrastructure.

[AnotherKamila]

You are right in both, of course.

debops.apt: It appears that ansible_cmdline is not supported on FreeBSD (that variable is not there when I run debops-task -m setup). I will look at why it is needed, whether it is needed on FreeBSD, and whether I should add support for it in Ansible. Thank you!

debops.netbase: I assume my problem is caused by having the hosts only in .ssh/config: my "hostnames" don't actually resolve via DNS and I normally don't mind, because my .ssh/config points to IP addresses (or, in case of VMs, to localhost). I will wait for the fix then. Thanks!

[AnotherKamila]

Ah! I was reading through debops/debops#620 (thanks @evilham for the pointer!), and it would appear I am using debops incorrectly: from there: "don't we already assume that the ansible inventory name is the FQDN?" So there lies my problem: in my case it is not the FQDN, because my VMs don't have FQDNs.

Is that true? Did I miss this in the DebOps documentation, or does it need to be added there? And perhaps, what is the expected workflow for things like VMs, should I have an entry for them in /etc/hosts so that they resolve?

[drybjed]

DebOps is designed around the hosts having a proper DNS domain configuration, with working FQDNs. The debops.netbase role is able to extract the FQDN and domain information from the Ansible inventory when it's defined like this in ansible/inventory/hosts:

hostname ansible_host=hostname.example.org
hostname.example.org ansible_host=192.0.2.1

NB, now I think that I should add another shorthand to the debops.netbase to extract the FQDN from, so that a third way could be possible:

hostname ansible_host=192.0.2.1 fqdn=hostname.example.org

All of the hosts on the network should see an uniform view of the DNS database. The hosts don't have to see the same IP addresses (for example an external IP address on a given DNS record can differ from an internal IP address seen from the inside) but ideally specifying the same DNS record should point you to the same host. If you don't have a DNS server handy then sure, you can add the required entries to /etc/hosts files.

And of course this has to be added to the documentation at some point.

[AnotherKamila]

@drybjed that makes sense, thanks! I believe this not explicitly stated in the docs, so yes, perhaps it should be. (I'd offer to help, but I don't feel confident enough, given that I didn't even know this until now. Also, what you just wrote is pretty much what the docs need, I think!)