| leftyfb | aloini: ntpd or chrony | 00:25 |
|---|---|---|
| leftyfb | aloini: also, something is seriously wrong with whatever is writing to that media.log. It's 2 weeks ahead of time | 00:26 |
| twb | Whatever is writing "media.log" is broken and not using RFC 3339 timestamp format. | 00:27 |
| twb | The fact that timedatectl indicates "NTPSynchronized=yes" is usually sufficient. As long as the system is running for at least 6 minutes without a reboot, that will automatically get commited to the hardware clock. | 00:28 |
| twb | That looks to me like you're running timesyncd's built in SNTP client, which is accurate to about 1 second. If you need better accuracy, or you expect targeted attacks, you can use ntpsec (full NTP), preferably with an NTS-capable NTP server. | 00:30 |
| twb | What you've pasted so far looks like someone ran datefudge on whatever wrote media.log | 00:31 |
| twb | Bleh, looks like if you want NTS right now you have to trust either Sweden or USA | 00:34 |
| === ijohnson|lunch is now known as ijohnson | ||
| === vlm_ is now known as vlm | ||
| Chr15P_1968 | Hi, I need to configure grub2 to ask for a login when you want to edit any of the menu entries, The only guides I could find requires you to use a username and password when the system boots. We are moving from Centos to Ubuntu so I'm a bit new to the Ubuntu way of things, was a simple excersize on grub that ships with Centos to achieve what I | 07:30 |
| Chr15P_1968 | needed. Is there a way in grub2 that ships with Ubuntu 20.04? | 07:30 |
| Hamidreza | Hi guys, what is LimitMEMLOCK and the eefect of adjusting it in systemd on service? | 09:42 |
| twb | Chr15P_1968: if you have a RHEL system around, look at /boot/grub/grub.cfg there | 11:19 |
| twb | Hamidreza: "man systemd.directives" is the index; it will tell you which manpage covers LimitMEMLOCK. That happens to be a ulimit, so also see /etc/security/limits.conf | 11:21 |
| twb | Hamidreza: in general LimitX= are not useful except to increase LimitNoFile= in rare cases. | 11:21 |
| twb | Hamidreza: for actual security hardening, run "systemd-analyze security" and "systemd-analyze security my-cool-unit.service" | 11:21 |
| Chr15P_1968 | @twb, we are currently running centos VMs and protecting grub2 menu entries. https://paste.ubuntu.com/p/K3yzDyM8DM/ shows the steps I used. | 11:48 |
| twb | if they're VMs don't bother with grub at all | 11:49 |
| twb | just tell libvirtd the kernel and ramdisk to boot directly | 11:49 |
| Chr15P_1968 | I will look into it, how will you boot into rescue mode for example | 11:50 |
| twb | http://ix.io/2PJ1 | 11:51 |
| twb | Chr15P_1968: if you need rescue mode then you need access to edit the VM's boot options | 11:51 |
| twb | Which if they have they can always just bypass grub anyway by adding an ISO | 11:51 |
| twb | Chr15P_1968: anyway, the steps you pasted sound reasonable for ubuntu also | 11:53 |
| Chr15P_1968 | True | 11:53 |
| twb | interesting that you are using EFI in VMs since currently that prevents snapshots in libvirtd | 11:53 |
| Chr15P_1968 | update_grub doesn't read 01_users file, I created the file. also grub2-setpassword isn't installed. Trying to see if I need to install a package that provided the tool | 11:58 |
| twb | use apt-file to see if it has another package or name | 12:02 |
| twb | re 01_users the path might be slightly different, I don't know offhand | 12:03 |
| twb | I don't use grub myself so I don't know without digging and ICBF | 12:03 |
| Hamidreza | twb, I know what is limitx but I don't know what is Memory lock (MEMLOCK) | 12:11 |
| twb | Hamidreza: did you read the references I cited? | 12:12 |
| Hamidreza | twb, Yes but it wasn't MEMLOCK in it | 12:13 |
| Hamidreza | I can't understand what it will do? | 12:18 |
| kierank | Has the "alternate" installer for ubuntu server been deprecated? | 13:12 |
| ogra | kierank, https://discourse.ubuntu.com/t/server-installer-plans-for-20-04-lts/13631 | 13:14 |
| ogra | (effectively it was deprecared since 16.04 or so, 20.04 just finished that step) | 13:15 |
| kierank | hmm ok. It's very annoying as it turns on autoupdates by default | 13:15 |
| ogra | that has nothing to do with the installer | 13:16 |
| kierank | sure, but the alternate one didn't | 13:16 |
| rbasak | I'm pretty sure it did | 13:17 |
| kierank | no, you get a choice | 13:17 |
| ogra | installing security updates automatically has been a default of apt and unattended-upgrades for a while already | 13:18 |
| ogra | and thats really not an installer option | 13:18 |
| kierank | In the alternate installer you get the choice of whether you want this or not | 13:19 |
| rbasak | In any case, does it matter if it's an installer option or not? Server users will be customising their servers immediately after install anyway; otherwise what's the point of installing server? So just customise as you wish in the process you're already using after installation. | 13:19 |
| ogra | thats definitely a bug ... but since that installer isnt supported anyway, thats a moot point | 13:20 |
| kierank | We see sometimes kernels randomly updating in the field and dkms modules breaking | 13:20 |
| ogra | (if it would be supported i'm sure that option would have been removed) | 13:20 |
| kierank | and it's the fault of people using the new installer and having autoupdates on by default | 13:21 |
| kierank | and assuming the behaviour was like the old one | 13:21 |
| ogra | not really | 13:21 |
| ogra | its the fault of the dkms stuff breaking ... but surely not the fault of apt updating things | 13:21 |
| rbasak | Regressions are bad and they shouldn't happen, so sorry about those. But I think you've got the wrong root cause here. It's *far worse* if users aren't installing security updates without realising that they're not. | 13:21 |
| ogra | file bugs about these issues and get them fixed ... | 13:22 |
| kierank | I'm reporting what is happening in the real world, if you don't like it that's not my fault. But you can't blame users for change in behaviour | 13:22 |
| kierank | (cf: linus rants about this) | 13:22 |
| rbasak | Where did we blame users? | 13:22 |
| kierank | 14:19:43 <rbasak> In any case, does it matter if it's an installer option or not? Server users will be customising their servers immediately after install anyway; otherwise what's the point of installing server? So just customise as you wish in the process you're already using after installation. | 13:23 |
| ogra | you are nmot reporting anything ... you are complaining about the installer ... | 13:23 |
| rbasak | How is that blaming users? | 13:23 |
| ogra | reporting bugs happens on launchpad 🙂 | 13:23 |
| rbasak | I'm just saying that if you want to customise your installation, you have an opportunity to do so. | 13:23 |
| kierank | Because you assume the users now have to check quite complex config files for something that they had a choice of before | 13:23 |
| rbasak | That's still not blaming users. | 13:23 |
| kierank | It is | 13:23 |
| kierank | The config files are quite complex and require multiple changes | 13:24 |
| rbasak | Ubuntu makes decisions about defaults. That's part of what Ubuntu is. Part of the origin of Ubuntu is *not* asking users a bunch of questions. | 13:24 |
| kierank | Whereas in alternate, you had one option | 13:24 |
| rbasak | It's entirely up to the Ubuntu project what the defaults should be, and what's appropriate to prompt during installation and what isn't. | 13:24 |
| kierank | It was clear-cut before, now you have to edit config files based on guesses from stackoverflow | 13:24 |
| rbasak | It's fine that you have a difference of opinion on that, and debates about what the defaults should be are welcome. | 13:24 |
| kierank | great user epxerience | 13:24 |
| rbasak | Not asking users a gazillion questions does make for a better user experience, yes. It's part of what gave Ubuntu early success over Debian. | 13:25 |
| rbasak | If users disagree with defaults, there's usually a customisation option available. | 13:25 |
| kierank | changing behaviour without telling them is not helpful | 13:25 |
| kierank | Is there actually an official way to disable autoupdates on server | 13:26 |
| kierank | that doesn't involve stackoverflow guessing and incantations | 13:26 |
| rbasak | Automatic security updates have been default in Ubuntu for many releases. | 13:26 |
| rbasak | There has been no change in behaviour. | 13:26 |
| rbasak | In the sense of what is default, anyway. | 13:26 |
| kierank | I don't know how to break this down to you: Before: clear option to turn them off in installer. After: ??? | 13:27 |
| rbasak | Changing what set of questions get asked in the installer can be expected to happen from release to release anyway. | 13:27 |
| kierank | Go to stackoverflow and guess | 13:27 |
| kierank | until it breaks in production | 13:27 |
| kierank | because there is an edge case in another random config file | 13:27 |
| kierank | https://askubuntu.com/questions/1167314/disable-automatic-updates-ubuntu-18-04 | 13:27 |
| kierank | people are literally guessing | 13:27 |
| kierank | https://help.ubuntu.com/lts/serverguide/automatic-updates.html | 13:27 |
| kierank | goes nowhere | 13:27 |
| rbasak | So we need a better answer there. | 13:27 |
| kierank | Blaming the users here is not helpful at all | 13:28 |
| ogra | who is blamingh users | 13:28 |
| rbasak | In any case, turning off automatic updates without putting an alternative management solution in place is *a really bad thing to recommend that users do*. | 13:28 |
| kierank | 14:19:43 <rbasak> In any case, does it matter if it's an installer option or not? Server users will be customising their servers immediately after install anyway; otherwise what's the point of installing server? So just customise as you wish in the process you're already using after installation. | 13:28 |
| kierank | Assumes users can somehow understand how to disable autoupdates via telepathy | 13:29 |
| rbasak | I don't think this conversation is being productive any more. | 13:29 |
| rbasak | I think I've made my position clear. | 13:29 |
| rbasak | No point in continuing. | 13:29 |
| kierank | Yes your point is "Blame the users" we get that | 13:29 |
| rbasak | It is not. | 13:29 |
| kierank | They must somehow guess how to go back to the old behaviour | 13:29 |
| kierank | Please let me know the official way to disable autoupdates | 13:29 |
| kierank | That used to work in alternate? | 13:29 |
| rbasak | You might be able to use "dpkg-reconfigure -plow unattended-upgrades" or something like that to see the old prompt and get the old behaviour. I would test that though. | 13:31 |
| kierank | QED | 13:31 |
| ogra | https://help.ubuntu.com/community/AutomaticSecurityUpdates | 13:31 |
| kierank | ogra: that's to turn them on | 13:32 |
| * ogra sighs and goes to do something useful instead | 13:32 | |
| kierank | It was one option field in alternate, it's now a huge complex config file | 13:32 |
| kierank | with lots of edge cases | 13:32 |
| kierank | as I understand it, I've followed most of the online guides | 13:33 |
| kierank | but random packages were still being updated | 13:33 |
| isostatic | rm -R /etc/apt | 13:34 |
| kierank | I think the way to do it is "systemctl disable --now apt-daily{,-upgrade}.{timer,service}" | 13:35 |
| kierank | But who knows, I'll only find out at 2am when things are broken | 13:35 |
| rbasak | I wouldn't recommend that, as I think it'll also disable the motd message that informs you when security updates are available. | 13:35 |
| kierank | So please let me know the official way to do it as it used to work in alternate? | 13:36 |
| ogra | or just follow the guide i gave you above and call "sudo dpkg-reconfigure --priority=low unattended-upgrades" ... which gives you EXACTLY !!!!! what debian-installer could give you ... | 13:36 |
| kierank | I can file a ticket on launchpad but we'll rehash the same arguments | 13:36 |
| rbasak | I already made a suggestion. | 13:36 |
| ogra | in either case, you should file a bug about the exact breakage you see with dkms pieces, so it can be fixed ... making ubuntu more insecure is *NOT* the solution | 13:38 |
| kierank | I have no idea how to reproduce said bug. Just wait for the next kernel update | 13:38 |
| kierank | If you install the kernel manually dkms works fine | 13:38 |
| rbasak | Some DKMS breakages were a result of bug 1915051, which I'm just reviewing the fix for as it happens. | 13:38 |
| ubot3 | Bug 1915051 in dkms (Ubuntu Hirsute) "dkms-autopkgtest: Also select binary packages that depends on dkms for testing" [High, In Progress] https://launchpad.net/bugs/1915051 | 13:38 |
| kierank | So in a practical world the only way to fix this is to turn off autoupdates | 13:39 |
| rbasak | It's how some DKMS packages skipped QA by accident. | 13:39 |
| kierank | I have this issue on 18.04 btw | 13:39 |
| rbasak | Help to better document things that the community often want to do are welcome. Though IMHO any documentation on turning automatic updates off should come with a dire warning about getting an alternative solution in place to get security updates, as not doing so is completely irresponsible. | 13:41 |
| rbasak | Help to fix regressions is also welcome. | 13:41 |
| rbasak | I don't see us adding a prompt to the installer though. The best place to debate that is probably https://discourse.ubuntu.com/c/server/17, but ultimately it's a trade-off, a decision needs to be made, and so people on one side are going to be disappointed. That's no reason not to help with the above two points though. | 13:43 |
| kierank | I don't think I'm getting the same issue here | 13:46 |
| kierank | How do I simulate a kernel update that the auto updater would do as opposed to one that is done by the user? | 14:03 |
| rbasak | I think you can just run "unattended-upgrades" | 14:06 |
| rbasak | Perhaps with --dry-run if you want | 14:06 |
| kierank | I suppose if I install without internet connection I won't get updates the first time | 14:06 |
| kierank | then I could try doing an unattended upgrade as soon as I enable the connection | 14:07 |
| sigv | I think you want the following apt configs: APT::Periodic::Update-Package-Lists "0"; APT::Periodic::Unattended-Upgrade "0"; | 14:08 |
| kierank | I did that, it wasn't enough | 14:08 |
| sigv | Unattended-Upgrade::Allowed-Origins {}; ? | 14:09 |
| kierank | don't know | 14:09 |
| sigv | would be helpful for us to know what you tried to configure so far. | 14:09 |
| kierank | those two as stackoverflow says | 14:09 |
| kierank | and then I got an unexpected update | 14:09 |
| kierank | So I did "systemctl disable --now apt-daily{,-upgrade}.{timer,service}" | 14:09 |
| kierank | and that seems to stop things | 14:10 |
| kierank | But I would rather understand why dkms fails on auto update | 14:10 |
| kierank | but not on normal user prompted upgrade | 14:10 |
| sigv | As mentioned above, I do not think you should be disabling apt-daily.service / apt-daily.timer "Daily apt download activities" | 14:10 |
| kierank | Sure, I'm just trying to fix the problem now | 14:11 |
| kierank | To not be woken up in the early hours | 14:11 |
| sigv | The apt-daily-upgrade.service / apt-daily-upgrade.timer disablement might make sense, but I do not think you should be just out-right disabling them tbh. | 14:11 |
| sigv | Could just set up a Unattended-Upgrade::Package-Blacklist {}; | 14:11 |
| sigv | for your kernel and dkms concerns and then have a separate workflow for those. | 14:12 |
| sigv | For the previous point, if you are managing a fleet = just put appropriate configurations in your orchestration, and installer defaults do not matter. If you are managing just a few servers and do not have orchestration in place, then just reconfigure unattended-upgrades. | 14:13 |
| sigv | Actually wonder if you could just uninstall `unattended-upgrades` package, but hey. | 14:13 |
| sigv | No, seems like a bad idea. Anyhow. | 14:14 |
| dwigton | I set up a trunk port to my machine that only allows vlans 1 and 20. the Native vlan is set to 100 and isn't actually a thing. Since untagged traffic won't get passed how do I tell ubuntu to use enp0s25.1 instead of enp0s25? | 14:23 |
| dwigton | I can get in fine since ssh uses vlan 1 but if I try to run updates ubuntu tries to make requests over enp0s25 which is untagged and of course nothing happens. | 14:25 |
| twb | dwigton: in netplan or in networkd? | 14:28 |
| dwigton | twb: netplan | 14:29 |
| twb | No idea about netplan, sorry | 14:29 |
| dwigton | How do you do it in networkd? maybe the ideas will give me a clue? | 14:30 |
| twb | Edit /etc/systemd/network/00-upstream.network and fiddle with VLANId= I think | 14:31 |
| twb | Oh it's just VLAN= | 14:32 |
| dwigton | I am tempted to try to give enp0s25 an id and see what happens. the worst is that I have to drag a monitor and keyboard to the "server" *cough* NUC to recover. | 14:32 |
| twb | EgressUntagged=20 looks like the specific option you would want in systemd | 14:32 |
| twb | dwigton: yeah I 100% hate devices that still don't have HTML5 BMCs | 14:33 |
| dwigton | hmm. the netplan documentation is either horrible or I am dumb. | 14:39 |
| twb | could be both! :-) | 14:40 |
| twb | I was considering Ubuntu for its better secure boot <-> zfs integration, but took one look at netplan and just went "noooooope" | 14:41 |
| twb | Too close to network-manager bricking wired interfaces back in 2010 | 14:41 |
| === ijohnson is now known as ijohnson|lunch | ||
| Ussat | Is anyone here familiar with MAAS ? | 20:06 |
| rbasak | Try #maas | 20:08 |
| Ussat | thank you | 20:10 |
| Ussat | was unaware | 20:10 |
| Ussat | Heh, seems to not be hight traffic, but thats ok I am patient | 20:13 |
| rbasak | Yeah it might take a while | 20:15 |
| twb | Ussat: it is always useful to "/msg alis help" on Freenode, and "/list help" on OFTC. | 20:15 |
| Ussat | ya ya | 20:15 |
| === StathisA_ is now known as StathisA | ||
| === ijohnson|lunch is now known as ijohnson | ||
| * enyc meows | 20:31 | |
| enyc | curious -- will ubuntu-server releases tend to include/defaust to kernel 5.4 LTS always ? | 20:31 |
| enyc | rather than HWE as per 20.04.2 desktop etc | 20:32 |
| RoyK | ubuntu 30.04 will probably not default to that kernel ;) | 20:32 |
| sarnold | enyc: I believe the server installers do default to the "ga" kernel and offer the hwe kernel as an option during install | 20:33 |
| enyc | RoyK: aah yes true | 20:37 |
| rbasak | Ubuntu Server 20.04.2 was released with HWE as an option. | 20:55 |
| rbasak | https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Installer | 20:55 |
| rbasak | "Starting from Ubuntu Server 20.04.2 the ISO images can optionally boot the installer using the HWE kernel. In this case the installed system will automatically make use of the HWE stack." | 20:56 |
| === hggdh changed the topic of #ubuntu-server to: Ubuntu Server discussion and support | For general (not server specific) support, try #ubuntu | IRC Guidelines: https://wiki.ubuntu.com/IrcGuidelines | home: https://wiki.ubuntu.com/ServerTeam | Docs and resources: https://ubuntu.com/server/docs | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!