Jul 292017

With the release of kernel-xen version 4.9.40, I have enabled CONFIG_TCP_CONG_BBR. This adds support for using BBR to improve the throughput from your servers (mostly web servers) to your clients.

If you run my kernel-xen package on your Xen guests, you can also take advantage of this new feature.

To enable, ensure you are running kernel-xen version 4.9.40 or above, then create a file called /etc/sysctl.d/enable-bbr.conf containing:

You can activate this by typing: $ sysctl -p

The changes will automatically apply at the next system boot.

To read more about BBR and why it makes such a difference, head on over to acmqueue for a far more in-depth analysis than I could provide.

May 312016

So yeah, I’ve been forced into using SystemD for just about everything now that the entire community has taken the koolaid.

I recently had a question where if a ConditionFileIsExecutable fails in the [Unit] section, the logs say that the service was started – but in fact the service won’t attempt to be started. No errors, no warnings, but a message of success. This seemed strange, so I jumped onto #systemd on Freenode and ended up with the following conversation:

17:37 -!- Irssi: Join to #systemd was synced in 5 secs
17:38 < CRCinAU> ok – so if the start of a service fails because ConditionFileIsExecutable fails, is it expected to be a silent failure?
17:38 < CRCinAU> ie nothing in the journal or logged to state why a service failed? just a “Started” then nothing further?
17:39 < grawity> CRCinAU: yeah, it’s supposed to be mostly silent
17:39 < grawity> unlike AssertFileIsExecutable=, by the way
17:39 < CRCinAU> logic behind that?
17:39 < grawity> its primary purpose is in filtering units which should or shouldn’t auto-start
17:40 < grawity> logging failures at default level would result in too much logspam on most systems
17:40 < CRCinAU> o_O
17:40 < grawity> e.g. there’s ssh-keygen.service with Condition= that at least one ssh_host_key is missing
17:41 < grawity> if you want things to be logged loudly, use Assert=
17:41 < CRCinAU> I don’t see a problem with that?
17:41 < grawity> with what
17:41 < CRCinAU> a message that a file doesn’t exist…..
17:41 < grawity> with users seeing “warning: ssh-keygen not started because EVERYTHING IS FINE” on every reboot?
17:42 < grawity> some programs install units with ConditionVirtualization=, which would either log warnings on every VM, or on every bare metal system
17:42 < grawity> if you want things to be logged loudly, use Assert=
17:42 < CRCinAU> wait……..
17:42 < CRCinAU> what the hell is systemd doing thinking about virtualisation?
17:43 < grawity> there are daemons which are only needed in VMs, or aren’t needed in VMs
17:43 < CRCinAU> urrrmmmm…….
17:43 < grawity> e.g. systemd’s own udev has no business running in a container
17:43 < CRCinAU> holy crap… so what you’re telling me is systemd is still hungry and needs to be fed more?
17:44 < michich> another example: vmtoolsd.service:ConditionVirtualization=vmware
17:44 < CRCinAU> I think I just died a little inside in that level of retardation.
17:45 < grawity> so by your own logic, a few minutes ago you were telling me systemd should be checking for your config files, instead of your own daemons doing that themselves?
17:46 < CRCinAU> no – the unit failed to start, and had no warning. if there was a problem and the unit failed, I’d expect to see something that says “blah.service failed because ConditionFileIsExecutable failed” or similar.
17:46 < CRCinAU> not just “Unit blah.service started”
17:46 < CRCinAU> when it fact it wasn’t
17:46 < CRCinAU> it *attempted* to start
17:46 < CRCinAU> but failed.
17:49 < CRCinAU> on another note, now I’m hearing that systemd is becoming virtualisation aware because users are too stupid to do “systemctl enable vmtoolsd.service” when they do a virtualised install?
17:49 -!- mode/#systemd [+b $a:CRCinAU] by evilgrawity
17:49 < CRCinAU> well, not even that… as I guess you’d have to install the VMWare tools in that situation to even have the service file in the first place – so it could even be part of the package install.
17:50 -!- #systemd Cannot send to channel
17:50 -!- CRCinAU was kicked from #systemd by evilgrawity [CRCinAU]

