Is afsd only a client file

[Boris Samorodov]

Hello List,


seems that the file "afsd" belongs to client part. But it compiles and
installs even when "--disable-kernel-module" option is used. Should I
prevent this file to be installed by openafs-sever port? Maybe a better
question: is there an option which prevents this file from
building/installing?


WBR
--
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Boris Samorodov]

Hello Tony,

(restored CC to freebsd-afs@, maybe someone can push me to the right
direction)

"Tony Jago" <[hidden email]> writes:

> The disable kernel module seems to only disable the kernel
> module. There are a whole heap of commands that are only for
> client. Infact the server bit is fairly small.

Hm, until now I've been sure that client is kernel modile +
afsd daemon + configuration files. Where can I find out
which file should belong to which port?


WBR
--
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Matt W. Benjamin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

Boris Samorodov wrote:
> "Tony Jago" <[hidden email]> writes:
>
>> The disable kernel module seems to only disable the kernel
>> module. There are a whole heap of commands that are only for
>> client. Infact the server bit is fairly small.
>
> Hm, until now I've been sure that client is kernel modile +
> afsd daemon + configuration files. Where can I find out
> which file should belong to which port?

That is the client, minimally.  Users need to get, list, and discard
tokens (aklog, klog, unlog, tokens*), talk to the client to configure
and debug it (fs), as well as do some AFS specific file operations (fs),
manage groups (pts), possibly also users (pts).  They should have vos,
too (vos listvldb).  You should also ship pagsh* (but I don't remember
if pags work right now in the FreeBSD client).

I'd think you should ship all of sys, rxgen, scout, udebug, cmdebug,
rxdebug, fstrace, up, and bos for administrative and debugging purposes.

Other distribution packages people have done (openafs.org) could be
helpful, also openafs top-level make has a "dest" target that puts a
Transarc style installation in a subtree "dest" of the openafs source
tree being built.

For the server, perhaps everything openafs would have put in its libexec
or sbin, and not already mentioned (except maybe copyauth).  And somehow
you are accounting for configuration files and a var tree with
appropiate permissions, as you noted.


Matt

- --

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. [phone]
fax. [phone]
cel. 734-216-5309

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJRTAEJiSUUSaRdSURCOn6AJ9a1eP1YnRIxvWLKOJ0CEAEUlJPlQCfXmIZ
L1UB412oycjPWbILHY7kLxI=
=qPHV
-----END PGP SIGNATURE-----
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Boris Samorodov]

Matt Benjamin <[hidden email]> writes:

>> Hm, until now I've been sure that client is kernel modile +
>> afsd daemon + configuration files. Where can I find out
>> which file should belong to which port?
>
> That is the client, minimally.  Users need to get, list, and discard
> tokens (aklog, klog, unlog, tokens*), talk to the client to configure
> and debug it (fs), as well as do some AFS specific file operations (fs),
> manage groups (pts), possibly also users (pts).  They should have vos,
> too (vos listvldb).  You should also ship pagsh* (but I don't remember
> if pags work right now in the FreeBSD client).
>
> I'd think you should ship all of sys, rxgen, scout, udebug, cmdebug,
> rxdebug, fstrace, up, and bos for administrative and debugging purposes.
>
> Other distribution packages people have done (openafs.org) could be
> helpful, also openafs top-level make has a "dest" target that puts a
> Transarc style installation in a subtree "dest" of the openafs source
> tree being built.
>
> For the server, perhaps everything openafs would have put in its libexec
> or sbin, and not already mentioned (except maybe copyauth).  And somehow
> you are accounting for configuration files and a var tree with
> appropiate permissions, as you noted.

OK, seems that to determine the server part is an easier task.
Let's say server executables are:
-----
libexec/openafs/
  buserver
  fileserver
  kaserver
  ptserver
  salvager
  upclient
  upserver
  vlserver
  volserver
sbin/
  bosserver
  ka-forwarder
  kadb_check
  kdb
  kpwvalid
  prdb_check
  pt_util
  rmtsysd
  vldb_check
  vldb_convert
  voldump
  volinfo
  vsys
-----

And let's assume other executables belong to the client part.

Any changes, additions, fixes? Thanks!


