Modem 3G EDGE USB comprado na DealExtreme

Pessoal, vou pastar aqui um comentário (review) que estou enviando para http://dx.com sobre este produto:

http://dx.com/edge-u2-edge-usb-2-0-wireless-modem-adapter-edge-gprs-gsm-54921

Inicialmente a foto do modem USB:

Agora a minha avaliação:

Price Rating: 5 stars
Ease-of-use Rating: 4 stars
Build Quality Rating: 5 stars
Usefulness Rating: 5 stars

Title: Worked fine on Debian Squeeze (Linux)

Prós: Size and design. Worked on Linux, in Brazil, using TIM as telephone operator.

Cons: not yet.

Other Thoughts:
Worked fine on Debian Squeeze. You must follow the steps:

1. # apt-get install usb-modeswitch wvdial
2. Edit /etc/usb_modeswitch.conf and change from DisableSwitching=0 to
DisableSwitching=1.
3. Insert modem in USB port.
4. Mount and unmount the modem (internal CD-ROM emulator) to force a
switch from CD-ROM to modem.
5. # wvdialconf
6. Edit /etc/wvdial.conf
7. # wvdial
8. Be happy!

Bottomline:
Details:

--- CD-ROM emulator ---

> usb 3-1: New USB device found, idVendor=0471, idProduct=1210
> usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[...]
> scsi 6:0:0:0: CD-ROM            Philips  Dev. 0 LUN 0     1.0  PQ: 0 ANSI: 0
[...]

--- Modem ---

> usb 3-1: New USB device found, idVendor=1dbc, idProduct=0005
> usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 3-1: Product: EDGE Modem
> usb 3-1: Manufacturer: Wisue Technology
> usb 3-1: SerialNumber: 000000-00-000000
> cdc_acm 3-1:1.0: ttyACM0: USB ACM device
> usbcore: registered new interface driver cdc_acm
> cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

Tags:3G, DealExtreame, Debian, DX.com, Internet, modem, Rede, Squeeze, Wheezy

udev: renaming an ethernet interface without reboot

In English (para português, olhe abaixo)

To rename a network interface in Linux, switching from eth0 to eth1 and from eth1 to eth0, you should follow some steps.

1. Edit the /etc/udev/rules.d/70-persistent-net.rules file.

See bellow an example of the file:

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# USB device 0x:0x (dm9601)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:4c:53:44:58", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# USB device 0x:0x (rt73usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1d:0f:df:59:c6", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:08:54:6a:3a:cd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

2. Change eth0 and eth1 names at end of lines.

See bellow the final situation (showing the relevant parts only):

[...]
# USB device 0x:0x (dm9601)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:4c:53:44:58", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

[...]
# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:08:54:6a:3a:cd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

3. Look at lines and search the kernel modules used by each network interface. We have dm9601 for eth1 and 8139too for eth0.

4. Remove and reload the kernel modules. You can use these commands:

# modprobe -r dm9601 8139too
# modprobe -a dm9601 8139too

5. When you load a kernel module, udev reads the associated config file and loads the rules.

See the results:

root@canopus:~# ifconfig
eth0      Link encap:Ethernet  Endereço de HW 00:08:54:6a:3a:cd  
          inet end.: 192.168.1.180  Bcast:192.168.1.255  Masc:255.255.255.0
          endereço inet6: fe80::208:54ff:fe6a:3acd/64 Escopo:Link
          UP BROADCASTRUNNING MULTICAST  MTU:1500  Métrica:1
          RX packets:994 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1151 errors:0 dropped:0 overruns:0 carrier:0
          colisões:0 txqueuelen:1000
          RX bytes:663937 (648.3 KiB)  TX bytes:290276 (283.4 KiB)
          IRQ:22 

eth1      Link encap:Ethernet  Endereço de HW 00:e0:4c:53:44:58  
          endereço inet6: fe80::2e0:4cff:fe53:4458/64 Escopo:Link
          UP BROADCASTMULTICAST  MTU:1500  Métrica:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          colisões:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Loopback Local  
          inet end.: 127.0.0.1  Masc:255.0.0.0
          endereço inet6: ::1/128 Escopo:Máquina
          UP LOOPBACKRUNNING  MTU:16436  Métrica:1
          RX packets:26345 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26345 errors:0 dropped:0 overruns:0 carrier:0
          colisões:0 txqueuelen:0
          RX bytes:16608459 (15.8 MiB)  TX bytes:16608459 (15.8 MiB)

Hope that helps.

In Portuguese

Para renomear uma interface de rede no Linux, alterando de eth0 para eth1 e de eth1 para eth0, você deve serguir alguns passos.

1. Edite o arquivo /etc/udev/rules.d/70-persistent-net.rules file.

Veja abaixo um exemplo do arquivo:

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# USB device 0x:0x (dm9601)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:4c:53:44:58", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# USB device 0x:0x (rt73usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1d:0f:df:59:c6", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:08:54:6a:3a:cd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

2. Altere os nomes eth0 e eth1 no fim das linhas.

Veja abaixo a situação final (apenas as partes relevantes):

[...]
# USB device 0x:0x (dm9601)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:4c:53:44:58", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

[...]
# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:08:54:6a:3a:cd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

3. Olhe as linhas e procure pelos módulos de kernel utilizados por cada interface de rede. No caso, temos dm9601 para eth1 e 8139too para eth0.

4. Remova e recarregue os módulos de kernel. Você poderá utilizar estes comandos:

# modprobe -r dm9601 8139too
# modprobe -a dm9601 8139too

5. Quando você carrega um módulo de kernel, o udev lê o arquivo de configuração relacionado e carrega as regras.

Veja os resultados:

root@canopus:~# ifconfig
eth0      Link encap:Ethernet  Endereço de HW 00:08:54:6a:3a:cd  
          inet end.: 192.168.1.180  Bcast:192.168.1.255  Masc:255.255.255.0
          endereço inet6: fe80::208:54ff:fe6a:3acd/64 Escopo:Link
          UP BROADCASTRUNNING MULTICAST  MTU:1500  Métrica:1
          RX packets:994 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1151 errors:0 dropped:0 overruns:0 carrier:0
          colisões:0 txqueuelen:1000
          RX bytes:663937 (648.3 KiB)  TX bytes:290276 (283.4 KiB)
          IRQ:22 

