Daenney's blog

As you might’ve noticed from other blog post entries I’m suddenly all into directory services. This happens b/c that’s what I’m currently working on. As such I find myself needing to manipulate data in a DIT quite a bit and writing ldif’s by hand is not my idea of fun. Instead I set out to create a small library that would essentially allow me to parse the result of LDAP search result entries into a Go struct and transform those back into add or modify operations.

This post is part of a series on directory services. Current available installments are: Introduction Terminology Basic concepts Designing the DIT Setting up an LDAP server Securing your LDAP server Writing and testing ACLs Directory Services are fundamentally pretty simple. All information they contain is stored in a hierarchical tree structure, called the DIT. Within the DIT entries can be nested into or beneath each other, creating this tree-like structure.

In this series of posts I want to talk about directory services. The directory allow you to model things like people, computers, groups and their relationships in a central database. This service can then be used for authenticating users, managing group memberships and a whole lot more. In many small environments people avoid the perceived complexity of directory services over manually managing and provisioning groups and users in systems. Though this can work really well, even on a small scale this can get annoying.

This post is part of a series on directory services. Current available installments are: Introduction Terminology Basic concepts Designing the DIT Setting up an LDAP server Securing your LDAP server Writing and testing ACLs Directory services come with a lot of terminology and part of that lingo is what makes things difficult to understand to someone who hasn’t heard any of it before. Below is a common list of terms you might run into in documentation and the rest of these posts and hopefully a simple enough explanation of what they mean.

My home WiFi router is an ASUS RT-AC66U. It’s a great device with a tolerable manufacturer provided UI and quite a lot of advanced features. Though it’s marketed as a WiFi router I use it as a WiFi access point and switch, it doesn’t route. I have a Linux box that does that. Since a lot of my devices are wireless a lot of my traffic flows through my WiFi access point.

One of the issues I run into when running a server, at home or anywhere else, is the crazy amount of random attempts at SSH logins. My SSH configuration is strict enough that most of these attempts just die on the key exchange, they never even get past the handshake. Then there’s fail2ban ensuring you get temporarily blocked if you’re obviously trying to brute force anything. Looking at the auth.log a lot of these attempts stem from Russia, China, various other parts of Asia, Africa and South America.

My ISP (Telia) doesn’t do native IPv6 yet (like most ISPs unfortunately). However, they do support something called IPv6 Rapid Deployment, also known as 6rd. What it does is fairly simply, it encodes in the information you get from your ISP during a DHCPv4 chat the information needed to set up a 6to4 tunnel with an endpoint provided by your ISP. Getting native v6 would be the best but this is probably the closest I’m going to get in a while.

Over the past few months I’ve started to reassemble a home server. I managed to get a great server board with 2 Xeon E5’s and 128GB of ECC RAM (b/c why not?) and spent Saturday breaking in the hard drives, setting everything up to be nice and encrypted and so on. One of the things I like to have at home is a decent monitoring system. I’ve toyed with Prometheus before but never really used it.

This has been a hard blog post to write, but to me it feels like it’s been a long time coming. For the better part of the past 5 years my job and open source contributions have revolved a lot around Puppet. I’ve been a member of the community for a long time, contributing to a range of different projects and giving a variety of talks at associated events like Puppet Camps, Configuration Management Camp and PuppetConf.

Every now and then I find myself in discussions with people around which tools we should use for what job. This comes up especially often in the context of FOSS with regards to communication platforms. Do we use IRC, Slack, Gitter? Also, are mailing lists still a thing? Should we have a Discourse instead? Fairly often the reaction of people will be “no you can’t use Slack, use FOSS tools for FOSS projects”.