[02:59] <entry_lvl_dev> i cant rdp into my server..i installed ubuntu-mate and followed some online insturctions.,.. im able to rdp but the screen stays blue after i log in
[02:59] <entry_lvl_dev> the desktokp envorinment doesnt load all the way
[05:56] <lordievader> Good morning
=== elsheepo is now known as beatzz
=== Screedo_ is now known as Screedo
[07:55] <blackflow> teward: ping! I've analyzed and traced down the issue I had with nginx+http2. The problem is in fact with nginx. If the connection is slow or has high(er) number of tcp retries, nginx will stop sending pipelined content within a http2 request.
[08:04] <blackflow> teward: apparently consistently after ~17 seconds.
[08:07] <blackflow> teward: now I do have send_timeout set to 15s, but that's supposed to be timeout between two successive write ops. does that option have a different meaning with http2 now?
[13:17] <coreycb> sahid: nova 19.0.1 uploaded to disco unapproved queue. thanks.
[13:23] <sahid> coreycb: ack
[14:23] <teward> blackflow: i don't see a bug open for you :P  The tricky part is a reproducible test case :p
[14:23] <teward> blackflow: that sounds like something Upstream should see though, at nginx, for them to debug
[14:23] <teward> and I don't see a reproducible test case anywhere other than your setup.
[14:31] <coreycb> jamespage, sahid: i'm going to merge openstack-pkg-tools from experimental. it's basically all debconf changes.
[14:35] <sahid> coreycb: ack
[14:37] <coreycb> sahid: worth noting we don't use debconf in the openstack ubuntu packages except for ones that originate in debian (the
[14:37] <coreycb> (the core packages we sync from debian will have debconf - zaqar, sahara, etc)
[14:38] <blackflow> teward: right, that's the part I'm trying to pin down now.
[14:44] <coreycb> jamespage: sahid: turns out everything we've been carrying has been merged into debian openstack-pkg-tools so i'll sync that (ie. syncpackage openstack-pkg-tools experimental) assuming it builds ok
[14:44] <coreycb> i mean, syncpackage -d experimental openstack-pkg-tools
[14:59] <teward> sdeziel: so I don't have any single-core test environments for any distro, but if I don't hear any "problems" in the next week or two I'll include that patch.
[15:00] <teward> I need to do a patch for Eoan but I should probably figure out which PHP version's going to be in it
[15:00] <teward> rbasak: is nacc still a good POC for PHP or is someone else handling PHP this cycle?
[15:00] <sdeziel> teward: cool. re single-core it's easy with lxd: lxc config set foo limits.cpu 1
[15:01] <teward> sdeziel: ya but i'm lazy and I meant in *prod* :p
[15:01] <teward> like a production site I can test with that's straight internet facing :p
[15:01] <teward> so unless you or Canonical want to loan me $8 for a 1-core KVM VPS with crap memory... :P
[15:01] <teward> all my stuff's dual core or better
[15:05] <teward> actually... *wonders about something*
[15:18] <teward> i might be able to deploy this in my cloud and test with a direct IP but I'm busy at work.
[15:18] <teward> this be a weekend task xD
[15:39] <Ademan-remote> I"m trying to run the 18.04.2 server alternate installer from an iso on a thumb drive, and I've booted to the point where the installer is running, and it's failing at "Detect and mount CD-ROM". I can mount the iso file just fine from the busybox command line, can I just mount it in the right place and/or point the installer to it?
[15:41] <Ademan-remote> Ah, gonna try this `mount -o loop path/to/iso/file/UBUNTUSERVER.ISO /cdrom'
[15:44] <nacc> Ademan-remote: i think maybe you did the wrong thing -- you don't usually boot the ISO, you write the ISO to the thumb drive itself and boot from the thumb drive.
[15:45] <Ademan-remote> the installer *really* wants to treat /dev/sdc1 as the cdrom: "Searching for Ubuntu installation media..." "Devices: '/dev/sdc1'"
[15:45] <nacc> Ademan-remote: i've not tried what you are suggesting, I don't know if it will work
[15:45] <Ademan-remote> nacc: it's *supposed* to be possible with EFI, and I'm booted, it's just the installer that's choking at this point
[15:46] <nacc> Ademan-remote: just don't know if it's an actually supported thing in ubuntu :)
[15:46] <nacc> (or tested)
[15:46] <Ademan-remote> that's fair haha
[15:48] <Ademan-remote> oh my goodness...
[15:49] <Ademan-remote> the problem was when I hit "Ok" acknowledging the problem mounting the CD-ROM, it was unmounting /cdrom for me... so I had to OK it first, then mount to /cdrom...
[15:50] <Ademan-remote> I did notice it was unmounting /cdrom but I didn't notice *when* it was happening heh
[15:52] <Ademan-remote> ( so `mount -o /foo/bar/baz/quux.iso /cdrom' actually works, just be careful what the installer is doing heh)
[15:52] <Ademan-remote> ...now to name this new box ;-)
[16:26] <teward> nacc: who handles PHP stuff now?
[16:28] <powersj> teward, working on getting someone on the team spun up on that
[16:28] <powersj> teward, something come up?
[16:49] <teward> powersj: nah, nothing of critical note, just need to know the php-fpm 'path' it's going to be dropping the socket into
[16:49] <teward> because https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1831748
[16:49] <ubottu> Launchpad bug 1831748 in nginx (Ubuntu) "Update /etc/nginx/sites-enabled/default with php-fpm 7.2" [Low,Triaged]
[16:49] <teward> not SRUable but DEFINITELY fixable for Eoan
[16:50] <teward> and since I think it's version number dependent, want to make sure I know the version landing for Eoan
[17:05] <nacc> teward: sorry was afk
[17:06] <teward> nacc: no problem
[17:06] <nacc> tbh i've not looked at php in some time. I know that's not great. I am happy to assist anyone who is looking to take it over from server (cc: powersj :)
[17:07] <teward> lol
[17:07] <teward> nacc: i was just curious what version was landing xD
[21:03] <keithzg[m]> Hmm is it expected that an 18.04 server with livepatching enabled would still be reporting 4.15.0-50 despite 4.15.0-51 being out? (I'm probably just misunderstanding something basic here.)
[21:04] <sdeziel> keithzg[m]: yes, that's normal. Live patches won't change what uname reports
[21:05] <sdeziel> keithzg[m]: furthermore, you also should/need to deploy regular patches so that when you reboot you get the -51 kernel proper
[21:07] <keithzg[m]> sdeziel: Ah, so 4.15.0-50.54-generic is equivalent to 4.15.0-51-generic? And yeah, I have unattended-upgrades set to automatically install all security updates anyways, in fact that's what triggered me noticing this, since the  -51 kernel was installed and so now the machine in question is reporting reboot-required.
[21:08] <sdeziel> keithzg[m]: not equivalent, no
[21:08] <sdeziel> keithzg[m]: live patches are only provided for (some?) security patches *when possible*
[21:08] <keithzg[m]> Ah, fair
[21:10] <sdeziel> keithzg[m]: you can check which CVEs are live patched with: canonical-livepatch status --verbose
[21:11] <keithzg[m]> sdeziel: Apparently currently none, since `canonical-livepatch status --verbose` gives identical output to `canonical-livepatch status`, to my surprise (both the version and fixes entries are just "").
[21:13] <sdeziel> keithzg[m]: so either the live patches were not published yet or Canonical decided the only CVE was negligible enough to not worth providing live patches
[21:14] <sdeziel> or maybe not even live patch'able since it was essentially ripping out a.out support IIRC
[21:16] <keithzg[m]> sdeziel: Makes sense
[21:16] <sdeziel> keithzg[m]: the notes in https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-11191.html mention this CVE only affecting i386 and is rated negligible. I don't even think live patches are made available for i386
[21:17] <keithzg[m]> Yeah and the server I have in question sure isn't running i386 anyways, heh
[22:25] <sudoISS> So, if `sudo adduser username` creates the user "username", wouldn't `sudo adduser username groupname` make "groupname" "username"'s primary group?
[23:12] <OerHeks> no, secondary, the primary group is used by default when creating new files (or directories), modifying files, or executing commands.