• Autor
  • Contato
  • AboutMe
  • ContactMe
Tchello Blog by Marcelo Moreira de Mello
  • Posts
  • Contato
  • Autor
  • Flickr
  • GPG Key
  • RSS Feed
  • Twitter
  • Facebook

About Author: Marcelo Moreira de Mello

Website
http://marcelo.mmello.org

Posts by Marcelo Moreira de Mello

3

Ativando e Desativando CPU’s sob demanda

By
Marcelo Moreira de Mello
– 24 October, 2009

Olá pessoal,
Após 1 semana sem escrever algum post (semana corrida) hoje irei demonstrar como podemos ativar ou desativar CPU’s sob demanda no seu linux.
Antes de começarmos, necessitamos checar se o kernel utilizado tem suporte a CPU Hotplug ( o kernel do Red Hat Entreprise Linux e o Fedora 11 tem).

[root@mmello boot]# grep HOTPLUG config-2.6.18-164.el5   | grep -v PCI
CONFIG_HOTPLUG=y
CONFIG_HOTPLUG_CPU=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ACPI_HOTPLUG_CPU=y
[root@mmello boot]# uname -a
Linux mmello.gru.redhat.com 2.6.18-164.2.1.el5xen #1 SMP Mon Sep 21 04:52:16 EDT 2009 i686 i686 i386 GNU/Linux
[root@mmello boot]#

Pronto!!! Se seu kernel tem esse suporte, podemos começar a brincar com as CPU’s, entretanto se o kernel utilizado não tem suporte, você pode adicionar o suporte.
Q: How to i enable my kernel to support CPU hotplug?
A: When doing make defconfig, Enable CPU hotplug support

   “Processor type and Features” -> Support for Hotpluggable CPUs
   Make sure that you have CONFIG_HOTPLUG, and CONFIG_SMP turned on as well.
You would need to enable CONFIG_HOTPLUG_CPU for SMP suspend/resume support as well.
Fonte: /usr/share/doc/kernel-doc-*/Documentation/cpu-hotplug.txt
 Visualizando a quantidade de CPUs utilizados no momento: 

[root@mmello cpu]# cd /sys/devices/system/cpu/
[root@mmello cpu]# ls
cpu0  cpu1
[root@mmello cpu]# cat /proc/cpuinfo  | grep -e processor -e “model name”
processor       : 0
model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz
processor       : 1
model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz
[root@mmello cpu]#
[root@mmello cpu]# cat /proc/interrupts
           CPU0              CPU1             
  1:      15838          0        Phys-irq  i8042
  8:          1          0        Phys-irq  rtc
  9:      15563          0        Phys-irq  acpi
 12:    1419340          0        Phys-irq  i8042
 14:     196343          0        Phys-irq  ide0
 16:          2          0        Phys-irq  yenta, uhci_hcd:usb2, radeon@pci:0000:01:00.0
 21:         27          0        Phys-irq  ehci_hcd:usb1, uhci_hcd:usb5
 22:       1635          0        Phys-irq  uhci_hcd:usb3, HDA Intel
 23:          0          0        Phys-irq  uhci_hcd:usb4
248:     563615       4974        Phys-irq  iwl3945
249:      11012          0        Phys-irq  peth0
250:     111120          0        Phys-irq  ahci
256:    3211767          0     Dynamic-irq  timer0
257:     456846          0     Dynamic-irq  resched0
258:         51          0     Dynamic-irq  callfunc0
259:          0     725421     Dynamic-irq  resched1
260:          0        123     Dynamic-irq  callfunc1
261:          0    1709771     Dynamic-irq  timer1
262:        771          0     Dynamic-irq  xenbus
263:          0          0     Dynamic-irq  console
264:          2          0     Dynamic-irq  vif1.0
265:          1          0     Dynamic-irq  blkif-backend
NMI:          0          0
LOC:          0          0
ERR:          0
MIS:          0

 Como podemos perceber, dentro do diretório /sys/devices/system/cpu existem 2 diretórios (cpu0 e cpu1) que na verdade refletem a quantidade de CPU’s reconhecida pelo kernel.
