[12:46] <NeoIce> I'm managing a multi-user environment and would like to restrict certain users to certain commands, whats the best way to accomplish that?
[12:46] <NeoIce> rbash isnt restrictive enough
[12:48] <tck> more restrictive than rbash?
[12:49] <NeoIce> mmhmm
[12:49] <NeoIce> rbash allows the chsh command still which basiclly nullifies using rbash
[12:50] <NeoIce> which seriously, whats the point of rbash if it only blocks SOME of the commands that allow shell changing?
[12:50] <tck> just turn off the x bit for app
[12:51] <tck> chmod o-x /usr/bin/chsh ?
[12:51] <NeoIce> but is there a way to specify which commands which user can use?
[12:51] <tck> not quite sure
[12:52] <tck> im sure you can input something into a startup script when the shell is executed
[12:53] <NeoIce> I read something but I cant find it again and it looked like you created a folder full of the commands you wanted to allow and you pointed something at it
[12:53] <tck> http://kitenet.net/~joey/code/pdmenu/
[12:54] <tck> it would be similar to the say, netopia menu based scenario i would imagine
[12:55] <tck> oh fancy that, its in apt
[12:55] <Pumpernickel> Would rbash with a carefully vetted $PATH work well enough for you?
[12:56] <NeoIce> can you explain that a little more?
[12:57] <Pumpernickel> Rbash seems to restrict users to running executables in their $PATH - no ./foo type commands, no commands starting with a /, no `cd`, etc.
[12:58] <Pumpernickel> So if you were to setup their $PATH to only include 'allowed' executables, that should be an absolute limit.
[01:02] <NeoIce> ah, found the environmental variable for the user that looks like this:
[01:02] <NeoIce> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[01:04] <dendrobates> NeoIce: you could chroot the user and only put the commands you want them  to access in the chroot.
[01:15] <NeoIce> yeah, rbash really doesnt block anything
[03:03] <nealmcb> infinity, et al.: is there a web page somewhere (or ubotu response) with insights on why ubuntu doesn't have webmin any more?  We see it come up so often, that having a good page to point people to would help.  Info on when we dropped it, what other GUI tools are available that deal with config files in a respectful way, etc (like ebox?), etc would be nice also.
[03:25] <mathiaz> nealmcb: not that I know of.
[03:26] <mathiaz> nealmcb: may by we could discuss that during tomorrow meeting.
[03:35] <nealmcb> mathiaz: that would be good.  as a new ubutu additions topic?  roadmap item?
[03:36] <mathiaz> nealmcb: addition topic seems good to me.
[03:37] <mathiaz> nealmcb: it may turn into a roadmap item at the end of the meeting.
[05:12] <newbie3> anybody using ncsa_auth on squid?
[05:12] <newbie3> my authentication can't run
[05:29] <nealmcb> newbie3: Can you be more specific?  What version, what browser, what configuration, what does it do instead?
[05:52] <newbie3> who's version?
[05:53] <newbie3> my ubuntu 7.04
[05:53] <newbie3> squid 2.6
[05:53] <newbie3> ncsa_auth can't run
[05:53] <newbie3> it's always wrong everytime i enter username and password
[05:55] <newbie3> actually the squid is running but not until i try to run the authentication program
[05:56] <newbie3> what could be wrong?
[07:20] <dezmaeth> hi, im having problems with chmodded directories
[07:20] <dezmaeth> i cant seem to enable uploads from users , i allready chmoded every needed directory as 777
[07:20] <dezmaeth> but still doesnt work
[08:06] <newbie3> my squid keep telling cache access denied?
[08:17] <bain> mornign 
[09:38] <newbie3> :)
[09:38] <newbie3> no responses
[09:56] <kraut> moin
[01:57] <pmjdebruijn> will Gutsy support dm-multipath in the installer?
[01:59] <Nafallo> hm
[01:59] <pmjdebruijn> for example CentOS 5 automatically creates /dev/mapper/mpath{0-...} devices when it's started with 'linux mpath'
[01:59] <Nafallo> I do need to throw this suggestion out here:
[01:59] <pmjdebruijn> quite critical for our datacentre
[02:00] <Nafallo> what do you people think of a task that will install openssh-server + deps as its own preselected tasks in the installer?
[02:00] <Nafallo> serverinstaller that is
[02:00] <Nafallo> most people will want to install it, and those that does not can easily untick it.
[02:00] <Nafallo> should help new users
[02:07] <dendrobates> Nafallo: We could not have it running by default.  We advertise no open ports in a default install.
[02:07] <lcdd> Nafallo: anything to help the admin get out of the server room sooner, i guess
[02:08] <dendrobates> Nafallo: I could see an argument for having it installed though.
[02:08] <Nafallo> dendrobates: yes I know. that's why I wondered about the option above. to make it easier to get the most usual thing up and running fast :-)
[02:08] <Nafallo> dendrobates: I don't want to force it on people, but a good default choice that you can untick :-)
[02:08] <Nafallo> lcdd: agreed
[02:09] <Nafallo> lcdd: or the datacenter ;-)
[02:09] <Nafallo> it's easier to hit enter then login, sudo apt-get install openssh-server, wait a bit, logout
[02:09] <Nafallo> :-)
[02:10] <dendrobates> why have a checkbox at all.  I think you can make the assumption that all servers need ssh-server.
[02:11] <dendrobates> You just can't start it by default without intervention at install.
[02:11] <infinity> I think that assumption would be incorrect.
[02:11] <Nafallo> dendrobates: cause we have a no open ports policy :-)
[02:12] <dendrobates> core server need ssh-server than moin and we ship moin on the image.
[02:12] <infinity> Uhh.
[02:12] <Nafallo> infinity: hi :-). I would love your feedback as well ;-)
[02:12] <dendrobates> s/core/more/
[02:12] <infinity> We ship both, we don't INSTALL moin.
[02:12] <infinity> Try logic that makes sense. :P
[02:13] <Nafallo> infinity: I applied for ~ubuntu-server btw. when you have time etc... ;-)
[02:14] <dendrobates> I'm not saying we should start ssh-server by default, I think it might be a useful option in the installer.
[02:14] <dendrobates> Nafallo: I add you in a few minutes.
[02:15] <infinity> There's no point in installing it and not starting it.
[02:15] <Nafallo> dendrobates: ah. thanks :-)
[02:15] <infinity> That has the same net effect as not installing it at all.
[02:15] <Nafallo> I rather have a task for it.
[02:15] <infinity> Namely that you can't make it run without having physical access to the box. :P
[02:18] <dendrobates> It's still early for me.   My last comments have nothing to do with my checkbox comments earlier.   What I am saying is it might be good to have an installer option that defaults to off, that installs and starts ssh-server when checked.
[02:19] <dendrobates> Nafallo: Are you on the server mailing list?
[02:20] <Nafallo> dendrobates: yes, have been from the start I think. backlogged though :-P
[02:20] <Nafallo> dendrobates: so what I suggested, except I want it default to on :-)
[02:21] <dendrobates> yes.  I think it is a good idea.
[04:08] <nealmcb> ubuntu server team meeting in 53 minutes in #ubuntu-meeting
[04:08] <nealmcb> https://wiki.ubuntu.com/ServerTeam/Meeting
[04:45] <dendrobates> server team meeting in 15 minutes at #ubuntu-meeting.
[05:02] <dendrobates> server meeting in #ubuntu-meeting now.
[06:00] <Jekhar> I'm new to server administration, using an Ubuntu-6.06 server running Ruby1.8.4 which was installed with apt-get. I have not found a .deb on the repository my server is checking for Ruby1.8.6. I'm sure I could build it myself, but was curious as to whether installing it via rubygems would cause any problems or inconsistencies with the present 1.8.4 package.
[06:20] <gamble6x> Jekhar: not terribly experienced with the ruby packages on 6.06.  But I'm curious.  Do you need both 1.8.4 and 1.8.6?  If not you could uninstall 1.8.4 to make sure there are no conflicts.
[06:20] <gamble6x> my assumption would be if you're installing from source you can designate where it puts the files for 1.8.6 and then just make sure whatever apps need to use 1.8.6 are pointing to that location.
[06:25] <leonel> In most packaged  distributions  if you  install some package from source  you need to make sure you install that package somewhere your instaled packages does not conflict with the new one 
[06:32] <nealmcb> Jekhar: what do you need in particular from ruby1.8.6?  switching out language versions can have a lot of ramifications
[06:33] <nealmcb> !info ruby
[06:33] <ubotu> ruby: An interpreter of object-oriented scripting language Ruby. In component main, is optional. Version 1.8.2-1 (feisty), package size 18 kB, installed size 96 kB
[06:34] <nealmcb> http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=ruby
[06:37] <Jekhar> I guess you could say its a job requirement. The rails app was written with 1.8.6 on our machines. But, I know that when I do capistrano commands, I get a warning message about a bug in Ruby1.8.6's threading implementation.
[06:37] <nealmcb> That shows 1.8.2 as the ruby version in ubuntu dapper thru gutsy....
[06:39] <Jekhar> Yeah, when I do a apt-cache policy ruby, it shows 1.8.2, but when I do ruby -v, it shows 1.8.4
[06:39] <nealmcb> I don't know much more about ruby versions or what you might run into compiling it from source
[06:39] <nealmcb> Jekhar: interesting...
[06:40] <nealmcb> on feisty, ruby -v  gives  ruby 1.8.5 (2006-08-25) [i486-linux] 
[06:40] <nealmcb> so that package summary seems dubious....
[06:41] <nealmcb> but on feisty, dpkg -l ruby  gives 1.8.2-1
[06:43] <nealmcb> I'll look later for more about ruby versions - seems like a bug to me - but now, about time for breakfast....
[06:44] <pmjdebruijn> does anybody here know whether it's possible to configure dm-multipath on a root fs, during the Ubuntu installation?
[06:44] <pmjdebruijn> this is rather essential in "enterprise" environments.... many of our systems don't have local disks anymore...
[06:59] <Nafallo> damn
[06:59] <Nafallo> missed the meeting cause of RL-stuff
[07:06] <Nafallo> ehrm. make that php-page NOT know SQL passwords. just check that the modules are working please.
[07:06] <Nafallo> connect, but don't auth. rather connect() -> disco() sort of way.
[07:06] <Nafallo> jdstrand: ^ :-)
[07:11] <Nafallo> infinity: ^ even :-)
[07:11] <Nafallo> infinity: btw. we don't either have it in php5 or something or a new package putting in /var/www/index.php
[07:12] <Nafallo> just green OK or read FAIL ;-)
[07:12] <infinity> Nafallo: I wasn't planning on it having any password knowlege. :P
[07:12] <Nafallo> infinity: good :-)
[07:12] <infinity> Nafallo: (what do you take me for..?)
[07:13] <Nafallo> infinity: didn't read you had the task until further down in the meeting. I know yu wouldn't :-)
[07:15] <Nafallo> I might want to take a stab at postfix+dovecot later btw
[07:15] <infinity> Stab on.
[07:16] <Nafallo> I have a real slick setup at work that would be fun to have as a task :-)
[07:16] <infinity> Anyone who occasionally pretends to understand network-manager should find postfix trivial in comparison. :)
[07:16] <Nafallo> lol
[07:16] <lamont> infinity: I understand network-manager sufficient for my needs...
[07:17] <lamont> but then apt-get remove --purge isn't much of a need.
[07:17] <infinity> lamont: Nafallo's actually played around with the source.  That shit doesn't wash off.
[07:17] <infinity> I know, I still have some on me as well.
[07:17] <lamont> no, it most certainly does not.
[07:17] <Nafallo> basically let dovecot use static checking for users mboxes in /var/mail/$user and let postfix auth throu dovecot would be a nice default.
[07:18] <Nafallo> also let postfix listen to more then 127.0.0.1 if the task is installed.
[07:18] <infinity> lamont: It's scary, and it gets scarier with each new iteration.
[07:18] <lamont> Nafallo: that's a preseeding thing...
[07:18] <infinity> lamont: The "let's pretend every network is wpa" thing was utter crack-addled genius.
[07:19] <Nafallo> lamont: preseeding? you meant only listen on 127.0.0.1?
[07:19] <Nafallo> lamont: why do we even have that? feels like a leftover from when we installed an MTA by default
[07:19] <lamont> db4.4 only enables pthreadsmutexes (NPTL crap) on amd64?
[07:19] <infinity> Nafallo: Enough stuff depends on "postfix | mail-transport-agent" that it's still a good default.
[07:20] <lamont> Nafallo: because there's no good answer
[07:20] <lamont> and people on cable modems install postfix
[07:20] <infinity> lamont: In Debian, amd64 was the only arch guaranteed to be NPTL-friendly (old kernel support, blah blah blah)
[07:20] <lamont> and then complain when they were open relays for their neighbor's compromised machine
[07:20] <infinity> lamont: In Ubuntu, we can probably change that to do it across the board.
[07:20] <lamont> infinity: should I?
[07:20] <Nafallo> infinity: but if we put a small package that pre-depends on postfix and dovecot-imapd and does some small seds in postinst? ;-)
[07:21] <infinity> lamont: If it puts your heart a-twitter to do so.  I was planning on doing it anyway.
[07:21] <lamont> Nafallo: modifying another package's config files is forbidden
[07:21] <Nafallo> lamont: well, it isn't open relay by default surely?
[07:21] <lamont> infinity: doing an upload anyway....
[07:21] <lamont> Nafallo: it's an open relay for whatever is in $my_networks
[07:21] <infinity> lamont: Doing the whole db4.x family?
[07:21] <lamont> yep
[07:22] <infinity> lamont: Right, well, go nuts with the NPTL change too, then.
[07:22] <Nafallo> lamont: ah. right. and FQDN on those machines are the ISPs thingies...
[07:22] <lamont> Nafallo: the upstream default is all machines on the local subnet.
[07:22] <Nafallo> lamont: debconf wrapper for modifying other packages things not allowed as well, right?
[07:22] <lamont> which is bad on cable-modems and in co-lo centers
[07:22] <infinity> Aye.
[07:23] <Nafallo> agreed
[07:23] <infinity> Nafallo: You want to wrap debconf in debconf?
[07:23] <lamont> Nafallo: I'm all for making the admin answer the question, or edit the config later.
[07:23] <lamont> hence the default (since I wasn't allowed to ask the question...)
[07:24] <lamont> infinity: care if I ignore the NPTL change for db4.{2,3}?
[07:24] <lamont> I mean, 4.2 is _so_ dead, right?
[07:24] <infinity> lamont: Just change 'em all, lazy man.
[07:24] <lamont> (as in, why is that in main, still??)
[07:24] <Nafallo> a new package in the task pre-depending postfix and running dpkg-reconfigure -plow postfix *s*
[07:25] <lamont> I don't think dpkg is that friendly
[07:25] <infinity> lamont: It's in main because pitti and I need to do a reducing-duplication run again before gutsy+1.
[07:25] <lamont> heh
[07:25] <infinity> Nafallo: And we allow you to upload to the archive?
[07:26] <Nafallo> infinity: I wouldn't upload until I get concent on the ideas. you should now that by now :-)
[07:26] <Nafallo> know even
[07:26] <lamont> infinity: 4.2 and 4.3 both lack NPTL_SUPPORTED_CPUS variables -> lose
[07:26] <infinity> lamont: Oh, even better.  You don't have to change a thing1
[07:26] <lamont> except for hppa/java dropping
[07:26] <lamont> --> upload already
[07:27] <infinity> lamont: Did you add lpia to the NPTL_SUPPORTED_CPUS list?
[07:27] <Nafallo> infinity: those ideas are intrusive enough to demand a spec anyway btw :-)
[07:27] <infinity> Spec, schmeck.  I upload intrustive things ALL THE TIME.
[07:27] <lamont> 4.5 has NPTL mutexes disabled for everyone....
[07:27] <infinity> I call it "work".
[07:28] <infinity> lamont: Yay consistency.
[07:28] <lamont> infinity: should I turn it on for giggles?
[07:28] <Nafallo> infinity: wasn't that you who hexedited fglrx or something? :-)
[07:28] <lamont> infinity: in 4.4, I eliminated the CPU check. :-)
[07:28] <infinity> lamont: Clint's a bit schizophrenic.  I think I need to get back into bdb maintenance again for a bit.
[07:28] <infinity> Nafallo: Yes.
[07:28] <infinity> Nafallo: We still do it.
[07:28] <Nafallo> infinity: I loved that one :-)
[07:28] <lamont> so was that a yes on "turn on NPTL for all in db4.5"???
[07:29] <lamont> infinity: what did we have to hexedit?
[07:29] <infinity> lamont: What could possibly go wrong?
[07:29] <lamont> LOL
[07:29] <lamont> done
[07:29] <lamont> #ifneq (,$(findstring z$(DEB_BUILD_GNU_CPU)z,$(NPTL_SUPPORTED_CPUS)))
[07:29] <lamont> ifneq (,$(findstring z$(DEB_BUILD_GNU_SYSTEM)z,$(NPTL_SUPPORTED_SYSTEMS)))
[07:29] <lamont> CONFIGURE_SWITCHES += --enable-pthreadsmutexes=yes
[07:29] <lamont> endif
[07:29] <lamont> #endif
[07:29] <lamont> I win.
[07:29] <infinity> lamont: SUSEish lib32/lib64 paths in the libGL.so binary.
[07:29] <Nafallo> lamont: the path to something xorgish I think :-)
[07:29] <Nafallo> lamont: re:hex
[07:30] <lamont> trembling....
[07:31] <infinity> lamont: There's nothing to fear, really...
[07:31] <lamont> infinity: yeah, I've certainly done worse.
[07:36] <jdstrand> Nafallo: I just got back from lunch-- I wouldn't have put a password in there either!
[07:37] <jdstrand> so I am not clear on what was decided regarding openssh-server task.  Or was it tabled til next time?
[07:38] <jdstrand> next meeting that is
[07:38] <Nafallo> wtf... why do we need an LAMP exception? it's a TASK, not INSTALLED BY DEFAULT
[07:38] <Nafallo> :-P
[07:39] <dendrobates> I want to start working on the sshd tasksel, but no one volunteered.
[07:40] <jdstrand> the task itself wouldn't be hard (haven't worked with tasksel myself, but certainly could).
[07:40] <jdstrand> I was mainly getting at whether ssh should be enabled by default with LAMP
[07:41] <nealmcb> Jekhar: the ruby version naming issue has already been reported: https://bugs.launchpad.net/ubuntu/+source/ruby-defaults/+bug/50480
[07:42] <nealmcb> [where did ubotu go?] 
[07:42] <dantalizing> ssh enabled by default with LAMP -1
[07:43] <Nafallo> dantalizing: agreed.
[07:43] <nealmcb> :-)
[07:43] <nealmcb> bug 50480
[07:43] <ubotu> Launchpad bug 50480 in ruby-defaults "Reported version is incorrect" [Undecided,Confirmed]  https://launchpad.net/bugs/50480
[07:43] <Nafallo> I would want ssh on the virtual host and not in the lamp guest on that server :-)
[07:44] <infinity> lamont: Oh, the LRM hack in question is correct-lib-path.c (and calls to correct-lib-path in debian/rules)
[07:44] <Nafallo> anyone agrees?
[07:44] <Nafallo> infinity: hmm. can we tell the bootthingie to install two tasks when choosing LAMP?
[07:44] <lamont> infinity: that's not hexediting... hex editing requires manual human intervention
[07:45] <jdstrand> Nafallo: I am inclined to agree.  It was brought up in the meeting that this use case as well as web developers wouldn't want it.
[07:45] <infinity> lamont: I used to do it with a hex editor, before automating it.
[07:45] <infinity> Nafallo: Of course we can.
[07:45] <lamont> infinity: automation is good
[07:46] <Nafallo> infinity: would you like that idea then? seperate tasks and make the starfeature install both of them, leaving the virtual box admin to install ssh-task on host and lamp-task on guest :-)
[07:46] <jdstrand> the way I feel is how many users want it or don't want it.  If users really want it, what about having a lamp-ssh-server task in addition to lamp-server?
[07:47] <jdstrand> not sure that is the best option, but it would at least address both sets of users
[07:47] <Nafallo> jdstrand: naah. cluttering.
[07:47] <dantalizing> i dont see the difficulty in a user adding ssh later
[07:47] <dantalizing> server install should be minimal
[07:47] <Nafallo> jdstrand: I rather have the bootmenu install both and then the regular installer have to choose them specifically.
[07:47] <jdstrand> Nafallo: there is already talk of openssh-server task.  Not sure if adding lamp-ssh-server would be more clutter
[07:47] <dantalizing> LAMP has an expected set of components
[07:48] <dantalizing> SSH is not one of them
[07:49] <jdstrand> Nafallo: that is still a little surprising to me, as a user, unless the bootmenu was clear that it is installing openssh-server
[07:49] <dantalizing> if remote administration is the thing, why not install SSH with any "server" application
[07:49] <jdstrand> dantalizing: aggreed
[07:49] <jdstrand> s/aggreed/agreed/
[07:50] <ScottK> Well it's certainly the first pacakge I install after a server setup.
[07:50] <Nafallo> dantalizing: space+enter vs. login, apt-get, wait, logout
[07:50] <jdstrand> without having studied any statistics, it seems that there is a large set of users who would install it immediately, and quite a few who wouldn't
[07:51] <Nafallo> jdstrand: LAMP+SSH in the boot then :-)
[07:51] <Nafallo> dantalizing: because of the non open ports policy :-)
[07:51] <dantalizing> scottk, me too, but for a server it is much better to err on the side of forcing users to install stuff, than adding extra unneeded (sp?) stuff
[07:51] <Nafallo> dantalizing: so better tick the box during install.
[07:52] <Nafallo> then the user agreed to broke non open ports :-)
[07:52] <dantalizing> yes
[07:52] <Nafallo> and doesn't have to login after final reboot
[07:53] <Nafallo> just reboot and go away, continue with what else to do.
[07:53] <Jekhar> nealmcb: thanks
[07:53] <Nafallo> and yes, raidcontrollers can take minutes of waiting better spent elsewhere...
[07:53] <ScottK> dantalizing: Not trying to argue either way (I agree no open ports by default is a good policy.
[07:53] <ScottK> I like Nafallo's tickbox idea.
[07:54] <dantalizing> yes
[07:54] <Nafallo> ScottK: what about alt. bootmenu to LAMP+SSH? :-)
[07:54] <Nafallo> ScottK: as our keyfeature
[07:55] <ScottK> Nafallo: Dunno.  LAMP + only SSH seems like kind of a detail.
[07:56] <jdstrand> ScottK: IMO it is a critical detail leaving an open login port with letting the user know.
[07:56] <jdstrand> s/with/without/
[07:56] <ScottK> jdstrand: Agreed.
[07:56] <ScottK> That's why I liked Nafallo's idea of asking if they want it.
[07:57] <Nafallo> ScottK: you knew I was talking about the SUSE thing we use for choosing stuff after booting the iso, right? :-)
[07:57] <jdstrand> ScottK: yes-- I believe there is consensus on having an openssh-server task, to check that box.  Please correct me if I am wrong.
[07:57] <jdstrand> ScottK: there was also talk of enabling ssh with LAMP by default.
[07:57] <Nafallo> ScottK: we have install, install lamp etc... would make sense to have install lamp+ssh and install both lamp and ssh task by that option.
[07:57] <jdstrand> ScottK: this was all from the meeting today
[07:58] <ScottK> Nafallo: No.  I've never run a suse server, just desktop.
[07:58] <ScottK> Yes.  I was reading during the meeting, but didn't have much to say.
[07:58] <ScottK> Nevermind then.
[07:58] <Nafallo> ScottK: you still get the bootmenu on the iso that comes from SuSE originally :-)
[07:59] <ScottK> OK.  It's been a long time since I installed a server from scratch.
[07:59] <Nafallo> ScottK: F1-F6 to change options you know... :-)
[07:59] <ScottK> Right
[07:59] <Nafallo> ScottK: so select LAMP+SSH instead of having install LAMP and get no SSH?
[08:00] <Nafallo> I think the option preseeds the installers taskquestion.
[08:00] <Nafallo> infinity: correct?
[08:00] <nealmcb> Jekhar: if you really need ruby, rather than a straight source compile you might see what the version in gutsy is, and build that source package on dapper (which does the compilation) and install the package it produces.  managing things via packages is a really good idea
[08:03] <nealmcb> (i.e. if you really need _version 1.8.6_ of ruby...)
[08:05] <jdstrand> dendrobates: since infinity is going to do the php page, I'll look at tasksel for openssh-server
[08:06] <Nafallo> jdstrand: great! what about the LAMP vs. LAMP+SSH in the isomenu? :-)
[08:07] <Nafallo> I haven't heard many arguments against...
[08:07] <jdstrand> Nafallo: no not yet.  Hopefully we'll get some more input
[08:09] <Nafallo> jdstrand: yea, that would be good :-)
[08:09] <Jekhar> nealmcb: Um, I'm not exactly sure how to do that.
[08:10] <Jekhar> But I'm pretty sure that gutsy has 1.8.2
[08:16] <nealmcb> feisty has ruby 1.8.5 (despite what dpkg says).  I don't know what gutsy has, but it should be at least 1.8.5
[08:17] <Nafallo> nealmcb: packagename?
[08:17] <nealmcb> can someone with gutsy run "ruby -v"  (install "ruby" package)
[08:17] <Nafallo>       ruby |    1.8.2-1 | http://gb.archive.ubuntu.com gutsy/main Packages
[08:17] <nealmcb> bug 50480
[08:17] <ubotu> Launchpad bug 50480 in ruby-defaults "Reported version is incorrect" [Undecided,Confirmed]  https://launchpad.net/bugs/50480
[08:18] <dantalizing> getting ruby1.8.6.36-1ubuntu1
[08:18] <Nafallo> dantalizing: *confirm*
[08:19] <dantalizing> ruby 1.8.6 (2007-06-07 patchlevel 36) [i486-linux] 
[08:20] <Nafallo> so the metapackage has the wrong version :-P
[08:20] <Nafallo> and we import that from Debian
[08:21] <Nafallo> and our ruby1.8 is probably updated in Ubuntu :-)
[08:21] <dantalizing> so Jekahar should be ok
[08:21] <Nafallo> there you go. your bug explained ;-)
[08:21] <dantalizing> *Jekhar
[08:21] <nealmcb> can someone give Jekhar tips on building that source package on dapper?
[08:21] <dantalizing> i dont think there is a need...if i understand he was looking for 1.8.6
[08:21] <Nafallo> ask jdong for a backport? :-)
[08:21] <dantalizing> which is installed
[08:22] <Jekhar> ruby 1.8.4 (2005-12-24) [x86_64-linux] 
[08:22] <nealmcb> but he is running dapper, and gutsy isn't out yet....
[08:22] <dantalizing> oic
[08:32] <nealmcb> https://help.ubuntu.com/community/CompilingSoftware 
[08:39] <dantalizing> looks like ruby is a basic configure/make/make install
[08:39] <dantalizing> no autoconf
[08:52] <Jekhar> Oh, yes indeed it is. I just did a wget from ruby-lang.org and did the usual install steps. I was going to use pbuilder but decided against it
[08:56] <Jekhar> Would there be any need for me to upgrade svn on the server?
[09:39] <nealmcb> Jekhar: did you put it in a different place than the default ruby?  or uninstall the default?
[09:39] <nealmcb> Jekhar: changing svn would seem to invite more problems, unless there is some feature you need
[09:47] <Jekhar> I put it in a different place as I could not find where the default was stored (I love having multiple people working on the same server). When I run "ruby -v" it reports 1.8.6, but I can't run any Rails "script" commands on the server
[09:56] <bdmurray> mathiaz: every once in a while I see [2380777.861967]  smb_get_length: Invalid NBT packet, code=b6
[09:56] <bdmurray> between my Feisty desktop and Dapper server
[09:56] <bdmurray> and smb_add_request: request [ffff8100b5462e00, mid=2769]  timed out!
[09:56] <mathiaz> hum.. does it crash you server or client ?
[09:56] <bdmurray> the client hiccuped this time
[09:57] <mathiaz> do you get a timeout ?
[09:57] <bdmurray> I'm using rhthymbox to listen to music and it there was quite a pause in the song
[09:57] <nealmcb> Jekhar: getting all the rails tools etc to find the right ruby stuff in an unofficial place may be a challenge - might want to ask on a rails channel.
[09:58] <mathiaz> bdmurray: how do you mount your dapper server 
[09:59] <mathiaz> bdmurray: with smbfs or cifs ?
[09:59] <bdmurray> mathiaz: with smbfs
[10:00] <mathiaz> bdmurray: could try to mount it with cifs ?
[10:01] <mathiaz> bdmurray: smbfs is no longer supported.
[10:02] <bdmurray> mathiaz: hunh, since when?
[10:03] <mathiaz> bdmurray: well. Let me rephrase that - smbfs is not actively maintained by upstream
[10:03] <mathiaz> bdmurray: anymore. Cifs is the successor/replacement for smbfs.
[10:08] <bdmurray> so just a s/smbfs/cifs/ in my /etc/fstab?
[10:13] <mathiaz> bdmurray: that should do it.
[10:15] <bdmurray> mathiaz: neat, I'll have to experiment some then
[10:19] <ajmitch> mathiaz: great, so next server team meeting will be at a different time? :)
[10:21] <mathiaz> ajmitch: we don't know yet.
[10:21] <mathiaz> ajmitch: it's just that we were running out of time. 
[10:22] <mathiaz> ajmitch: so dendrobates asked if we should have more frequent meetings.
[10:22] <mathiaz> ajmitch: I guess that 19:00 UTC would be a better time for you guys ?
[10:22] <ajmitch> well, feature freeze is almost upon us
[10:23] <ajmitch> yes, 7AM isn't too bad
[10:24] <ajmitch> back in 10 minutes
[10:35] <ajmitch> ok
[10:38] <Innatech> having some trouble with a 7.04 install on SATA drives. I've tried with a dmraid mirror, an mdraid mirror, with boot on  a plain ext3 partition  and / on a  mdraid mirror, and finally with plain ext3 /boot and / partitions on a single drive. The failure mode is the same each time: install is OK from CD, and when complete you can chroot into target and do stuff--but when rebooting GRUB dies silently when you try and boot a kernel. 
[10:38] <Innatech> break=premount doesn't help, it hangs forever at "starting up...."
[10:52] <mathiaz> sommer: I've updated the ServerTeam Roadmap
[10:53] <sommer> mathiaz: cool 
[10:53] <mathiaz> sommer: with a section about tracking wiki pages on help.ubuntu.com
[10:53] <nealmcb> mathiaz: thanks for all the bug triage also!
[10:53] <mathiaz> nealmcb: yeah ! I finised the last bugs below 90 000 yesterday
[10:54] <mathiaz> nealmcb: but ivoks did a lot of work too...
[10:54] <sommer> mathiaz: I just got done reading through the dovecot doc for feisty and there are a couple of updates.
[10:54] <sommer> Should I create a page under the section you created update drafts?
[10:55] <sommer> if that makes sense?
[10:55] <mathiaz> sommer: hum.. for now, I'd just list the pages.
[10:55] <sommer> sure no problem.
[10:55] <mathiaz> sommer: I've added a sentence "Here is a list of pages that requires some attention:"
[10:56] <mathiaz> sommer: so you could just add bullet points below it, linked to the wiki page on help.ubuntu.com
[10:56] <sommer> ya...what I was thinking was to add a link to the original page and a link to proposed updates.
[10:56] <mathiaz> sommer: I don't think we need that structure.
[10:57] <mathiaz> sommer: help.ubuntu.com/community/ is a wiki.
[10:57] <mathiaz> sommer: so pages should be updated directly
[10:57] <mathiaz> sommer: (there is always a history).
[10:57] <sommer> ah...I'm with ya
[10:57] <mathiaz> sommer: and I don't think that we have the man power to have a review process
[10:58] <mathiaz> a wiki is supposed to be editable by anyone
[10:59] <mathiaz> it should be easy to update a page
[10:59] <ScottK> lamont: Would you have any interest in uploading the current git-core release before UVF?  There's a debian/control typo (milli found it when he was looking at it), so the debdiff is here: Bug 132527
[10:59] <ubotu> Launchpad bug 132527 in git-core "Please merge git-core 1:1.5.2.4-1 from Debian Unstable (Main)" [Undecided,New]  https://launchpad.net/bugs/132527
[10:59] <sommer> mathiaz: so is this page the official doc?  https://help.ubuntu.com/7.04/server/
[11:00] <lamont> ScottK: what ubuntu-changes do we have, I wonder.
[11:00] <lamont> and yes, I would be interested
[11:00] <ScottK> We have none now.
[11:00] <sommer> mathiaz: Is that also under community?
[11:00] <mathiaz> sommer: that's the ubuntu server guide maintained by the doc team.
[11:00] <ScottK> The only one I proposed is fixing the typo in the build-dep.
[11:00] <mathiaz> sommer: it's not under the community umbrella.
[11:00] <sommer> mathiaz:  gotcha, that's that doc where I found a couple of updates.
[11:01] <mathiaz> sommer: the server guide is maintained in docbook.
[11:01] <lamont> ScottK: I just played drumsticks on postfix/+bugs. :-)
[11:01] <mathiaz> sommer: the community docs are located under help.ubuntu.com/community/
[11:01] <ScottK> I saw.  Very nice.
[11:01] <lamont> and I'll be uploading 2.4.5-2 and syncing that to ubuntu once I test the config changes
[11:01] <mathiaz> sommer: it's a wiki.
[11:02] <sommer> mathiaz: aaaahhhh...my bad I was looking under the wrong area.
[11:02] <mathiaz> sommer: if you want to update the server guide, you should contact the ubuntu-doc team.
[11:02] <lamont> ScottK: rock
[11:02] <ScottK> sommer: Or you can file bugs against ubuntu-doc and attach a patch.
[11:02] <mathiaz> sommer: they'll be happy if someone wants to make some changes to the server guide.
[11:03] <sommer> mathiaz: is the docbook source available?
[11:03] <mathiaz> sommer: yes. it's in a svn repository I think.
[11:03] <mathiaz> sommer: the DocTeam is also a community team.
[11:03] <sommer> mathiaz: cool I'll check into it...at least for the dovecot page...heh
[11:04] <lamont> ScottK: so debian's 1.5.2.4-1 has a typo?  or gutsy has different packages?
[11:04] <mathiaz> sommer: https://wiki.ubuntu.com/DocumentationTeam/
[11:05] <ScottK> lamont: Deiban's 1.5.2.4-1 has a typo (it's been reported).
[11:05] <ScottK> Debian even
[11:05] <lamont> you have a debian bug #?
[11:05] <sommer> mathiaz: thanks for the link.  I've got a migration to LDAP to do so I'll check in later.
[11:05] <ScottK> No.  I'll go look.
[11:05] <lamont> ah.  433196
[11:05] <lamont> nm
[11:05] <ScottK> Debian bug 433196
[11:05] <ubotu> Debian bug 433196 in git-core "Typo of libcurl3-gnutsl-dev in Build-Depends" [Minor,Open]  http://bugs.debian.org/433196
[11:06] <ScottK> That's the one.
[11:06] <lamont> ScottK: given that (1) it's an obvious failure, and (2) marked as pending upload, I'm going to be evil and upload it as 1:1.5.2.4-1build1
[11:06] <lamont> with only slight amounts of guilt
[11:06] <ScottK> And then file a sync request?
[11:07] <lamont> no.  upload that to ubuntu, and then 1.5.2.4-2 will autosync over it... and hopefully he wasn't lying about having it fixed for the next upload.
[11:07] <ScottK> Ah
[11:07] <ScottK> I see
[11:07] <ScottK> Sounds good to me.
[11:07] <lamont> LP# nnnn, yes?
[11:07] <ScottK> Yes
[11:08] <ScottK> Except there's no LP bug written for that
[11:08] <ScottK> Oh
[11:08] <ScottK> No
[11:08] <ScottK> It's LP: #nnnn
[11:13] <lamont> 132527 is the LP bug
[11:14] <ScottK> Ah.  For the merge.  Got it now.  
[11:14] <ScottK> I guess I should have put that in the debian/changelog I did.
[11:16] <mathiaz> We hadn't had enough time to get to the Triagger section of the Roadmap during the meeting.
[11:17] <mathiaz> The goal was to have a look at all the samba bugs below 90 000
[11:17] <mathiaz> which has been reached.
[11:17] <mathiaz> So I'd like to set another target for Triagging work.
[11:17] <mathiaz> Either apache2 or php5 - any preferences ?
[11:18] <ScottK> I don't have a personal stake either way, but it seems to me it'd make sense to deal with Apache2 first.
[11:20] <ajmitch> php5 has 37 open bugs
[11:20] <mathiaz> well - we'd target only New,Unconfirmed bugs
[11:21] <mathiaz> apache2 has 13 and php5 has 18
[11:21] <ajmitch> not too many in either case
[11:22] <nealmcb> I'd guess that startiing with apache2 would be good
[11:22] <mathiaz> ajmitch: I think it's realistic to have them triagged in 2 weeks.
[11:23] <ajmitch> agreed
[11:23] <mathiaz> we'll go back to samba later...
[11:25] <ScottK> ajmitch: Invalid and Won't Fix are my favorites.
[11:25] <ajmitch> heh
[11:25] <ajmitch> eg https://bugs.launchpad.net/ubuntu/+source/php5/+bug/120103
[11:25] <ubotu> Launchpad bug 120103 in php5 "PHP 5.2.3-ubuntu1 Broken - Problems with : /usr/lib/php5/20060613+lfs/" [Undecided,New]  
[11:26] <ajmitch> I can't reproduce it, though I recall something like that in the past
[11:27] <lamont> ScottK: uploaded
[11:27] <ScottK> Cool.
[11:27] <ScottK> Now all I need is an archive admin for a sync and my "Done before UVF" list is complete.
[11:28] <lamont> ScottK: and about 21 hours or so
[11:28] <ScottK> Yeah.
[11:28] <lamont> er, that was git-core uploaded to gutsy, not debian
[11:29] <lamont> what do you have that's sync-pending?
[11:29] <ScottK> That's what I thought.
[11:29] <ScottK> Bug #132543
[11:29] <ubotu> Launchpad bug 132543 in pypolicyd-spf "Please sync pypolicyd-spf 0.4.1-1 from Debian Unstable (Main)" [Medium,Confirmed]  https://launchpad.net/bugs/132543
[11:29] <ScottK> Is the one.
[11:29] <lamont> oh.  spf crap
[11:29] <ScottK> No, good SPF stuff.
[11:29] <ScottK> It's a tool, not a panacea.
[11:29] <ajmitch> my todo list before UVF is only a mile long
[11:30] <ajmitch> including a security update to do asap
[11:30] <ScottK> lamont: I agree that SPF sucks, it just sucks less than the other available options.
[11:30] <lamont> and breaks email
[11:30] <lamont> go spf
[11:30] <ScottK> Sure.  But only a little.
[11:30] <lamont> spf: proof that college kids can write protocols
[11:30] <ScottK> What's better and deployable currently?
[11:31] <lamont> dkim is at least sensible
[11:31] <ScottK> For combating domain forgery?
[11:31] <ScottK> What does DKIM give you beyond another identity that the end-user doesn't see?
[11:31] <ScottK> If they were going to do a proper policy component, I would agree.
[11:32] <ScottK> Actually, though I see good synergy between the two.
[11:32] <lamont> anyone who implements a collective-discussion interface via /etc/aliases will discover that spf doesn't allow users to send mail to that interface and have it delivered to their coworkers...
[11:32] <lamont> there is absolutely no guarantee that email from user@foo.com will arrive from foo.com's mail servers.
[11:32] <ScottK> That's true.
[11:33] <lamont> SPF asserts that there is.
[11:33] <lamont> and if you check that the mail comes from where foo.com says it must, then you bounce valid email.
[11:33] <ScottK> SPF asserts that domain owners should be able to assert that one should be suspicious about mail that doesn't.
[11:33] <lamont> I know that my company won't let me do that.
[11:33] <lamont> (hurt when I did...)
[11:34] <ScottK> Yes, but there is deployed forgery prevention scheme that doesn't do that.
[11:34] <ScottK> DKIM breaks on most mailing lists and has the same "greeting card" problem that SPF does.
[11:35] <lamont> the only real solution is end user signing... but they won't stand for that yet.
[11:35] <ScottK> Right, so in the meantime, it's nothing or an imperfect solution.
[11:35] <ScottK> Some will wait, some would prefer the imperfect solution.
[11:35] <lamont> my big issue with spf was that the designers did their design, published it, got feedback about what they broke, and said (basically) "We choose to ignore that part of the spec, because it's inconvenient"
[11:37] <ScottK> Well we are working on that bit now.
[11:37] <lamont> until spf allows mail to come from anywhere, it breaks that part of the whole store-n-forward mail delivery architecture.
[11:37] <lamont> 'which is to say, there's a lot of work there.
[11:38] <ScottK> As an example, one "solution" to the forwarding problem is for recievers to whitelist known forwarders from SPF checks.  pypolicyd-spf now supports whitelisting.
[11:39] <ScottK> The truth is thought that, except for alias forwarding, mail today is point to point (at least border point to border point).
[11:40] <ScottK> Of course it's opt-in at the domain level, so we don't have to agree.
[11:41] <lamont> whitelisting will help, that's always a good thign
[11:42] <lamont> of course, that's the big issue with spam fighting in general.. how much of a false-{positive,negative} rate does $CUST feel is acceptable
[11:42] <ScottK> Yes.
[11:43] <ScottK> The data I've seen says the "forwarding problem" is generally a less than 1% (often much less) problem.  That may or may not be tolerable.
[11:44] <lamont> well, it's idiots who don't know how to set up a mailing list, for the most part. :-)
[11:44] <lamont> and .forward files
[11:44] <ScottK> Yes.  That's in the less than 1% by volume.