On Fri, 8 Jun 2007, Steven Jenkins wrote:
On 6/8/07, Derrick J Brashear
<[EMAIL PROTECTED]> wrote:
why bother removing it. all of src/kauth is
already on the block
What's the scheduled removal date for all of
src/kauth? It it's fairly
imminent, I agree there's no big win. However, if
i
On 9 Jun 2007, at 09:32, Marcus Watts wrote:
/1/ revise install directions to describe installing with
kerberos V kdc by default. (both MIT & heimdal?)
I've done this for the QuickStart Guide. It currently assumes that
you're using a MIT KDC, but it would be trivial for someone with
H
"Steven Jenkins" <[EMAIL PROTECTED]> sent:
...
> At umich.edu when we were running kaserver, we ran with "GETPASSWORD"
> > enabled. We used it so that we could rename principals -- ptserver has a
> > rename option, but kaserver doesn't. With special code running on the kdc
> > though, we could fe
On 6/8/07, Derrick J Brashear <[EMAIL PROTECTED]> wrote:
why bother removing it. all of src/kauth is already on the block
What's the scheduled removal date for all of src/kauth? It it's fairly
imminent, I agree there's no big win. However, if it's still 'to be decided
when', then I think the
why bother removing it. all of src/kauth is already on the block
On Fri, 8 Jun 2007, Steven Jenkins wrote:
On 6/7/07, Marcus Watts <[EMAIL PROTECTED]>
wrote:
...
At umich.edu when we were running kaserver, we ran
with "GETPASSWORD"
enabled. We used it so that we could rename
principal
On 6/7/07, Marcus Watts <[EMAIL PROTECTED]> wrote:
...
At umich.edu when we were running kaserver, we ran with "GETPASSWORD"
enabled. We used it so that we could rename principals -- ptserver has a
rename option, but kaserver doesn't. With special code running on the kdc
though, we could
"Steven Jenkins" <[EMAIL PROTECTED]> writes:
...
> - admin_tools.c: kas getpassword/getpasswd(which I couldn't get to work --
...
> [EMAIL PROTECTED] ]$ kas getpassword -name admin
> kas:getpassword: caller not authorized getting admin's password via loopback
> connection to GetPassword
>
> I also
Steven Jenkins <[EMAIL PROTECTED]> writes:
> There has been a discussion over on openafs-docs about vos
> online/offline & hidden commands -- there is a desire to have all
> commands and all options documented and visible for consistency's sake,
> although the documentation may note where a comman
There has been a discussion over on openafs-docs about vos online/offline &
hidden commands -- there is a desire to have all commands and all options
documented and visible for consistency's sake, although the documentation
may note where a command is dangerous or requires special privileges.
I