=== 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 | ||
weedmic | re: intel-microcode 3.20191115.1ubuntu0.18.04.2 - pls provide link so I can see exactly what is going to change | 12:41 |
---|---|---|
weedmic | or, better, is this firmware change - or just software inside the kernel? | 12:42 |
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:47 |
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:51 |
weedmic | exactly what I needed - appreciated | 12:53 |
weedmic | brb - needs a reboot | 12:54 |
OerHeks | https://usn.ubuntu.com/4182-4/ A regression was discovered that caused some Skylake processors to hang after a warm reboot. | 13:07 |
=== cpaelzer__ is now known as cpaelzer | ||
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:50 |
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:51 |
sarnold | compare against https://help.ubuntu.com/lts/serverguide/postfix.html which should do a better job describing debian/ubuntu tls configs | 19:54 |
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:08 |
evit | sarnold, I'm sending only through Amazon SES | 20:09 |
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:11 |
WILYLP86 | hi everyone | 20:15 |
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 | 20:19 |
=== RoyK^ is now known as RoyK | ||
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:35 |
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:36 |
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:37 |
sarnold | pgnd: if you're running the HWE kernel then you can remove the release kernels, sure | 20:38 |
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:39 |
pgnd | hm. don't have any *meta* pkgs installed atm ... | 20:40 |
pgnd | looking at the link | 20:40 |
sarnold | linux-generic-hwe-18.04 perhaps? | 20:43 |
pgnd | ah, so 'meta' is not in the naming ... looking at "Built Packages" | 20:43 |
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:44 |
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:45 |
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:47 |
pgnd | hehe, "probably"! u in Marketing? Sales? ;-p | 20:48 |
sarnold | :D | 20:48 |
* pgnd holds breath while uninstalling. bets self $1 that it'll automagically reinstall itself, just to piss me off | 20:49 | |
sarnold | lol | 20:50 |
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:52 |
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:53 |
pgnd | no clear reason it NEEDS GBs in /boot. nah, production's just fine. | 20:54 |
pgnd | that's /boot, NOT /root | 20:54 |
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:55 |
pgnd | sure. clear how it scales. just not clear why the installer had that demand. water under the bride, anyway, now | 20:56 |
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:58 |
sarnold | back inthe day I had a linux rescue floppy that could mount ntfs and fix winnt permissions problems.. 1.44 mb.. crazy. | 20:59 |
pgnd | yeah, yeah. I'm 'spoiled'. In suse it's trivial to specify multiinstalls, what & how many kernels are installed, kept, purged etc. | 21:00 |
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:01 |
pgnd | rm'd the release kernels, rebooted. now, boot's @ "ext4 256M 128M 111M 54% /boot" | 21:04 |
pgnd | and no smoke! cool. | 21:04 |
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:15 |
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:17 |
pgnd | thx 4 the autorm refs | 21:18 |
pgnd | my search-fu is NOT strong. can't seem to find docs, or anecdotal evidence, that it DOES work on non-EFI. | 21:34 |
hggdh | lsmod | grep btr | 23:12 |
hggdh | darn! sorry | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!