20080624

Revision 1 as of 2008-06-24 16:22:40

Clear message

Agenda

Items we will be discussing:

  • Review ACTION points from previous meeting.
  • Relocation of web pages from /var/www/ to /srv/www/ in future releases LukeHasNoName

  • Intrepid spec status (still - when will stuff get approved?) - ScottKitterman

  • Iso testing - 8.04.1 and 8.10-alpha1 - MathiasGug

  • Open Discussion.
  • Agree on next meeting date and time.

Minutes

Agree on next meeting date and time

Next meeting will be on Tuesday, June 24th at 15:00 UTC in #ubuntu-meeting.

Log

{{{[16:03] <lukehasnoname> heh [16:03] <mathiaz> meh - no Mootbot [16:03] <ivoks> damn robots [16:03] <kraut> lukehasnoname: thanks [16:03] <mathiaz> so today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting [16:04] <mathiaz> last week meeting minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20080617 [16:04] <mathiaz> [TOPIC] Ebox and augeas [16:05] <mathiaz> so we had some discussion about augeas and ebox [16:05] <mathiaz> I sent an email to the ebox developers about this issue [16:05] <mathiaz> https://lists.warp.es/pipermail/ebox-devel/2008-June/000376.html [16:06] <mathiaz> there has been some discussion about this and the ebox developers seem open to the idea [16:06] <mathiaz> they've started to look into using augeas and experiment with it [16:06] <mathiaz> on a related note, nxvl has packaged augeas for ubuntu [16:07] * nealmcb cheers [16:07] <mathiaz> http://nvalcarcel.aureal.com.pe/?p=196 [16:07] <mathiaz> he uploaded it to REVU and is waiting for feedback - http://revu.ubuntuwire.com/details.py?package=augeas [16:08] <mathiaz> so I think that all I have to report from the ebox front [16:09] * lukehasnoname claps [16:10] <mathiaz> [TOPIC] text browser on the server cd [16:10] <mathiaz> so I sent a reply to the thread with the official decision from the server meeting [16:10] <mathiaz> and the discussion is still going on - also it turned into a broader subject [16:11] <mathiaz> but I don't think there anything more to say in this meeting about it. [16:11] <lukehasnoname> well [16:11] <mathiaz> anyone wants to add something wrt to last week meeting ? [16:11] <nealmcb> well it seemed to me to relate well to scottk's blueprint [16:12] <lukehasnoname> nealmcb: pretty close, ya [16:12] <lukehasnoname> One idea is making custom ISOs from a javascript web-app [16:12] <mathiaz> nealmcb: right - so I'd suggest to update the blueprint with ideas that emerged during the thread [16:12] * nijaba not sure FAI is the right approach though, if we are talking about the same blueprint [16:13] <mathiaz> and continue the discussion on the blueprint [16:13] <mathiaz> nijaba: we're talking about this blueprint [16:13] <nealmcb> do we have consensus that it should be easy for folks to either install some sort of bare-bones server, or a comfortable more friendly server [16:13] <lukehasnoname> https://lists.ubuntu.com/archives/ubuntu-server/2008-June/001812.html [16:13] <lukehasnoname> nealmcb: Looks like it from the ML [16:13] <mathiaz> nealmcb: from what I read from the thread, it seems so [16:14] <ivoks> bare-bone server is waporware... [16:14] <mathiaz> nealmcb: that may be included in the blueprint rationale [16:14] <mathiaz> nealmcb: to explain the reason for doing so [16:14] <nealmcb> ivoks: ? [16:14] <kirkland> mathiaz: i think it's essential that Ubuntu provide a mechanism for a bare minimal CLI-only system [16:15] <kirkland> mathiaz: I say Ubuntu in that it may or may not be the Server Team, but I think it would suit well for our team to provide that sort of install [16:15] <ivoks> nealmcb: there will always be people considering it not so bare as it should be; just ignore me [16:15] <mathiaz> kirkland: agreed - I like to the approach of installing a bare-system and then having a way to turn it into a specific type of machine [16:16] <nealmcb> I think the question is how bare bare is... there are lots of utilities in unix that are helpful but not essential [16:16] <kirkland> mathiaz: right... and if that's JEOS->real hardware, or Alternate CD, or mini.iso+CLI ... whatever [16:16] <ivoks> there can't be bare bone server; there can be bare bone linux system [16:16] <nealmcb> just give 'em busybox Smile :) [16:16] <mathiaz> kirkland: right - but at least we start to have some general idea about where we'd like to head for [16:16] <ivoks> so, as i agree with kirkland; this should be ubuntu project, not ubuntu server project [16:16] <kirkland> nealmcb: if it can run apt-get and connect to the network, it's minimal enough for me [16:17] <mathiaz> ok - let's move on [16:17] <nealmcb> ivoks: in the sense that you can give them a platform for putting their own services on it, with a good kernel etc, you can give them a jeos with hardware support and let them build from there [16:17] <soren> kirkland: apt-get? Sheesh! What's wrong with telnet+ar+tar+gzip? [16:17] <lukehasnoname> soren: ha [16:17] <mathiaz> [TOPIC] Relocation of web pages from /var/www/ to /srv/www/ in future releases [16:17] <lukehasnoname> Ah, yes [16:17] <mathiaz> lukehasnoname: why ? [16:18] <soren> *blink* [16:18] <kirkland> ??? [16:18] <soren> Why, oh why? [16:18] <lukehasnoname> >_> [16:18] <lukehasnoname> ok [16:18] <zul> mathiaz: no no no no no [16:18] <ivoks> let's all agree - no [16:18] <kraut> may i say something to that? [16:18] <nealmcb> soren: Smile :) [16:18] <sommer> seems like that would cause issues [16:18] <lukehasnoname> Simply consider it, though I know chances are slim. But it would conform much better to logic and the FHS if we did [16:18] * kraut would prefer that idea and lean the directory hierachie completly to FHS [16:18] <kraut> (FHS: http://www.pathname.com/fhs/pub/fhs-2.3.pdf) [16:18] <lukehasnoname> same with mysql and ftp [16:19] <lukehasnoname> I've spoken with some people who agree on principle [16:19] <kraut> AOL [16:19] <lukehasnoname> it's up to you guys to put it into practice... let me very quickly grab a quote [16:19] * nealmcb always puts server stuff in /srv - what would the impacts be? [16:19] <kraut> many people would cry after the change, but after everybody knows the "issue", it would be much better [16:19] <lukehasnoname> /srv contains site-specific data which is served by this system. [16:19] <kraut> and FHS is just the best standard i think [16:19] <lukehasnoname> /var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files. [16:20] <lukehasnoname> those are from the FHS [16:20] <ivoks> ahm... [16:20] <nealmcb> and what do other distros do? [16:20] <lukehasnoname> If you read the page kraut linked to, just the two paragraphs on those two dirs, you'll see the logic I'm looking at. [16:20] <sommer> nealmcb: /var/www/* [16:20] <kraut> nealmcb: redhat and suse does the same [16:20] <nijaba> Suse - /srv [16:20] <ivoks> 'Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv.' [16:20] <kirkland> nealmcb: RH is /var/www/html [16:21] <zul> gentoo is /srv if I remember correctly but they dont count Wink ;) [16:21] <kraut> ah, sorry, redhat uses /var/www/html [16:21] <kraut> blame on me, i've just watched it out Smile :) [16:21] <lukehasnoname> ivoks: That is talking cross -platform, but from an Ubuntu perspective, it would be much more logical to have static web files in its own directory, in a different area from logs [16:21] <lukehasnoname> zul: aw [16:21] <kraut> i'm a friend of standards and best practices and FHS is at the moment the best choice. [16:21] * soren points at ivoks [16:22] <kraut> i'm out. need to work. just highlight me. [16:22] <lukehasnoname> kraut: thanks. [16:22] <soren> kraut: Certainly. And the FHS itself says why it's a bad idea, as ivoks pointed out. [16:22] <emgent> hello. [16:22] <emgent> @schedule rome [16:22] <ubottu> emgent: Schedule for Europe/Rome: Current meeting: Server Team | 24 Jun 20:00: LoCo Council | 25 Jun 19:00: QA Team | 26 Jun 00:00: Platform Team | 26 Jun 12:00: MOTU School Session - Apport retraces [16:23] <lukehasnoname> brb [16:23] <lukehasnoname> think about it [16:23] <zul> I dont agree with this at all besides this should really be done in debian [16:24] * sommer agrees with zul [16:24] <ivoks> there are some benefits of change, but are they so big to really do it? [16:24] <lukehasnoname> zul: I can see your debian argument [16:24] * ivoks agrees with zul and soren [16:24] * sommer also agrees with ivoks [16:24] <nealmcb> has debian discussed it? [16:24] <kraut> FHS: http://www.pathname.com/fhs/pub/fhs-2.3.pdf - Point: 3.16.1. Purpose [16:24] <mathiaz> /srv seems to be targeted at site customization, ie the local sysadmin is reponsible for figuring out the layout - as the package maintainers, we can default to /var/ww [16:24] <soren> Even if this was a good idea (which I don't think it is), it would have to be an *extremely* good idea to justify the horror of maintaining a delta for each and every debian package that ships stuff in /var/Www [16:25] <ivoks> i mean... there's a lot of packages, we would have huge delta just cause of location change [16:25] <mathiaz> there are a lot of packages that relay on /var/www and also common knowledge [16:25] <kraut> soren: so pointing to that, it would be a good idea to use /srv/<protocol>, for example /srv/www [16:25] <lukehasnoname> So the consensus is: If it were ever to happen, run it through deb? [16:25] <soren> kraut: "that"? [16:25] <mathiaz> it's not fundamitally wrong to use /var/www [16:25] <kraut> soren: why to use /srv/www instead of /var/www [16:26] <lukehasnoname> I'm also the guy who thinks that /usr is redundant [16:26] <zul> its just a nightmare to maintain from a developers point of view [16:26] <ivoks> lukehasnoname: if debian changes it, i would accept it; i'm not strongly oposed, but i am oposed to big delta for no gain [16:26] <kraut> mathiaz: of course not, but /srv/www is more a "best practice" [16:26] <soren> kraut: "unspecified and there is currently no consensus on how this should be done" [16:26] <lukehasnoname> however, I will run it through Debian if I write up a formal proposal that I think has strong case points. [16:26] <kraut> soren: that's business as usual [16:26] <soren> And if we start shipping stuff in there, we might *very* well overwrite user's stuff that they already put in there. [16:27] <ivoks> kraut: there a tons of tutorials with 'place the website into /var/www' [16:27] <kraut> soren: it's more a guide for "best practisces", and /srv/<protocol> sounds reasonable [16:27] <mathiaz> lukehasnoname: that seems like the best course of action [16:27] <kraut> ivoks: only while years ago somebody choiced that, we need to choice it also in our future, also if there is a better soloution? [16:27] <mathiaz> lukehasnoname: we won't change the default location if debian is against it because of the huge delta it would introduce [16:27] <lukehasnoname> Alright... I know it's a change, and change is harsh, but bad habits are formed out of archaic standards that never get moved around. [16:27] <Brazen> There can also be a transition period with /var/www symlinked to /srv/www (sorry I'm late, don't know if this has been mentioned) [16:27] <lukehasnoname> mathiaz: That is the only point I completely agree with here,. [16:28] <lukehasnoname> Debian has to be aboard [16:28] <soren> kraut: I don't think so, actually. I order stuff in /srv by domain. [16:28] <ivoks> kraut: as you can see, we aren't very sure it's better; FHS is very... hm... blur about /srv [16:28] <ScottK-palm> Sorry for being late. Did we talk about specs already. [16:28] <zul> ScottK-palm: no [16:28] <lukehasnoname> no ScottK-palm [16:28] <mathiaz> we have to balance these issues (delta, history and common knowledge) with the best practices (which aren't so clear according to the FHS) [16:28] <ivoks> i use /srv for smb shares Big Grin :) === ArneGoet1e is now known as ArneGoetje [16:28] <ScottK-palm> Thanks. [16:28] <kraut> ivoks: that's correct, but if i understood correctly, /srv/<protocol> or /srv/<department>/</protocol> would be the best choice [16:29] <zul> ivoks: you are weird Wink ;) [16:29] <kraut> ivoks: i use /home/kraut/mobiledisk for samba, so should that be a worldwide standard? Wink ;) [16:29] <lukehasnoname> Hell with you guys, I'm going to gobolinux. :p That's that then. I'll discuss the possibility with Debian if I feel I have a case, otherwise I'll just manually do it for me. [16:29] <kraut> (just kidding) [16:29] <nealmcb> kraut: common, yes. "best"? ymmv... [16:29] <ivoks> kraut: 'such as' - FHS doesn't have a strong opinion on /srv [16:29] <ivoks> zul: we all are Big Grin :) [16:29] <ScottK-palm> On /var/www we should definitely follow Debianm [16:29] <kirkland> i definitely do not see how this change would improve the Ubuntu experience for anyone--sysadmins or users [16:30] <mathiaz> allright - let's move on [16:30] <lukehasnoname> yes [16:30] <Brazen> definately follow Debian, but strongly encourage Debian to move to /srv [16:30] <ivoks> leave it to debian [16:30] <nealmcb> ScottK-palm: or perhaps lead them, but be in sync.... [16:30] <mathiaz> I think we've got some opinions on why not to do it [16:30] <kraut> Brazen: *5* [16:30] <mathiaz> and why to do it [16:30] <mathiaz> next topic [16:30] <lukehasnoname> Welcome Brazen. I got slaughtered, heh. [16:31] <mathiaz> [TOPIC] Intrepid spec status [16:31] <Brazen> sorry lhnn, I meant to be here [16:31] <ScottK-palm> I'm not saying don't try to convince them, but don't diverge over it. [16:31] <mathiaz> dendrobates is the last steps of getting things approved [16:31] <mathiaz> ScottK-palm: which specs are looking for ? [16:32] * ScottK-palm got one comment from dendrobates. thanks. how does it look on getting approved? [16:32] <mathiaz> ScottK-palm: I think that the two specs about email are quit straightforward and could be implemented [16:32] <ScottK-palm> It's the flavors spec I'm most interested in. [16:33] <mathiaz> ScottK-palm: right - there has been some discussion about it [16:33] <mathiaz> ScottK-palm: during this meeting and on the w3m thread [16:33] <dendrobates> ScottK-palm: I have been delayed while canoncial worked some things out. I will be starting the approval process this afternoon. [16:33] <mathiaz> ScottK-palm: so it seems that there is more work to be done on the spec [16:33] <ScottK-palm> Great. [16:33] <nealmcb> ScottK-palm: fyi, (09:06:48 AM) mathiaz: on a related note, nxvl has packaged augeas for ubuntu [16:34] <ScottK-palm> I saw. [16:34] <nijaba> ScottK-palm: how would you consider replacing FAI by augeas in your spec (or supplementing it?) [16:34] <ScottK-palm> Comments on the flavors spec please. I'll fix it up. [16:35] <ScottK-palm> nijaba: one step at a time. [16:35] <ScottK-palm> I think with FAI will be hard enough. [16:36] <mathiaz> I haven't seen any new specs subscribed [16:36] <ivoks> ssl thing? [16:36] <mathiaz> so make sure that the specs are in a pending aproval state [16:36] <ivoks> maybe i didn't do subscribing right :/ [16:36] <mathiaz> so that dendrobates can go through the list [16:36] <ScottK-palm> Plus one on thay one. [16:36] <mathiaz> ivoks: I saw it [16:36] <ivoks> ok, thanks, [16:37] <ScottK-palm> SSL v2 needs to die. [16:37] <mathiaz> anything else on the spec front ? [16:37] <ivoks> ScottK-palm: we'll kill it [16:37] <ScottK-palm> Not from me. [16:38] <ScottK-palm> Anyone? [16:38] <mathiaz> let's move on then [16:38] <mathiaz> [TOPIC] Iso testing - 8.04.1 and 8.10-alpha1 [16:38] <mathiaz> we're gearing for 8.04.1 and 8.10-alpha1 [16:39] <mathiaz> new isos have been created and testing the ubuntu-server isos is welcomed [16:39] <mathiaz> slangasek: are there 8.10-alpha1 ubuntu-server isos ready for testing ? [16:40] <mathiaz> the iso testing tracker (http://iso.qa.ubuntu.com/) has 8.04.1 isos [16:40] <mathiaz> slangasek: but I don't see any -server isos for intrepid alpha1 [16:41] <ScottK-palm> Wasn't that delayed? [16:41] <mathiaz> ScottK-palm: we've started the alpha1 isos now [16:41] <mathiaz> ScottK-palm: the new kernel has been uploaded [16:41] <ScottK-palm> OK. [16:42] <mathiaz> ScottK-palm: so alpha1 isos are being prepared [16:42] <mathiaz> anyway - -server isos for 8.04.1 are already ready [16:42] <dendrobates> it will be interesting to see if installing Recommends by default causes us a problem. [16:42] <dendrobates> It has already been problematic on my dev vm's [16:42] <mathiaz> so iso testing is much appreciated [16:43] <nijaba> dendrobates: that's not in 8.04.1 though... [16:43] <ScottK-palm> We need some clear policy if Universe recommends need MIR. [16:43] <lukehasnoname> dendrobates: I assume packages have been getting worked on to have reasonable recommends? [16:43] <zul> nijaba: no it isnt [16:43] <mathiaz> we're targeting a release of 8.04.1 next week [16:43] <dendrobates> nijaba: the topic includes 8.10 alpha. [16:44] <nijaba> dendrobates: my mistake, did not notice [16:44] <ScottK-palm> Fortunately Debian has had reccomends by default for some time so they've done a lot of work. [16:44] <mathiaz> ScottK-palm: right - well it depends on the package [16:44] <dendrobates> bzr will install X Smile :) [16:45] <zul> dendrobates: ergh [16:45] <mathiaz> ScottK-palm: I guess dropping to suggest if needed [16:45] <ivoks> devscripts installs... well... a lot Big Grin :) [16:45] <lukehasnoname> I had trouble with this recently, since the C# compiler is "recommends" for mono-develop and it didn't get installed [16:45] <mathiaz> ScottK-palm: other wise, MIR will have to be filled for each recommends [16:45] <soren> dendrobates: What? [16:45] <mathiaz> ScottK-palm: since main has to be installable on its own [16:46] <mathiaz> ScottK-palm: why would you think MIR should be avoided for Recommends ? [16:46] <ScottK-palm> Yes, but install won't fail on missing recommends. [16:46] <dendrobates> if it is too large of a problem, we can push the change back in server to intrepid+1, but only if we have too many problems to handle. [16:47] <ScottK-palm> Not saying either way. It's a lot of MIR though. [16:47] <mathiaz> ScottK-palm: hm - good question then. You may wanna ask about it on ubuntu-devel [16:48] <lukehasnoname> MIR? [16:48] <lukehasnoname> sudo acronym-define MIR [16:48] <ScottK-palm> Maybe someone could make a list for the server packages. [16:48] <ScottK-palm> Main Inclusion Report [16:49] <kirkland> lukehasnoname: https://wiki.ubuntu.com/MainInclusionProcess [16:49] <lukehasnoname> thanks ScottK-palm kirkland [16:49] <mathiaz> ScottK-palm: good point. that would give us some real data on the amount of work needed [16:50] <ScottK-palm> mathiaz: MIR is more of a Canonical question than Ubuntu. [16:50] <ivoks> ScottK-palm: how come? [16:50] <ScottK-palm> Because it affects their support contracts. [16:51] <nealmcb> well, it affects the support contracts of anyone who supports main [16:51] <ivoks> right [16:52] <nijaba> ScottK-palm: it affects mainly Ubuntu maintenance commitment [16:52] <nijaba> the support contract is a separate thing [16:52] <ivoks> the moment we don't include something in main cause it affects somebody's contract, i'll leave Smile :) [16:52] <ScottK-palm> Smile :) [16:52] <nijaba> if canonical decides to support a subset of main, nothing forbids us to do so [16:53] <ScottK-palm> True. [16:53] <nijaba> and that is not really something that we should consider here [16:53] <nealmcb> nijaba: right [16:53] <ivoks> let's eliminate fear of canonical and move on Smile :) [16:53] <nijaba> however, maintenance of packages has some impact [16:54] <mathiaz> maintenance has an impact on the Ubuntu Security team [16:54] <nijaba> and the security team is not the last one impacted [16:54] <ScottK-palm> Someone please get a policy and let us peons know. [16:55] <nealmcb> moving right along.... [16:55] <mathiaz> let's move on [16:55] <mathiaz> [TOPIC] Open discussion [16:55] <ScottK-palm> Yep.... [16:55] <mathiaz> anyone wants to add something ? [16:56] <ivoks> postfix-dovecot is on it's way [16:56] <zul> mathiaz: thanks for getting openldap uploaded btw [16:56] <soren> ivoks: Cool. [16:56] <mathiaz> ivoks: \o/ [16:56] <mathiaz> zul: np [16:56] <soren> ivoks: I'm looking forward to seeing the implementation. [16:56] <sommer> yay for openldap Smile :) [16:57] <ivoks> soren: https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/164837 [16:57] <ubottu> Launchpad bug 164837 in tasksel "Dovecot SASL for postfix" [Undecided,Invalid] [16:57] <ScottK-palm> Do we have people who watch upstream support forums for dovecot,openldap, etc.? [16:57] <ivoks> funny... invalid means something completly different in croatian Big Grin :) [16:58] <mathiaz> [TOPIC] Agree on next meeting date and time [16:58] <kirkland> ivoks: there's an alternate meaning in English too [16:58] <mathiaz> same time, same place, next week ? [16:58] <sommer> mathiaz: sure [16:58] <ivoks> + [16:58] <ScottK-palm> Ubuntu specific stuff comes up on postfix-users mail list frequently. [16:58] * kirkland is on vacation next week Wink ;-) [16:59] <nijaba> +1 [16:59] <ivoks> ScottK-palm: like? [16:59] <ScottK-palm> I think someone should be watching other upstream venus too. [16:59] <zul> kirkland: nyeah nyeah nyah :P [16:59] <mathiaz> allright - so same place, same time [16:59] <ivoks> ScottK-palm: i'm on bacula's dev list [16:59] <mathiaz> see ya next week and happy iso-testing }}}