WBR
--
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Emmanuel Vadot-3]

Boris Samorodov wrote:

> Matt Benjamin <[hidden email]> writes:
>
>  
>>> Hm, until now I've been sure that client is kernel modile +
>>> afsd daemon + configuration files. Where can I find out
>>> which file should belong to which port?
>>>      
>> That is the client, minimally.  Users need to get, list, and discard
>> tokens (aklog, klog, unlog, tokens*), talk to the client to configure
>> and debug it (fs), as well as do some AFS specific file operations (fs),
>> manage groups (pts), possibly also users (pts).  They should have vos,
>> too (vos listvldb).  You should also ship pagsh* (but I don't remember
>> if pags work right now in the FreeBSD client).
>>
>> I'd think you should ship all of sys, rxgen, scout, udebug, cmdebug,
>> rxdebug, fstrace, up, and bos for administrative and debugging purposes.
>>
>> Other distribution packages people have done (openafs.org) could be
>> helpful, also openafs top-level make has a "dest" target that puts a
>> Transarc style installation in a subtree "dest" of the openafs source
>> tree being built.
>>
>> For the server, perhaps everything openafs would have put in its libexec
>> or sbin, and not already mentioned (except maybe copyauth).  And somehow
>> you are accounting for configuration files and a var tree with
>> appropiate permissions, as you noted.
>>    
>
> OK, seems that to determine the server part is an easier task.
> Let's say server executables are:
> -----
> libexec/openafs/
>   buserver
>   fileserver
>   kaserver
>   ptserver
>   salvager
>   upclient
>   upserver
>   vlserver
>   volserver
> sbin/
>   bosserver
>   ka-forwarder
>   kadb_check
>   kdb
>   kpwvalid
>   prdb_check
>   pt_util
>   rmtsysd
>   vldb_check
>   vldb_convert
>   voldump
>   volinfo
>   vsys
> -----
>
> And let's assume other executables belong to the client part.
>
> Any changes, additions, fixes? Thanks!
>
>
> WBR
>  

Well, the bos, vos and backup command are totally useless to an afs user
so I think it will
be better to included them in the openafs-server ports.
I don't see either the "scout" or "udebug" command in your list, this is
for monitoring servers so ...
The uss command is only for the administrator.

I think if your add those command in the list it should be good.

--
Emmanuel Vadot
[hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Boris Samorodov]

ElBarto <[hidden email]> writes:

> Boris Samorodov wrote:
>> Matt Benjamin <[hidden email]> writes:
>>
>>  
>>>> Hm, until now I've been sure that client is kernel modile +
>>>> afsd daemon + configuration files. Where can I find out
>>>> which file should belong to which port?
>>>>      
>>> That is the client, minimally.  Users need to get, list, and discard
>>> tokens (aklog, klog, unlog, tokens*), talk to the client to configure
>>> and debug it (fs), as well as do some AFS specific file operations (fs),
>>> manage groups (pts), possibly also users (pts).  They should have vos,
>>> too (vos listvldb).  You should also ship pagsh* (but I don't remember
>>> if pags work right now in the FreeBSD client).
>>>
>>> I'd think you should ship all of sys, rxgen, scout, udebug, cmdebug,
>>> rxdebug, fstrace, up, and bos for administrative and debugging purposes.
>>>
>>> Other distribution packages people have done (openafs.org) could be
>>> helpful, also openafs top-level make has a "dest" target that puts a
>>> Transarc style installation in a subtree "dest" of the openafs source
>>> tree being built.
>>>
>>> For the server, perhaps everything openafs would have put in its libexec
>>> or sbin, and not already mentioned (except maybe copyauth).  And somehow
>>> you are accounting for configuration files and a var tree with
>>> appropiate permissions, as you noted.
>>
>> OK, seems that to determine the server part is an easier task.
>> Let's say server executables are:

[old list was here]

>> And let's assume other executables belong to the client part.
>>
>> Any changes, additions, fixes? Thanks!
>>  
> Well, the bos, vos and backup command are totally useless to an afs
> user so I think it will
> be better to included them in the openafs-server ports.
> I don't see either the "scout" or "udebug" command in your list, this
> is for monitoring servers so ...
> The uss command is only for the administrator.

