terça-feira, 25 de outubro de 2011

Cópias remotas de arquivos

Fonte:http://www.devin.com.br/copias-remotas-de-arquivos/
Autor: Hugo Cisneiros (Eitch)
Uma das tarefas mais comuns de um administrador de sistemas é copiar arquivos de uma máquina para outra. Em rede, isto pode ser feito de diversas maneiras, como por exemplo: FTP, HTTP, SSH, RSYNC, entre outros. Este artigo mostra as principais formas de fazer isso. Vou tentar ser o mais direto possível.
Vamos usar aqui dois servidores exemplo:
  • servidor1.example.com (192.168.0.1)
  • servidor2.example.com (192.168.0.2)

SSH

O protocolo do SSH é seguro o suficiente para fazer cópias entre servidores em uma rede e é sempre o protocolo recomendado. Vamos agora para como fazer isso:
Copiando um arquivo simples de uma máquina para outra
servidor1$ scp maluco@servidor2.example.com:~/arquivo.txt ./

O comando acima copia o arquivo.txt do HOME (~) do usuário maluco, do servidor2 para o diretório atual do servidor1. Bem parecido com o comando cp.

Copiando todo um diretório de uma máquina para outra
servidor1$ scp -r maluco@servidor2.example.com:/home/maluco /tmp

Ou seja, copio o diretório maluco do servidor2 para a máquina atual, no diretório /tmp.
servidor1$ scp -Cpr maluco@servidor2.example.com:/home/maluco /tmp

O parâmetro -C agora faz a mesma ação anterior, só que agora compactando os dados antes de enviar pela rede. O ssh usa formato gzip e pode-se usar essa opção caso se queira economizar na banda de rede.

O parâmetro -p preserva todos modos e timestamps de arquivos, ideal para fazer uma cópia mais exata.

Usando o tar e o ssh para cópias mais exatas ainda

Por exemplo, um backup de sistema. O tar é ótimo para criar um arquivamento que preserva todas as permissões, usuários e grupos donos, modos, links simbólicos, etc. Desse jeito dá pra juntar os dois:
servidor1$ tar -cpzf - /etc | ssh maluco@servidor2.example.com "cat > /var/lib/backup/servidor1-etc.tar.gz"

O comando acima vai compactar o diretório /etc, só que ao invés de jogar o resultado em um arquivo, joga como STDIN, que o comando ssh pega e executa no servidor2 o comando cat, que por sua vez pega o STDIN e joga para o arquivo /var/lib/backup/servidor1-etc.tar.gz.

Em outras palavras, ele compacta o diretório /etc e já joga no outro servidor direto. Isso economiza tempo e espaço no servidor origem.
servidor1$ tar -C /home -cpzf - maluco | ssh maluco@servidor2.example.com "tar -C /home -xpzf -"

Agora ao invés de usar o cat, ele jogou diretamente o diretório na máquina remota, descompactado. É parecido com a opção -rp do scp, só que com a vantagem do tar: preserva modos, permissões, donos, links, etc.

Para mais informações sobre STDIN, STDOUT, pipes (|), tenho um outro artigo falando sobre isso.


HTTP e FTP


A primeira coisa que você precisa saber é que eu não vou ensinar a compartilhar os arquivos por HTTP e FTP neste artigo. É um assunto totalmente diferente, então vamos assumir que você já tenha os arquivos servidos via HTTP ou FTP em algum lugar :)

Pra quem já é um pouco acostumado com esses protocolos, um programa sempre vem na mente: wget. Mas além dele também há um comando muito útil para fazer operações mais complexas: o lftp.

Pegando arquivos e páginas via HTTP/FTP
servidor1$ wget -c 'http://servidor2.example.com/arquivo.txt' -O /home/maluco/informacoes.txt

O comando acima pega o arquivo.txt do servidor1 e o escreve (-O) em /home/maluco/informacoes.txt. Se você não especificar o -O, ele coloca no diretório atual com o mesmo nome remoto (no caso, arquivo.txt). O -c é para ele tente continuar um download caso o arquivo já exista, e a não ser que você queira sobrescrever os arquivos destino, é bom sempre usar a opção.
servidor1$ wget -c -r 'http://www.devin.com.br'

Já este vai fazer uma cópia recursiva de todo o site www.devin.com.br. Isso inclui os links e imagens, que o wget pega automaticamente do código HTML.

Mirrors com lftp

E falando em recursividade, o lftp fornece ótimos recursos para fazer este tipo de download. Por exemplo, eu estou afim de criar um espelho interno do repositório de pacotes do CentOS. Vamos supor que eu tenha escolhido o mirror kernel.org, via HTTP:
servidor1$ lftp
lftp :~> open http://mirrors.kernel.org/centos/5.5/os/x86_64/
lftp mirrors.kernel.org:/centos/5.5/os/x86_64> mirror -verbose
[...]

O lftp se encarrega de examinar o diretório e pegar todo o seu conteúdo: arquivos e sub-diretórios, salvando no diretório atual. A opção –verbose vai mostrando na tela o que o lftp está fazendo (analizando os diretórios, baixando os arquivos…).

O mesmo pode ser feito com um comando só, um ótimo jeito para se fazer isso automaticamente em shell-scripts:
servidor1$ lftp -c "open http://mirrors.kernel.org/centos/5.5/os/x86_64/ && mirror --verbose"

Ou seja, com o parâmetro -c, consigo executar os dois comandos (conectar, fazer mirror) de modo não-interativo, e depois ele sai do programa (para não sair, usa-se o -e ao invés de -c). O mirror também analisa e continua os downloads de onde parou, caso precise.

A mesma coisa pode ser feita via FTP, vamos supor agora que é preciso também de usuário e senha…
servidor1$ lftp -c "open ftp://usuario:senha@mirrors.kernel.org/centos/5.5/os/x86_64/ && mirror --verbose"

O lftp ainda suporta uma porrada de opções. São centenas. Nesse caso, a manpage sempre ajuda (man lftp). Uma das opções que eu acho muito legal é a exclude. Com a opção exclude, eu consigo fazer um download recursivo, retirando arquivos com nomes que não quero. Por exemplo:
servidor1$ lftp -c "set mirror:exclude-regex '(\.svn|SRPMS)' && open ftp://mirrors.kernel.org/centos/5.5/os/ && mirror --verbose"

