[9fans] Indoor and outdoor plumbing
Hello everyone, I'm still fairly new to plan9 after only a little over a week of exposure and intense absorption into that world. At this point, I'm coming up for air in order to see what the long time prospects are. To be honest, I'm not sure, in particular with respect to its life outside a research environment. I do though very much want it to live beyond. In that spirit and the spirit that comes along as one reads Rob Pike's paper on plumbing, I offer the below. The man pages are an exotic tool for people unfamiliar with them. However, to those who are familiar, they provide crucial and concise information for the subject on hand. The man pages within the plan9 system by and large follow the traditional format. There are a few differences in comparison to those in the unix or linux world, but really not that many. What I want to suggest here is a section for plumbing, or rather PLUMBING as the man pages might list it. I suggest this in the context of the subject line. Indoor and outdoor plumbing; what is that about? The door as I am using it in the previous terms refers to the door of ones home, or $home here. I think that most people do not have a blueprint for the plumbing in their home, or if one exists then it possibly has been misplaced. In particular, they often do not hand a plumber a blueprint if they call one to come and fix their plumbing. However for plumbing for public spaces and environments that go beyond the context of serving one individual or one family, a blueprint or some form of documentation is needed. At the least, it is very beneficial for anyone needing to work with the plumbing. Okay, so the analogous situation here is the plumbing in the plan9 system that is out (of) doors, outside $home's door. It needs documentation for sensible use. That documentation at the least provides a meeting point for conventions in the use of plumbing. However, it also provides needed structure regarding connecting points and flow of information in the form of messages. One difficulty is where to put that information in regards to the man pages, i.e. which ones. Since the command is not necessarily the source of the plumbing rules that connect with the process associated with the command, it is difficult to require the implementors of a command to be responsible for that section. Consequently, one problem to be included in the proposal is what is the basis for including plumbing information. How does one decide to put a section in a man page that one did not originally author? It becomes a problem of how to deal with community living. I assume that if the original designers of plan9 had included said section in the organization of the man page that they would have done an excellent job of defining the form of that section. However, it doesn't look as if that section was included. So if it is to be included, then it is up to the present community to figure out what should be in it. Obviously some may think that section is unnecessary. For some, possibly many, man pages that is probably true. However for others I think differently. At this point, it can be treated as a bit of an exercise as to what the form of that section should contain and how it should be presented. The spirit of the man pages seem to be (for me) that of mathematical common sense. So there it is. Any thoughts? -jeff
Re: [9fans] sheevaplug port available
there is a pull script in glenda's bin. use that. - erik I was giving that a shot, but get a few errors. Looks like it's not pulling new files: ! sys/src/cmd/ratrace.c: not replicated; will not update ! sys/src/9/kw/devtwsi.c: not replicated; will not update ! sys/src/9/omap/screen.c: not replicated; will not update ! sys/src/9/omap/screen.h: not replicated; will not update ! sys/src/9/omap/screen.h: not replicated; will not update ! sys/src/9/omap/devuart.c: not replicated; will not update ! sys/src/9/omap/screen.c: not replicated; will not update Also, I get a bunch of permissions errors, such as the following: error: copying /n/boot/386/9load: '/tmp/replica00098100' permission denied error: copying /n/boot/386/9loadask: '/tmp/replica00098100' permission denied error: copying /n/boot/386/9loaddebug: '/tmp/replica00098100' permission denied This is on a combined CPU/auth server, and was run as the hostowner (bootes). Are the permissions wrong out-of-the-box? Could this be because some directories are owned by sys while others by bootes? bootes is a member of the sys group, but as we discussed previously, that won't be honored in the current implementation. So is the proper thing to do to convert a new install to a cpu/file server (fossil) to change ownership of all files to bootes? Thanks!! -Ben winmail.dat
Re: [9fans] sheevaplug port available
error: copying /n/boot/386/9load: '/tmp/replica00098100' permission denied Not somthing as trivial as you have no /tmp? (its usually bound to $home/tmp in profile). So is the proper thing to do to convert a new install to a cpu/file server (fossil) to change ownership of all files to bootes? This is definitely not necessary. My senario at home: I have a single combined cpu/auth/file server, my hostowner is bootes. When I want to do a pull I run cpu -u bootes, as $cpu points to this server I loopback and get a new prompt, but this time as bootes (think of it like the unix su(1) command, though you don't get the console's namespace). I beleive Now I can run pull(1) from /usr/glenda/bin/rc/ and get my updates. sys/src/9/omap/screen.c: not replicated; will not update I wonder if your replica databases have got in a mess? Somone whith more nous of replicas internals may be able to help there. -Steve
Re: [9fans] sheevaplug port available
You might want to look at /tmp, you may not have a writable one from the login. Executing ramfs normally takes care of that issue. I saw the ratrace.c error this early morning, but it seems to have been transient. I guess you ought to try a second time, by then somebody more savvy than me might be awake to guide you. ++L
Re: [9fans] /sys/src/cmd source rebuild
There is a small error in the compilation of /sys/src/cmd/ip/snoopy (for the ARM, I expect the same for the 386 ... and it is): mk snoopy 5c -FTVw aoemask.c ip/snoopy/aoemask.c:42 name not declared: aoerr mk: 5c -FTVw aoemask.c : exit status=rc 5630: 5c 5632: error check to see that your mkfile is up-to-date. make sure to do a mk clean; mk all. the complaint is about autogenerated stuff. - erik
Re: [9fans] sheevaplug port available
This is on a combined CPU/auth server, and was run as the hostowner (bootes). Are the permissions wrong out-of-the-box? Could this be because some directories are owned by sys while others by bootes? bootes is a member of the sys group, but as we discussed previously, that won't be honored in the current implementation. this is almost certainly incorrect. (you don't mention you're using 9vx' #Z.) plan 9 fileservers that store files on disk (fossil, kfs, kenfs, cwfs, etc) do maintain their own groups. you may wish to put your fs into allow mode for pull. it's plan 9 file servers living in the local kernel, e.g. #c, that don't know about groups. - erik
Re: [9fans] sheevaplug port available
On Thu, Oct 21, 2010 at 1:23 AM, Benjamin Huntsman bhunts...@mail2.cu-portland.edu wrote: bootes is a member of the sys group, but as we discussed previously, that won't be honored in the current implementation. I'm pretty sure we did not say anything like that. ron
Re: [9fans] sheevaplug port available
The most effective way I've found to build from sources is to use mercurial. The second most effective way is replica. I have found I quite enjoy building from and hacking on a sources tree backed by mercurial. YMMV. ron
Re: [9fans] sheevaplug port available
this is almost certainly incorrect. (you don't mention you're using 9vx' #Z.) plan 9 fileservers that store files on disk (fossil, kfs, kenfs, cwfs, etc) do maintain their own groups. you may wish to put your fs into allow mode for pull. it's plan 9 file servers living in the local kernel, e.g. #c, that don't know about groups. - erik Wasn't that what we found just last week regarding the /dev/sd00/nvram thing? This is on native Plan 9, (er, under VMware), not 9vx or anything like that. The filesystem is fossil, not kfs. you may wish to put your fs into allow mode for pull. You can do that on fossil? I thought you had to have kfs for that? Thanks!! -Ben winmail.dat
Re: [9fans] sheevaplug port available
you may wish to put your fs into allow mode for pull. You can do that on fossil? I thought you had to have kfs for that? I don't believe you can simply switch fossil into and out of allow mode, you can specify -P to open to disable permission checking (enable allow) see fossilcons(8) but that would require a reboot. As I described before, this should not be necessary, and is not for me. just run bull as hostowner, i.e. from your server's console. -Steve
Re: [9fans] sheevaplug port available
Wasn't that what we found just last week regarding the /dev/sd00/nvram thing? This is on native Plan 9, (er, under VMware), not 9vx or anything like that. The filesystem is fossil, not kfs. i think you are confusing the block filesystem served by #S, which does not do (real) group checking, and the filesystem your files are stored on, which does. you may wish to put your fs into allow mode for pull. You can do that on fossil? I thought you had to have kfs for that? steve's right. allow mode is managed by the srv command in fossil. - erik
Re: [9fans] sheevaplug port available
I don't believe you can simply switch fossil into and out of allow mode, you can specify -P to open to disable permission checking (enable allow) see fossilcons(8) but that would require a reboot. As I described before, this should not be necessary, and is not for me. just run bull as hostowner, i.e. from your server's console. -Steve Hmm, I did run pull as the hostowner, and got the errors in the previous post. I'll check the permissions on /tmp, and I bet you're right there. Also though, what about the not replicated; will not update errors? Thanks! -Ben winmail.dat
Re: [9fans] sheevaplug port available
sys/src/9/omap/screen.c: not replicated; will not update I wonder if your replica databases have got in a mess? Somone whith more nous of replicas internals may be able to help there. -Steve Local replica DB mismatches can be handled like pull conflicts: with either -s path or -c path. In this particular case replica/pull -ssys/src /dist/replica/network should suffice. BTW, /dist/replica/network automatically toogles fossil in -AWP mode in /srv/replica - Yaroslav
Re: [9fans] sheevaplug port available
I think it worths to mention: for convenience, run as hostworner once: cd mkdir lib/replica cp -x /dist/replica/network lib/replica/sys Since then, pulls can be done as easy as replica/pull -v sys - Yaroslav
Re: [9fans] sheevaplug port available
Wasn't that what we found just last week regarding the /dev/sd00/nvram thing? This is on native Plan 9, (er, under VMware), not 9vx or anything like that. The filesystem is fossil, not kfs. The file servers that maintain on-disk file systems like kfs, fossil, kenfs, etc. all do use groups in the expected way. Part of the reason they can easily do so is that they have the file that lists the groups. The in-kernel file servers and many of the user space file servers that don't provide persistent data storage do not fully handle groups. This isn't too surprising since they might well be running without a persistent disk-based file system present. So the fossil file system does use groups, but the server that provides /dev/sd00 does not. BLS
Re: [9fans] sheevaplug port available
I'll check the permissions on /tmp, and I bet you're right there. There's a good chance your /tmp issue is not permissions, but a lack of /tmp being mounted. If your hostowner doesn't have a lib/profile or its lib/profile doesn't mount /tmp, then you won't be able to write anything to it. As has been mentioned, ramfs provides a file system that lives in memory and defaults to mounting it on /tmp. So running it will give you a /tmp even without fossil being there. BLS
Re: [9fans] sheevaplug port available
The file servers that maintain on-disk file systems like kfs, fossil, kenfs, etc. all do use groups in the expected way. yes. but there are obscure exceptions. dossrv is fully updatable, but doesn't bother with groups. but of course that's cheating. fat doesn't even support users. and it doesn't really matter. nobody stores more than boot files in fat. there are also some non-updatable fses that don't support groups such as paqfs, 9660srv, the various tapefs programs that also don't support groups. of these, i can't see how it would be useful, except in the case of paqfs. - erik
