Arquvo de ‘linux’
-
The recovery
Continuando o post anterior…
Quando vi que nada funcionava bateu aquele gelo: PUTZ! COMO FUI FAZER ISSO?! Logo pensei: preciso ficar frio e encarar este desafio agora, recuperar o sistema… Já abri uma VM que tenho aqui de testes e dei o mesmo comando suicida, para representar o cenário e propor uma solução. Logo pensei: vou isolar esse disco virtual e trabalhar com ele em secudário, já que ele zuado não iniciará. Como eu estava trabalhando com um Slackware, em ambos sistemas, já resolvi inicializar via DVD de instalação, já que o Slackware entrega um bash no início da instalação.
Depois de inicializado pelo DVD, montei a partição / da instalação estragada no diretório virtual /mnt (virtual sim porque inicializei via DVD). Montou sem problemas, mas é claro, não estraguei a partição, e sim o sistema. Fui até o diretório que foi promovido ao novo /, o /mnt/usr/src/twolame, e verifiquei que todas as pastas movidas estavam lá, e totalmente acessíveis e com as permissões originais. Simplesmente executei o comando inverso da cagada:
mv /mnt/usr/src/twolame/* /mnt
Pronto, sem mensagens de erro. Para ver se tive êxito, reinicializei o sistema, mas procurando o boot no disco da VM. Simpirilim! Funcionou. Parace que o sistema nunca passou pelo que passou. Tudo em seu devido lugar, apenas parti para a máquina física que foi abençoada com meu comando mortal para fazer o mesmo.
Resumindo… tudo resolvido. UFA!
-
Oh shit!
Há momentos na vida em que a gente deseja fortemente ter o recurso de rollback ou, no vulgo, ctrl+z. Esta noite realmente eu me superei. Ao tentar compilar um pacote Slackbuild, consegui destruir o meu sistema. Veja o tamanho da cagada:
Criei uma pasta para os arquivos que ia trabalhar, mkdir twolame. Lá dentro baixei os arquivos do slackbuilds.org, referentes à este pacote. Os arquivos são pacote tarball dos fontes; twolame.tar.gz, que contém o script slackbuild e outros de apoio; e a assinatura twolame.tar.gz.asc. Para compilar descompactei o twolame.tar.gz e aí que começou o inferno.
Com a simples finalidade de mover todo o conteúdo da pasta twolame recém gerada para a pasta local (.), fui dar o seguinte comando:
mv twolame/* .
Mas ao digitar, pressionei o ‘t’ do twolame muito fraco, tanto que nem chegou a ser impresso na tela, e eu como sou distraído, ou confiante demais, apertei o tab para auto-completar, o que não aconteceu, e segui com o /* .. Nem precisa dizer o que saiu né:
mv /* .
Bem, acho que nem preciso dizer que após este comando, nada mais funcionou né. O pior foi pensar que este sistema seria ativado em um cliente no dia seguinte. Por isso sempre digo, nunca dê acesso de root para criança.
-
diff binário
Estava eu procurando por uma solução de patch binário para compor uma parte do meu sistema de backups. Pois bem, embora não seja o cerne de tudo, vou explicar meu cenário para que seja melhor entendido.
Eu estou trabalhando com máquinas virtuais com imagens de discos em volumes lógicos (LVM). Usando o recurso de snapshot do LVM, que é assunto para outro post, eu estava copiando inteiramente a imagem para um backup, através do comando dd. O problema é ter que fazer uma cópia full da imagem a cada backup. Minha máquina de teste tem 10GB, mas imagina um servidor em produção, que pode ter várias dezenas de GBs… Fica inviável o backup deste jeito. Assim começou a busca por uma solução de calcular a diferença entre os dois binários, imagem de produção e a backup, para assim gerar um patch com somente o necessário para transferir ao servidor de backup. Após, eu precisaria aplicar este patch e assim atualizar a iamgem.
Pesquisando no oráculo Google, encontrei este site. Lá pude baixar dois fontes, bsdiff e bspatch. Esses são versões ‘binárias’ do GNU diff e patch. Depois de baixar, compilei usando o Makefile do próprio pacote. Como ele foi feito para os *BSD, o formato do Makefile é um pouco diferente. Para compilar direitinho, crie um arquivo chamado Makefile.patch no mesmo diretório do fonte. Dentro dele, coloque o seguinte conteúdo:
--- Makefile 2010-06-28 14:52:42.351369894 -0300 +++ Makefile.gnu 2010-06-28 14:53:29.883369968 -0300 @@ -1,4 +1,5 @@ CFLAGS += -O3 -lbz2 +INSTALL ?= /bin/install PREFIX ?= /usr/local INSTALL_PROGRAM ?= ${INSTALL} -c -s -m 555 @@ -10,6 +11,6 @@ install: ${INSTALL_PROGRAM} bsdiff bspatch ${PREFIX}/bin -.ifndef WITHOUT_MAN +ifndef WITHOUT_MAN ${INSTALL_MAN} bsdiff.1 bspatch.1 ${PREFIX}/man/man1 -.endif +endifSalve o arquivo e aplique o patch da seguinte forma:
patch -p0 < Makefile.patch
Depois disso, é só instalar:
make install
Para testar, fiz o seguinte: copiei para uma pasta os binários /bin/ls e /bin/bash. Lá, calculei a diferença usando o bsdiff:
/usr/local/bin/bsdiff ls bash teste
Assim, foi criado o arquivo binário teste, que é a diferença entre ls e bash, ou seja, um patch. Depois, eu resolvi aplicar este patch no próprio ls. Assim, eu faria este ls se transformar no bash.
/usr/local/bin/bspatch ls ls_patched teste
Realmente, aconteceu como eu esperava. O comand bspatch gerou um binário ls_patched, que é o resultado do ls + teste. E adivinha, ele é exatamente o bash. Executa direitinho.
-
Liberar espaço
De vez em quando, a partição root, ou / (barra), fica perto de usar sua capacidade máxima, e para que o sistema não pare, é preciso liberar um pouco de espaço. De cara, eu sempre penso no diretório /tmp. Claro, se ele fizer parte da mesma partição do /. Para solucionar temporariamente o problema de espaço, eu excluo os arquivos temporários que não foram usados desde uma certa data. Para isto, o comando find é bastante útil. Como exemplo, no meu laptop, eu rodo a seguinte sentença:
$ sudo find /tmp -atime +1 -exec rm -rfv{} \;Isto faz com que ele busque no diretório /tmp todos os arquivos que tem a data de acesso maior que 1 dia no passado e submete-o ao comando rm, para removê-lo. A data pode ser modificada alterando o parâmetro +1 do atime. Caso coloque +2, serão buscados os arquivos com mais de 2 dias de acesso. Para mais informações, sempre existe o man.
$ man find
Outro utilitário bom para ajudar na busca por maior espaço livre é o du (disk usage). Ele faz uma somatória do uso de cada diretório e subdiretório. Dois parâmetros que sempre uso são: -h, para traduzir o espaço usado para unidades mais legíveis (GB, MB…); –max-depth=n, que diz ao du para correr até o nível n. Exemplo de uso:
$ sudo du -h --max-depth=1 /tmp
Ou seja, some o uso de todos os diretórios e subdiretórios de /tmp, porém só me exiba até o primeiro nível, de maneira legível.
-
CPU flags
Pelo tanto que venho lendo sobre virtualização e propriedades dos processadores, resolvi ir um pouco mais a fundo para saber o que significam aqueles nomes estranhos de instruções. No Linux pode-se verificar o conteúdo do arquivo /proc/cpuinfo:
$ grep flags /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch lbrv
As mais comuns que vi referências foram: PAE (Physical Address Extensions) que permite endereçamento de memória acima de 4GB; HT (Hyper Threading) que permite um núcleo de processador possuir duas filhas de processamento, simulando assim processamento paralelo; LM (Long Mode) que indica presença de instruções x86_64; entre outros que podem ser encontrados neste endereço.
-
rc.libvirt
Segue abaixo um script de start e stop para o serviço libvirtd que fiz para Slackware:
#!/bin/bash MODULES="tun vhost_net" PIDFILE="/var/run/libvirtd.pid" TIMEOUT=${TIMEOUT:-40} OPTS=${OPTS:-""} check_running_machines() { i=0 for j in `virsh list | grep running | awk '{print $2;}'` ; do virsh shutdown $j done echo -n "Waiting machines" while [ $(virsh list | grep running | wc -l) -gt "0" ]; do if [ "$i" -ge "$TIMEOUT" ];then break fi echo -n "." i=`expr $i + 1` sleep 1 done echo "" if [ $(virsh list | grep running | wc -l) -gt "0" ];then echo -n "The following machines are still running, forcing shutdown: " for j in `virsh list | grep running | awk '{print $2;}'` ; do virsh destroy $j echo -n "$j " done echo "" sleep 2 fi } check_processor() { egrep 'vmx' /proc/cpuinfo > /dev/null if [ "$?" -eq "0" ];then MODULES="$MODULES kvm_intel kvm" fi check=$? egrep 'svm' /proc/cpuinfo > /dev/null if [ "$?" -eq "0" ];then MODULES="$MODULES kvm_amd kvm" fi check=`expr $check + $?` if [ $check -eq "2" ];then echo "Your systems does not support KVM!" fi } start() { if [ -f $PIDFILE ];then echo "libvirt is already running..." exit 1 fi echo "Starting libvirtd..." check_processor modprobe -a $MODULES libvirtd -d -l $OPTS } stop() { if [ ! -f $PIDFILE ];then echo "libvirt is not running..." exit 2 fi check_running_machines check_processor echo "Stopping libvirtd..." kill -TERM `cat $PIDFILE` modprobe -ra $MODULES } case $1 in start) start ;; stop) stop ;; restart) stop sleep 1 start ;; *) echo "Usage: $0 (start|stop|restart)" ;; esac -
qemu-kvm
Há tempos venho usando a virtualização como meio de testar sistemas e multiplicar o número de máquinas de teste, que sem ela, seria quase impossível. Nesta última semana passei a me preocupar mais com o assunto. Embora eu já venha usando seus milagrosos recursos, nunca havia parado para ver que soluções existem na praça e como esta mágica funciona. Resolvi finalmente ler um livro sobre o tema que um amigo me emprestou há mais de um ano. Não sei o que é pior, não devolver o livro do amigo ou não ler. O livro se chama Virtualização, publicado pela Linux Magazine.
Para quem ainda não leu, o livro fala do conceito de virtualização de uma forma bastante didática e direta apresentando softwares desta área, porém sua ênfase está na solução OpenSource Xen. Ao ler o livro, me lembrei de um recurso que já tinha visto, mas não estudado antes, as instruções Intel-VT e AMD-V, que podem ser referenciadas como vmx e svm respectivamente no Linux. Lembrei também, que há opções disponíveis na tela de configuração do Kernel para habilitar esses recursos, o KVM. Falando rapidamente, o KVM (Kernel-based Virtual Machine) é uma implementação no kernel-space que permite melhor uso do recurso de virtualização do processador usando máquinas virtuais compatíveis com ele.
Mas o KVM não poderia trabalhar sozinho numa solução de virtualização. Pesquisando um pouco mais, vi que o emulador Qemu tem uma versão modificada para trabalhar com o KVM. Como usuário de Slackware que sou, encontrei o script SlackBuild no repostório não-oficial SlackBuilds.org do qemu-kvm. Baixei o pacote do qemu-kvm que estava no mesmo repositório juntamente com seu script e já mandei bala. Alterei o script para dizer qual arquiteturas quero emular. Para isto, basta definir a variável BUILD_ARCH que contém as arquiteturas separadas por um espaço. A lista de arquiteturas suportadas é: i386; x86_64; alpha; arm; armeb; cris; m68k; microblaze; mips; mipsel; ppc; ppc64; ppc64abi32; sh4; sh4eb; sparc; sparc64 e sparc32plus. No meu caso, ficou assim:
BUILD_ARCH="i386 x86_64"
ARCH=`uname -m` ./qemu-kvm.SlackBuild
Depois disto, aguardei o fim da compilação e instalei:
installpkg /tmp/qemu-kvm-0.12.3-x86_64-1_SBo.tgz
Para seu uso, é importante que seu processador suporte a instrução vmx ou svm. Para saber se seu processador suporta, use o seguinte comando:
egrep '(vmx|svm)' /proc/cpuinfo
Se retornar alguma linha, quer dizer que seu processador está preparado. O KVM deve estar compilado com o kernel. Pode ser tanto incorporado no kernel como em módulo. No kernel huge do Slackware, ele já vem compilado como módulo. Para usá-lo, basta carregar o módulo.
Para AMD:
modprobe -a kvm kvm_amd
ou para Intel:
modprobe -a kvm kvm_intel
Agora só é preciso criar a máquina virtual.
O qemu vem com algumas ferramentas, mas aqui falarei apenas de duas: qemu e qemu-img. Antes de tudo, precisamos criar o disco virtual. Para isso, usei o qemu-img:
qemu-img create -f qcow2 ~/teste.img 10G
Traduzindo, mandei ele criar o arquivo de imagem ~/teste.img no formato qcow2 de tamanho 10G. Caso verifique o tamanho do arquivo de imagem e ele esteja muito pequeno, não se assuste. Ele cresce conforme demanda até o limite de 10G. Ainda não descobri como criar o imagem com todo seu espaço já alocado.
Agora basta rodar a máquina na linha de comando:
qemu -hda ~/teste.img -cdrom ~/slackdvd.iso -boot d -m 256 -k pt-br -name Teste -net nic,model=pcnet -net user
Traduzindo, eu pedi para o qemu inicializar a máquina de nome Teste atribuindo o disco ide primério como sendo teste.img, uma unidade de cdrom montada com a imagem slackdvd.iso. Pedi para que busque o boot na unidade d, ou seja, no dvd. Ele terá também 256MB de memória, um teclado com layout pt-br. Para conectividade use uma placa de rede do modelo pcnet e crie uma nat da minha interface de rede real para ela. Assim terei acesso à Internet. Caso não queira ter o terminal preso, acrescente a opção -daemonize.
Essa configuração é básica, apenas para se ter um primeiro contato. Vale observar também, que o comando qemu cria um ambiente 32bit. Para uso de sistemas 64bit, use o comando qemu-system-x86_64 em seu lugar. Para configurações mais completas, confira o manual do comando qemu:
man qemu
-
Instalação NIS – Cliente
O cliente é levemente parecido com o cliente, apenas algumas opções a mais. Primeiramente no arquivo /etc/yp.conf definimos qual o domínio que pertenceremos e qual é o servidor NIS deste. Este arquivo ficará com o seguinte conteúdo, apenas:
domain dominio_nis server endereço_do_servidor
Agora é preciso indicar ao sistema que procure as informações de login no NIS. Para isto, alteraremos o arquivo /etc/nsswitch.conf. Localize as linhas que contenham as configurações para os arquivos passwd, group e shadow. Altere para o seguinte:
passwd: files nis shadow: files nis group: files nis
Isto fará com que o sistema procure primeiramente nos arquivos locais, caso não encontre, procurará via NIS. Mais outro detalhe, é importante para que isto aconteça. No final do arquivo /etc/passwd, acrescente uma linha igual à esta:
+::::::
No arquivo /etc/group, por sua vez, acrescente:
+:::
Está quase pronto. Agora para usarmos a autenticação remota, precisamos definir nosso domínio NIS com o comando:
nisdomainname [dominio]
Observe que o domínio do servidor e cliente deverão ser o mesmo. Após, apenas inicializaremos o NIS cliente com o comando:
/usr/sbin/ypbind
Depois de tudo isto, os usuários terão que ser cadastrados apenas no servidor, podendo ser logados de qualquer máquina cliente do servidor NIS.
-
Instalação NIS – Servidor
Primeiramente é preciso entender o NIS. Sem maiores pesquisas, baseando apenas no meu conhecimento, ele é um serviço de informações de contas de usuários. Com este serviço, você pode ter centralizado em apenas um servidor todas as contas, senhas e grupos de um sistema. Este é consultado pelas estações, clientes, que buscam nele informações para o login.
Para ele funcionar, é necessário que o serviço de rpc esteja habilitado e rodando, tanto no servidor como no cliente, pois as trocas de informações são feitas pelo portmap.
Vamos à configuração!
O servidor é extremamente simples. Com o serviço rpc rodando, você precisará apenas definir seu domínio NIS com o comando:
nisdomainname [dominio]
Após, rode o comando ypserv, que normalmente está em /usr/sbin.
/usr/sbin/ypserv
Para um servidor master, precisará também executar o comando rpc.yppasswdd que está em /usr/sbin.
/usr/sbin/rpc.yppasswdd
Para servidor slave, em lugar do rpc.yppasswdd, use o comando rpc.ypxfrd, que é um proxy para o master.
/usr/sbin/rpc.ypxfrd
Para cada usuário criado no sistema, é necessário ir até o diretório /var/yp e rodar o comando:
make
Sem isto, o usuário criado não será válido no NIS. Pronto, seu servidor está rodando e aguardando requisições de login!
Tags
Recentes
Blog
Lista de Links
- Debugging Consultoria Debugging Consultoria
- LPI
- Voip-Info Wiki VoIP