No comando acima, eu estou excluindo qualquer arquivo ou diretório que tenha o contenha o nome .svn ou SRPMS. Isso me faz baixar apenas os diretórios i386 e x86_64. Fácil não? Aí é só usar a imaginação. Os exemplos aqui são muito comuns na hora de criar espelhos de repositórios e arquivos entre sistemas.

Mirror reverso (upload de arquivos)

No caso de mirror de um mirror reverso, ao invés de pegar os arquivos de um sistema remoto, eu coloco os arquivos no sistema remoto. A sintaxe é praticamente a mesma:
servidor1$ lftp -c "lcd /var/lib/backup && open ftp://usuario:senha@servidor2.example.com/backup/ && mirror -R --verbose"

O que mudou aqui: o comando lcd vai para o diretório local, onde os arquivos se encontram. Depois eu abro uma conexão FTP com servidor2.example.com, utilizando um usuário e senha. Em seguida eu faço um mirror reverso (opção -R), que ao invés de fazer download dos arquivos, vai fazer upload. Simples dessa forma.


RSYNC


O rsync foi feito especialmente para você sincronizar os arquivos de dois lugares e por isso ele é otimizado para isso. Geralmente é utilizado para copiar diretórios e seus conteúdos da forma mais exata possível (preservando permissões, modos, timestamps). Além disso, antes de começar a copiar, ele analisa o destino (ou origem, dependendo do caso) e vê o que realmente tem que ser copiado. Se um arquivo já existe no destino, para que copiar de novo?

O rsync pode funcionar via protocolo próprio, ou via ssh. Se existe um servidor rsync, pode-se usar ele. Para criar um, vai um pouco fora do escopo deste artigo, mas não é tão complicado também. Na maioria das vezes, você vai querer usar o rsync via ssh, que é o caso mais comum.

Sincronizando um diretório no servidor remoto
servidor1$ rsync -e "ssh" -avr /var/lib/backup/ maluco@servidor2.example.com:/var/lib/backup/

No comando acima, utilizei o ssh (-e “ssh”) para fazer o transporte. As opções -avr copiam recursivamente (-r), mostrando tudo o que for sendo copiado (-v) e da forma mais exata possível, preservando (-a). Até aí tudo bem…

… Mas preste bastante atenção! O rsync é muito sensível com a barra no final da origem e destino. Então coloque isso na cabeça:


  • Quando não se usa a barra no final, o rsync copia o diretório e todo seu conteúdo;
  • Quando usar a barra no final, o rsync copia apenas o conteúdo do diretório.

Confuso? Eu também fiquei. No exemplo anterior, eu copiei o conteúdo do diretório backup (localizado em /var/lib) para o /var/lib/backup do servidor2. Isso significa que o diretório /var/lib/backup deve existir no servidor2, senão é capaz de dar erro. Ficou assim:
servidor2$ ls /var/lib/backup
1   11  13  15  17  19  20  22  24  26  28  3   31  33  35  37  39  40  42  44  46  48  5   6  8
10  12  14  16  18  2   21  23  25  27  29  30  32  34  36  38  4   41  43  45  47  49  50  7  9

E se eu tirar uma barra?
servidor1$ rsync -e "ssh" -avr /var/lib/backup maluco@servidor2.example.com:/var/lib/backup/

Nesse caso, olha só como ia ficar:
servidor2$ ls /var/lib/backup
backup
servidor2$ ls /var/lib/backup/backup
1   11  13  15  17  19  20  22  24  26  28  3   31  33  35  37  39  40  42  44  46  48  5   6  8
10  12  14  16  18  2   21  23  25  27  29  30  32  34  36  38  4   41  43  45  47  49  50  7  9

Como tirei a barra, ele também copiou o diretório backup, ao invés de apenas seu conteúdo. Então lembre-se sempre… Com barra: só conteúdo; Sem barra: diretório e conteúdo.

Assim como lftp, o rsync também aceita excluir arquivos por nome:
servidor1$ rsync -e "ssh" --exclude='.svn' -avr /var/www/html/aplicacao maluco@servidor2.example.com:/var/www/html

No comando acima, sincronizamos o diretório /var/www/html/aplicacao, mas excluindo qualquer operação com arquivos que tem no nome “.svn“. Uma prática muito comum por aí.

Por padrão, o rsync não remove arquivos e diretórios do destino. Isso significa que a sincronização é apenas em uma mão. Se no servidor1 novos arquivos surgirem, ou arquivos forem modificados, o rsync vai sincronizar. Mas se um arquivo ou diretório for removido, ele não será removido no servidor2. Para resolver isso, usa-se a opção –delete:
servidor1$ rsync -e "ssh" --exclude='.svn' --delete -avr /var/www/html/aplicacao maluco@servidor2.example.com:/var/www/html

Dessa forma você evita de ficar acumulando “lixo” no servidor2.

Há no entanto um problema com este método. O problema é que os dados, enquanto armazenados não estão em criptografados. Se alguém entra e rouba o server, vão ter acesso aos dados. Depois, se alguém rouba o server de backup, não há procedimentos de backup offsite, para guardar o backup fora da empresa. Também dessa forma não há checagem de integridade de dados. Quando se usa um cp para copiar os dados, eles podem chegar do outro lado com defeito e não será feita nenhuma checagem disso (md5checksum) caso a mídia apresente algum defeito, um badblock, etc. O melhor mesmo é usar um sistema de backup, como o Nimbus Opensource Backup, GPL e prevê todas as boas práticas em backup. Está disponível em http://www.trynimbus.com grátis (GPL).

Configurando interfaces de rede manualmente no Centos

Autor:eu próprio.

Tendo como base a interface eth0 (a primeira) devemos aceder ao seguinte da seguinte forma ao à configuração da interface:

vi /etc/sysconfig/network-scripts/ifcfg-eth0

Utilizo o vi para a edição.

Observe a sintaxe abaixo:

DEVICE=eth0
BOOTPROTO=static
DHCPCLASS=
HWADDR=00:31:25:56:A6:B2
IPADDR=192.168.1.181
NETMASK=255.255.255.0
ONBOOT=yes

Fazendo isto (com  sintaxe semelhante) estamos a colocar o ip da interface estaticamente como 192.168.1.181 e dizendo que isto será feito no momento do boot do sistema.

Em seguida entre aqui:

vi /etc/sysconfig/network

NETWORKING=yes
HOSTNAME=CentOS
GATEWAY=192.168.1.230

Aqui definimos a rede com o hostname CentOS e o gateway 192.168.1.230

Após isto reinicie o serviço de rede:

/etc/init.d/network restart

Depois podemos até alterar os dns para acesso a web:

vi /etc/resolv.conf

Neste ficheiro colocamos assim:

nameserver 200.165.132.148
nameserver 200.165.132.155

Este é o modo simples de definir os dns que queremos.

Para concluir ficou assim

FILE:icfg-eth0
DEVICE="eth0"
NM_CONTROLLED="yes"
ONBOOT="yes"
HWADDR=00:0C:29:FC:CC:DB
TYPE=Ethernet
#BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
#novo
BOOTPROTO=static
IPADDR=192.168.1.181
NETMASK=255.255.255.0

FILE:network
NETWORKING=yes
HOSTNAME=CentOS6
#novo
GATEWAY=192.168.1.230

FILE:resolv.conf
nameserver 192.168.1.5
nameserver 192.168.1.230

segunda-feira, 24 de outubro de 2011

Configuração Manual do CentOS– Correr repositório do DVD. Instalando rede manual

Comecei por fazer uma instalação “minimal”  do CentOS 6.0.

Na configuração da rede não me apercebi e a rede ficou  desativada.

Ao correr o ifconfig só me aparecia a interface de loopback.

Pesquisando na net descobri o comando lspci para verificar as característica da placa.

Ao correr o comando lspci dava mensagem de comando inválido ou inexistente.

Descobri que tinha de instalar o pacote pciutils.

Tentei o yum e nada. O primeiro repositório era um site …como não tenho rede o yum dava erro e nada. Há que preparar o yum para correr do dvd.

Mãos à obra…

Primeiramente, precisamos desabilitar todos os repositórios do Yum. Para isso, basta editar todos os arquivos .repo que estiverem no diretório /etc/yum.repos.d/, trocando ou criando todas as ocorrências de enabled=1 por enabled=0.

Podemos fazer isso com um único comando:

# for Arquivo in /etc/yum.repos.d/*.repo

   do

   sed -i 's/\(enabled=\)1/\10/' $Arquivo

   done

Em seguida, verificamos se já existe ou criamos um arquivo media.repo no diretório /etc/yum.repos.d/ com o seguinte conteúdo:

[media]

name=Fedora 7 i386 DVD

baseurl=file:///media/CENTOSDVD/

enabled=1

gpgcheck=0

Basta montar agora o DVD.

# mount /dev/dvd /media/CENTOSDVD

Já podemos correr o YUM. Começamos por limpar a atualizar.

# yum clear

# yum check-update

Está ok podemos agora instalar o pciutils

# yum search pciutils

# yum install pciutils.x386_64

Agora já podemos correr o comando

# lspci |grep net

e ver os dados da nossa placa.

Concluí entretanto que afinal a placa estava instalada. No entanto desligada.

Bastava para isso ter corrido o  comando

# ip link

 image

 

 

 

 

Verificamos que não existe eth0 e que o eht1 está desligado (DOWN)

No ficheiro de configuração da placa eth0  em /etc/sysconfig/network-scripts/ifcfg-eth0 temos

ONBOOT=no

A placa ficava sempre desligada no arranque. Podemos ligá-la desde já com o comando /etc/sysconfig/networking-scripts/ifup-eth e obtemos a seguinte mensagem de erro:

image

 

 

 

isto deve-se ao facto de a placa estar com designada por eth1 e  não por eth0.

Não sei porque isto acontece mas talvez se deva ao que acontece depois de copiarmos ou movermos uma máquina virtual no VM Ware.

Quando iniciamos no VM Ware uma máquina virtul copiada, a primeira pergunta que o VM Ware faz é se copiamos ou movemos a máquina. Consoante a resposta ele mantem o Mac Address da placa de rede ou gera um novo Mac Adreess.

Se respondermos que copiámos, ele gera um novo mac para a placa e aqui que o problema é criado. No ficheiro /etc/sysconfig/network-scripts/ifcfg-eth0  temos a linha com o Mac da placa “HWADDR=00:30:48:56:A6:NE” que depois não coincide com o Mac gerado pelo VM Ware. Julgo que é que provoca a alteração do alias da placa de eth0 para eth1 (mas não tenho a certeza). O Linux sabe quem são as eth’s pelos seus endereços de hardware.

Mude a variável HWADDR no seu arquivo ifcfg-eth0 para compatibiliza-lo com o endereço da VM e pronto..

Além de termos que mudar novamente o name de eth1 para eth0 no arranque, temos também que alterar o mac adreess na variável HWADDR no arquivo ifcfg-eth0 e compatibiliza-lo com o endereço da VM. 

Para testar que funciona podemos para esta sessão alterar o name da placa  eth1 com o seguinte comando:

# ip link set dev eth1 name eth0

# ls –l /sys/class/net

# /etc/init.d/network restart

Devemos no entanto alterar o Mac Address. Para isso devemos consultar o mac da VM. Ver imagens seguintes:

imageimage

O nosso problema continua por resolver. Sempre que reiniciamos o eth1 mantem-se.

Pesquisando na Net descobri onde são guardadas os nomes das interfaces de rede: eth0, eth1 etc. Este arquivo no CentOS é o /etc/udev/rules.d/70-persistent-net.rules.

Para editá-lo utilizei o editor vi:

# vi /etc/udev/rules.d/70-persistent-net.rules

image

 

 

 

 

 

 

 

 

 

 

 

 

Verificamos então que temos dois interfaces com o name “eth0” e com mac address diferentes. Verificamos tb que um dos registos “eth0” tem o mesmo mac address que o “eth1”. Daí os problemas.

Removi as duas primeiras entradas relativas ao eth0 com mac diferente e a relativa ao eth1. Reiniciei a máquina e a rede está up…..

Conclusão:

Quando se diz ao VMWARE que se trata de uma cópia, para que não haja conflitos com a outra máquina virtual ele gera um novo mac address para a placa de rede. Ao gerar um novo mac, o anterior que tinha sido assumido pelo SO deixa de existir.

Como o SO não encontra esse endereço físico, gera um novo interface (eth1) com o novo mac. 

Usando o DVD do Fedora como repositório do Yum

Quando instalamos o Fedora

Usuários Fedora sabem que o Yum busca as informações sobre os pacotes, por padrão, na Internet, de forma que não é possível utilizá-lo sem estar conectado à rede mundial.
Descreverei aqui como utilizar o DVD de instalação do Fedora 7 como repositório do Yum, permitindo usar esse sistema de gerenciamento de pacotes quando a Internet não estiver disponível.
Primeiramente, precisamos desabilitar todos os repositórios do Yum. Para isso, basta editar todos os arquivos .repo que estiverem no diretório /etc/yum.repos.d/, trocando todas as ocorrências de enabled=1 por enabled=0. Podemos fazer isso com um único comando:
# for Arquivo in /etc/yum.repos.d/*.repo

   do
   sed -i 's/\(enabled=\)1/\10/' $Arquivo
   done

Em seguida, criamos um arquivo media.repo no diretório /etc/yum.repos.d/ com o seguinte conteúdo:

[media]

name=Fedora 7 i386 DVD
baseurl=file:///media/Fedora%207%20i386%20DVD/
enabled=1
gpgcheck=0
Nota: na linha 3, %20 é o código ASCII para espaço em branco. Se você colocar Fedora 7 i386 DVD o Yum causará erro. Você também não pode esquecer de colocar a barra (/) no final da URL.

Pronto. Agora, basta adicionar o DVD no drive e tanto o yum quando o Pirut funcionarão perfeitamente, usando os softwares disponíveis no DVD, sem necessidade de conexão à internet ou a uma rede local.

Dispositivos no Linux

Fonte: http://www.devin.com.br/dispositivos/

Autor: Hugo Cisneiros (Eitch)

Os dispositivos são uma coisa que temos que conhecer no Linux, senão agente se perde aos poucos nas configurações mais básicas. Por isso fiz esse tutorial tentando explicar algo sobre eles…

O que são dispositivos?

Um dispositivo é todo o componente de hardware, e do sistema operacional. Um dispositivo é “algo especial” que é compartilhado com o Kernel, ou seja, um exemplo de dispositivo são as impressoras, CD-ROMs, modems, portas, mouse, HDs, etc. No Linux, os dispositivos físicos são tratados como arquivos. Estes arquivos são um tipo especial no sistema de arquivos e se encontram no diretório /dev. Se você der um ls neste diretório, verá que existe um pouquínho de arquivos (Bota pouquinho nisso :)). Cada arquivo neste diretório corresponderá a um dispositivo de acordo com o seu tipo.

Se você usava DOS/Windows antes, você acessava o drive C:, lembra? No Linux não existe isso! Vai ser um dispositivo no lugar… Você vai usar isso o tempo todo, porque você vai mexer com mouse, com impressora, IDE’s, SCSI’s, etc. Então aqui vai alguns arquivos do /dev e seus respectivos dispositivos:

/dev/hdXX

Aqui é correspondete as Interfaces IDEs, ou seja, tudo que tiver conectado nos cabos IDEs :) Exemplos, podemos citar HD’s e CD-ROM’s. O xx significa qual IDE, onde o primeiro x corresponde a qual IDE, e o segundo x (opcional) corresponde a partição. Veja a tabela à seguir:

Dispositivo Descrição
/dev/hda IDE Primária Master
/dev/hda1 Partição 1 da IDE Primária Master
/dev/hda2 Partição 2 da IDE Primária Master
/dev/hdb IDE Primária Slave
/dev/hdb1 Partição 1 da IDE Primária Slave
/dev/hdb2 Partição 2 da IDE Primária Slave
/dev/hdc IDE Secundária Master
/dev/hdc1 Partição 1 da IDE Secundária Master
/dev/hdc2 Partição 2 da IDE Secundária Master
/dev/hdd IDE Secundária Slave
/dev/hdd1 Partição 1 da IDE Secundária Slave
/dev/hdd2 Partição 2 da IDE Secundária Slave

Perceba aqui que cada hdx vai até os números 2, mas não é apenas até o 2, pode ir mais longe. Dependendo de quantas partições tiver o seu HD, pode ser 3, ou 4, ou 9 por exemplo.

/dev/fdX

Aqui é o dispositivo equivalente ao drive de disquete, onde o x corresponde a qual driver. Caso você tenha apenas um drive, esse drive vai ser o /dev/fd0. Se tiver 2 drives, o primeiro será /dev/fd0 e o segundo /dev/fd1, e por aí vai.

/dev/ttyX

Quando você se loga no seu Linux, você acaba de se logar nesse terminal. Ou seja, um terminal serve para voc6e se logar e usar uma shell (interpretador de comandos). O /dev/ttyX corresponde a cada terminal, onde X vai ser substituído pelo número do terminal (são dezenas se quiser). Pode ser /dev/tty1 (Terminal 1), /dev/tty3 (Terminal 3), /dev/tty8 (Terminal 8) e por aí vai… até você enjoar :)

Você também pode se deparar com /dev/ttypX. Neste caso é para terminais acessados por telnet/ssh.

/dev/ttySX

Portas seriais! Na versão 2.2.x do kerne, estas portas seriais correspondem ao modem, ao mouse, e outras coisas ligadas nas ‘COMs’. Veja a tabela:

Dispositivo Descrição
/dev/ttyS0 COM1 (Porta serial 1)
/dev/ttyS1 COM2 (Porta serial 2)
/dev/ttyS2 COM3 (Porta serial 3)
/dev/ttyS3 COM4 (Porta serial 4)

Agora se você usa um kernel velho de versão anterior a 2.2.x, ao invés de ser /dev/ttySX, vai ser /dev/cuaX. Ou seja, você terá os equivalentes como /dev/cua0, /dev/cua1, /dev/cua2 e /dev/cua3. E estes dispositivos /dev/cuaX são usados para determinar os modems.

/dev/lpX

Corresponde a porta da impressora ou porta de um serviço paralelo. X é o número correspondente a porta… 0 = LPT1 por exemplo.

/dev/plipX

Esse dispositivo corresponde a uma conexão de cabo paralelo. O X será o número correspondente a porta, como no exemplo anterior.

/dev/console

Este é um dispositivo especial, simbolizando os consoles (terminais não-gráficos).

/dev/null

Este é um dispositivo nulo, ou seja, tudo que você mandar ou se referir a ele, será nulamente mandado para o inferno :)

Outros

Os dispositivos são muitos e listar todos eles aqui não seria tão legal assim. Você pode explorar o diretório /dev procurando saber sobre eles. Se você por acaso apagou um dispositivo e quer saber como criá-lo, utilize o script /dev/MAKEDEV. Basicamente você usa este script assim:

# /dev/MAKEDEV ttyS3

Isto irá criar o dispositivo ttyS3. Para mais informações sobre a criação de dispositivos, utilize a manpage do MAKEDEV ou do mknod. Na verdade o /dev/MAKEDEV é apenas um script para intermediar o usuário e o comando mknod… O mknod é o que faz o trabalho mais árduo :)


Montando os dispositivos


Primeiro eu espero que você tenha lido sobre o que é um dispositivo. Agora vamos saber como se usar um dispositivo, ou seja, um HD, um disquete, um CD-ROM, etc. O comando que usaremos aqui é o mount, que pelo próprio nome, podemos ver que ele serve para ‘montar’ dispositivos em um certo lugar.


Vamos falar primeiro sobre como montar o disco flexível. Para fazê-lo é o seguinte. O Linux trata todos os seus dispositivos como arquivos device, estes arquivos estão localizados no diretório “/dev”. Para o caso do disco flexível, o Linux trata como /dev/fdx, onde x é o número do dispostivo: o primeiro será fd0, o segundo será fd1, e assim por diante. Aqui no caso, estamos com um driver de disquete, que é o /dev/fd0. Para montar o disco flexível então, colocamos o disquete, e executamos o seguinte comando:

# mount /dev/fd0 /diretorio_onde_o_disco_vai_ser_montado

O diretório_onde_o_disco_vai_ser_montado tem que existir, e tem que estar totalmente vazio. Este diretório, que você pode nomear como quiser funciona como se você estivesse no disquete. Agora se você quer montar outro disquete, você terá que desmontar o disquete montado primeiro, para depois poder montar outro. Para o desmonte, usa-se o comando “umount”:

# umount /dev/fd0 (ou)
# umount /diretorio_onde_o_disco_esta_montado

Você pode também fazer o seguinte, criar um shell script, que se chama, por exemplo de ‘diskon’ (Para ativar) e ‘diskoff’ (Para desativar). Então para melhor utilização, coloque este arquivo em um diretório PATH, ou então coloque o PATH no diretório onde você quiser colocar os scripts.


Agora vamos montar uma partição. É o mesmo esquema de montar o disco flexível, só que o arquivo do dispositivo é diferente. Para partições em um HD IDE, os nomes dos dispositivos são /dev/hdxx, onde o primeiro x é a letra correspondente ao HD (na ordem a, b, c, d, e por aí vai), e o segundo x é correspondente ao número da partição. Para partições em um HD SCSI, os nomes dos dispositivos são /dev/sdxx, onde o primeiro x é a letra correspondente ao HD (na ordem a, b, c, d, e por aí vai), e o segundo x é correspondente ao número da partição. Se eu quero montar a partição /dev/hda2 (HD número 1, partição número 2), eu faço:

# mount /dev/hda2 /diretorio

E para desmontar, usa-se o comando umount:

# umount /dev/hda2 (ou)
# umount /diretorio

Existe também no comando mount, o parâmetro -t, que vai indicar que tipo de sistema de arquivos a partição usa (FAT32, FAT16, minix, ext2, UMSDOS, etc). Se você não colocar esta opção, o comando força uma compatibilidade para a montagem. O recomendado é colocar esta opção, pois às vezes o mount não consegue detectar qual o sistema de arquivos, e gera um erro. Um exemplo do uso da opção -t é:

# mount -t vfat /dev/hda2 /diretorio

Este comando montará uma partição FAT32 em /diretorio. Como eu disse anteriormente, utilizar-se de shell scripts facilita seu trabalho. Agora vamos montar um CD-ROM. O mesmo esquema, só que você deve saber qual o dispositivo referente ao seu CD-ROM, que tem como nome /dev/hdx, onde x é a letra correspondente à posição do CD-ROM na IDE. Para montar um exemplo, façamos:

# mount /dev/cdrom /mnt/cdrom

Para desmontar, a mesma coisa de sempre:

# umount /dev/cdrom (ou)
# umount /mnt/cdrom

Nota: Se você der uma olhada no arquivo /dev/cdrom, você verá que ele não é um dispositivo, e sim um link simbólico para o dispositivo correspondente ao CD-ROM (/dev/hdx). Isso quer dizer que você pode substituir o /dev/cdrom pelo /dev/hdx tranqüilamente, assim como pode também modificar o link simbólico para apontar para outro dispositivo.


Existe outro método de montagem muito mais prático do que os citados acima… É uma pré-configuração de montagem no arquivo /etc/fstab. Este arquivo contém as informações de montagem para os dispositivos e seus diretórios. Por exemplo, quando a sua distribuição inicia, ela procura no /etc/fstab para saber onde está a raiz do seu sistema, e vai montar no /. Também contém informações de montagem para os diretórios especiais como o /proc, e até mesmo para o uso da memória SWAP. Vejamos aqui o meu arquivo /etc/fstab como exemplo para estudarmos ele:

$ cat /etc/fstab
/dev/hda2 swap swap defaults 0 0
/dev/hda5 / reiserfs defaults 0 0
/dev/hda1 /boot ext2 defaults 1 1
/dev/fd0 /mnt/floppy auto user,noauto 0 0
/dev/cdrom /mnt/cdrom iso9660 user,noauto,ro 0 0
none /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0

Viu este exemplo? Por exemplo, peguemos a segunda linha. Esta segunda linha é a minha raiz, que está na partição /dev/hda5, será montada automaticamente (‘defaults’) no diretório “/” durante a inicialização. E esta partição tem o sistema de arquivos ReiserFS. Na primeira temos a montagem da memória SWAP… E vejamos a linha que começa com /dev/cdrom. Aqui facilita as coisas porque os parâmetros ‘user,noauto,ro’ significam que qualquer usuário pode montar o CD-ROM (user), não é montado automaticamente na inicialização (noauto) e é montado como somente leitura. Qual a diferença? O comando mount só pode ser usado pelo root, mas com essa opção no /etc/fstab, um usuário comum pode montar o cd-rom apenas com o comando “mount /mnt/cdrom”, ou “mount /dev/cdrom”. A sintaxe deste arquivo não é muito difícil, e vendo este exemplo aqui, você pode muito bem criar suas próprias configurações para dar mais praticidade no seu uso com os dispositivos no Linux! Mexa à vontade, mas nunca nas linhas que já vêm, pois se não o Linux pode não achar sua partição e poderá não conseguir iniciar o sistema, e você terá de bootar com um bootdisk para consertar isto… Então mexa, mas pense duas vezes antes de mexer :)

