[04:00] <cpaelzer> good morning
[12:02] <simulant> Hi does anyone know an easier way to pull up a list of ip addresses that successfully logged into an email account on ubuntu server within the last day or two? Mail log has 1000s of entires to try look through with login failures and various other messages in there... Any easier way?
[12:10] <rbasak> simulant: grep?
[12:10] <rbasak> simulant: most admins would use a combination of things like grep/egrep, sed, awk, cut, sort, uniq, etc.
[12:48] <simulant> rbasak: ok thanks
[12:57] <RoyK> rbasak: or just perl or python ;)
[13:00] <rbasak> "Just"
[13:00] <tafa2> does anyone run their own hypervisor (promox/vmware/similar) in the cloud on a dedicated server? I've got several VPS's now and have done some quick maths and it'll basically be cheaper for me to get a dedi and just portion it out the way I want
[13:01] <tafa2> was wondering if anyone did this and woudl advise against doing so?
[13:01] <rbasak> tafa2: you might try lxd
[13:01]  * tafa2 googles lxd
[13:01] <rbasak> You can run it on a single VPS
[13:02] <ahasenack> that's a pro tip
[13:04] <_KaszpiR_> tafa2 in general it is possible but usually you are responsible for the whole automation process, and usually it's not worth it unless you already have it
[13:07] <tafa2> yeah I figured as much :)I'm running a few locally at home and at $dayjob (hyper-v, and prox) just wondering if anyone
[13:07] <tafa2> has done and would just recommend to sticking to regular VPS's
[13:08] <tafa2> for example, I forget I'd have to order (and justify) additional IP's
[13:13] <tafa2> rbasak is lxd basically containerised OS's?
[13:13] <tafa2> so... docker but for an OS?
[13:13] <rbasak> tafa2: right
[13:13] <tafa2> Interesting... what's the benefit over KVM for example?
[13:13] <rbasak> Higher density is the main reason
[13:14] <rbasak> You don't have to dedicate RAM on a per-contaner basis
[13:14] <rbasak> (though you can apply limits)
[13:14] <tafa2> 0o
[13:14] <rbasak> Faster starts/clones/etc, easier to manage.
[13:14] <tafa2> so the each lxd image gets it's own root shell, seperate environment but no allocated RAM?
[13:15] <rbasak> eg. usually you'd set up containers on the same filesystem so no messing with loopback mounts for management.
[13:15] <tafa2> just uses it from a "pool"
[13:15] <rbasak> Each container sees its own stuff only, as if it's the only OS on the system.
[13:15] <rbasak> However a container process is just a process like any other
[13:15] <rbasak> That you can see from the host if you "ps".
[13:16] <rbasak> Try it: on Ubuntu, "lxc launch ubuntu:bionic my-first-container" and "lxc exec my-first-container bash"
[13:16] <tafa2> I'm on the online tutorial now
[13:16] <tafa2> pretty cool
[13:16] <rbasak> It's what Docker was originally based on. Your description of "like Docker but for OSs" seems backwards to me because I was using lxc before Docker existed :)
[13:18] <tafa2> lol
[13:18] <tafa2> I get you
[13:18] <tafa2> I've spun it up
[13:19] <tafa2> It's interesting, but a faff - although everything is separate I don't feel like its a truly independent OS/environment in terms of access
[13:20] <tafa2> looks like there'd be a lot of messing around with internal network assignements
[13:25] <rbasak> You can arrange the network how you like - much like a VM.
[13:25] <rbasak> Bridge host NICs through, or apply through NAT, etc.
[13:25] <rbasak> Networking is essentially no different to using VMs.
[13:26] <rbasak> It's also possible for containers to share the same network namespace as the host, though I'm not sure if lxd supports that.
[13:34] <rbasak> cpaelzer: if you're taking the samba reviews, shall I take apache2?
[13:34]  * rbasak claims it
[13:35] <ahasenack> \o/
[13:48] <cpaelzer> rbasak: yes that is ok
[13:48] <cpaelzer> I'm juts now able to start on the samba MPs
[13:49] <rbasak> cpaelzer: nice job figuring out the race in the dovecot test. That one had defeated me when I looked a few years ago.
[13:50] <cpaelzer> it is ugly++
[13:51] <cpaelzer> and I'm not entirely sure it is "the same" as the arm one you hunted
[13:51] <tobasco> jamespage: just got this issue in production https://bugs.launchpad.net/neutron/+bug/1667756
[13:52] <tobasco> do you still support xenial mitaka? is these two allegable for backport to xenial/mitaka
[13:52] <tobasco> https://review.openstack.org/#/c/460924/ https://review.openstack.org/#/c/482847/
[13:52] <tobasco> coreycb: ^
[13:59] <coreycb> tobasco: assuming they backport fairly cleanly then it shouldn't be a problem
[13:59] <coreycb> tobasco: yes we do support xenial/mitaka
[14:00] <tobasco> want me to add the distro to that bug and add a comment?
[14:01] <coreycb> tobasco: i can do that. if you happen to be able to provide mitaka versions of those patches that would help speed up the process. they can be attached to the bug.
[14:02] <tobasco> i haven't tried applying those newton patches on mitaka
[14:18]  * rbasak takes the open-vm-tools review
[14:33] <ahasenack> rbasak: I prepared the SRU paperwork for pmdk and ndctl (#1781269 and #1781268), it needs sponsorship
[14:33] <ahasenack> is that something you could card and do?
[14:36] <rbasak> ahasenack: yes. Carded.
[14:36] <ahasenack> thanks
[15:15] <setra> anybody knows about a decent CEFS Cluster setup guide, which really works?
[15:17] <tobasco> coreycb: tried looking through a cherry-pick but it seems a lot of stuff changed
[15:20] <coreycb> tobasco: that might make it tough to do
[15:28] <tomreyn> setra: my guess you mean CEPH
[15:28] <tomreyn> *is
[15:58] <rbasak> ahasenack: may I have comment permission on your git-ubuntu FAQ document please
[15:59] <rbasak> ?
[16:14] <setra> tomreyn, yes that is what I meant... :-)
[16:33] <teward> bleh, can an ubuntu-server list moderator approve my message?  Apparently, since my email change over, my @ubuntu.com address is auto-stuck in the moderation queues >.>
[16:53] <ahasenack> rbasak: done
[16:57] <teward> shoutout to powersj for once again helping me with the nginx bug triage.  I probably need to update the duplicate detection triggers
[16:57] <teward> your help is always appreciated powersj  :)
[16:57] <powersj> :) had one come up today so figured I'd go through your list
[16:58] <powersj> having those templates makes it real easy
[16:58] <teward> indeed.  i'm finding more and more though that these're 'delayed' bug submissions so I need to sniff through the logs,
[16:58] <teward> powersj: you might be interested in a feature proposal i wrote
[16:58] <teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1782226
[16:59] <teward> so I can get rid of those stupid "err: bound to port" bugs **once and for all** lol
[16:59] <powersj> nice!
[16:59] <teward> i'm working on getting that working, but i've had https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1781971 as a more important "this should be done first" thing from Andreas
[17:00] <powersj> ah yeah I read that one as well today
[17:00] <teward> that one's got an interesting headache fixing though
[17:00] <teward> nginx-daemon in my test builds doesn't have a depend on nginx-common in the debian/control...
[17:00] <teward> ... but it gets an nginx-common dependency anyway when built
[17:00] <ahasenack> you mean andres
[17:00] <teward> oops yes
[17:00] <teward> sorry i'm fast-reading over four screens today :|
[17:01] <teward> anyways, IDK why it's adding nginx-common when I don't declare it in its dependencies, so blah.
[17:01] <ahasenack> I'm used to tha tparticular confusion :)
[17:01] <teward> hashtag HelpWanted :P
[17:08] <TJ-> teward: through one of the declared dependencies?
[17:09] <teward> didn't see any.  the only thing it depends on are the libnginx-* dynamic modules that aren't third party modules that nginx-core would have otherwise depended on, otherwise it has no declaration of any other dependencies that I'm aware of which would pull in nginx-common
[17:09] <teward> i'll have to dig deeper
[17:09] <teward> it's probable I'm just missing something :p
[17:13] <TJ-> teward: as in ${misc:Depends} ?
[17:14] <teward> that... might be why, hmm.
[17:14] <TJ-> teward: is nginx-daemon a new binary package ?
[17:14] <teward> TJ-: it replaces the binary component of the nginx-core package, yes, and doesn't depend on nginx-common directly (which was requested by andres)
[17:15] <teward> nginx-core therefore is more or less a package that has some configuraiton and tests in it, but otherwise doesn't contain a binary nginx executable, that is provided by nginx-daemon in this 'test' build to get it done
[17:15] <teward> any way to see what misc:Depends expands into?
[17:20] <teward> TJ-: if this works I owe you a beer.
[17:21] <teward> i had a feeling it might be something stupid so :P
[17:22] <TJ-> dh_gencontrol deal with it, so maybe look at the build log in detail
[17:28] <teward> well that just happened (my hardline dropped o.o)
[17:28] <dlloyd> did you make it out of the matrix in time
[17:31] <teward> lol
[17:31] <teward> I **am** the matrix!  *evil laughter*
[17:42] <philaneous> hi guys im having issues with SSL certificates via letsencrypt. i cant get the the redirection to work. HTTPS works locally but when i run an ssl checker the certificate is not found. It's also not accessible outside of the LAN on 443.
[17:43] <teward> TJ-: confirmed it was the misc:Depends
[17:43] <teward> not sure how to alter that so it doesn't add nginx-common to everything...
[17:44] <TJ-> teward: is there something in debian/rules adding it statically?
[17:45] <TJ-> teward: debian/dh_nginx:234:                addsubstvar($package, "misc:Depends", nginx_depends());
[17:47] <teward> yep that'd be it there
[17:47] <teward> TJ-: it adds it to all the packages o.O
[17:47] <teward> that's... not good?
[17:47] <teward> might have to trim that for this to work properly, and that'd not be nice to do
[17:48] <teward> TJ-: though I might be able to adjust that to avoid certain packages and strings... such as for the modules and the nginx-daemon binary package
[17:48] <teward> TBH I stared at this for eight hours on Saturday before saying "I need a break" o.O
[17:48] <teward> guess I missed lots of these things
[17:54] <TJ-> teward: it only looks to be included if the package being built contains a module. Is that the case with nginx-daemon?
[17:54] <TJ-> teward: if so, you can edit the line "if ($package !~ m/libnginx-mod-\w+?/)" to include a match for nginx-daemon
[17:58] <teward> TJ-: actually the way it's doing that is it adds everything
[17:58] <teward> TJ-: the dep add is *after* that check
[17:58] <TJ-> teward: oh yeah... my indentation was confusing me
[17:58] <teward> this sounds like a bug in the code, because that line adds nginx-common to all the modules
[17:59] <teward> TJ-: i can adjust this to make it have a secondary conditional that it needs to not match that regex and also not match nginx-daemon
[17:59] <TJ-> teward: the commit log talks about soemthing dynamic
[17:59] <teward> but this also sounds like a bug in the package and that i need to poke that upstream
[17:59] <teward> TJ-: libnginx-mod-* includes compiled .so module binaries, yes.
[17:59] <teward> but they don't depend on nginx-common, they just have a requirement on one of the nginx binaries being installed
[17:59] <powersj> ahasenack, the 1404 name is not related to 14.04 ;)
[18:00] <teward> TJ: so `nginx-daemon | nginx-full | nginx-light | nginx-extras` makes sense, but you could technically install just the .so without any additional configs
[18:00] <teward> *except* for the fact that it would then fail to load that module unless you have an nginx.conf built to do it
[18:00] <teward> TJ-: so i'm starting to think that this might not be doable within the confines of what's needed because of those dynamic modules...
[18:00] <TJ-> teward: right. This in the commit log suggests why "Not all modules are ready for dynamic building"
[18:01] <teward> TJ-: i think we're talking two separate 'issues' here
[18:01] <teward> (1) Binary moduels that're dynamic
[18:01] <teward> (2) Modules compiled inot the code
[18:01] <teward> the problem with (1) is that you need nginx-common because it creates the config struct that the modules then install into
[18:01] <teward> which includes the modules-available
[18:01] <TJ-> teward: that sounds about correct
[18:02] <teward> which means that what andres wants is not doable
[18:02] <ahasenack> powersj: go figure :)
[18:03] <teward> TJ-: if that's the case, then I'll have to reply as such on the bug, because it's not able to be done in a way that would work for what andres and their team needs
[18:04] <teward> ... actually...
[18:04] <teward> ... we may be able to just install nginx-daemon without the third party modules
[18:04] <teward> s/third party modules/dynamic modules/
[18:04] <teward> it'd strip a good portion of nginx functionality out
[18:04] <teward> (at least, the functionality those modules provide)
[18:04] <teward> but it'd work...
[18:06] <TJ-> teward: you've defined nginx-daemon as a flavour ? if so can't you just statically link the popular/common  modules into it? or is that not what is wanted?
[18:07] <teward> TJ-: this is an 'in the works' package.
[18:07] <teward> not the final
[18:07] <teward> once i figured out the deps issue I was going to fix it
[18:07] <teward> however the original request was the binary that nginx-core provides without nginx-common
[18:08] <teward> hence the original 'scope' discussion I had with andres as to what exactly was being requested
[18:09] <teward> i'll have to think about how to approach this
[18:09] <teward> but I won't be able to do that while these coworkers of mine are rude noisy [CENSORED] right next to my cube and they aren't even discussing work
[18:10] <teward> this is a wishlisted feature, of course, of more importance before FeatureFreeze of this cycle is which NGINX branch to track
[18:11] <teward> and i'm still waiting for that email to be released from the mod queue on the mailing list so I can get everyone's input :P
[18:11] <TJ-> teward: the only noise I have is birds tweeting, and tapping on the roof of my inside-out room :)
[18:13] <teward> TJ-: heheh.  You're lucky then :P
[18:13] <teward> I'm stuck with noisy inconsiderate coworkers WHO I HOPE ARE READING THIS HUGE PRINT OVER MY SHOULDERS.
[18:13] <teward> (it's been one of those days...)
[18:13] <teward> *pops in earbuds and blasts metal music to drown them out*
[18:14] <TJ-> ha! and now a Husky come to howl at me for her dinner :)
[18:50] <teward> TJ-: I think what I'll do is strip nginx-daemon to a separate package excluding the dynamic modules, and leave that in nginx-core.  Once that's done the daemon can be installed separately minus the featuresets that were in the dynamic modules
[18:50] <teward> that should settle andres' request as well as solve nginx-core.
[18:50] <teward> but that's a problem for tomorrow ;P
[19:19] <leftyfb> davidlopez: while you CAN install a GUI onto your server, it will in no way make properly configuring your server easier. In fact, it will slow you down in many ways including adding unnecessary resources to your server. If you have any interest in learning, the terminal is where it's at.
[20:45] <tomreyn> so this channel is +z, bu thtere are no ops
[20:45] <tomreyn> *but there
[20:45] <leftyfb> wait, can you see this?
[20:45] <tomreyn> yes
[20:45] <tomreyn> you're registered
[20:45] <leftyfb> and philip___ isn't?
[20:45] <tomreyn> i guess not
[20:46] <tomreyn> -NickServ- philip___ is not registered.
[20:47] <tomreyn> so unregistered users can type here, and assume they've been read. but in fact only ops would get to see them. and there are no users with mode +o here (currently)
[20:47] <tomreyn> meaning unregistered users just speak to /dev/null without being aware of it
[20:48] <leftyfb> kinda sad that there's no +o's here
[20:54] <powersj> There are ops and if you need something I believe you can ask in #ubuntu-irc
[20:54] <powersj> They turned on registering after a lot of spam
[22:46] <rbasak> Unit193: ^
[22:46] <Unit193> rbasak: What's up?
[22:46] <rbasak> See backscroll please?
[22:47] <rbasak> Do we need to do something about that?
[22:48] <Unit193> rbasak: I'd think for this channel +r would be best, personally.  I'm not a named op here though.
[22:52] <Unit193> rbasak: Poked somewhere else, hopefully it's solved soon.
[22:58] <rbasak> Unit193: thanks!