Re: [OpenAFS] Questions regarding AFS ticket lifetime

[Jeffrey Altman]

Automatic renewal in NIM is used at many sites so I think you need
to figure out what tickets you have and what cache is being used.
kinit -R does exactly the same thing that NIM does.

Of course, I don't know why the configuration is set to renew when 
there is 1 minute left.
You want to renew when there is much more than one minute.  I think 
default is 30 minutes.

On Friday, April 20, 2012 10:25:55 AM, Anders Magnusson wrote:
> Thanks Jeffrey, now lot of things became clearer :-)
>
> But to solve this incident; since automatic renew in NiM do not work
> but kinit -R && aklog does work for the API cache, we are planning to
> add this to the Task Scheduler.  Do you see any problem with doing it
> like this?
>
> -- Ragge
>
>
> On 04/20/2012 03:40 PM, Jeffrey Altman wrote:
>> Anders:
>>
>> If you configure the default credential cache to be MSLSA: then the LSA
>> credentials will be used.
>>
>> The functionality (an explorer shell logon hook) that was used to copy
>> credentials at logon no longer exists on Vista and later versions of
>> the operating system.  Since the functionality does not exist, the
>> functions exported from kfwlogon.dll do not get executed and no
>> Kerberos tickets can be copied in to the API: credential cache.
>>
>> I have plans to build a new in kernel credential cache mechanism using
>> the AFS Authentication Groups available in the 1.7.x series.  I have no
>> available resources at the moment to implement it and I can't make a
>> commitment as to when I will.
>>
>> At the moment afslogon.dll will obtain a new AFS token at logon, but it
>> will not be renewable.
>>
>> Jeffrey Altman
>>
>>
>> On Friday, April 20, 2012 9:25:13 AM, Anders Magnusson wrote:
>>
>>> Yes, I have seen that, but that do not explain the behaviour since I
>>> have no wish to fetch thingd from MSLSA.
>>> Integrated logon works, but fetching new krbtgt at unlock of the login
>>> window does not.
>>> And BTW, importing tickets from MSLSA to API seems to work (pressing
>>> import button).
>>>
>>> -- Ragge
>>>
>>
>
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info



signature.asc
Description: OpenPGP digital signature

Re: [OpenAFS] Re: Kernel NULL pointer dereference

[Andrew Deason]

On Fri, 20 Apr 2012 18:30:58 -0500
Ken Elkabany  wrote:

>> I hope 'vos changeaddr' is not something you run very often. You should
>> almost never run that command.
> 
> Not at all. We have a fileserver that has two IPs that map to one of
> its interfaces; one accessible via LAN, one accessible via WAN. We
> wanted all accesses to be done through the local IP so we used
> changeaddr.

Augh, no. This is not how you relocate/renumber/etc a fileserver. The
'vos changeaddr' command should _never_ be run (unless you run it with
the -remove switch) unless you're dealing with some uncommon old
fileservers or something like that. Please never do this again.

If you want to change the IP addresses that a fileserver advertises, you
just alter the list of IP addresses on the fileserver (either by
changing the interface lists or by modifying NetInfo/NetRestrict/etc)
and restart it. If you really want to not restart it, you can use the
'vos setaddrs' command; but that's pretty new and even then it's not
necessary to use.

-- 
Andrew Deason
adea...@sinenomine.net
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: Kernel NULL pointer dereference

[Ken Elkabany]

On Fri, Apr 20, 2012 at 10:30 AM, Andrew Deason wrote:

> On Thu, 19 Apr 2012 18:55:08 -0700
> Ken Elkabany  wrote:
>
> > We have 2 OpenAFS servers running 1.4.14. We have many clients that we
> > just switched over to 1.6.1pre1. Starting earlier today, we started
> > getting NULL pointer dereferences, which has been completely hosing
> > the clients. The client machines hang on any call that deals with AFS,
> > whether it's "ls /", "ls /afs", "klist", etc...
>
> 'klist' shouldn't touch AFS...
>

