[02:23] <DarkSun88> Hi all
[04:25] <Hobbsee> @schedule sydney
[04:25] <ubotu> Schedule for Australia/Sydney: 08 Jun 06:00: Ubuntu Development Team | 13 Jun 01:00: Kernel Team | 13 Jun 22:00: Edubuntu | 15 Jun 02:00: Ubuntu Development Team | 17 Jun 03:00: Xubuntu Developers | 20 Jun 05:00: Technical Board
[04:27] <evand> @schedule new_york
[04:27] <ubotu> Schedule for America/New_York: 07 Jun 16:00: Ubuntu Development Team | 12 Jun 11:00: Kernel Team | 13 Jun 08:00: Edubuntu | 14 Jun 12:00: Ubuntu Development Team | 16 Jun 13:00: Xubuntu Developers | 19 Jun 15:00: Technical Board
[09:53] <dholbach> hiya agoliveira
[09:54] <Riddell> evening
[09:54] <pitti> hi
[09:54] <mathiaz> hello
[09:55] <bryyce> hi all
[09:55] <keescook> hiya
[09:56] <evand> hello
[09:57] <bdmurray> olleh
[09:57] <cjwatson> good evening all
[09:58] <dholbach> bdmurray: (-: o
[09:58] <bdmurray> doh, that didn't render well
[09:58] <pitti> dholbach: erk
[09:58] <pitti> here it did
[09:58] <pitti> but it hurts my eyes :)
[09:58] <kylem> moo.
[09:58] <bdmurray> I blame keescook
[09:58] <pitti> bdmurray: no, its not a 'X rendering fonts upside down' bug :)
[09:58] <keescook> bdmurray: get yer own colo! ;)
[09:59] <shawarma> Good evening, all.
[09:59] <fabbione> evening
[10:00] <asac> hi all
[10:00] <dholbach> cjwatson: doko told me he might be 5 minutes late
[10:00] <cjwatson> ok
[10:00] <cjwatson> thanks
[10:01] <cjwatson> asac,rtg__: ping?
[10:01] <rtg__> dong
[10:01] <dholbach> wow.... hey mvo
[10:01] <asac> cjwatson: 5 lines above :)
[10:01] <mvo> good evening
[10:01] <mvo> hey dholbach
[10:01] <asac> evening mr. mvo
[10:02] <cjwatson> asac: err, sorry, didn't mean you :)
[10:02] <cjwatson> bryyce: ping
[10:02] <bryyce> heya
[10:02] <cjwatson> cool
[10:02] <cjwatson> now where's mdz
[10:02] <cjwatson> mdz: pingaling
[10:02] <Keybuk> stuck at the mercy of British Rail I'm afraid
[10:02] <Keybuk> https://wiki.ubuntu.com/DevelTeamMeeting20070607
[10:03] <Keybuk> let's get started while mdz is delayed
[10:03] <Keybuk> everybody here?
[10:03] <Riddell> I am
[10:03] <Keybuk> I see everyone from my team, Colin and Heno, everyone from yours?
[10:03] <agoliveira> The ones absent, please raise your hands!
[10:03] <heno> Keybuk: yep
[10:03] <cjwatson> Keybuk: yes
[10:03] <Keybuk> everyone from mdz's looks to be here too?
[10:03] <shawarma> Think so.
[10:04] <mathiaz> yop
[10:04] <Keybuk> so, we have some new people with us today
[10:04] <bryyce> yay!
[10:04] <Keybuk> keescook has returned from the IS team, and will be working on security, and filling in his spare time with some server work
[10:04] <keescook> \o/
[10:04] <mvo> welcome back!
[10:04] <asac> keescook: welcome back!
[10:04] <shawarma> Yay, keescook!
[10:04] <keescook> thanks; I missed you guys.  :)
[10:05] <Keybuk> and heno has bravely stepped up to lead our QA efforts, and will be reporting to mdz and leading the new QA team; the first member of which is bdmurray
[10:05] <cjwatson> QA> there will be more
[10:05] <heno> indeed
[10:05] <bdmurray> that'll be nice
[10:05] <kylem> more quality? :P
[10:05] <cjwatson> kylem: maaaaaaaaybe
[10:05] <pitti> Quality! Quality! Quality!
[10:05] <heno> I'm assigning bugs to all of you as we speak :)
[10:06] <keescook> :)
[10:06] <Mithrandir> Keybuk: spare time?  What's that? :-P
[10:06] <dholbach> heno: python-launchpad-bugs FTW :)
[10:06] <Keybuk> if everyone's read the agenda and reports, any further agenda items before we get started?
[10:06] <cjwatson> I encourage those of you with ideas or problems related to quality, bugs, etc. to make sure heno is aware of them so that he can include them in plans
[10:07] <heno> yep, tips and suggestions welcome!
[10:08] <Keybuk> aha, an mdz!
[10:08] <Keybuk> no longer at the mercy of SouthEastern trains, eh?
[10:08] <BenC> heno: please ping me when you have ample time :)
[10:08] <agoliveira> mdz_: hi boss
[10:08] <cjwatson> so no more agenda items; let's go on with those we have
[10:08] <mdz_> Keybuk: south west
[10:08] <cjwatson> Where is the right place to carry kernel /proc/sys settings? (kees)
[10:08] <cjwatson> historically this has been in procps, but I agree that the conffile merge is a bit nasty
[10:08] <Keybuk> keescook: so there's obviously /etc/sysctl.conf, but that's not really great
[10:08] <kylem> cjwatson, why not have an /etc/sysctl.d? :)
[10:09] <cjwatson> haha donk
[10:09] <Keybuk> there's the double-not-great there of also it only gets done once
[10:09] <cjwatson> nightmare ;-)
[10:09] <keescook> right, I already did the procps change, but I thought I'd double check
[10:09] <Keybuk> so if the sysctl is for a module, it won't take effect
[10:09] <heno> BenC: will do, thanks
[10:09] <cjwatson> Keybuk: interesting point
[10:09] <kylem> Keybuk, modules can't register sysctls iirc
[10:09] <keescook> aaah, yeah
[10:09] <kylem> it's a static kernel table.
[10:09] <keescook> so, this is (currently) for core kernel features.
[10:09] <kylem> i'm 99% sure...
[10:09] <cjwatson> BenC: are you willing to have your team take such patches?
[10:09] <keescook> I expect more, though
[10:09] <BenC> sysctl.d sounds like a good idea
[10:10] <Keybuk> kylem: /proc/sys/net/ipv6 ? :p
[10:10] <cjwatson> doko: welcome
[10:10] <mdz_> keescook: what's the use case you're trying to address?
[10:10] <BenC> cjwatson: which kind of patches?
[10:10] <BenC> for procps?
[10:10] <Keybuk> my thoughts in the past was indded an /etc/sysctl.d that would get re-run on each module load
[10:10] <kylem> Keybuk, good point.
[10:10] <doko> sorry, a bit late
[10:10] <keescook> mdz_: the use-case is me getting controversial security features into mainline kernel.
[10:10] <kylem> Keybuk, apparently maybe things have changed in the intervening 7 years since i cared about a sysctl :P
[10:10] <mdz_> keescook: which require boot-time initialization of sysctls?
[10:10] <keescook> I've been allowed to do it as long as I provide a /proc toggle
[10:10] <Keybuk> keescook: does the sysctl turn them on or off?
[10:10] <mdz_> ah
[10:11] <cjwatson> sysctl.d does sound a bit excessive to me though; .d usually means because multiple packages need to ship configuration
[10:11] <keescook> Keybuk: right.  for example /proc/sys/kernel/maps_protection (now in gutsy)
[10:11] <pitti> keescook: ah, such as enabling /tmp race protection and such?
[10:11] <BenC> I have to step out for 15, but maybe udev could handle the modular sysctl stuff?
[10:11] <cjwatson> BenC: right, things that we're setting in the default distro anyway in /etc/sysctl.conf at the moment
[10:11] <keescook> pitti: right, symlink races, and I can imagine there may be others
[10:11] <cjwatson> since we ship them that way by default, it's arguable that our kernel should just default that way
[10:11] <Keybuk> BenC: udev can set sysctls quite easily, since it knows when modules are added
[10:11] <BenC> cjwatson: we can do that, yes
[10:12] <kylem> are you proposing applying these from initramfs?
[10:12] <iwj> My autopkgtest-xenlvm needs to mess with sysctl.
[10:12] <BenC> Keybuk: right, my thoughts exactly
[10:12] <pitti> keescook: hmm, but sysctl.conf is a conffile, so why is that so painful?
[10:12] <iwj> That is, maybe people will hate it for doing so but it does anyway :-).
[10:12] <cjwatson> at present, we appear to set kernel.printk, kernel.maps_protect, and some dev.mac_hid stuff on powerpc
[10:12] <cjwatson> (the latter of which is mostly superseded by mouseemu now)
[10:12] <keescook> pitti: well, I just worry about people having to do a sysctl.conf merge on each upgrade
[10:12] <Keybuk> cjwatson: and all of net.ipv4.conf.*
[10:12] <iwj> I think a .d is the right answer.
[10:12] <keescook> and I'd hate to see people ignore the update and leave themselves open
[10:13] <cjwatson> keescook: even worse, it's a conffile with arch-specific contents
[10:13] <kylem> kees, why would this change more than once a stable release
[10:13] <mdz_> cjwatson: eewww
[10:13] <kylem> surely procps isn't going to have /that/ many bugs. :P
[10:13] <cjwatson> fortunately work in feisty means that can probably go away in the future, but still
[10:13] <keescook> kylem: it shouldn't, which is why I put it in currently.  I just thought I'd ask here where everyone can give me some ideas.  :)
[10:13] <pitti> keescook: hm, but in general that's true for every changed conffile; do you really think that so many people will care?
[10:13] <cjwatson> another problem with sysctl.conf or sysctl.d is that if sysctls go away and you don't merge conffile changes you get cryptic warnings on boot which look scary but aren't
[10:14] <pitti> anyway, I agree that setting those we care about by default in the kernel is a bit cleaner
[10:14] <cjwatson> what does sysctl.d buy us over sysctl.conf?
[10:14] <iwj> cjwatson: It lets my package not have to invent an init.d script which doesn't work properly because it runs too early.
[10:14] <mdz_> if we're changing the default, it should be changed in the kernel
[10:14] <Keybuk> cjwatson: takes away merge headaches
[10:14] <keescook> I'd probably like to see two things:  1) sysctl.d (to avoid merge pain)  2) sysctl not die when it tries to set a non-existing file
[10:14] <mdz_> and so no sysctl.conf modification should be required to stick with the default
[10:14] <iwj> And keescook's (2) too.
[10:15] <cjwatson> it sounds like there are a couple of different cases, one set of which (e.g. iwj's) are addressed by sysctl.d and others of which (the stuff procps is shipping by default) should be addressed by kernel patches
[10:15] <keescook> mdz_: that's was my thinking originally.  it's a 1 line patch to the kernel, and if people don't like it for some reason, they should _disable_ it with procps.
[10:15] <pitti> keescook: then it should at least cry out very loudly, otherwise you could miss important things
[10:15] <cjwatson> so I see no reason why we can't do both
[10:15] <pitti> keescook: I agree to 'disable manually'
[10:15] <keescook> pitti: right, it already cries loudly, but just bombs out
[10:16] <iwj> cjwatson: both> Mmm, perhaps.
[10:16] <mdz_> keescook: that's a bug
[10:16] <cjwatson> I never knew it bombed out; I thought it was just a warning
[10:16] <cjwatson> I agree that's a bug
[10:16] <pitti> keescook: at least initially we probably have to carry the entire patch and not just the 'flip it on' bit, right?
[10:16] <keescook> mdz_, cjwatson: perhaps I am wrong; I will double check and open a bug if needed
[10:17] <iwj> We could give it a new flag --don't-mind-unknown-ctls.
[10:17] <cjwatson> it doesn't currently document that it minds
[10:17] <cjwatson> oh
[10:17] <cjwatson>        -e     Use this option to ignore errors about unknown keys.
[10:17] <mdz_> we could add a --don't-be-stupid
[10:17] <iwj> I mean, to even suppress the warning.
[10:17] <keescook> pitti: I have been trying to get stuff into mainline.  the maps protection is in 2.6.22, so we only need to carry the "on by default" patch (1 line)
[10:17] <iwj> cjwatson: Oh :-).
[10:17] <Keybuk> sysctl --i-agree-that-this-is-not-a-benchma-oh-wait
[10:17] <fabbione> ROFL
[10:17] <shawarma> :)
[10:18] <mdz_> cjwatson: that should be the default when reading from a file
[10:18] <Mithrandir> Keybuk: "acknowledge".  Have to weed out the lousy spelers.
[10:18] <cjwatson> keescook: from the source, I think you are mistaken that it bombs out
[10:18] <cjwatson> it does exit non-zero, but it keeps going round the loop anyway
[10:18] <keescook> If I can get enough time, I hope to have ASLR taken upstream, but applied in our kernel (/me begs BenC)
[10:18] <pitti> keescook: ah, that one, yes; I thought we would finally include the /tmp race protection and so
[10:18] <keescook> cjwatson: okay, sorry for that bit.  ignore my (2) above.  :)
[10:18] <iwj> /tmp race protection> What, the thing where creating without O_EXCL in sticky dirs fails ?
[10:19] <keescook> pitti: yup, I imagine many things
[10:19] <iwj> Or something else ?
[10:19] <mdz_> keescook: I think that modifying /etc/sysctl.conf is rare enough, and the consequences of the merge are trivial enough, that we don't need to worry about it
[10:19] <keescook> iwj: can't follow symlinks not owned by you in a +t dir
[10:19] <pitti> iwj: following a symlink in world-writable directories fails if it isn't owned by you
[10:19] <iwj> symlink> Ah, helps a lot.
[10:19] <keescook> mdz_: meaning these things should stay in procps?
[10:19] <pitti> simple 10-line patch and very effective
[10:19] <mdz_> keescook: I don't see a problem
[10:20] <keescook> mdz_: okay.
[10:20] <mdz_> keescook: it's not as if something breaks if they miss the merge
[10:20] <iwj> ln -s /somewhere /tmp/.X11-unix ...
[10:20] <iwj> Still, we can say "use mount --bind".
[10:20] <keescook> mdz_: it doesn't break, but it leaves them "open" to this minor issue
[10:20] <mdz_> keescook: ...which they're already open to and have been for 30 years :-)
[10:20] <pitti> iwj: lots of daemons and scripts still use things like /tmp/$$ or even static names, right
[10:21] <keescook> well, it hasn't mattered in 29 of those 30 years because everything was statically located in memory.  :)
[10:21] <Keybuk> iwj: don't bind-mount anything /ish to /tmp :p
[10:21] <keescook> so, since stack/heap ASLR, this is an issue.  once text ASLR is done, the maps file becomes very valuable
[10:21] <Keybuk> the guy who filed *that* bug is still stalking me
[10:22] <mdz_> keescook: but one is still no worse off than one has been in the paste
[10:22] <mdz_> past
[10:22] <mdz_> the worst that happens is that one misses out on a new bit of sticky gooey protective measure
[10:22] <keescook> anyway, sounds like the norm is to put kernel defaults into procps, which is the answer I was looking for.  :)  right, they're no worse off.
[10:22] <mdz_> next?
[10:23] <Keybuk> Where do Ubuntu's non-stock ulimits come from? (kees)
[10:23] <Keybuk> PAM
[10:23] <Keybuk> she's an air-hostess who does UNIX security work in her spare time
[10:23] <keescook> so, pam has compiled defaults?
[10:23] <Keybuk> yeah
[10:23] <mdz_> Keybuk: and keeps things from sticking to the skillet
[10:23] <cjwatson> it does, but they don't match those keescook cites
[10:23] <Keybuk> I think everything is unlimited
[10:23] <Keybuk> bar a few things
[10:23] <cjwatson> nproc is unlimited in pam_limits, for instance
[10:23] <pitti> right, a longstanding bug
[10:23] <cjwatson> whereas keescook says it's 2048
[10:24] <Keybuk> I think kees is advocating a limit, not advocating its removal?
[10:24] <cjwatson> oh, hang on, you mean it should be 2048
[10:24] <keescook> well, my list is from what the kernel hands init
[10:24] <mdz_> there's a very, very old bug about this
[10:24] <pitti> $ ulimit -u
[10:24] <pitti> unlimited
[10:24] <pitti> right, 'provide sane default ulimits' or so
[10:24] <cjwatson> mdz_: bug#?
[10:24] <mdz_> looking
[10:24] <keescook> and I've seen a few places where don't want unlimited signals, locked memory, or user process.  I need to study the POSIX msg queue more
[10:24] <cjwatson> 14505?
[10:24] <mdz_> it's something like "ZOMG UBUNTU VULNERABLE TO SHELL SCRIPT FORK BOMB"
[10:25] <Mithrandir> keescook: locked memory locked to 32kb sounds a bit on the slim side, though
[10:25] <mdz_> cjwatson: that's the one
[10:25] <keescook> Mithrandir: according to kernel comments, this is how much gnupg wants.  *shrug*
[10:25] <Mithrandir> keescook: hm, ok.
[10:25] <fabbione> we should be careful not to slam them too much down
[10:25] <keescook> but unlimited is clearly wrong it introduces yet another local DoS
[10:25] <cjwatson> keescook: feel free to poke pam (note that it uses a debian/patches-applied/ patch scheme)
[10:26] <cjwatson> agoliveira: yes
[10:26] <mdz_> Mithrandir: it's enough for a password, which is as much as any typical application wants
[10:26] <keescook> fabbione: are you aware of other things that lock mem?  I've been told that the binary video drivers need it, but I don't understand why/where
[10:26] <mdz_> would make a good soft limit at least
[10:27] <Keybuk> core 0, prio 0, sigpending 3072, memlock 32, nofile 1024, msgqueue 819200, rtprio 0, nproc 3072
[10:27] <Keybuk> (everything else unlimited)
[10:27] <fabbione> keescook: no, and since we don't have good samples, that's why i suggest to trigger them down slowly to see where we break
[10:27] <iwj__> Excuse me, I didn't see anything after    21:21 <Keybuk> the guy who filed *that* bug is still stalking me
[10:27] <Mithrandir> keescook: binary video drivers run as root anyway, I'd think?  Or do they mean GL memory is locked?
[10:27] <mdz_> keescook: seems like a good thing to switch early in the release cycle and see what breaks
[10:27] <cjwatson> iwj__: I'll /msg you the rest
[10:27] <iwj__> I seem to be having some local dsl difficulty.
[10:27] <kylem> keescook, if you use binary video drivers, security isn't one of your concerns...
[10:27] <mdz_> keescook: that's the best way to chase out the unexpected cases
[10:27] <keescook> Mithrandir: yeah, I'm not sure, I go poke at it with nvidia
[10:27] <mdz_> keescook: though a grep for mlock over the archive sources wouldn't hurt either
[10:27] <keescook> kylem: very good point.  :)
[10:27] <pitti> kylem: no, but if we have too restrictive defualt limits, their double-buffering etc. might break
[10:28] <kylem> pitti, seriously though, nvidia.ko has a "get root" ioctl...
[10:28] <pitti> kylem: yeah, and samsung printer drivers make your openoffice suid root
[10:28] <keescook> mdz_: so we maintain a set of unpack sources in the DC, or do I need to do a big step/unpack loop?
[10:28] <pitti> kylem: (no joke)
[10:28] <Mithrandir> pitti: that's the best thing ever.
[10:28] <kylem> pitti, ...
[10:29] <mdz_> keescook: we don't, afaik
[10:29] <fabbione> keescook: i have the space to do that here locally
[10:29] <cjwatson> kylem: bug 110724
[10:29] <ubotu> Launchpad bug 110724 in openoffice.org "OpenOffice runs as root for all users" [Undecided,Rejected]  https://launchpad.net/bugs/110724
[10:29] <mdz_> keescook: do yourself a favour and do it on a DC machine
[10:29] <keescook> and that bug has _duplicates_
[10:30] <keescook> fabbione: do I have access to "here"?
[10:30] <fabbione> keescook: i can provide that...
[10:30] <keescook> okay, cool
[10:30] <pitti> keescook: I still have some scripts to grep the sources of the entire archive
[10:30] <fabbione> keescook: or use the DC.. up to you.. just let me know
[10:30] <keescook> anyway, what do people think of the 2048 user process limit?
[10:30] <mdz_> pitti: that should go in a package somewhere
[10:30] <fabbione> keescook: that will break my builds
[10:30] <iwj__> ~~
[10:30] <mdz_> keescook: I think it's perfectly reasonable
[10:30] <iwj> Excuse me.
[10:31] <keescook> yeah, i'll raise it for myself, but for an ubuntu default, it seemed better than unlimited.  :)
[10:31] <mdz_> fabbione: make -j should fail gracefully; if it doesn't, it should be fixed
[10:31] <pitti> mdz_: well, it only ever makes sense on the DC, and the scripts currently need hand-editing, but I'll look at generalizing them and maybe put them into devscripts or so
[10:31] <mdz_> not even fail gracefully. cope, rather
[10:31] <Keybuk> keescook: the default is 3072, why lower it?
[10:31] <fabbione> mdz_: ehhehe :)
[10:31] <keescook> Keybuk: your init values differ from mine a bit.  we'll compare notes later?
[10:31] <pitti> keescook: fabbione's 'make -j 300' is not what I really call 'reasonable default for normal users' anyway :)
[10:32] <Keybuk> keescook: I'm just reading from gdb before upstart's main loop <g>
[10:32] <pitti> Keybuk: default is unlimited for nproc
[10:32] <keescook> neither is my use of LVM.  :)
[10:32] <fabbione> pitti: nah.. that's history.. i am at an average of -l 4096
[10:32] <fabbione> -j even
[10:32] <keescook> Keybuk: ah, I booted with init=/bin/bash and did "ulimit -a"  :P
[10:32] <cjwatson> fabbione: I think you can raise your ulimits
[10:32] <Keybuk> keescook: what's the reason for wanting to apply limits anyway?
[10:32] <Keybuk> for a single-person machine, surely unlimited *is* the right default?
[10:32] <fabbione> cjwatson: yeah i guess i will have to
[10:33] <keescook> mostly local DoSs
[10:33] <Keybuk> why do we want to place limits on what an Ubuntu user can do
[10:33] <keescook> Keybuk: ^^
[10:33] <pitti> Keybuk: making processes which are gone wild not block the entire system
[10:33] <Keybuk> they'll have the same ffect
[10:33] <keescook> the aim is slightly more towards safer server installs
[10:33] <Keybuk> process goes wild => machine can't spawn new process to fix it
[10:33] <Keybuk> process goes wild and hits limit => still can't spawn new process
[10:33] <mdz_> Keybuk: bulletproof shoes
[10:33] <keescook> and these were a few things that stood out when comparing ubuntu defaults to other distros
[10:33] <pitti> Keybuk: they can, on a new console
[10:33] <Keybuk> mdz: I prefer paper bullets
[10:33] <pitti> Keybuk: AFAIK, nproc is per console, isn't it?
[10:34] <Keybuk> pitti: and how do we explain "new console" to non-server users?
[10:34] <mdz_> pitti: I don't think so
[10:34] <Keybuk> pitti: no
[10:34] <Keybuk> nproc is global
[10:34] <cjwatson> setrlimit(2) says it's per-uid
[10:34] <keescook> anyway, sounds like "yes, hunt and fix, culprit is PAM".
[10:34] <Keybuk> (remember, no root password, guys!)
[10:34] <pitti> ah, 'k; sorry for misremembering then
[10:34] <Keybuk> no logging in as root and killing the run-away process
[10:34] <cjwatson> Keybuk: I think they're screwed either way
[10:34] <Keybuk> cjwatson: exactly, so why limit users from doing legitimate things with no gain here?
[10:34] <cjwatson> I'm not sure that we gain a whole lot by taking away the lubricant
[10:35] <cjwatson> er, I mean I'm not sure that we lose a whole lot
[10:35] <cjwatson> Keybuk: legitimate users who need that can raise the limit, no?
[10:35] <keescook> I think it marginally helps multiuser systems.
[10:35] <Keybuk> does nproc cover processes or processes *and* threads?
[10:35] <pitti> Keybuk: anyway, right now the bash fork bomb instantly freezes the entire system; it can only get better
[10:35] <keescook> Keybuk: unsure about threads
[10:36] <cjwatson> I think there are much fewer of them, and that they're much more knowledgeable, than those who get screwed by accidental or malicious forkbombs
[10:36] <Keybuk> cjwatson: will we provide a gui to increase the limit?
[10:36] <pitti> gvim limits.conf (SCNR)
[10:36] <Keybuk> (I'm firmly a "0, 1 or unlimited" kinda man, sorry)
[10:36] <cjwatson> do you think that users who need several thousand concurrent processes require a gui?
[10:36] <bryyce> heh
[10:36] <Keybuk> cjwatson: I think that nprocs includes threads
[10:36] <pitti> well, '1' is not that bad either; worked fine in DoS :)
[10:36] <cjwatson> even so
[10:36] <pitti> erm, DOS
[10:37] <cjwatson> (yes, threads too)
[10:37] <mdz_> we do have the option of setting different defaults for server and desktop
[10:37] <mdz_> and more restrictive limits do make sense for servers
[10:37] <fabbione> that would be more sensible
[10:37] <Keybuk> yeah, I agree that this is right for server
[10:37] <Keybuk> just not desktop
[10:37] <Keybuk> desktops are by definition hundreds of processes with lots of threads each
[10:37] <keescook> Keybuk: you're speaking specifically about nproc?
[10:37] <pitti> but if we use sysctl.conf, we have to agree to a common limit
[10:37] <cjwatson> $ ps x | wc -l
[10:37] <cjwatson> 110
[10:38] <cjwatson> this is a factor of at least 20 or so we're talking about?
[10:38] <keescook> pitti: I think they'd go in /etc/security/limits.conf in the end
[10:38] <cjwatson> I'm not convinced, I'm afraid
[10:38] <Keybuk> cjwatson: i just don't see the gain in changing it
[10:38] <mdz_> anything less than the maximum pid is an improvement
[10:38] <Keybuk> you're still screwed by a fork bomb
[10:38] <Keybuk> so what's the difference?
[10:38] <mdz_> Keybuk: not on a server
[10:38] <mdz_> where there are non-admin users
[10:38] <pitti> for me the gain is that right now you are definitively screwed on a fork bomb; with a limit you at least have a chance to recover
[10:39] <keescook> pitti: +1
[10:39] <cjwatson> at least accidental forkbombs may well stop and give you your system back once they hit the limit
[10:39] <Keybuk> cjwatson: you forgot the "m"
[10:39] <Keybuk> ps won't show threads by default these days
[10:39] <mdz_> Keybuk: I don't think nproc applies to threads anyway
[10:39] <cjwatson> a forkbomb that chews through your pid space will likely cause the OOM killer to kick in and then bits of your desktop start to disappear
[10:39] <cjwatson> Keybuk: given that most of my processes are non-threaded terminals, that's specious
[10:40] <Keybuk> cjwatson: more likely the fork bomb will keep pushing against the limit, and you have to reboot
[10:40] <Lure> mdz_: it does (according to setrlimit(2) manpage)
[10:40] <mdz_> Lure: is that pre- or post-NPTL?
[10:40] <Keybuk> nproc is counted for each clone(), no?
[10:40] <mdz_> date on the man page is 2005
[10:41] <cjwatson> I have 110 processes and 124 threads
[10:41] <mdz_> keescook: this is becoming a discussion which needs to be had on the mailing list
[10:41] <mdz_> we need to move on
[10:41] <keescook> mdz_: sure thing.  sounds like only nproc is contentious
[10:41] <mdz_> pitti: release update?
[10:42] <pitti> mdz_: it's out :)
[10:42] <mdz_> pitti: wow! way ahead of schedule
[10:42] <cjwatson> pitti: congratulations on Ubuntu 7.10, then
[10:42] <pitti> went pretty smooth, although I had to learn and struggle a lot with learning the engineering bits
[10:42] <mdz_> we were planning on october
[10:42] <agoliveira> :-D
[10:42] <mdz_> pitti: you should have a chat with heno about release-relevant bug tracking
[10:43] <pitti> mdz_: right, that's on the list already
[10:43] <pitti> so far we have about 5 or 6 for tribe-2
[10:43] <pitti> and a few for later versions
[10:45] <Keybuk> fabbione: how is the hardware certification proceeding?
[10:45] <fabbione> Keybuk: started as scheduled.. no bugs so far but it's a bit early to say
[10:46] <fabbione> we are going to skip sparc for this round
[10:46] <fabbione> i found a last minute blocker
[10:46] <fabbione> and agreed with pitti to not release it
[10:46] <fabbione> but we have fixes on the way already
[10:47] <fabbione> that's about it from radio hardware-cert
[10:47] <fabbione> :)
[10:47] <mdz_> I think it would be good to publicize the test results from tribe-1 sometime before tribe-2
[10:47] <mdz_> on -devel or -devel-announce
[10:47] <mdz__> I just got randomly dropped from the wireless network
[10:47] <mdz__> I think it would be good to publicize the test results from tribe-1 sometime before tribe-2 on -devel or -devel-announce
[10:48] <cjwatson> merges: we have 30 outstanding, which need to be completed by 21st June
[10:48] <cjwatson> that's excellent progress for this point in the cycle, but we just need to get through the last few
[10:48] <fabbione> mdz_: did someboby pasted to you?
[10:48] <mdz_> fabbione: no
[10:49] <heno> we need to add a feature to the USO tracker to make such reporting efficient
[10:49] <heno> Should be fairly easy to do
[10:49] <heno> *ISO tracker
[10:50] <bryyce> cjwatson: should the Updated Merges also be completed by the 21st?
[10:50] <pitti> bryyce: there will constantly be new ones
[10:50] <mdz_> bryyce: those are packages which have been updated since they were merged
[10:50] <pitti> those should be picked with some common sense applied, I think
[10:50] <bryyce> ok
[10:51] <mdz_> we can't be exactly up to date at the deadline, but we should be close enough
[10:51] <cjwatson> bryyce: no
[10:51] <mdz_> everything must be merged at least once
[10:51] <Keybuk> ish
[10:52] <Keybuk> those are packages which have been *uploaded* since the start of the release cycle
[10:52] <Keybuk> they may have never been merged
[10:52] <Keybuk> check versions
[10:52] <cjwatson> right, I know grub is in that camp
[10:53] <Keybuk> (it parses the changes file and looks at the intended distribution <g>)
[10:53] <Keybuk> if the last change was for the current release, it goes in updated rather than new
[10:53] <cjwatson> to clarify, we can still upload merges after the Debian import freeze, up to upstream version freeze; we just won't automatically sync every day or so
[10:53] <cjwatson> (if that confused you, ask me out of band and I'll be happy to clarify)
[10:53] <mdz_> speaking of grub, /me mumbles about bug 21412
[10:53] <ubotu> Launchpad bug 21412 in grub "Default update-grub behaviour is not intuitive with respect to user modifications" [Medium,Confirmed]  https://launchpad.net/bugs/21412
[10:54] <mdz_> that bug needs to die.  who will speak for the trees?
[10:54] <Keybuk> (and I tend to turn a switch at DIF to change the word from "Outstanding" to "New" :p)
[10:55] <mdz_> it's bitten countless users and sysadmins, and now it's bitten Dell as well
[10:55] <mdz_> heno: let us make gutsy the release where it finally dies
[10:55] <Keybuk> is that the "you need to edit the comments?" bug
[10:55] <cjwatson> please check with me about installer implications; it's fiddly :-/
[10:55] <mdz_> Keybuk: yes
[10:56] <mdz_> cjwatson: might be a good idea to note that in the bug itself
[10:56] <cjwatson> it is a bug that requires careful design to make sure the result isn't just as bad
[10:56] <mdz_> in case the bug fairy comes by to fix it and wasn't in this meeting
[10:56] <mdz_> speaking of meetings, is there any other business for this one?
[10:56] <cjwatson> done
[10:57] <ogra> :)
[10:57] <mdz_> going once
[10:57] <mdz_> twice
[10:57] <mdz_> thrice...gone.  good night and good day and back to the battlefield with ye
[10:57] <bryyce> for those curious, here's some photos of current bulletproof-x status:  http://people.ubuntu.com/~bryce/BulletProofX/
[10:57] <bryyce> night!
[10:57] <keescook> thanks everyone!
[10:57] <mdz_> thanks, everyone
[10:57] <asac> thanks!
[10:57] <Mithrandir> that leaves me with a whooping three minutes until next meeting. :-P
[10:57] <bdmurray> bye!
[10:57] <evand> thanks
[10:57] <dholbach> thanks
[10:57] <iwj> Goodnight all.  Hmm, I should sleep on that bug.
[10:57] <fabbione> night all
[10:57] <ogra> thanks :)
[10:57] <mathiaz> thanks. bye.
[10:58] <mvo> goodnight
[10:58] <pitti> thanks all
[10:59] <nixternal> @schedule chicago
[10:59] <ubotu> Schedule for America/Chicago: Current meeting: Ubuntu Development Team | 12 Jun 10:00: Kernel Team | 13 Jun 07:00: Edubuntu | 14 Jun 11:00: Ubuntu Development Team | 16 Jun 12:00: Xubuntu Developers | 19 Jun 14:00: Technical Board
[10:59] <cjwatson> bryyce: nice start!
[10:59] <bryyce> thanks :-)
[11:00] <pitti> bryyce: cool
[11:00] <pitti> that, and friendly-recovery as yet another fallback will make it much better
[11:00] <cjwatson> bryyce: I have various minor quibbles but it sounds like you want to get further before taking those, and I probably shouldn't distract you with irrelevant bits :)
[11:01] <bryyce> yeah I am going to hammer on it more
[11:02] <bryyce> btw, I'm thinking the right place for this to live is as a patch on gdm - does that sound reasonable?
[11:03] <pitti> bryyce: hm, either that or the place which currently produces those broken blue screens?
[11:03] <pitti> bryyce: with gdm you'd have to do it for all dms
[11:03] <pitti> like kdm and the XFCE one at least
[11:03] <bryyce> I'm guessing the blue screens are generated by xorg-server itself
[11:03] <pitti> right, Xorg should notice if it couldn't start up
[11:04] <bryyce> yeah, unfortunately this approach relies on a gdm hook that kdm doesn't have (haven't looked at xmms yet)
[11:04] <pitti> xmms? :)
[11:04] <bryyce> er
[11:04] <bryyce> xfce ;-)
[11:04] <pitti> autofingers
[11:04] <bryyce> zactly
[11:05] <pitti> bryyce: why is it significantly easier to hack this into gdm than into X?
[11:05] <bryyce> I don't have strong feelings either way
[11:05] <bryyce> I figured gdm since it hooks in via the gdm.conf file
[11:06] <bryyce> however it isn't really gdm specific other than the hook
[11:06] <bryyce> so putting it in xorg-server might make sense if/when we can also hook into kdm.  hmm
[11:06] <pitti> bryyce: I figure eventually it can call kde-guidance on Kubuntu and such?
[11:07] <bryyce> yup
[11:07] <pitti> it could just check which is available and pick the first
[11:07] <shawarma> Well, both zenity and displayconfig-gtk are not going to work all that well on a Kubuntu system anyway?
[11:07] <pitti> and if nothing's there, just call dpkg-reconfigure -phigh xserver-xorg :)
[11:07] <bryyce> shawarma: shouldn't matter
[11:07] <shawarma> bryyce: right, just read the bit about kde-guidance..
[11:07] <pitti> shawarma: right, but guidance should; after all, displayconfig-gtk was ported from KDE :)
[11:07] <bryyce> we're not loading the window manager proper at all
[11:07] <shawarma> pitti: Oh, really? I didn't know.
[11:08] <bryyce> however, I do like the idea that the dialog used for configuring in failsafe is the same as when they're logged into whatever they normally use
[11:08] <pitti> shawarma: yeah, it sometimes happens in this direction, too
[11:08] <bryyce> since things will look the same, etc.
[11:08] <pitti> bryyce: right, merely checking for which one is available will not be 100% right, but it's a fine start
[11:08] <bryyce> yeah displayconfig-gtk and kde's displayconfig both use the guidance_backends package
[11:09] <pitti> the latter was recenlty split out; yay no more code duplication :)
[11:09] <bryyce> for now I'm just focusing on the gnome/ubuntu, to keep it simple.  I think it should be straightforward to adapt it to other window managers once the basics are proven
[11:10] <pitti> right, it just needs to be kept in mind
[11:10] <bryyce> most of the hard work is going to be in getting it to boot up reliably on any random piece of hardware
[11:10] <bryyce> pitti, yup!  Unfortunately, presently installing guidance_backends pulls in a bunch of Qt libs too
[11:10] <pitti> bryyce: how good does the 'no xorg.conf' mode work currently?
[11:10] <bryyce> pitti, works great
[11:11] <pitti> yuck @ qt libs
[11:11] <pitti> I was planning to use that for restricted-manager
[11:11] <bryyce> pitti, a lot of systems I've tested it on came up just fine
[11:11] <pitti> cool, I gotta try that
[11:12] <pitti> it'll give me the wrong resolution, but still
[11:12] <bryyce> but when you want custom stuff - extra font paths, binary drivers, different keyboard layouts, etc. then obviously that's a problem
[11:12] <pitti> keyboard layout is the worst thing probably
[11:12] <bryyce> however I understand xserver 1.3 will accept partial xorg.conf's, where you leave display/device/etc. empty and just specify stuff you wish to override
[11:12] <pitti> but as long as you can drive the recovery with the mouse, its probably ok
[11:12] <bryyce> but I haven't tested that out
[11:13] <bryyce> xserver 1.4 is going to have input hotplug as well, so maybe many of these customizations will not be needed either
[11:13] <Riddell> bryyce: that should be fixed no?
[11:13] <pitti> Depends: libc6 (>= 2.5-5), libx11-6, libxext6, libxrandr2 (>= 2:1.2.0), libxrender1, libxss1, libxxf86vm1, python (>= 2.5), python-support (>= 0.3.4), python (<< 2.6)
[11:13] <pitti> looks fine to me
[11:13] <pitti> (guidance-backends)
[11:14] <bryyce> ok hmm
[11:14] <Riddell> it's a recent fix
[11:14] <cjwatson> partial xorg.conf - it pretty much has to, that's going to be the common case :)
[11:14] <bryyce> ahh, I must have grabbed before that
[11:14] <pitti> Riddell: btw, would you mind if I put my spacing fix there?
[11:14] <bryyce> cjwatson: yup
[11:14] <pitti> Riddell: it changes the tabs/spacing to be like the one dexconf writes
[11:14] <Riddell> pitti: what does that do?
[11:15] <Riddell> pitti: hmm, ask _Sime_ first, he's the upstream
[11:15] <pitti> but just that, no functional changes
[11:15] <pitti> Riddell: it's probably not appropriate for upstream, since that's a distro-level custom
[11:15] <pitti> but sure, I'll ping him
[11:15] <cjwatson> so if I have xserver 1.3 installed, can I just delete the Device, Monitor, and Screen sections and let it try to guess?
[11:16] <Riddell> pitti: actually ignore me, we discussed that patch before in #k-d and it's fine to apply
[11:16] <pitti> Riddell: cool, then I'll do that and throw out the copy from r-m
[11:16] <bryyce> cjwatson: or delete their contents
[11:17] <bryyce> cjwatson: ah yeah it looks like you can delete the contents entirely
[11:18] <bryyce> still need the ServerLayout section though
[11:18] <bryyce> Section "ServerLayout"
[11:18] <bryyce>   Identifier "Default Layout"
[11:18] <bryyce>   InputDevice "Generic Keyboard"
[11:18] <bryyce>   InputDevice "Configured Mouse"
[11:18] <bryyce> EndSection
[11:18] <cjwatson> but delete the Screen line from ServerLayout?
[11:20] <bryyce> yup
[11:23] <pitti> good night everyone
[11:23] <bryyce> cya