| 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 | 02:59 |
| lordievader | Good morning | 05:56 |
| === elsheepo is now known as beatzz | ||
| === Screedo_ is now known as Screedo | ||
| 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. | 07:55 |
| blackflow | teward: apparently consistently after ~17 seconds. | 08:04 |
| 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? | 08:07 |
| coreycb | sahid: nova 19.0.1 uploaded to disco unapproved queue. thanks. | 13:17 |
| sahid | coreycb: ack | 13: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:23 |
| coreycb | jamespage, sahid: i'm going to merge openstack-pkg-tools from experimental. it's basically all debconf changes. | 14:31 |
| sahid | coreycb: ack | 14:35 |
| 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:37 |
| blackflow | teward: right, that's the part I'm trying to pin down now. | 14:38 |
| 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:44 |
| 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. | 14:59 |
| 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:00 |
| 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:01 |
| teward | actually... *wonders about something* | 15:05 |
| 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:18 |
| 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:39 |
| Ademan-remote | Ah, gonna try this `mount -o loop path/to/iso/file/UBUNTUSERVER.ISO /cdrom' | 15:41 |
| 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:44 |
| 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:45 |
| 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:46 |
| Ademan-remote | oh my goodness... | 15:48 |
| 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:49 |
| Ademan-remote | I did notice it was unmounting /cdrom but I didn't notice *when* it was happening heh | 15:50 |
| 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 ;-) | 15:52 |
| teward | nacc: who handles PHP stuff now? | 16:26 |
| powersj | teward, working on getting someone on the team spun up on that | 16:28 |
| powersj | teward, something come up? | 16:28 |
| 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:49 |
| teward | and since I think it's version number dependent, want to make sure I know the version landing for Eoan | 16:50 |
| nacc | teward: sorry was afk | 17:05 |
| 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:06 |
| teward | lol | 17:07 |
| teward | nacc: i was just curious what version was landing xD | 17:07 |
| 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:03 |
| sdeziel | keithzg[m]: yes, that's normal. Live patches won't change what uname reports | 21:04 |
| sdeziel | keithzg[m]: furthermore, you also should/need to deploy regular patches so that when you reboot you get the -51 kernel proper | 21:05 |
| 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:07 |
| 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:08 |
| sdeziel | keithzg[m]: you can check which CVEs are live patched with: canonical-livepatch status --verbose | 21:10 |
| 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:11 |
| 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:13 |
| sdeziel | or maybe not even live patch'able since it was essentially ripping out a.out support IIRC | 21:14 |
| 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:16 |
| keithzg[m] | Yeah and the server I have in question sure isn't running i386 anyways, heh | 21:17 |
| sudoISS | So, if `sudo adduser username` creates the user "username", wouldn't `sudo adduser username groupname` make "groupname" "username"'s primary group? | 22:25 |
| OerHeks | no, secondary, the primary group is used by default when creating new files (or directories), modifying files, or executing commands. | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!