I agree. Perhaps I remember incorrectly, though the whole filesystem seemed
to have been in a very bad state (hence hanging on "ls /").


>
> > A "vos changeaddr" was done earlier today, whereby a large collection
> > (4000) of volumes were mistakenly assigned to another server. These
> > were corrected with "vos syncvldb" followed by "vos syncserv". I
> > mention it here, as it's the only thing we've done to the AFS cluster
> > today.
>
> I hope 'vos changeaddr' is not something you run very often. You should
> almost never run that command.
>
>
Not at all. We have a fileserver that has two IPs that map to one of its
interfaces; one accessible via LAN, one accessible via WAN. We wanted all
accesses to be done through the local IP so we used changeaddr.
Unfortunately, we pointed all the volumes to a different, incorrect server.

I'm also not sure if just running syncvldb/syncserv will entirely fix
> that; changeaddr has screwed up server entries pretty bad in the past. I
> wouldn't say you're out of the woods until you're still fine after a
> fileserver restart.
>
> It looks like it didn't. Due to some combination of changeaddr, syncvldb,
and syncserv, it looks like some volumes had 2 identical RO entries. After
removing all the RO entries for volumes that exhibited this issue, the
segfaulting went away. This was a lengthy operation as we have 4000+
volumes each with read only copies.


> > Here's what we found in the syslog:
> >
> > Apr 20 01:30:43 SERVER kernel: [12861236.027818] BUG: unable to handle
> > kernel NULL pointer dereference at 0028
> > Apr 20 01:30:43 SERVER kernel: [12861236.027836] IP: []
> > afs_Conn+0x1e7/0x260 [openafs]
>
> 1.6.1pre1 is not a great version to be running, but I can't think of
> something that's been fixed since then that would address this. If
> someone else has some idea, feel free to say otherwise.
>
> We did an early upgrade to the daily build of Ubuntu Precise, which had
1.6.1pre1. We just saw the update to 1.6.1-1 from two days ago (thanks
Sergio), so we'll be upgrading asap.


> That offset suggests dereferencing sa_flags for a NULL srvAddr. The only
> place I think that can happen is:
>
>/* First is always lowest rank, if it's up */
>if ((tv->status[0] == not_busy) && tv->serverHost[0]
>&& !(tv->serverHost[0]->addr->sa_flags & SRVR_ISDOWN) &&
>!(((areq->idleError > 0) || (areq->tokenError > 0))
>  && (areq->skipserver[0] == 1)))
>
> so it suggests that we have a vol struct with a server that has 0
> srvAddrs attached. I think maybe this is possible if we had another
> server struct 'steal' the srvAddr away, so we removed the srvAddr and
> we're left with none.
>
> One guess at what happened:
>
>  - something tries to look up a volume A, and knows that it's on a
>   server with IP address X
>  - 'vos changeaddr' created a new non-mh server entry for IP X
>  - we look up some other volume B, see it's on IP X, but we make a new
>   server struct for the non-mh server, and steal X away from the other
>   mh server struct
>  - we need to look up volume A again, and serverHost[0] is pointing to a
>   server that used to have the srvAddr for IP X, but since it was
>   reassigned, the first srvAddr is now NULL.
>
> I'm not exactly sure what we'd want to happen in that situation. The
> quick fix is to just check for the NULL srvAddr, but I'm not immediately
> sure if that would cause us to keep trying to use a volume struct with
> no reachable servers until the vol entry expires.
>
> I (or someone) would need to experiment a bit to verify that. However,
> if something like the above is the case, this should never happen unless
> you make server identity/numbering mistakes like that. If someone else
> wants to look, I would guess this is reproducible by accessing a vol,
> changing the server uuid, accessing a different vol on the same server
> and then accessing the first vol again. Or something like that.
>
>
Thank you for taking the time to think about this. Once again, after
deleting the duplicate RO entries the problem disappeared. If you need any
help in reproducing this issue, do let me know. However, since it happened
on our live production systems, we aren't keen on making it happen again.


