Respostas:
Pode ser seguro - ou, mais precisamente, o nível de risco pode estar dentro do seu alcance. O nível de risco aceitável dependerá de vários fatores.
Você tem um bom sistema de backup que permitirá reverter rapidamente se algo quebrar?
Você está encaminhando os logs do servidor para um sistema remoto para que, se a caixa falhar, você ainda saberá o que aconteceu?
Você está disposto a aceitar a possibilidade de que algo possa quebrar e você pode ter que fazer uma rápida restauração / reversão no sistema se algo falhar?
Você compilou manualmente alguma coisa por conta própria ou absolutamente tudo instalado em seu sistema veio dos repositórios oficiais? Se você instalou algo localmente, é possível que uma alteração upstream possa interromper o software local mantido / instalado.
Qual é o papel deste sistema? É algo que dificilmente se perderia se morresse (por exemplo, um servidor DNS secundário) ou é a parte principal da sua infraestrutura (por exemplo, servidor LDAP ou servidor de arquivos primário).
Deseja configurar isso porque ninguém responsável pelo servidor tem tempo para manter os patches de segurança? O risco potencial de ser comprometido por uma vulnerabilidade não corrigida pode ser maior que o potencial de uma atualização incorreta.
Se você realmente acha que deseja fazer isso, sugiro que você use uma das ferramentas que já existem para esse fim cron-apt. Eles têm alguma lógica para serem mais seguros do que apenas um cego apt-get -y update.
apt-get upgrade, não apt-get update, certo?
apt-get update, é bastante difícil quebrar alguma coisa.
Geralmente é seguro, mas eu não o recomendaria por uma simples razão:
No ambiente de produção, você precisa saber exatamente o que está nele ou o que deveria estar nele e poder reproduzir esse estado com facilidade.
Quaisquer alterações devem ser feitas através do processo de Gerenciamento de Mudanças, onde a empresa está totalmente ciente do que está entrando, para que posteriormente possam analisar o que deu errado e assim por diante.
As atualizações noturnas tornam esse tipo de análise impossível ou mais difícil de fazer.
Eu poderia fazer isso no stable, ou no Ubuntu, mas não em um ramo instável, ou mesmo no ramo de testes.
Embora, quando eu visto meu sysadmin hat, acredito que devo aplicar manualmente todas as atualizações, para manter a consistência entre os servidores - e também para que, se um dia um serviço for interrompido, eu sei quando atualizei a atualização pela última vez. serviço. É algo que talvez eu não verifique se as atualizações estão ocorrendo automaticamente.
Usamos a atualização estável e programada apt-get para terça-feira à noite na maioria dos nossos sistemas Debian (coincide com as atualizações da Microsoft "patch terça-feira"). Funciona bem. Também temos todos os eventos de atualização registrados no Nagios, para que possamos ver um histórico de quando as atualizações foram realizadas pela última vez em qualquer servidor.
Quando você especifica que este é um servidor de "produção", isso significa que também existem servidores de desenvolvimento e teste? Nesse caso, os patches devem ser testados nesses sistemas antes de serem instalados na caixa de produção.
Eu não faria isso. Correções ruins acontecem e eu não gostaria que um sistema falhasse no meio da noite ou enquanto estivesse indisponível. Eles devem ser empurrados em uma janela de manutenção quando um administrador estiver disponível para monitorar a atualização.
Lembro-me de fazer isso em um trabalho anterior; Acabei com problemas no servidor de produção porque uma atualização reescreveu um arquivo de configuração automaticamente.
Portanto, eu aconselho você a supervisionar as atualizações.
Se a alternativa for aplicar irregularmente as atualizações, você não seguirá ativamente as atualizações de segurança e estiver executando um Lenny estável à baunilha; a atualização automática provavelmente aumentará a segurança da sua máquina, pois você atualizará as falhas de segurança conhecidas mais rapidamente.
O Ubuntu Server possui um pacote que permitirá a atualização automática de atualizações de segurança. Ele permite que você coloque na lista negra certos aplicativos também. Ele também fala sobre o apticron, que enviará um e-mail quando houver atualizações disponíveis para o seu servidor.
Você pode descobrir mais sobre isso nas páginas seguintes, dependendo da versão do Ubuntu Server em execução.
EDIT: Supondo que você esteja executando o Ubuntu. Embora eu aposto que os mesmos pacotes e soluções estão disponíveis no Debian.
Isso depende da sua infraestrutura. Se eu tiver uma única máquina, normalmente reviso as atualizações e vejo o que preciso ou o que posso evitar. Se estou usando um cluster, algumas vezes implanto as alterações em uma máquina, vejo como elas acontecem e depois as implico nas outras máquinas, se tudo parecer bem.
Atualizações de banco de dados que eu sempre olho de perto.
Se você possui um sistema de arquivos compatível com captura instantânea, pode ser realmente útil para capturar instantâneos do sistema, aplicar atualizações e, em seguida, ter a opção de reverter as alterações se algo der errado.
Tente descobrir por que um pacote está sendo atualizado? é correção de bug? correção de segurança? é um comando local ou um serviço de rede remota? O software foi testado com as novas atualizações?
As atualizações do kernel devem ser abordadas com mais cautela. Tente descobrir por que o kernel está sendo atualizado? Você realmente precisa dessas mudanças? isso afetará seu aplicativo. Preciso aplicar isso por segurança?
9 em cada 10 atualizações de software ocorrerão sem problemas, mas são os raros momentos em que você deixa o seu computador como uma pilha de lixo, tem um plano de recuperação ou recuperação do sistema.
apt-get upgrade -yvez deupdate? Existe alguma-ybandeira paraupdate?