Como aceder ao DVD no Linux pela consola (CentOS)

Verificar na diretoria /dev. O diretório dev é o local onde se localizam os arquivos especiais ou os arquivos de dispositivos.

Existem dispositivos que talvez precisem ser criados manualmente no diretório dev para isso existe um comando chamado MAKEDEV, com este comando é possivel criar os arquivos do dispositivo necessário.

O diretório /dev contém arquivos associados a dispositivos físicos. Essa associação visa permitir que os drivers apontem para os dispositivos corretos (essa é uma explicação simplista).
A montagem vale apenas para dispositivos que contenham um sistema de arquivos e consiste em associar um diretório qualquer a um volume formatado (partição, unidade lógica, sistema de arquivos em rede - CIFS ou NFS, p.ex.). Assim, pode-se acessar arquivos daquele volume como se fossem parte do sistema de arquivos raiz (/).
Quanto ao /mnt e ao /media, não existe nada de particular nesses diretórios, a não ser a padronização determinada pelo FHS. A recomendação é que qualquer dispositivo removível seja montado em um subdiretório de /media (/media/floppy para disquetes e /media/cdrom para CDs, p.ex.) e que o diretório /mnt seja usado apenas para montagem temporária (p.ex., para copiar dados para uma partição recém-formatada). Nem todas as distros respeitam essa recomendação.

Assim decobri que no CentOS 6.0 a pasta /dev/dvd é um link para /dev/sr0 . Mas isso não interessa podemos fazer a montagem com /dev/dvd.

Criei uma diretoria em /mnt para o meu DVD:

mkdir /mnt/dvd

De seguida montei o dvd:

mount /dev/dvd /mnt/dvd

Podemos testar fazendo:

ls /mnt/dvd

É tudo…

sexta-feira, 21 de outubro de 2011

Erro MSI rollback is currently disabled

clip_image002

Este erro ocorre porque a funcionalidade de recuperação do Microsoft Windows Installer está desactivada. O programa de configuração do .NET Framework requer consolidação acções personalizadas para uma instalação correcta. Anulação de alterações e consolidação de acções personalizadas não são executados quando anulação for desactivada.

Anulação de alterações está desactivada na política DisableRollback no registo. O valor de política DisableRollback pode ter sido definido pelo administrador. A Microsoft recomenda que os administradores não desactivar anulação a menos que este seja necessário.

Existem dois locais no registo onde o valor de política DisableRollback pode ser definido. Para resolver este problema, é necessário saber onde a política DisableRollback foi definido e remova ou desactive a definição.

Para saber se esta propriedade já existe no registo, execute C:\Regedit.exe e verificar as seguintes localizações:

 

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer\DisableRollback

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer\DisableRollback

 

Se a chave DisableRollback existe e tiver um valor de "1", elimine a chave ou defina o valor da chave como "0". (Pode também definir DisableRollback através da linha de comandos de instruções.) A Microsoft recomenda que os administradores e programadores não definir esta propriedade se utilizam instruções de linha de comandos para executar o programa de configuração ou programa de configuração não funcionará.

Criar um ficheiro .reg (por ex. rollback.reg) com o seguinte conteúdo de forma a colocarmos a chave Rollback com o valor 0 em vez de 1:

 

Windows Registry Editor Version 5.00

 

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]

"DisableRollback"=dword:00000000

 

[HKEY_CURRENT_USERE\SOFTWARE\Policies\Microsoft\Windows\Installer]

"DisableRollback"=dword:00000000

  

quarta-feira, 28 de setembro de 2011

Atualizando IOS e CIOS: Novo Pimp My Wii 2.24

por em 27 de julho, 2011


[Tutorial: Atualizando suas IOS e CIOS com o Pimp My Wii 2.24]

       Olá camaradas da Games Fever!!! Não, vocês não estão vendo coisas… I’m Back. Depois de um bom tempo afastado estou de volta pra trazer mais alguns tutoriais interessantes do mundo homebrew do Wii e algumas atualizações importantíssimas para os meus tutoriais antigos que podem ser encontrados aqui no site.

       Neste primeiro tutorial após meu retorno, discutiremos sobre uma atualização em uma ferramenta importantíssima: O Pimp My Wii. Como muitos devem saber, o Pimp My Wii é uma ferramenta poderosa, capaz de Atualizar IOS e CIOS do Wii sem precisar fazer um System Update e além disso ele pode corrigir erros de instalações anteriores mal sucedidas além de uma infinidade de funções secundárias como Instalação de arquivos .WAD e etc, Porém, neste tutorial, abordaremos apenas a função básica de atualização de IOS e CIOS. Quem desejar se aprofundar nas funções do Pimp My Wii, a internet está aí, use-a.

 Nível do Tutorial: Fácil         

Pré – Requisitos:

  • Homebrew Channel 1.0.8 Previamente Instalado
  • SD Card (Qualquer Tamanho)
  • Nintendo Wii
  • Pack do Tutorial “Atualizando suas IOS e CIOS com o Pimp My Wii 2.24″ [Clique Aqui]
  • Internet Configurada no Wii (Se não tiver nternet no Wii, nem adianta chorar porque não vai dar certo)

[TUTORIAL]:

[Parte I: Preparando o SD Card para o trabalho sujo]

        Bem camaradas, essa parte é bem simples mas eu vou explicar para aqueles que não estão acostumados ainda com as traquinagens do mundo Homebrew do Wii:

 

  • Baixe o pack do tutorial. Você irá obter um arquivo compactado do WinRar.
  • Extraia o conteúdo do pack para a área de trabalho do seu PC. Você irá obter uma pasta [Tutorial... bla bla bla].
  • Insira o SD card no seu computador, faça backup dos arquivos contidos nele e em seguida formate-o em FAT32.
  • Agora abra a pasta [Tutorial... bla bla bla] e copie o conteúdo dela [Pasta "apps"] para a raíz do SD Card. Para quem não sabe, a raíz do SD Card ou de qualquer dispositivo de armazenamento é aquela primeira tela que aparece quando você abre o dispositivo, que mostra as pastas contidas nele e etc, ou seja, é a unidade primária do dispositivo, onde estão localizadas todas as pastas e subpastas.
  • Insira o SD Card no Wii

