Página seguinte
Página anterior
Índice
- Formatar a partição como uma partição DOS, e criar o arquivos de troca Windows nela, mas sem rodar o Windows ainda (deve-se manter o arquivo de troca completamente vazio por enquanto, assim ele pode ser compactado com eficiência).
- Inicie o Linux e salve a partição em um arquivo. Por exemplo, se a partição é /dev/hda8:
dd if=/dev/hda8 of=/etc/dosswap
- Compacte o arquivo de troca; uma vez que tudo que ele contém são zeros, a compressão terá um excelente resultado.
gzip -9 /etc/dosswap
- Adicione a seguinte linha ao arquivo /etc/rc para preparar e instalar a área de troca sob o Linux:
XXXXX é o número de blocos da partição de troca
mkswap /dev/hda8 XXXXX
swapon -av
Esteja seguro de adicionar uma linha de definição da área de troca no arquivo /etc/fstab.
- Caso o pacote init/reboot suporte /etc/brc ou /sbin/brc adicione o seguinte ao arquivo /etc/brc, ou faça manualmente ao iniciar o DOS | OS/2 para converter de volta a partição em uma versão do DOS/Windows:
swapoff -av
zcat /etc/dosswap.gz | dd of=/dev/hda8 bs=1k count=100
# Note que este comando grava somente os primeiros 100 blocos da partição. Eu encontrei empiricamente este número como suficiente.
>> Quais os prós e contras de se utilizar essa sistemática?
Prós: pode-se economizar uma quantidade substancial de disco.
Contras: caso o passo 5 não seja realizado de forma automática, deve-se lembrar de executá-lo manualmente, e isso pode atrasar a inicialização em nanosegundos. :-)
Segue aqui uma dica, usada por mim algumas vezes.
Recuperação de arquivos texto pessoais.
Caso acidentalmente um arquivo texto tenha sido apagado, por exemplo, algum email ou os resultados da última noite de programação, há uma chance de recuperá-los. Caso o arquivo tenha sido gravado em disco, isto é se não foi gravado há mais de 30 segundos, seu conteúdo pode ainda estar na partição em disco.
Pode-se usar o comando grep para procurar o conteúdo do arquivo diretamente na partição em disco.
Por exemplo, recentemente, eu acidentalmente apaguei um email. Então imediatamente cesse qualquer atividade que possa modificar a partição:
Neste caso basta suspender qualquer atividade de salvamento de arquivos ou executar compilações, etc.. Em algumas situações eu na verdade desliguei o sistema e o inicializei em modo monousuário, sem montar os sistemas de arquivos.
Após eu utilizei o comando egrep na partição do disco: no meu caso uma mensagem eletrônica em /usr/local/home/walter/. Inicialmente pode-se ver que o diretório está localizado em /dev/hdb5, utilizando-se o comando df:
sputnik3:~ % df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda3 18621 9759 7901 55% /
/dev/hdb3 308852 258443 34458 88% /usr
/dev/hdb5 466896 407062 35720 92% /usr/local
sputnik3:~ % su
Password:
[michael@sputnik3 michael]# egrep -50 'ftp.+COL' /dev/hdb5 > /tmp/x
Agora deve-se ser extremamente cuidadoso ao lidar com partições de discos, devendo-se verificar cuidadosamente o comando a ser aplicado antes de pressionar Enter. Neste caso procuro o email contendo a palavra ftp seguido de algum texto que contenha a palavra COL. A mensagem continha aproximadamente 20 linhas, tendo então usado -50 para recuperar todas as linhas no entorno da mensagem. No passado eu cheguei a usar -3000 para ter certeza de recuperar todas as linhas de algum código fonte. A saída do comando egrep foi direcionada para uma partição diferente do disco - prevenindo-se assim alguma gravação sobre a área que contém as informações desejadas.
Após, utilizei o comando strings para auxiliar na avaliação da saída anterior:
strings /tmp/x | less
Seguro o suficiente para garantir que o email estava lá.
Este método não é totalmente seguro, pois parte ou toda a área utilizada pelo arquivo anteriormente já pode ter sido utilizada.
Esta dica é provavelmente útil somente em sistemas monousuários. Em sistemas multiusuários com alto nível de atividade em disco, o espaço liberado pode já ter sido utilizado.
Em meu sistema doméstico esta dica pode ser utilizada com sucesso em pelo menos três ocasiões nos últimos anos - principalmente quando acidentalmente eu apaguei o resultado de dias de trabalho. E caso a tarefa na qual eu esteja trabalhando chegue a um ponto onde eu sinta um progresso significativo, é aconselhável copiá-lo em um ou mais disquetes, não sendo necessário usar esta dica com muita freqüência.
Uso de Um Sistema Imutável
Imediatamente após a instalação e configuração de um sistema, vá aos diretórios /bin, /sbin/, /usr/bin, /usr/sbin e /usr/lib (e alguns outros prováveis candidatos) e utilize livremente o comando 'chattr +i'. Adicione também os arquivos do kernel no raiz. Após execute 'mkdir /etc/.dist/' e copie todo o conteúdo de /etc/ nele (eu normalmente faço isto em dois passos usando /tmp/etcdist.tar para evitar a recursividade) no diretório (opcionalmente pode-se simplesmente criar /etc/.dist.tar.gz) - e indicá-lo como imutável.
A razão para tudo isso é limitar eventuais danos que podem ser feitos pelo usuário que acessa o sistema como superusuário root. Assim não se apagará arquivos importantes com um redirecionamento ou com um comando acidental 'rm -fr' (apesar destes comandos ainda poderem causar um grande estrago no sistema - ao menos as bibliotecas e executáveis estarão a salvo).
Isso torna o sistema ainda mais seguro pois evita serviços de busca de falhas de segurança, tornando mais difícil ou praticamente impossível o seu uso (uma vez que muitos deles fundamentam-se na regravação de arquivos que executem ações com o programa SUID e tenham acesso a ambientes de trabalho).
O único incoveniente deste procedimento aparece ao se executar 'make install' em diversos binários do sistema. Caso se esqueça de executar o comando chattr -i nos arquivos a serem regravados e nos diretórios onde eles estão localizados, o comando make falhará. Basta executar o comando e executar novamente make. Pode-se ainda mover os binários antigos, bibliotecas, e tudo o mais para um diretório .old/ ou renomeá-los ou ainda aplicar o comando tar, etc..
Todos os arquivos e comandos novos podem estar em /usr/local! ou /usr/local/`nome_da_máquina`. Caso a sua distribuição deixe vazio o diretório /usr/local , então simplesmente crie os diretórios /usr/local/src, /usr/local/bin, etc. e utilize-os. Caso a sua distribuição coloque arquivos em /usr/local, então pode-se criar um diretório com o comando 'mkdir /usr/local/`hostname`' e atribuir a permissão de grupo +w para ele (eu ainda faço uso de SUID e SGID para garantir que cada membro do grupo w possa somente lidar com arquivos que a eles pertencem, e que assim todos os arquivos criados pertencerão ao grupo w).
Após, adquira o hábito de sempre colocar novos pacotes em /usr/local/src/.from/$NOME_DO_PACOTE/ (para arquivos .tar ou qualquer outro) e construa-os em /usr/local/src (ou .../$NOME_DA_MÁQUINA/src). Esteja seguro que ele seja instalado sob a hierarquia de diretórios local. Caso ele necessariamente deva ser instalado em /bin ou /usr/bin ou algum outro local, crie uma ligação simbólica da hierarquia local com cada elemento que deva ser colocado em outro local.
A razão para isto - mesmo que dê um pouco mais de trabalho - reside na capacidade de isolar o que deve ser copiado e restaurado ou reinstalado no caso de uma reinstalação completa a partir de uma mídia da distribuição (normalmente um CD). Usando um diretório /usr/local/.from pode-se ainda manter-se um histórico informal da origem dos fontes -- o que auxilia na hora de buscar atualizações - o que pode ser crítico ao se monitorar a lista de questões de segurança.
Por exemplo, todos os sistemas que eu configurei no trabalho (quando eu era encarregado da administração do sistema) e que foram administrados por muitos contratados e outras pessoas, e tiveram um grande número de atualizações, mantiveram uma idéia precisa dos elementos que foram adicionados ao sistema após a instalação e configuração iniciais.
Eu reparei em uma dificuldade desnecessária nos procedimentos recomendados na seção 2c das dicas, edição 12 da LG. Neste caso estou enviando uma alteração para facilitar o processo:
#!/bin/sh
# lowerit
# converte os nomes de todos os arquivos do diretório atual para letras
# minúsculas. Funciona somente em arquivo - não muda nomes de diretórios
# e solicitará confirmação antes de regravar um arquivo já existente.
for x in `ls`
do
if [ ! -f $x ]; then
continue
fi
lc=`echo $x | tr '[A-Z]' '[a-z]'`
if [ $lc != $x ]; then
mv -i $x $lc
fi
done
Bem, é um programa longo. Ao invés de usar tudo isso pode-se usar o seguinte comando:
for i in * ; do [ -f $i ] && mv -i $i `echo $i | tr '[A-Z]' '[a-z]'`;
done;
Na próxima dica pode-se encerrar todo os processos de um determinado usuário com o seguinte comando.
kill -9 `ps -aux |grep ^<nome_usuário> |tr -s " " |cut -d " " -f2`
Por exemplo, caso o usuário se chame paloma:
kill -9 `ps -aux |grep ^paloma |tr -s " " |cut -d " " -f2`
Agora com cuidado, vamos falar de senhas do superusuário que foram esquecidas ou perdidas.
A solução dada na Linux Gazette é a mais universal, mas não a mais simples. Tanto com o LILO como com o loadlin, pode-se incluir o parâmetro "single" para se iniciar diretamente no ambiente de trabalho padrão, sem a necessidade de informar senhas. A partir daqui, pode-se mudar ou remover quaisquer senhas, antes de digitar "init 3" para iniciar o sistema em modo multiusuário.
Justin Dossey
Começaremos do princípio, dos fontes do programa. Inicialmente deve-se obter os fontes do sendmail. Eu estou utilizando a versão 8.9.0, a qual é, no momento em que escrevo este artigo, o que há de mais recente. Eu o obtive em ftp.sendmail.org:/pub/sendmail/sendmail.8.9.0.tar.gz
Tem o tamanho de aproximadamente 1 Mb e considerando que se esteja executando a versão 8.7.6, eu creio que o esforço vale a pena. Caso funcione, certamente você saberá prontamente, de outra forma não há como receber as novas versões dos COMO FAZER :-)
Agora que já se tem os fontes, deve-se descomprimi-los. Pode-se criar um diretório chamado sendmail-8.9.0 dentro do diretório atual. Vá para o diretório (com o comando cd), e leia os arquivos README e RELEASE_NOTES (e esteja ciente das atualizações que foram feitas). Agora pode-se ir para o diretório src. Aqui é onde a maior parte do trabalho será executada.
Nota: O sendmail é um pequeno, poderoso e bem escrito programa. O binário é compilado em menos de 5 minutos em uma máquina 5x86 133 com 32Mb de RAM! A compilação completa e a instalação (configuração) levam menos de 15 minutos.
Eu normalmente não executo o BIND em meu sistema, então encontrei as seguintes linhas:
# ifndef NAMED_BIND
# define NAMED_BIND 1 /* usando Servidor de Domínios Berkeley */
# endif
e mudando 1 para 0:
# ifndef NAMED_BIND
# define NAMED_BIND 0 /* usando Servidor de Domínios Berkeley */
# endif
No Debian 1.3.1, db.h é por padrão instalado em /usr/include/db, ao invés de /usr/include, onde sendmail espera encontrá-lo. Vá para os diretórios src,
mailstats, makemap, praliases, rmail e smrsh e execute o seguinte comando:
./Build -I/usr/include/db
Uma vez feito isso, execute `cd ..' e digite make install. Voilá! Sendmail versão 8.9.0 deve estar instalado. Isso claro, assumindo que a configuração original já foi realizada. Para que tudo funcione corretamente, uma vez que eu hospedo listas de mensagens usando majordomo, é necessário adicionar o seguinte no início de /etc/sendmail.cf:
O DontBlameSendmail=forwardfileinunsafedirpath, forwardfileinunsafedirpathsafe
Sendmail 8.9.0 é desagradável sobre permissões de arquivos e diretórios, e irá reclamar sobre arquivos e diretórios em aliases ou .forward que tenham permissões de escrita para todos os usuários ou para o grupo. Uma vez que não é uma boa idéia desabilitar estes avisos, como sou o único que utiliza o sistema, sinto-me à vontade para fazê-lo.
YMMV.
Criar e manter um arquivo /LEIAME.`nome_máquina` e/ou um /etc/LEIAME.`nome_máquina` [Ou possivelmente /usr/local/etc/LEIAME.`nome_máquina` -Maint. ]
Desde o primeiro dia da administração do sistema, tome notas neste arquivo como um histórico on-line. Pode-se incluir a linha "vi /LEIAME.$(nome_máquina)" no arquivo /bash_logout do superusuário. Uma outra forma de fazer isso é criar um programa su ou sudo que faça mais o menos o seguinte:
function exit \
{ unset exit; exit; \
cat ~/tmp/session.$(date +%y%m%d) \
>> /LEIAME.$(nome_máquina) && \
vi /LEIAME.$(nome_máquina)
}
script -a ~/tmp/session.$(date +%y%m%d)
/bin/su.org -
(use o comando typescript para criar um histórico da sessão e criar uma função para automatizar a inclusão e atualização do histórico).
Eu admito que não utilizei essa política de automação, confiando sempre na minha disciplina. De qualquer forma a idéia está formatada.
Minha última sugestão é manter o caminho para o superusuário com o seguinte formato 'PATH= /bin'.
Somente isso e nada mais. Assim tudo o que o superusuário fizer pode ser provido por uma ligação simbólica com /bin ou por um nome alternativo ou por uma função de ambiente de trabalho, ou ainda pela digitação explícita do caminho.
Isso torna qualquer usuário acessando o sistema como superusuário ciente de que binários estão sendo utilizados. O administrador inteligente de um sistema multiusuário irá periodicamente observar os arquivos /bin e /.*history procurando padrões ou mensagens freqüentes.
O administrador realmente interessado irá buscar seqüências que podem ser automatizadas, colocar checagens em pontos necessários, e verificar quais privilégios do "superusuário" podem ser revistos (uso de editores, MTA e outros programas interativos com funcionalidades elaboradas que podem agregar informações em arquivos de dados - como o famoso vi ./.exrc e emacs ./.emacs e mesmo o $EXINIT e as macros header/footer). Naturalmente estes comandos podem ser executados da seguinte forma:
cp $data $algum_diretório_usuário/tmp
su -c $comando_origem $mudanças
cp $algum_diretório_usuário/tmp $data
onde os dados variam de comando para comando.
Muitas destas precauções podem ser consideradas exageradas em estações de trabalho domésticas ou de usuários individuais, mas são altamente recomendadas como política de administração de sistemas multiusuários, particularmente em um sistema exposto ao público.
- Edite o arquivo que inicializa o xdm, (possivelmente /etc/rc/rc.6 ou /etc/rc.local) e que contenha as seguintes linhas na seção de início do xdm.
/usr/bin/X11/xdm
exec /usr/bin/X11/X -indirect servidor
- Edite o arquivo /usr/lib/X11/xdm/Xservers, comentando a linha que inicia o servidor na máquina local (por exemplo starting 0:)
- Ao reinicializar o computador, você estará em casa e além.
Eu inclui isso quando eu estava desesperadamente tentando configurar minha própria sub-rede a partir de uma máquina e levei mais de uma semana para corrigir todos os problemas.
Adicional: com o velho SLS (1.1.1) por alguma razão pode-se utilizar o parâmetro -nodaemon após a linha do xdm - porém isso NÃO funciona para versões mais recentes.
Página seguinte
Página anterior
Índice
|
