Re: [debops-users] Proposal: debops.ifupdown removed from common playbook

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

-----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXk07RAAoJEIb9mAu/GkD4O94QANMR+kqceaGALLVW9tRu1HJo d7GcJsdYDj5vqRf5JHJc2CJd7xc1XJYgqnjuvY/OAgSS2NoUeKSw1PPkaUEKc1Ty s3rqQ/jzGfW0nS4t2wfh+qA9r9k4Z6yeiAECKopNXEmvQsY8wKQDU5N4C4OxCvND 6JEyQRvdUfLRugd76xOhtiZqSAfChsAcl7cPXGypDKsQ+Eq8eZCCy1o9Tu1p0faW HLCtZDnGyWhnxVf5mYU2IEFw5EtexOhUfmzbicUbWcYJjqrIFcARPN4CYcbAa/wF o6pWCo9w29PFuq0wzLzLEhAsctabZaEWJde8jADtek+hja4dkRCgpwBjxTkD2XVw So3hIL0fAwbV5ngFiDZLd95VRpcDZfJC8FA/fzTG8YQhCwid0VB8SJ435+5+OcHz a42Ogw+2YKtExmv44TkEO7sU5NaO3eZpkSTPeDvzCXweIBbLEoF27Mr6MYD8fNZV mE91XkjaGE2zZS8Ee35Sy+CH4F41r3PbPF84YDuDtkVFVqBpJpFQG8n3FKtgDSJu jI8E83In0jM4pecjtS70QJyUQ/ZEWDf8QRc9jgUyZ6Cfqu9+ZeUZr1+I3Qx3oVnV 55GwcZpqh5vw/T8yGAd2mjBLdjNi42mvX1BdJdSUwmgj4xOm5puXlNrkTQ5BthA5 EC51QFObqzVqXSXVg2/O =Qjqz -----END PGP SIGNATURE-----