[00:27] <Impulse__> Evening y'all
[00:29] <Impulse__> anyone that can help me with a question?
[00:31] <Patrickdk> !ask
[00:31] <Patrickdk> so, no, I don't think anyone can
[00:31] <Impulse__> ow, okay then :-)
[00:33] <brrr> !patience
[00:33] <Impulse__> Eurhm, i'm looking for a web gui based interface for my server/ main functionality is to monitor my disks, add disks, copy files etc
[00:33] <Patrickdk> good luck on that
[00:33] <Patrickdk> !ebox
[00:34] <Patrickdk> forget the others
[00:34] <Patrickdk> is extreemly rare, if those work at all
[00:34] <Impulse__> is it that good? because i've read and tryed Webmin but not what i need
[00:35] <Patrickdk> !webmin
[00:36] <Impulse__> mhm... well, the problem with webmin was to add a new fysical disk, can it be done with zentyal without any prob or?
[00:36] <Patrickdk> I wouldn't know
[00:36] <Patrickdk> it's pretty simple to just add a disk, via cli
[00:36] <Patrickdk> no need for some web based program to do it for you
[00:38] <Impulse__> true, the other thing i need is a samba server so that my laptop can acces the files, most of it only 2 VM's and my xbmc need to acces the files. The prob i have is that i come from a windows server, so the disks are NTFS formated. Only 1 is new, so that i can copy everything to the new disk, and then format the old one
[08:45] <jonascj> Hi all. I am trying to rename my ethernet cards so they will have persistent meaningful names. I am trying to name them based on bus position. This is what I've done to get the bus positions and what my /etc/udev/rules.d/70-persistent-net.rules looks like: http://paste.linuxassist.net/view/f0087a7e
[08:46] <jonascj> Done with inspiration from here: http://www.linuxfromscratch.org/blfs/view/development/chapter07/network.html
[08:46] <jonascj> but upon reboot my nics are still not named "onboard" and "pci"
[08:46] <jonascj> What can cause the rules not to apply? The rules-file have the execute bit set...
[09:17] <henkjan> https://lists.ubuntu.com/archives/ubuntu-server/2014-July/006934.html
[09:18] <henkjan> al those 3.13 issues :'(
[09:22] <cfhowlett> henkjan roll back to an earlier kernel ...
[09:23] <henkjan> cfhowlett: i installed newer kernels
[09:25] <cfhowlett> henkjan or that :)
[09:26] <henkjan> just amazing that 3.13 passed qualite assurance
[09:30] <lordievader> It's strange Trusty doesn't get 3.14, since that one got a longterm status now.
[09:34] <jonascj> Where should I expect to see udev log output?
[09:35] <jonascj> in /var/log/syslog or /var/log/dmesg?
[09:36] <jonascj> I have the level to debug in /etc/udev/udev.conf, rebuild initramfs (like udev.conf says I need to) with "update-initramfs -u", but upon reboot /var/log/syslog conatains not a single occurence of 'udev' and /var/log/dmesg only contains 'udev' four times (for renaming two nics). I would have expected more from debug log level
[09:46] <jonascj> hmm the log is apparently /var/log/udev :$
[12:54] <hxm> exists something like git but simpler?
[12:57] <Pici> err... there are a number of different version control systems out there.  git is pretty simple imo.
[12:59] <Chris_hubu> hxm, there is subversion too, but git is the most popular/democratized, you might want to learn how to use it, it's pretty powerful
[13:08] <gnuoy> stgraber,hi, I'm looking at merging  2.15-1 of nagios-nrpe from debian and I see we're carrying a patch to remove the use of urandom ( http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/nagios-nrpe/utopic/view/head:/debian/patches/01_nodevrandom-and-docoptions.dpatch ). Do you happen to know why that is?
[13:11] <stgraber> gnuoy: nope
[13:12] <gnuoy> stgraber, ok, thanks
[13:21] <ashd> can someone tell my what re-creates ldap.conf file on reboot?
[13:28] <pmatulis> ashd: by default, nothing
[15:16] <gnuoy> rbasak, I've raised a bug with debian for the lack of vcs fields in the debian/control file for nagios-nrpe. I'm now looking at why we carry this patch to remove the use of urandom. I've found some discussion on the subject. The patch was introduced by the debian maintainers in response to Bug 333552 . Why it was removed again is a bit of a mystery, I see discussion on the subject for Bug 660585 but the conclusion seems to be a rejection of the re
[15:16] <gnuoy> quest to remove the patch. I'm not sure what I should do from here
[15:17] <rbasak> gnuoy: thank you for finding those! It seems to me that this change affects behaviour but no other interface to the user, so there wouldn't be any regression to the user (eg. break scripts) whatever we chose to do. Does this seem accurate to you?
[15:18] <gnuoy> rbasak, yes, thats my understanding, it only changes the way the seed is generated
[15:18] <rbasak> gnuoy: IMHO, for the issue itself, I don't think it's for a package maintainer to change the behaviour like this. The original bug should have been forwarded upstream.
[15:19] <gnuoy> that makes sense
[15:19] <gnuoy> that would suggest we should loose the patch then ?
[15:19] <rbasak> gnuoy: and I don't buy the /dev/random running out of entropy thing. There has been much news recently about packages that should use urandom; using /dev/random over /dev/urandom at any time apart from boot time is purely academic, AIUI.
[15:20] <rbasak> gnuoy: so yes - I'd do whatever Debian do here to minimize our maintenance burden and so that users are less confused about any difference in behaviour.
[15:20] <rbasak> gnuoy: best to document this rationale in the changelog message thoughl.
[15:21] <gnuoy> rbasak, absolutely. Thanks for the advice, that makes sense to me
[15:21] <rbasak> gnuoy: no problem. It may be that there's some case that consequently breaks because something new blocks for entropy, but if that happens we can deal with that when we have more data. Especially as we can make a change without impacting the user at all.
[15:22] <gnuoy> kk
[16:56] <blopxop> any idea how to run bash command ~/.profile with root privilege without giving the user full right to said command?
[17:00] <hallyn_> anyone hanging out here who is a part of openvswitch upstream?
[18:47] <yossarianuk> hi - is anyone aware what I need to do to get ipv4+ipv6 working in a KVM bridge ?
[18:49] <patdk-wk> absolutely nothing :)
[18:49] <yossarianuk> patdk-wk: i.e out the box (as long as you have ipv6 connection) it should be enabled ?
[18:49] <patdk-wk> yes
[18:49] <patdk-wk> even if you don't have an ipv6 connection
[18:50] <yossarianuk> i.e br0 should show the inet6 address with ifconfig , etc ?
[18:51] <yossarianuk> patdk-wk: thanks
[18:51] <patdk-wk> heh?
[18:51] <patdk-wk> br0?
[18:52] <bitfury> !info icinga
[18:52] <patdk-wk> only if your host machine uses ipv6, had nothing to do with the kvm bridge or the kvm guest
[19:23] <bitfury> hi, if I wanted to install a package from the universe repo how would I specify this with apt-get?
[19:24] <lordievader> bitfury: Is the universe repo enabled?
[19:25] <bitfury> yep
[19:25] <bitfury> reading through the apt-get manual, looks like I could just specify a package's version
[19:25] <bitfury> thinking that would yield the same result
[19:26] <lordievader> bitfury: sudo apt-get install <package-name>, or alternatively, if you want more info about the package: sudo apt-cache show <package-name>
[19:26] <bitfury> lordievader: wouldn't that download and install the one in main?
[19:26] <bitfury> I remember you could specify a repo to use
[19:27] <lordievader> bitfury: For as far as I know, packages can be in one repo only. What package are we talking about here?
[19:27] <bitfury> lordievader: icinga
[19:27] <lordievader> !info incinga
[19:27] <lordievader> !info icinga
[19:28] <lordievader> bitfury: That lives in universe, like you said. It is not in other repos.
[19:29] <bitfury> lordievader: https://launchpad.net/ubuntu/+source/icinga/1.11.5-1
[19:29] <bitfury> that's universe as well no?
[19:32] <lordievader> bitfury: That is the source of the package. And there is mention of Utopic's Universe.
[19:35] <bitfury> lordievader: Ok got it. So If I add a maintainers PPA and do a apt-get install <package-name> it will get it from there?
[19:36] <lordievader> bitfury: If they have a newer version and equal priority is given to the repos, yes.
[19:36] <bitfury> that is if the package name is the same as in main
[19:38] <bitfury> lordievader: got it, thanks for clarifying
[19:38] <lordievader> bitfury: No problem ;)
[20:15] <bitfury> !info munin