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
next parent 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).