Um detalhe interessante é que dentro do diretório /sys/devices/system/cpu/cpu0 não existe o arquivo online, pois a CPU0 é utilizada para iniciar outros componentes de hardware.

[root@mmello cpu0]# pwd
/sys/devices/system/cpu/cpu0
[root@mmello cpu0]# ls
cache  cpufreq  crash_notes  topology
[root@mmello cpu0]# cd ../cpu1/
[root@mmello cpu1]# ls
cache  cpufreq  crash_notes  online  topology
[root@mmello cpu1]#

Para desligar a CP
U, basta alterarmos o valor do arquivo online e o kernel irá desligar essa CPU sendo totalmente ignorada pelo sistema.

[root@mmello cpu1]# pwd
/sys/devices/system/cpu/cpu1
[root@mmello cpu1]# ls
cache  cpufreq  crash_notes  online  topology
[root@mmello cpu1]# cat online
1
[root@mmello cpu1]# echo 0 > online
[root@mmello cpu1]# cat /proc/cpuinfo  | grep -e processor -e “model name”
processor       : 0
model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz
[root@mmello cpu1]# cat /proc/interrupts
           CPU0             
  1:      18028        Phys-irq  i8042
  8:          1        Phys-irq  rtc
  9:      15808        Phys-irq  acpi
 12:    1459630        Phys-irq  i8042
 14:     199799        Phys-irq  ide0
 16:          2        Phys-irq  yenta, uhci_hcd:usb2, radeon@pci:0000:01:00.0
 21:         27        Phys-irq  ehci_hcd:usb1, uhci_hcd:usb5
 22:       1657        Phys-irq  uhci_hcd:usb3, HDA Intel
 23:          0        Phys-irq  uhci_hcd:usb4
248:     572614        Phys-irq  iwl3945
249:      11206        Phys-irq  peth0
250:     111818        Phys-irq  ahci
256:    3282320     Dynamic-irq  timer0
257:     479545     Dynamic-irq  resched0
258:         51     Dynamic-irq  callfunc0
262:        771     Dynamic-irq  xenbus
263:          0     Dynamic-irq  console
264:          2     Dynamic-irq  vif1.0
265:          1     Dynamic-irq  blkif-backend
NMI:          0
LOC:          0
ERR:          0
MIS:          0
[root@mmello cpu1]#


Agora sim!!! :)   O kernel esta reconhecendo somente 1 processador (core) em meu sistema e fez o recálculo das IRQ’s e dos processos para serem executados somente pela CPU0.
Para habilitar novamente a CPU1, basta alterar o arquivo online para 1.
[root@mmello cpu1]# pwd
/sys/devices/system/cpu/cpu1
[root@mmello cpu1]# ls
crash_notes  online
[root@mmello cpu1]# cat online
0
[root@mmello cpu1]# echo 1 > online
[root@mmello cpu1]# cat /proc/cpuinfo  | grep -e processor -e “model name”
processor       : 0
“background-color: #eeeeee; color: black;” />model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz
processor       : 1
model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz
[root@mmello cpu1]# cat /proc/interrupts
           CPU0              CPU1             
  1:      19194          0        Phys-irq  i8042
  8:          1          0        Phys-irq  rtc
  9:      15923          0        Phys-irq  acpi
 12:    1467238          0        Phys-irq  i8042
 14:     201365          0        Phys-irq  ide0
 16:          2          0        Phys-irq  yenta, uhci_hcd:usb2, radeon@pci:0000:01:00.0
 21:         27          0        Phys-irq  ehci_hcd:usb1, uhci_hcd:usb5
 22:       1660          0        Phys-irq  uhci_hcd:usb3, HDA Intel
 23:          0          0        Phys-irq  uhci_hcd:usb4
248:     576780       4974        Phys-irq  iwl3945
249:      11294          0        Phys-irq  peth0
250:     112381          0        Phys-irq  ahci
256:    3316395          0     Dynamic-irq  timer0
257:     480164          0     Dynamic-irq  resched0
258:         51          0     Dynamic-irq  callfunc0
259:          0     761653     Dynamic-irq  resched1
260:          0        123     Dynamic-irq  callfunc1
261:          0    1759641     Dynamic-irq  timer1
262:        771          0     Dynamic-irq  xenbus
263:          0          0     Dynamic-irq  console
264:          2          0     Dynamic-irq  vif1.0
265:          1          0     Dynamic-irq  blkif-backend
NMI:          0          0
LOC:          0          0
ERR:          0
MIS:          0

