BeaverIs.Me

systemd.timer and service to renew Let’s Encrypt certificate

Mount Google Drive in Arch Linux without syncing

Using Digital Ocean on their base 20GB package I’ve always been curious how to add space to the VPS using a service such as Google Drive. Today Ben Lobaugh pointed out a nifty guide to me that I roughly followed to add 15GB of space to my VPS.

Connect to Google Projects and create a Project

Under APIs add the Google Drive API to the project

Under Credentials setup an OAuth Client ID

1422470664M2EzO

You may need to set a product name in the consent screen to continue

Chose Installed application and Other then Create your Client ID

You should now have a Client ID and Client Secret

Install “`google-drive-ocamlfuse“` from aur.

As an elevated user:

# google-drive-ocamlfuse -headless -label my-project -id $CLIENT_ID -secret $CLIENT_SECRET

You should be asked to visit a URL in a browser to finish the authentication.

Now open ~/.gdfuse/my-project/config with your favorite text editor and add your access token under verification_code also check that client_id and client_secret are correct

Now mount the drive

# google-drive-ocamlfuse -label my-project /home/gehidore/gdrive

Note: One thing I’ve noticed is that left unused the connection seems to fail between Google Drive and the system with the drive mounted, this requires # umount /mountpoint and invoking the mount command again via # google-drive-ocamlfuse -label my-project /mountpoint

Install Arch Linux with full control on DigitalOcean VPS

I’ve been one to complain that DO dropped support for Arch Linux, others have done hacky workarounds that wind up still using the locked down kernels that DO provides. Recently they added FreeBSD to their list of supported Operating Systems with a mention that they would allow fully custom kernels to be used. In this I saw a door to freedom of choice again.

If you want to give it a go here’s what I did.

Create a FreeBSD Droplet.

Connect via the Console Access in DigtalOcean admin and elevate yourself to root.

Add some tools we’re going to need:
replace $editor with your favorite editor assuming it doesn’t come prepackaged on FreeBSD 10.1

# pkg install grub2 wget e2fsprogs $editor

Partition adding a bios-boot partition, replace swap for /boot and install grub2

# swapoff -a
# gpart delete -i 1 /dev/vtbd0
# gpart delete -i 2 /dev/vtbd0
# gpart add -t \!21686148-6449-6E6F-744E-656564454649 -i 1 -s 2M /dev/vtbd0
# gpart add -t linux-data -i 2 /dev/vtbd0
# gpart show /dev/vtbd0

You should now have a layout that looks like this:

# mkfs.ext3 /dev/vtbd0p2
# mount -t ext2fs /dev/vtbd0p2 /boot
# grub-install /dev/vtbd0

Grub should return a polite completed message:

Download the arch install media from your favorite mirror with wget and place it in /boot
Note: Since you’ve passed the point of no return it is imperative to verify the md5sum or sha1sum as you won’t be able to download another copy once you’ve committed to a reboot.

Configure grub to boot the Arch Linux install media:
my /boot/grub/grub.cfg looks like this:

Reboot and you should be greeted with grubs boot menu:

From here you can install Arch Linux and live happily ever after.

Note: To install you’ll need to configure your networking statically, the pertinent information for your network can be found at the bottom of the Console Access page in the Digital Ocean Admin.

Some Notes on installation:

If you wish to continue to use the second partition as /boot in your installation as I did you’ll need to remount /run/archiso/img_dev RW and bindmount it to your /boot inside /mnt before you chroot.

# mount /dev/vda3 /mnt/
# mkdir /mnt/boot
# mount -o remount,rw /run/archiso/img_dev
# mount -o bind /run/archiso/img_dev /mnt/boot

Continue your install as normal.

A special thanks WonderWoofy for all the support and ideas that got this going.

Thanks to kaictl for proofreading this.

Thanks to Rick for his article that covered how to set the bios-boot flag with gpart under FreeBSD.

systemd-networkd with wpa_supplicant to manage wireless with roaming support

Finally fed up with the many tools for managing wireless and even wired connections that just seem to cause more problems than the underlying tools I discussed with a friend the idea of networkd supporting roaming profiles for wireless. Searching around he found some super good information and this is what I ended up doing. I created these files:

The following finished off the setup:

# rm /etc/resolv.conf
# systemctl enable systemd-networkd
# systemctl enable wpa_supplicant@wlp3s0
# systemctl enable systemd-resolved
# systemctl start systemd-networkd
# systemctl start wpa_supplicant@wlp3s0
# systemctl start systemd-resolved
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

I also elected to start using systemd-timesyncd.

# systemctl enable systemd-timesyncd
# systemctl start systemd-timesyncd

For a static ip replace DHCP=yes with the following:

Address=192.168.0.42/24
Gateway=192.168.0.1

The guide which this was pilfered from suggests using:
wpa_passphrase <ESSID> <passphrase> >> wpa_supplicant-wlp3s0.conf
to add new networks to the network pool. Happily borrowed from here

CoreDuo Mac Mini archlinux headless boot

It’s been said many a time across the interweb that the early Intel, and perhaps current Intel Mac Mini’s often refuse to boot to Linux in CSM ( Legacy ) mode without a monitor plugged in. Today I decided to do some research and found that the GPU doesn’t get powered unless it detects a monitor and the firmware of the mini wont pass off control until the GPU is powered. To bypass this I found a few howto’s and the one that really worked involved 3 68Ohm resistors placed into a DVI to VGA adapter to trick the GPU into thinking it had a display attached. Here’s what it looks like:

Thanks to Nick Oneill and his post about the exact fix I used, now I can perform updates on my headless mac mini and reboot via remote knowing fully well it will be able to boot on it’s own.

archlinux monitor hotplugging

In a short follow up to my previous post about patching the modesetting driver for persistent nomenclature of a single displaylink device.

Part of my goal with the previously mentioned patch was to continue with my fork of the udev-monitor-hotplugging script for linux systems. I’ve now added in support for display link devices using the patched version of the modesetting driver and a single displaylink device.

Display Link driver for Xorg on archlinux, patched to keep the device name the same

So this is no terrible feat, it’s just one way I’ve managed to make my life as linux user easier. I have a a Lenovo Thinkvision USB 2.0 Display Link Monitor that matches my laptop’s built in display. The issue with these devices is that until recently support for the linux has been lacking. Thanks to David Airlie we have support for these devices and it’s quite good. The downside in my situation is that while it is nearly plug and play the device name kept growing by one each time the device was unplugged and plugged back in during an active session. So if I unplugged the device and closed my laptop to head somewhere then opened her back up and plugged the monitor back in what was DVI-1-0 would now be DVI-1-1. For most this wouldn’t cause any issues I suppose, I use i3wm as my Window Manger and it has a nifty feature that allows you to set Workspace assignments to specific screens. So if the device changed to DVI-1-1 I would need to change my config to reflect this and refresh i3 to get these Workspace assignments to work.

As I said it’s no major accomplishment but it helps my productivity *tons*, especially when I decide to displace.

For those who could use it, here is an Archlinux PKGBUILD and the necessary patch to set the device to be DVI-1-0 this pulls the latest git branch of the modesetting driver