>  --
> Andrew Deason
> adea...@sinenomine.net
>
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>

[OpenAFS] Re: Kernel NULL pointer dereference

[Andrew Deason]

On Thu, 19 Apr 2012 18:55:08 -0700
Ken Elkabany  wrote:

> We have 2 OpenAFS servers running 1.4.14. We have many clients that we
> just switched over to 1.6.1pre1. Starting earlier today, we started
> getting NULL pointer dereferences, which has been completely hosing
> the clients. The client machines hang on any call that deals with AFS,
> whether it's "ls /", "ls /afs", "klist", etc...

'klist' shouldn't touch AFS...

> A "vos changeaddr" was done earlier today, whereby a large collection
> (4000) of volumes were mistakenly assigned to another server. These
> were corrected with "vos syncvldb" followed by "vos syncserv". I
> mention it here, as it's the only thing we've done to the AFS cluster
> today.

I hope 'vos changeaddr' is not something you run very often. You should
almost never run that command.

I'm also not sure if just running syncvldb/syncserv will entirely fix
that; changeaddr has screwed up server entries pretty bad in the past. I
wouldn't say you're out of the woods until you're still fine after a
fileserver restart.

> Here's what we found in the syslog:
> 
> Apr 20 01:30:43 SERVER kernel: [12861236.027818] BUG: unable to handle
> kernel NULL pointer dereference at 0028
> Apr 20 01:30:43 SERVER kernel: [12861236.027836] IP: []
> afs_Conn+0x1e7/0x260 [openafs]

1.6.1pre1 is not a great version to be running, but I can't think of
something that's been fixed since then that would address this. If
someone else has some idea, feel free to say otherwise.

That offset suggests dereferencing sa_flags for a NULL srvAddr. The only
place I think that can happen is:

/* First is always lowest rank, if it's up */
if ((tv->status[0] == not_busy) && tv->serverHost[0]
&& !(tv->serverHost[0]->addr->sa_flags & SRVR_ISDOWN) &&
!(((areq->idleError > 0) || (areq->tokenError > 0))
  && (areq->skipserver[0] == 1)))

so it suggests that we have a vol struct with a server that has 0
srvAddrs attached. I think maybe this is possible if we had another
server struct 'steal' the srvAddr away, so we removed the srvAddr and
we're left with none.

One guess at what happened:

 - something tries to look up a volume A, and knows that it's on a
   server with IP address X
 - 'vos changeaddr' created a new non-mh server entry for IP X
 - we look up some other volume B, see it's on IP X, but we make a new
   server struct for the non-mh server, and steal X away from the other
   mh server struct
 - we need to look up volume A again, and serverHost[0] is pointing to a
   server that used to have the srvAddr for IP X, but since it was
   reassigned, the first srvAddr is now NULL.

I'm not exactly sure what we'd want to happen in that situation. The
quick fix is to just check for the NULL srvAddr, but I'm not immediately
sure if that would cause us to keep trying to use a volume struct with
no reachable servers until the vol entry expires.

I (or someone) would need to experiment a bit to verify that. However,
if something like the above is the case, this should never happen unless
you make server identity/numbering mistakes like that. If someone else
wants to look, I would guess this is reproducible by accessing a vol,
changing the server uuid, accessing a different vol on the same server
and then accessing the first vol again. Or something like that.

-- 
Andrew Deason
adea...@sinenomine.net

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] batch/cron jobs writing to afs file systems

[Harald Barth]

> I'm looking for any help and/or advice or better yet an example of a
> working batch/cron system for writing to an afs file system.

I think the credentials should be long enough for worst job wall time
length at job submission time. So the credentials should be "stuffed
away" during qsub and then when the job is started the job start part
should forward the credentials into all batch nodes. That's how our
old and modified (hackish) easy does it. But it is old and modified 
and should be replaced.