Done.

> I think if your add those command in the list it should be good.

Thanks for your help! Here is a changed list:
-----
bin/
  bos
  scout
  udebug
libexec/openafs/
  buserver
  fileserver
  kaserver
  ptserver
  salvager
  upclient
  upserver
  vlserver
  volserver
sbin/
  backup
  bosserver
  ka-forwarder
  kadb_check
  kdb
  kpwvalid
  prdb_check
  pt_util
  rmtsysd
  uss
  vldb_check
  vldb_convert
  voldump
  volinfo
  vos
  vsys
-----

Any more fixes?


WBR
--
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Derrick Brashear]

On Tue, Dec 16, 2008 at 3:49 AM, Boris Samorodov <[hidden email]> wrote:

> Matt Benjamin <[hidden email]> writes:
>
> >> Hm, until now I've been sure that client is kernel modile +
> >> afsd daemon + configuration files. Where can I find out
> >> which file should belong to which port?
> >
> > That is the client, minimally.  Users need to get, list, and discard
> > tokens (aklog, klog, unlog, tokens*), talk to the client to configure
> > and debug it (fs), as well as do some AFS specific file operations (fs),
> > manage groups (pts), possibly also users (pts).  They should have vos,
> > too (vos listvldb).  You should also ship pagsh* (but I don't remember
> > if pags work right now in the FreeBSD client).
> >
> > I'd think you should ship all of sys, rxgen, scout, udebug, cmdebug,
> > rxdebug, fstrace, up, and bos for administrative and debugging purposes.
> >
> > Other distribution packages people have done (openafs.org) could be
> > helpful, also openafs top-level make has a "dest" target that puts a
> > Transarc style installation in a subtree "dest" of the openafs source
> > tree being built.
> >
> > For the server, perhaps everything openafs would have put in its libexec
> > or sbin, and not already mentioned (except maybe copyauth).  And somehow
> > you are accounting for configuration files and a var tree with
> > appropiate permissions, as you noted.
>
> OK, seems that to determine the server part is an easier task.
> Let's say server executables are:
> -----
> libexec/openafs/
>  buserver
>  fileserver
>  kaserver
>  ptserver
>  salvager
>  upclient
>  upserver
>  vlserver
>  volserver
> sbin/
>  bosserver
>  ka-forwarder
>  kadb_check
>  kdb
>  kpwvalid
>  prdb_check
>  pt_util
>  rmtsysd
>  vldb_check
>  vldb_convert
>  voldump
>  volinfo
>  vsys
> -----
>
> And let's assume other executables belong to the client part.
>

Two copies of fs, vos, pts, bos, kas, asetkey, tokens, udebug, klog get
installed normally. you want copies of at least fs, vos, bos, asetkey,
udebug, pts (maybe not klog, tokens) in server, even if they are installed
elsewhere in client.

>
> Any changes, additions, fixes? Thanks!
>
>
> WBR
> --
> Boris Samorodov (bsam)
> Research Engineer, http://www.ipt.ru Telephone & Internet SP
> FreeBSD committer, http://www.FreeBSD.org The Power To Serve
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-afs
> To unsubscribe, send any mail to "[hidden email]"
>

--
Derrick
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Emmanuel Vadot-3]

Derrick Brashear wrote:

> On Tue, Dec 16, 2008 at 3:49 AM, Boris Samorodov <[hidden email]> wrote:
>
>  
>> Matt Benjamin <[hidden email]> writes:
>>
>>    
>>>> Hm, until now I've been sure that client is kernel modile +
>>>> afsd daemon + configuration files. Where can I find out
>>>> which file should belong to which port?
>>>>        
>>> That is the client, minimally.  Users need to get, list, and discard
>>> tokens (aklog, klog, unlog, tokens*), talk to the client to configure
>>> and debug it (fs), as well as do some AFS specific file operations (fs),
>>> manage groups (pts), possibly also users (pts).  They should have vos,
>>> too (vos listvldb).  You should also ship pagsh* (but I don't remember
>>> if pags work right now in the FreeBSD client).
>>>
>>> I'd think you should ship all of sys, rxgen, scout, udebug, cmdebug,
>>> rxdebug, fstrace, up, and bos for administrative and debugging purposes.
>>>
>>> Other distribution packages people have done (openafs.org) could be
>>> helpful, also openafs top-level make has a "dest" target that puts a
>>> Transarc style installation in a subtree "dest" of the openafs source
>>> tree being built.
>>>
>>> For the server, perhaps everything openafs would have put in its libexec
>>> or sbin, and not already mentioned (except maybe copyauth).  And somehow
>>> you are accounting for configuration files and a var tree with
>>> appropiate permissions, as you noted.
>>>      
>> OK, seems that to determine the server part is an easier task.
>> Let's say server executables are:
>> -----
>> libexec/openafs/
>>  buserver
>>  fileserver
>>  kaserver
>>  ptserver
>>  salvager
>>  upclient
>>  upserver
>>  vlserver
>>  volserver
>> sbin/
>>  bosserver
>>  ka-forwarder
>>  kadb_check
>>  kdb
>>  kpwvalid
>>  prdb_check
>>  pt_util
>>  rmtsysd
>>  vldb_check
>>  vldb_convert
>>  voldump
>>  volinfo
>>  vsys
>> -----
>>
>> And let's assume other executables belong to the client part.
>>
>>    
>
> Two copies of fs, vos, pts, bos, kas, asetkey, tokens, udebug, klog get
> installed normally. you want copies of at least fs, vos, bos, asetkey,
> udebug, pts (maybe not klog, tokens) in server, even if they are installed
> elsewhere in client.
>  

So if I install openafs-client and openafs-server I'll have fs at two
different place ? Seems ugly to me.
As I said vos and bos are useless to an user so they should be in the
server port.
pts must be in the client port, even it's used for creating users, it
can also be used to create sub-group (login:group).
fs is needed to setting up a new cell but not after (server side), so it
should be in the client ports.

--
Emmanuel Vadot
[hidden email]

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Derrick Brashear]

> Well, the bos, vos and backup command are totally useless to an afs user so
> I think it will



as a mere mortal long before i had any admin power i used bos and vos.

they are part of both the client and the server, and should be installed by
both.


>
> be better to included them in the openafs-server ports.
> I don't see either the "scout" or "udebug" command in your list, this is
> for monitoring servers so ...
> The uss command is only for the administrator.


udebug is a debugging command, can be run by scripts etc. belongs in both.

>
>
> I think if your add those command in the list it should be good.
>
> --
> Emmanuel Vadot
> [hidden email]
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-afs
> To unsubscribe, send any mail to "[hidden email]"
>

--
Derrick
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Derrick Brashear]

>
> So if I install openafs-client and openafs-server I'll have fs at two
> different place ? Seems ugly to me.


Sounds subjective to me :)


>
> As I said vos and bos are useless to an user so they should be in the
> server port.


Repeating yourself doesn't make me more likely to agree.

I suppose it depends how atuned to afs the user is but vos will check quotas
where ACLs do not permit, (think help desk staffed by non admins) and bos
can be used to verify that a server is unreachable because, say, it crashed,
or what restart times are. (same idea)

As a student I used them for those purposes uncompensated.



--
Derrick
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Emmanuel Vadot-3]

Derrick Brashear wrote:
>
>
>     So if I install openafs-client and openafs-server I'll have fs at
>     two different place ? Seems ugly to me.
>
>
> Sounds subjective to me :)
>  

What do you propose for the path of the redundant binaries ?

>
>     As I said vos and bos are useless to an user so they should be in
>     the server port.
>
>
> Repeating yourself doesn't make me more likely to agree.
>
> I suppose it depends how atuned to afs the user is but vos will check
> quotas where ACLs do not permit, (think help desk staffed by non
> admins) and bos can be used to verify that a server is unreachable
> because, say, it crashed, or what restart times are. (same idea)
>
> As a student I used them for those purposes uncompensated.

fs listquota is not enough for you ? (it's a real question, not ironic)
I kind of disagree for splitting the openafs ports cause as you say some
commands are useful (more or less) for both client and server part, but
as it seems that it's going to be that way, I want the port to be clean
and with no redundancy.
The thing is you can't use the some vos command without a client (vos
dump, restore etc ...) but those commands are not intend to users.
Quoting the openafs administration reference :

