On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote: > > "/sys/log/cron: rc (cpurc): can't open: 'sys/log/cron' is a directory" > > > > ... not quite sure what to make of that. > > that's weird. it shouldn't be a directory, just an append-only file > like most of the others in /sys/log. not sure how it got directoried. > remove and replace. >
Easy enough! > > * Could anyone explain or tell me where I can find more information > > regarding what all is going on with the following: > > > > con -l /srv/fscons <snip> > /srv/fscons is the conventional location for you fossil console; see > fossilcons(8) for more information, including what uname, fsys, and > create do. > Aha - thanks, I was looking at fs(8) -- which wasn't helping me. > > * At one point I created a new user with 'auth/changeuser' that I didn't > > need/want. What's the suggested means of removing this user? > > see keyfs(4). remove the directory. > Works like a charm. Knowing the the correct manual page(s) to be looking at certainly helps! <grin> I can't help though but be curious as to why there's no command, or an additional switch to changeuser, to remove users from the keyfile. I guess due to Plan 9's simplicity motto? > > * Similarly to the question above, how should I delete a user created > > with uname via fscons? > > you may or may not realize this, but it's sometimes non-obvious: users > on the auth server are different from users on a file server, and they > don't need to be the same (depending on what you want). changeuser and > keyfs work on the auth server; anything done on fossil's console > (/srv/fscons) is on the file server. again, see fossilcons(8). > Thanks, yes I was aware (superficially) that there was a difference between users on the auth server and users on the file server. I read through fossilcons(8) though, and I'm still not sure how to delete a filesystem user. I almost got the impression that it's not possible - due to the mention that "Once an id is used in file system structures archived to Venti, it is impossible to change those disk structures, and thus impossible to rename the id"; but reading on, I guess to remove a user, I just need to manually edit the user table? Will it hose things if I edit /adm/users directly, from a shell, rather than executing 'users [ -r file ]' on /srv/fscons? Again, it's seems lacking that there isn't simply a 'uname -name' switch. (I'm not complaining, just bewildered.) > > * I hope I don't get beat up on this one (well, I hope I don't get too > > beat up on _any_ of these questions...), but it seems strange that > > something as important as a cpu/auth server would just go and boot up > > right into the hostowner... apparently this a non issue - so what am I > > not understanding? > > philosophy. plan9, like research unix before it, recognizes that if > you have physical access to the box, all bets are off anyway. > Well, sounds like a flawed philosophy taken too far. Flawed, because all bets are not necessarily off with physical access; and taken too far, because... dang, what harm is there in providing that last means of interference to a hostile? Cpu/Fs/Auth server says: "If you can touch me, I'm _all_ yours..." What a fascinatingly... loose... form of security, if you catch my drift. > security consists of locking your door. > ... which means bootes is just a quick hacksaw or boltcutter or crowbar away... so why even bother with a locked door? Security is ultimately about the price/time/effort/skills a potential attacker (or vandal) is willing (and able) to put forth in order to overcome a system's security measures. A password is amazingly effective for a vast number of the most common circumstances encountered in many typical environments. Anyhow... I guess there's no reason to argue/debate! Looks like I have some options: > if you really, really need to get around that, you have a few options. > the closest to "out of the box" is to install and run a screen locker; > a few people have written those, although i'm not entirely certain any > are current. more ambitiously, there was a 3rd edition patch to detach > the console devices from the cpu server itself, asking for login and > treating it as an attached terminal. those are assuredly out of date, > but if you really need the functionality, that's where to start. > > alternately, just run something on the console that doesn't have a > "quit" function. the console doesn't have interrupt functionality. > Thanks for the suggestions! That 3rd ed. detached console devices patch seems to be the best path, but probably the least trivial. Cheers, Corey