> I did come across a project called AUKS
> (http://auks.sourceforge.net/) which looks like it could do the job,
> but it's not clear to me how to actually use it.

See

http://workshop.openafs.org/afsbpw10/wed_3_2.html

What I don't like with auksd is actually on slide 14

>>  Single addressless credential per user
>>Stored in Auks Memory Cache
>>Provided to requesters without KDC interaction
>>Forwarding to thousands of peers without KDC interaction

I think I want KDC interaction when forwarding tickets and issuing service 
tickets.

> For info we use a mixture of scientific linux 5 and 6 machines in
> the group and use torque/maui for controlling the batch system. The
> afs servers are all running openafs 1.6.0 on scientific linux 6.2
> boxes.

I have looked at torque. Both at the gssapi branch and the cgroups
branch. I was not happy with what I saw. So I will continue to look at
slurm instead. Unfortunately other things pop up all the time, so I
can't say how much time I can spend on this. We mostly run Centos 5
and some 6 (yet another Redhat recompile like SC, but without the cool
"scientific" in its name).

Harald.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Questions regarding AFS ticket lifetime

[Anders Magnusson]

Thanks Jeffrey, now lot of things became clearer :-)

But to solve this incident; since automatic renew in NiM do not work
but kinit -R && aklog does work for the API cache, we are planning to
add this to the Task Scheduler.  Do you see any problem with doing it
like this?

-- Ragge


On 04/20/2012 03:40 PM, Jeffrey Altman wrote:

Anders:

If you configure the default credential cache to be MSLSA: then the LSA
credentials will be used.

The functionality (an explorer shell logon hook) that was used to copy
credentials at logon no longer exists on Vista and later versions of
the operating system.  Since the functionality does not exist, the
functions exported from kfwlogon.dll do not get executed and no
Kerberos tickets can be copied in to the API: credential cache.

I have plans to build a new in kernel credential cache mechanism using
the AFS Authentication Groups available in the 1.7.x series.  I have no
available resources at the moment to implement it and I can't make a
commitment as to when I will.

At the moment afslogon.dll will obtain a new AFS token at logon, but it
will not be renewable.

Jeffrey Altman


On Friday, April 20, 2012 9:25:13 AM, Anders Magnusson wrote:


Yes, I have seen that, but that do not explain the behaviour since I
have no wish to fetch thingd from MSLSA.
Integrated logon works, but fetching new krbtgt at unlock of the login
window does not.
And BTW, importing tickets from MSLSA to API seems to work (pressing
import button).

-- Ragge





___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] batch/cron jobs writing to afs file systems

[Andrew Pickford]

Hi,

I'm setting up an afs cell for the particle physics research group at 
Glasgow University. I've got the afs cell setup and working and I'm now 
looking at how user jobs on the local batch system and user cron jobs 
can write to the afs cell.


