[00:02:33] --- haba has become available
[03:25:23] --- Simon Wilkinson has become available
[05:30:16] --- summatusmentis has left
[06:40:08] --- Simon Wilkinson has left
[06:41:36] --- Simon Wilkinson has become available
[06:52:55] --- Simon Wilkinson has left
[06:55:26] --- Simon Wilkinson has become available
[07:13:27] --- Simon Wilkinson has left
[07:15:48] --- Simon Wilkinson has become available
[11:43:17] --- Russ has become available
[13:25:15] --- sxw has become available
[13:25:27] <sxw> master is currently broken. I'm working on a fix.
[13:25:54] <kaduk@mit.edu/barnowl> Are the PDF and/or html documentation built by default (if the tools
are available), or does one need to (e.g.) 'make pdf' manually?
[13:28:25] <sxw> You need to do it manually
[13:29:53] <kaduk@mit.edu/barnowl> Cool.
(Otherwise I would have to tell my packaging "no really, don't build
them".)
[13:35:08] <sxw> 1b2de4a for those who need something that builds now
[14:31:40] <kaduk@mit.edu/barnowl> Hmm, Russ around?
[14:38:08] <Russ> Yeah, somewhat at least.
[14:42:42] <kaduk@mit.edu/barnowl> I am kind of probing for ideas vaguely relating to pam_afs_session.
We run our cluster machine logins in a schroot environment; schroot
runs a PAM stack with its "login".  This breaks when going from Lucid
to Natty; I've traced it to the schroot call; before schroot, the user
has tokens and a pag and a pag keyring entity; after schroot, they are
in a different pag and keyring entity, but with no tokens.
[14:44:39] <Russ> Is /proc available in the schroot?
[14:45:15] <kaduk@mit.edu/barnowl> Yes.
[14:45:17] <Russ> And are they in a real PAG, or a UID-based PAG, aftre the schroot?
[14:45:35] <Russ> Hm.  So pam-afs-session is failing during the schroot login?
[14:46:21] <kaduk@mit.edu/barnowl> (post-schroot)
$ id
uid=20922(sipbtest) gid=65534(nogroup)
groups=65534(nogroup),123(nss-nonlocal-us
ers),7329(sipbtest),1105982306(afspag-1105982306)
$ keyctl show
Session Keyring
       -3 --alswrv  20922 65534  keyring: _ses.3313
188389646 ----s--v      0     0   \_ afs_pag: _pag
[14:46:42] <kaduk@mit.edu/barnowl> That's my suspicion, but I'm not super-confident around these parts.
[14:46:56] <sxw> Is the credentials cache available within the chroot?
[14:47:02] <Russ> Yeah, that's a real PAG.  Is the user prompted for a Kerberos authentication during the schroot, or just it just use the existing UID as the authorization?  If the latter, I bet pam-afs-session thinks there's nothing to do since it doesn't think Kerberos was used.
[14:47:03] <kaduk@mit.edu/barnowl> Yes.
[14:47:21] <sxw> 1.4 or 1.6?
[14:47:22] <Russ> I bet if you added always_aklog to the pam-afs-session options, it would go better.
[14:48:00] <kaduk@mit.edu/barnowl> (That is, yes, the cache is available; I can workaround by putting an
explicit 'aklog' in the Xsession which uses the tickets.)
[14:48:09] <kaduk@mit.edu/barnowl> 1.6
[14:48:11] <Russ> Yeah, always_aklog probably will fix the problem then.
[14:48:26] <Russ> pam-afs-session by default doesn't run aklog unless KRB5CCNAME is set in the PAM environment.
[14:48:36] <kaduk@mit.edu/barnowl> Hmm.
[14:49:48] <kaduk@mit.edu/barnowl> If I'm reading things right, pam-afs-session is pulled in for schroot
via @include common-session; do I want to always_aklog in
common-session or add an explicit pam-afs-session for pam.d/schroot ?
[14:51:00] <Russ> You probably want the latter, although there's not a lot of harm to adding always_aklog in common-session.  The downside would be that non-Kerberos logins where the user happens to have a Kerberos ticket cache somewhere aklog will find it will end up with a token when they otherwise wouldn't, but there's probably no real problem caused by that.
[14:51:32] <kaduk@mit.edu/barnowl> Probably not, especially since on these cluster machines there should
not be any non-kerberos logins.
[14:53:01] <Russ> You could at least add always_aklog to common-session and see if it fixes the problem and make sure we're on the right track.
[14:53:08] <kaduk@mit.edu/barnowl> Yup, doing that now.
[14:53:42] <kaduk@mit.edu/barnowl> Hmm, login still failed.
[14:55:35] <kaduk@mit.edu/barnowl> And no tokens post-schroot.
So much may have changed from lucid to natty that I'm not even 100%
sure I'm looking in the right place.
[15:13:47] <Russ> You could try adding debug to the pam-afs-session line and see what syslog says about what's going on.
[15:21:31] <kaduk@mit.edu/barnowl> Oh, hmm, the schroot debug output only includes:
D(2): pam_putenv: set HOME=/mit/sipbtest
D(2): pam_putenv: set LOGNAME=sipbtest
D(2): pam_putenv: set PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
D(2): pam_putenv: set SHELL=/bin/athena/tcsh
D(2): pam_putenv: set USER=sipbtest
D(1): pam_putenv OK
D(1): pam_acct_mgmt OK
D(1): pam_setcred OK
D(2): PAM authentication succeeded for user 

"Maybe I should try to do something about that"
[15:23:54] <kaduk@mit.edu/barnowl> syslog reports from pam_afs_session merely:
pam_sm_open_session: entry (0x0)
running /usr/bin/aklog as UID 1000
pam_sm_open_session: exit (success)
[15:24:44] <Russ> Okay, hm.  Then it thinks everything is fine.
[15:24:56] <kaduk@mit.edu/barnowl> But it is from gdm-session worker and before any of the schroot stuff,
so maybe this is the first time the pam stack gets run?
[15:25:28] <Russ> Is there any logging from schroot?  it sounded like schroot isn't ever calling the session stack, so maybe the problem is that pam-afs-session isn't in the auth stack for setcred?
[15:26:00] <Russ> Or that you need debug logging on the auth version, or always_aklog there.
[15:26:18] <kaduk@mit.edu/barnowl> Yeah, schroot just logs about getent/adduser and a couple other
cleanups we do to the chroot; it doesn't say anything about pam stuff.
[15:27:40] <kaduk@mit.edu/barnowl> (I'm not sure that I understand everything you said in that last
remark.)
[15:28:41] <kaduk@mit.edu/barnowl> Would throwing a pam_debug.so into schroot's stack be useful?
[15:30:54] <Russ> The stuff you pasted in there said it was running PAM.
[15:31:05] <Russ> No, adding the debug option to the pam-afs-session invocation is better.
[15:31:54] <kaduk@mit.edu/barnowl> Well, my (naive) understanding was that gdm run its pam stack, and
then our stuff hooks in the Xsession and calls schroot, which runs a
different pam stack.  The syslog output I pasted would probably have
been from the gdm stack, and I didn't see anything from schroot.
[15:32:38] <kaduk@mit.edu/barnowl> (I did not just paste from syslog since it's on a different machine
than I am; there were some prefixes that I stripped.)
[15:33:05] <Russ> Okay, I was assuming all the D(1) and D(2) stuff that you said was from schroot was, rather than being from gdm.
[15:33:26] <kaduk@mit.edu/barnowl> Oh, that stuff is from .xsession_errors
[15:35:58] <Russ> Oh, okay.  Yeah, from gdm then.
[15:36:54] <kaduk@mit.edu/barnowl> So unless schroot's pam stack is syslogging to inside the chroot, I'm
not sure where its debug output is going (if it is even sending any).
[15:52:29] <kaduk@mit.edu/barnowl> Oops, the syslog stuff I copied was from when I logged in as the local
user, not the athena user that didn't get tokens.
[16:20:23] --- haba has left
[16:54:56] --- jaltman/FrogsLeap has left: Disconnected
[18:06:21] --- jaltman/FrogsLeap has become available
[19:57:45] <jaltman/FrogsLeap> we have a new loser in the buildbot race.  opensuse-i386-builder.   the pending build queue items have been waiting more than 5 hours at this point.
[20:10:49] <shadow@gmail.com/barnowl754E0B64> i wonder why
[20:58:49] <kaduk@mit.edu/barnowl> For fbsd, kdump is just an empty file.  The reasons for this are
fairly clear; however, sometimes this empty file gets installed and
sometimes it does not.  I haven't been able to pick out a pattern to
when it does or does not get installed, which is kind of annoying.
[21:01:36] --- kaduk@mit.edu/barnowl has left
[21:02:14] --- kaduk@mit.edu/barnowl has become available