Alright, last two chapters of the book!


# Chapter 13

This chapter is about building a file server using P9 proto.

It starts by describing disk devices, devices defined as `/dev/sd*`.
The driver can be controled with /dev/sd<..>/ctl
For example: /dev/sdD0/data will be an abstraction of data on disk. (raw)
The disk is partitioned under a plan9 partition, with sub-ones.

The utilities used to do that are fdisk for the whole disk partitions
and disk/prep for plan9 ones.
We can also create partition by sending commands (echo) to the ctl of
the disk but it's wiser to use fdisk to avoid mistakes.

This kind of reminds me of this research I had done on disks storage:
https://venam.nixers.net/blog/unix/2017/...ystem.html

The kfs or fossil command are used to manipulate/create/format the filesystem.

The next part of the chapter is about learning about 9p protocol, which
is akin to CIFS and NFS.
We dive a bit into traces of requests and responses of the protocol.

The goal, as mentioned at the start of the chapter is to build a file
server that will handle these 9P requests.

To do this, we have to initialize an Srv struct, which is a struct with
pointers to definitions of method. It's kind of like the virtual file
system in a way, similar calls too.
It's "plugged" into the system through postmountsrv function, basically
running the 9p server implementation.

An NB here is that instead of using malloc, we must use emalloc9p. "The
9P library provides implementations for emalloc9p, erealloc9p, and
estrdup9p that mimic the ones with a similar name in the C library".

The example of a semaphore as a server is such a bad example. They
could've chosen something else that is much more obvious.

The chapter ends with the Plan9 build system, an equivalent of Makefiles
with a similar syntax that is called mkfile and built with the mk command.

# Chapter 14

The final chapter is on security.

Quote:Plan 9 are not supposed to have local storage nor any other local resource
to protect!
A Plan 9 terminal is just a machine to connect to the rest of services
in the network

That's a nice take on security. Terminals are single user machines,
expected to have nothing on them, and nothing to hide.

Quote:; cat /dev/hostowner
nemo;
; cat /dev/sysname
nautilus;
It may be a surprise, but the machine name is irrelevant for security
purposes. Only the host owner is relevant.

So these are irrelevant too.

To make sense of Plan9 security we have to think in a distributed way.
Each server is responsible for the protection of its content. Doing
user authorization and authentication.
Authentication is then delegated to a separate node, an authentication
server. But this server itself doesn't store the keys, they are stored
in a keyfs (sort of like an HSM, but in software like a java keystore).

This sort of reminds me of OAuth2, with identity servers, or maybe even Vault.
They are grouped into authentication domains, user@domain.

All auth is implemented in a program called factotum, an authentication
agent. Like an ssh-agent, sort of.

I wasn't so satisfied with the last chapters, I felt they missed the
point of explaining by getting lost in the details, it was burdening
the reading processing.
Frankly, even though it covers generic OS topics, I'm not sure it would
be the book I'd recommend to students studying operating systems.
The first few chapters were interesting to discover Plan9 but afterwards
it went downhill for me.