[00:06] <antarus> it was good last time I used it
[14:34] <psivaa> cjwatson: xnox: I would like to know which is the correct default  %sudo in sudoers file:
[14:35] <psivaa> "%sudo ALL=(ALL:ALL) ALL" vs "%sudo ALL=(ALL:ALL) NOPASSWD: ALL"
[14:37] <xnox> psivaa: $ apt-get download sudo; dpkg-deb -R /tmp/foo; grep sudo /tmp/foo/etc/sudoers => says it's the former.
[14:38] <xnox> dpkg-deb sudo*.deb -R /tmp/foo
[14:38] <cjwatson> $ apt-get download sudo >/dev/null && dpkg --fsys-tarfile sudo_*.deb | tar xO ./etc/sudoers | grep %sudo; rm sudo_*.deb
[14:38] <cjwatson> %sudo   ALL=(ALL:ALL) ALL
[14:38] <cjwatson> haha, snap
[14:39] <xnox> apart from i'm still struggling to correctly type stuff =)
[14:39] <xnox> dpkg-deb -R sudo*.deb /tmp/foo
[14:41] <psivaa> xnox: cjwatson: ok, i *appear to see that it's different in between saucy and trusty. but could not confirm it yet.
[14:41] <cjwatson> Doubt it
[14:41] <psivaa> trusty has it without NOPASSWD certainly
[14:41] <xnox> psivaa: it's a conffile, so local modifications may have been preserved and/or upgrades are done different.
[14:42] <cjwatson> $ schroot -c saucy-i386 -- apt-get download sudo >/dev/null 2>&1 && dpkg --fsys-tarfile sudo_*.deb | tar xO ./etc/sudoers | grep %sudo; rm sudo_*.deb
[14:42] <cjwatson> %sudo   ALL=(ALL:ALL) ALL
[14:42] <xnox> psivaa: are you looking at a cloud image pephaps?
[14:42] <psivaa> xnox: this is a netboot installation
[14:42] <cjwatson> Right.  This is only interesting if you're looking at a fresh install with no weird stuff.
[14:42] <psivaa> yep, I'll do that. thanks :)
[14:42] <cjwatson> The installer has never set NOPASSWD
[14:44] <xnox> psivaa: dpkg-query -W -f='${Conffiles}' sudo
[14:44] <ogra_> does the installer still set up the admin group in there ?
[14:44] <xnox> psivaa: will give you md5sum of /etc/sudoers. And you can do $ sudo md5sum /etc/sudoers.
[14:45]  * ogra_ just noticed that we have a line for it in the touch install 
[14:45] <xnox> psivaa: if they are different somebody locally modified it.
[14:45] <xnox> psivaa: (one way or the other, but dpkg did not install that version that you see on disk)
[14:46] <xnox> ogra_: "%admin ALL=(ALL) ALL" is in /etc/sudoers. Is that what you mean?
[14:46] <ogra_> xnox, yes
[14:46] <ogra_> i thought we dont need it anymore
[14:46] <ogra_> (on fresh installs)
[14:47] <psivaa> ogra_: xnox: cjwatson just entered a meeting, will update once i finish that :)
[14:47] <cjwatson> admin's for back-compatibility
[14:48] <ogra_> right, so touch shouldnt need it
[14:51] <ogra_> root@ubuntu-phablet:/# grep admin /etc/group
[14:51] <ogra_> root@ubuntu-phablet:/#
[14:51] <ogra_> heh yeah i think thats pretty safe :P
[14:51] <ogra_> one hack less :)
[15:04] <psivaa> xnox: I know that the file is being modified anyway, but afaik, it's in the %admin line. im starting new installs now
[15:07] <xnox> psivaa: ok. it's best to drop snippets into /etc/sudoers.d/ then it's clear what's default & what's custom.
[15:08] <psivaa> xnox: ack, will try and include that step
[15:35] <bdmurray> xnox: could you have a look at my mp for bug 1051935? https://code.launchpad.net/~brian-murray/ubiquity/bug-1051935/+merge/194262
[15:35] <ubot2> Launchpad bug 1051935 in ubiquity (Ubuntu Saucy) "Fails with SystemError when too many files are open" [Undecided,Confirmed] https://launchpad.net/bugs/1051935
[15:36] <xnox> bdmurray: yeap, looks good. will merge after the meeting.
[17:01] <psivaa> cjwatson: xnox: ok, so the fresh install has not set NOPASSWD for sudoers.. Just found that it was a configuration setting that changed it later. thanks for the clarification though :)
[18:32] <cydizen> hello hello ubuntu-installer! -  I'm working with a customer who is using a kickstart file for automatic installation, which mostly works except when 'part' creates the final partition it grows the partition size to the remainder of the available disk. (regardless of what the maxsize is set at).    Does anyone have any suggestions for working around this?   (or perhaps this is a bug)  Thank you -
[18:42] <cjwatson> It's a long-standing bug; the best workaround is to add a dummy filler partition and delete it at the end.
[18:42] <cydizen> That's the road I was going down, thank you cjwatson
[20:05] <mwharris> im trying to troubleshoot a problem with the installer where my hostname is set to my numeric IP instead of the dhcp-provided hostname
[20:05] <mwharris> where exactly in the installer is the hostname set?
[20:05] <mwharris> it seems like dhclient isn't changing it
[21:23] <antarus> mwharris: the hostname is preseeded...?
[21:23] <antarus> mwharris: maybe grep for that in teh src
[21:29] <infinity> mwharris: do you have broken reverse DNS on your network that returns your IP for the reverse of your IP?
[22:15] <mwharris> antarus: yeah preseeded hostname was my first thought
[22:15] <mwharris> but even then i would expect dhclient to change it
[22:15] <mwharris> infinity: the network should be set up correctly with rdns
[22:16] <mwharris> i do see the preseed netcfg/get_hostname is set to the bad address
[22:16] <mwharris> (this is after the failed install)
[22:16] <mwharris> (but still in d-i)
[22:21] <mwharris> that debconf value is set by netcfg dhcp, not preseeded.
[22:22] <infinity> mwharris: Like I said, usually from reverse DNS.
[22:23] <infinity> Though, also from dhcp, depending.
[22:23] <infinity> So, either your nameserver's returning bogus info, or your dhcp server is.
[22:23] <xnox> mwharris: we default from dhcp, if we don't get one a generic one is used. If you don't like it - preseed your own ahead of time, or fix network.
[22:24] <mwharris> looking at /var/lib/dhcp/dhclient.leases, "option host-name" is correct
[22:25] <mwharris> should dhclient set the hostname in that case?
[22:26] <mwharris> or would it do a reverse lookup first?