On Nov 18, Matt Grant wrote: Hey, welcome to the mailing list and to the DebOps project! I'm sorry that it took so long for your mail to get to the mailing list. It seems that the current Postscreen configuration doesn't work well with Google mail servers. Awesome, we need more of that for the future! I myself at the moment work in IPv4-only environment for the most part, hopefully it will change someday. DebOps is written with IPv6 support in mind, if services support it they listen on IPv6 network, firewall is configured both with iptables and ip6tables, etc. There might be some kinks here and there in regards to only supporting IPv6, so if you find something let the team know. Apart for not being able to get things from GitHub - we know about it, it's Fastly's fault. :-) Either a Squid proxy on dual-stack host, or making a GitLab mirror for the things you need are the most likely solutions I would think of. I was looking into IPSEC some time ago and StrongSWAN seemed as the way to go. I would hope that it could use the debops.pki key/cert infrastructure in some way. I'm not sure about the need to define all the connections between all servers, is that really necessary in IPSEC? Can't you just make something like Tinc, with the nodes connecting to the mesh network and being able to talk to each other without the need to define each p2p connection separately? I guess this is needed for increased security and connection authorization. Anyway, it's a huge topic all on its own, I could get into it and probably will have at some point to understand it better. I haven't used netscript, I suppose it's an alternative iptables management solution? I imagine that it could be combined with ferm via hooks. Alternatively, you could replace ferm with netscript in your own set of playbooks, although that would be a bit more invovled. DebOps roles are designed in a way that role dependencies can be interchangeable and their configuration can be kept in the role default variables. Currently there's no good, preferred way to provide interchangeable roles in the playbooks, we are experimenting with nginx/apache2 and ownCloud, so we will see how that goes. Should be doable, I would aim for integration with ifupdown. I want to look into Kerberos in the future, although I was aiming more into OpenLDAP + MIT Kerberos (not sure if Heimdal is a better alternative, or has better support in Debian). Do you know how well Samba-based domain controller works with UNIX systems? As for the Samba support in general, I don't have much experience with it. The debops.samba role definitely could use some love, especially that we found out that the currently used configuration model is pretty much broken. [1] Therefore a new configuration needs to be designed. Any suggestions here are welcome, I would like to see a way to define options conditionally if that's possible. [1]: https://github.com/debops/ansible-samba/issues/14 Looking forward to it when Kerberos KDC is set up. A general rule I use in DebOps is to not have missing dependencies, for example if an application requires specific database, role for that database needs to be available first. I was considering DMS while researching BIND9 (role is not yet ready for a release[2]). Unfortunately DMS was dropped from Debian Testing [3]. Do you plan to address that in time for the Stretch freeze? [2]: https://github.com/drybjed/ansible-bind [3]: https://packages.qa.debian.org/d/dms.html This will be nice to have. I'm looking into OpenNebula at the moment since it seems to be better suited for my University's needs, but support for OpenStack will be definitely welcome by DebOps users. Some parts of the stack were requested as early as February 2015 [4]. [4]: https://github.com/debops/debops-playbooks/issues/100 I assume its baked into OpenStack? What would you want to use for this functionality? Sounds good, although to me it seems that cloud-init is more suited for preseeding/LXC templates, building VM images, where you bake in some software which contacts a configuration host and gets configuration from there. I don't see that included directly in the main playbook, but deployment of support somewhere would definitely be welcome. /etc/skel management sounds interesting, currently user accounts are managed by the debops.users role which can deploy user dotfiles via git if needed. DebOps roles and playbooks are designed more on the system side than the user (unprivileged) side. I would see this rather as a separate project which can contain only unprivileged roles/playbooks that can be executed by the users on their accounts as needed. I'm not really sure about the extent of the changes that you think will be needed. I suppose that we can see what needs to be done as we go. Currently there are a few roles that are collections of different services (debops.auth, debops.console for example), I want to split them into individual application roles so that design of customized playbooks would be easier to do. It will be done in time, lots of work ahead. Of course due to that lots of things may change in the main playbooks, so keeping an eye on the change logs is always a good idea. Project is still in the beta phase (0.x.y everywhere), but I know that people are using it in production (myself included) so I try to be careful with changes - but redesigning roles from ground up if needed is certainly possible. Sounds like most of these should be covered by the common DebOps playbook; debops.apt, debops.users, debops.authorized_keys, debops.ntp are all included in common. The support for sudo is very bare in debops.auth, a dedicated role would certainly be very handy. Networking is managed by debops.ifupdown role in a separate playbook so that it can be enabled if needed. The role was recently rewritten, you should check the documentation in the role repository [5], the one on the DebOps documentation site will be currently outdated due to issues with documentation not being built in ReadTheDocs, builds take too long and get killed. I guess that it's time for the debops.rtd role to setup our own instance. [5]: https://github.com/debops/ansible-ifupdown/tree/master/docs Can you be more specific? I tried to fix ifupdown/systemd issues by introducing a new ifup-allow-boot.service unit that starts the marked network interfaces "manually" after networking.service is finished. What interface types do you try to configure to not have IP addresses? Can you show an example /etc/network/interfaces configuration you tried to use? Some of your suggestions will be definitely welcome in DebOps. I try to keep the set of roles included in the 'common.yml' playbook reasonably generic, so that it can be used on all hosts managed by DebOps - other roles can be then added "on top" of the default base host configured with the 'common.yml' playbook. Currently there are 100+ roles in total, Ansible seems to be reasonably fast in skipping most of them when they're not in use. I estimate that we can add another 100 or so roles and playbooks before there will be a major need to redesign the playbook layout. At this point there probably will be separate playbooks for different functionalities that you will be able to chain together. DebOps is designed to be a common Ansible framework which people can use to design their environments and deploy applications on top of it. Having more diverse role catalog will certainly help with that. If you want to start contributing, I suggest that you read the DebOps Guidelines and Policies [6] so that you know what to expect. At the moment a new policy is being drafted [7] that defines how roles should be written; it might be of interest to you as well. [6]: https://docs.debops.org/en/latest/debops-policy/docs/index.html [7]: https://github.com/debops/debops-policy/pull/17 You can get access to the debops-contrib GitHub organization [8] where people put their own roles that are designed to work with DebOps. If your role is useful enough it will be moved to the main organization. There's currently no defined policy on that, so I guess that we will see how it goes. [8]: https://github.com/debops-contrib Once again, welcome to the project and I hope that you will enjoy it. :-) Cheers, Maciej