=== Napsterbater_ is now known as Napsterbater
=== cpaelzer__ is now known as cpaelzer
=== cpaelzer__ is now known as cpaelzer
=== mIk3_09 is now known as mIk3_08
=== jelly-home is now known as jelly
[12:41] <weedmic> re:  intel-microcode 3.20191115.1ubuntu0.18.04.2 - pls provide link so I can see exactly what is going to change
[12:42] <weedmic> or, better, is this firmware change - or just software inside the kernel?
[12:47] <martiansoul> I want to record only the time when there is a cache hit and not a cache miss using curl. that's the value contained in `x-cache`(hit or miss) in response header.
[12:51] <OerHeks> weedmic, easy to find, https://launchpad.net/ubuntu/+source/intel-microcode/3.20191115.1ubuntu0.18.04.2 diff, changes
[12:51] <weedmic> Q!
[12:53] <weedmic> exactly what I needed - appreciated
[12:54] <weedmic> brb - needs a reboot
[13:07] <OerHeks> https://usn.ubuntu.com/4182-4/ A regression was discovered that caused some Skylake processors to hang after a warm reboot.
=== cpaelzer__ is now known as cpaelzer
[19:50] <evit> I'm trying to setup Amazon SES for sending TLS enabled email. Using the documentation here https://docs.aws.amazon.com/ses/latest/DeveloperGuide/postfix.html
[19:51] <evit> Evidently the Amazon documentation is wrong and it is giving me an error...  cannot load Certification Authority data, CAfile="/etc/ssl/certs/ca-bundle.crt": disabling TLS support
[19:54] <sarnold> compare against https://help.ubuntu.com/lts/serverguide/postfix.html which should do a better job describing debian/ubuntu tls configs
[20:08] <evit> sarnold, Do I need to generate a TLS certificate?
[20:08] <sarnold> evit: I'm not sure, I haven't hosted email in the modern era
[20:09] <evit> sarnold, I'm sending only through Amazon SES
[20:11] <evit> sarnold, When I switch my smtp_tls_CAfile to /etc/ssl/certs/ca-certificate.crt in main.cf it works without issue.
[20:11] <sarnold> yay
[20:15] <WILYLP86> hi everyone
[20:19] <evit> sarnold, This looks like the correct path https://www.webmoves.net/blog/build/send-email-from-ubuntu-linux-via-amazon-ses-3139/
[20:19] <evit> now I get no errors and mail is flowing w/ TLS
[20:19] <sarnold> very nice, thanks for the link
=== RoyK^ is now known as RoyK
[20:28] <teward> sarnold: i see email hosting questions
[20:28] <teward> ... and I run my own email ;)
[20:28] <teward> a little bit late I know but...
[20:28] <sarnold> hey teward :)
[20:28] <evit> teward, Hi
[20:29] <evit> teward, Amazon SES documentation seems to be wrong on Ubuntu to SES config
[20:29] <evit> https://docs.aws.amazon.com/ses/latest/DeveloperGuide/postfix.html
[20:30] <evit> teward,  This looks like the correct path https://www.webmoves.net/blog/build/send-email-from-ubuntu-linux-via-amazon-ses-3139/
[20:30] <evit> teward, Correct CA file is sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
[20:30] <evit> Amazon doesn't have enough $$$ to have correct docs. =P
[20:31] <teward> well... in 18.04 /etc/ssl/certs/ca-certificates.crt *is* a valid path...
[20:31] <teward> and unless you're blind, the section stating "If you use Ubuntu or a related distribution, type the following command:" is using the ***correct command*** you just stated
[20:31] <teward> ;)
[20:31] <teward> point 7 bullet point #2
[20:31] <teward> soooooooooooooooooooooooo
[20:31] <sarnold> teward: the thing is that th e docs were written for rh-derivatives that use CAfile="/etc/ssl/certs/ca-bundle.crt": instead
[20:31] <sarnold> ah
[20:31] <teward> sarnold: correction:
[20:31] <teward> there's multiple bullet points
[20:31] <teward> and you have to ***actually read*** to know which command(s) to run ;)
[20:32] <teward> so this is a case of PEBKAC and not reading the document properly
[20:32] <evit> teward, don't be a passive aggressive d-wad
[20:33] <evit> I see it now
[20:33] <teward> that wasn't my intention
[20:33] <teward> but if you want to call names
[20:33] <teward> *goes to do something else more productive with his time*
[20:33] <pgnd> I've got an Ubu18LTS server up.  /boot is small. kernel HWE 18 *is* installed/enabled.  Kernels in place are 4.15.0-72, 5.0.0-36 & 5.0.0-37 (running).
[20:34] <pgnd> If I apt remove 4.15.0-72 & friends, the action is: "linux-generic linux-headers-4.15.0-72 linux-headers-4.15.0-72-generic linux-headers-generic linux-image-4.15.0-72-generic linux-image-generic linux-modules-4.15.0-72-generic linux-modules-extra-4.15.0-72-generic linux-tools-4.15.0-72
[20:34] <pgnd>   linux-tools-4.15.0-72-generic linux-tools-generic"
[20:34] <pgnd> is it 'safe' to remove the unversioned "linux-generic" & "linux-headers-generic"?
[20:34] <pgnd> or 4.15x in general?
[20:35] <WILYLP86> I have an active directory in samba4 and I need to know if there is any way to store a user's password in SSHA, or another type of hash
[20:35] <sarnold> pgnd: those are how you get updates
[20:36] <pgnd> sarnold: hi.  the 'generic' ones?
[20:36] <sarnold> pgnd: yeah
[20:36] <sarnold> pgnd: those meta-packages are updated to include dependencies on the new kernels when updates are released
[20:37] <pgnd> Hm.  So, since I *do* want updates that come along with the 18HWE, I'm stuck with keeping the 4.15.0x packages around? even though I'll NEVER use them?
[20:38] <sarnold> pgnd: if you're running the HWE kernel then you can remove the release kernels, sure
[20:39] <pgnd> sarnold: sry, I'm being dense.  If I do remove the release kernels, it rm's the 'generic' pkgs, as above.  Then updates don't work, iiuc.  But I *do* want updates ... of the HWE kernels.
[20:39] <pgnd> or are THEY handled by different packates?
[20:39] <sarnold> pgnd: yeah, they are, eg https://launchpad.net/ubuntu/+source/linux-meta-hwe
[20:40] <pgnd> hm.  don't have any *meta* pkgs installed atm ...
[20:40] <pgnd> looking at the link
[20:43] <sarnold> linux-generic-hwe-18.04 perhaps?
[20:43] <pgnd> ah, so 'meta' is not in the naming ... looking at "Built Packages"
[20:44] <sarnold> yeah, source package names don't have to match binary package names. It can be bloody confusing, and the ratsnest of kernel packages is the worst of the lot, I think
[20:45] <pgnd> sarnold: ok, I've got: linux-generic-hwe-18.04 linux-headers-generic-hwe-18.04 linux-hwe-tools-4.8.0-52 linux-image-generic-hwe-18.04
[20:45] <pgnd> installed.  is that^ sufficient to safely REMOVE the 'release' 4.x kernel* ?
[20:45] <lordcirth_> Apt/.deb packages were never designed to have multiple versions installed in parallel, so the kernels with the versions in the names are hacky
[20:45] <sarnold> I literally only make sense of these things because I've got a local archive mirror and can do things like ls -ld main/l/linux*/*hwe*   kinds of things
[20:45] <pgnd> yeah, Ubu-space kernel naming is ... challenging.  Not my usual cup o' tea! ;-)
[20:47] <sarnold> pgnd: that linux-hwe-tools-4.8.0-52 is ~2 years old, probably it can be removed..
[20:47] <pgnd> lordcirth_: I'm generally in suse-land; bit simpler there.  or at least I understand it better :-)
[20:48] <pgnd> hehe, "probably"!  u in Marketing? Sales? ;-p
[20:48] <sarnold> :D
[20:49]  * pgnd holds breath while uninstalling.  bets self $1 that it'll automagically reinstall itself, just to piss me off
[20:50] <sarnold> lol
[20:52] <pgnd> The recent upgrade from 16LTS to 18LTS was 'very greedy' about /boot space.  very Microsoft-like.  had to crib using /boot temporarily on an external USB.  woulda hoped that 250MB for a boot partition was enuf for an upgrade ...
[20:52] <sarnold> oof yeah that's way too tight
[20:53] <pgnd> well, perspective.  the install process is way too fat!
[20:53] <sarnold> even post-install, 256 is going to give you a bad time
[20:54] <pgnd> no clear reason it NEEDS GBs in /boot.  nah, production's just fine.
[20:54] <pgnd>  that's /boot, NOT /root
[20:55] <pgnd> which reminds me ... anyone KnowForCertain(tm) whether 18LTS can/does boot from /boot on RAID-1?  16LTS sure didn't ...
[20:55] <sarnold> 512 megs should be enough for four ~60M initramfses, kernels, symbol maps..
[20:56] <pgnd> sure.  clear how it scales.  just not clear why the installer had that demand.  water under the bride, anyway, now
[20:58] <sarnold> poor bride hope the dress didn't get soaked :)
[20:58] <pgnd> heh, oops.
[20:58] <sarnold> pgnd: there's just something that'll keep around ~four kernels during updates and upgrades and these things aren't small any more..
[20:59] <sarnold> back inthe day I had a linux rescue floppy that could mount ntfs and fix winnt permissions problems.. 1.44 mb.. crazy.
[21:00] <pgnd> yeah, yeah.  I'm 'spoiled'.  In suse it's trivial to specify multiinstalls, what & how many kernels are installed, kept, purged etc.
[21:01] <pgnd> I typically keep boot on LV on RAID 1 or 10.  Then scaling to demand is trivial.  Physical partitions are an annoying PITA.  Which is why I'm looking/hoping (currently, not finding) re: Ubu18 boot on RAID support scope, if any.
[21:04] <pgnd> rm'd the release kernels, rebooted. now, boot's @ "ext4  256M  128M  111M  54% /boot"
[21:04] <pgnd> and no smoke! cool.
[21:15] <sarnold> pgnd: there's something that's missing with raid in boot but I've never taken the time to understand it -- https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1466150
[21:15] <ubottu> Launchpad bug 1466150 in grub-installer (Ubuntu) "grub-install breaks when ESP is on raid" [High,Triaged]
[21:17] <sarnold> pgnd: /etc/kernel/postinst.d/apt-auto-removal /etc/apt/apt.conf.d/01autoremove-kernels may be useful to you too
[21:17] <pgnd> saw that. that's on EFI.  works fine here on "Other OS"; jhas for ages.  That said, on Ubu18, I'd settle for legacy/old-school ...
[21:18] <pgnd> thx 4 the autorm refs
[21:34] <pgnd> my search-fu is NOT strong.  can't seem to find docs, or anecdotal evidence, that it DOES work on non-EFI.
[23:12] <hggdh> lsmod | grep btr
[23:12] <hggdh> darn! sorry