[root@mmello cpu1]#

No próximo post, demonstrarei como podemos dedicar algumas CPU’s para tarefas/processos específicos no sistema, como por exemplo, executar o Oracle em um processador físico com exclusividade em uma máquina bi-processada por exemplo.

Era isso aí!!!
Abraços.

Tweet
Tags: cpu hotplug habilitando cpu sob demanda, Posts
9

Utilizando o RPM como ferramenta de recovery e auditoria

By
Marcelo Moreira de Mello
– 17 October, 2009

Olá pessoal,
Depois de alguns dias, estou retornando com mais um post. Hoje, pretendo demonstrar como podemos utilizar o sistema RPM para recuperarmos permissões de arquivos e verificarmos quando um arquivo ou binário foi alterado no sistema.
O RPM (Red Hat Package Manager) é uma ferramenta poderosa que nos permite não só instalar ou remover softwares, mas também verificar o estado de cada arquivo do sistema que foi oferecido por pacotes RPM.
Quem nunca acidentalmente executou um chmod 777 -R / ou até mesmo um chown nobody:nobody -R / ?!?!  (é… esse eu peguei pesado, mas vale como exemplo :P )  Ou até mesmo se perguntou será que o binário /bin/ls foi alterado no servidor de produção!?!
Podemos verificar as situações colocadas acima, utilizando o comando RPM com parâmetro –verify (V), que consiste em pesquisar no banco de dados do rpm (/var/lib/rpm) quais arquivos foram modificados desde a instalação do pacote.
 Se quiséssemos verificar se o binário /bin/ls foi alterado em nosso sistema, a primeira informação que precisamos adquirir será saber qual o pacote RPM que ofereceu o binário /bin/ls. Para isso, podemos:

[root@mmello ~]# rpm -qf /bin/ls
coreutils-5.97-12.1.el5

Uma vez descoberto o pacote de origem do binário, podemos verificar se todos os arquivos oferecidos pelo pacote coreutils foram alterados desde a sua instalação na máquina.
[root@mmello ~]# rpm -V coreutils
[root@mmello ~]#
 
A saída do comando acima nos mostrou que nenhum binário foi alterado no sistema desde a sua instalação.  O que iremos fazer agora é forçar um erro, isto é, substituir algum binário que foi instalado pelo pacote coreutils e fazer a verificação novamente.

