Re: book chapters

Hello,

I have many students in my university.
In receiving reports from my students, Plan 9  doesn't have safe 
solution.
I would be happy if Plan 9 has append only directory.
The concept is similar to that of append only file.

Kenji Arisawa

Re: book chapters

> I would be happy if Plan 9 has append only directory.
> The concept is similar to that of append only file.

a blind directory?  gee that can't be hard.

is there a replica limit?

Is there a limit to the number of pull-s one can do from
sources.cs.bell-labs.com? If there is, I must've reached it since my
replica/pull simply returns without issuing any errors or warnings...

I'm paranoid because I've modified slightly /dist/replica/network to mount
fossil (/srv/boot /n/boot) instead of the default kfs and I'm worried that
something may be wrong with what I've done...

Also, I know chgrp's man page says that I need to be in 'allow' mode to
change the owner of a file, but I feel slightly uncomfortable having all
those files in the main tree owned by my update user (I've removed myself
as the update user -- again too paranoid that I may do 'mk' in /sys/src/cmd
without having bound my private src/ before it...). Besides, replica/pull
complains a lot because it tries to chgrp -u sys all new files...

What do you think?  Should files be neatly 'chgrp -u sys'-ed? Or should I do
a pull only in a fossil -A mode (equivalent to disk/kfscmd allow)? 

andrey

Re: book chapters

You already have that.  Make the directory only writable by the
students.  They can create files in it but can't remove them.

From: Kenji Arisawa <arisawa <at> ar.aichi-u.ac.jp>
Subject: Re: [9fans] book chapters
Date: 2003-06-30 23:16:37 GMT

Hello,

I have many students in my university.
In receiving reports from my students, Plan 9  doesn't have safe 
solution.
I would be happy if Plan 9 has append only directory.
The concept is similar to that of append only file.

Kenji Arisawa

Re: is there a replica limit?

> I'm paranoid because I've modified slightly /dist/replica/network to mount
> fossil (/srv/boot /n/boot) instead of the default kfs and I'm worried that
> something may be wrong with what I've done...

I hesitate to apply replica direct to real file server/fossil. ☺

Kenji

Re: is there a replica limit?

On Tue, 1 Jul 2003 okamoto <at> granite.cias.osakafu-u.ac.jp wrote:

> I hesitate to apply replica direct to real file server/fossil. ☺
> 

I've been doing it to my kfs server for 8 months without a hitch (I trust
both Russ' testing process and bell-labs developers enough for that) on a
machine with a single user -- me. None of my development stuff is touchable
by replica at all, too.

Now with fossil I managed to overwrite cpurc and termrc (two servers with
the same name, wrong rio window, etc :) but I just copied the old ones from
last night's venti snap.

With fossil and a mirrored disk I feel much more comfortable doing daily
updates, and much less paranoid of loosing my data. 

andrey

strange things in /sys/log/auth

i have the following appearing in my logs several times a day:

[ see the attached file, i snipped this to ensure that my mailer doesn't
mangle it ]

the number of entries match the number of non-default users that I have
added. for each one of them I've chosen "never" as the 'expire' option. the
users were added using the fossil console, and then their options were set
using auth/changeuser. 

is this a bug? should I change the way I'm adding users?

there's nothing else wrong with authentication -- it works fine for all
users, as far as I can see...

andrey

plan9 Jun 30 18:54:18 keyfs starting warnings: 3f00dbba 3eff8a2d
warning: can't open bootes/expire:r
warning: can't open rminnich/expire:r
warning: can't open €\€€€)€͝€mX€h%€K€>€9F€X€€€€Ԟ€$€€€߶€€€v?€€'€€,?D%+€€€5€x€€yyk5%2iR/expire:r
warning: can't open €\€€€)€͝€mX€h%€K€>€9F€X€€€€Ԟ€$€€€߶€€€v?€€'€€,?D%+€€€€€€)>€"€
a€€>/expire:r
warning: can't open €v4/expire:r
warning: can't open €\€€€)€͝€mX€h%€K€>€9F€X€€€€Ԟ€$€€€߶€€€v?€€'€€,?D%+€€€€€€Z€€ڋP€3/expire:r
warning: can't open €\€€€)€͝€mX€h%€K€>€9F€X€€€€Ԟ€$€€€߶€€€v?€€'€€,?D%+€€€€v€f€€€~€€/expire:r

Re: strange things in /sys/log/auth

> there's nothing else wrong with authentication -- it works fine for all
> users, as far as I can see...

I've seen this before.  It looks like the key that keyfs is using
(presumably taken from nvram) doesn't match the key that was used when
initially creating /adm/keys.  Odds are good you added all your users
after the initial corruption due to the key mismatch, though, which is
why authentication still works correctly.

If you have a small number of users, I'd suggest blowing away the
current keys file and recreating it using the password that's in nvram,
and then reassigning passwords.  If that's too much of a hassle, then
you could cd into /mnt/keys and just remove all the corrupt entries,
but I'm not sure if you wouldn't run into other problems later on down
the road.

Or, I could be completely wrong.  However, the last time I saw behavior
like what you're describing, it was due to a key mismatch.  Luckily,
since I had just set up the auth server and there was no one in it, it
was easy for me to just recreate it.

	- Dan C.

Re: strange things in /sys/log/auth

What Dan said.

It looks like what I saw when I gave my cpu server (and thus its
keyfs) the wrong key.  What does "ls -l /mnt/keys" on your cpu's
console print?  It should be something like this:

cpu% ls /mnt/keys
/mnt/keys/bootes
/mnt/keys/claudia
/mnt/keys/cross
/mnt/keys/dhog
/mnt/keys/geoff
/mnt/keys/martha
/mnt/keys/plus
/mnt/keys/upas

If instead it looks like:

/mnt/keys/€9F€X€€€€Ԟ€$€€
/mnt/keys/+€€€€v€fÂ

Then keyfs has the wrong key in nvram.

Re: strange things in /sys/log/auth

well, it only has two users -- bootes and me, nobody else that I've added
appears there...

it must be said that the events i reported do not appear in the logs from
the very beginning. first it was a complaint about bootes' expire, then 
another user appeared there, and then i got the corrupted strings...

the fact that the keys were just moved from a kfs server with all the other
data from the disk probably wouldn't have helped.

i'll follow dan's suggestion and reset everything once i can sit behind the
console...

andrey

ps: /mnt/keys of a cpu server:

kn9% ls -l /mnt/keys
d-r-xr-xr-x M 117 bootes sys 0 Jun  3 12:38 /mnt/keys/bootes
d-r-xr-xr-x M 117 bootes sys 0 Jun 24 09:13 /mnt/keys/andrey
plan9%

On Mon, 30 Jun 2003, Geoff Collyer wrote:

> What Dan said.
> 
> It looks like what I saw when I gave my cpu server (and thus its
> keyfs) the wrong key.  What does "ls -l /mnt/keys" on your cpu's
> console print?  It should be something like this:
>