eth1      Link encap:Ethernet  Endereço de HW 00:e0:4c:53:44:58  
          endereço inet6: fe80::2e0:4cff:fe53:4458/64 Escopo:Link
          UP BROADCASTMULTICAST  MTU:1500  Métrica:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          colisões:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Loopback Local  
          inet end.: 127.0.0.1  Masc:255.0.0.0
          endereço inet6: ::1/128 Escopo:Máquina
          UP LOOPBACKRUNNING  MTU:16436  Métrica:1
          RX packets:26345 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26345 errors:0 dropped:0 overruns:0 carrier:0
          colisões:0 txqueuelen:0
          RX bytes:16608459 (15.8 MiB)  TX bytes:16608459 (15.8 MiB)

Espero que isso ajude.

Tags:Debian, eth0, eth1, eth2, hardware, hotplug, interfaces, kernel, Linux, names, plug and play, Rede, reload, restart, Squeeze, udev, Wheezy

Conventional keyboard without numpad – do it yourself!

Hello all,

The objective of this post is show as make a keyboard without a numpad from a conventional and complete computer keyboard. The original post was written in Brazilian Portuguese and is at http://eriberto.pro.br/blog/?p=1050. Though the post is in pt_BR, has several images showing all process. So you can understand the pictures and make your keyboard too!

We will strip the numpad using a hacksaw. You will need a keyboard with the control and the leds out of the area will be cutted off. A great example are the Dell keyboards, as can be viewed in the image bellow (click to enlarge). However, we have thousand of similar keyboards in the world.

If you have comments, doubts or ideas, please, write here in English. Use the reply area bellow.

Thanks for your international visit!

Enjoy!

Tags:abnt, abnt2, computer, DIY, do it yourself, hardware, how to make, keyboard, keyboard without number pad, keyboard without numeric keypad, keyboard without numeric pad, keyboard without numpad, keypad, Linux, number pad, numeric, numpad, us, Windows

Teclado ABNT2 convencional mas sem numpad – Eu fiz o meu!

Observação importante, escrita em 15 de março de 2012: pessoal, está havendo uma certa dúvida sobre o porque desse teclado e não um compacto comercial. É porque são diferentes. Por favor, antes de tudo, leiam lá em baixo a minha resposta para o Marcos e entenderão. É uma das primeiras. Obrigado!

Adiantando o resultado final

Eis o meu tão sonhado teclado sem numpad:

A história

Há cerca de um ano, eu publiquei um post que, na verdade, pedia socorro. Por uma questão de conforto e pouca ocupação de espaço eu precisava de um teclado igual a um convencional mas sem a parte numérica. O referido post foi o Preciso de teclado similar ao convencional mas sem numpad. Esse post fez relativo sucesso. Não pelo número de comentários, mas pelo número de visitas que recebe até hoje.

Nunca encontrei o tão almejado teclado. Cheguei a escrever para uns 30 fabricantes, no mundo todo, pedindo que produzissem o teclado. Mas nada aconteceu. Na mesma época, tive a ideia de serrar um teclado mas tive um problema: ao desmontar um, descobri que a membrana interna não podia ser cortada, pois fazia parte de um conjunto. Uma opção seria dobrar por debaixo do teclado. Mas surgiu outro problema: o circuito de controle e de leds, que geralmente fica na parte direita, teria que ser dobrado para baixo do teclado e isso não daria certo. Desisti da cirurgia. E o tempo passou...

De repente, eu vi a luz...

Semana passada, quase um ano depois, andando pelo Supermercado Extra, não pude deixar de observar um teclado da marca Bright. Modelo 0014. Abaixo, uma foto dele:

Observe no topo da imagem que os leds e, consequentemente, o circuito de controle não ficam acima do numpad, como ocorre na maioria dos teclados. Eles ficam deslocados para a esquerda, um pouco acima da área que contém o Home, Delete, Page Up etc. Então, daria para serrar o numpad e dobrar a membrana com facilidade. Não pensei duas vezes. Comprei o teclado.

Algumas características do 0014:

• USB.
• ABNT2.
• Um pouco duro, mas funciona bem. Estou utilizando há cerca de uma semana.
• Convencional.
• Barato. Ótimo para experiências.
• Fácil de ser encontrado. Alguns locais: lojas do Extra (loja mesmo, não o site), Kalunga, microoffice, inecel, outros (procure nas imagens do Google).
• Site do fabricante: http://www.bright.com.br.

Agora, uma foto da etiqueta que pode ser encontrada no fundo do teclado:

Serrando, colando, construindo...

Ao chegar em casa, retirei todos os parafusos e desmontei o teclado. Agora, vou começar a narrar em fotos todo o procedimento. A ideia é cortar um pouco para dentro do numpad para não danificar a área de controle (que contém os leds), exatamente na linha vermelha mostrada abaixo:

Agora, veja o passo a passo. Se precisar, clique nas figuras para ampliar.

O teclado Dell

No dia seguinte, depois de fabricado o meu teclado, fui a um outro mercado (Atacadão) e, observando os computadores dos caixas, notei que existem teclados Dell com o mesmo formato. É bem provável que o Bright seja uma cópia. Veja:

Bem, esse não é ABNT2 e a Dell não vende teclados separados de computadores no Brasil. Mas no Mercado Livre está cheio de teclados Dell  (e ABNT2). Custam de R$ 13,00 a R$ 30,00. Já comprei o meu e estou esperando chegar para fazer a experiência. Ele deve ser mais suave. Fica a dica!

Ah, existem outros teclados com esse layout. Procurando por keyboard nas imagens do Google, encontrei um Genius. Na verdade, agora eu quero um com teclas iluminadas. Que tal me ajudar a encontrar?