I'm looking for any help and/or advice or better yet an example of a 
working batch/cron system for writing to an afs file system. I did come 
across a project called AUKS (http://auks.sourceforge.net/) which looks 
like it could do the job, but it's not clear to me how to actually use it.


For info we use a mixture of scientific linux 5 and 6 machines in the 
group and use torque/maui for controlling the batch system. The afs 
servers are all running openafs 1.6.0 on scientific linux 6.2 boxes.



Thanks,

Andrew

--

Andrew PickfordEmail: andrew.pickf...@glasgow.ac.uk
Rm 473, Kelvin BuildingTelephone: +44 141 330 4197
Dept of Physics and Astronomy  Fax: +44 141 330 5881
University of Glasgow  ppewww.physics.gla.ac.uk/~pickford/
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Running vos or pts against a specific cell server

[Jeffrey Altman]

On Friday, April 20, 2012 6:31:04 AM, Harald Barth wrote:
>> Sadly, AFSCONF is only used if a configuration file cannot be found in the 
>> default location.
>
> That I would say is either a bug in the implementation or in the design. When 
> someone sets an
> environment variable, the meaning is to 99% to use the value in it.
>
>> I wrote the support for -config to work around this, but that
>> feature is, as Andrew says, only available on master.
>
> I would suggest that the priority should be changed in the following way:
>
> 1. Command line if given
> 2. Env variable if set
> 3. Default place as compiled in
>
> Harald.

I think that is a reasonable patch for inclusion in 'master' if someone 
wants to submit it to gerrit.

Jeffrey Altman




signature.asc
Description: OpenPGP digital signature

Re: [OpenAFS] Questions regarding AFS ticket lifetime (fwd)

[Jeffrey Altman]

On Friday, April 20, 2012 8:33:09 AM, Stephen Joyce wrote:
> On Fri, 20 Apr 2012, Lars Schimmer wrote:
>
>>> The problem is:
>>> 1) Automatic renewal of the tgt by NiM do not work on Windows 7.  It
>>> did
>>> on XP.
>>> 2) Letting NiM fetch a new tgt when the user unlocks the screen do not
>>> work.  It did on XP.
>>
>> Windows 7 is not Windows XP, MS changed a lot based on security and user
>> management.
>> Read the OpenAFS release notes about obtaining tokens on login:
>> http://www.openafs.org/dl/openafs/1.7.10/winxp/ReleaseNotes/html/ch03s06.html
>>
>>
>> "Integrated Logon will not transfer Kerberos v5 tickets into the user's
>> logon session credential cache. This is no longer possible on Vista and
>> Windows 7."
>
> I thought the gotcha above was only true if UAC was turned on AND the
> user in question was an admin.
>
>  "On Windows Vista, Windows 7, and Windows Server 2008 the operating
> system does not permit the importation of the Kerberos Ticket Granting
> Ticket if the active user account is a member of the Administrators or
> Domain Administrators groups and User Account Control (UAC) mode is
> active."
> 
>
>
> Have you tried ticket importing as a non-admin user and/or with UAC
> off? It must still be configured in the NIM options, of course.
>
> Cheers, Stephen

This is not a UAC issue.  This is related to the lack of a logon and 
logoff event handler in Vista and beyond.

Jeffrey Altman




signature.asc
Description: OpenPGP digital signature

Re: [OpenAFS] Questions regarding AFS ticket lifetime

[Jeffrey Altman]

Anders:

If you configure the default credential cache to be MSLSA: then the LSA 
credentials will be used.

The functionality (an explorer shell logon hook) that was used to copy 
credentials at logon no longer exists on Vista and later versions of 
the operating system.  Since the functionality does not exist, the 
functions exported from kfwlogon.dll do not get executed and no 
Kerberos tickets can be copied in to the API: credential cache.

I have plans to build a new in kernel credential cache mechanism using 
the AFS Authentication Groups available in the 1.7.x series.  I have no 
available resources at the moment to implement it and I can't make a 
commitment as to when I will.

At the moment afslogon.dll will obtain a new AFS token at logon, but it 
will not be renewable.

Jeffrey Altman


On Friday, April 20, 2012 9:25:13 AM, Anders Magnusson wrote:

> Yes, I have seen that, but that do not explain the behaviour since I
> have no wish to fetch thingd from MSLSA.
> Integrated logon works, but fetching new krbtgt at unlock of the login
> window does not.
> And BTW, importing tickets from MSLSA to API seems to work (pressing
> import button).
>
> -- Ragge
>




signature.asc
Description: OpenPGP digital signature

Re: [OpenAFS] Questions regarding AFS ticket lifetime

[Anders Magnusson]

On 04/20/2012 01:30 PM, Lars Schimmer wrote:

On 20.04.2012 12:53, Anders Magnusson wrote:

On 04/20/2012 09:35 AM, Lars Schimmer wrote:

   From memory, during our Windows XP days (different OS, different
OpenAFS, different Network Identity Manager, different MIT Kerberos
for Windows), just locking and unlocking the computer refreshed the
AFS ticket.

