Re: Atualizações do debian!
Em 02/02/07, Felipe Augusto van de Wiel
(faw)<felipe@cathedrallabs.org> escreveu:
On 02/02/2007 02:06 AM, Marcos Lazarini wrote:
[...]
Hmmm... se a configuração estiver correta, ele não vai
perguntar, parece que você não está entendendo isso. Você pode
fazer o mesmo que fez com o cron de outra forma, usando o cron.d
e sem ter conflitos.
Fui atrás do caso que originou essa discussão, p/ mostrar p/ vc
EXATAMENTE o que houve. Veja só:
$ cat /etc/cron.d/clamav-freshclam
37 2 */1 * * clamav [ -x /usr/bin/freshclam ] && /usr/bin/freshclam
/dev/null
$ cat /etc/cron.d/clamav-freshclam.dpkg-dist
-43 */1 * * * clamav [ -x /usr/bin/freshclam ] &&
/usr/bin/freshclam >/dev/null
O arquivo de cima é o que eu tenho instalado hoje, e o debaixo era o
do pacote. Não gostaria de entrar no mérito se deveria ou não mexer
nesse arquivo, pois a princípio, não vi indicação de não mexer (até pq
não concordo com a configuração atual que meu colega colocou lá - mas
não está errado e funciona - ao contrário do que vc assumiu ai em
cima).
Esse foi o caso que originou essa discussão, que tava ficando muito
abstrata (há essa opção, aquela possibilidade, tal alternativa) mas
nenhuma das propostas resolveria esse conflito que tive ai em cima.
Qual a sua visão desse caso? Fiz algo que não devia (alterar o
/etc/cron.d/clamav-freshclam)? O que houve foi ou não um bug?
O apt e o cron-apt tem configurações que permitem certa
flexibilidade na hora de tomar ações quanto a decisões, além
disso, é como eu disse, pode ser que você prefira ficar com
seu servidor vulnerável ao invés de perder suas configurações,
essa é a opção de cada sysadmin.
De novo, vc está falando que a atualização vai 'corrigir' meus
problemas de configuração... não sabia que o apt tinha inteligencia
artificial também p/ saber o que é configuração certa e errada :-)
Quando tem alguma modificação importante (acontece as vezes no
testing), vem um arquivo NEWS no pacote que é mostrado no momento da
atualização (pelo menos comigo é assim). Eu acho que isso é suficiente
p/ avisar ao administrador de que houve uma mudança significativa no
modo de lidar com algo, e que tome as providencias necessárias p/ se
adequar.
> (ainda comentando sobre o cron: outra coisa que fiz foi mudar o
> horário padrão dos cron.{daily|weekly|monthly}, pois são todos 6 e
> pouco por padrão. Alguns programas, como o locate, logcheck (p/ citar
> dois), demoram um certo tempo, e ai o cron de um período encavalava no
> outro, a maquina usava swap, etc e tal)
Pra isso existe divert e outros recursos, pra não
perder a configuração, ou você acha que é a única pessoa
do mundo que muda esses horários? :)
Vc está se referindo ao dpkg-divert? que alias eu não conhecia.
O problema ia ser eu adivinhar/lembrar que tinha que usá-lo... Se essa
for a solução correta, deveria ter um aviso mais claro.
>> Então eu acho que você não cuida de servidores críticos.
>> É melhor ter o serviço seguro por default do que sua configuração
>> querida. :-)
>
> Certamente a configuração padrão funciona, mas ela pode não ser
> adequada - veja situação que descrevi acima. Se procurar um pouco,
> certamente vão existir casos em que não é nem um pouco interessante a
> substituição do arquivo de configuração (o que me vem a cabeça agora é
> o 915resolution - ele só funciona depois q vc o configura)
E por isso você pode configurar o apt pra não trocar o arquivo
e não questioná-lo sobre isso.
Desculpe, mas nao consegui achar essa opção. Não é a '--assume-yes' do apt-get.
Poderia nos dizer qual é?
(olha que lembro dessa pergunta passar na lista e ficar sem resposta! :-) )
[..]
>> > De qquer maneira, queria saber qual a diferença, e depois do pacote
>> > instalado, dá bem mais trabalho saber...
>>
>> debdiff, aide, fcheck e controle de versão serve exatamente
>> pra isso. :-)
>
> Essas coisas oferecem rollback? :-)
Oferecem.
> Agora não tenho noticia de um gerenciador de pacotes que use controle
> de versão nos arquivos q ele instala
O apt tem um protótipo pra isso e você pode mudar o seu /etc pra
usar svk naturalmente e controlar as mudanças nas suas configurações.
Seria fantástico.
[...]
> Certamente - mas se a janela for de 1 h ou 1 dia, a meu ver não faz
> muuita diferença: vc foi exposto da mesma maneira e pode ter sido alvo
> da mesma forma. Por isso, são necessários outros métodos (como os IDS
> q vc citou acima) p/ cercar por outros caminhos eventuais explorações
> de vulnerabilidades. Estou pensando nas relacionadas a escalada de
> privilégios; se o prob. é um DoS, ai é potencialmente mais tranquilo.
Não vou nem discutir o aspecto de ficar exposto por 1h ou por
24h, quando menor a janela de exposição melhor, e você pode configurar
atualização pró-ativa, sob demanda, ou seja, sai a atualização você
dispara os robôs.
> Sem contar que numa intranet, o ambiente supostamente tem uma relação
> de confiança maior do que com outro micro da internet. Agora, em
> servidores o assunto é bem diferente.
Tem certeza? _Vários_ estudos mostram que a maioria dos ataques
bem sucedidos é interna ou com participação interna.
Bom, estava me referindo as máquinas/serviços e não as pessoas :-)
Pois alguns direitos de acessos são baseados no IP da máquina (ex:
cups, samba, etc) Claro que vc pode fazer um 'hardening' mas não vem
ao caso aqui.
As pessoas certamente são o elo mais fraco.
>> > Se fosse 100% seguro automatizar assim as atualizações, eu aposto que
>> > certamente já viria ligado por default, ou então seria mto fácil ligar
>> > isso. Prefiro a moda antiga ainda :-)
>>
>> É 100% seguro (com security stable). Tanto que muita gente usa.
>> ;)
>
> A pergunta que não quer calar é: pq não é ao contrário então? já não
> vem ligado e desliga se vc não quiser?
Por que o Debian tem uma postura conservadora, ele não assume
que você tem conexão 24h por dia e logo não assume que você queira
automaticamente atualizar listas e pacotes.
Seria legal então se fosse disponibilizado no manual, como última
etapa da instalação, os passos p/ habilitar essa funcionalidade. Já
que muita gente usa, deve ser questão de um ctrl+c ctrl+v :-)
> Em ultimo caso, eu faria todas as máquinas automáticas, mas a minha
> eu ia atualizar na mão p/ acompanhar o processo e ver se correu tudo
> bem nas outras - eventualmente pode ser necessário um procedimento de
> correção.
Eventualmente pode ser necessário desentupir o banheiro, ou
seja, "shit happens". O ponto é que há formas de automatizar o processo
com segurança, se você não teve boas experiências com isso, pode apontar
os problemas e suas impressões, mas não defenda que o processo é
fundamentalmente falho, pois ele não é.
Caso não tenha ficado claro, eu cuido de mais de um servidor
fazendo atualizações automáticas com alta periodicidade sem problemas
nos últimos 12 meses.
Está tudo claro - a minha visão não é exatamente a mesma do que a sua,
mas ainda estamos remando p/ o mesmo lado :-)
Apesar do e-mail estar longo, a conversa estar cansando, e da
trabalheira que dá, eu só pediria p/ que você desse uns exemplos um
pouquinho mais práticos de como vc resolveu algumas das coisas que
discutimos aqui - pois é ai que a nossa visão diverge: eu vejo algo
complicado, e p/ vc é bem mais fácil.
Abraço,
Marcos
Reply to: