Salutations openafs-info@,
I'm wondering if we're the only cell on the planet seeing messages like
> Thu Jul 31 04:24:32 2014 ReadVnodes: unknown tag x96 found, skipping
> Thu Jul 31 04:24:32 2014 ReadVnodes: unknown invalid tag x96, aborting
transiently while releasing volumes? All hosts invol
On Thu, 31 Jul 2014 19:00:00 -0400 (EDT)
Benjamin Kaduk wrote:
> I find it interesting that we are all phrasing this in terms of a
> comparison to rpc.gssd ... which is a linux-specific piece of
> functionality. Yes, Solaris and BSD have gssd, but they're different
> implementations.
That's jus
On Thu, 31 Jul 2014, Brandon Allbery wrote:
For what it's worth, I am seeing more people move to (or start with)
NFSv4 and then run into the restrictions imposed by rpc.gssd and become
frustrated. This seems to be educational as to why OpenAFS uses tokens.
I find it interesting that we are all
On Thu, 31 Jul 2014 17:18:49 -0500
Andrew Deason wrote:
> And like you mentioned, some people don't care about PAGs, so even if
> this makes PAGs useless, that's not necessarily a problem.
Or, another possibility is that the rpc.gssd-like behavior could be
turned on only for pag-less operations,
On Thu, 2014-07-31 at 17:32 -0500, Andrew Deason wrote:
> But even this seems like a good example of why some people are
> frustrated or annoyed by all of this. Every single authentication
> framework thing needs to have its own AFS plugin, or AFS tool, or
> whatever; you just listed two different
On Thu, 31 Jul 2014 16:39:53 -0400
Dave Botsch wrote:
> On Linux, we use krb5-auth-dialog with its aklog plugin.
> Krb5-auth-dialog auto renews tickets and tokens, which is really nice
> (no need to run a separate krenew).
>
> On Mac (and replaced with krb5-auth-dialog for Linux), we use my now
On Thu, 31 Jul 2014 20:41:08 +
Brandon Allbery wrote:
> I think this also kills off PAGs pretty effectively, unless the
> equivalent of rpc.gssd has some privileged access to all PAGs and a
> way to map a given access to its PAG.
This certainly would have information about PAGs, since it goe
On Thu, 2014-07-31 at 15:29 -0500, Andrew Deason wrote:
> The alternative is to effectively "guess" what credentials we should
> be
> using, which is what NFSv4 does (rpc.gssd). That is, all you need to
> do
> to authenticate is to run a plain 'kinit' or equivalent (with no
> knowledge of AFS/NFS),
On Linux, we use krb5-auth-dialog with its aklog plugin.
Krb5-auth-dialog auto renews tickets and tokens, which is really nice
(no need to run a separate krenew).
On Mac (and replaced with krb5-auth-dialog for Linux), we use my now
quite old AFSTokens application as an all-in-one app. Like I said,
Hi all,
I've had a few users and administrators complain to me from time to time
about the existence of 'aklog'. (By 'aklog' I really mean any mechanism
to convert krb5 tickets to AFS tokens, but I'm referring to them all as
'aklog' for simplicity.) The need for an AFS-specific authentication
step
On Thu, 31 Jul 2014 13:53:48 -0500
Eric Frost wrote:
> I'm getting an error at login:
>
> groups: cannot find name for group ID 1104730420
I'm not sure why libnss-afspag would not be working for you, but is the
problem here just that this message appears? You could avoid it by just
not running
All,
I'm getting an error at login:
groups: cannot find name for group ID 1104730420
From reading it seems that's a PAG. I read that libnss-afspag would
remedy the problem. I've downloaded, compiled, and installed
libnss-afspag and modified /etc/nsswitch.conf group: line to include
afspag per th
Jeffrey Altman writes:
> 2. The choice of whether to active "fs setcrypt" is determined
> by the distribution in configuration. The Windows default
> to use "fs setcrypt on" is provided by the packaging.
Note that the Debian packaging does the same thing.
--
Russ Allbery (ea...@eyrie
On 7/31/2014 11:20 AM, Benjamin Kaduk wrote:
> One might ask why we permit such gratuitous behavior differences across
> our platforms.
Very simple.
1. There was no functional Windows client before 2004 so there
was no behavior change to worry about.
2. The choice of whether to active "fs
On Thu, 31 Jul 2014, Jeffrey Altman wrote:
On 7/31/2014 10:18 AM, Brandon Allbery wrote:
On Thu, 2014-07-31 at 16:12 +0200, Martin Richter wrote:
So this means that client caching can't be used anymore after DES has
been removed from the KDC?
No; rxkad-kdf derives a DES key from a stronger k
Hi Jeffrey,
Thanks for the clarification.
In my case this will be a new installation so no clients < 1.6.5 will be
seen on the cell ever (1.6.5 is part of SL distribution and may be used
occasionally). I hope this won't be an issue.
Public service isn't planned by now.
Martin
On Thu, 31
On 7/31/2014 10:18 AM, Brandon Allbery wrote:
> On Thu, 2014-07-31 at 16:12 +0200, Martin Richter wrote:
>> So this means that client caching can't be used anymore after DES has
>> been removed from the KDC?
>
> No; rxkad-kdf derives a DES key from a stronger key. Also clients still
> default to
On Thu, 2014-07-31 at 16:12 +0200, Martin Richter wrote:
> So this means that client caching can't be used anymore after DES has
> been removed from the KDC?
No; rxkad-kdf derives a DES key from a stronger key. Also clients still
default to no encryption in the cache manager (fs setcrypt). Just
p
So this means that client caching can't be used anymore after DES has been
removed from the KDC?
Regs
Martin
On Thu, 31 Jul 2014 13:48:36 +
Brandon Allbery wrote:
On Thu, 2014-07-31 at 15:32 +0200, Martin Richter wrote:
for any reason I just missed the three documents Thanks a lot!
On Thu, 2014-07-31 at 15:32 +0200, Martin Richter wrote:
> for any reason I just missed the three documents Thanks a lot!
> On Thu, 31 Jul 2014 09:09:11 -0400 (EDT)
>
> Benjamin Kaduk wrote:
>
> On Thu, 31 Jul 2014, Martin Richter wrote:
>
> since I wasn't
Hi Ben,
for any reason I just missed the three documents Thanks a lot!
Martin
On Thu, 31 Jul 2014 09:09:11 -0400 (EDT)
Benjamin Kaduk wrote:
On Thu, 31 Jul 2014, Martin Richter wrote:
Hello,
since I wasn't able to find out now is there any official stantement whether or
when mor
On Thu, 31 Jul 2014, Martin Richter wrote:
Hello,
since I wasn't able to find out now is there any official stantement whether
or when more secure kerberos tickets (like AES) will be supported?
DES isn't the best choice and anything I've found was dated back years ago.
Thanks in advance for
Hello,
since I wasn't able to find out now is there any official stantement whether
or when more secure kerberos tickets (like AES) will be supported?
DES isn't the best choice and anything I've found was dated back years ago.
Thanks in advance for any information.
Regards
Martin
23 matches
Mail list logo
