Yum and ldapsearch: a Lesson for 28 April

Source

The question of how to install things still trips me up sometimes. There are a bunch of possible ways it could be done in any given situation, and fairly often, the preferred method isn’t detailed overly meticulously in the README or other docs. Sometimes you have to clone repos and run a certain command in that directory; sometimes it means adding something to /usr/bin and opening a new terminal window; sometimes you summon a UI with a texty terminal command, which feels oddly like sorcery to me.

It’s a good deal easier now, but when I was just starting it could be a real trial. I spent a lot of an afternoon at Hackbright struggling with Postgres because I did a brew install instead of Postgres.app, which… did not get me what I needed and introduced a host of other problems. (It did get me a really interesting philosophical kind of conversation about the pros and cons of installing things from too high a level, courtesy of a teacher who became my friend – who still semifondly recalls that time she had to unpick what fuckery I’d wrought in such good faith.)

Today, trying to figure out how to get the command ldapsearcavailable to me, I learned one thing and was reminded of another.

  1. I learned yum whatprovides */$WhatYouSeek. (Thanks, Server Fault.) In my case, ldapsearch was one of several commands inside a differently named package: openldap. Oho. (It’s actually in a couple different families of packages, but I do not need to get Perl up in my business today.)
  2. I was reminded that – less commonly for the kind of work that I do – sometimes the needed command is not the name of the package. Some packages aren’t all about one command doing one thing well, despite the best urgings of the Unix philosophy. So – ldapsearch is snuggled into openldap. Got it.

Now you’ve got it too.

Restoring Github Repo Access in the Terminal after Adding 2FA

Molding, windows, and walls of central room of Oakland's 16th Street Station

This is the second time I’ve had to look this up, and the instructions are spread across a couple of pages. So for the sake of my future self, I’m compiling the steps here. Maybe it’ll help someone else too. That’d be cool.

So you added 2FA to your Github account. (Very smart; nice job.) Problem: your terminal no longer accepts your (still valid) password when you’re trying to push to a repo. Here’s how to fix that.*

1. Create a new personal access token.

Go to Github and ensure you’re logged in. (An aside: you’ve saved your access codes in a password manager or some other secure place in case the device you designated for 2FA authentication codes catches on fire, right? Excellent, carry on.)

Go to the upper-right corner of the page, click your profile image, and click Settings. In the sidebar of the next page, scroll to the bottom and click Personal access tokens. Click Generate new token. Give it a name that will make your future self grateful for today’s clarity. Select what permissions you want this token to give. Then: Generate token. The token that appears will only be visible right now, so make sure you save it or do what you need to do with it. (Or save it to 1Password and then proceed to the next step.)

2. Save it to your OSX keychain credentials

Here’s the choose your own adventure part: do you have Github credentials saved for more than one Github account on this machine?

2a. Nah, just one. Let’s nuke it and replace it.

Cool, let’s get rid of the old credential first. Go into your terminal and type this:

git credential-osxkeychain erase

There’ll be a pause and then nothing. That means success. (I still find this convention strange, but I like a verbose interface, so that’s my own struggle to deal with.)

Now, do that push that you were probably trying to do when you realized you’d cut off access on a machine you perhaps don’t code from so often. It’ll ask you for your username and password. Give it your username as usual, but instead of your password, paste that Personal access token that we created in the last step into the terminal. Hit enter. Wait. Enjoy your success (which will be confirmed by a message this time).

2b. I’m super cool and access SO MANY accounts. Let’s just replace one, please.

Alright, fancy. For this one, we’ll start with the Keychain Access app instead of the terminal. (Don’t worry, we’ll finish in the terminal for this step too, if you prefer.) Open Keychain Access and then type in “Github” to narrow down the options listed. You’re looking for an entry for github.com. To confirm you’re looking at the right one, ^click and select “Get info” from the menu that appears. Confirm that the username you’re looking for is the one listed under account, then select Access Control and confirm that the option listed is git-credential-osxkeychain. If those two things look right, we’ve found the right credential.

Now you can edit it there, replacing the existing password with your new token, or you can delete it and provide the new credential via the terminal when prompted after you try to push again, as described in 2a.

There you go! Such security, what authentication.

Want to double-check my work? Here’s what I used to put together these steps (both times, because sometimes that’s what it takes):

And if you haven’t set up 2FA for Github yet, my god get on that ok wow with the instructions here.

*On a Mac. That’s the context here. Mac Mac Mac.

Header image is from my recent visit to Oakland’s 16th Street Station, which is usually closed up. In this case, my access was granted by paying to be part of a photo tour. Authentication comes in many forms.