=== tyhicks` is now known as tyhicks
=== danwest is now known as danwest-holiday
=== m1dnight1 is now known as m1dnight_
[07:06] <vivek_> hello all, is there a way to setup default quota limits for each new user that gets created in the system on ubuntu server?
[07:17] <repozitor> is there any idea why my firewall doesn't work?
[07:17] <repozitor> i installed firewall-cmd and now it's status is running, rules are fine
[07:17] <repozitor> but some denied port are open from outside of server
[07:17] <repozitor> for example nmap show me 587 is open, but i expect firewall-cmd should deny it
=== Lcawte|Away is now known as Lcawte
[07:45] <ankitkulkarni> Hey Guys, I have to create myown distributable ubuntu iso so that I can install it again on my own pc using a pendrive . I have tried distroshare, pinguy builder , remastersys(although not available now for 14.04)  . Iso are created but no luck in installing them . I created 14.04 iso , it was of 2.2 gb around but takes lot of time to install . Normal ubuntu would take only few minutes while the distroshare one takes hours to install . Any
[07:45] <ankitkulkarni> good way to create small distributable iso from my current installation .
[07:57] <ikonia> I'd look at what in the process is taking time to install and why
[07:57] <ikonia> and define " a lot of time "
[07:58] <ikonia> a default install is actually very small, and if you're installing 2.2GB media it will take longer
[08:07] <ankitkulkarni> ikonia, yeah . "a lot of time "  is actually different when created with different method . From distroshare it takes almost 3+ hours to install the system .  With remastersys it stucked on choosing the install option .
[08:08] <ankitkulkarni> ikonia, I will try to debug what process exactly is taking time
[09:35] <lordievader> Good morning.
=== Lcawte is now known as Lcawte|Away
=== Lcawte|Away is now known as Lcawte
=== dosaboy_ is now known as dosaboy
=== Lcawte is now known as Lcawte|Away
[15:31] <teward> anyone know a way to migrate a dovecot install completely from one server to another?
[15:31] <teward> it's on an old 9.10 server, now, trying to migrate it to a 14.04 server, but i'm getting dovecot auth issues :/
[15:32] <teward> (and yes I know 9.10 is old, but i'm not asking for help with that part, merely migrating it to a 14.04 system)
[15:41] <Montgallet> http://serverfault.com/questions/105804/how-can-i-migrate-dovecot-from-one-server-to-another
[15:42] <Montgallet> migrate dovecot to postfix possible too google search
[15:43] <teward> erm, i'm trying to migrate dovecot -> dovecot
[15:43] <coreycb> jamespage, keystoneauth1 has an optional dependency on requests-kerberos as a plugin, which I'm considering moving to Suggests in d/control instead of MIRing python-requests-kerberos
[15:43] <jamespage> coreycb, that sounds sensible
[15:43] <coreycb> jamespage, ok
[15:44] <teward> Montgallet: what's unclear from the imapsync is whether I have to provide every single user's authentication to make it sync - if so, most of these have authentication that's not readily available - there's an in-house listserv solution that relies on this, so the passwords are stored internally, NOT readily able to be provided...
[15:48] <coreycb> jamespage, zul: can you add a team subscriber to python-senlinclient, python-openstacksdk, python-keystoneauth1?
[15:49] <jamespage> coreycb,
[15:49] <jamespage> yes
[15:49] <coreycb> jamespage, thanks
[15:50] <jamespage> coreycb, done
[16:40] <coreycb> jamespage, can you sponsor these uploads from the debian/mitaka branches?  http://paste.ubuntu.com/14401092/
[16:47] <jamespage> coreycb, hey do we have a bug for the liberty point releases? I have a spare 1hr so could help with those updates if need be
[16:48] <coreycb> jamespage, ah thanks. let me check.
[16:48] <coreycb> jamespage, I don't think we have one yet
[16:57] <rbasak> nacc: o/
[16:58] <nacc> rbasak: hey!
[16:58] <rbasak> nacc: so looking at bug 1318317, I first wondered what the intention was of the original author of the init script.
[16:58] <ubottu> bug 1318317 in openipmi (Ubuntu) "openipmi startup script removes kernel modules" [High,Confirmed] https://launchpad.net/bugs/1318317
[16:58] <rbasak> nacc: which led me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614394 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539416 that suggest that it isn't packaged with an init script in Debian, so the bug relates to the functionality Ubuntu added and is missing from Debian.
[16:58] <ubottu> Debian bug 614394 in openipmi "Suggestion: init.d script and config file for openipmi" [Normal,Open]
[16:58] <ubottu> Debian bug 539416 in openipmi "debian/rules: debian/openipmi.init: added init-script." [Wishlist,Open]
[16:58] <rbasak> nacc: and you say that the init script comes directly from upstream?
[17:00] <rbasak> Doing some archeology, it looks like the init script was added by Ubuntu back in 2008! From https://launchpad.net/ubuntu/+source/openipmi/+changelog
[17:01] <rbasak> nacc: so usually I'd like to minimise our work in Ubuntu by coordinating with the original upstream source of anything we want to change, to see if we can do it there instead so we don't have to maintain being different from the world.
[17:01] <rbasak> nacc: in this case it sounds like nobody else is looking after the init script anyway, so I think it's fine for you to polish it up and we can upload that.
[17:02] <nacc> rbasak: well, i think it came from upstream, at least? and has been since modified ... but they are too similar to not have a common parent, it seems like
[17:02] <rbasak> nacc: perhaps we should update to the latest upstream script then, assuming it works?
[17:02] <nacc> rbasak: the last upstream change to impi.init was june 2010
[17:02] <rbasak> nacc: and then fix the bug if necessary, and send upstream that patch?
[17:02] <nacc> rbasak: i don't think it does ... but i can test it separately
[17:03] <nacc> rbasak: upstream git vs. xenial: 34 insertions(+), 80 deletions(-)
[17:03] <nacc> rbasak: but i see what you are driving at ... and that's why i sent an e-mail upstream
[17:03] <nacc> but crickets since; let me subscribe to that list and see if my e-mail was just ignored/lost
[17:06] <rbasak> nacc: thanks. As long as we do our best to contact upstream and send patches I think that's the best we can do.
[17:09] <nacc> rbasak: yep, so ... would you prefer i fully cleanup the init-script? it seems to be logically a bit circuitous; or is it better to just make the minimal changes locally?
[17:09] <rbasak> nacc: I'm not sure there's much point in fully cleaning it up if upstream aren't responsive and aren't likely to accept it.
[17:09] <jamespage> coreycb, gah - our charms will need updating to support a .1
[17:10] <jamespage> that decision lacked forsight...
[17:10] <rbasak> nacc: so I think making the minimal change in Ubuntu is fine for now.
[17:10] <nacc> rbasak: ok, I'll wait for testing results and then fixup my patch (should be a no-op for testing purposes still)
[17:10] <nacc> rbasak: i'll also take a peek at the effect of using the upstream init-script
[17:11] <rbasak> nacc: as long as it doesn't break any use cases our users might have except in some reasonable way. So for example I don't want to fix POWER at the cost of some regression on some Intel hardware. If that happens then we might need to clean it up to support both cases or something.
[17:11] <rbasak> nacc: OK, thanks. Let me know when you're ready. If you think that on balance your change fixes things and probably doesn't break things, that'll be fine I think.
[17:12] <rbasak> nacc: ideally IMHO /etc/modules shouldn't be required to be used for this at all, since the logic should be in one place.
[17:12] <rbasak> nacc: I think that's the case with your current patch?
[17:13] <coreycb> jamespage, darn, hopefully it's not too invasive
[17:13] <balrogg_cs> Good afternoon everyone , someone could direct me to a good tutorial on VPN for Ubuntu Server ?
[17:15] <nacc> rbasak: right, notionally, /etc/modules is separate and unconsidered; what my patch does functionally is make it non-fatal if some HW modules (as specified in the config file), fail to load
[17:19] <rbasak> nacc: that sounds reasonable given that the package tries to load those by default (I think?) and hardware exists that works without those modules. Ideally we'd detect and load only required modules by default but I don't think there's any need to go that far.
[17:24] <nacc> rbasak: yeah, it's more to do (at least with this bug, in particular) with some confusion (IMO) on the OP's part as to how to control the IPMI modules at runtime. Basically, the openipmi 'service' just loads whatever the config file says to load; which by default is only ipmi_si and ipmi_devintf -- hence why other stuff appears as unloaded, because that's the OpenIPMI configuration
[17:25] <nacc> but then secondarily, the Power folks complain because impi_si fails to load at all on their system (and the default config has it required) and so the init-script bails out
[17:25] <nacc> it might be better to treat it as two separate bugs? not sure
=== rmc3 is now known as shishi
=== shishi is now known as rmc3
[17:26] <rbasak> I think I also see it as two bugs, but maybe I draw the line in a different place.
[17:27] <rbasak> I think "fails by default on Power" is the real bug here from a UX perspective.
[17:27] <nacc> rbasak: yep, I'd agree
[17:27] <rbasak> "Doesn't intelligently pick what modules to attempt to load by default" is a secondary bug I think, which I guess is much lower priority since we aren't aware of a way that would actually impact a user right now.
[17:27] <jamespage> coreycb, hey - I've uploaded what I can to https://launchpad.net/~james-page/+archive/ubuntu/wily/+packages for testing
[17:27] <rbasak> Even though fixing that one would be nice.
[17:27] <nacc> rbasak: so the alternative fix, which might be more palatable, is to just change the default value for IPMI_SI to "no" on Power
[17:28] <coreycb> jamespage, thanks
[17:28] <jamespage> however I need to think about the ch fix for version detection - may need to match on major/minor version only
[17:28] <rbasak> nacc: sure, but then you need to detect when to do that, and it's tricky to do in packaging because of conffile rules.
[17:28] <nacc> rbasak: right, and that's what I have sort of asked the upstream community about ... and whether the init-script should be mucking with modules that aren't set to "yes" in the first place (sinc ethey might be being controlled by something else, e.g.)
[17:28] <rbasak> (/etc is the sysadmin's domain, and changing it from scripts needs to respect any local changes the sysadmin made, and that's tricky)
[17:29] <nacc> rbasak: yeah, I wasn't sure that would be "easier" by any means :)
[17:29] <rbasak> :)
[17:29] <rbasak> Perhaps the default value should be "autodetect" and the script enhanced to be able to use that.
[17:30] <rbasak> But anyway, that's to fix the secondary bug, which I'm happy to leave.
[17:30] <nacc> rbasak: yep
[17:30] <rbasak> File it if you wish. It is useful to keep track of these things, since this bug will get resolved and forgotten.
[17:30] <rbasak> Then if anyone in Debian, Ubuntu or upstream wants to make things better at least there's a list.
[17:30] <nacc> rbasak: so the remaining/open question is if anyone relies on some /etc/default/openipmi configured modules not loading as fatal
[17:30] <rbasak> Right.
[17:31] <rbasak> That's a very good question.
[17:31] <nacc> it's still detectable, for what it's worth
[17:31] <nacc> the $? will have bit 1 set
[17:31] <nacc> but it's not going to just quit
[17:32] <rbasak> Presumably if someone is depending on that being fatal, then something will be fatal later?
[17:32] <rbasak> That is: something will be fatal later anyway, if we make the current failure non-fatal?
[17:33] <rbasak> If you've considered it and can't think of any other way, I think it's OK to fix it as you proposed unless/until someone points something out.
[17:33] <nacc> yeah, that's true; and as far as the end-user is concerned, the "fatal"ness of it is detected the same (technically), by that $? value. They just wont' see "[fail]" from the init-script ... but I'll take a closer look today, given what you've said
[17:46] <nacc> rbasak: thanks for the talkthrough, I appreciate it -- I probably will have some follow-up questions later about your archeology & investigation
=== argh_ is now known as grantsmith
[17:48] <rbasak> nacc: no problem!
[18:49] <coreycb> zul, can you sponsor this upload to xenial? https://code.launchpad.net/~corey.bryant/ubuntu/+source/python-keystoneauth1/+git/python-keystoneauth1
[18:54] <zul> coreycb: uscan --verbose --download failed
[19:08] <coreycb> zul, I've fixed that up and I'll push that to the debian repo separately
[19:14] <nacc> rbasak: ah ha! since we are setting RETVAL still, evne though we proceed (rather than aborting early), we still see the service 'fail' to start/restart
[19:43] <rbasak> nacc: good catch!
[19:53] <genii> Does anyone know of a way to use a secondary screen as the primary with just CLI, no X/xrandr ?
=== Lcawte|Away is now known as Lcawte
[20:09] <TJ-> genii: per-output framebuffer controls are via 'fbset', to swap primary<>secondary I suspect you'd need to do something to change the default from /dev/fb0
[20:11] <TJ-> genii:  'con2fbmap' should do what you want
[20:11] <genii> TJ-: My main prob is I have server installed headless on an old laptop which has had it's screen removed. Ssh-ing in works fine but I want to set it up that I can plug a monitor in locally and have it work if something happens
[20:13]  * genii investigates con2fbmap
[20:14] <TJ-> genii: you'll need to ensure there are framebuffers configured for the active outputs and a DRI/KMS driver active
[20:23] <wxl> hey folks is there anyone within the server community that tends to deal with ppc stuff?
[20:41] <rbasak> wxl: ask your question and find out!
[21:45] <wxl> rbasak: it's not so much a support issue as an architectural one. i have been contacted by a guy with some ppc64 hardware who's trying to get *ubuntu* (so not just server) working on it and he had some question about the potential of releasing multiple kernels, which apparently debian does upstream. i'm just trying to find him a good contact to chat with.
[21:46] <RoyK> wxl: it may be a good idea to use debian instead, then, since ubuntu is rather focused on x86/x64
[21:47] <wxl> RoyK: except for lubuntu, ubuntu mate, and server.
[21:47] <smoser> i dont know that "ubuntu is rather focused on x86/x64"
[21:47] <smoser> right.
[21:48] <RoyK> wxl: if you look at the updates on ubuntu, it holds a rather strong record of not updating anything that's not mainstream
[21:48] <sarnold> wxl: are we talking ancient stuff like a g5 mac or new shiny stuff from ibm or others? :)
[21:48] <wxl> sarnold: new, shiny.
[21:48] <RoyK> wxl: may I ask what sort of hardware?
[21:49] <wxl> RoyK: while i don't argue with you, this is orthogonal
[21:49] <sarnold> wxl: http://cdimage.ubuntu.com/releases/14.04/release/
[21:49] <sarnold> wxl: ppc64el iso is probably a fair starting point :)
[21:50] <wxl> here's what he's told me so far: dual-core, 64-bit, non-Altivec-enabled e5500 core
[21:50] <wxl> he also sent a pic http://tinypic.com/view.php?pic=1zbtlk9&s=5
[21:51] <wxl> he really just needs someone to chat at that might have the slightest of inkling as to what he might be talking about XD
[21:51] <sarnold> "remove at risk of death"
[21:52] <sarnold> there's a warning you don't see every day
[21:52] <wxl> apparently he's pushed support for it into the 4.4 kernel on his own
[21:53] <wxl> but i guess this is a Book-E CPU and the kernel needs to be compiled with Book-E support rather than Book-S support thus the question about alternative kernels
[21:56] <wxl> here's an older article that discusses Book-E if it's helpful https://www.kernel.org/doc/ols/2003/ols2003-pages-340-350.pdf
[21:57] <sarnold> aha :) now we're on to something. perhaps #ubuntu-kernel then?
[21:59] <wxl> ah maybe that would be best. great idea sarnold. thanks!
[22:00] <sarnold> wxl: if book-e vs book-s is a mutually exclusive choice, I wouldn't be too surp0rised if someone wants a support contract to make it worth while :) hehe
[22:01] <wxl> sarnold: money always helps XD
=== Lcawte is now known as Lcawte|Away
[22:54] <tsimonq2> ^
=== IdleOne is now known as Guest62646
[23:01] <lost1nfound> hey guys, ive had a pretty serious production problem since upgrading from 15.04 to 15.10 on my EC2 m4.xlarge/c4.xlarge high-traffic web instances. the instances just become unreachable and fail status checks 2-4 times per day. seen ifquery segfaults in logs as well, but nothing logs once they go into this state, so this is a bit tricky to debug. been working with aws support for 3 weeks and no
[23:02] <lost1nfound> luck. has anyone else had similar issues? or could maybe point me in the right direction?
[23:02] <lost1nfound> my other 15.10 instances are fine (20+) but these 10 machines crash 2-4x a day. i have an askubuntu post about it but it hasn't gotten any response, and im not sure where to go from here: https://askubuntu.com/questions/710747/after-upgrading-to-15-10-from-15-04-ec2-webservers-have-become-very-unstable
[23:02] <TJ-> lost1nfound: have you kept an open ssh session tailing the /var/log/kern.log to try to capture useful clues?
[23:04] <lost1nfound> i have, but the connection times out and i never see anything around the time of the crash
[23:05] <TJ-> OK, and have AWS shared any diagnostic clues with you?
[23:05] <TJ-> things they've ruled out maybe?
[23:16] <TJ-> those segfaults in ifup all look to be ocurring early in the life of the boot, and we could deduce there is a problem with the virtualised interface not being completely ready in some strange way
[23:51] <lost1nfound> TJ-: sorry, someone pulled me into a meeting. they have not, other than telling me theyve throughly examined the host/hardware diagnostics and determined theres no problem
[23:53] <lost1nfound> fairly early in the boot, one im looking happened right after remounting the root filesystem
[23:53] <TJ-> is there any pseudo-console (IPMI/KVM) options other than SSH to connect to the guest?
[23:53] <lost1nfound> at 2.817xxx. so not very early; the network adapter had already been initialized, etc
[23:53] <lost1nfound> i dont think aws offers that :( let me look again
[23:54] <TJ-> 2.8 seconds is early in terms of uptime though
[23:54] <TJ-> many things happen in parallel at boot-time; those could be due to some unusual race condition
[23:55] <lost1nfound> ah here we go, i found the console log and indeed, one of my frequently crashing machines logged [171009.844097] general protection fault: 0000 [#1] [ 0.000000] Initializing cgroup subsys cpuset
[23:55] <lost1nfound> immediately before reboot
[23:57] <TJ-> typical there's no stracktrace with it
[23:59] <lost1nfound> right, yeah. i wonder if theres any way to enable any debugging information on one of the systems