How has this changed for Windows 7 and our current setup, as this
no longer seems to be working?

Remember the 2 different credential caches of windows - one of system
at login and one for NetworkID Manager.

On Login you get a ticket/token with the Windows Builtin credential
cache which CANNOT be accessed by Network ID Manager.
Only after you obtained a token manual in NetworkID manager it renews
the token automatic and you can set the token lifetime with Network ID
manager.

The problem is:
1) Automatic renewal of the tgt by NiM do not work on Windows 7.  It did
on XP.
2) Letting NiM fetch a new tgt when the user unlocks the screen do not
work.  It did on XP.

Windows 7 is not Windows XP, MS changed a lot based on security and user
management.
Read the OpenAFS release notes about obtaining tokens on login:
http://www.openafs.org/dl/openafs/1.7.10/winxp/ReleaseNotes/html/ch03s06.html

"Integrated Logon will not transfer Kerberos v5 tickets into the user's
logon session credential cache. This is no longer possible on Vista and
Windows 7."
Yes, I have seen that, but that do not explain the behaviour since I 
have no wish to fetch thingd from MSLSA.
Integrated logon works, but fetching new krbtgt at unlock of the login 
window does not.
And BTW, importing tickets from MSLSA to API seems to work (pressing 
import button).


-- Ragge


It gives a bad user experience to tell them that they need to fetch
stuff manually,
since they did not need to do so on XP but now on Windows 7.  Therefore
we need to
find out what is wrong since this was not a problem before (with XP).

It is a security precaution situation made by MS. Go and ask MS to
change it.


-- Ragge



MfG,
Lars Schimmer


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Questions regarding AFS ticket lifetime (fwd)

[Stephen Joyce]

On Fri, 20 Apr 2012, Lars Schimmer wrote:


The problem is:
1) Automatic renewal of the tgt by NiM do not work on Windows 7.  It did
on XP.
2) Letting NiM fetch a new tgt when the user unlocks the screen do not
work.  It did on XP.


Windows 7 is not Windows XP, MS changed a lot based on security and user
management.
Read the OpenAFS release notes about obtaining tokens on login:
http://www.openafs.org/dl/openafs/1.7.10/winxp/ReleaseNotes/html/ch03s06.html

"Integrated Logon will not transfer Kerberos v5 tickets into the user's
logon session credential cache. This is no longer possible on Vista and
Windows 7."


I thought the gotcha above was only true if UAC was turned on AND the user in 
question was an admin.


 "On Windows Vista, Windows 7, and Windows Server 2008 the operating system 
does not permit the importation of the Kerberos Ticket Granting Ticket if the 
active user account is a member of the Administrators or Domain Administrators 
groups and User Account Control (UAC) mode is active." 



Have you tried ticket importing as a non-admin user and/or with UAC off? It 
must still be configured in the NIM options, of course.


Cheers, Stephen
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Questions regarding AFS ticket lifetime

[Lars Schimmer]

On 20.04.2012 12:53, Anders Magnusson wrote:
> On 04/20/2012 09:35 AM, Lars Schimmer wrote:
>>>  From memory, during our Windows XP days (different OS, different
>>> OpenAFS, different Network Identity Manager, different MIT Kerberos
>>> for Windows), just locking and unlocking the computer refreshed the
>>> AFS ticket.
>>>
>>> How has this changed for Windows 7 and our current setup, as this
>>> no longer seems to be working?
>> Remember the 2 different credential caches of windows - one of system
>> at login and one for NetworkID Manager.
>>
>> On Login you get a ticket/token with the Windows Builtin credential
>> cache which CANNOT be accessed by Network ID Manager.
>> Only after you obtained a token manual in NetworkID manager it renews
>> the token automatic and you can set the token lifetime with Network ID
>> manager.
> The problem is:
> 1) Automatic renewal of the tgt by NiM do not work on Windows 7.  It did
> on XP.
> 2) Letting NiM fetch a new tgt when the user unlocks the screen do not
> work.  It did on XP.