Este post deve gerar muitas ideias em muitas pessoas. Então, não exitem em escrever os seus comentários logo abaixo.

Espero que aproveitem este post.

[]s

Tags:abnt, abnt2, Bright, como fazer, comprar, computador, Dell, faça você mesmo, fazer, hardware, keypad, Linux, number pad, numpad, PC, português, teclado, teclado numérico, teclado sem keypad, teclado sem number pad, teclado sem numpad, teclado sem teclado numérico, us, Windows

Promoção relâmpago! Pegue aqui o seu saquinho de IPs. Válido somente para este século.

Segundo fontes, uma delas aqui, o Planeta Terra chegou a 7 bilhões de habitantes no fim de 2011.

IPv4

Vamos falar de endereços IP. O endereço IPv4 é composto por 4 bytes ou 4 octetos ou 32 bits (é tudo a mesma coisa). Então, raciocinando em bytes, a grosso modo, cada octeto pode ir de 0 a 255, o que nos dá 256 possibilidades. São 4 octetos, o que nos dá 256^4, num total de 4.294.967.296 endereços.

IPv6

Agora vem o IPv6. Ele é composto por 16 bytes ou 8 grupos de 16 bits ou 128 bits. Raciocinando em bytes cada grupo pode ir de 0 a 65535, o que nos dá 65.536 possibilidades. São 8 grupos, o que nos dá 65.536^8, num total aproximado de 3,4 x 10^38 endereços (3,4 undecilões de endereços).

Por habitante da Terra

IPv4 = 256^4 / 7.000.000.000 =~ 0,6 IPs.

IPv6 = 65.536^8 / 7.000.000.000 =~ 4.9 x 10^28 IPs.

Mas será que usarei tudo isso?

Tudo não, penso. Mas muitos. Com certeza, em pouco tempo, talvez 10 anos, tudo terá IP. A geladeira da sua casa, por exemplo, será microprocessada, rodando um sistema operacional, atualizando os preços dos produtos existentes dentro dela pela Internet. E o seu relógio de pulso comprado por R$ 20,00 no camelô? Ele também vai atualizar data e hora, no meio da rua, pela Internet. É fato que você usará vários IPs em casa, no carro etc.

O futuro...

Por mais absurdo que possa parecer, uma hora os endereços IPv6 vão acabar. Então, o IPv6 vai acabar, assim como está ocorrendo com o idoso IPv4.

Pense...

Tags:endereço IP, exaustão de IP, Internet, IPS, IPs por habitante, IPv4, IPv6, Rede

Instalação do servidor news INN2

Por acaso, me lembrei hoje que eu havia escrito, em 2004, um documento sobre a instalação e a configuração do servidor news INN2 no Debian Sarge. Há poucos instantes, regatei esse documento e publiquei em http://eriberto.pro.br/artigos.

Para quem não sabe o que é um servidor news, segue o que escrevi no início do referido documento:

O INternet News versão 2 é um servidor NNTP1. Com ele, é possível disponibilizar o serviço de Newsgroup em uma rede.

O Newsgroup é um sistema similar a uma lista de discussão. Permite que pessoas cadastradas possam trocar mensagens relativas a um determinado assunto. Essa troca de mensagens, geralmente, busca a solução de problemas.

Uma característica do serviço news é a utilização de um cliente específico ou genérico para a leitura das mensagens. É algo similar ao IMAP só que em grupo. Como cliente, podemos utilizar o Mozilla Thunderbird (Icedove), por exemplo. Duas sugestões para a pesquisa de clientes:

$ apt-cache search nntp client
$ apt-cache search news client

Apesar do documento ter sido escrito para o Sarge, creio que tudo funcionará bem no Squeeze. Não testei mas posso tirar dúvidas aqui.

Bem, talvez isso seja útil para alguém. News é bem bacana e ainda existem alguns serviços desse tipo na Internet, como é o caso do http://news.gmane.org (que também pode ser acessado via browser).

Divirta-se!

Tags:Debian, fórum, icedove, inn, inn2, leafnode, Linux, lista discussão, Mozilla Thunderbird, news, notícias, redes, Sarge, sn, Squeeze

WordPress: instalação segura, desempenho e gerenciamento de memória

Muitos, como eu, utilizam o WordPress para fazerem os seus sites e blogs. E, com certeza, o WordPress é o sistema mais utilizado para blogs e um dos mais difundidos para sites na atualidade. O grande problema é que a maioria dos usuários descompacta o WordPress dentro dos seus GNU/Linux ou dos seus espaços em provedores, realiza a configuração básica via web, instala um monte de plugins e... pronto. Dessa forma, poderão ocorrer muitos problemas de desempenho e segurança.

O grande objetivo deste post é mostrar como agregar um pouco mais de segurança à instalação e como escolher os plugins de uma forma mais cuidadosa.

A instalação do WordPress

Depois da clássica instalação do tipo "descompacte o .zip, chame a URL do site, configure o seu WordPress", algumas medidas deverão ser adotadas. A primeira delas é via shell (ssh, por exemplo) ou via FTP. Consiste em apagar arquivos que deem pistas sobre o seu WordPress, como versão etc. Ao realizar ataques, por exemplo, é sempre bom saber o software que está rodando do outro lado, incluindo a sua versão. Um dos grandes vilões aqui é o arquivo readme.html do WordPress. Ele cita a versão do WordPress instalado. Será possível encontrar um monte desses arquivos se você procurar no Google por algo como isto:

wordpress inurl:readme.html

Um exemplo de resultado, retirado da web (clique para ampliar):

Assim sendo, apague o quanto antes os arquivos license.txt e readme.html, existentes na raiz do diretório que contém o WordPress. Note que esse procedimento poderá ser necessário também depois de uma atualização do WP. Para tanto, utilize o comando:

# rm license.txt readme.html

Mas há outra saída, caso você deseje preservar tais arquivos. Alterar as suas permissões para 000 com o comando chmod.

