import local git repos to GOGS

A few months back I decided I needed a local git server of some kind, and after doing a little research settled on GOGS (who knows why), with a few runners up in case things got dicey with GOGS - Phabricator was one, among a few others.  Today I decided it was time to make the git server happen, and things got very dicey but I stuck with GOGS anyway.

Here are the clean and reduced instructions for cloning your local git repos into GOGS.  This is probably pretty basic for some people, but a git wizard I am not.

1. Convert your local repos into a bunch of bare repos:
   
   mkdir bare-repos
   cd bare-repos
   git clone --bare --local /home/you/code/myfrivolousproject
   # repeat until there are "frivolousproject.git" dirs for all your frivolous projects inside bare-repos
2. Convert them so we can use a dumb webserver:
   
   cd frivproj1
   git update-server-info -f # I'm not sure, but it seemed like I needed the -f
   cd ../frivproj2
   git update-server-info -f # also, thanks to this guy for this key step!
   # etc...
3. Start a dumb webserver:
   
   cd bare-repos
   python -m SimpleHTTPServer
4. In GOGS, hover over the + at the top right, choose "New Migration", then enter "http://LOCALIPADDR:8000/myfrivproj1".  You can figure out what to enter for the rest of the fields.  Authentication is not needed.  MAKE SURE you enter the actual IP of your client machine, and not localhost!  I think I screw this up every time.
5. If you screw up, you'll get an extremely unhelpful 500 page, and something like "repository not found" in the logs.  Probably you forgot the update-server-info step, or started the webserver in the wrong directory.  But if you somehow managed to make it all work right, you'll get dropped into your new GOGS project page!
6. After you do this, you may want to add the git repo as the origin to your local checkout.  cd to the checkout, and run git remote add origin $URL, where URL=the HTTPS link URL found in the gogs page project.

That took way too much work, I must be tired.

convert existing live btrfs root filesystem to raid1

Fuck it, we're doing it live!

All commands below make these assumptions:

• sda = EXISTING boot drive
• sda1 = EXISTING root fs
• sdz = NEW boot drive

Modify the dev entries in the commands below according to your setup or bad things will happen!

1. Copy the partition table from the old disk to the new one.  You probably don't want to get this backwards.
   
   yo@mama:# sfdisk -d /dev/sda | sfdisk /dev/sdz
   After doing this you may want to pull and then reinsert the drive, to refresh the entries in /dev.  Linux can be weird about this, partprobe doesn't always work.
2. The disks I'm using are not the same size, the new one is a bit larger than the current one.  If the new one were smaller that would be a bit trickier, but since it isn't I won't really get into that.  (Basically you'd either need to recreate the partitions by hand on the new drive, or send the sfdisk output to file and modify that by hand before throwing on the new drive.)
   
   Instead, we'll just let that extra space be.
3. Add the new disk.  Assuming your existing disk is mounted as the root filesystem, the command would go like this:
   
   yo@mama:# btrfs device add /dev/sdz1 /
   yo@mama:# btrfs balance start -dconvert=raid1 -mconvert=raid1 /
   
   If you've read the docs, you know there is also an -s flag for system chunks that can be passed to btrfs balance start.  You don't need to use -s here, according to various people on the internet, and I even found this comment that verifies it in the btrfs-progs sources:
   
   

   /* 
    * allow -s only under --force, otherwise do with system chunks
    * the same thing we were ordered to do with meta chunks
    */

   
   Also, for some reason balances happen in the foreground by default and output nothing.  Watch the progress by opening another terminal and running:
   
   yo@mama:# while btrfs balance status / ; do sleep 10; clear; done
4. And that should be it.  You can make sure it went down as it was supposed to by running:
   
   yo@mama:# btrfs fi show /
   
   Which should give a listing with two devices.

Then, you can give it the balls-to-the-wall test by disconnecting your old boot drive. Make sure that the balance has finished before you do this!  If you're a sissy, run sync before pulling the drive.

LACP port bonding with DHCP on debian stretch

Finding information on LACP port bonding can be tricky.  It seems there's a decent guide published every couple years, but then the code changes and the information no longer really applies.

And creating a bonded interface with DHCP is even trickier.  You could solve it this way, if you wanted to cop out.  But copping out is for out coppers, and everyone knows that that ain't me.

So we're going to configure LACP port bonding (aka 802.3ad) on our brand new install of debian stretch (at the time of this writing, stretch is nearly identical to jessie, so this guide ought to work for jessie for a few years).

1. aptitude install ifenslave
   echo 'mii' >> /etc/modules
   modprobe bonding
   
   This gives us the ability to create bond interfaces.
   
   
2. vi /etc/network/interfaces
   
   And make sure the contents look something like this:
   
   source /etc/network/interfaces.d/*
   
   # Loopbackz
   auto lo
   iface lo inet loopback
   
   # Enslave these interfaces
   allow-hotplug eth0
   allow-hotplug eth1
   
   # The bonded interface
   auto bond0
   iface bond0 inet dhcp
       bond-slaves eth1 eth0 # order matters!  the first listed interface is the one whose mac is used
       bond-mode 802.3ad
       bond-miimon 100
       bond-downdelay 200
       bond-updelay 200
       bond-lacp-rate 1
       bond-xmit-hash-policy layer2+3
   
   
3. Reboot.  Or muck around with /etc/init.d/networking restart, ifconfig INTERFACE DOWN|UP, etc.
4. If the ifconfig output looks good, and the output from cat /proc/net/bonding/bond0 looks good, and you have network connectivity, then you've done it!

Go have a cold beer, you've earned it.