Windows 7 is not Windows XP, MS changed a lot based on security and user
management.
Read the OpenAFS release notes about obtaining tokens on login:
http://www.openafs.org/dl/openafs/1.7.10/winxp/ReleaseNotes/html/ch03s06.html

"Integrated Logon will not transfer Kerberos v5 tickets into the user's
logon session credential cache. This is no longer possible on Vista and
Windows 7."

> It gives a bad user experience to tell them that they need to fetch
> stuff manually,
> since they did not need to do so on XP but now on Windows 7.  Therefore
> we need to
> find out what is wrong since this was not a problem before (with XP).

It is a security precaution situation made by MS. Go and ask MS to
change it.

> -- Ragge
> 


MfG,
Lars Schimmer
-- 
-
TU Graz, Institut für ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Questions regarding AFS ticket lifetime

[Anders Magnusson]

On 04/20/2012 09:35 AM, Lars Schimmer wrote:

 From memory, during our Windows XP days (different OS, different
OpenAFS, different Network Identity Manager, different MIT Kerberos
for Windows), just locking and unlocking the computer refreshed the
AFS ticket.

How has this changed for Windows 7 and our current setup, as this
no longer seems to be working?

Remember the 2 different credential caches of windows - one of system
at login and one for NetworkID Manager.

On Login you get a ticket/token with the Windows Builtin credential
cache which CANNOT be accessed by Network ID Manager.
Only after you obtained a token manual in NetworkID manager it renews
the token automatic and you can set the token lifetime with Network ID
manager.

The problem is:
1) Automatic renewal of the tgt by NiM do not work on Windows 7.  It did 
on XP.
2) Letting NiM fetch a new tgt when the user unlocks the screen do not 
work.  It did on XP.


It gives a bad user experience to tell them that they need to fetch 
stuff manually,
since they did not need to do so on XP but now on Windows 7.  Therefore 
we need to

find out what is wrong since this was not a problem before (with XP).

-- Ragge

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Running vos or pts against a specific cell server

[Harald Barth]

> Sadly, AFSCONF is only used if a configuration file cannot be found in the 
> default location.

That I would say is either a bug in the implementation or in the design. When 
someone sets an
environment variable, the meaning is to 99% to use the value in it.

> I wrote the support for -config to work around this, but that
> feature is, as Andrew says, only available on master.

I would suggest that the priority should be changed in the following way:

1. Command line if given
2. Env variable if set
3. Default place as compiled in

Harald.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Questions regarding AFS ticket lifetime

[Arne Wiebalck]

On Apr 20, 2012, at 9:35 AM, Lars Schimmer wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 2012-04-20 07:52, Anders Nordin wrote:
>> Ok,
>> 
>> Bear with me because I might not have formulated the questions
>> correctly, I'm mostly a Windows admin and not entirely up to speed
>> on the AFS/Kerberos lingo.
>> 
>> Environment:
>> 
>> Windows 7 x64 Enterprise OpenAFS 1.7.1000 (64-bit) Network Identity
>> Manager 2.0.1.903 MIT Kerberos for Windows (64-bit) 3.2.2
>> 
>> 1)
>> 
>> Why do you need to renew the credentials manually? From what I
>> understand Network Identity Manager should handle this (until the
>> end of the renewable lifetime ofcourse). Please see the two
>> attached images.
>> 
>> http://staff.www.ltu.se/~kex/renew1.jpg 
>> http://staff.www.ltu.se/~kex/renew2.jpg
>> 
>> 2)
>> 
>> From memory, during our Windows XP days (different OS, different
>> OpenAFS, different Network Identity Manager, different MIT Kerberos
>> for Windows), just locking and unlocking the computer refreshed the
>> AFS ticket.
>> 
>> How has this changed for Windows 7 and our current setup, as this
>> no longer seems to be working?
> 
> Remember the 2 different credential caches of windows - one of system
> at login and one for NetworkID Manager.
> 
> On Login you get a ticket/token with the Windows Builtin credential
> cache which CANNOT be accessed by Network ID Manager.

