Posts tagged ‘utilidades’
-
procps-dev
Essa semana precisei implementar uma função da biblioteca libproc para que meu programa só permitisse uma instância. O problema é que eu precisava dos headers do pacote procps, mas por padrão o Slackware não instala.
Por isso, precisei fazer manualmente, baixar o pacote, desempacotar e copiar para a pasta de headers. Não sei se futuramente esses valiosos arquivos serão inclusos no pacote oficial, mas de qualquer maneira, eu criei um SlackBuild que possa ajudar quem está na mesma que eu.
#!/bin/bash MIRROR=${MIRROR:-http://ftp.belnet.be/packages/slackware/slackware_source/} VERSION=${VERSION:-3.2.7} ARCH=noarch BUILD=${BUILD:-2duderamos} CWD=$(pwd) TMP=${TMP:-/tmp} PKG=$TMP/package-procps-dev rm -rf $PKG rm -rf $TMP/procps-$VERSION if [ ! -f procps-${VERSION}.tar.gz ];then wget "${MIRROR}/a/procps/procps-${VERSION}.tar.gz" || exit 1 fi cd $TMP tar xzvf $CWD/procps-$VERSION.tar.gz || exit 1 mkdir -p $PKG/install mkdir -p $PKG/usr/include/procps mkdir -p $PKG/lib cd $TMP/procps-$VERSION cp proc/*.h $PKG/usr/include/procps cat $CWD/slack-desc > $PKG/install/slack-desc cat $CWD/doinst.sh > $PKG/install/doinst.sh cd $PKG makepkg -l y -c n $TMP/procps-dev-$VERSION-$ARCH-$BUILD.txz rm -rf $TMP/procps-$VERSION.tar.gz rm -rf $TMP/procps-$VERSION rm -rf $PKG -
docalls
Quem ainda não foi ‘vítima’ de uma chamada de telemarketing? Embora muitos achem isto chato, empresas continuam usando esta técnica para divulgar seus produtos. Para os usuários de VoIP, e mais especificamente Asterisk, o docalls, pequeno script shell, pode te ajudar a gerar ‘malas-diretas’ de voz.O seu funcionamento é baseado no módulo pbx_spool.so do Asterisk, e portanto, este deverá estar carregado para funcionar. Ele pode ser baixado aqui.
-
Montar partição de VM em host
Há momentos em que é necessário trabalhar com um disco ou partição de um servidor Linux sem que ele seja usado no boot. Normalmente em PCs usamos um disco de boot que nos entrega um shell para darmos comandos. Geralmente isto é feito para depuração de problemas na partição.
Em máquinas virtuais baseadas no KVM, é possível montar uma partição de uma máquina virtual no servidor hospedeiro. Para isto, basta usar o módulo Network block driver (nbd). Para habilitar, verifique se sua configuração do kernel contém “CONFIG_BLK_DEV_NBD=m” ou “CONFIG_BLK_DEV_NBD=y”. Caso seja um módulo, basta carregá-lo com o modprobe.
modprobe nbd max_part=63
Mais informações, use: modinfo nbd.
No pacote do qemu-kvm, vem uma ferramenta chamada qemu-nbd. Com ela, basta conectar algum dos arquivos de bloco nbd à imagem do disco virtual. No meu caso:
qemu-nbd -c /dev/nbd0 /dev/logical/dns2
.
Ele critou outros arquivos de blocos, representando todas as partições do meu disco virtual: /dev/nbd0p1, /dev/nbd0p2 e /dev/nbd0p3. Com isto, basta eu montar este bloco a alguma pasta do sistema, como no exemplo:
mount /dev/nbd0p1 /mnt/tmp
Vale lembrar que o hospedeiro precisa ter suporte ao sistema de arquivos da partição que será montada.
Para desconectar, é preciso desmontar as partições montadas anteriormente e desconectar o dispositivo.
qemu-nbd -d /dev/nbd0
Mais informações use “qemu-nbd -h” ou “man qemu-nbd”.
-
Estender partição
Como toda invenção, meu aprendizado é orientado à necessidade. Recentemente passei por um sufoco de espaço em disco em uma máquina virtual minha, que opera sobre um servidor Linux com KVM. Para melhor gerência, meus discos virtuais estão alocados como volumes lógicos LVM2, o que facilitou muito meu trabalho neste momento.No meu caso, eu tinha uma VM montada sobre um volume de 10GB, e eu desejava expandir este espaço para 30GB, sem ter que anexar outro volume. Segui rigorosamente estes passos: parar a VM, expandir o volume lógico, dar boot com um CD ou pendrive de boot da distribuição, recriar a tabela de partições com o fdisk com os novos valores, estender a partição ext4 com resize2fs. Acompanhe mais detalhadamente abaixo.
Volume lógico
Antes de mais nada, a máquina virtual deverá estar desligada. No servidor hypervisior, execute o seguinte comando:
lvextend -L +20G /dev/logical/plutus
Isto faz com que meu volume lógico ‘plutus’ seja aumentado em 20GiB (veja diferença entre GiB e GB)
Partição física do disco virtual
Depois de o volume esticado, basta dar o boot na máquina virtual usando um disco de boot externo. Isto é importante porque vamos mexer na estrutura básica das partições. No meu caso eu uso Slackware64 13.1 e fdisk, mas nada impede de usar outra distro e ferramenta. O importante é que não haja formatação na finalização do processo. Aqui, assume-se que você saiba usar a ferramenta escolhida.
Na minha VM, eu tenho duas partições: / (root ou barra) como sda1 de 9,5GiB e swap como sda2 0,5GiB. Neste passo, preciso entrar no fdisk no dispositivo sda e excluir as duas partições. Mas calma! Isto não fará com que você perca seus dados, pois estamos apenas mexendo no mapeamento das partições, onde começa e termina o que. Depois de excluir, criei a partição número 1, que corresponde ao / com o tamanho de 29,5GiB e o restante para swap. Aqui é importantíssimo que se observe o início da partição 1, que deverá estar no mesmo bloco da anterior. Caso contrário, os dados ficarão inacessíveis. Feito isto, basta salvar a nova tabela de partições.
Estendendo a partição ext4
Aproveitando que não estamos rodando em cima do disco em questão, vamos efetivar o tamanho da partição útil do sistema. Para isto usarei o comando resize2fs do pacote e2fsprogs. Este passo é muito simples, basta usar o comando:
resize2fs /dev/sda1
Isto fará com que ele aumente a partição ext4 para o máximo possível, no caso 29,5GiB. É provável que ele solicite uma checagem com o fsck antes de fazer isto. Basta usar o comando:
fsck /dev/sda1
Finalização
Agora, basta testar. Antes mesmo de um boot no disco principal, tente montara nova partição:
mount /dev/sda1 /mnt
Se tudo correu bem, você poderá navegar na nova partição pelo ponto de montagem /mnt. Agora basta dar um reboot usando o disco principal.
-
VirtualBox e usb
O VirtualBox tem um recurso de acesso à dispositivos USB da máquina host, mas nem sempre é fácil usá-lo. No meu caso, o host é um Slackware 13.1 Linux. O problema é de permissão e simples de se resolver. No início, quando o sistema de arquivos USB (usbfs) é montado, ele normalmente coloca tudo para apenas o root ter controle. A mágica está em alterar isto, usando o grupo plugdev, que no Slackware é usado para dispositivos removíveis.
Primeiramente seu usuário deve estar no grupo. Adicione o usuário que vai usar o VirtualBox no grupo com o seguinte comando, no meu caso, usuário eduardo:usermod -a -G plugdev eduardo
Agora basta uma alteração no fstab. Acrescente a seguinte linha:
usbfs /proc/bus/usb usbfs devgid=83,devmode=660 0 0
Isso fará com que o sistema no início monte o usbfs sendo do grupo do plugdev também, e dando permissão de leitura e escrita para seus membros.
Para resolver isso rapidamente sem reinicializar o sistema, use o seguinte:
mount -o remount,devgid=83,devmode=660 /proc/bus/usb
-
Dicas rápidas
Nessa ultima semana, descobri dois comandos que me foram bastante úteis. Esses são at e ionice. Abaixo segue um brief sobre ambos.
At
Esse comando é um agendador de tarefas. Semelhante ao cron, porém este não é cíclico. Agendar uma tarefa é fácil, basta informar ao at o arquivo que contém os comandos que serão executados e a hora e data. Talvez assim tenha ficado um pouco vago. Vou dar um exemplo. Crie um arquivo contendo o seguinte:
#/bin/sh touch /tmp/teste-at
Assumindo que o arquivo criado seja o ~/job.txt, vamos agendar a execução desse programa:
at -f ~/job.txt 3pm tomorrow
Se tudo ocorrer bem, aparecerá uma mensagem semelhante à essa:
job 1 at Thu Jul 29 15:00:00 2010
A notação de hora e data do at é um tanto flexível. Neste exemplo, poderíamos definir como 15:00 Jul 29 2010, ou então15:00 07/29/10. O resultado seria o mesmo. Para melhor detalhamento, consulte o manual do comando: man at. Para consultar os jobs que já foram agendados, use o comando primo atq, e para remover/cancelar um job, use o atrm fornecendo o id do job como primeiro argumento.
ionice
Assim como o comando nice, ele estabelece prioridades para os processos, mas este, se limita às operações de disco (I/O). Sua sintaxe é semelhante do seu primo nice. Dois argumentos eu enfatizo: -c e -p. O primeiro define o número da classe de prioridade e o segundo o número do PID que sofrerá a modificação.
As classes podem ser:
Idle: O processo só usará o processador para I/O se nenhum outro processo estiver usando.
Best effort: O processo concorrerá o processador em níveis de prioridade que podem ser definidas entre 0 e 7, sendo 0 (zero) a maior prioridade. Para definir esse valor, use a opção -n. Vale lembrar que qualquer que seja o nível de prioridadem ele sempre passará na frente de processos da classe Idle.
Real-time: Esse é para processos que realmente necessitem de atenção de I/O. Assim como a classe Best effort, esse é dividido em 8 níveis de prioridades e sua definição é idêntica. Vale lembrar que qualquer processo dessa classe, mesmo que seja prioridade 7, passará na frente de processos Best effort e Idle.
O número das classes Idle, Best effort e Real-time são respectivamente 3, 2 e 1. 0 (zero) significa que não pertence a classe alguma. Caso queira já iniciar o processo com ionice definido, troque o argumento -p pelo comando em si, como por exemplo:
ionice -c 3 cp ~/hugefile.img /tmp
Ou seja, defina classe Idle para o processo que executará a cópia do arquivo hugefile.img.
Para maior detalhamento, consulte o manual do comando, man ioince.
-
swapfile
Para usuários GNU/Linux, é muito comum o termo swap, ou partição swap. Em poucas palavras, ele diz respeito à técnica de extender a memória física, que as vezes não é suficiente, para o disco rígido. No Linux, o subsistema de memória usa um mapeamento virtual da memória, que permite um programa da userspace gravar na memória sem se preocupar onde está fisicamente. Mas este já é assunto para outro post.
Como de costume, logo na instalação de uma distribuição já particionamos o disco de uma tal maneira que uma parte fica reservada para a área de troca, que é a tradução de swap. Alguns usam partições primárias para isto, outros lógicas… Alguns seguem uma regra que diz que “a capacidade do swap deve ser o dobro da memória física”… mas no final, isso fica mesmo é a critério do administrador do sistema.
O problema da partição é que complica no caso de precisar aumentar seu espaço. Para isto, poderia criar outra partição e ativá-la no sistema, mas seria necessário espaço em disco não particionado.
Uma solução rápida para isto seria criar um arquivo de swap, ou swapfile. Para criá-lo é quase igual à uma partição, já que para o Linux, os dispositivos de block são representados como arquivos e, cá entre nós, uma partição nada mais é que um conteiner grande de dados (um arquivão!). Na prática, sua criação ficaria assim:
Gerar um arquivo do tamanho de 512 * 100.000 bytes (100.000 blocos de 512 bytes) contendo apenas zeros:
dd if=/dev/zero of=/tmp/swapfile bs=512 count=100000
Definir o arquivo criado como swap:
mkswap /tmp/swapfile
Ativar o novo arquivo no pool de swap do sistema com prioridade 0 (zero):
swapon -p 0 /tmp/swapfile
Verificar o pool swap do sistema:
swapon -s
Desativar um dispositivo/arquivo swap do sistema:
swapoff /tmp/swapfile
Quanto à performance e aplicabilidade em ambiente de produção, prefiro não opinar, mas acredito ser uma alternativa mais rápida e simples para o aumento da área de troca, swap.
-
ssh com chave privada
No mundo Linux o protocolo ssh é muito utilizado para administração remota e transferência segura de arquivos entre hosts, sendo na maioria servidores. Acredito que sua ampla adoção se deve à simplicidade, velocidade e segurança. Por padrão, na maioria das distribuições Linux ele usa autenticação por senha e um par de chaves públicas.
Outro método de autenticação seria por meio de um par de chaves pública e privada. Nesse método, cada cliente possui uma chave privada que o identifica e deve ser protegida. O servidor recebe a chave pública correspondente de cada cliente para autenticar. Desta forma, não há, à princípio, necessidade de senha. Porém, o próprio certificado pode exigir uma senha para ser acessado, mas assim, ele será único para todos os servidores e não haverá tráfego de senha entre servidor e cliente. Vejamos como fazer isto:
No cliente, é preciso gerar as chaves com o seguinte comando:
ssh-keygen
Ele perguntará por uma senha. Caso queira fornecer, digite-a. Caso queira que o acesso seja direto, deixe em branco. Por padrão, ele gerará dois arquivos: ~/.ssh/id_rsa e ~/.ssh/id_rsa.pub. Respectivamente eles são a chave privada e pública em algorítmo RSA. Copie a chave pública para o servidor (assumindo que o IP dele é 10.0.0.8):
scp ~/.ssh/id_rsa.pub 10.0.0.8:~
No servidor, insira a chave pública recém recebida na lista de chaves autorizadas:
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
Feito isto, basta alterar o modo de autenticação do servidor. Acesse o arquivo de configuração /etc/ssh/sshd_config e altere, acrescente ou descomente as seguintes opções para que confira com o modelo:
# Define autenticação por chave pública RSA. RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys # Desabilita autenticação por senha PasswordAuthentication no PermitEmptyPasswords no
Reinicialize o serviço do ssh. No Slackware execute /etc/rc.d/rc.sshd restart. Agora está pronto, basta testar. No cliente, pode-ser conectar usando duas sintaxes:
ssh 10.0.0.8
Use o exemplo acima caso o nome do arquivo e caminho da chave seja o padrão, ~/.ssh/id_rsa. Se for diferente, a seguinte sintaxe será necessária:
ssh -i <caminho completo para chave privada> 10.0.0.8
Para mais informações, o bom e velho man sempre ajuda.
-
libvirt e LVM2
Uma ótima forma de criar uma estrutura para suportar máquinas virtuais é a parceria entre libvirt e LVM2. No meu caso em específico, uso o emulador qemu-kvm para rodar minhas máquinas virtuais. A seguir, apresentarei como se cria um pool de volumes lógicos no libvirt e como converter máquinas já criadas em arquivos de imagens.
Antes de tudo, é necessário que já tenha sido criado um grupo virtual. Como isso não está no escopo do post, recomendo navegar por esse howto. Com o grupo criado e ativado, vamos criar a definição do pool para o libvirt. Abra um editor de texto, como o vim, e coloque nele o seguinte texto:
<pool type='logical'> <name>logical</name> <source> <device path='/dev/sdb1'/> <name>logical</name> <format type='lvm2'/> </source> <target> <path>/dev/logical</path> </target></pool>
Nesse exemplo, vamos assumir que a partição que compõe o grupo logico é o /dev/sdb1. Após, salve com um nome sugestivo, como por exemplo logical.xml. Agora só resta registrar no libvirt.
virsh pool-define logical.xml
Mesmo registrado, o sistema ainda não ativou o pool. É recomendado que ele seja marcado como autostart, para que caso o libvirt pare, ele ative automaticamente o pool. Para isto, basta os seguintes comandos:
virsh pool-autostart logical virsh pool-start logical
Com o pool inicializado, agora só resta criar um volume lógico dentro dele:
virsh vol-create-as logical disco_teste 10GB
Este comando criará um volume lógico de nome disco_teste no grupo logical tendo como capacidade 10GiB
Convertendo arquivos de imagens em volumes lógicos
Caso já tenha uma máquina virtual configurada em um arquivo de imagem nos formatos suportados pelo qemu, basta convertê-lo usando o próprio qemu-img para o formato desejado. Na versão 0.12.4 os formatos suportados são: cow, qcow, vdi, vmdk, cloop, dmg, bochs, qcow2, host_device, raw entre outros.
Antes de começar, é preciso criar um volume lógico com o mesmo tamanho da imagem existente. Para ter o valor correto, use a ferramenta qemu-img para saber o tamanho total da imagem:
qemu-img info disco.img
Ele retornará algo como:
image: disco.img file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 4.0G cluster_size: 65536
Veja que, embora o arquivo tenha tamanho de 4GB, ele pode crescer até o tamanho virtual, que é de 10GB para esta imagem. Agora, crie um volume lógico com este tamanho seguindo o modelo logo acima.
Eu conheço duas formas de levar o arquivo de imagem para um volume lógico. A primeira é usando o qemu-img para já gravar a imagem no volume:
qemu-img convert -f qcow2 -O host_device disco.img /dev/logical/disco_teste
Ou então, com uma etapa a mais, e portanto mais demorada, transformando a imagem do formato nativo para raw e depois transferindo os dados de forma bruta para o volume com o dd:
qemu-img convert -f qcow2 -O raw disco.img disco.raw dd if=disco.raw of=/dev/logical/disco_teste
O resultado de ambos é o mesmo. Desde que tenha um domínio registrado com esse disco, agora é só usar o volume lógico recém criado. A definição de um disco em volume lógico segue o modelo:
<devices> ... <disk type='block' device='disk'> <source dev='/dev/logical/disco_teste'/> <target dev='sdc' bus='scsi'/> </disk> ... </devices>
-
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.
Tags
- There was a problem connecting to Twitter, or no public messages were found.
Recentes
Estou lendo
Wish list
Blog
- Carlos Feichas
- Debugging Consultoria
- Fabiano Xavier
- Fábio Arezi
- Felipe Molina
- Lucas Catón
- Mateus Penha
- Tiago Mathidios
Lista de Links
- Asterisk Asterisk PBX
- Debugging Consultoria Debugging Consultoria
- LPI
- Slackbuilds Repositório Slackbuilds
- Slackware Site oficial Slackware
- Viva o Linux Comunidade Viva o Linux
- Voip-Info Wiki VoIP