IMPORTANTE: depois de escrever esta parte do post, encontrei um plugin que realiza, automaticamente, as ações descritas acima. Ele será comentado mais adiante. Trata-se do SIG.

O próximo passo será alterar o nível de permissão de acesso ao arquivo wp-config.php, que contém a senha de acesso ao banco de dados. Este passo só deverá ser realizado depois da configuração inicial do WordPress, ou seja, já deverá ter ocorrido a conexão entre o WP e o banco de dados. Para tanto, utilize o comando a seguir:

# chmod 400 wp-config.php

Dependendo de como o servidor de páginas esteja configurado, poderemos alterar mais um nível de permissionamento. Um exemplo disso é o Apache2 no Debian, que roda sob o usuário www-data. Então, neste caso, para maior segurança, devermos deixar arquivos com 640 (exceto o wp-config.php) e os diretórios com 750. Ainda, todos os arquivos e diretórios, inclusive o que contém o WordPress, deverão pertencer ao usuário www-data. Para isso, considerando que o site WordPress esteja em /var/www/teste/, deveremos executar:

# find /var/www/teste -type f -perm 644 -exec chmod 640 {} \;
# find /var/www/teste -type d -perm 755 -exec chmod 750 {} \;
# chown -R www-data.www-data /var/www/teste

O último item deste tópico, mas não menos importante,é sobre a conta de administrador. Essa conta, por default, é criada com o nome de usuário admin. Então, os robôs da Internet que buscam descobrir senhas utilizam sempre admin como usuário para tentarem entrar no blog. Por este e muitos outros motivos, é fundamental que você crie um usuário com outro nome para ser administrador e exclua o admin.

Esta é a configuração básica de segurança do WordPress. Os próximos tópicos tentarão descobrir "brechas" ou problemas.

De olho no log

A partir de agora deveremos ter o cuidado de verificar se aparecem erros no log /var/log/apache2/error.log. É MUITO IMPORTANTE testar o WordPress com o tema padrão e sem plugins. Teste com uma página ou com um post e um comentário, dependendo do seu caso. Depois, configure o WordPress, utilizando o painel de controle, de acordo com o seu gosto. Verifique o log novamente. Somente depois disso, instale temas e plugins. Mas não esqueça de testar um a um.

Atualize sempre!

Ao ser informado sobre atualizações no core do WordPress, em plugins ou temas, não hesite! Sistemas atualizados são chave primordial para manter a segurança do seu site. Atualizar ajuda a evitar invasões, defacements etc. Há plugins que avisam por e-mail sempre que uma atualização é lançada. Particularmente, gosto do WP Updates Notifier.

Mas há uma regra básica para atualizações sem impacto: evite alterar o código-fonte do WordPress. Muitos sites ensinam dicas e truques que irão requerer alteração de código. Isso não é bom, pois qualquer atualização irá matar as suas alterações. Prefira utilizar plugins que executem tarefas específicas em vez de alterar código para obter benefícios.

Cuidados com temas e plugins

A maioria dos usuários de WordPress adora instalar temas e plugins indiscriminadamente. Realmente é prazeroso ter um monte de recursos. No entanto, temas não testados e plugins diversos podem trazer alguns problemas, como:

• Bugs. Um tema ou um plugin pode não funcionar corretamente. Com isso não teremos os resultados desejados, ou teremos resultados indesejados, ou poderemos ter ocorrências de difícil observação mas que nos levarão de simples telas brancas a desastres, como a perda de dados.
• Problemas de segurança. Isso poderá ocorrer principalmente em plugins que interagem com usuários. Assim, antes de instalar um plugin desse tipo, procure saber sobre o mesmo na Internet.
• Queda do serviço durante atualizações do WP. Plugins e temas poderão não estar preparados para novas versões do WordPress por ocasião de atualizações.
• Esgotamento de memória. Quanto mais plugins você tiver, mais consumo de memória você terá. E muitos provedores não toleram isso. Atenção também para plugins que consomem memória descontroladamente.

Como conselho final neste tópico, tenha o MÍNIMO de plugins instalados sempre. Quanto menos, melhor! Mas, para isso, você terá que vencer a sua vontade de ter milhões de plugins instalados. Então, preocupe-se se estiver utilizando mais de 10 plugins. Além disso, verifique o consumo de memória, erros etc. E cuidado com os sites que dizem: 30 maravilhosos plugins para isso ou aquilo. A maioria deles é maravilhosa mesmo. No entanto, os autores desses sites, raramente, testam os plugins que usam ou aconselham e... Espalham o caos.

Fechando o acesso aos diretórios de plugins

Alguns plugins permitem o acesso aos seu diretórios (que podem conter dados valiosos armazenados). Um deles, pelo menos até a versão atual, é o Lightbox Gallery, muito conhecido e utilizado. Para saber sobre o que estou falando, procure no Google por:

inurl:plugins lightbox-gallery

Assim, é uma boa ideia bloquear o acesso direto ao diretório de cada plugin instalado. Há várias formas de fazer isto. Vou citar duas:

• Se você tiver acesso às configurações do servidor de páginas e se este for um Apache2, edite o arquivo de configuração do site (possivelmente em /etc/apache2/sites-available/) e adicione:

<Directory /var/www/site/wp-content/plugins>
        Options -Indexes
</Directory>

Observe que você deverá alterar, no código acima, a primeira linha, de forma que o path referente ao diretório de plugins fique correto.

• Se você não tiver acesso às configurações do servidor de páginas, poderá criar um index.php vazio dentro dos diretórios de plugins que não contenham qualquer index (index.php, index.html etc). Realmente esta não é a solução mais profissional. No entanto, ela cai bem neste caso, pois será possível resolver o problema em provedores de acesso e também criar esse tipo de arquivo via script, se o servidor ou provedor permitir o agendamento de tarefas.

IMPORTANTE: o mesmo plugin que citei anteriormente, aquele que encontrei depois de escrever as primeiras partes deste post, também cuida dos diretórios sem index. Ele será comentado mais adiante. Trata-se do SIG.