Sorry if that has been discussed before, but could you remind me what
the technical reason was? 

I would guess that other kerberized applications on Windows would need 
to access that too, no? (If I am not mistaken, we have tweaked putty, for 
instance, to do exactly that).

> Only after you obtained a token manual in NetworkID manager it renews
> the token automatic and you can set the token lifetime with Network ID
> manager.
> 
> On logon you can set ticket lifetime in AD controller.
> 
>> MVH
>> 
>> Anders Nordin IT-Service
> 
> 
> MfG,
> Lars Schimmer
> - -- 
> - -
> TU Graz, Institut für ComputerGraphik & WissensVisualisierung
> Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
> Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk+REcsACgkQmWhuE0qbFyPSTwCaAn7A/pLfvD/6pgUzVWdQbfhQ
> dwIAnjo15Pa24Pc3G44pepVjj+qK3k3M
> =q4Eb
> -END PGP SIGNATURE-
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info



smime.p7s
Description: S/MIME cryptographic signature

Re: [OpenAFS] Kernel NULL pointer dereference

[Sergio Gelato]

* Ken Elkabany [2012-04-19 18:55:08 -0700]:
> We have 2 OpenAFS servers running 1.4.14. We have many clients that we just
> switched over to 1.6.1pre1.
[...]
> Tainted: P   O 3.2.0-23-virtual #36-Ubuntu

I've been informed that LP#975838 has been fixed, meaning that 1.6.1-1 will 
soon be available in Ubuntu 12.04 LTS. Thanks to Anders Kaseorg for nudging
things along. His PPA archive may be of interest; it's at
https://launchpad.net/~openafs/+archive/master
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Questions regarding AFS ticket lifetime

[Lars Schimmer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2012-04-20 07:52, Anders Nordin wrote:
> Ok,
> 
> Bear with me because I might not have formulated the questions
> correctly, I'm mostly a Windows admin and not entirely up to speed
> on the AFS/Kerberos lingo.
> 
> Environment:
> 
> Windows 7 x64 Enterprise OpenAFS 1.7.1000 (64-bit) Network Identity
> Manager 2.0.1.903 MIT Kerberos for Windows (64-bit) 3.2.2
> 
> 1)
> 
> Why do you need to renew the credentials manually? From what I
> understand Network Identity Manager should handle this (until the
> end of the renewable lifetime ofcourse). Please see the two
> attached images.
> 
> http://staff.www.ltu.se/~kex/renew1.jpg 
> http://staff.www.ltu.se/~kex/renew2.jpg
> 
> 2)
> 
> From memory, during our Windows XP days (different OS, different
> OpenAFS, different Network Identity Manager, different MIT Kerberos
> for Windows), just locking and unlocking the computer refreshed the
> AFS ticket.
> 
> How has this changed for Windows 7 and our current setup, as this
> no longer seems to be working?

Remember the 2 different credential caches of windows - one of system
at login and one for NetworkID Manager.

On Login you get a ticket/token with the Windows Builtin credential
cache which CANNOT be accessed by Network ID Manager.
Only after you obtained a token manual in NetworkID manager it renews
the token automatic and you can set the token lifetime with Network ID
manager.

On logon you can set ticket lifetime in AD controller.

> MVH
> 
> Anders Nordin IT-Service


MfG,
Lars Schimmer
- -- 
- -
TU Graz, Institut für ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723


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

iEYEARECAAYFAk+REcsACgkQmWhuE0qbFyPSTwCaAn7A/pLfvD/6pgUzVWdQbfhQ
dwIAnjo15Pa24Pc3G44pepVjj+qK3k3M
=q4Eb
-END PGP SIGNATURE-
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info