# Moved (2020/03/07)
This blog has moved to https://seh.dev.
The source is hosted at https://github.com/henesy/henesy.github.io.
# Using p9sk1 authentication in modern 9front (2018/12/27)
Many moons ago 9front moved to dp9ik auth from p9sk1 due to security concerns. However, there may be cases, such as using parts of plan9port, that one may want to enable the old cpu protocol and p9sk1 authentication.
Steps to complete:
-
Enable p9sk1 by removing the
-N
flag from the authsrv(2) init scripts:-
/rc/bin/service.auth/authsrv.il566
-
/rc/bin/service.auth/tcp567
-
-
Enable the legacy cpu(1) protocol server via:
- mv '/rc/bin/service/!tcp17010' /rc/bin/service/tcp17010
Assuming your auth/cpu server is otherwise configured correctly, you should be able to use 0intro's legacy drawterm to connect to your server as a proof of concept.
Some useful configuration verification commands:
-
netaudit
-
auth/debug
-
auth/asaudit
Some information on the auth differences is available: http://9.postnix.pw/ref/auth_notes
# Intro to Graphics on Plan 9 (2018/09/21)
A common question asked all over the Plan 9 community is that of how to get started making GUI applications, as 9 is closely married to the GUI.
While I might get around to a step by step tutorial on GUI programming in another post or location, I'd rather compile some helpful examples and resources for getting started.
Some useful programs for reference:
Some useful documents for reference:
- bouncing ball example again
- c programming in plan 9
- graphics(2)
- addpt(2)
- allocimage(2)
- draw(2)
- event(2)
- frame(2)
- window(2)
- draw(3)
- rio(4)
- font(6)
Hopefully this helps an intrepid adventurer get started.
Feel free to reach out to me on 9fans or IRC and I'll gladly expand this list.
Happy hacking!
# Creating and Applying 9front Patches (2018/09/07)
Creating
To create a patch we first pull 9front's hg repo and bind our files into place:
sysupdate
bind -a /dist/plan9front /
cd /
In this example we're making a patch for rio, any combination of folders should work:
bind $home/src/rio /sys/src/cmd/rio
To get the latest commit:
hg log | sed 5q
A first log output example might be:
changeset: 6705:eecec6d3b341
user: cinap_lenrek@felloff.net
date: Mon Sep 03 20:54:26 2018 +0200
summary: vt: fix plumbsel(), snarfsel()
The commit hash we're looking for is eecec6d3b341
and we can use it as follows to make the diff file:
hg diff -r eecec6d3b341 /sys/src/cmd/rio/wind.c > $home/mypatch.diff
Applying
In the same way we pull and bind our files into place:
sysupdate
bind -a /dist/plan9front /
cd /
For individual files you could use ape/patch
if desired, but for most 9front patches you should use hg:
hg import --no-commit -f $home/mypatch.diff
The patch is now applied!
If you wish to trash the changes from the patch, use:
hg revert
# Touring Blit in 2018 (2018/05/30)
Ever wondered if there was a nice way to get a VAX-grade, semi-authentic, Blit experience?
Good news! While 9front ships with a Blit emulator via games/blit
you can also connect to UNIX from GNU/Linux with this handy port and plan9port.
To get a connection going just run the following on your emulator of choice:
blit -t 'tcp!papnet.eu!8888'
Choose ken
as your username.
Enjoy your authentic UNIX experience!
# DiscordFS — A Tale of Two Clients (2018/05/24)
Around a year ago I worked on my first attempt at a Discord client that would build and function on 9front. Since then the landscape hasn't changed much and neither has the client. It works well enough for my needs and the two or so other people who use it. Since then however, the number of members in the 9fans Discord Server has grown many times its original size. Summarily, the interest in a native client for 9front grew to scale. The problem is that for Discord to be experienced fully as intended, it demands a GUI. Plan 9 fits the bill well for this as the GUI model is very intuitive and the graphical use of the system is encouraged at every turn. The problem is that the Go language used for the client is not only a slight bit unreliable on Plan 9, but is not the native language of the system. A concession has been made as to where the Discord library used is fairly robust and well maintained, so we didn't want to abandon it, but we wanted to use C to fit the 9front software standards people expect.
The solution is a filesystem. What follows is the rough format of such a filesystem, outlining how such a filesystem would be laid out. DiscordFS could be run as a client on its own and be in Go, though it would not be very intuitive. The idea model for a native 9front client would be a C program which expects a filesystem interface for Discord (provided by DiscordFS) and then handles graphical display and processing of user input complete with colors and images as per the Electron Discord client.
Structure
As always, input is much appreciated. Feel free to pitch in on the conversation via the 9fans Discord Server.
/
henesy/
...
heneinesy/
9fans/
ctl
roles
about
channels/
general/
ctl
messages
about
...
members/
mveety/
ctl
roles
about
mora/
...
r40k/
...
...
- ctl — A file which allows documented commands to be run and operated against a given element (add/remove/change permissions)
- messages — Dynamically loads the last N messages for a channel as they're read depending on the ctl configuration
- about — Displays general, parseable, information about a given element
- attachments — A directory containing files that were attached to messages. The messages folder, when a file is attached, can have special syntax to denote that a message is attached and what its filename and hash are.
In this case /
is the top directory in the mounted fs with subfolders for each user and then for each user subfolders for each server they are a member of, etc.
# Install Notes for Plan 9 Second Edition (2018/03/19)
A thanks to aap for providing copies of the floppy images and isos used to perform the test installs. None of this would have been able to happen without you.
Disclaimer: I have not successfully managed to get Plan 9 2e (2e from hereon) installed in qemu or physical hardware. Qemu has had issues due to the fact that I'm unfamiliar with configuring IDE in qemu. If anyone figures out how to install 2e in qemu, please let me know.
Some useful references before starting:
In general, the 2e install process breaks down into the following steps:
- Burn floppies (and cd, if desired)
- Install MS-DOS
- Install diskettes 1-4
- Install from cd (if desired)
If you have the space and ability, I recommend doing the full post-demo install.
1. Burn floppies
Diskette 1 is easy, you will write it directly to a floppy disk or just boot the .img as it ships. For diskettes 2-4 you will have .vd files that must be copied (not written) to dos-formatted floppy images or disks.
Note: These instructions assume a linux host.
To create a formatted floppy image:
mkfs.msdos -C disk.img 1440
To mount a floppy image:
mount -o loop disk.img /path/to/somedir
From this point you'd make .img's for the disk[2-4] .vd's and copy the respective file onto the image.
If you need to create floppy images from DOS disks at this time, you can do:
dd bs=512 count=2880 if=/dev/fda of=dos.img
2. Install MS-DOS
You can choose (probably) any 6.xx+ version of DOS up to Windows 95, but I've only tested the installation with MS-DOS 6.2. FreeDOS or DrDOS might work, but again, I haven't tested them.
The required size for a demo install is pretty small, you can probably stick with DOS defaults if you just want to make a demo installation. If you want a full installation, you will need to install DOS on a 1GB+ partition (recall that DOS can't handle disks/partitions greater in size than 2GB) or so. The full installation will copy the entire contents of the cd (~500MB) and you will have a full demo installation in addition to this.
Perform the DOS installation by following the prompts, nothing special needs to be done here.
Note: DOS does not need cd drivers as the drivers come from the disk1 image. As such, you are limited with hardware you can use by the supported ware provided in the 2e installer. Good luck.
3. Install diskettes 1-4
Load and boot into disk1.
You should be prompted for a disc to install to, in my case /dev/hd0
. Then select the primary DOS partition (Probably partition 0). Select Proceed
when prompted whether to install or not. Diskette 1 will then copy some files to the DOS partition.
When prompted for configuring installation, note that options not explicitly configured will not be written to the plan9.ini file generated. That is, there are no defaults. Configuring extra options you're not sure about shouldn't hurt anything, but if you select a video mode that is unsupported on your video card (emulated or otherwise), the GUI will fail to start and you'll have to boot into disk1 to reconfigure your system (reconfiguring through disk1 is the encouraged method for fixing bad plan9.ini's regardless).
My configuration looked something like this:
- 'VGA setup' → 800x600x1 → vga (using …x8 broke graphics for me even though …x1 worked fine)
- 'Mouse type' → PS2
- 'ATA (IDE) controller' → secondary - Port 0x170 → IRQ 15 (this is how I used my cd drive for the full install with the drive configured as IDE's Secondary Master)
- 'File system console' → CGA
Once configured, save the plan9.ini when prompted and reboot into DOS.
Run plan9\b
. Select option [1] for Diskette System installation. You'll be prompted to load each diskette in series, as per usual. Once installation is finished, select 'Make the newly installed Plan 9 the default' and then select 'Reboot'.
Load and boot into disk1.
Go through the configuration process as before. After the configuration is complete you will be prompted to set a default configuration for your Plan 9 installation. Select 'An active Plan 9 system' then select your disk with DOS and Plan 9 installed. Reboot into DOS.
Run plan9\b
. Congratulations, you now have a working Plan 9 Second Edition demo installation installed! If all you wanted was to install the demo, you can stop here. If you wish to create a full 2e installation, continue to the next section.
4. Install from cd
Now that all the hard work is out of the way, the cd install is pretty simple.
Note: If at any point you are prompted with a warning about overwriting an existing Plan 9 installation, don't mind it. Overwriting is intended during the installation phases.
Boot back into disk1 and reconfigure your install to point to the correct IDE or SCSI drive where your cd will be loaded and set the install mode to 'File System Installation' when prompted.
Note: From VirtualBox I had configured my cd drive on IDE to be Secondary Master. When configuring the installer, I had selected IDE → Secondary → IRQ 15
and the disk1 installer was able to find the cd drive.
Boot into DOS and run plan9\b
. Make sure the cd is inserted. Selection option [2] for installing from cd, when prompted for the location of the cd, navigate to the correct device
Assuming you have sufficient space for the installation, the installer should copy all the files off of the cd. you will be prompted to 'Make the newly installed Plan 9 the default', select this and then 'Reboot'.
Once the copying is done, reboot into disk1 and reconfigure your install and set the install mode to 'An Active Plan 9 System'. Reboot.
From DOS run plan9\b
, when prompted for a user enter tor
. There is no none
user by default from the cd, this is an old mistake.
Instructions for adding the user are in the INSTALL document from the top list of references.
Congratulations, you have a full installation of Plan 9 Second Edition, please enjoy responsibly.
~S
# Using Plan9Port Mkfiles (2018/03/03)
Recently I decided to play with the idea of porting Nemo's semfs (from Ch13 of his book) to *nix as a learning exercise.
As a goal I wanted to change as little of the original code as possible. Even with the plan9port 9c/9l bindings however, some portions of the source (unnamed struct members, mostly) did not build and required changing.
A notable point of change was the mkfile for semfs, originally using the mkone file, I needed to find the equivalent mkfile in plan9port.
The original mkfile looked something like this:
</$objtype/mkfile
TARG = semfs
OFILES = \
sem.$O \
semfs.$O
HFILES = \
sem.h
BIN = $home/bin/$objtype
</sys/src/cmd/mkone
After a bit of digging, a suitable replacement was found in plan9port:
<$PLAN9/src/mkhdr
TARG = semfs
OFILES = \
sem.$O \
semfs.$O
HFILES = \
sem.h
BIN = $home/bin/$objtype
<$PLAN9/src/mkone
Assuming that a functional plan9port install exists and $PLAN9 is set to the root of said install, the mkfile works exactly as one would expect. Pleasantly, the nature of the mkhdr file means that the output binary will be named o.* in a similar pattern to the 6.out or 8.out style produced by the Plan 9 C compilers.
# Testing 1 2 3… (2018/02/23)
Hello from Postnix space!