[1025] in athena10
Re: [Fwd: [JIRA] Created: (ATN-23) Kerberos 4 tickets not obtained
daemon@ATHENA.MIT.EDU (Tim Abbott)
Sat Jan 31 16:42:32 2009
Date: Sat, 31 Jan 2009 16:41:31 -0500 (EST)
From: Tim Abbott <tabbott@MIT.EDU>
To: Evan Broder <broder@mit.edu>
cc: debathena@mit.edu
In-Reply-To: <49837CDD.1020102@mit.edu>
Message-ID: <alpine.DEB.2.00.0901311632270.2057@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Okay, this should now be fixed with the latest version of
debathena-reactivate.
I initially thought that my fix didn't actually work, until I realized
that schroot.conf is actually automatically generated at login time, and
thus my testing fix of just changing schroot.conf didn't work.
By the way, it seems far too easy to make the chroot fail to de-allocate,
requring one to reboot the machine (one easy way to break a machine is to
become root, start an ssh server inside the chroot as root, and then
logout).
I think using unionfs for our schroots would substantially mitigate this
problem. Because unionfs doesn't require that you allocate the space for
your chroots in advance, leaking a unionfs directory because of some
problem doesn't prevent you from allocating a new one.
(schroot doesn't support unionfs without a patch that hasn't yet been
merged in any release, but I've been using a patched version at work for a
while now, and it works fine).
-Tim Abbott
On Fri, 30 Jan 2009, Evan Broder wrote:
> Yep.
>
> - Evan
>
> Tim Abbott wrote:
>> I have some guesses; I can take a look at it at tomorrow's hackathon.
>> I assume this is reproducible on the XVM cluster test machine?
>>
>> -Tim Abbott
>>
>> On Fri, 30 Jan 2009, Evan Broder wrote:
>>
>>> Hey Tim -
>>> The KRBTKFILE set by libpam_krb524 isn't sticking going into the
>>> login session for the cluster machines. The KRB5CCNAME set by
>>> libpam_krb5 is. Any idea as to why?
>>>
>>> - Evan
>>>
>>>
>