Plugins essenciais para segurança

Alguns plugins são muito interessantes para a segurança. Na verdade, eles são essenciais e vale a pena tê-los. É importante ressaltar que todos foram testados de forma básica, inclusive no que tange a consumo de memória.

WordPress Firewall 2

Este plugin detecta ataques diversos, bloqueando-os. Utiliza eurísticas e pode avisar, via e-mail, sobre atividades irregulares ocorridas. Simples e rápido de configurar.

WP Sanitize

O WP Sanitize realiza algumas ações de segurança muito importantes. Dentre elas, remove a versão do WordPress das páginas apresentadas na Internet. Ele também possui um recurso muito útil, que é a limpeza diária automática do banco de dados, removendo os overhead (lixo deixado no banco).

WP Updates Notifier

Avisa, via e-mail, sobre a atualização de elementos no WordPress. São eles: o core, plugins e temas. Mas não abuse, pois essas verificações consomem memória e link, e provedores não gostam disso. Sugiro uma verificação por dia.

Silence is Golden Guard plugin (SIG)

O plugin é capaz de fazer verificações diárias no WordPress, atuando sobre problemas encontrados. Alguns já foram descritos neste post e foi gratificante encontrar um plugins que automatizasse as ações. Algumas delas: cria arquivos index.php em diretórios de plugins e outros, apaga arquivos readme.txt etc. NO ENTANTO, este plugin ao ser ativado, consome 5 MB de RAM constantemente (um valor absurdo para WordPress). Esse detalhe foi visto com o auxílio do plugin PHP memory indicator. Assim, creio que seja uma boa ideia deixá-lo desativado. De vez em quando, ative-o, clique em Scan Now (disponível na página de configuração do plugin) e desative-o. Recomendo que faça isso sempre que houver qualquer instalação ou upgrade de core, tema ou plugin. Então, o seu WordPress estará protegido e não haverá consumo de memória desnecessariamente.

WordPress File Monitor Plus

Este plugin realiza o famoso check de integridade do sistema, avisando por e-mail caso algum arquivo tenha sido criado, apagado ou alterado. É bem configurável e essencial para denunciar casos de invasão ou preparação para a invasão. Use isto!!!

BackUpWordPress

Backup sempre é necessário. Este plugin é simples e eficiente. No entanto, ocupa cerca de 1 MB de memória quando ativado. Assim, caso você não tenha outro meio de realizar backup, ative-o. No entanto, caso possa, prefira backup via provedor. Ou ainda, caso o seu provedor lhe dê acesso via shell, como é o meu caso, utilize scripts e tarefas agendadas. Ainda, você terá problemas em provedores de hospedagem compartilhada, caso o seu conteúdo WP seja muito grade. Isso porque durante o backup haverá alto consumo de memória e o processo será encerrado prematuramente. Com isso, dependendo do caso, você nunca terá backup.

Apesar de ocupar 1 MB de RAM, o plugin é o mais simples e eficiente que testei. Cheguei a usá-lo quando hospedava em outro provedor que não me concedia shell. Para se ter uma ideia, o plugin Backup Scheduler, quando ativado, só em stand by, já ocupa mais de 5 MB de RAM.

Agora, veja os logs...

Se você tiver acesso aos logs do servidor, olhá-los será o próximo passo. O que nos interessa é o log error.log do Apache. Normalmente fica em /var/log/apache2/error.log. Lá será possível encontrar algumas ocorrências irregulares, como esta:

[Thu Feb 16 14:27:23 2012] [error] [client 200.x.x.1] File does not exist: /var/www/wp2/wp-content/plugins/silence-is-golden-guard/images/tom.png, referer: http://www.rede.com.br/wp2/wp-admin/options-general.php?page=sig-guard.php

Neste caso, é nítido que está faltando o arquivo /var/www/wp2/wp-content/plugins/silence-is-golden-guard/images/tom.png. Geralmente os problemas apresentados serão relativos à falta de arquivos. Mas isso é importante? Sim! Muito! Porque haverá consumo de mais tempo e memória procurando algo que não existe e, logo depois, escrevendo em log. Os logs também ficarão recheados e ocupando espaço. Então, deveremos fazer os seguinte:

• Criar os arquivos faltosos, deixando vazio o seu conteúdo. Isso poderá ser feito com o comando touch. Exemplo:

# touch /var/www/wp2/wp-content/plugins/silence-is-golden-guard/images/tom.png

• Avisar ao autor sobre o problema para que ele possa corrigi-lo. Isso poderá ser feito na página específica do plugin, dentro do site http://wordpress.org/extend/plugins.

Tratando a memória

A partir de agora falaremos um pouco sobre memória.

O WordPress costuma ser uma dor de cabeça para os provedores de conteúdo, uma vez que a maioria dos administradores de blogs e sites costuma instalar milhões de plugins sem saber o que está fazendo. Então, os WordPress da vida vão virando monstros comedores de RAM. Na maioria das vezes, os provedores optam por utilizar ferramentas que matam os processos, principalmente os baseados em PHP, que estejam consumindo muita memória. O resultado disso, geralmente, será uma mensagem "500 Internal Server Error" na tela de quem acessa o site. Isso ocorre, especialmente, em provedores com hospedagem compartilhada, onde vários site são abrigados pela mesma máquina e usam o mesmo processador e a mesma memória.

O ajuste da memória

Regras de ouro, caso esteja utilizando um espaço comprado em um provedor:

• Nunca abuse de plugins.
• Otimize ao máximo o seu WordPress.
• Faça medição de uso de memória com plugin específico para isso.

Além disso, o WordPress vem configurado para utilizar somente 32 MB de RAM em caso de uso simples ou 64 MB para multisites, que é a situação referente a disponibilizar vários sites e blogs utilizando apenas um motor WordPress. No entanto um WordPress com um tema comum e alguns plugins, em standby, já consome uns 35 MB ou mais. O tema escolhido também interfere nisso. E por incrível que pareça, plugins instalados, mesmo desativados, também consomem memória. Então, será necessário ampliar esse limite de 32 MB ou você enfrentará constantes erros 500. Mas o limite de memória a ser utilizado pelo WordPress não poderá ser maior que o limite estabelecido pelo PHP para todas as aplicações gerenciadas por ele.

