- Friday, February 15, 2019

release-team@conference.openafs.org

Friday, February 15, 2019< ^ >

Room Configuration

Room Occupants

GMT+0
[13:05:13] meffie joins the room
[13:17:53] meffie leaves the room
[13:43:11] meffie joins the room
[13:56:09] <meffie> good morning.
[13:58:44] <kaduk@jabber.openafs.org/barnowl> greetings
[14:00:17] wiesand joins the room
[14:00:56] <wiesand> Hi
[14:01:39] <wiesand> Bad news: I haven't gotten much done for another week.
[14:02:10] <wiesand> Good news: That project that has soaked up all my spare time for the past few months is finished :)
[14:02:24] <kaduk@jabber.openafs.org/barnowl> Me, neither.  I had a flurry of activity around last week's meeting
(mostly before?) but not much else this week.
[14:03:14] <kaduk@jabber.openafs.org/barnowl> But finishing projects is a good feeling!
[14:03:25] <wiesand> I'll waste the weekend on recovering and relaxing, but things will be back to normal starting monday.
[14:03:55] <wiesand> Oh yes it is.
[14:04:38] <meffie> i finished a project yesterday too, at least "phase 1" is done.
[14:05:25] <meffie> i plan on reviewing gerrits now as a reward.
[14:05:35] <wiesand> :)
[14:05:42] <kaduk@jabber.openafs.org/barnowl> :)
[14:05:56] <wiesand> ok, let's talk about the 1.8.3pre1 wish list…
[14:06:22] <kaduk@jabber.openafs.org/barnowl> I don't even remember which parts of that  I failed to act on last week
:(
[14:06:50] <wiesand> I do ;-)
[14:07:27] <wiesand> Cheyenne pulled up a couple of changes (mostly autoconf) lately - are those urgent to get into 1.8.3?
[14:07:38] <meffie> no.
[14:07:51] <wiesand> ok, thanks
[14:07:55] <meffie> those are just "clean ups" to remove build warnings.
[14:08:57] <wiesand> obviously, what's ready before I am, and low risk, can still make it in, but I won't block on those then.
[14:10:26] <mvita> sorry, I got detained
[14:10:27] <meffie> ok.
[14:10:46] <meffie> thanks wiesand.
[14:11:12] <wiesand> I remember "solaris vnodes" being on the wish list but not quite ready yet - any news/ETA on those?
[14:11:37] <mvita> they have been reviewed & verified
[14:12:17] <mvita> oh, I see I only verified the top one.
[14:12:20] <kaduk@jabber.openafs.org/barnowl> Oh hey, and it looks like I even did the code review for the whole
solaris-nonembed-vnode stack (But not solaris-vnop-warnings)
[14:12:34] <meffie> ben posted a question about kaio.
[14:12:46] <kaduk@jabber.openafs.org/barnowl> So I guess  I should merge those.
It would be great if you could do the "verified +1" on the whole stack,
yes (but if not I can probably fake something up)
[14:12:59] <meffie> (i think we just moved where v->v_data is assigned)
[14:13:00] <kaduk@jabber.openafs.org/barnowl> Like five minutes ago :-P
[14:13:16] <mvita> done
[14:13:22] <kaduk@jabber.openafs.org/barnowl> thanks mvita!
[14:13:27] <meffie> thank you Mark.
[14:13:27] <mvita> https://gerrit.openafs.org/#/q/topic:solaris-nonembed-vnode
[14:15:24] <kaduk@jabber.openafs.org/barnowl> Okay, have some non-embedded vnodes, SUN511_ENV!
[14:15:51] <mvita> this should allow allows an 11.3 kmod to run on 11.4 without rebuilding
[14:16:00] <mvita> allow allows allow allows
[14:16:15] <mvita> <stuck keyboard>
[14:16:31] <wiesand> Fine, I'll see to pull those up for 1.8.3pre1.
[14:17:00] <meffie> yay!
[14:17:00] <wiesand> Together with those others we discussed in the last meetings.
[14:17:39] <wiesand> And then we should get pre1 out next week.
[14:17:58] <wiesand> Finally… shame on me.
[14:18:36] <wiesand> And I think that's about what I have on the stable series today.
[14:19:05] <meffie> thank wiesand
[14:19:35] <wiesand> I also hope to have a first look at RHEL8 beta soon.
[14:19:49] <meffie> ah, good.
[14:20:30] <wiesand> I haven't read the thread on the mailing list in detail yet, but it looks like there's some trouble.
[14:20:54] <kaduk@jabber.openafs.org/barnowl> The aarch64 thing was a red herring (apparently?)
[14:21:06] <meffie> by the way, cheyenne made some updates for selinux policies for openafs servers, he's looking for where those should be submitted.
[14:21:13] <kaduk@jabber.openafs.org/barnowl> I don't know who is supposed to have responsibility for setting the
sysname, from user to spec file or what
[14:21:55] <kaduk@jabber.openafs.org/barnowl> For selinux, I kind of think we have a mismatch of distro-maintained
bits, but I could be wrong.
[14:22:32] <kaduk@jabber.openafs.org/barnowl> I think we at MIT have had to put in a workaround for client apparmor
profiles in debian/ubuntu for a while, but that is probably fairly far
afield of the selinux server profiles
[14:23:46] <wiesand> For RHEL, the Red Hat Bugzilla is at least worth a try.
[14:24:02] <meffie> ok,  this is for centos/rhel. he's looking for the correct place to send the patches. Thanks, i'll let him know.
[14:24:56] <meffie> Ben thank you for fielding the question on the aarch64 / arm64 build error.
[14:25:06] <wiesand> Dan Walsh was quite reasonable in the past here.
[14:25:20] <kaduk@jabber.openafs.org/barnowl> For rxgk-phase1, I pushed a few tweaks on
https://gerrit.openafs.org/10567 earlier this morning; it would be good
to get someone else's eyes on those changes, which I think are otherwise
set ot merge
[14:25:33] <wiesand> How to get changes into the upstream "reference policy", I don't know
[14:25:35] <meffie> yay.
[14:25:40] <kaduk@jabber.openafs.org/barnowl> meffie: no problem; this one was an easy one, luckily enough
[14:27:51] <mvita> ben: re: rxgk - I have a few questions
[14:28:05] <kaduk@jabber.openafs.org/barnowl> questions are good!
[14:28:52] <mvita> for my testing I converted ptclient to pthreads and added rxgk support via pr_Initialize2
[14:29:06] <mvita> where should I submit those?
[14:29:21] <mvita> The pthread support of course requires the rxgk-phase1 stack
[14:29:42] <mvita> sorry, I meant the _rxgk_ support
[14:29:59] <kaduk@jabber.openafs.org/barnowl> But the pthread conversion should be pretty orthogonal, right?
[14:30:05] <mvita> yeah
[14:30:29] <mvita> but you need that to make rxgk work - it's only enabled for pthreads
[14:30:49] <kaduk@jabber.openafs.org/barnowl> Right
[14:31:20] <mvita> I don't have to submit it at all - no one uses ptclient but developers - but I thought it would be useful for use
[14:31:25] <kaduk@jabber.openafs.org/barnowl> I guess, I would base your branch on top of rxgk-phase1, then make one
topic for the pthread conversion, and a separate topic for the rxgk
functionality
[14:31:27] <mvita> us
[14:31:40] <kaduk@jabber.openafs.org/barnowl> You need to submit it if we are to make good on our plans for world
odmination^W^WLWP elimination!
[14:31:40] <mvita> ok
[14:31:50] <meffie> but the non-threaded code is going to die, so we do need it.
[14:32:26] <meffie> LWP has got to go.
[14:32:49] <mvita> My other question is about rxgk on Solaris native Kerberos
[14:33:22] <mvita> I was not able to find the secret config sauce to make it build - and perhaps that distro of Kerberos is not sufficient
[14:33:45] <mvita> So I was wondering if and how we should pursue that further
[14:34:19] <kaduk@jabber.openafs.org/barnowl> IIUC solaris-native kerberos does not provide gss_pseudo_random() and is
thus unsuitable
[14:35:14] <mvita> yes, that's what's blocking
[14:35:19] <mvita> okay
[14:35:30] <mvita> I won't spend any more time on that
[14:36:13] <kaduk@jabber.openafs.org/barnowl> (I also realized at some point that the kerberos world has gone and
added a couple new enctypes since I first did the rxgk stuff, so we'll
need to update a couple places for those eventually.  But they are
somewhat boring changes, so it hasn't been a priority.)
[14:36:44] <mvita> Do you have any thoughts on my comments in 11105?
[14:36:52] <kaduk@jabber.openafs.org/barnowl> I should probably not spend time wondering if the solaris gssapi stack
gives you enough rope to provide your own gss_pseudo_rand()
implementation on top of it.
[14:37:10] <kaduk@jabber.openafs.org/barnowl> I ... should probably read those comments
[14:37:39] <mvita> well, the Solaris ccache implementation may be problematic too, based on some things I read
[14:38:08] <kaduk@jabber.openafs.org/barnowl> Oh, just the strcmp() == 0 ones?  Those seemed obviously correct when
they went by
[14:38:53] <mvita> did you want me to push a new patchset ?
[14:39:04] <mvita> or would you prefer to do it?
[14:39:18] <meffie> good catch :)
[14:39:38] <kaduk@jabber.openafs.org/barnowl> It's fine for you to do so.  I think at this point we should just
checking the individual commit and push just that one change, rather
than trying to manage the whole stack.
[14:39:46] <kaduk@jabber.openafs.org/barnowl> And yes, very good catches :)
[14:40:11] <mvita> what about the ptserver changes required to WhoIsThisWithName?
[14:40:13] <kaduk@jabber.openafs.org/barnowl> (TBH it's probably more a question of you vs. Andrew rather than you vs.
me; I haven't done much with this stack lately)
[14:41:15] <kaduk@jabber.openafs.org/barnowl> I don't have a good handle on the WhoIsThisWithName stuff in my head at
the moment
[14:41:37] <kaduk@jabber.openafs.org/barnowl> Is there a gerrit change earlier in the stack that would need changes as
well as one non-adjacent to it in the stack, or something like that?
[14:41:39] <mvita> okay - it just needs a clause to support seclevel rxgk
[14:41:58] <kaduk@jabber.openafs.org/barnowl> Or are you talking about inserting a wholly new commit?
[14:42:21] <kaduk@jabber.openafs.org/barnowl> Inserting a new commit at an arbitrary point in the stack should be fine
(e.g., to be the direct parent of the change that depends on it)
[14:42:33] <mvita> I think it would have to be a new commit - there is nothing in the stack currently that touches WhoIsThisWithName - it was just an omission
[14:42:45] <kaduk@jabber.openafs.org/barnowl> Ah, got it.
[14:42:50] <kaduk@jabber.openafs.org/barnowl> Please go ahead!
[14:43:03] <mvita> I tried to write it but couldn't get it to work
[14:43:09] <kaduk@jabber.openafs.org/barnowl> Oh.
[14:43:19] <kaduk@jabber.openafs.org/barnowl> Actually, hmm, maybe there is a draft of it later on in the non-phase1
stack.
[14:43:34] <mvita> there may well be -  I didn't look yet
[14:43:48] <mvita> where is that in gerrit?
[14:44:29] <kaduk@jabber.openafs.org/barnowl> Looks like it might not be in gerrit yet.
[14:45:11] <kaduk@jabber.openafs.org/barnowl> https://github.com/kaduk/openafs/commit/541efc7c0eb3e9ff4225b50cb8e5b6a47e8b23a9
seems to be the relevant bits in my local tree, but we should check
whether Andrew has some updated version before going too far with it
[14:46:29] <mvita> ah, yes, that's exactly what I took a stab at - this is good
[14:49:02] <mvita> I'll touch base with Andrew
[14:49:15] <kaduk@jabber.openafs.org/barnowl> That commit should be on the branch named "rxgkng" in my repo, if you
need to look for related things.
[14:49:24] <mvita> thanks
[14:50:41] <kaduk@jabber.openafs.org/barnowl> Mike, thanks for the updates on the auto-tune commit.
[14:50:57] <kaduk@jabber.openafs.org/barnowl> It looks like we're still waiting for some more updates, though -- is
that right?
[14:51:05] <meffie> ok, i'm working on the next one.
[14:51:15] <meffie> yes
[14:51:40] <meffie> going to restructure this a bit if that's ok ?
[14:51:54] <kaduk@jabber.openafs.org/barnowl> Have at it!
[14:52:11] <meffie> ok, thank you
[14:52:19] <kaduk@jabber.openafs.org/barnowl> No, thank you!
[14:52:47] <kaduk@jabber.openafs.org/barnowl> Hmm, looks like the gcc8-checking topic is stalled behind lack of
buildbot verification.  I should probably just rebase to force a new
build...
[14:52:56] <meffie> please.
[14:53:33] <meffie> sorry i dont have an easy way to force a re verification. i have an idea on how to implement such.
[14:54:00] <kaduk@jabber.openafs.org/barnowl> I mean, I  could also log in to buildbot and request a specific build,
which would (IIRC) trigger the "Verifed +1"
[14:54:09] <meffie> oh, on the buildbot front:
1. i upgraded the master to 1.8.1 (security release)
[14:54:28] <kaduk@jabber.openafs.org/barnowl> But that would require mucking with my browser settings to allow
javascript from the  non-https page, and digging out my password, and
the rebase thing has this shiny button right there
[14:54:30] <meffie> 2. we added another gentoo builder with gcc 8
[14:54:57] <kaduk@jabber.openafs.org/barnowl> cool!
[14:55:04] <meffie> 3. we have a new macos builder on the way, for recent version of macos.
[14:55:22] <kaduk@jabber.openafs.org/barnowl> I have a tab open with a sketch of instructions for building
mod_proxy_wstunnel for EL6/apache22 and may get to that this weekend
[14:55:39] <meffie> ah, yes, thank you. sorry for the extra work :(
[14:57:24] <wiesand> I'll refrain from mentioning Singularity once more ;-)
[14:57:26] <kaduk@jabber.openafs.org/barnowl> It's just the cost of modernity
[14:57:49] <kaduk@jabber.openafs.org/barnowl> Hmm, looks like you should remind me next week to look at 13431 if I
haven't by then.
[14:58:13] <kaduk@jabber.openafs.org/barnowl> I've been trying (slowly) to get through 'bosserver-no-client-dirs' as
well.
[14:59:04] <meffie> noted. thanks!
[14:59:49] <meffie> sorry that's been such a mission. the src/auth/cellconfig.c file is not my favorite. :)
[15:00:28] <kaduk@jabber.openafs.org/barnowl> Oh, and back on the fileserver-tuning, I glanced at 13488 (log tuning
values) -- did we have thoughts about putting any of that at level 5 vs.
0?  I wasn't sure how verbose we feel like making the initial impulse of
startup messages
[15:00:37] <kaduk@jabber.openafs.org/barnowl> cellconfig.c has a long history, yes.
[15:01:11] <mvita> out of time…
[15:01:22] <kaduk@jabber.openafs.org/barnowl> I  think we were about done anyway...
[15:01:29] <kaduk@jabber.openafs.org/barnowl> any other topics?
[15:01:53] <meffie> thanks, not here. have a good weekend.
[15:01:55] <wiesand> not here
[15:02:26] <kaduk@jabber.openafs.org/barnowl> thanks everyone!
[15:02:31] <wiesand> Let's adjourn then. Thanks a lot everybody!
[15:02:36] <kaduk@jabber.openafs.org/barnowl> wiesand, be sure to relax a lot over the weekend :)
[15:03:04] <wiesand> will do - first "normal" weekend in a while…
[15:04:24] wiesand leaves the room
[15:50:42] meffie leaves the room