[00:18] <teward> rbasak: uhm, who looks after the perl autopkgtests
[00:18] <teward> because there's some nasties in there holding up Perl, and we need that to get out of proposed, or forcibly bypass that, before we can actually test the merge, etc.
[00:18] <teward> because i need to rebuild if we've bumped Perl at all
[07:27] <b3h3m0th> How do I: Lock user for X seconds after Y consecutive failed login attempts within a time windows of Z seconds.
[07:27] <b3h3m0th> Using PAM ?
[07:30] <sarnold> b3h3m0th: I think pam_tally2 is probably the way to get there
[07:30] <b3h3m0th> I tried tally but could not figure out a way to specify the Z param
[07:30] <b3h3m0th> *tally2
[07:31] <b3h3m0th> pam_faillock,  a redhat patch does support this using a fail_interval param. But  unfortunately for me ubuntu does not ship it :(
[07:41] <b3h3m0th> fail_interval=n: The length of the interval during which the consecutive authentication failures must happen for the user account lock out is n seconds. The default is 900 (15 minutes).
[07:41] <b3h3m0th> ^ This is what I'm actually looking for. [source: https://linux.die.net/man/8/pam_faillock]
[07:42] <b3h3m0th> I want a user to be able to try to login (Y-1) times every Z seconds indefinitely without lockout.
[08:56] <zioproto> hello all. Just starting a trusty to xenial do-release-upgrade on a server running glance-api and glance-registry. Openstack version MItaka. Any specific Openstack advice ? It is a staging system so relax :)
[09:47] <aaran> Hi, what is the name of the service that lets you book out time slots on a server for computation? I thought it was time sharing but thats from the olden days of mainframes
[09:49] <aaran> any ideas?
[09:54] <aaran> hmm think I found it job scheduling
[09:54] <rbasak> aaran: are you thinking about stuff like https://en.wikipedia.org/wiki/TORQUE_Resource_Manager ?
[09:55] <rbasak> It's more of an HPC thing.
[09:56] <rbasak> Also Slurm
[09:57] <aaran> basically we have a gpu server that a bunch of staff would like to run jobs on and its a system to book time to use the machine
[09:59] <aaran> its a single server so I dont think that slrum would be needed as that seems to be for clusters?
[10:07] <rbasak> For a single server, why not just use a shared calendar and trust?
[10:08] <aaran> because of students and their inability to stick to a schedule
[10:08] <aaran> But its an idea, thanks I will pitch the idea and wait to see what comes of it
[10:10] <caribou_> rbasak: jgrimm: FYI I have just synced clamav. The only remaining part will be to get the MIRed tomsfastmath in
[10:10] <cpaelzer> aaran: from my experience with similar - unfortunately not FOSS - solutions after the initial setup of getting hard schedules everybody complains about wasting so much time
[10:11] <cpaelzer> aaran: if you go for calendar+trust doe it as calendar+trust+communication; nothing is as bad as killing a 8 hour job 5 minutes before it completes :-)
[10:11] <cpaelzer> aaran: if you go for any sort of automation, make it a prio or credit based system with seme tolerance before killing runnign jobs
[10:12] <rbasak> For hard (no trust needed) schedules, I wonder if MAAS could help. It has an API, so you could automatically redeploy and give access to a scheduled user every time the scheduled user changes.
[10:12] <rbasak> Not too much scripting.
[10:12] <rbasak> Perhaps way overkill though (over using trust).
[10:12] <aaran> hhmm
[10:12] <cpaelzer> also chargeback (no matter how small) helps tremendously to get the people to keep their work fast and efficient
[10:14] <aaran> not sure if chargeback would be feasible
[10:14] <cpaelzer> doesn't have to be money
[10:15] <cpaelzer> if you implement something time credit based just lower that in case one overruns
[10:15] <cpaelzer> makes things much more self regulating
[10:15] <cpaelzer> but well over-engineering s at stake - start with calendar+trust and see where you get
[11:10] <joelio> any idea how https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-8743.html is getting on, appreciate it's medium risk
[11:15] <rbasak> joelio: try asking in #ubuntu-hardened.
[11:16] <rbasak> (it's also quite early for the Americas so you might not get an answer straight away)
[11:17] <joelio> rbasak: no worries, it's just on my list of things to keep an eye on, no biggie :)
[11:48] <cpaelzer> nacc: I think I debugged and understood the pg-repack issue, if you could trigger to re-run the postgres dep8s that would be nice
[11:48] <cpaelzer> nacc: from https://bileto.ubuntu.com/excuses/2470/yakkety.html that would be
[11:49] <cpaelzer> nacc: and actually the postfix tests and not the postgres ones
[11:49] <cpaelzer> pitti confirmed in the bug that these might just be flaky and worth a re-trigger
[12:57] <zioproto> regarding openstack packaging for glance the trusty to xenial upgrade was painless
[12:57] <zioproto> I am using the standard xenial mitaka packages
[13:16] <zioproto> Finally some interesting problem. I guess all puppet+openstack people will run soon into this https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1570472
[13:24] <zioproto> jamespag`, coreycb this bug is not assigned on Xenial, there is PPA that fixes the problem. Before we have a bunch of Openstack people having this problem, how can we make sure this gets assigned for review and merge in Xenial ??? thanks https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1570472
[14:39] <cpaelzer> coreycb: FYI the machine type fixes just passed the unapproved queue
[14:40] <cpaelzer> coreycb: I'll ping again when they built, tested and I'mabout to mark as verification done
[14:41] <coreycb> cpaelzer, ok thanks
[14:59] <lucidguy> Looks like if you want Nagios4 on Ubuntu 16.04 you have to build from source.. not on any reputable repo?
[15:16] <rbasak> lucidguy: yeah I don't think Nagios 4 is packaged in Debian or Ubuntu.
[15:19] <lucidguy> rbasak: I'm trying to decide if I should stick with v3 from repo or go and build v4
[15:21] <rbasak> I don't know enough to answer that question, sorry.
[15:56] <teward> cpaelzer: thanks for your testing, I appreciate the rapidity of your getting those tests done :)
[15:56] <teward> cpaelzer: thanks for your testing, I appreciate the rapidity of your getting those tests done :)
[15:56] <teward> cpaelzer: did you see anything that would otherwise be considered "bad" in the package?  (My brain isn't fully awake, I need another 3 coffees lol)
[16:00] <cpaelzer> teward: I did not do packaging review yet
[16:00] <cpaelzer> teward: didn't realize I should
[16:00] <teward> cpaelzer: nah, it's all good, i meant as "Anything odd introduced in the logs"
[16:00] <teward> packaging review I'm confident is fine, base Debian + our delta
[16:00] <cpaelzer> teward: from the "package user side" it appeared good to me
[16:00] <teward> and we were able to drop a few things.
[16:00] <teward> cpaelzer: yeah that's the primary tests I was after
[16:01] <teward> package review, I'm confident it's fine, because it's pretty much base Debian package + nginx-core specific things + build compat. fix for fPIE/fPIC that seems to be ubuntu specific + apport hooks
[16:02] <teward> nginx in Debian just uploaded 1.10.3-1 recently so it's not able to be pulled yet for merging, but it shouldn't be more than packaging changes.
[16:02] <teward> i'll check that tomorrow, until then I'm going to push this up because I'd *love* to get this in before FeatureFreeze
[16:02] <teward> we can FFe request for any packaging-specific changes that aren't 'new features'
[16:03] <teward> first, food, 'cause I haven't eaten all morning
[16:10] <joelio> lucidguy: considered Icinga2 ?
[16:25] <cpaelzer> rbasak: can you hit the importer on exim4 and logwatch for me - I'd like to consider feasibility of a re-merge before FF
[16:27] <jgrimm> cpaelzer, thanks!  cpaelzer btw, i suggested that you be added to the importer team
[16:28] <cpaelzer> jgrimm: I had hoped to annoy rbasak often enough that he does so on his own at some point :-)
[16:28] <jgrimm> heheh
[16:28] <rbasak> Running
[16:28] <cpaelzer> thanks
[16:29] <cpaelzer> jgrimm: btw I escaped the libvirt abstraction hell, libvirt-python binding to the rescue
[16:29] <jgrimm> rbasak, since you are at it.  autofs and libqb would be handy to import too.
[16:29] <lucidguy> joelio: no, boss asked for Nagios
[16:29] <jgrimm> cpaelzer, \o/
[16:30] <rbasak> cpaelzer: done. I think they were no-ops. The automatic importer is working maybe?
[16:40] <rbasak> nacc: OK to push obviously-correct minor usd bugfixes straight to master?
[16:41] <teward> rbasak, cpaelzer, jgrimm, powersj: NGINX merge uploaded to proposed.  Faster than my initial timeline was yesterday.  :)
[16:41] <rbasak> teward: \o/
[16:41] <rbasak> Thank you!
[16:41] <jgrimm> teward, \o/
[16:41] <teward> might need another one as an FFe for 1.10.3-1 from Debian (additional packaging changes)
[16:41] <teward> but hey *that* merge we get to drop a delta xD
[16:42] <rbasak> nacc: never mind. It's a bug in my pending branch. Not even in master!
[16:43] <teward> rbasak: those local branch/tree bugs are pesky and annoying, aren't they :P
[16:43] <rbasak> :-)
[16:43] <rbasak> Nice to get the bugs ironed out before I propose a merge :)
[16:45] <nacc> rbasak: ack on bugs
[16:45] <nacc> cpaelzer: i think pitti got those retriggered?
[16:46] <rbasak> jgrimm: autofs done (no-op?)
[16:46] <rbasak> jgrimm: libqb running (looks like an import from the beginning)
[16:49] <teward> rbasak: eheh, look at all the "NEW" in the queue xD  https://launchpad.net/ubuntu/zesty/+queue
[16:49] <teward> (for nginx)
[16:50] <teward> (translations)
[16:56] <jgrimm> rbasak, thanks! and thanks!
[16:56] <nacc> jgrimm: fyi, new dogtag-pki is being synced over and built now, then various tests should rekick or i will manually as neccessary
[16:56] <jgrimm> nacc, thanks
[16:57] <nacc> jgrimm: re: openvpn, can i reject the old merge request?
[16:58] <nacc> jgrimm: MP: #316337
[16:58] <jgrimm> nacc, yep i only left it around for you to refer back to
[16:58] <nacc> jgrimm: ack, will close once i merge the new one
[16:58] <jgrimm> since i'd uploaded a new branch. thanks sir
[16:58] <nacc> jgrimm: 317004 is current?
[16:59] <jgrimm> nacc, yes
[17:02] <coreycb> zul, i'm working on testing a cherry-pick of this to nova: https://review.openstack.org/#/c/431582/
[17:04] <GPenguin> hello, i am interested in the wordpress package on ubuntu 16.04. server edition
[17:05] <GPenguin> the readme in /usr/share/doc/wordpress is ... uhm... well, a bit rusty?
[17:05] <GPenguin> i see the mysql server itself is not installed. and the doc speaks about a password which i never set
[17:06] <GPenguin> is there a more detailed and more up to date version of the documentation out there?
[17:07] <nacc> GPenguin: yes, wordpress only depends on a client
[17:07] <nacc> GPenguin: you need to setup a server potentially
[17:07] <GPenguin> ah, hmmm
[17:08] <nacc> GPenguin: if you insatll suggests, it will pick up mysql-server as well
[17:08] <rbasak> jgrimm: libqb done
[17:11] <GPenguin> nacc: i am also missing the wp-config.php
[17:12] <jgrimm> rbasak, thanks
[17:13] <GPenguin> uhh, that is in /usr/share/wordpress
[17:17] <nacc> GPenguin: looking to see if i can reproduce; iirc, when i did the update, i got it installed and setup fine
[17:26] <nacc> GPenguin: and the apache config uses /usr/share/wordpress
[17:26] <nacc> GPenguin: the example one
[17:37] <nacc> GPenguin: yeah, so that basically works, your choice of apache configuration, enable it, run setup-mysql and then navigate in a browser to finsih the wordpress install like normal
[17:38] <GPenguin> hmmm
[18:04] <zul> coreycb: okie dokie
[18:27] <BrianBlaze420> oh man going from 8 to 16 is fun lol
[18:37] <compdoc> 16 girlfriends?
[18:42] <OerHeks> 16 bit?
[18:44] <nacc> 8.04 to 16.04 based upon yesterday's context
[18:44] <nacc> BrianBlaze420: honestly, it's probably easiest to backup data and install from scratcch
[18:44] <BrianBlaze420> yeah that's what is happening
[18:44] <BrianBlaze420> so sad lol
[18:45] <BrianBlaze420> i am more sad that the guy who set this up walked away from it for so long
[18:45] <BrianBlaze420> anyways I am just venting :)
[18:55] <teward> BrianBlaze420: sounds like an evil system I had to work with in the past, at my one workplace.  8.04 running evil Python
[18:55] <teward> 16.04 wasn't out yet so we had to -> 14.04
[18:55] <teward> 14.04 -> 16.04 will be easy heh
[18:55] <teward> python, dovecot, etc. all configured on 14.04 works pretty well on 16.04 too :P
[18:55] <BrianBlaze420> lol yeah I am looking forward to getting there
[18:55] <BrianBlaze420> where I am not horrified of updating lol
[18:56] <teward> took a year to migrate everything off 8.04
[18:56] <teward> because of python lol
[18:56] <teward> dovecot and postfix were easy
[18:56] <teward> python, not so much
[18:56] <teward> (3rd party library updates, etc. caused problems0
[18:56] <teward> s/library/module/
[18:56] <teward> anyways i digress :)
[18:57] <BrianBlaze420> :)
[18:57] <BrianBlaze420> at least I feel less alone, so I appreciate lol
[18:57] <teward> sarnold: ohai, you!  nginx merge uploaded to -proposed.  Lotsa new binaries lol
[18:58] <sarnold> teward: \o/ nice, how'd it go?
[18:58] <teward> sarnold: painfully.  'cause it's a ***horrible*** evil process.
[18:58] <sarnold> teward: aye :/
[18:58] <teward> baseDebian + PackagingDeltaChanges + (fixMistake x 4)
[18:59] <teward> finally got it to a PPA last night, and cpaelzer was kind enough to run install/upgrade tests
[18:59] <teward> i'm just waiting for the mismatched components report :P
[18:59] <teward> 'cause there'll be some
[19:00] <teward> (some of the dynamic module packages)
[19:13] <JoseLuis_> Good afternoon all.
[19:14] <teward> greetings
[19:16] <JoseLuis_> I have a lot of mail in my server about Cron <root@localhost> /etc/cron.hourly/kill.sh  and Cron <root@localhost> /etc/cron.hourly/cron.sh
[19:18] <JoseLuis_> SIOCSIFFLAGS: Cannot assign requested address     SIOCSIFFLAGS: Protocol driver not attached
[19:20] <sarnold> what do those scripts do?
[19:22] <JoseLuis_> cat /etc/cron.hourly/kill.sh  http://termbin.com/vgz8
[19:22] <JoseLuis_> cat /etc/cron.hourly/cron.sh http://termbin.com/cfb4
[19:23] <sarnold> oh crap
[19:23] <sarnold> now I remember why your name is familiar
[19:23] <sarnold> JoseLuis_: https://www.linode.com/docs/security/recovering-from-a-system-compromise
[19:25] <JoseLuis_> sarnold: I am going to read
[19:34] <JoseLuis_> sarnold: Definitely, we will to create a new server in linode, but we should need to install security first before to install program and database.
[19:36] <sarnold> JoseLuis_: it'd be worth trying to figure out how this instance was compromised while you're at it -- full forensics are extremely difficult, but it'd be best to know if the machine was hacked via ssh password brute-force searches, or a web-based management console, or something else..
[19:40] <JoseLuis_> yeah, but I do not know how to do this.
[19:41] <teward> sarnold: compromised systems are compromised!
[19:41] <teward> JoseLuis_: you'd either hire someone
[19:41] <teward> or just not bother finding how to ID the compromise.  Either case, nuke with fire
[19:46] <JoseLuis_> I was hired in august for manage mongodb and to make some scripts in linux to monitoring some server in linode and windows.
[19:48] <sarnold> I wonder if this was involved http://thehackernews.com/2017/01/secure-mongodb-database.html
[19:49] <JoseLuis_> the security in linux servers and windows server is almost null, (pass with 12345678, qwerty, etc..)
[19:50] <teward> JoseLuis_: well, "the security in linux servers" is a matter of configuration
[19:50] <teward> 99% of the time, people who set up the servers
[19:50] <teward> don't follow common sense practices
[19:50] <JoseLuis_> sarnold: thanks for the information.
[19:51] <sarnold> teward: I'm afraid that's what he was reporting on :)
[19:51] <sarnold> JoseLuis_: good luck
[19:51] <teward> heh
[19:51] <teward> sarnold: CrapSecurity is about equal to ZeroSecurity
[19:52] <teward> and then there's my network, locked up tight, every system has a firewall, different passwords for each, service and priv. separation across multiple systems...
[19:52] <teward> VLANed out the wazoo to protect other subnets...
[19:52] <teward> IDS/IPS on the border...
[19:52] <teward> redundant firewalls...
[19:52] <teward> ... is my network overkill yet?  :P
[19:53] <sarnold> ayup. :)
[21:09] <pmatulis> a rift in the fabric of time
[21:39] <Dmitrii-Sh> cpaelzer: hi, is there a reason why libvirt is missing from https://code.launchpad.net/~usd-import-team/+git ? I'm not too familiar with usd-importer yet but 'git grep -i libvirt' in its repo shows that it is commented out in the usd-cron-packages.txt:#libvirt
[21:42] <Dmitrii-Sh> cpaelzer: in general, I am looking for a good way to do quick git merge-base --is-ancestor <hash1> <hash2> type of checks for upstream patches and it is much easier to have an up-to-date git repo at hand to do it
[21:43] <nacc> Dmitrii-Sh: there is a distinct git repository being used
[21:44] <nacc> Dmitrii-Sh: for libvirt they use the debian repo, iirc
[21:44] <nacc> Dmitrii-Sh: there is an ubuntu branch (or branches)
[21:44] <nacc> Dmitrii-Sh: i might be wrong, smb may also know
[21:46] <Dmitrii-Sh> nacc: hmm, I saw the Debian repo https://anonscm.debian.org/cgit/pkg-libvirt/libvirt.git/refs/ but there is only a single ubuntu branch there (from 2007)
[21:47] <nacc> Dmitrii-Sh: oh sorry, there is a lp repo, i guess (found it from the ubuntu package search SCM link)
[21:47] <nacc> https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt
[21:48] <nacc> Dmitrii-Sh: that looks current, i think
[21:48] <nacc> Dmitrii-Sh: also, should be the Vcs-Git value in the control file in the source pacakge, iirc
[21:51] <Dmitrii-Sh> nacc: this one seems right
[21:51] <Dmitrii-Sh> nacc: http://packages.ubuntu.com/source/xenial-updates/libvirt the repo mentioned here too
[21:51] <nacc> Dmitrii-Sh: cool :)
[21:52] <Dmitrii-Sh> nacc: wasn't the case with qemu AFAIR but this one is good )
[21:52] <Dmitrii-Sh> nacc: thx
[22:35] <powersj> rbasak: thanks for the review of etckeeper, updates made!