A primeira ação será instalar um plugin de visualização de memória. Lembre-se de desativá-lo depois do uso! Então, sugiro o "PHP memory indicator". Ele mostra dados no rodapé da página. Veja a figura a seguir (clique para ampliar):

O primeiro valor exibido é a quantidade de memória utilizada pelo WordPress (40.74 MB), incluindo o tema e plugins. O segundo valor é a quantidade máxima de memória com utilização permitida pelas configurações do PHP (90 MB). O limite de memória imposto pelo WordPress não é mostrado.

No caso anterior, sabendo que o valor limite default do WordPress para sites e blogs fora do sistema multisites é 32 MB, faltará memória. Com isso, teremos um festival de erros 500, pois os acessos de usuários irão gerar um uso de memória que será rejeitado pelo sistema. Para evitar isso, poderemos alterar as configurações do WordPress. Procure utilizar o valor máximo permitido pelo PHP, reduzido em 10%. Ou seja: 90 - 10% = 81 MB.

Para alterar a quantidade de memória utilizada pelo WordPress, aumentando de 32 para 81 MB, edite o arquivo wp-config.php (na raiz do WordPress) e insira no início, logo depois de <?php:

define('WP_MEMORY_LIMIT', '81M');

Caso você precise de um maior controle sobre o que está ocorrendo na memória e informações detalhadas sobre o sistema, utilize o plugin TPC! Memory Usage. Ele é um pouco difícil de encontrar. Então, clique aqui. Mas lembre-se: depois de utilizar, desative-o! A seguir um exemplo de tela de informações do plugin (clique para ampliar):

Mito: plugin para medir uso de memória lhe dirá tudo!

Muitos e muitos sites e blogs, na verdade todos os que eu vi, dizem que plugins como o TCP! Memory Usage mostram toda a memória que o WordPress está usando. Diversos sites ensinam: "olhe a quantidade de memória utilizada pelo WordPress no radapé, antes e depois da instalação do plugin. A diferença entre os dois será a quantidade de memória gasta pelo plugin". ERRADO!!!!!!

Qualquer processo, quando ativo, consome muito mais memória do que quando está em standby. Então, um plugin como o BackUpWordPress, por exemplo, irá consumir muito mais memória no momento em que estiver realizando o backup. Além disso, há diversas variáveis que interferem de forma diferente no sistema a cada instante. Então, se você instalar, por exemplo, o PHP memory indicator e executar vários refreshes no browser enquanto olha o rodapé, notará que o consumo de memória variará um pouco. Porque é assim que um sistema operacional funciona! Simples!

Vamos a um exemplo. No rodapé de um WordPress, podemos ver:

Obrigado por criar com o WordPress. | Load 40.72 of 90M

Agora, vamos instalar o plugin BackUpWordPress. Depois da instalação, o sistema mostra:

Obrigado por criar com o WordPress. | Load 41.56 of 90M

Vamos desinstalar e ver como fica. Resultado:

Obrigado por criar com o WordPress. | Load 40.69 of 90M

Observe que houve uma pequena variação, ou seja, o valor final não foi 40.72 e sim 40.69. Isso é o esperado em um sistema operacional. Com isso, a teoria mostrada na maioria dos sites está um pouco fora da realidade, apesar de ser inegável que você terá uma excelente ideia do consumo de memória COM O PLUGIN EM STANDBY. Não é exato. É aproximado. Mas muito próximo do real.

Agora vamos fazer uma prova de fogo. Passei a monitorar a memória com um watch. Depois de vários refreshes em cima do browser que mostra o WordPress, obtive:

# watch -n1 free -m

Every 1,0s: free -m

             total       used       free     shared    buffers     cached
Mem:          3516        792       2724          0         99        240
-/+ buffers/cache:        452       3064
Swap:            0          0          0

Em outras palavras, o sistema está gastando 452 MB de RAM para se manter neste momento. Agora iniciarei, manualmente, uma operação de backup via plugin. Veja o resultado, durante todo o período do backup:

-/+ buffers/cache:        483       3033

A operação foi repetida e o mesmo resultado foi obtido novamente. Isso quer dizer que, durante o backup, 31 MB de RAM são consumidos (483 MB - 452 MB). É lógico que não foi o plugin quem gastou sozinho esses 31 MB. Isso porque há chamadas de sistema envolvidas, que também consomem memória. Mas consideremos que o BackUpWordPress tenha utilizado, pelo menos, 30% desse total (número mágico que saiu da minha cabeça). Então, podemos arbitrar que o plugin consumiu cerca de 9 MB. Resumo: o plugin ocupa cerca de 850 KB em standby e, estimativamente, 9 MB ou mais em funcionamento. Assim sendo, fique de olho nos seus plugins e temas (também ocupam memória).

É importante ressaltar que, além de consumo de memória, é durante o seu funcionamento que plugins podem apresentar falhas de segurança. Uma atenção especial deve ser dada aos plugins que interagem com o usuário.

Conclusão

A correta instalação do WordPress é muito importante para o seu funcionamento. Segurança também é primordial. Assim, vários detalhes deverão ser observados. Provedores como o DreamHost serão o céu ou o inferno, dependendo de como você hospede o seu site. Se fizer errado ou de qualquer jeito, com certeza, você será presenteado com um festival de erros 500.

Uma dica é testar em um servidor local todo o seu ambiente, antes de fazer upload para o provedor. Observe mensagens de erro nos logs, consumo de memória com auxílio do comando free e plugin específico etc. Assim, você escolherá os melhores plugins e temas. E lembre-se do conselho final: não abuse dos plugins!!! Eles poderão esgotar a memória e, talvez, abrir brechas de segurança.