I’m kinda speechless now.

May 282016

Recently, I’ve been going all out on deploying LDAP and realising how much easier it would have made my life over the years. Fusion Directory has proven to be a good management interface for keeping things in check.

That’s the easy part though – now how do you go about making all your software to implement the features of LDAP and FusionDirectory? Sometimes with difficulty!

After a lot of mucking around, I’ve managed to get postfix working properly with LDAP as a source of email accounts, alias, forwards etc. We want to use the standard gosaMailDelivery flags to make life easy – and these are well documented for Fusion Directory.

Firstly, I’m going to assume that you already have openLDAP and Fusion Directory running. The documentation here is more than adequate to follow.

So now we’re down to postfix.

Firstly, we want to handle accounts that postfix needs to deliver mail to. Create a new file /etc/postfix/ldap-accounts.cf and use the following:
server_host = ldap.example.com
search_base = ou=people,dc=example,dc=com
scope = sub
bind = no
version = 3
query_filter = (&(mail=%s)(objectClass=gosaMailAccount)(!(gosaMailDeliveryMode=[*I*])))
result_attribute = mail

Now we want to handle aliases – so create /etc/postfix/ldap-aliases.cf:
server_host = ldap.example.com
search_base = ou=people,dc=example,dc=com
scope = sub
bind = no
version = 3
query_filter = (&(gosaMailAlternateAddress=%s)(objectClass=gosaMailAccount)(!(gosaMailDeliveryMode=[*I*])))
result_attribute = mail

Next step is forwards *with* delivery to the local account as well – create /etc/postfix/ldap-forward.cf:
server_host = ldap.example.com
search_base = ou=people,dc=example,dc=com
scope = sub
bind = no
version = 3
query_filter = (&(|(gosaMailAlternateAddress=%s)(mail=%s))(objectClass=gosaMailAccount)(!(gosaMailDeliveryMode=[*I*])))
result_attribute = mail,gosaMailForwardingAddress

And lucky last, we have forwards only – without a local delivery in /etc/postfix/ldap-forward-only.cf:
server_host = ldap.example.com
search_base = ou=people,dc=example,dc=com
scope = sub
bind = no
version = 3
query_filter = (&(|(gosaMailAlternateAddress=%s)(mail=%s))(gosaMailDeliveryMode=[*I*])(objectClass=gosaMailAccount))
result_attribute = gosaMailForwardingAddress

Once these files have been created, we can configure postfix. I use a full virtual delivery – so no user accounts exist on the mail server. Add the following to /etc/postfix/main.cf:
virtual_alias_maps = proxy:ldap:/etc/postfix/ldap-aliases.cf proxy:ldap:/etc/postfix/ldap-forward.cf proxy:ldap:/etc/postfix/ldap-forward-only.cf
virtual_mailbox_maps = proxy:ldap:/etc/postfix/ldap-accounts.cf

That is the bulk of the setup done.

Aug 022015

It’s been a while since my last post – and this one is a doozey.

So Bind is one of the most popular DNS servers on the planet. Just about everyone runs it. So when news breaks that a specially crafted request can cause the named process to exit, then a problem is presented.

Enter CVE-2015-5477.

The official report says:

named in ISC BIND 9.x before 9.9.7-P2 and 9.10.x before 9.10.2-P3 allows remote attackers to cause a denial of service (REQUIRE assertion failure and daemon exit) via TKEY queries.

This doesn’t really convey the severity of the issue. Thankfully, the ISC elaborate more. In it, they say:

The practical effect of this is that this bug is difficult to defend against (except by patching, which is completely effective) and will not be particularly difficult to reverse-engineer. I have already been told by one expert that they have successfully reverse-engineered an attack kit from what has been divulged and from analyzing the code changes, and while I have complete confidence that the individual who told me this is not intending to use his kit in a malicious manner, there are others who will do so who may not be far behind. Please take steps to patch or download a secure version immediately.
This bug is designated “Critical” and it deserves that designation.

Essentially, “You’re screwed. Upgrade now”.

If you’re a system admin, and you’re reading this, check your bind version now, make a coffee, then dig in for the long haul.