Migrating to a new GitHub Enterprise host

I’m moving my VMWare infrastructure from old hardware to new hardware. One of the last guest VMs I’ve waited to move is my GitHub Enterprise (GHE) host. My plan to migrate the system was simple:

  1. Create a new, empty GitHub Enterprise VM on the new VMWare infrastructure
  2. Put the old GHE system in maintenance mode
  3. Take a backup of the old GHE system
  4. Shut down the old GHE system
  5. Start the new GitHub Enterprise VM and select the Migrate option
  6. Restore the backup to the new GHE system using the ghe-restore tool

The installation instructions provided by GitHub are pretty good. To deploy a new GitHub Enterprise image I followed Installing GitHub Enterprise on VMWare.

Of course, no process is perfect. Here are a couple minor points that may save you some time:

Continue reading Migrating to a new GitHub Enterprise host

The Case of the Mysterious Git Repo

I’m migrating scripts from one CentOS host to another. (The old one is CentOS 6 and the new one is CentOS 7.) One of the items I want to move is a script that’s part of a git repo.

I know it’s a git repo because it has a .git directory. The directory and files are owned by a local user, luser1.

Where did this git repo come from?

You can call git config -l and it will tell you things about the repo, including the remote.origin.url. Now I can tell that it came from my GitHub Enterprise (GHE) instance.

But it doesn’t tell you who created it. And luser1 doesn’t exist on my GitHub Enterprise instance.

I tried to clone it on the new host, just to see what would happen:

$ sudo -u luser1 git clone git@github.osric.net:team1/the-sauce.git

Result:

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Somehow luser1 is able to interact with this repo on the old host, even though the user doesn’t exist in GHE.

Fortunately the local repo has some history:

$ head -n1 .git/logs/HEAD

Result:

0000000000000000000000000000000000000000 ab509345a16d987dac10987c4bc2df0c0dfb3ed9 luser1 luser1 <luser1@oldhost.osric.net> 1505633110 -0500   clone: from git@github.osric.net:team1/the-sauce.git

Right there there it is, all the info I wanted! Except that’s the same user, the user that doesn’t even exist in GitHub Enterprise.

Or does it? I went looking at some of the other users in my GitHub Enterprise instance. There were a few system accounts, and when I checked some of them had several SSH keys associated with the accounts. One of the SSH key fingerprints even said luser1.

I wanted to compare that key fingerprint to the key in /home/luser1/.ssh/id_rsa.pub. I can never remember how to do that, but StackOverflow had the answer on How do I find my RSA key fingerprint?

$ ssh-keygen -lf /home/luser1/.ssh/id_rsa.pub

Result:

2048 bb:fc:1c:03:17:5f:67:4f:1f:0b:50:5a:9f:f9:30:e5 /home/luser1/.ssh/id_rsa.pub (RSA)

The fingerprint matches! The SSH key was added to a completely different username in GitHub Enterprise which does have access to the repo.

That works, but why would someone do that? Convenience, I assume, but it wasn’t obvious when I needed to reverse-engineer it!