The commands in the vos command suite are the administrative interface
to the Volume Server and Volume Location (VL) Server. System
administrators use vos commands to create, move, delete, replicate, back
up and examine volumes, among other operations.

But I think you know that but know you see my point.

--
Emmanuel Vadot
[hidden email]

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Matt W. Benjamin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Guys,

The "vos listvldb" is one of the first things I type when I logon to a
strange AFS environment, and more importantly, one of the first things I
ask someone to type if I have to debug a problem on a client.  Both of
the commands being discussed are the client program interfaces to server
programs.

Matt

Derrick Brashear wrote:

>> So if I install openafs-client and openafs-server I'll have fs at two
>> different place ? Seems ugly to me.
>
>
> Sounds subjective to me :)
>
>
>> As I said vos and bos are useless to an user so they should be in the
>> server port.
>

- --

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. [phone]
fax. [phone]
cel. 734-216-5309

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJR7lGJiSUUSaRdSURCLrbAJ0bvGCKJOIuWdrTFaCPNkTUBSDEWACdHiVm
pbKq5e7EOTM9jW2rIb4oYFs=
=pvGs
-----END PGP SIGNATURE-----
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Derrick Brashear]

On Tue, Dec 16, 2008 at 9:14 AM, ElBarto <[hidden email]> wrote:

> Derrick Brashear wrote:
>
>>
>>
>>    So if I install openafs-client and openafs-server I'll have fs at
>>    two different place ? Seems ugly to me.
>>
>>
>> Sounds subjective to me :)
>>
>>
>
> What do you propose for the path of the redundant binaries ?
>

Putting the extra copies in sbin

>
>
>
>>    As I said vos and bos are useless to an user so they should be in
>>    the server port.
>>
>>
>> Repeating yourself doesn't make me more likely to agree.
>>
>> I suppose it depends how atuned to afs the user is but vos will check
>> quotas where ACLs do not permit, (think help desk staffed by non admins) and
>> bos can be used to verify that a server is unreachable because, say, it
>> crashed, or what restart times are. (same idea)
>>
>> As a student I used them for those purposes uncompensated.
>>
>
> fs listquota is not enough for you ? (it's a real question, not ironic)

fs lq /afs/dementia.org/usr/shadow and tell me the quota.

Then vos examine user.shadow -c dementia.org


> I kind of disagree for splitting the openafs ports cause as you say some
> commands are useful (more or less) for both client and server part, but as
> it seems that it's going to be that way, I want the port to be clean and
> with no redundancy.


> The thing is you can't use the some vos command without a client (vos dump,
> restore etc ...) but those commands are not intend to users.


vos dump can be used without a client.

>
> Quoting the openafs administration reference :
>
> The commands in the vos command suite are the administrative interface to
> the Volume Server and Volume Location (VL) Server. System administrators use
> vos commands to create, move, delete, replicate, back up and examine
> volumes, among other operations.
>
> But I think you know that but know you see my point.
>

You could say that I am intimately versed in the functionality of the pieces
and their intended and actual purposes.



>
>
> --
> Emmanuel Vadot
> [hidden email]
>
>


--
Derrick
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Palle Girgensohn-2]

--On tisdag, ti 16 dec 2008 09.28.21 -0500 Derrick Brashear
<[hidden email]> wrote:

> On Tue, Dec 16, 2008 at 9:14 AM, ElBarto <[hidden email]> wrote:
>
>> Derrick Brashear wrote:
>>
>>>
>>>
>>>    So if I install openafs-client and openafs-server I'll have fs at
>>>    two different place ? Seems ugly to me.
>>>
>>>
>>> Sounds subjective to me :)
>>>
>>>
>>
>> What do you propose for the path of the redundant binaries ?
>>
>
> Putting the extra copies in sbin

This is stupid. Why two copies? What if server and client installations get
out of sync? That couldmake problems very hard to debug, since it is hardly
really well specified which of bin and sbin that comes first in the path.
The user will get confused, at best.

