20080409

Agenda

Items we will be discussing:

Minutes

Bug milestoned for hardy

mathiaz listed bugs related to the server team that are milestoned for hardy:

  • Launchpad bug 213482 in openldap2.3 "Dapper to Hardy upgrade fails with slapd" : issue with cyrus-sasl2. mvo fixed it.
  • Launchpad bug 81242 in postfix "postfix-ldap is linked against gnuTLS": lamont started to look into it.

  • Launchpad bug 155947 in libnss-ldap "ldap config causes Ubuntu to hang at a reboot" : kirkland and zul spent some time investigating this bug. However, no one was able to reproduce it. It may be related to a feisty->gutsy->hardy upgrade path. Most of the reporters are also unable to provide the needed information. It was decided to stop spending time on this bug.

  • Launchpad bug 189616 in dovecot "connection problems under load with hardy dovecot": mathiaz was unable to reproduce the problem in his testing. He will contact elmo to ask for more information about the configuration.
  • Launchpad bug 199144 in apache2 "Apache2 with mpm_worker times out with many concurrent requests": zul wasn't able to reproduce the bug. More information from the reporter is needed.
  • Launchpad bug 208419 in auth-client-config "Integrate samba password in PAM": slangasek asked the opinion of the server team about adding libpam-smbpasswd to the samba-server task. mathiaz and dendrobates gave a +1.

ACTION: mathiaz to update the samba-server seed.

RC/Final testing of server isos

mathiaz reminded everyone of the Hardy Release Schedule: RC should be available in one week and Final in two weeks. That means a lot of iso testing will be conducted in the next two weeks. Testing is coordinated on the isotesting tracker [1]. Anyone interested in helping out should register on the tracker to get notified about new isos available for testing.

[1]: http://iso.qa.ubuntu.com/

sommer asked if sparc iso would be available for hardy. slangasek stated that sparc was being moved to "ports" and was not a Canonical-supported release anymore, including for server.

owh wondered if there are any specific testing requirements for ubuntu-server isos. mathiaz pointed to the Server Install test cases [2]. This wiki page outlines the process to test the ubuntu-server isos.

[2]: https://wiki.ubuntu.com/Testing/Cases/ServerInstall

Agree on next meeting date and time

Next meeting will be on Wednesday, April 16th at 21:00 UTC in #ubuntu-meeting.

Log

