💾 Archived View for thorjhanson.com › blog › 20220324-9front-in-qemu.gmi captured on 2022-07-16 at 13:43:59. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
A few months ago, I decided to attempt an installation of 9front (a popular fork of Plan 9) in QEMU. I was ultimately successful, and decided to write some notes down as I went.
Ultimately, I cannot give any guarantees or warrantees about this document: It is an outline of what I did, not a guide or a how-to.
My objective was to install a combined CPU, filesystem, auth server, and secstore all in on 9front virtual machine, running on QEMU on my home NAS (running Arch Linux). My NAS has a Wireguard connection up to my rented VPS exposing the 9p ports publicly (modern 9p supports TLS connections). This allow me to access my 9front installation from any of my Wireguard-connected, LAN devices, or through the VPS's exposed ports using drawterm. Eventually I should be able to connect to the server from other 9front instances as well, although I haven't tried that yet.
My primary resource was the FQA.
I installed QEMU on my NAS. I downloaded the latest ISO from the website, uploaded it my NAS, and added a dedicated ZFS dataset for the VM. Those steps can vary based on an individual's setup.
I started out reading FQA s3.3.1 and s4. As root, I created a sparse disk image in my VM directory:
qemu-img create -f qcow2 my9front.qcow2.img 30G
I then booted the ISO with VNC turned on. Since my NAS is headless (SSH-only), I made sure to enable VNC in the QEMU:
qemu-system-x86_64 -cpu host -enable-kvm -m 4096 \ -vnc :2 \ -net nic,model=virtio,macaddr=52:54:00:00:EE:03 -net user \ -device virtio-scsi-pci,id=scsi \ -drive if=none,id=vd0,file=/vms/my9front/my9front.qcow2.img \ -device scsi-hd,drive=vd0 \ -drive if=none,id=vd1,file=9front.iso \ -device scsi-cd,drive=vd1,bootindex=0
The `-vnc :2` ends up exposing the VNC session on port `5902`. After punching the appropriate hole in my firewall, I was able to use Remmina to connect to the booted session.
I jumped to the FQA section 4.3, "Performing a simple install".
It prompted for a boot device. I pressed `[enter]` since the default was correct. I pressed `[enter]` again to choose the user as glenda.
The next question was on VGA and input. I accepted the defaults, since I wasn't planning on accessing the session over VNC regularly anyway. The defaults worked, but the mouse control was super wonky. I tried increasing the screen resolution by listing the available resolutions and then selecting one, but it didn't help the mouse:
@{rfork n; aux/realemu; aux/vga -p}
@{rfork n; aux/realemu; aux/vga -m vesa -l 1920x1080x32}
I then thought I'd try changing the mouse type, which got my scroll wheel working, but didn't help the weird mouse behavior:
aux/mouse ps2intellimouse
I decided to go ahead despite the incorrect mouse sensitivity, since I'd ideally not be using it this way much longer.
In the booted system, I ran `inst/start` and followed the suggested steps in order. I chose `hjfs` for the filesystem because it sounded simpler.
In the partdisk step I chose my qcow2 40GB disk (sd00). I chose mbr partition, then `w`, `q`.
Next on prepdisk I chose the default partition, then `w`, `q`.
On mountfs, I chose the default partition, default cache, and reamed the partition.
In the configdist I chose local.
For confignet I left the system at DHCP, although was apprehensive about how networking would go after reboot.
At the mountdist step I used the defaults.
Then it was the copydist step, `[enter]`. Wait up to an hour for the copy to complete.
Next it was the ndbsetup step. Chose system name (my9front). For the tzsetup I chose my timezone, and for the boot-related settings I just kept the defaults. I was then ready to reboot.
After the initial install, the QEMU startup command has to be modified. I had to kill the VM with ctrl-c. I then had to run the following, as root since I'm using reserved ports. If I wanted to avoid running as root, I could use my firewall settings to map those ports to different ones, but I personally wasn't concerned about running QEMU as root:
qemu-system-x86_64 -cpu host -enable-kvm -m 4096 -vnc :2 -net nic,model=virtio,macaddr=52:54:00:00:EE:03 -device e1000,netdev=net0 \ -netdev user,id=net0,hostfwd=tcp::17019-:17019,hostfwd=tcp::567-:567 -net user \ -device virtio-scsi-pci,id=scsi \ -drive if=none,id=vd0,file=/vms/my9front/my9front.qcow2.img -device scsi-hd,drive=vd0 -display none
Once remote access is all working, the VNC part will be able to be removed.
In the newly-installed system, I checked for internet:
ip/ping google.com
I wasn't able to get a connection. I ran:
ip/ipconfig
Which got networking working. Ping times seemed pretty flaky though, which I attribute to the VM.
A resource for me was a blog post about setting up 9front on a Raspberry Pi:
Plan 9: Setting up 9front on a Raspberry Pi
So, I edited `/rc/bin/termrc` and added `ip/ipconfig` just before the DNS stuff (so that it runs it on boot). This worked for the time being, although I was unsure how it would end up working once the CPU server stuff got enabled.
Next I wanted to ensure the system would boot automatically, without a VNC session and a person to accept the boot parameters. I ran `9fs 9fat` to gain access to the boot config, and edited `/n/9fat/plan9.ini`, adding the following:
user=glenda
And switching `bootargs` to `nobootprompt`. I rebooted to test, and confirmed that it fully booted without my intervention.
I then went to FQA section 7.3.3, instructions for setting up a fileserver.
First, I switched the system to CPU sever mode by editing `/n/9fat/plan.ini` and either adding or editing the `service` parameter:
service=cpu
I then had to ensure networking would still come up - I edited `/rc/bin/cpurc` and made sure the line `ip/ipconfig` was included.
I gave the `glenda` user a password (putting in my password instead of supersecret):
auth/factotum -g 'proto=p9sk1 dom=my9front user=glenda !password=supersecret'
Then I followed the nvram setup and the CPU server setup. I had to make sure ports 17019 and 567 were both open on my firewall.
I also explicitly set the servicedir in `/rc/bin/cpurc`. I removed some of the if-statements, and added the following:
serviced=/rc/bin/service # cpu+auth server auth/keyfs -wp -m /mnt/keys /adm/keys auth/cron >>/sys/log/cron >[2=1] & aux/listen -q -t /rc/bin/service.auth -d $serviced tcp
There appeared to be two files to enable the CPU and auth services:
/rc/bin/service/tcp17019 # CPU server /rc/bin/service.auth/tcp567 # Auth server
This confirmed to me that I should only need those two ports forwarded in QEMU, and optionally later 17020 for mounting the filesystem (have not tried this yet). To confirm I understood this correctly, I rebooted the VM with all but those two ports closed. I was able to successfully log into drawterm.
9front-drawterm -a 192.168.0.105 -h 192.168.0.105 -u glenda
Note: I have noticed that when logging in via drawterm, I seem to have to sometimes wait for nearly a minute for some sort of timeout to occur before drawterm proceeds. This only happens on my LAN, not my Wireguard network. I have more permissive firewall rules on my Wireguard network, so my current suspicion is there is another port that I may need unblocked or modified. Temporarily shutting off the firewall during this testing section might be a good idea. If anyone has any info on what could be happening here, I'd love to hear from you!
I then created a `riostart-remote` script so that my drawterm would connect straight to a graphical connection: I copied the `riostart` script from `/usr/glenda/bin/rc/riostart` to `/usr/glenda/bin/rc/riostart-remote`, customized it as I saw fit, then added a few lines under the CPU section of `$home/lib/profile`:
if(! webcookies >[2]/dev/null)
webcookies -f /tmp/webcookies
webfs
plumber
rio -i riostart-remote
bind -ac /mnt/term $home/term
The bind mount at the end allows me to conveniently access the drawterm machine's files from `$home/term` (they are usually available under `/mnt/term` whenever one logs into a system).
I read that there is a way to get the 9fat mount working from in here, so in the future I might consider that. Otherwise, the 9fat can only be serviced from a VNC connection.
I confirmed that I was able to log in over drawterm and have my session start up as expected, even after rebooting the machine.
I next did some reading about setting up a CPU server from a 9p.io page:
Configuring a Standalone CPU Server
I read something in the FQA section 7.4.3.2 that misled me into thinking I needed to convert to a newer key format. I believe that can be ignored - I think it is for people who had an existing installation when the change to the new key format occurred. New installations seem to already use the new key format.
After some more reading I determined that I would want to set up a secstore. So, as hostowner (glenda), I made the secstore:
mkdir /adm/secstore chmod 770 /adm/secstore
I added the following to cpurc:
auth/secstored
Then I added glenda to the secstore by running:
auth/secstored auth/secuser glenda
At this point I also tried to fix the sysname in cpurc - replacing all instances of `cirno` with `my9front` anywhere I could find it. I rebooted, and all looked good.
Logging in via drawterm I tried accessing the secstore:
ipso
It seemed to load fine, even if it was empty.
Next I decided to add a `thor` user, to use as my regular login. Do some reading in the FQA, but what I ended up running:
auth/keyfs auth/changeuser thor auth/secuser thor echo newuser thor >> /srv/hjfs.cmd
Then I generated files by logging in as the user and running
/sys/lib/newuser
This seemed to work. Inspecting the `$home/lib/profile` under the `cpu` section showed `auth/factotum` was being run on login. It raised an error:
secstore secstore: remote file factotum does not exist secstore: cmd failed
And prompted for the secstore password. I suspected this is related to the nvram being wrong or the factotum not having anything initialized in it. So, I initialized the secstore factotum file with a blank file:
touch factotum auth/secstore -p factotum
Then I rebooted to see if the error goes away. That seemed to work. It prompts for my password and my secstore key on login (they are the same), and there are no errors. From what I can tell, this is correct behavior.
The glenda user exhibited the same symptoms, so I logged in there and used the same solution to fix it.
Netsurf has been ported to 9front. I installed it. It is fantastic.
After a quite a lot of reading, it seems that modern 9p/drawterm connections should already be using TLS encryption; it is set up during the auth/handshake at some point.
For using CA certificates for TLS for other services, such as HTTPS or 9p without auth, I did find some hints on Peter Mikkelsen's blog:
How I get tls certificates for 9front
For the time being, I won't be hosting any public shares, so I'll consider this setup done!
Hopefully somebody, somewhere finds this useful. If you have any tips or corrections, please do not hesitate to let me know (see the [Contact] tab on my website).