In Ruby, especially while writing low-level protocols, you may have encountered
String#unpack(). If you’ve ever experimented with them, they may seem mysterious; they take a cryptic string as a parameter (maybe something like
w*) and seem to return gibberish (or, conversely, convert gibberish into something humans can understand). I’m not going to go into tons of detail, nor am I going to cover every format that these methods accept, but I’ll cover a few that I’ve used.
What led me to writing this post was actually some recent experimenting that I’ve been doing with Crystal. I’m trying my hand at writing a simple BER parser/encoder as a part of my journey to writing an LDAP library for Crystal. The lack of an LDAP library is honestly the biggest reason I haven’t used Crystal for more things. Since BER is a binary method of encoding, the Ruby LDAP BER code uses a ton of
String#unpack(). Unfortunately, Crystal doesn’t have analogous methods for its
Array class or
String struct so I’ve had to write my own.
Here, I’ll describe a few of the formats supported by
#pack and write some compatible examples in Crystal.
Continue reading Rewriting Ruby’s #pack and #unpack Methods in Crystal
Most of the time, connecting to LDAP is pretty straightforward and is just a matter of applying the right configuration to your application. Or maybe it isn’t even something you need to think about; it could be abstracted away behind an API call. This wasn’t always the case though. In several of my previous jobs, authentication wasn’t just a matter of submitting a username and password; I needed to setup and maintain the system that made that work, both for the server and its clients. Thankfully there was a ton of documentation and guides for making Linux work with LDAP. But what about LDAP in containers?
Times have changed and now we’re building containers, not really needing to worry about a lot of the details of Linux configuration. For the most part, we don’t need much from PAM (and even less from
sssd) in containers. That said, sometimes you encounter software that just has to rely on your OS for authentication where LDAP sure comes in handy. Here I describe how to configure your Docker container to leverage LDAP via
sssd for users and groups.
Continue reading LDAP in Containers
We’re in very strange times, that’s for sure. The entirety of humankind is trying to social engineer a defense against a microscopic threat, yet here I am wanting to talk about working and how well it’s going in spite of the pandemic.
When I was first inspired to write this brief post, I decided against it because it felt too much like bragging. After all, not being able to work is clearly on the minds of MILLIONS of people right now. But really, this isn’t about me; it is a testament to how working on a phenomenal team makes it possible to be busy and happy with my job no matter what the rest of the world is up to.
I’m glad to work with friends, to have tons of work to do, and to see my projects succeeding. As a person that already works from home, this whole situation hasn’t been much of a change for me, but it has been fantastic to see how well the rest of the team has been doing with it. It really matters how companies handle situations like these; we all gain some solid insight into what a company values and how much it can adapt. My group has certainly adapted and after a week or so, I think we’re back in the groove. We’re not slowing down — we’re picking up! I’m grateful that work is the last of my worries (which is precisely how it should be during a pandemic).
Some tips for companies:
- Let people work from home if they can!
- Make sure your employees aren’t worried about taking sick time or personal time to figure out family situations.
- Lead by example: if CEOs or leadership video conferences from a home desk just like everyone else, people are less nervous.
- Be transparent.
- Be understanding.
Tips for individuals:
- Develop a healthy morning routine.
- Take breaks and go for a walk outside.
- Establish rules for disruptions during work (when my door is closed, I’m in a meeting).
- Communicate often in the chat.
- Leave room between meetings for personal time like getting water, checking in on kids, grabbing a snack, etc.
Stay healthy, everyone!
Sometimes, when you’re using a Linux server as your home router/Internet gateway, you need to change your public IP. I won’t go into the reason(s) why, because they don’t really matter. Maybe you accidentally exposed the proxy port (mostly just for your kids to protect their Internet access) directly to the Internet and ended up blacklisted by most things on the Internet, who knows? Best not to dwell on the hypothetical.
At first, it seems obvious: just release and renew with your DHCP client. A quick
dhclient -r enp4s0 (or whatever your interface name is) seems like the solution. But ISPs are too smart for that. Maybe try turning off your cable modem and leaving it off for a few minutes? Nope. None of this works because of how ISPs (and really, most any DHCP server) handle DHCP leases: they’re tied to the MAC address of your network interface. This means that when your network interface’s MAC address is seen by their DHCP server, it’ll offer it the same IP. This makes sense for ISPs to do; they can tie an IP to a customer based on their physical device.
Continue reading Changing Your Public IP on Home Internet
Any developer worth their salt knows that Redis is great for caching. As an in-memory cache, it gets the job done. You certainly don’t have to take my word for it; the major sponsors of Redis (redislabs) wrote a white paper to explain it. What isn’t quite as widely known is that Redis has some other uses worth considering. I’ll list the ones I’m aware of (and have used) which are all available with open-source Redis.
Continue reading Redis, Ruby, and Some Surprising Uses
I’ve been working on an open-source project for managing the Kong API Gateway, both as an SDK and as a CLI tool using a straightforward, YAML-based templated configuration. The project is called Skull Island and is available on RubyGems via skull_island, on DockerHub via jgnagy/skull_island, and of course on GitHub as jgnagy/skull_island.
Continue reading Skull Island: A CLI and SDK for Kong
I recently posted about my experience with k3s and how I’m now using it to run my blog. I also mentioned my blog’s new domain and how I’m keeping the old name working. That involved changing the Ingress resource for my blog, so I’ll show how I updated it to accept the old domains and automatically redirect to my preferred domain without needing to make WordPress itself do any redirecting.
Continue reading Redirecting Domains on a Traefik Ingress
I bought a new (arguably better) domain for my blog now! If you’re reading this, you’ve probably noticed, but it is therubyist.org, because I’m a fan of Ruby. The old name won’t be going anywhere, at least for the time being. Given the purchase of this new domain, I have several domains I need to maintain. Since I run this blog (and a few other services) from my home server which has a dynamic IP, setting up the domain apex (i.e., “naked domain”) is tricky. I’ve been using a dynamic DNS service called duckdns.org which gets the job done for subdomains since I can just CNAME to my personal DuckDNS subdomain, but it doesn’t solve this apex problem.
I decided that I was tired of doing this manually and that I would try to write a script. It would be appropriate, given my blog’s new domain name, to write it in Ruby. I did a quick DuckDuckGo search and noticed that someone wrote a GoDaddy SDK for Ruby. Yes, I use GoDaddy for my DNS… not necessarily endorsing them, but they seem to work well for my needs, especially now that I’ve discovered that they offer RESTful APIs.
Continue reading Updating GoDaddy DNS Entries with Ruby
It has been a while since I last posted, but between college, work, and kids, I’ve been pretty busy. That said, I recently attended KubeCon 2019 and saw a lot of interesting presentations. As a fan of Rancher, I gravitated toward a lot of their talks. One that really caught my attention was Darren Shepherd’s talk on k3s. I really liked what I saw; it made setting up Kubernetes really easy, lightened the dependency load for small clusters, but still is very much the right amount of “batteries included” like most things made by Rancher.
I decided to move my home server (which runs, among other things, this blog) to k3s. Here, I’ll walk through how I did it — at least specifically for running a WordPress blog — just to demonstrate how easy it is. Fair warning though, there is a lot of YAML ahead!
Continue reading Blogging on Kubernetes
There are lots of good reasons for and articles recommending running Docker containers read-only, but what I have a difficult time finding are descriptions of how to do this for many popular images. Some software needs to write to a few important and predictable locations. It surprises me how often image providers neglect to offer instructions or details required to run their image this way.
Even setting aside read-only containers, counting on writing to the writable layer just feels wrong. Per the documentation, for the writable layer, both read and write speeds are lower because of the copy-on-write/overlay process through the storage driver. In my experience,
docker diff output means I haven’t taken the time to configure my volume declarations, either through tmpfs mounts, volumes, or bind mounts.
Continue reading Read-only Docker Containers