Started logging meeting in #ubuntu-meeting
[23:02:50] * mathiaz waves at MootBot :)
[23:03:06] <mathiaz> Today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[23:03:45] <mathiaz> Previous meeting minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20080402
[23:04:53] <mathiaz> owh: I've noticed you've attached the patches
[23:05:20] <owh> Yup, though I suspect they won't ever actually get used :)
[23:05:25] <mathiaz> nijaba: did you get a chance the talk with bdmurray about the Ubuntu Server Bug contact page ?
[23:05:34] <nijaba> mathiaz: yes I did
[23:05:53] <nijaba> mathiaz: zul an I are listed as contacts for bug triagger now
[23:06:41] <mathiaz> nijaba: great - so the purpose of the page is to list people that can be referred to online, via irc
[23:07:00] <mathiaz> nijaba: if there are any questions related to a package specific to the server are ?
[23:07:07] <nijaba> mathiaz: yes, when a triagger does not know what to do with a big, they contact us
[23:07:26] <nijaba> a bug even
[23:07:36] <mathiaz> nijaba: seems great - thanks nijaba and zul for taking up this role :)
[23:07:52] <mathiaz> I think that's all from last week meeting
[23:08:20] <mathiaz> [TOPIC] Bug milestoned for Hardy
[23:08:46] <mathiaz> As you may have noticed, we're approaching the release date of hardy
[23:09:05] <mathiaz> There is a list of bug milestone for hardy: https://launchpad.net/ubuntu/+milestone/ubuntu-8.04
[23:10:36] <mathiaz> I went through the list and here are some bugs that are relevant to us:
[23:10:45] <mathiaz> bug 213482
[23:10:46] <ubotu> Launchpad bug 213482 in openldap2.3 "Dapper to Hardy upgrade fails with slapd" [High,Triaged] https://launchpad.net/bugs/213482
[23:11:06] <mathiaz> I think mvo is working on it
[23:11:20] <mvo> mathiaz: I just posted a possible fix
[23:11:31] <mvo> requires renaming libsasl2-modules to libsasl2-2-modules
[23:11:43] <mvo> that is a bit unfortunate as the rdepends needs transitioning too
[23:11:56] <mvo> there are not that many but its not ideal timing
[23:12:09] <mvo> the fix works for me (and my kvm auto-upgrade tester)
[23:12:26] <slangasek> I always knew that libsasl2 rename was a bad idea, I just didn't know why :)
[23:12:31] <mathiaz> mvo: should this be considered as a blocker for the release of hardy ?
[23:12:34] <nijaba> (yeah, mvo too uses kvm!)
[23:12:55] <mvo> definitely, slapd breaks for everybody on dapper->hardy upgrades, that is not acceptable :)
[23:13:30] <mvo> but the authorative answer can only come from a release-manager on this of course :)
[23:14:03] <mathiaz> well - I guess we'll have to figure which packages are impacted by the rename
[23:15:21] <mvo> there may be more ways to fix it too, but its good that we have a working solution
[23:16:22] <mvo> someone with good understand on sasl should probably have a additional look on it
[23:17:16] <mathiaz> Anyone wants to have a look into this sasl/ldap problem ?
[23:18:07] <sommer> mathiaz: I'm interested, but am far from a packaging guru :)
[23:18:47] * sommer can definitely help test
[23:19:00] <mathiaz> sommer: right - testing will be welcomed once we have a fix
[23:19:30] <mathiaz> bon - if someone wants to take a shot at it, you have the bug number ;)
[23:19:35] <mathiaz> let's move on
[23:19:44] <mathiaz> bug 81242
[23:19:49] <ubotu> Launchpad bug 81242 in postfix "postfix-ldap is linked against gnuTLS" [Medium,Triaged] https://launchpad.net/bugs/81242
[23:22:10] <mathiaz> So slangasek gave some pointers that needs more investigation
[23:23:07] <mathiaz> lamont: do you have any comments on this GnuTLS vs Postfix issue ?
[23:24:29] <mathiaz> let's move on to bug 155947
[23:24:30] <ubotu> Launchpad bug 155947 in libnss-ldap "ldap config causes Ubuntu to hang at a reboot" [Undecided,Confirmed] https://launchpad.net/bugs/155947
[23:24:50] <mathiaz> kirkland: did you fix it ?
[23:24:58] <kirkland> mathiaz: :-) nope
[23:25:00] <nxvl> sorry for being late, i have had work problems
[23:25:00] <nijaba> mathiaz: I think this bug has difficulty to be reproduced...
[23:25:05] <kirkland> mathiaz: but there are two points to be made about it
[23:25:38] <kirkland> mathiaz: the first, is that we now have significant evidence that the failure path of this bug involves a system which has been upgraded from Feisty -> Gutsy -> Hardy
[23:26:05] <kirkland> mathiaz: in that users are talking about a pam_ldap.conf config file that ceased to exist after Gutsy
[23:26:09] * kirkland points at dendrobates
[23:26:24] <kirkland> mathiaz: the second point is that at least one user confirmed a suspicion...
[23:26:43] <kirkland> mathiaz: "hang on boot" in the title may not in fact be an accurate description of this bug
[23:26:56] <kirkland> mathiaz: "hang on login" when no ldap server present is probably a more accurate description
[23:27:13] <kirkland> mathiaz: at least one commenter recently agreed with this analysis
[23:27:26] <slangasek> that sounds to me like a separate bug than the one originally being reported
[23:27:31] <kirkland> mathiaz: in which case I think me, zul, jdstrand, dendrobates, and others have reproduced that behavior
[23:27:31] <mathiaz> kirkland: right - hang on login makes sense to me
[23:27:45] <jdstrand> kirkland: I seem to remember a comment on this happening in dapper, and not fixed in etch either
[23:27:47] <kirkland> mathiaz: i'd say hang on login is "functions as designed" in my opinion
[23:27:53] <slangasek> "hang on boot" is explainable in terms of the network not being up yet and nss_ldap being !clever
[23:28:44] <kirkland> in any case, i have never hung a system on booting trying to reproduce this, and i've tried at least a dozen installations of feisty -> hardy
[23:28:50] <jdstrand> kirkland: I also seem to remember (maybe in a duplicate) that people described the problem in the same way as the missing nvram bug, which *was* a hang on boot
[23:28:53] <kirkland> jdstrand: i did not go back to dapper/edgy
[23:28:57] <mathiaz> kirkland: re pam_ldap.conf - does it mean that upgrades are not handled properly ?
[23:29:06] <kirkland> mathiaz: that is possible
[23:29:14] <jdstrand> (the nvram bug was fixed btw)
[23:29:32] <kirkland> mathiaz: users are saying that they're "fixing" this by adding a "soft bind policy" to the ldap.conf
[23:30:02] <kirkland> mathiaz: if any fix for this bug is required, i think that may be it, for it, in the upgrading case
[23:30:46] <nijaba> kirkland: how would you explain it only happening in cas of an upgrade?
[23:31:10] <kirkland> nijaba: configuration that's not properly ported out of pam_ldap.conf ?
[23:31:12] <mathiaz> nijaba: we changed libnss-ldap to use one configuration file
[23:31:38] * kirkland was not around for that change, yields to mathiaz & dendrobates
[23:31:39] <mathiaz> nijaba: in feisty, there used to be to files to configure ldap info - one for pam and one for libnss
[23:31:52] <jdstrand> kirkland: not ported properly would indeed happen, as there wasn't any porting IIRC
[23:32:14] <jdstrand> kirkland: let me check, but I think it was just a debconf note saying 'you have to do this manually'
[23:32:14] <nijaba> and is softbind the default now on a new install?
[23:32:18] <mathiaz> nijaba: dendrobates changed it in gutsy, so that pam and libnss use one configuration file (/etc/ldap.conf)
[23:33:15] <mathiaz> jdstrand: I think he put some logic to migrate the files
[23:33:31] <mathiaz> jdstrand: at least if the two configuration files were the same
[23:33:54] <mathiaz> jdstrand: the issue is when libnssldap and pam_ldap aren't using the same configuration
[23:33:55] <jdstrand> I worked on that a bit myself, I am digging into it now
[23:34:56] <jdstrand> mathiaz: no migration-- ldap-auth-config/move-to-debconf
[23:35:20] <mathiaz> jdstrand: ok
[23:35:30] <jdstrand> "You MUST either reconfigure your settings with debconf, or manually migrate your settings into ldap.conf and verify your configuration before logging out."
[23:35:46] <kirkland> jdstrand: please link to that somehow as a comment in the bug?
[23:35:57] <kirkland> mathiaz: how should we proceed on this bug at this point, for Hardy?
[23:36:04] * kirkland looks for guidance
[23:36:04] <mathiaz> that would explain why we see this problem only on an feisty -> gutsy upgrade
[23:36:17] <jdstrand> kirkland: it's in the ldap-auth-client source for debconf
[23:36:25] <jdstrand> configuration
[23:36:40] <mathiaz> well - the problem is that users don't read what debconf is telling them
[23:37:37] <jdstrand> that happens if either or both of /etc/libnss-ldap.conf and /etc/pam-ldap.conf exist on upgrade
[23:37:46] <dendrobates> initally we were going to disallow upgrade if the seperate files still existed, but it was decided that was a bad plan.
[23:39:19] <jdstrand> there is no sane way to migrate them as it is possible to actually use both on the same system (which was one of the driving forces behind dendrobates' merging to /etc/ldap.conf to begin, IIRC)
[23:39:44] <jdstrand> reason being it was too complicated and error prone
[23:40:07] <jdstrand> (but I'll let him speak to that if desired)
[23:40:45] <mathiaz> kirkland: I don't think we can really say we know what's going on in this bug
[23:40:57] <kirkland> mathiaz: okay, back at the grinding wheel again
[23:40:58] <mathiaz> kirkland: it's still not reproducable
[23:41:03] <kirkland> mathiaz: right
[23:41:29] <mathiaz> kirkland: the comments are also long
[23:41:30] <kirkland> mathiaz: should I focus more on dapper -> hardy upgrades, as that might be the more popular upgrade path in the future?
[23:41:39] <mathiaz> kirkland: oh yeah - definelty
[23:41:58] <mathiaz> kirkland: is there someone on the bug thread that is able to reproduce the problem now ?
[23:42:08] <kirkland> mathiaz: yeah, a lot of comments, though, are autoresponders from someone's annoying vacation responder :-S
[23:42:24] <mathiaz> kirkland: if not - we don't have any choice but to wait for someone that runs in the same problem
[23:42:36] <mathiaz> kirkland: and then we can start debugging it
[23:42:36] <kirkland> mathiaz: no one whose been willing to either (a) share their configs, or (b) meet me in IRC or on private email
[23:43:09] <mathiaz> kirkland: right - that happends often in long running bugs
[23:43:17] <kirkland> mathiaz: there is a single user who claims he's seen this on Hardy beta, when I asked for logs/configs, he couldn't get them to me/Launchpad
[23:43:27] <jdstrand> kirkland: how about an ssh root session into there system?
[23:43:28] <mathiaz> kirkland: some of the commenter are just adding a me too -while it's not the same problem
[23:43:30] <jdstrand> ;P
[23:43:34] <slangasek> kirkland: mark the bug as incomplete to force the issue?
[23:43:38] <jdstrand> s/there/their/
[23:43:52] <kirkland> slangasek: good plan, I'll go that route.
[23:44:15] <slangasek> (and be clear about what config files you need :)
[23:44:20] <kirkland> if this is a boot hang, i want /var/log/syslog, and some ldap/nss configs out of /etc
[23:44:33] <jdstrand> kirkland: someone mentioned etch being broken in the same way, might be worthwhile to look at Debian BTS
[23:44:42] <mathiaz> bug 189616
[23:44:43] <ubotu> Launchpad bug 189616 in dovecot "connection problems under load with hardy dovecot" [Undecided,New] https://launchpad.net/bugs/189616
[23:44:51] <kirkland> jdstrand: okay
[23:45:03] <mathiaz> I've started to look into that bug - but I've found nothing up to now
[23:45:13] <nijaba> another: "yet to be reproduced" bug...
[23:46:24] <nijaba> mathiaz: could we convince elmo to give it another shot with a network sniffer on?
[23:46:52] <mathiaz> nijaba: hum - I don't think that he'll be happy with the network sniffer part...
[23:47:11] <nijaba> mathiaz: we are talking about ssl traces...
[23:47:13] <jdstrand> I don't think he'd be happy with the 'another shot' part
[23:47:29] <nxvl> i can sniff some packages on a test suite
[23:47:33] <nxvl> using virtual machines
[23:47:56] <nijaba> jdstrand: this, I can imagine, but I'd like to know if he can reproduce on hardy, not on a backported to dapper dovecot
[23:48:33] <mathiaz> nijaba: I've tried to use a backported to dapper dovecot version and wasn't able to reproduce the bug
[23:48:59] <nijaba> mathiaz: with simulated ssl imap client and all?
[23:49:05] <jdstrand> nijaba: absolutely, if it's not hardy test then it's not valid. I was just being 'realistic'
[23:49:17] <mathiaz> nijaba: with a real imap ssl client (a python script)
[23:49:32] <mathiaz> nijaba: I've run 60 concurent clients login/logging out
[23:49:42] <nijaba> mathiaz: good.... so --> incomplete?
[23:50:09] <mathiaz> nijaba: yeah - I'll talk to elmo to figure out what the configuration is
[23:50:13] <jdstrand> if --> incomplete, document *everything*
[23:50:32] <mathiaz> nijaba: there may be some weird setup somewhere.
[23:50:33] <nijaba> mathiaz: yep, that is one part we have not been good at on this bug.
[23:50:37] <nxvl> btw
[23:50:47] <nxvl> do we support backported packages?
[23:50:57] <nxvl> i think it can be broken by the dapper configuration
[23:51:08] <mathiaz> nxvl: depends how you define "we" and "support"
[23:51:16] <nijaba> nxvl: no, but elmo, if you do not know, is our IS guy
[23:51:58] <nxvl> "we" as in server team and "support" as in fix bugs that includes and old still supported release and new packages
[23:52:16] <nxvl> nijaba: yep i knew he was our sysadmin
[23:52:17] <dendrobates> nxvl: we have to try and fix this,
[23:52:18] <mathiaz> nxvl: generally no
[23:52:41] <dendrobates> or rather try and find out if it exists.
[23:52:47] <nxvl> dendrobates: so we do care about them
[23:52:50] <mathiaz> nxvl: in this particular case, we'd better try to investigate the issue a little bit
[23:52:57] <dendrobates> we care about this one.
[23:53:01] <owh> Just an observation, but so far both his and other virtual testing seems not to show the issue. Could it be related to his hardware?
[23:53:03] <nxvl> oh ok
[23:53:19] <nxvl> i will try to make a test suite later today or tomorrow and try to reproduce it
[23:53:27] <nxvl> configuring a postfix on dapper
[23:53:34] <nxvl> and then backport it
[23:53:45] <dendrobates> nxvl: because this could be a problem in production environments and becuase we absolutely trust the source.
[23:53:46] <nijaba> nxvl: in fact, we would hate seing this bug occuring on hardy in a live user config
[23:53:51] <mathiaz> owh: well - dovecot on dapper works correctly
[23:54:07] <mathiaz> owh: switch backported dovecot and it fails
[23:54:54] <dendrobates> the best case, is tn reproduce it in dapper using the backport, and then have it not exist in hardy
[23:55:01] <owh> mathiaz: But on the other side of that is that his own load testing and that done by you does not show the problem. Unless of course we're not simulating enough load.
[23:55:28] <mathiaz> owh: yes.
[23:55:44] <jdstrand> mathiaz: do you have his backported packages, 'dpkg -l' and dovecot configuration?
[23:55:49] <nxvl> i have just asked for more information about the bug to try to reproduce it
[23:55:50] <mathiaz> owh: the issue was seen on a production system
[23:56:06] <mathiaz> jdstrand: not yet - I was going to ask about it.
[23:56:11] <owh> mathiaz: We're (ubuntu-server) not really setup for testing load are we?
[23:56:33] <jdstrand> mathiaz: I'd be curious about the installed packages too (hence the dpkg -l)
[23:56:33] <owh> mathiaz: Yeah, not really a nice place to find bugs at the best of times.
[23:56:51] <owh> So, gather more information basically jdstrand.
[23:57:03] <jdstrand> yes, the bug is 'terse'
[23:57:05] <owh> s/./?/
[23:57:12] <mathiaz> owh: agreed - I'l talk with elmo about the setup
[23:57:15] <owh> That's a good word :)
[23:57:30] <mathiaz> That's was all for the bugs milestoned for the release.
[23:57:49] <mathiaz> [TOPIC] RC/Final testing of server isos
[23:58:01] <nijaba> mathiaz: isn't bug #199144 milestoned?
[23:58:02] <ubotu> Launchpad bug 199144 in apache2 "Apache2 with mpm_worker times out with many concurrent requests" [Undecided,Incomplete] https://launchpad.net/bugs/199144
[23:58:14] <mathiaz> nijaba: hum... true
[23:58:30] <mathiaz> nijaba: zul wasn't able to reproduce the bug
[23:59:02] <zul> about that one I wasnt able to reproduce the bug I ran the command a hundread times through the loop and still wasnt able to reproduce it
[23:59:12] <slangasek> also, a reminder that https://bugs.launchpad.net/ubuntu/hardy/+bugs aren't milestoned, but they are targets of opportunity... if you exhaust the milestoned bugs, or if anyone wants something that might be easier to tackle, that's a place to look
[23:59:21] <zul> it doesnt help what yaddayadda is in the bug report
[00:00:01] <nijaba> zul: at least the reporter responds to our queries
[00:00:05] <zul> yep
[00:00:10] <mathiaz> zul: could it be a hardware problem ?
[00:00:26] <mathiaz> zul: like faulty memory ?
[00:00:35] <zul> mathiaz: it could be faulty network card not sure
[00:01:48] <zul> there was a bug about in apache's bug tracker but that was from 3 years ago
[00:02:43] <owh> Uh, what about a PHP issue, that is, PHP is hogging all the children?
[00:03:11] <owh> I know the report says it isn't related, but I've seen it happen often on crap PHP code.
[00:03:57] <mathiaz> zul: is the root of the website a php script ?
[00:03:58] <nijaba> owh: I guess that is what zul meant when he said "it doesnt help what yaddayadda is in the bug report"
[00:04:21] <zul> mathiaz: he doesnt say
[00:04:25] <mathiaz> zul: you may wanna ask more information about the setup
[00:04:29] <nijaba> mathiaz: would be a good question to ask
[00:04:31] <slangasek> if the content he's testing against is PHP, that could very well be the cause, yes :)
[00:04:33] <owh> nijaba: That's possible I suppose.
[00:04:34] <zul> yep...
[00:05:40] <zul> I will do so as soon as I finish what Im working on :)
[00:05:50] <mathiaz> zul: great
[00:05:57] <mathiaz> so to go back to the topic
[00:06:01] <mathiaz> [TOPIC] RC/Final testing of server isos
[00:06:34] <mathiaz> heno started to organize -server iso testing for RC and Final
[00:06:58] <owh> mathiaz: Sorry to intrude but do we need a time check?
[00:07:27] <mathiaz> @schedule
[00:07:29] <ubotu> Schedule for Etc/UTC: Current meeting: Server Team 10 Apr 20:00: Security Team | 11 Apr 12:00: MOTU | 16 Apr 21:00: Server Team | 23 Apr 21:00: Server Team | 30 Apr 21:00: Server Team
[00:08:00] <mathiaz> owh: well - there isn't any meeting now
[00:08:09] <owh> All good.
[00:08:17] <mathiaz> owh: but I think we're almost finished now
[00:08:38] <mathiaz> so tomorrow is the archive freeze until Final release
[00:08:56] <mathiaz> we'll have an RC of Hardy next week
[00:09:00] <mathiaz> and final in two weeks
[00:09:08] <zul> thats freaking scarey
[00:09:20] <sommer> mathiaz: are there going to be sparc iso's?
[00:09:32] <mathiaz> slangasek: ^^
[00:09:43] <nijaba> sommer: yes, but not officially maintained
[00:09:54] <slangasek> there will be sparc isos, on the same level with hppa/powerpc/ia64...
[00:10:02] <owh> zul: I was just thinking that :)
[00:10:04] <sommer> so should they be tested?
[00:10:17] <mathiaz> sommer: if you have the hardware, yes
[00:10:26] <sommer> cool
[00:10:39] <slangasek> sparc is being moved to "ports", it's not a Canonical-supported release anymore, including for server
[00:10:46] <slangasek> but that doesn't mean it shouldn't be tested
[00:11:02] <mathiaz> sommer: I don't know if the isotesting tracker will track sparc tests though
[00:11:26] <owh> mathiaz: So, are there any specific testing requirements for U-S for the .iso's ?
[00:11:57] <owh> I mean, booting and installing is fine, but that's hardly "testing" an .iso is it?
[00:12:03] <mathiaz> owh: owh https://wiki.ubuntu.com/Testing/Cases/ServerInstall
[00:12:15] <mathiaz> owh: we have a list of 9 test cases
[00:12:31] <mathiaz> owh: the testing procude is outlined on the wiki page.
[00:12:44] <owh> mathiaz: I'm reading it as you type :)
[00:13:07] <mathiaz> owh: if you're interested in helping out, you should check out http://iso.qa.ubuntu.com/
[00:13:14] <mathiaz> owh: it's the iso testing tracker
[00:13:38] <mathiaz> owh: when the release team has new isos to test, they will be published there
[00:13:39] <nijaba> owh: feel free to register yourself for some tests ;)
[00:13:44] <owh> mathiaz: As I'm reading this, it's hardly beyond "tick" a box installation is it.
[00:14:03] <nijaba> owh: right
[00:14:03] <mathiaz> owh: a little bit more
[00:14:04] <owh> Are there any actual testing suites?
[00:14:14] <mathiaz> owh: there are some tests to be done depending on the installation profile
[00:14:35] <mathiaz> owh: for ex, make sure that postgres is running on reboot, etc...
[00:14:39] <owh> mathiaz: Yeah, check if you can create a database, but basically, trust the installer. That's pretty trivial IMO.
[00:14:43] <slangasek> owh: there are test cases to follow to ensure that the packages are installed correctly by default; the ISO testing isn't intended to be a replacement for the much longer period of beta testing that's been ongoing
[00:14:44] <nxvl> i will give a try to iso's when i work on the postfix bug
[00:14:46] <mathiaz> owh: everything is outlined in the test description
[00:14:47] <nxvl> using a VM
[00:15:08] <owh> slangasek: Cool. I just thought I'd ask.
[00:15:20] <mathiaz> owh: trivial is better than nothing ;)
[00:15:28] <owh> mathiaz: There is that.
[00:15:43] * owh has to head off to breakfast.
[00:16:14] <sommer> whoa... thought he said beerfest for a second :-)
[00:16:49] <mathiaz> all right - that's all I wanted to mention for the meeting
[00:16:58] <mathiaz> [TOPIC] Any Other Business
[00:17:17] <mathiaz> slangasek: do you want to add something related to the incoming release ?
[00:17:41] <slangasek> I have one particular bug I'd like to request attention on :)
[00:17:59] <slangasek> bug #208419
[00:18:01] <ubotu> Launchpad bug 208419 in auth-client-config "Integrate samba password in PAM" [Undecided,In progress] https://launchpad.net/bugs/208419
[00:18:20] <jdstrand> the patch is forth-coming, I promise! :)
[00:18:29] <slangasek> this is a pretty late "feature", but it's pretty trivial to enable
[00:18:37] * jdstrand wishes auth-client-config didn't start with 'a' now
[00:18:42] <slangasek> so I'd like the server team to comment on pulling libpam-smbpass into the samba-server seed by default
[00:20:07] <mathiaz> considering that the samba-server task is targeted at new comers, I think it'd make sense
[00:20:10] * nijaba dreams of rediecting both to slapd once and for all...
[00:20:54] * slangasek twitch
[00:21:02] <mathiaz> I think that most of the samba deployments in the server world don't require libpam-smbpass
[00:21:24] <slangasek> mathiaz: I think they don't /use/ it, but do you think that's what people /want/?
[00:21:37] <slangasek> do admins not want password sync by default between Unix and Samba
[00:21:38] <slangasek> ?
[00:21:57] <sommer> I wouldn't, by default
[00:22:06] <mathiaz> slangasek: hum... depends on the use case
[00:22:14] <mathiaz> slangasek: and the environment
[00:22:21] * mathiaz ponders
[00:23:31] <mathiaz> IMO adding to the samba-server seed makes sense to me
[00:23:39] <mathiaz> considering the target audience
[00:24:02] <nijaba> dendrobates: any impact for likewise?
[00:26:21] <mathiaz> slangasek: so for me, it's a +1 for the samba-server seed modification
[00:28:00] <dendrobates> nijaba: no
[00:28:19] <nijaba> good, thanks
[00:28:30] <dendrobates> nijaba: wait, let me read the bug first.
[00:29:43] <dendrobates> nijaba: no, it does not apply.
[00:29:55] <dendrobates> slangasek: +1
[00:30:02] <slangasek> k, cheers :)
[00:31:07] <mathiaz> slangasek: I can take a look at modify the seeds
[00:31:39] <slangasek> cool, thanks
[00:32:10] <owh> Just an aside, how is the survey coming along?
[00:32:57] <nijaba> owh: their were a few security issues uncovered by kees in limesurvey. we are waiting for upstream to fix those before it can be hosted on u.c
[00:33:29] <owh> Is there any way to speed that up - I mean, waiting for someone else to do something might take years :)
[00:33:50] <nijaba> owh: I am in touch with their lead dev almost daily
[00:34:08] <nijaba> owh: I he gave me good assurance it is going to be fixed soon
[00:34:24] <owh> nijaba: Is there a time line?
[00:34:33] <nijaba> owh: ASAP
[00:34:38] <owh> :)
[00:34:52] <owh> So, if that is sorted out, are we ready to roll?
[00:35:06] <nijaba> owh: I believe so, yes
[00:35:24] <owh> Do we need to do another #U-S - wide testing run?
[00:35:36] <owh> s/another/a/
[00:36:06] <nijaba> owh: not sure but if you feel like it, I can set one up easy enough
[00:36:20] <owh> What do others think about this?
[00:36:45] <owh> Just to be clear, I'm talking about a test-run sent to the ubuntu-server list.
[00:37:00] * sommer thought the last one looked good
[00:37:00] <mathiaz> owh: a test-run ? Has anything changed ?
[00:37:29] <owh> mathiaz: At the moment, there have only been a select few who have run it.
[00:37:34] <nijaba> mathiaz: we fixed about ten "bugs" since last test
[00:37:48] <owh> I'm just wondering if it needed a wider audience before release.
[00:38:07] <nijaba> owh: I think it should be fine
[00:38:13] * mathiaz agrees
[00:38:22] <owh> All good then :)
[00:38:40] <nijaba> owh: we did 4 iteration, with an average of 5 testers
[00:38:47] <mathiaz> [TOPIC] #
[00:38:47] <mathiaz> Agree on next meeting date and time.
[00:38:50] <owh> Hmm, is there anything else I should be doing about the init.d scripts?
[00:38:55] <mathiaz> [TOPIC] Agree on next meeting date and time.
[00:39:09] <mathiaz> owh: nope - it's all good for now :)
[00:39:16] <mathiaz> Next week, same time, same place ?
[00:39:24] <owh> WFM
[00:39:33] <sommer> o./
[00:39:35] <nijaba> +0.9
[00:39:44] * owh jumps for joy :)
[00:39:56] * owh could do with more sleep as well...
[00:40:15] <owh> Just out of interest, what TZ's are people in? For me it's UTC+8
[00:40:20] <mathiaz> Great - so see ya all next week, here at the same time
[00:40:26] <nijaba> UTC+2 here
[00:40:30] <owh> So this meeting starts at 5am.
[00:40:36] <mathiaz> happy testing
[00:40:42] <mathiaz> thanks for attending :)
[00:40:46] <sommer> thanks mathiaz
[00:40:47] <nijaba> thanks mathiaz
[00:40:52] <sommer> owh: UTC -4
[00:41:02] <owh> thanks mathiaz for your tireless typing :)
[00:41:07] <jdstrand> thanks mathiaz!
[00:41:18] <owh> So, nijaba is really screwwed :|
[00:41:20] <nxvl> UTC - here
[00:41:20] <mathiaz> owh: our TZ range from UTC+8 to UTC-9
[00:41:24] <nxvl> 5*
[00:41:49] <mathiaz> owh: hum - UTC-7 to be correct
[00:41:50] <sommer> er, I think I'm 5 as well :)
[00:41:55] <mathiaz> #endmeeting

MeetingLogs/Server/20080409 (last edited 2008-08-06 16:21:46 by localhost)