marsisalie's questions

So I've been using Stretch as a production server for a small academic research office.

Had a nice ~500 or so days of uptime, and I kept it up to date as updates rolled.

This summer, Stretch was phased out from LTS. So I updated to 10, then 11 (Bullseye). Since then, I feel like I have to reboot after a kernel update maybe, once a month ? (Rebooted twice since June when I upgraded the OS).

I am a bit annoyed at being 'forced' to reboot that often for changes to be applied. I need to find time windows and/or advise with userbase to prevent service outage. And well, it is new to me that a Linux distro needed to be rebooted that often to be keep up to date. (Also, but not that important, I think about my uptime record that need to be bested!)

There is this post here saying it is recommended to reboot after kernel upgrades Debian: Kernel update using APT - reboot required to take effect? which I understand, but it was not like that before, isn't?

Is there a new paradigm for Debian where reboots were not mandatory before Bullseye but now are?

We are working on a software solution and some of our providers are really CentOS 7 centered.

CentoS 7 will continue to produce through the remainder of the RHEL 7 life cycle, which will end sometime in 2024.

CentOS 8 will receive updates till December 2021.

CentOS Stream was announced by Red Hat but is apparently not a replacement for CentOS.

I am not very into diving in this if options are uncertain in the near future with CentOS.

Question: what are the options for CentOS 7 users when RHEL 7 reach its end of life and users need a production ready server?

We have a physical machine serving databases and websites. We want to contract a consultant for this planned migration from the older physical Windows machine to an up to date brand new Virtual Machine.

Obviously the contractor will need an account with privileges to make this happen. In this case, I trust them but, at the same time, what if I don't trust them or don't know enough about them to entirely trust them? I was looking for the best practices when this happen (you don't know if you trust the contractor). What if they put a backdoor ? Or by mistake or just without knowing, do something that could later compromise the new machine?

My question: What are the best practices to prepare a security plan when hiring an external contractor to do stuff at our site requiring an account with privileges?

I found this answer : Best practice for providing server admin contractor with root access (on CentOS)? but it was targeting a Linux Flavor, and is possibly dated. I like the suggestion of setting a Statement of Work, which I will consider, but was looking for technical solutions too.