Check-in
by Imre Jonk
Hi all,
TL;DR: we need to talk about keeping DebOps the awesome and healthy
project that it is today, for many years to come. Please voice any
concerns you may have. Also, some battle history, cuz' Maciej is a
sucker for war stories.
Let me start off this lengthy email by congratulating everyone involved
in this project with the sheer progress that we made since DebOps
0.8.1, which is the first DebOps release I got to use. In production
mind you, which may or may not have pressed Maciej to pull forward his
1.0.0 release [1].
There has been even more progress since genesis [2] (is that where the
'ginas' name came from, Maciej?). I had just started my System and
Network Engineering education at the AUAS and landed my first job as a
Debian (or initially, Ubuntu) system administrator at Bits of Freedom.
It would have been good to know a thing or two about Ansible and IT
automation back then. But I got an O'Reilly book on that subject a few
months into the job, so that was nice.
After some time I had been using Ansible for about half a year at Bits
of Freedom, but wrote all playbooks from scratch. They weren't exactly
the best quality and I still felt like I was working hard, not smart. I
had trouble reusing my own roles and had difficulty solving some
automation problems which resulted in me still doing a lot of manual
sysadmin work. This of course felt more like putting out fires instead
of real progress. I thought that Docker could save me, but no, that
only made it worse because now I still had the exact same automation
problems, but with the added complexity of container lifecycle
management.
Then, somewhere at the end of february (or beginning of march) 2019, I
decided to give this "data center in a box" thingy a try. I had just
landed my second sysadmin job at CipherMail, where the previous admin
had been doing everything by hand. Long story short, I turned off the
very last legacy, hand-managed VM last week. We now run ~45 servers
across multiple data center locations and cloud providers. There are
high availability setups in there, like our DNS, LDAP, RADIUS, mail and
web clusters. We have firewalls, load balancers, DNSSEC, Let's Encrypt
and IPv6 everywhere. Our office wifi has WPA2 Enterprise with EAP-TTLS
for authentication against our LDAP database. Our VPN setup is
incredibly easy to enroll for new users and allows login with LDAP
username, password and Yubikey OTP. Simply removing a user from our
LDAP database immediately revokes their access to almost every IT
system we have. Everything is all meticulously monitored with Icinga
and its agents. Security patching takes minutes instead of hours. And
the best thing? It is *all* automated. And that leaves me with lots of
time to automate even more, like our continuous integration setup and
an upcoming cloud service. I actually have the time to visit customers
on-site now, which happened last week for the first time and was really
inspiring to me!
I truly feel like I am in full control of the whole IT infrastructure
at my place of work, which is something that I had definitely not felt
before. That data center in a box thingy, combined with some additional
roles I wrote, has been a major game changer for me. It became the only
open source project that I regularly contribute to, although I don't
put nearly as much time in it as I would want. The small but capable
community around it is just great. I feel indebted to many of you,
especially to Maciej.
Which is why I never want this adventure to end.
Honestly, even the thought of the possibility of this great project
ceasing to exist makes me sweat. I know that DebOps has brought a lot
of joy to many system administrators and homelab hobbyists out there.
CipherMail has also benefited greatly from the steady development over
the last few years. Of course there won't be an immediate operational
or security issue for us if all development would cease, but our
automation progress would most certainly be heavily impacted by it.
So consider this a check-in round. What I would like is an honest
'temperature' reading of all contributors. Not your actual temperature
(although it would be nice to hear that you're COVID-free), but more
how you currently see the future of DebOps and your involvement. Is
there anything you would like to see improved? And, even more important
but not as pleasant to discuss, what would happen if you were to cease
spending time on DebOps due to other priorities or unforeseen
circumstances? Do you feel like the project is (heavily) dependent on
you? Is your involvement causing you any sort of stress?
Lastly I'd like to lend a proverbial ear to any suggestion or comment
on this email. I want to know if I can do something more to ensure the
continued success of this project. I am certainly able to arrange
things like publicity and sponsoring of infrastructural services, and
will probably be able to organize a meetup for all of us once these
tougher times are behind us. Or maybe we should do regular online
meetups. Let me know what you think. My employer and I both recognize
the importance of our shared adventure.
Yours truly, and truly yours,
Imre
[1]
https://lists.debops.org/hyperkitty/list/debops-users@lists.debops.org/me...
[2]
https://github.com/debops/debops/commit/a214ab2c2f1f28d072456204477bd040a...
5 years, 1 month
debops.rsyslog and rsyslog__send_permitted_peers
by Lawrence McAbee
Hello.
First email. I've been using debops for a few months now. Great tool,
thanks for it.
I have found what I think might be a problem with the newer version of
debops.rsyslog.
Error I get from syslog is:
Aug 28 12:19:24 ajax rsyslogd: error: peer name not authorized - not
permitted to talk to it. Names: DNSname: internal.org; DNSname:
*.internal.org; CN: sirius.i.internal.org; [v8.32.0 try
http://www.rsyslog.com/e/2088 ]
I had thought (and still think) the issue is the certificate that I am
being kludgy about (the sending host is ajax.internal.org sending to
sirius.i.internal.org through a NAT, and I was thinking that since
ajax can not lookup the i.internal.org domain, it was some GNU TLS
check that was failing.
After playing around and reading, I found
rsyslog__send_permitted_peers, but in the code I see it declared but
it never ends up in the config file. Also, the documentation states:
rsyslog__send_permitted_peers: '{{ rsyslog__permitted_peers }}'. BUT,
while for the receiver (in remote.input) permittedPeer can be an
array, for the sender, ( in 00-forward-logs.conf) the directive is
streamDriverPermittedPeers and has to be a string. (at least I think
that is what the ryslsog documentation says)
I modified debops/ansible/roles/rsyslog/defaults/main.yml as seen in
the diff below to get rsyslog__send_permitted_peers in the forward file.
I'll cut and paste a diff below. Has anyone else had this problem, or
am I wrong that this is an issue?
73,675d672
< {% if rsyslog__send_permitted_peers is string %}
< streamDriverPermittedPeers="{{
rsyslog__send_permitted_peers }}"
< {% endif %}
Thanks.
5 years, 2 months
owncloud and letsencrypt
by Damiano Venturin
Hello everyone
I just spent a couple of hours on the owncloud role. My understanding is
that this role does not support acme to automatically produce
letsencrypt certificates. Is this correct?
Dam
5 years, 2 months
group restrictions?
by dev
hello everybody,
Since a wile I do have a weird behavior, that some group assignments are
not executed.
mainly I recognized these with apt_install and resources.
today I had the time to debug and moved them out of the way, and back
one by one.
after 3 resources, no all definitions got executed (mostly commands) any
more.
I did a yamllint & beautification – without any change. I ignored the
error with linelength > 80, since they don't seem to make any difference
I remember dark, that years ago there was something like a max. limit in
which a host could only be member in 3 groups.
is that still the case? why? and can that be changed, it's a too big
restriction.
if not, any suggestions how I could debug this?
TIA
guenter
5 years, 2 months
Call for testing: dhcpd role update
by Imre Jonk
Hi all,
As some of you know I largely rewrote the dhcpd role. Everyone who can
set up or otherwise utilize a test network is highly encouraged to try
it out. All feedback is greatly appreciated.
The PR is here: https://github.com/debops/debops/pull/1471
Having users of the old dhcpd role review my changes is especially
useful. Please consider taking a look!
Thanks,
Imre
5 years, 2 months
Question about debops.secrets, pki, ansible controller
by Julien Lecomte
Hello
What I want to achieve is that the root password be the same on all my
hosts, and that this value be read statically from my configuration such
as:
root_account__password: foobar
root_account__password_update: True
The playbook runs fine, and no errors occur, yet when trying to do a
simple login with the password it doesn't work. The previous root
password also no longer works.
Luckily I don't lock myself out (sudo still works).
What am I doing wrong?
Julien
5 years, 2 months
anyone who's running an acme server?
by Damiano Venturin
This is a question I have in my mind since months.
I see that the nginx role allows a vm to become an acme server and catch
all the certificates generated by letsencrypt.
I never tried this solution because my I'm concerned on how I can
distribute the certificates to other vms which are not involved with the
letsencrypt process.
What's the best practice for automatically distributing them?
Dam
5 years, 2 months
Running debops against a proxmox host
by Stuart Mumford
Hello all,
I have been using debops for a while for my homelab, and it's been a
great way to learn ansible for me.
I am currently building myself a new proxmox server, and I am wondering
if people have advice or experience they could share with running
debops against a proxmox host.
I have tried this in the past and things like the DNS configuration and
other things have ended up a little broken, so I am hesitatant to just
run the full common playbook against it again.
The main things I am interested in running on the proxmox host from
debops are the pki role, and any other core roles which might make
things better without interfering with the existing quirks of a proxmox
install. I was thinking at least unattended upgrades, sshd and then
samba.
Thanks,
Stuart
5 years, 2 months
