Hacking:Servers/Beefcake

Beefcake is a virtual machine occupying roughly half of LukeShu's KGPE-D16 in Indianapolis. It runs no publicly accessible services, but is intended to be usable as a build machine for Parabola developers. It has a large data disk which archives all repos since April 2018; which are exposed to the librechroots as an HTTP service.

$ uname -m
x86_64

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           29Gi       725Mi       250Mi        13Mi        28Gi        28Gi
Swap:         7.4Gi       4.0Mi       7.4Gi

$ df -h | sed -n '1p;/^\/dev/p'
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda         10G  5.6G  4.1G  59% /
/dev/vdb        9.8G  6.8G  2.6G  73% /home
/dev/vdc        4.6T  4.6T  644K 100% /mnt/data
/dev/vdd        100G   42G   58G  43% /var/lib/archbuild

1 Login in Beefcake

1.1 Proxy via Winston

To login in Beefcake using Winston as a proxy, you need to first login in winston and forward Beefcake IP address locally:

ssh user@parabola.nu  -L localhost:1863:192.168.9.164:1863

You can then login to Beefcake with the following command:

ssh user@localhost -p 1863

Alternatively, you can also use the information from above as a 'ProxyCommand' in your SSH configuration file(s) in ~/.ssh/config or /etc/ssh/ssh_config.

More information is also available on a mailing list post.

1.2 LibreVPN

This is more complicated to setup; but allows accessing Beefcake and other parabola servers, without relying on any one of them as a proxy. LibreVPN also makes it fairly simple (once setup) to add any rare hardware, or useful services to the network, for other Parabola devs to access.

TODO: this is currently not well-documented

2 Using your local gpg-agent to sign files on beefcake

If you're building packages on beefcake, obviously you'll need to PGP-sign them when you release them. But copying your GPG secret key to Beefcake seems risky & silly. Instead, you should set up forwarding so that Beefcake can use your local gpg-agent that has access to your local secret key, rather than running gpg-agent on Beefcake.

2.1 Step 1: Stop Beefcake from automatically starting gpg-agent for you

user@beefcake $ mkdir -p ~/.config/systemd/user
user@beefcake $ ln -sT /dev/null ~/.config/systemd/user/gpg-agent.socket

2.2 Step 2: Configure SSH to forward your local gpg-agent

Unfortunately, this requires knowledge of where GPG will look for the gpg-agent socket. Which is under-documented, and relies on undocumented heuristics for magically trying to guess the appropriate place, instead of just letting the user configure it.

If /run/user/$UID/ exists (as it will on systemd systems (and elogind systems?); systemd keeps track of that directory as that user's $XDG_RUNTIME_DIR), then you insert the following in to the appropriate section of your SSH config:

user@local:~/.ssh.config

Host beefcake
	RemoteForward /run/user/1015/gnupg/S.gpg-agent /run/user/1000/gnupg/S.gpg-agent.extra
	#                       ^^^^                             ^^^^
	#                your UID in hackers.git             your local UID

	# Whatever DISPLAY or TTY name the remote `gpg` sends to gpg-agent will be on Beefcake,
	# not on the local host.  So we need to tell gpg-agent the correct DISPLAY/TTY info. 
	PermitLocalCommand yes
	LocalCommand gpg-connect-agent UPDATESTARTUPTTY /bye

If /run/user/$UID/ doesn't exist (as it won't OpenRC systems without elogind), then GnuPG puts the socket somewhere else:

user@local:~/.ssh.config

	RemoteForward /run/user/1015/gnupg/S.gpg-agent /home/luke/.gnupg/S.gpg-agent.extra
	#                       ^^^^                   ^^^^^^^^^^
	#                your UID in hackers.git     your local HOME