Tags:500, acabar com erro 500, CMS, consumo de memória, Content Management System, Debian, defacement, desempenho, hospedagem, hospedagem compartilhada, Internal Server Error, Internet, intrusão, invasão, Linux, memória, performance, plugins, provedor, provedor de hospedagem, Rede, security, Segurança, sites, web, web hosting, WordPress, WP

Cálculo de datas com o comando date no GNU/Linux

De vez em quando necessitamos fazer cálculos com datas para nós mesmos ou dentro de scripts. O comando date possui ótimos recursos para nos auxiliar nisso. Este post irá mostrar algumas das possibilidades de cálculo utilizando o date. Mas, antes de tudo, falarei um pouco sobre formatação.

Formatação de datas e hora

O comando date permite a formatação de datas e hora. Basta utilizar uma expressão de formatação iniciada com o caractere "soma". Exemplos:

$ date
Ter Fev 14 16:15:48 BRST 2012

$ date "+%d de %B de %Y"
14 de fevereiro de 2012

No caso acima, %d refere-se ao dia, %b ao mês e %Y ao ano. Para saber mais sobre os parâmetros possíveis, consulte o manual on-line do comando date ($ man date) e procure por FORMAT.

Observação: BRST significa Brazilian Summer Time. Fora da época de horário de verão teremos BRT (Brazilian Time).

Cálculos elementares

Agora veremos alguns exemplos de cálculos com datas. Será necessário utilizar a chave -d. Apenas ressalto que o resultado final pode utilizar formatação, como descrito antes.

Datas e horas passadas e futuras

Alguns exemplos:

$ date
Ter Fev 14 16:35:46 BRST 2012

$ date -d "+10 days"
Sex Fev 24 16:38:00 BRST 2012

$ date -d "-10 days"
Sáb Fev  4 16:38:17 BRST 2012

$ date -d "+10 min"
Ter Fev 14 16:49:09 BRST 2012

$ date -d "-10 min"
Ter Fev 14 16:29:27 BRST 2012

$ date -d "+10 days -2 hours +10 min -50 secs"
Sex Fev 24 14:49:51 BRST 2012

Agora com formatação:

$ date -d "+10 days -2 hours +10 min -50 secs" '+%d %b %y, %H:%Mh'
24 Fev 12, 14:50h

$ date -d "+2 years +1 month -1 week" '+%d %b %y, %H:%Mh'
07 Mar 14, 15:47h

Exemplo em script:

#!/bin/bash
DATA=$(LANG=C date -d "-1 day" '+%b %e')
cat /var/log/syslog | grep "$DATA" | grep login

Na verdade, você tem que ser intuitivo para lidar com o date. Olha que exemplo louco:

$ date -d "next fri"
Sex Fev 17 00:00:00 BRST 2012

Ele mostrou a data da próxima sexta-feira (fri de friday). Outra saída, caso você não seja intuitivo, é ler o código fonte do comando. O manual on-line não cita as possibilidades. Então, tais possibilidades são (algumas aceitam plural, como hours): ago, day, fortnight, hour, last, min, month, next, now, sec, this, today, tomorrow, week, year e yesterday.

Outro exemplo:

$ date -d "last fri"
Sex Fev 10 00:00:00 BRST 2012

Agora preste atenção: day, fortnight, hour, min, month, sec, week e year são conhecidos como unidades e PODEM ser combinados com ago, last, next, now, this, today, tomorrow e yesterday, que são os modificadores. Exemplo:

$ date -d "last-week +1 day"
Qua Fev  8 17:55:00 BRST 2012

Unix Epoch

Para quem não sabe, o Unix Epoch é uma data de referência do Unix, ou seja, 01 de janeiro de 1970, às 00:00h. Os Unix utilizam bastante essa data. Por exemplo: quando você inclui um usuário no sistema com o comando adduser, uma linha é gerada no arquivo /etc/shadow. O terceiro campo dessa linha é a quantidade de dias decorridos desde o Unix Epoch. Então, é possível saber quando o usuário foi cadastrado ou quando a sua conta foi alterada pela última vez. Veja:

eriberto:$6$8wFWksz9$cGv03Q0y9B3bKVvao168QueUhv7ViMkS3SdXGOYOyqDaaUmjIit3m/0F6/98jTaglalgfatWGpVL4mp/x7oag/:15134:0:99999:7:::

No caso, 15134 é o número de dias desde o Epoch.

É importante dizer que a unidade do Epoch pode variar de aplicação para aplicação. Alguns logs, por exemplo utilizam a quantidade de segundos e não o de dias. É o caso do log do Squid. Veja o exemplo de uma linha desse log:

1294013828.588      0 84.63.123.123 TCP_MEM_HIT/200 943 GET http://www.debianet.com.br NONE/- text/css

No caso, 1294013828 é a quantidade de segundos. O 588 representa fração de segundos.

Cálculos com Epoch

Para saber o Epoch em segundos da data atual, utilize o comando:

$ date +%s
1329246450

Note que %s, segundo o manual on-line do comando date, significa a quantidade segundos passados desde a 00h de 01/01/1970. Para fazer o cálculo inverso, utilize a opção -d com o caractere "@" antes do número. Exemplo:

$ date -d @1329246450
Ter Fev 14 17:07:30 BRST 2012

Para saber o Epoch de uma data qualquer, com a hora, basta especificá-las. O detalhe é que tem que ser em inglês. Exemplo:

$ date +"%s" -d "Feb 14 17:07:30 BRST 2012"
1329246450

Também é possível remover a hora:

$ date +"%s" -d "Feb 14 2012"
1329184800

Assim, fazer cálculos com datas e Epoch ficou fácil. Basta utilizar os conceitos anteriores. Darei alguns exemplos. Comecemos calculando qual data representa o Epoch 15134 em dias.

$ date -d "1970-01-01 +15134 days"
Qui Jun  9 00:00:00 BRT 2011

Agora, veremos o que representa o Epoch 1329246450 em segundos. Já vimos uma forma fácil de fazer isso. Mas uma outra forma seria:

