marsisalie's questions

Então, estou usando o Stretch como servidor de produção para um pequeno escritório de pesquisa acadêmica.

Tive uns bons ~ 500 ou mais dias de tempo de atividade e mantive-o atualizado à medida que as atualizações rolavam.

Neste verão, o Stretch foi retirado do LTS. Então atualizei para 10, depois 11 (Bullseye). Desde então, sinto que tenho que reiniciar após uma atualização do kernel, talvez, uma vez por mês? (Reiniciado duas vezes desde junho, quando atualizei o sistema operacional).

Estou um pouco irritado por ser 'forçado' a reiniciar com tanta frequência para que as alterações sejam aplicadas. Preciso encontrar janelas de tempo e/ou aconselhar a base de usuários para evitar a interrupção do serviço. E bem, é novo para mim que uma distribuição Linux precisava ser reiniciada com tanta frequência para se manter atualizada. (Além disso, mas não tão importante, penso no meu recorde de tempo de atividade que precisa ser superado!)

Existe este post aqui dizendo que é recomendado reiniciar após as atualizações do kernel Debian: Atualização do kernel usando APT - reinicialização necessária para ter efeito? que eu entendo, mas antes não era assim, não é?

Existe um novo paradigma para o Debian onde as reinicializações não eram obrigatórias antes do Bullseye, mas agora são?

Estamos trabalhando em uma solução de software e alguns de nossos provedores são realmente centrados no CentOS 7.

O CentoS 7 continuará a produzir durante o restante do ciclo de vida do RHEL 7, que terminará em algum momento de 2024.

O CentOS 8 receberá atualizações até dezembro de 2021.

O CentOS Stream foi anunciado pela Red Hat, mas aparentemente não é um substituto para o CentOS.

Não sou muito de mergulhar nisso se as opções forem incertas no futuro próximo com o CentOS.

Pergunta: quais são as opções para usuários do CentOS 7 quando o RHEL 7 chega ao fim de sua vida útil e os usuários precisam de um servidor pronto para produção?

Temos uma máquina física atendendo bancos de dados e sites. Queremos contratar um consultor para essa migração planejada da máquina Windows física mais antiga para uma nova máquina virtual atualizada.

Obviamente, o contratante precisará de uma conta com privilégios para que isso aconteça. Nesse caso, eu confio neles, mas, ao mesmo tempo, e se eu não confiar neles ou não souber o suficiente sobre eles para confiar inteiramente neles? Eu estava procurando as melhores práticas quando isso acontece (você não sabe se confia no contratante). E se eles colocarem uma porta dos fundos? Ou por engano ou apenas sem saber, fazer algo que possa comprometer mais tarde a nova máquina?

Minha pergunta : Quais são as melhores práticas para preparar um plano de segurança ao contratar um contratado externo para fazer coisas em nosso site que exigem uma conta com privilégios?

Encontrei esta resposta: Prática recomendada para fornecer ao administrador do servidor acesso root (no CentOS)? mas estava visando um Linux Flavor, e possivelmente é datado. Eu gosto da sugestão de definir uma Declaração de Trabalho, que vou considerar, mas também estava procurando soluções técnicas.