It is really a very good argument for just having one port. I see no real
reason why there should be a separation. Some client binaries are only
needed when the server is installed, hence they need both. There seems to
be no clean cut between server and client in the upstream sources
(client-only and server-only installations share some binaries, e.g.), then
we should not force such a (non-clean) cut into the FreeBSD ports system
either.

Palle

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Boris Samorodov]

ElBarto <[hidden email]> writes:

> I kind of disagree for splitting the openafs ports cause as you say
> some commands are useful (more or less) for both client and server
> part, but as it seems that it's going to be that way, I want the port
> to be clean and with no redundancy.

Let me elaborate on this a little. First off, how the port will look
like is a matter of discussion. I'm open to suggestions. As well as
someone may take the port I've done and suggest his version. ;-)

My intention is following. The main port (say, net/openafs) will be one
and will install the whole thing. And there will be some options (say
WITH_SERVER_ONLY, WITH_CLIENT_ONLY) which will allow installing the
relevant part. (BTW in this case who do care if a slave ports
like net/openafs-server and/or openafs-client exist?)

While discussing port(s) questions I was told that server and client
parts are totally different and don't have anything in common. And if
they do have then my ports are wrong. That and only that pushed me to
find out which file belongs to which part.

If you (read: developers, users and admins of OpenAFS on FreeBSD) give
me a definite answer then I'll create such a port. You may even give
a triple division: those files are server, those file are client,
while those are common! I'll deal with it. Thanks.


WBR
--
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Boris Samorodov]

Boris Samorodov <[hidden email]> writes:

> If you (read: developers, users and admins of OpenAFS on FreeBSD) give
> me a definite answer then I'll create such a port.

Hm, I've found an answer. This page seems to be authorative enough:
http://www.openafs.org/manpages/index.html


WBR
--
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Derrick Brashear]

On Tue, Dec 16, 2008 at 10:44 AM, Boris Samorodov <[hidden email]> wrote:

> Boris Samorodov <[hidden email]> writes:
>
> > If you (read: developers, users and admins of OpenAFS on FreeBSD) give
> > me a definite answer then I'll create such a port.
>
> Hm, I've found an answer. This page seems to be authorative enough:
> http://www.openafs.org/manpages/index.html
>
>
notice some commands (vos) appear in "user" and "administrator"...
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Boris Samorodov]

"Derrick Brashear" <[hidden email]> writes:

> On Tue, Dec 16, 2008 at 10:44 AM, Boris Samorodov <[hidden email]> wrote:
>> Boris Samorodov <[hidden email]> writes:
>>
>> > If you (read: developers, users and admins of OpenAFS on FreeBSD) give
>> > me a definite answer then I'll create such a port.
>>
>> Hm, I've found an answer. This page seems to be authorative enough:
>> http://www.openafs.org/manpages/index.html
>>
> notice some commands (vos) appear in "user" and "administrator"...

Didn't find. Which one?


WBR
--
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Derrick Brashear]

On Tue, Dec 16, 2008 at 11:26 AM, Boris Samorodov <[hidden email]> wrote:

> "Derrick Brashear" <[hidden email]> writes:
> > On Tue, Dec 16, 2008 at 10:44 AM, Boris Samorodov <[hidden email]> wrote:
> >> Boris Samorodov <[hidden email]> writes:
> >>
> >> > If you (read: developers, users and admins of OpenAFS on FreeBSD) give
> >> > me a definite answer then I'll create such a port.
> >>
> >> Hm, I've found an answer. This page seems to be authorative enough:
> >> http://www.openafs.org/manpages/index.html
> >>
> > notice some commands (vos) appear in "user" and "administrator"...
>
> Didn't find. Which one?
>

actually i guess vos is always "user" according to that, which is bunk. you
must be an admin to run e.g. vos changeloc, vos addsite, etc...

whereas vos examine, not so much.

i could edit the web page in question if it'd help ;)

but really what it means is vos_* appears in man1, and the "admin" stuff
appears in man8. it's sort of arbitrary.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"

[Boris Samorodov]

"Derrick Brashear" <[hidden email]> writes:

> i could edit the web page in question if it'd help ;)

Yes, please.


WBR
--
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[hidden email]"