[Parte II: Executando o Pimp My Wii 2.24]

       Chegamos agora na parte importante deste tutorial. Tomem cuidado pois isso requer um pouco de atenção. não vão sair por aí apertando botões aleatórios.

  • Com o SD Card inserido no Wii, abra o Homebrew Channel e selecione o ícone do Pimp My Wii. Em seguida, aperte o botão “LOAD”
  • O Pimp My Wii será carregado e mostrará a tela inicial contendo diversas opções. Selecione a opção “TEST AND FIX PROBLEMS”
  • O Programa vai procurar e carregar a IOS250 ou a IOS249 (Seja lá qual ele achar melhor)
  • Em seguida ele vai perguntar se pode inicializar a conexão com a internet. Aperte “A” para permitir. Em seguida vai aparecer o endereço IP do Wii e o programa vai perguntar se deve prosseguir. Aperte “A” denovo.
  • A tela a seguir pergunta se desejamos jogar jogos modificados (Ex: Custom Rock Band) e se queremos que o Pimp My Wii aplique o Trucha bug nas IOS que ele vai atualizar. Aperte “B” para dizer que Sim.
  • Agora o Pimp My Wii vai Mostrar tudo que tiver de errado no seu Wii. Vá apertando “A” quando ele pedir.
  • Ao final da lista de diagnóstico, aperte “A” para o programa exibir a lista de coisas que devem ser Instaladas.
  • Na Lista de Instalação, apenas vá apertando “A” até chegar no final. É muito importante que você não mexa em mais nada na lista de instalação, apenas vá apertando “A”
  • Agora basta esperar ele terminar de atualizar tudo e ser feliz.

[FIM DO TUTORIAL]

       É isso aí camaradas… Tutorial extremamente simples. Se vocês seguirem à risca o que está escrito, não tem como errar. Esse tutorial será um Pré-Requisito para meus futuros tutoriais, portanto, é bom que todos executem-no

Atualizando a CIOSX: Nova CIOSX Rev21 D2XV6 Mod

por em 4 de agosto, 2011

[Tutorial: Atualizando a CIOSX: Nova CIOSX Rev21 D2XV6 Mod]

Olha eu aqui novamente galera da games fever. O tema do tutorial de hoje será um MOD feito na versão original da CIOSX Rev21 Lançada pelo Waninkoko. Como aconteceu com as Hermes CIOS, apareceu um carinha aleatório do nada, encontrou vários bugs e coisas que poderiam melhoras na CIOSX do Waninkoko e resolveu corrigir esses “erros” e relançar as CIOSX, dando origem às CIOSX D2X. Já faz um tempo que a primeira versão das CIOSX D2X foi lançada e semana passada foi lançada a 6° Versão dessas CIOS. Dentre muitas outras melhorias que essas novas CIOS trazem, a principal é que,  elas bloqueiam a função de IOS Reload do Wii… Aí vocês me perguntam: “Mas capitão, o que diabos é IOS RELOAD?” Simples jovens padawans, IOS Reload é como o próprio nome diz, Recarregar uma IOS no meio do jogo. Isso antigamente terminava em tela preta ou retorno ao Wii Menu toda vez que um jogo tentava recarregar uma IOS. Os jogos mais famosos que costumavam usar a Função de IOS Relaod eram “RED STEEL 2″, “Metroid Prime Trilogy”, “Wii Sports Resort”… e outros jogos similares. Pois é… Com essa nova CIOS todos esses problemas se resolvem, vocês nunca mais terão que usar “Alt.dol” e eu estou hoje aqui apara ensinar a vocês como instalá-las. Quem quizer o Changelog completo dessas novas CIOS, procure no Google.

Nível do Tutorial: Fácil

Pré – Requisitos:

  • SD Card de qualquer tamanho
  • Pack do Tutorial [Clique Aqui]
  • Homebrew Channel 1.0.8 previamente instalado
  • Ter executado meus 2 últimos tutoriais [Recomendado]

[TUTORIAL]

[Parte I: Preparando o SD Card para o trabalho]

       Bem, essa parte é bem simples e todos já deveriam saber fazer isso sozinhos, mas eu vou explicar denovo pra fixar isso na mente de vocês.

  • Baixe o pack e extraia o conteúdo dele para a área de trabalho do seu Computador. Você irá obter uma pasta com o nome do tutorial.
  • Insira o SD Card no seu computador, abra a pasta raíz, faça backup do que estiver dentro dele e em seguida formate-o em FAT32.
  • Agora abra a pasta do tutorial e pegue a pasta “apps” e a pasta “wad” contidas nela e copie-a para a raíz do seu SD Card.
  • Agora retire o SD Card do computador e coloque-o no Wii.

[Parte II: Instalando as CIOSX D2X com o Wad Manager 1.7]

        Bem, chegamos à parte importante do tutorial. É aqui onde você deve redobrar sua atenção para que nada saia errado. Sigam à risca o que estiver escrito e seu wii chegará vivo ao final.

  • Com o SD Card devidamente inserido no seu Wii, abra o Homebrew Channel e selecione o ícone do WAD Manager 1.7 e em seguida pressione o botão “LOAD”.
  • Aperte A na tela “Disclaimer”
  • Na tela “SELECT IOS VERSION TO USE”, selecione a IOS249 e em seguida aperte “A”
  • Na tela “Select NAND emulator device”, selecione “Disabled” e em seguida aperte “A”
  • Na tela “Select source device”, selecione “Wii SD Slot” e em seguida aperte “A”
  • Agora apareceu uma tela pra você selecionar a pasta onde estão os arquivos .wad, selecione a pasta WAD.
  • Selecione o arquivo “cIOS249[56]-v21d2x6.wad”  e em seguida a opção “Install WAD”
  • Aperte “A” Quando terminar
  • Agora selecione o arquivo “cIOS250[57]-v21d2x6.wad” e faça a mesma coisa
  • Aperte “A” Quando terminar
  • Aperte Home para voltar ao Menu do Homebrew Channel
  • No Menu do Homebrew Channel, aperte Home e em seguida “Return to System Menu” para voltar para o Menu do Wii.

