ace3@midway.uchicago.edu
dd if=/dev/hda8 of=/etc/dosswap
gzip -9 /etc/dosswap
mkswap /dev/hda8 XXXXX
swapon -av
swapoff -av
zcat /etc/dosswap.gz | dd of=/dev/hda8 bs=1k count=100
>> 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. :-)
michael@actrix.gen.nz
Segue aqui uma dica, usada por mim algumas vezes.
Recuperação de arquivos textos 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.
jadestar@rahul.net
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 à 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...
jadestar@rahul.netTodos 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 pacote 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.
dossey@ou.edu
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
for i in * ; do [ -f $i ] && mv -i $i `echo $i | tr '[A-Z]' '[a-z]'`;
done;
dossey@ou.edu
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
paul@geeky1.ebtech.net
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 HOWTOs :-)
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: Sendmail é um pequeno, poderoso e bem escrito programa. O binário é compilado em menos de 5 minutos em uma máquina 5x86 133 com 32Megs 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.
jadestar@rahul.netCriar 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
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 um sistema exposto ao público.
a.triulzi@ic.ac.uk
/usr/bin/X11/xdm
exec /usr/bin/X11/X -indirect servidor
Eu inclui isso quando eu estava desesperadamente tentando configurar minha própria subrede 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.