9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: uriel@cat-v.org
To: rsc@swtch.com
Cc: 9fans@cse.psu.edu
Subject: [9fans] Re: wiki changes
Date: Thu, 16 Feb 2006 17:10:01 +0100	[thread overview]
Message-ID: <1d2d864e73c8adcadc59a6b81779c961@cat-v.org> (raw)
In-Reply-To: <4cd2b7e516bb1cf90dbf06fe748780bc@swtch.com>

> Thanks for the recent changes to the wiki.
> They're pretty good but I found a handful of small errors,
> which are listed below.  
>
> On the whole the new text looks better.  Thanks.
> Russ

Thanks for the feedback and the corrections!


>> - #DISABLE PERMISSIONS CHECKING
> 
> If you killed this section, how are they supposed to 
> have permission to do the rest?  At the least you
> should tell them how to add glenda to sys.

That is documented in [adding a new user], I will point there.

IMHO it's much better to add glenda to group sys than the "disable
permissions checking" hack.  I have asked several times, is there any
good reason why glenda is not in group sys by default?  It would make
setting up things for new users much easier.

I thought it was you who said disabling permission checking should be
deprecated.


>> - #! # auth/keyfs -wp -m /mnt/keys /adm/keys >/dev/null >[2=1]
>> + #! # auth/keyfs -p -m /mnt/keys /adm/keys >/dev/null >[2=1]
>>   #! # auth/cron >>/sys/log/cron >[2=1] &
> 
> Why did you remove the -w?  Regardless of whether you
> think it's a good idea to use -w, that's what cpurc says!

Sorry, I got confused with the other call to keyfs where -w was
superfluous.  I added it back.

> This text (cut from earlier in the page) should be added to the
> beginning of this section:
> 	> - #You can decide what name to give your cpu server owner. This is the
> 	> - #user that all the cpu servers run as. We'll name the user 'bootes';
> 	> - #it is recommended that you also choose 'bootes' as it will appear in
> 	> - #the instructions frequently.

Yes, I deleted it because it was in a place where it was not relevant,
I'm still not too happy with that text, but I added it back as it is.


> You got rid of the text about creating the key file and
> the cron log file.  That's an important step (no one has
> permissions to create in /adm) and needs to be
> updated for fossil:
> 
>> - #It's necessary to clear the existing key file:
>> - #
>> - #! rm /adm/keys
>> - #! disk/kfscmd 'create /adm/keys bootes bootes 660'
>> - #
>> - #If necessary, create cron's log file with:
>> - #
>> - #! disk/kfscmd 'create /sys/log/cron bootes sys 664 a'
Yes, but this assumes kfs. And the cron file was created before:
! main: create /active/sys/log/cron bootes bootes a664

I don't think I ever created the /adm/keys file and it all "just
worked", /adm is mode 775 adm:sys and the user is assumed to be in
group sys, so it should not be a problem, I think.  But my picture of
how all this fits together is not very clear, so probably I got
something wrong.

>> - #Optionally, configure your mail setup (described above) by editing
>> - #rewrite, remotemail, smtpd.conf, and names.local, all in /mail/lib.
>> - #
> 
> This is important!  Why did it go away?

Because it's covered in [mail configuration].  I will add a link to it
at the bottom along the link to the file server setup link.

>>   #COMPILE AND INSTALL A STANDALONE CPU/AUTH KERNEL
> 
> The compiling part can go away - just use /386/9pccpuf.
Good idea.

>>   # *	A netkey binary is available from
>>   #	[ftp://plan9.bell-labs.com/netkey/] .
>>   # *	If you want to access cpu server from the internet and have a
>>   #	firewall, open up ports 567 and 17013.
> 
> Will anyone have any idea what a netkey binary is at this point?
Not me :)

>> + #Also note that in case you really want a dedicated file server, a
>> + #new version of the file server code updated to use the latest
>> + #version of 9P and with various other improvements can be found at:
>> + #/n/sources/contrib/geoff/fs64.tgz
> 
> Fs64 adds 64-bit files sizes.  The current /sys/src/9 already
> speaks the latest version of 9P.
Oh, it would be nice if fs64 could be merged with /sys/src/9/fs/,
maybe goeff could get direct write access to that sub-tree as he is
the one maintaining that code?


I think I fixed all the other problems you reported, let me know if
there is anything else.

Thanks

uriel





       reply	other threads:[~2006-02-16 16:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4cd2b7e516bb1cf90dbf06fe748780bc@swtch.com>
2006-02-16 16:10 ` uriel [this message]
     [not found] <b8fb0cd32aa3b19d181f5b0db1fec046@swtch.com>
2006-02-16 16:20 ` uriel
2006-02-16 11:24   ` Russ Cox
2006-02-16 16:44     ` uriel
2006-02-16 17:22       ` Russ Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1d2d864e73c8adcadc59a6b81779c961@cat-v.org \
    --to=uriel@cat-v.org \
    --cc=9fans@cse.psu.edu \
    --cc=rsc@swtch.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).