$ date -d "1970-01-01 +1329246450 secs"
Ter Fev 14 20:07:30 BRST 2012

Note que houve uma diferença de 3 horas entre a resposta anterior e esta, considerando ainda o horário de verão (estamos vivendo ele hoje). Isso me parece ser um bug do comando (ou de libraries). Mas se pedirmos o resultado em UTC (hora de Greenwitch), com a opção -u, o resultado será igual. Veja:

$ date -d @1329246450 -u
Ter Fev 14 19:07:30 UTC 2012

$ date -d "1970-01-01 +1329246450 secs" -u
Ter Fev 14 19:07:30 UTC 2012

Como no horário de verão estamos a menos de 2 horas de Greenwitch, o resultado correto brasileiro deveria ser 17:07h. Então, o cálculo com o comando "date -d @1329246450" foi mais preciso. Mas, digamos que o outro comando quebra o galho.

Comando cal

Já que estamos falando de datas, o comando cal também pode ser útil. Ele nos fornece um calendário on-line sempre que precisamos. Exemplos:

$ cal
   Fevereiro 2012
Do Se Te Qu Qu Se Sá
          1  2  3  4
 5  6  7  8  9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29

Há outras opções interessantes:

$ cal -3 ---> fornece o calendário do mês anterior, do atual e do próximo.

$ cal 2012 ---> mostra o calendário de 2012.

$ cal 9 1971 ---> mostra o calendário de setembro de 1971.

$ cal -j ---> mostra o calendário juliano.

Este post é particularmente útil para administradores de sistemas.

[]s!

Tags:1970, Bash, date, Debian, Epoch, forense, Forense computacional, Linux, shell, shell script, timestamp, unix, Unix Epoch

Cansado de man e apt em português?

Ok, sei que muitos vão me condenar até a morte depois que eu escrever isto. Mas é um posicionamento pessoal.

Realmente, não gosto de manual on-line e apt traduzidos. Isso me traz uma série de inconvenientes. Veja um exemplo no Debian Squeeze:

$ man ls   -> me mostra um manual em português de 1998.
$ LANG=C man ls   -> me mostra um manual em inglês de 2010!

O que eu fiz aqui? Mudei a variável de ambiente LANG somente para o comando em questão ao colocá-la na frente do mesmo. O "C" quer dizer POSIX. Em POSIX, o idioma é inglês. Experimente os seguintes comandos:

$ LANG=C date
$ date

Entendeu? Muda o idioma, somente para o comando e somente naquela execução. Um outro exemplo:

$ apt-cache search database monitor   -> me traz 31 resultados
$ LANG=C apt-cache search database monitor   -> me traz 48 resultados

Assim sendo, a minha solução foi editar o ~/.bashrc e inserir no final:

alias man='LANG=C man'
alias apt-cache='LANG=C apt-cache'

Agora, cada vez que consulto algo no ambiente gráfico, em se tratando de man ou apt-cache, vem em inglês e atualizado.

Espero que seja útil para alguém. Eu já até paguei mico abrindo bug no Debian porque estava lendo um manual desatualizado.

[]s!

Tags:Debian, LANG=C, Linux, POSIX, shell, Squeeze, unix

OpenVPN com Windows 7

Recentemente, alguns clientes de rede que trabalham em outro ambiente e se conectam via OpenVPN fizeram upgrade de XP para 7. Depois desse upgrade, tivemos dois problemas:

• Algumas máquinas se conectavam mas não acessavam a rede interna.
• Outras se conectavam mas chegavam via Internet e não via VPN. Assim, eram bloqueados pelo sistema de firewall para o acesso a determinados serviços.

Comecei a realizar testes com um netbook com Windows 7 via 3G. O console do OpenVPN GUI mostrava bem claramente uma situação: na hora de criar rotas, eu obtinha o erro Route addition via IPAPI failed. Então, olhando o manual on-line do OpenVPN e procurando por Windows, encontrei:

Windows-Specific Options:
[...]
--route-method m
     Which method m to use for adding routes on Windows?

     adaptive (default) -- Try IP helper API first.  If that fails, fall back to the route.exe shell command.
     ipapi -- Use IP helper API.
     exe -- Call the route.exe shell command.

Outra boa opção que encontrei na Internet e depois procurei entender no manual foi a --route-delay. Esta opção também é benéfica nos MS Windows. As citadas opções devem ser inseridas no script do cliente. Assim, incluí as seguintes linhas nos clientes:

--route-method exe
--route-delay 5

Bem, com as linhas acima, a situação mudou. Passei a receber uma mensagem referente a não ter privilégios para criar rotas. Então, executei o OpenVPN GUI como administrador e deu certo. Um pouco estranho, pois os usuários teriam que ter a senha de algum administrador. Então, procurando na Internet sem parar, não encontrei uma solução direta via Windows. Parece que ninguém encontrou. Mas há aplicativos como suDown e sudowin que dizem resolver o problema. Não os testei porque realmente não estou precisando desse tipo de solução.

O último problema enfrentado foi o fato dos usuários conseguirem navegar fora do túnel. Na maioria das vezes isso não é problema, a não ser no nosso caso (aqui no meu trabalho). Dependendo do IP de origem (VPN ou Internet), o nosso usuário terá direito a alguns acessos. Então, ele deverá estar o tempo todo dentro do túnel. Já tínhamos uma configuração para isso, do lado do servidor. Trata-se da seguinte linha no arquivo do OpenVPN server (em /etc/openvpn/):

push "redirect-gateway"

Só que  não estava funcionando. Então, voltando ao manual on-line do OpenVPN para ver se tinha algo especial para o Windows 7, descobri que a opção mudou e foram acrescidos parâmetros. Ele explica cada parâmetro e recomenda def1, que realmente bate com o meu caso. Então, a nova linha:

push "redirect-gateway def1"

Com isso tudo se resolveu e os Windows 7 estão na VPN.

[]s!

Tags:Debian, firewall, Internet, Linux, OpenVPN, Rede, Squeeze, unix, VPN, Windows, Windows Vista, Winsows 7