[root@mmello ~]# cp /bin/date  /bin/ls
cp: overwrite `/bin/ls’? y
[root@mmello ~]# ls
Sat Oct 17 11:23:07 BRT 2009
[root@mmello ~]#
 

Pronto! Substituímos o binário /bin/ls pelo comando /bin/date e agora iremos refazer a checagem através do RPM.

[root@mmello ~]# rpm -V coreutils
S.5….T   /bin/ls
[root@mmello ~]#

A saída do comando nos mostrou que o  Size (S), o MD5 (5) e o Timestamp (T) foram alterados no binário /bin/ls desde a instalação. Podemos concluir se o MD5 do binário esta diferente logo o binário foi alterado. Para corrigirmos, teremos que reinstalar o RPM no sistema.

[root@mmello ~]# rpm -ivh coreutils-5.97-12.1.el5.i386.rpm –replacepkgs
warning: coreutils-5.97-12.1.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
Preparing…                ########################################### [100%]
   1:coreutils              ########################################### [100%]
[root@mmello ~]# ls
anaconda-ks.cfg                   install.log
coreutils-5.97-12.1.el5.i386.rpm  install.log.syslog
[root@mmello ~]# rpm -V coreutils
[root@mmello ~]#
 

Se quisessemos realizar uma checagem em todo os arquivos do sistema, podemos executar o comando rpm -Va 
Esse recurso também é interessante para controlarmos mudanças em arquivos texto e gerenciarmos permissões e proprietários de arquivos.
Primeiro, iremos verificar qual pacote RPM oferece o arquivo /etc/inittab e checar se quais arquivos foram alterados desde a  instalação do pacote.

 [root@mmello ~]# rpm -qf /etc/inittab
initscripts-8.45.17.EL
[root@mmello ~]# rpm -V initscripts
..5….T c /etc/inittab
S.5….T c /etc/rc.d/rc.local
[root@mmello ~]#

Como podemos ver acima, o arquivo /etc/inittab teve o conteúdo alterado 5(MD5) e o T(Timestamp) e o arquivo /etc/rc.d/rc.local além do conteúdo, o tamanho  também foi alterado.
Poderíamos piorar a situação, fazendo o seguinte: 

[root@mmello ~]# ls -la /etc/inittab
-rw-r–r– 1 root root 1666 Oct 17 09:41 /etc/inittab
[root@mmello ~]# chmod  777 /etc/inittab
[root@mmello ~]# chown  nobody:nobody /etc/inittab
[root@mmello ~]# ls -la /etc/inittab
-rwxrwxrwx 1 nobody nobody 1666 Oct 17 09:41 /etc/inittab
 

Se consultarmos agora, veremos que as permissões do arquivo foram alteradas M(Mode) bem como o proprietário U(User) e grupo G(Group).

[root@mmello ~]# rpm -V initscripts
.M5..UGT c /etc/inittab
S.5….T c /etc/rc.d/rc.local
 

Podemos usar o RPM para recuperar as permissões e proprietários dos arquivos chamando as opções –setperms e –setugids respectivamente.
[root@mmello ~]# rpm -q initscripts –setperms
[root@mmello ~]# ls -la /etc/inittab
-rw-r–r– 1 nobody nobody 1666 Oct 17 09:41 /etc/inittab
[root@mmello ~]# rpm -V initscripts
..5..UGT c /etc/inittab
S.5….T c /etc/rc.d/rc.local
[root@mmello ~]# rpm -q initscripts –setugids
[root@mmello ~]# ls -la /etc/inittab
-rw-r–r– 1 root root 1666 Oct 17 09:41 /etc/inittab
[root@mmello ~]# rpm -V initscripts
..5….T c /etc/inittab
S.5….T c /etc/rc.d/rc.local


Como podemos ver, o RPM restaurou as permissões e proprietários originais do arquivo. Isto é, se um dia algum administrador descuidado executar chmod 777 -R / , você poderia executar o comando rpm -qa –setperms para recuperar todos os arquivos que originalmente foram criados por pacotes RPM.

Acho que era isso aí.. ;)
<
span style=”font-size: x-small;”>Abraços..

Tweet
Tags: Posts, rpm recovery auditoria setperms restore
6

Ataque de Dicionário com OpenSSL – Quebrando senhas

By
Marcelo Moreira de Mello
– 12 October, 2009

Olá,
Você já deve ter se perguntado: Como que o linux faz para autenticar um usuário no arquivo /etc/shadow?!?!
Hoje vou mostrar como podemos utilizar o openssl para realizar um ataque de dicionário contra as senhas armazenadas no arquivo /etc/shadow.
Primeiramente, irei setar a senha do usuário marcelo para finger. Coloquei finger?!?! Porque é uma palavra que está cadastrada no arquivo /usr/share/dict/linux.words que será o arquivo de dicionário que irei utilizar como fonte de senhas. 

[root@mmello ~]# echo finger | passwd –stdin marcelo
Changing password for user marcelo.
passwd: all authentication tokens updated successfully.

Sim, podemos dizer que o arquivo /usr/share/dict/linux.words pode ser chamado de dicionário hacker, embora existam muito mais arquivos utilizados para essa finalidade e alguns com gigabytes de tamanho.
Para quebrarmos a senha com sucesso, precisamos entender como funciona o campo de senha do arquivo /etc/shadow.

[root@mmello ~]# grep marcelo /etc/shadow
marcelo:$1$zFsqshA3$Sol9g2OAEwswwladdDCax0:14529:0:99999:7:::


Note que o caracter $ é utilizado como separador de argumentos dentro do campo de senha.
$1$ – Indica que estamos trabalhando com hashes em MD5. Algoritmos de MD5 são chamados de também de algoritmos de hash e possuem a característica de ser one-way, isto é, você fornece um arquivo ou uma string e ele gerará um conjunto de números (hash) que servirá como integridade do arquivo. Quando esse número for diferente, o arquivo ou a entrada foram alterados. One-way por você nunca irá pegar o hash gerado e converter novamente na entrada ou arquivo original.
 [root@mmello ~]# echo linux rocks | md5sum
6453bea88e9acdd8d3ccead424063432  -
[root@mmello ~]# echo Linux Rocks | md5sum
9d96c752c61fd1f96ddce20ec0be1dd4  -

 
$zFsqshA3$ – Campo destinado para o salt. Salt é uma string randomizada que é gerada no momento em que você cadastra a senha. Como trabalhamos com senhas com hash MD5, se não utilizássemos o salt, dois ou mais usuários que tivessem a mesma senha iriam ter o mesmo hash armazenado no arquivo /etc/shadow.
$Sol9g2OAEwswwladdDCax0 - A senha do usuário. Esse campo é a composição da senha + salt | hash md5
Vamos ao que interessa. Utilizaremos o comando openssl, chamando a função passwd para interpretar as informações do arquivo /etc/shadow e fazer um ataque de dicionário. 
[root@mmello ~]# openssl  passwd –help
Usage: passwd [options] [passwords]
where options are
-crypt             standard Unix password algorithm (default)
-1                   MD5-based password algorithm
-apr1              MD5-based password algorithm, Apache variant
-salt string     use provided salt
-in file            read passwords from file
-stdin             read passwords from stdin
-noverify        never verify when reading password from terminal
-quiet             no warnings
-table             format output as table
-reverse         switch table columns

Agrupando as informações:
[root@mmello ~]# openssl  passwd -1 -salt ‘zFsqshA3′ -table -in /usr/share/dict/linux.words  | grep ‘Sol9g2OAEwswwladdDCax0′
finger  $1$zFsqshA3$Sol9g2OAEwswwladdDCax0

Depois de 49 segundos, a senha do usuário foi descoberta.

Faça o teste em seu servidor, teste a complexidade de sua senha e sempre lembre: Alterne ao máximo o caracteres de sua senha com números, caracteres especiais,  maiúsculas e minúsculas. 

Grande abraço.

Tweet
Tags: openssl ataque dicionário quebrar senhas, Posts
2

Criando devices persistentes com udev

By
Marcelo Moreira de Mello
– 12 October, 2009

Olá pessoal,

Resolvi escrever o primeiro post desse blog, explicando como podemos utilizar o udev para criarmos dispositivos de maneira persistente em servidores linux.

Para que vocês possam entender melhor em que situação vamos utilizá-lo vamos imaginar o seguinte cenário: como todo bom administrador, devemos nos preocupar com a realização de backups de maneira constante e isso não poderia ser diferente em sua estação de trabalho. Assim, você acaba de adquirir um HD externo via usb para realizar seus backups. Como esse HD é um dispositivo de armazenamento via usb, o kernel irá reconhece-lo através do módulo chamado usb_storage. Todo dispositivo  que é acessado via o módulo usb_storage, será reconhecido pelo kernel como se fosse um dispositivo SCSI ou SATA e por esse motivo acessado através  /dev/sd*.

Baseando-se nessas informações, a ordem em que os dispositivos são conectados  é de suma importância para com os nomes que esses dispositivos irão receber, isto é, se já houver um dispositivo SCSI ou SATA na máquina e o HD for conectado, o kernel irá reconhece-lo como /dev/sdb, por outro lado, se já existirem 2 dispositivos e o HD for conectado, o kernel irá reconhece-lo como /dev/sdc.

Sabendo dessas características, imaginemos aquele script de backup que você fez, para  sempre copiar os dados do seu diretório pessoa para esse HD (um script utilizando o rsync, e diga-se de passagem que é uma ótima ferramenta para sincronizar arquivos) como iremos garantir que o HD sempre será reconhecido como /dev/sdb1 ou até mesmo como /dev/bkp-disc por exemplo?

Para isso, agora damos sentido e motivação para criarmos regras através do udev para reconhecimento dos dispositivos de maneira automática e persistente, de modo que a ordem em que o dispositivo for conectado no sistema não modifique o nome do dispositivo no sistema.

No exemplo abaixo, irei utilizar o meu pendrive como dispositivo de armazenamento de dados e criar uma regra no udev para que o kernel sempre o reconheça através do dispositivo /dev/backup/pendrive-corsair.

1) Reconhecendo o dispositivo:

Para criarmos a regra, é importantíssimo a aquisição do máximo de informações possíveis sobre o dispositivo para que essas informações sejam combinadas com a finalidade de reconhecer esse dispositivo como único.  Para isso, poderemos utilizar informações como SYSFS{serial}, Model, Vendor, Label de cada dispositivo.

Para a visualização das informações do dispositivo que serão utilizadas como base para a criação da regra, podemos utilizar o comando udevmonitor. Lembre-se de executar o comando antes de conectar o pendrive no sistema.

[root@mmello ~]# udevmonitor
udevmonitor prints the received event from the kernel [UEVENT]
and the event which udev sends out after rule processing [UDEV]

Com o udevmonitor em execução, conecte  o pendrive drive e teremos uma saída parecida com a abaixo:

UEVENT[1255310436.834501] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-5
UEVENT[1255310436.834558] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-5/usbdev1.3_ep00
UEVENT[1255310436.835214] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0
UEVENT[1255310436.835258] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0/usbdev1.3_ep81
UEVENT[1255310436.835309] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0/usbdev1.3_ep02
UEVENT[1255310436.836472] add@/class/usb_device/usbdev1.3
UDEV  [1255310436.836472] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-5
UDEV  [1255310437.067368] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-5/usbdev1.3_ep00
UEVENT[1255310437.127863] add@/module/usb_storage
UEVENT[1255310437.129329] add@/bus/usb/drivers/usb-storage
UEVENT[1255310437.130821] add@/class/scsi_host/host4
UDEV  [1255310437.147745] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0
UDEV  [1255310437.352425] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0/usbdev1.3_ep81
UDEV  [1255310437.354021] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0/usbdev1.3_ep02
UDEV  [1255310437.372298] add@/class/scsi_host/host4
UDEV  [1255310437.661869] add@/class/usb_device/usbdev1.3
UEVENT[1255310442.132037] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0/host4/target4:0:0/4:0:0:0
UEVENT[1255310442.132079] add@/class/scsi_disk/4:0:0:0
UEVENT[1255310442.196681] add@/block/sdb
UEVENT[1255310442.196720] add@/block/sdb/sdb1
UEVENT[1255310442.196760] add@/class/scsi_device/4:0:0:0
UEVENT[1255310442.196797] add@/class/scsi_generic/sg1
UDEV  [1255310442.300359] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0/host4/target4:0:0/4:0:0:0
UDEV  [1255310442.527154] add@/class/scsi_generic/sg1
UDEV  [1255310442.527193] add@/class/scsi_disk/4:0:0:0
UDEV  [1255310442.543947] add@/block/sdb
UDEV  [1255310442.710674] add@/class/scsi_device/4:0:0:0
UDEV  [1255310442.902840] add@/block/sdb/sdb1
UEVENT[1255310443.306232] add@/module/fat
UEVENT[1255310443.335451] add@/module/vfat
UEVENT[1255310443.339346] mount@/block/sdb/sdb1
UDEV  [1255310443.340535] mount@/block/sdb/sdb1

Na listagem gerada pelo udevmonitor acima, podemos notar desde o processo da identificação do dispositvo, a carga do módulo usb_storage, o nome do dispositivo que foi atribuído pelo kernel ao dispositivo e finalizando com a montagem do mesmo.

A linha mais importante no momento é UEVENT[1255310442.196681] add@/block/sdb que informa como o kernel reconheceu e nomeou o dispositivo.

O udev alimenta o SYSFS, isto é, se nos posicionarmos no diretório /sys/block/sdb teremos algumas informações sobre o pendrive conectado.

[root@mmello sdb]# pwd
/sys/block/sdb
[root@mmello sdb]# ls
dev  device  holders  queue  range  removable  sdb1  size  slaves  stat  subsystem  uevent
[root@mmello sdb]#

Para facilitar a localização de informações do dispositivo, podemos utilizar o comando udevinfo passando como argumento a localização do dispositivo reconhecido.

[root@mmello sdb]# udevinfo  -a -p /block/sdb | less

O comando acima listará uma série de informações sobre o dispositivo. Nosso trabalho agora é escolher algumas informações de modo com que quando combinadas, reconheçam o dispositivo como único no mundo, e o udev possa ajudar o kernel a reconhece-lo sempre pelo mesmo nome.  Escolhi essas informações:

BUS==”usb”
DRIVER==”usb”
SYSFS{serial}==”A110000000026017″
SYSFS{product}==”Flash Voyager”
SYSFS{manufacturer}==”Corsair”

2) Criando a regra

Precisamos criar um arquivo dentro do diretório /etc/udev/rules.d, devemos respeitar 2 regras:

 a) o arquivo precisa iniciar com um número que indicará a ordem que o mesmo será processado;
 b) o arquivo precisa finalizar com a extensão .rules

Retire o pendrive do computador, e vamos criar nossa regra:

[root@mmello rules.d]# vim /etc/udev/rules.d/62-pendrive.rules

<
strong>DRIVER==”usb”, SYSFS{serial}==”A110000000026017″, SYSFS{product}==”Flash Voyager”, SYSFS{manufacturer}==”Corsair”, NAME=”backup/pendrive-corsair”, SYMLINK=”pendrive-corsair”

Na regra acima, mapeamos que sempre que conectado um dispositivo que for USB, o fabricante Corsair, o modelo Flash Voyager e com o serial A110000000026017 será criado o dispositivo /dev/backup/pendrive-corsair e com um link simbólico para /dev/pendrive-corsair.

Para testarmos, salve o arquivo e digite o comando udevtrigger para recarregar as configurações do udev.

Conecte o pendrive e pronto, sua regra já esta funcionando!!!

[root@mmello rules.d]# ls -la /dev/backup/pendrive-corsair
brw-r—– 1 root disk 8, 17 Oct 11 22:48 /dev/backup/pendrive-corsair

[root@mmello rules.d]# ls -la /dev/pendrive-corsair
lrwxrwxrwx 1 root root 23 Oct 11 22:48 /dev/pendrive-corsair -> backup/pendrive-corsair

[root@mmello rules.d]# df -h /dev/backup/pendrive-corsair
Filesystem            Size  Used Avail Use% Mounted on
/dev/backup/pendrive-corsair
                      1.9G   20K  1.9G   1% /media/mmello

Ainda seria possível adicionar nessa regra os parâmetros OWNER, GROUP, MODE para personalizar as permissões do dispositivo.

OWNER=”user”, GROUP=”group”, MODE=”0755″

Para maiores informações, man udev e consulte o diretório /usr/share/doc/udev-***/writing_udev_rules

Grande abraço.

Tweet
Tags: Posts, udev device persistente rules.d
2

Bem Vindos!!!!

By
Marcelo Moreira de Mello
– 11 October, 2009

lá pessoal,

Já faz algum tempo que esse blog vem se ensaiando para sair do forno.. e eis que aqui estamos..

Arrumei um tempo para criar a conta e deixar tudo pronto para começar alimentar esse blog com minhas experiências profissionais, pessoais e dividir um pouco alguns momentos com vocês…

Enfim… bem-vindos…

Abs.. e até breve…

Gtalk: tchello.mello@gmail.com
MSN: tchello.mello@gmail.com

Tweet
Tags: Personal, Posts
0

GPG-Key

By
Marcelo Moreira de Mello
– 16 May, 2009
Tweet
0

Flickr

By
Marcelo Moreira de Mello
– 15 May, 2009

flickr-logo

Tweet
Tags: flickr, fotos, perfil
0

Contato

By
Marcelo Moreira de Mello
– 15 May, 2009
*(denotes required field)
CAPTCHA Image
Refresh Image

Powered by Fast Secure Contact Form

Tweet
Tags: contato
0

Autor

By
Marcelo Moreira de Mello
– 15 May, 2009

Marcelo Moreira de Mello

MARCELO MOREIRA DE MELLO was born in São Paulo, Brazil but was brought up in Passo Fundo/Porto Alegre in Rio Grande do Sul – Brazil. Nowadays he lives in São Paulo Porto Alegre with his lovely wife Renata and their 2 dogs (Theo and Sophie).

Currently he holds a Senior Software Maintenance Engineer position at Red Hat Inc, having also worked for several years as Senior Instructor and Consultant for the same company. Marcelo is certified in RHCI, RHCX, RHCE, RHCDS, RHCVA, RHCSS, RHCA, among other certifications. Marcelo assists Fedora Project as Fedora Brazil Ambassador.

He also is an enthusiastic photographer and chef. This aims to share some tips and learn about cooking and photography.

The material published here is personal and does not reflect Red Hat’s opinion.

Profissional Contact: mmello <at> redhat.com

Personal Contact/MSN: marcelo <at> mmello.org

About.me: http://about.me/mmello



MARCELO MOREIRA DE MELLO nasceu em São Paulo, Brasil mas cresceu em Passo Fundo/Porto Alegre no Rio Grande do Sul – Brasil. Hoje em dia ele mora em São Paulo Porto Alegre com sua amável esposa Renata e seus 2 cachorros (Theo e Sophie).

Atualmente ele ocupa o cargo de Senior Software Maintenance Engineer na Red Hat Inc, mas trabalhou por vários anos como Instrutor e Consultor Senior na mesma empresa. Marcelo possui algumas certificações como RHCI, RHCX, RHCE, RHCDS, RHCVA, RHCSS, RHCA. Marcelo também participa do Projeto Fedora Brasil como embaixador.

Ele também é um entusiasta por fotografia e culinária. Este blog irá tentar compartilhar/aprender algumas dicas sobre cozinha e fotografia.

Todos os materiais publicados neste blog são pessoais, e não refletem a opinião de minha empresa.

Contato Profissional: mmello <at> redhat.com

Contato Pessoal/MSN: marcelo <at> mmello.org

About.me: http://about.me/mmello

Tweet
Tags: autor
Page 6 of 6« First«...23456
  • Conecte-se / Follow us
    *
  • Photos (view gallery)
    Happy Sophie :)White WolfCactiCais do PortoRed CandlesSunset @ San Antonio, TXHoover DamSunset @ Porto AlegreFace in Rock - Sedona/AZToucanYaki Point - Grand Canyon National ParkSunset in SedonaRight WayVortex TreeIgreja Matriz São Pedro - Gramado/RSMohave Point - Grand Canyon National Park
  • Últimos/Recent Posts
    • Spacewalk 1.6 Released
    • Sharing with fpaste.org
    • Compartilhe com fpaste.org
    • Sharing resources with Synergy
    • Compartilhando recursos com Synergy
    • Boleadoras Show in Porto Alegre/RS – Brazil :)
    • RHN Satellite Tips and Tricks – Red Hat Summit 2011 by Thomas Cameron
  • Tags
    atualizando fedora preupgrade bash bash-completion beta cpu hotplug habilitando cpu sob demanda cpuset dedicando cpu isolcpus cryptsetup pendrive criptografia evento universidade são caetano do sul certificações Red Hat f14 fedora fedora 14 fpaste glibc hug a developer iptables recent regras dinâmicas java javac kickstart instalação automatizada anaconda linux install system-config-kickstart kickstart pxe dhcp syslinux pxelinux.0 lemon pepper Linus Torvalds linux LinuxCon LinuxCon2010 linux configs mount journal writeback ordered ext3 tune2fs blkid mouse Oracle Personal Photograph Posts red hat redhat revista espírito livre blueproximity bluetooth rhel6 beta rlwrap segurança sound spacewalk sqlplus synergy tchelinux evento palestrantes puc rs vi vim workaround
  • Spacewalk Stats

    Ohloh profile for mmello


  • Blogroll
    • Alberto Silva
    • Dan Walsh
    • Dennis Gilmore
    • Douglas Landgraf
    • Flavio's Blog
    • Glauber Costa – glommer.net
    • Gustavo Duarte
    • Jeronimo Zucco
    • João Paulo de Lima Barbosa
    • Osmar Leão
    • Pablo Hess
    • Ricardo Ferreira
  • Arquivo/Archive

About Arras WordPress Theme

Tchello Blog