On Tue, Sep 16, 2025 at 9:36 AM <[email protected]> wrote: > Newb here. I'm trying to wrap my head around these different roles and which > goes where. Conceptually, they kinda make sense:
I'm going to be shameless and plug my own writing here: https://pub.gajendra.net/2016/05/plan9part1 Plan 9 kernels can be configured with different profiles: the two important ones vis these distinctions are "terminal" and "cpu server". Both are built from the same set of sources, and the profile determines whether the kernel's global variable "cpuserver" is set or not. The difference between them really isn't that big: they affect how much RAM is reserved for the system vs users, number of available processes, and a few other details. In fact, there's only one reference to "cpuserver" in the portable code: in the console driver, a cpu server will recognize "^P" on the console as a command to reboot itself (that can be turned off, however). A program can tell which configuration it is running under by examining the `service` environment variable, which is set by the kernel at boot time. In the Old Days, the Plan 9 file server ("kenfs") ran its own, specialized kernel that was distinct from the "normal" plan9 kernel. But that hasn't been the case for a few decades now. > TERMINAL - a lightweight install that depends on the other roles to get work > done. I think drawterm from linux qualifies, but could be another plan9 > system - can it run alone or do you also need CPU on the machine (seems like > you would). It's unclear to me what you mean when you say, "do you also need CPU on the machine". Clearly, a computer acting as a terminal needs _a_ CPU (and RAM and some IO devices, etc), but I don't think that's what you were asking. Canonically, a terminal is a discrete computer, running the "terminal" profile of the plan9 kernel. In a plan9 network, these are the machines that users sit in front of to interact with the system. Terminals are capable of running any number of programs locally, and they can be configured with a local file system and run standalone without a CPU server. In fact, for many years, when one booted the "live" version of Plan 9 from the ISO, one booted into a terminal kernel. `drawterm` doesn't really qualify, in the sense that `drawterm` is a program that runs under another, non-Plan 9 operating system. By itself, drawterm can't really do much; one may think of it as a program that emulates just enough of a plan9 terminal and its devices (/dev/draw, mouse, keyboard) so that it can connect to a remote cpu server, where all the actual work is done (including running e.g., the window system). But it doesn't run programs on its own, and there is no such thing as a "standalone drawterm". > CPU - where processing gets done, could be a superpowered workstation in the > networks, could also be the same as the terminal. "CPU" servers provide services and/or resources to the network. They can provide access to computational resources, or they may just run server programs. For example, the authentication server, secstore daemon, and file server all (usually) run on plan 9 CPU server kernels. When used for such purposes, they needn't be very "big" machines. Traditionally, they also provided shared access to machines with significant (read: expensive) computational capacity. Terminals are kind of meant to be inexpensive. They're expected to be beefy enough to provide a nice UI experience and have excellent hardware for human use (e.g., a nice keyboard, mouse, monitor, sound...that kind of thing), but not be huge machines in their own right. They don't suck, but they're not meant to be supercomputers. For things where you need lots of fast CPUs and RAM, and where it's not economically viable to provision that for each user, you'd use a shared CPU server. > FILESERVER - even though they all pretty much serve files, I get the > impression this is more than than - a dedicated server for the network > serving up stuff, kinda like NFS? Conceptually, not too far off, but the implementation is quite different. As I mentioned, in the early days, the file server ran its own dedicated kernel that ran no user processes and really did nothing other than serve files and manage its own storage devices. A novel part of the early design was the way backups worked: the file system really lived on write-once magneto-optical media in a large jukebox. Hard disks were used as a read/write cache in front of the WORM device; writes were buffered on disk, and once a day (at 5am, IIRC) all the dirty blocks modified in the previous day were written out to the WORM, and a new directory entry was created in a special filesystem indexed by date; users could mount this, and effectively "cd back in time." This subsumed traditional backup functions, and gave some modicum of revision control over time. The bulk of the system's RAM was used as a further cache in front of disk (using a scheme similar to the Unix buffer cache). However, with Plan 9 4th Edition, that version of the file server (and the WORM drive as the real backing store for the file system) was retired and replaced with userspace programs running on a standard Plan 9 kernel. Nowadays, a file server on a plan9 network is just a specially designated cpu server that is configured to serve files, and there are several different programs that do that. But since those are just normal programs, you could run them on a terminal kernel if you wanted. But outside of standalone environments (laptops and the like), in situations where you want to provide file service to a network of machines, most people don't. Note that there are also programs that allow one to serve the plan9 file protocol from e.g. Unix systems (`u9fs`). These are mostly intended for accessing resources on remote, non-plan9 machines, but folks have used them to serve as a traditional plan9 file server. > AUTHSERVER - some 9front thing that adds more sophisticated authentication? The authentication server is just a normal program that runs on a standard plan 9 system. It's often cordoned off onto a dedicated cpu server, but that's not required. One of the design goals of plan 9 was to build up a federated Unix-like environment from a network of machines, instead of having a network of small, semi-independent Unix computers. It was recognized that the traditional Unix mechanisms for authentication of either users---let alone services---wouldn't work in that environment (nor would the concept of a "superuser" like `root`), and so a scheme for doing strong, cryptographically-secured authentication was designed and implemented (it looks something like kerberos). Plan 9 machines participate in that protocol when they boot and establish their connection to the file server, when users log into terminals, and so on. This paper covers much of the current implementation: https://www.usenix.org/conference/11th-usenix-security-symposium/security-plan-9, but note that 9front has made significant changes here (dp9ik vs p9sk1). > That's how I'm thinking about now. I have installed 9front on a t430. If I > installed a terminal, cpu, fs, or authserver, it was by design of the > inst/start program or by accident... although, I did do some keychain stuff > to get the ability to drawterm into the system > > Similarly, I have installed 9legacy on my rpi3b+ and configured a barebones > way of drawterming into it. > > I'd like to learn more and do more hands on stuff. Ideally, I'd like to > distribute some pieces-partses on a few pis. I'm not finding the right docs > to help me figure out what I'm interested in to doing (admittedly, I'm not > real clear on what needs to be done). I am thinking that I want to: > > Install a CPU (just a cpu? or does it make more sense to do CPU+FS). > Install an FS (does this require a CPU?). > Install a couple Terminals (needs a CPU?). You can configure things in whatever way you like; it really doesn't matter. I suggest starting simple and building up to more complex configurations as you gain more familiarity with the system overall. Don't overthink it; if your goal is to learn how it works, you can do so with a single machine, or even For my system, I have: 1. A diskful file server running on a cpu server kernel that uses Fossil+Venti to serve files to my local network 2. A standalone auth server with a local SSD that stores my authsrv database and secstore data (e.g., that data doesn't live on the plan9 file server). That machine also runs authoritative DNS for my local domain, and provides DHCP service to my local network. 3. A standalone CPU server that boots from the file server, using the auth service to authenticate itself. 4. A Raspberry Pi serving as a diskless terminal; it boots from the file server, and uses the auth service when I log into it. I also compiled drawterm from source for e.g. my workstation, so I can connect from my Mac. > The authserv is that strictly 9front, or does it also apply to 9legacy? If > so, then I prolly ought to build an authserv, either independent or with one > of the others. The authentication protocols are different, and I'm not certain, but I believe that 9front ripped out support for the older p9sk1 auth. Perhaps it can be used from the client side to connect to non-9front things, but I honestly don't recall (Ori would know, if he cares to chime in). > All that and I have to also note that the pi doesn't seem like an install - > it seems like a live boot system that's preconfigured? If so, how does that > change the complexion of what I need to do, or does it? If I recall correctly, Richard Miller distributes his version of plan 9 for the Raspberry Pi as a filesystem image. It doesn't really change much about what you're trying to do, assuming that you don't mind how he's packaged things. > Finally, there are a plethora of tiny plan9 howtos splattered from here to > timbuktu in cloudland. It's hard to judge their quality, applicability, or > reasonability as a newb, so please don't think I haven't been looking, but I > haven't had a a lot of success with a lot of what's out there. It's either > deep enough to drown, or so shallow, my feet hardly get wet. > > Thanks, for any help y'all can offer. At this point, your best bet is to run 9front everywhere, and look at the 9front FQA. The documents on 9p.io may be helpful as well, but beware of the differences, as 9front has made changes in a number of areas. You may also want to read the original plan9 paper, "Plan 9 from Bell Labs": https://9p.io/sys/doc/9.html It answers a lot of the questions asked above. - Dan C. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf4bb650e9449e4d9-Me40de97f8056586fb8319da3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
