[debops-users] Destination directory /etc/pki does not exist
by russell sherman
i might be doing this wrong..
using a very simple playlist and including only the debops.pki role results in the following error.
it appears that the role attempts to write a .gitignore file to /etc/pki before the /etc/pki dir is created.
TASK [debops.pki : Ensure that sensitive files are excluded from version control] ***
fatal: [data]: FAILED! => {"changed": true, "failed": true, "msg": "Destination directory /etc/pki does not exist"}
fatal: [www]: FAILED! => {"changed": true, "failed": true, "msg": "Destination directory /etc/pki does not exist"}
hosts:
control: OSX 10.11.6
data: ubuntu/trusty64 vagrant
www: debian/jessie64 vagrant
--
7 years, 8 months
[debops-users] Proposal: debops.ifupdown removed from common playbook
by Maciej Delmanowski
Hello everyone,
In the IRC channel, ganto brought up an idea to remove the 'debops.ifupdown'
role from the common playbook and move it to a separate play, activated by an
Ansible group. After thinking about it I agree, but we wanted to hear an
opinion of the community about this as well.
The 'debops.ifupdown' role came to be because I wanted most of my hosts to be
automatically configured with network bridges, in case that the host would be
used to run virtual machines and/or containers, which is a very common
practice these days. By default it automatically sets up one or two network
bridges, depending on the host type and number of physical network interfaces.
This has two big advantages for a server:
- after running the common playbook, the host is ready to deploy virtual
machines or containers with their network interfaces connected to the same
networks as the host itself
- in cases where physical network connections are inverted, say 'eth0' is
a private network and 'eth1' is a public network, know sets of bridge names
can make this switch agnostic to the rest of the software - just set the
correct public and private network interfaces and run the 'debops.ifudown'
role to have it configure the bridges in a known layout. This advantage can
be show for example with the 'debops.ferm' role, were you could define
different rules for public and private interfaces based on the network
bridge names and have them correctly filter traffic.
Unfortunately, the current situation with 'debops.ifupdown' managing
interfaces by default in the 'common' playbook has its drawbacks as well:
- host and interface detection isn't perfect and can sometimes fail. This is
important especially for new users, who might not expect the network layout
to change, or host going offline for unknown reasons due to wrong
configuration being guessed by the role.
- some host configurations don't let you manage the network interfaces from
inside of the host itself - for example restricted Docker containers, and
similar. Some of these configurations can be detected by checking POSIX
capabilities, but that doesn't work in all cases. In such setups, the user
is forced to disable 'debops.ifupdown' entirely via inventory variable, in
which case the whole role becomes useless to him/her.
- if an user plans to use 'systemd-networkd' to manage the host networking,
'debops.ifupdown' might interfere, forcing the user to disable it, in which
case it becomes just a dead weight in the 'common' playbook.
Therefore, I'm considering removing the 'debops.ifupdown' from the 'common'
playbook. The role is used much less frequently by other roles than say,
'debops.ferm' is, so the changes to the playbook behaviour in the short run.
On the other hand, other roles that depend on known state of network
interfaces might need to be modified to use local facts which 'debops.ifudown'
will need to create to indicate what interface is the public/private one (for
example 'debops.dhcpd' might need this information to disable the daemon on
correct network interfaces).
To enable the 'debops.ifupdown' role to manage interfaces, you will need to
add a host to an inventory group. This will make a few things easier to do
- some of the automatic host detection code could be safely removed, therefore
the role will be easier to manage.
I haven't tested the effects yet, the change won't be done for sometime as
I would like to finish a different switch first - removing Postfix from the
'common' role and replacing it with nullmailer. So if you are interested,
there's time to voice your opinion and sway me in the other direction. :-)
Cheers,
Maciej
7 years, 9 months
