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.
1) IPv6 only systems
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.
2) Strongswan IPSEC for sustained connection security. With
points such as between servers, much more efficient as SSL Encryption
session does not have to be negotiated per TCP connection, far more secure
than SSL as all key material in kernel not user space, not withstanding
better protocol design.
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.
3) netscript IP address and interface managerment
4) netscript IP tables combined with ferm
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.
5) Open vswitch set up
Should be doable, I would aim for integration with ifupdown.
6) Samba as AD controller and kerberos server
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. 
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
7) kerberos client set up
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
8) Set up and configuration of DMS
I was considering DMS while researching BIND9 (role is not yet ready for
a release). Unfortunately DMS was dropped from Debian Testing . Do you plan
to address that in time for the Stretch freeze?
9) Set up and configuration of openstack
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 .
10) 'Thin' cloud mode for quickly deploying short-lived cloud
demand. Won't need all the security bells and whistles, just an ssh-keyed
I assume its baked into OpenStack? What would you want to use for this
11) integrating with cloud-init
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.
12) site local role for all those things that stroke an individual
fancy like /etc/skel shell mode support...
/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.
The thin mode and the work on ferm/netscript iptables are core
functionality changes. If you think all this will make debops far too top
heavy let me know.
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
At the moment my needs for Opens stack dev are for quickly deploying
platform initialisation as I am bringing up 10-20 systems quickly (Apt,
user accounts, ssh keys, NTP, sudo, dns common stuff), and then manually
configuring each platform and using backup to store those details.
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
, 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.
In my set up there is quite a bit of netscript involved due to
ifupdowns inability/refusal to up network interfaces with NO addressing on
them ;-( (Needed for firing up and connecting open vswitch as I use a lot
of VLAN trunking, and soon VXLAN).
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?
I can understand if you don't want me to push all this stuff onto
as there is quite a lot of complexity in it already. Please let me know if
this architecture here is too far different from the depops hosting
platform model to try blending it in.
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
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  so that you know what to expect. At the moment
a new policy is being drafted  that defines how roles should be written; it
might be of interest to you as well.
You can get access to the debops-contrib GitHub organization  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.
Once again, welcome to the project and I hope that you will enjoy it. :-)