Pronto, agora seus problemas com a função de recarregamento de IOS provavelmente vão acabar… Tutorialzinho bem simples mesmo… é isso aí galera, até a próxima. No proximo tutorial vou ensinar vocês a Instalar e Configurar o USB Loader GX 2.2, até lá o/.

Instalando o novo USB Loader GX 2.2

por em 10 de agosto, 2011


[Tutorial - Instalando o novo USB Loader GX 2.2]

Olá senhoras e senhores da Games Fever. Como prometido, no tutorial de hoje ensinarei vocês a instalar a mais nova versão do USB Loader, o USB Loader GX 2.2. Essa nova versão promete acabar com muitos problemas que são dor de cabeça para muitos usuários desse programa e traz ainda diversas novas funções: Total suporte a unidades FAT32 e NTFS, Função “Back To” (Quando você sai do jogo, ao invés dele voltar pro wii menu, volta pra tela do usb loader gx)”, Função “Block IOS Reload”, Suporte às Rodries CIOS, Suporte às CIOSX D2X (Recomendado), Suporte à Winnertag,  Suporte a Dispositivos com mais de 2TB, Suporte a dois drives simultâneos… etc e etc… Quem quiser ver o Changelog completo, digite “USB LOADER GX” no Google e entre no site oficial do programa. O Tutorial vai ser bem simples… consiste em simplesmente instalar um arquivo .wad ou então apertar o botão “Update” em alguma versão anterior do USB Loader GX. Acho que esse tutorial nem é tão necessário, mas como tem muita gente enchendo o saco dizendo que depois que executou o Pimp My Wii 2.24 ou Instalou as CIOSX D2X os loaders pararam de funcionar, taí o tutorial.

Nível do Tutorial: Fácil

Pré – Requisitos:

  • SD Card de tamanho qualquer
  • Homebrew channel 1.0.8 previamente instalado
  • CIOSX D2X V6 (249/250) + Rodries CIOS V5.1 (202/222/223/224/225)
  • Pack do Tutorial >>>[CLIQUE AQUI]<<<
  • Internet Configurada no Wii (APENAS PARA QUE FOR USAR A FERRAMENTA DE UPDATE)

[TUTORIAL]

[Parte I: Preparando o SD Card para o trabalho

  • Baixe o pack e extraia o conteúdo dele para a área de trabalho do seu Computador. Você irá obter uma pasta com o nome do tutorial.
  • Insira o SD Card no seu computador, abra a pasta raíz, faça backup do que estiver dentro dele e em seguida formate-o em FAT32.
  • Agora abra a pasta do tutorial e pegue a pasta “apps” e a pasta “wad” contidas nela e copie-as para a raíz do seu SD Card. Ignore a pasta "Config" por enquanto.
  • Agora retire o SD Card do computador e coloque-o no Wii.

[Parte II: Instalando o USB Loader GX 2.2 com o Wad Manager 1.7]

Bem, chegamos à parte importante do tutorial. É aqui onde você deve redobrar sua atenção para que nada saia errado. Sigam à risca o que estiver escrito e seu wii chegará vivo ao final.

[OPÇÃO 1]

       Antes de começar essa parte, trate de remover qualquer versão anterior do USB Loader GX que esteja instalada no seu Wii. Para fazer isso, basta você apagar o canal do USB Loader GX usando o Menu “DATA MANAGEMENT” do Wii. Se você usa o USB Loader GX apartir do Homebrew Channel, apague a pasta do USB Loader GX de dentro da pasta “apps” do seu SD Card antes de instalar essa nova versão.

  • Com o SD Card devidamente inserido no seu Wii, abra o Homebrew Channel e selecione o ícone do WAD Manager 1.7 e em seguida pressione o botão “LOAD”.
  • Aperte A na tela “Disclaimer”
  • Na tela “SELECT IOS VERSION TO USE”, selecione a IOS249 e em seguida aperte “A”
  • Na tela “Select NAND emulator device”, selecione “Disabled” e em seguida aperte “A”
  • Na tela “Select source device”, selecione “Wii SD Slot” e em seguida aperte “A”
  • Agora apareceu uma tela pra você selecionar a pasta onde estão os arquivos .wad, selecione a pasta WAD.
  • Selecione o arquivo “USB Loader GX 2.2 ULNR.wad”  e em seguida a opção “Install WAD”
  • Aperte “A” Quando terminar
  • Aperte Home para voltar ao Menu do Homebrew Channel
  • No Menu do Homebrew Channel, aperte Home e em seguida “Return to System Menu” para voltar para o Menu do Wii.

Agora você verá que o canal do USB Loader está em algum lugar da tela principal do Wii menu. Vale salientar que este NÃO é um Canal atalho, ou seja, você não precisa ter os arquivos do USB Loader GX dentro do seu SD Card para que ele funcione. Para este aplicativo, o SD Card só se faz necessário para armazenar os arquivos de configuração e as imagens das capas dos jogos.

[OPÇÃO 2]

       Se você já tem alguma versão anterior do USB Loader GX e tem Internet configurada no seu Wii, basta que você abra o menu de configurações do seu USB Loader GX e procure pelo botão “UPDATE”. Aperte o botão e ele fará tudo sozinho.

[Parte III: Configurando o USB Loader GX 2.2]

      Bem… eu previ que muita gente iria se embananar nessa parte, por isso eu simplesmente fiz um arquivo de configurações “Custom” e coloquei no pack do tutorial. Lembram-se da pasta “Config” que eu disse pra vocês ignorarem no começo do tutorial? Pois é… Basta que, após instalar o USB Loader GX 2.2, vocês coloquem aquela pasta “config” na raíz do SD Card que vocês usam normalmente no Wii, fazendo isso, Quando vocês abrirem o USB Loader GX, ele já estará configurado. Se quiserem mudar alguma coisa, podem mudar, mas tenham certeza do que estão fazendo.

 

Pronto, agora vocês têm a ultima versão do USB Loader GX. Espero que essa ladainha de “Ah… Meu loader parou de funcionar” acabe. Até a próxima o/