* [9fans] fscons users -r/-w <file> vs. editing /adm/users manually
@ 2010-05-15 23:56 Corey
0 siblings, 0 replies; 6+ messages in thread
From: Corey @ 2010-05-15 23:56 UTC (permalink / raw)
To: 9fans
If one wants to remove an existing user from the fossil file server,
is it perfectly ok to simply edit /adm/users, as the hostowner user,
directly? Or is it considered better practice to issue users -r/-w via
fossilcons? Or is there effectively no real difference?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] fscons users -r/-w <file> vs. editing /adm/users manually
2010-05-16 1:16 ` Corey
2010-05-16 1:28 ` erik quanstrom
@ 2010-05-16 8:55 ` Steve Simon
1 sibling, 0 replies; 6+ messages in thread
From: Steve Simon @ 2010-05-16 8:55 UTC (permalink / raw)
To: corey, 9fans
re: when users leave
I think the labs policy was to change the name of the user from
frank:frank
to
was-frank:frank
the first name is what is used by auth and is reported by dirstat()
the seccond name is what is held on the disk (ken fs uses integers here).
Beware: this is from memory, I have not tested this.
-Steve
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] fscons users -r/-w <file> vs. editing /adm/users manually
2010-05-16 1:28 ` erik quanstrom
@ 2010-05-16 2:34 ` Corey
0 siblings, 0 replies; 6+ messages in thread
From: Corey @ 2010-05-16 2:34 UTC (permalink / raw)
To: 9fans
On Saturday 15 May 2010 6:28:00 erik quanstrom wrote:
> > So, assuming a non-venti server: when removing users from the fossil
> > filesystem, there's no effective difference whether I do so by manually
> > editing /adm/users versus fscons: users -r/-w [file] ?
> >
> > I'm just slowly trying to accumulate "best practices" for my
> > documentation efforts.
>
> personally, i'd shy away from recommendiations on removing
> users, since it might not be appropriate for all system setups.
>
Certainly - fair and proper warning and details will be provided, however
I'm taking a "full disclosure" approach to my notes/documentation,and
am attempting to cover the sort of questions/scenarios that new users
such as myself might be confronted with.
( I'm trying to write the kind of docs that I myself would have liked
to have had available during my own initial forays into Plan 9 setup
and administration ) [I mean no sleight against the current wiki]
> anyway, if you edit /adm/users, you may have to tell the fs about
> what you've done.
>
Perfect, thanks:
In the event that a hostowner intentionally wants to remove a user from
the users table, I'll recommend that 'users -r/-w [file]' be used rather than
merely editing /adm/users directly.
cheers
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] fscons users -r/-w <file> vs. editing /adm/users manually
2010-05-16 1:16 ` Corey
@ 2010-05-16 1:28 ` erik quanstrom
2010-05-16 2:34 ` Corey
2010-05-16 8:55 ` Steve Simon
1 sibling, 1 reply; 6+ messages in thread
From: erik quanstrom @ 2010-05-16 1:28 UTC (permalink / raw)
To: corey, 9fans
> So, assuming a non-venti server: when removing users from the fossil
> filesystem, there's no effective difference whether I do so by manually
> editing /adm/users versus fscons: users -r/-w [file] ?
>
> I'm just slowly trying to accumulate "best practices" for my documentation
> efforts.
personally, i'd shy away from recommendiations on removing
users, since it might not be appropriate for all system setups.
anyway, if you edit /adm/users, you may have to tell the fs about
what you've done.
- erik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] fscons users -r/-w <file> vs. editing /adm/users manually
2010-05-16 0:55 erik quanstrom
@ 2010-05-16 1:16 ` Corey
2010-05-16 1:28 ` erik quanstrom
2010-05-16 8:55 ` Steve Simon
0 siblings, 2 replies; 6+ messages in thread
From: Corey @ 2010-05-16 1:16 UTC (permalink / raw)
To: 9fans
On Saturday 15 May 2010 5:55:33 erik quanstrom wrote:
> On Sat May 15 19:56:50 EDT 2010, corey@bitworthy.net wrote:
> > If one wants to remove an existing user from the fossil file server,
> > is it perfectly ok to simply edit /adm/users, as the hostowner user,
> > directly? Or is it considered better practice to issue users -r/-w via
> > fossilcons? Or is there effectively no real difference?
>
> if you are using venti and thus have a dump (snapshots), i would
> recommend against removing users since removing users can make
> the dump unintelligible. at coraid, we just disable auth.
>
Ack - I should have mentioned: fossil only, no venti - no snapshots.
So, assuming a non-venti server: when removing users from the fossil
filesystem, there's no effective difference whether I do so by manually
editing /adm/users versus fscons: users -r/-w [file] ?
I'm just slowly trying to accumulate "best practices" for my documentation
efforts.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] fscons users -r/-w <file> vs. editing /adm/users manually
@ 2010-05-16 0:55 erik quanstrom
2010-05-16 1:16 ` Corey
0 siblings, 1 reply; 6+ messages in thread
From: erik quanstrom @ 2010-05-16 0:55 UTC (permalink / raw)
To: corey, 9fans
On Sat May 15 19:56:50 EDT 2010, corey@bitworthy.net wrote:
>
> If one wants to remove an existing user from the fossil file server,
> is it perfectly ok to simply edit /adm/users, as the hostowner user,
> directly? Or is it considered better practice to issue users -r/-w via
> fossilcons? Or is there effectively no real difference?
if you are using venti and thus have a dump (snapshots), i would
recommend against removing users since removing users can make
the dump unintelligible. at coraid, we just disable auth.
- erik
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-05-16 8:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-05-15 23:56 [9fans] fscons users -r/-w <file> vs. editing /adm/users manually Corey
2010-05-16 0:55 erik quanstrom
2010-05-16 1:16 ` Corey
2010-05-16 1:28 ` erik quanstrom
2010-05-16 2:34 ` Corey
2010-05-16 8:55 ` Steve Simon
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).