| === y0sh- is now known as y0sh_ | ||
| === toabctl_ is now known as toabctl | ||
| === Ps1-Jack is now known as Psi-Jack | ||
| === paride7 is now known as paride | ||
| === ivoks_ is now known as ivoks | ||
| === masACC is now known as maswan | ||
| === paride2 is now known as paride | ||
| === slyon_ is now known as slyon | ||
| === Casper26_ is now known as Casper26 | ||
| === bahama- is now known as bahamat | ||
| === bahamat is now known as bahama- | ||
| === ubot3 is now known as ubottu | ||
| === rafaeldtinoco_ is now known as rafaeldtinoco | ||
| === priteau_ is now known as priteau | ||
| === odc_ is now known as odc | ||
| === zerosum is now known as Guest8097 | ||
| === Morpheus is now known as Guest4177 | ||
| === cwaydt5 is now known as cwaydt | ||
| === bahamat_ is now known as bahamat | ||
| === bahamat is now known as bahamat_ | ||
| znf | Hi | 10:52 |
|---|---|---|
| znf | How exactly do you add a certificate to the trust root in Ubuntu? | 10:53 |
| znf | context: we have some clients who are running old crap (16.x) and since yesterday with the expiration of DTS's X1, obviously their app can't connect to our API anymore (as we use LE) | 10:54 |
| znf | I've deployed a 16.04 VM to try to reproduce and/or provide instructions on how to get the new root accepted, but I'm failing on it | 10:54 |
| ogra | znf, https://ubuntu.com/security/notices/USN-5089-1 | 11:13 |
| znf | yeah, that's >18.04 tough :) | 11:13 |
| ogra | well, the linked bug lists xenial as fix released too | 11:15 |
| znf | ah, didn't notice that, thanks | 11:16 |
| === Guest4177 is now known as Mekaneck | ||
| === waveform_ is now known as waveform | ||
| === Morpheus is now known as Guest2215 | ||
| === Guest2215 is now known as Mekaneck | ||
| === smoser1 is now known as smoser | ||
| === bahamat_ is now known as bahamat | ||
| xnox | znf: enable ESM and upgrade. | 15:13 |
| xnox | znf: Ubuntu 16.04 has all of letsecnrypt stuff fixed in ESM (gnutls, openssl, ca-certificates) https://ubuntu.com/security/esm | 15:13 |
| === ddstreet_away is now known as ddstreet | ||
| Odd_Bloke | Hey folks, when we're performing maintenance on one of our machines, we'd like to take that opportunity to apply apt upgrades. Specifically, for consistency with how it happens at other times, we'd like to manually run unattended-upgrades. I know that it's split into separate fetch and install steps: does `unattended-upgrade` run both of those at once, or should we prefer starting apt-daily.service | 17:22 |
| Odd_Bloke | and then apt-daily-upgrade.service? | 17:22 |
| xnox | Odd_Bloke: disabling timers; and running .service units sounds best. | 17:26 |
| xnox | Odd_Bloke: but that will not apply everything. i.e. only security; not updates. | 17:26 |
| Odd_Bloke | xnox: To be clear, we do want it to also run when the timers kick it off: this is just opportunistic to take whatever package install cost we might have waiting while a machine is already in maintenance. (So I assume we can just leave the timers enabled?) | 17:27 |
| Odd_Bloke | Yeah, we have additional config in there so it does what we want (which is also why we want to run *it*, rather than applying upgrades another way). | 17:28 |
| JanC | xnox: wouldn't only security vs. also updates depend on the configuration of unattended-upgrades ? | 18:17 |
| JanC | as in: that's the default, but you can change it? | 18:17 |
| === sarnold_ is now known as sarnold | ||
| Odd_Bloke | Yep, you can configure it (and we do): xnox was describing the default behaviour. | 19:20 |
| === genii is now known as genii-core | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!