Resolvendo o problema de falta de espaço em partições Linux

Para aqueles casos desesperadores em que se percebe tarde demais que a partição onde está montada o "/var" foi subdimensionada e os serviços do sistema começam a parar por falta de condições de gravar seus dados temporários e logs, existe solução.... ;)

Esta pode não ser a solução mais "ortodoxa", alguns podem até chamá-la de "lusitana" (com o perdão dos irmãos além-mar), mas o importante é que funciona!!

O único requisito indispensável é que se tenha espaço em disco que possa ser utilizado para uma nova partição, e que este espaço seja maior que aquele que o diretório em questão já consome (óbvio). Aqui, pode-se considerar válido: espaço no próprio disco que ainda não foi utilizado por nenhuma partição (não particionado), que já esteja em uso por uma partição dispensável (jogue fora aquele Windows que você mantinha guardado por nostalgia), adicionar um novo disco à máquina, etc...

Os passos a executar serão, respectivamente:

• Criar a nova partição
• Formatá-la com um sistema de arquivos compatível com o Sistema Operacional
• Copiar os dados da origem atual (diretório, partição) para a nova partição
• Alterar o arquivo /etc/fstab para montar o diretório na nova partição de agora em diante (novo ponto de montagem)
• Rezar 8 padres-nossos e 2 aves-marias
• Reiniciar a máquina, se for o caso de um diretório de uso so SO, como o "/var" e testar o resultado
• Estando tudo certo, remover o diretório/partição onde originalmente se encontravam os dados para aquele espaço ficar disponível para outros usos

Transformando isso em comandos:

• Particionamento:
  

• fdisk /dev/hda #Carrega o particionador para o disco IDE (hd) master primário (a)
  
• p #Lista as partições existentes no disco
  
• d #Deleta partição existente para liberar o espaço da mesma (opcional)
• 3 #Indica o número da partição a deletar
  
• n #Cria uma nova partição no disco
• p / e #Escolhe entre tipo de partição Primária ou Extendida
• #Confirma o bloco inicial da partição como sendo o próximo disponível no disco
• +2048M #Indica um tamanho de 2048Mb/2Gb para a partição
• w #Sai, gravando as configurações na tabela de particionamento
• Obs.: Dependendo da máquina, pode ser necessário um reboot para a alteração ser reconhecida
• Formatar a partição no sistema de arquivos desejado:
• mkfs -t ext3 /dev/hda3 #Aqui, o parâmetro que segue o -t é o sistema de arquivos
• Copiar os dados do diretório atual para a nova partição (isso demanda montá-la em algum ponto de montagem temporário):
• mkdir /mnt/temp
• mount -t ext3 /dev/hda3 /mnt/temp
• cp -a /var/* /mnt/temp
• umount /mnt/temp
• rmdir /mnt/temp
  
• Adicionar a entrada no /etc/fstab (vou usar o exemplo do /var) como a linha a seguir:
• /var /dev/hda3 defaults 0 2
• Já rezou?? Então lá vai: /sbin/reboot (ou shutdown -r now)

Configurar o APT para utilizar um servidor proxy (anônimo)

Me sinto um idiota toda vez que esqueço isso, mas como o problema é recorrente, vale anotar:

• Editar o arquivo /etc/apt/apt.conf e adicionar a ele a linha:

Acquire::http::Proxy "http://ip_do_servidor:porta_do_servidor/";

• Se necessário, criar um alias para o wget (nunca precisei):

alias "wget=wget -Y on"


Difícil, né??? >:/

Obs.: Se o servidor proxy exige autenticação, basta acrescentar usuario:senha@ antes do IP do servidor (http://usuario:senha@ip:porta/;)

Active Directory: usuário não consegue logar, ou loga e não acessa recursos

Essas são duas situações igualmente estranhas, que quebram a cabeça da gente, mas por incrível que pareça têm uma solução extremamente simples!!!

Certa vez um usuário me chamou reclamando que o computador dele naquele dia resolveu não deixá-lo logar de jeito nenhum.... Ele já havia confirmado que não era problema com sua senha nem usuário, já que havia conseguido fazer logon à partir de um outro computador. Fui até lá e constatei que era verdade, até porque também tentei logar com o meu usuário normal e com um usuário equivalente ao administrador do domínio e sempre a mesma resposta: nenhum controlador de domínio está disponível ou não pode ser encontrado.

Em outra situação (outro dia, outra rede), o usuário me informou que conseguia fazer logon na rede, mas não conseguia mapear nenhuma unidade de rede do servidor de arquivos, recebendo a mensagem de que o recurso não estava disponível. Percebi que, estranhamente, o usuário estava realmente logado no domínio correto, com permissões suficientes para o referido acesso, mas não conseguia acessar nenhum compartilhamento no servidor.

Entretanto, em ambas as situações, fazendo logon como usuário local do computador eu conseguia "pingar" o referido controlador de domínio tanto pelo IP quanto pelo nome (o que indica que o DNS não era o problema).

Depois de sofrer um pouco, percebi que o horário dos computadores estava muito diferente do meu... Na realidade, havia pelo menos 1 hora de diferença (1h a mais). Verifiquei então e percebi que o Fuso Horário da estação estava GMT -3, enquanto o servidor e as outras estações estavam com GMT -4. Foi só corrigir o fuso das estações com problemas e reiniciá-las e os problemas sumiram....

MS Active Directory não aplica política de configuração do IE

Ambiente

• Rede com serviço de diretório Active Directory com servidores Windows 2003 Server e clientes Windows XP (SP2) e Windows 2000 Professional
• Diversos ítens do ambiente de trabalho gerenciado por Objetos de Políticas de Grupo (GPOs)
• Perfis de usuário ambulantes e pasta pessoais (home folders) armazenados na rede
• Árvore do serviço de diretórios com diversos níveis hierárquicos dentro do domínio, definidos por aninhamento de Unidades Organizacinais (OUs)
• Gerenciamento das GPOs pela ferramenta GPMC (Group Policy Management Console)
  

Problema

Uma das configurações aplicadas por GPOs aos usuários é a configuração de servidor Proxy no IE (Configurações do Usuário/Configurações do Windows/Manutenção do Internet Explorer/Conexão /Configurações do proxy), que precisou sofrer uma pequena alteração de parâmetros (parâmetro "Excessões"). Acontece que apesar de "aparentemente" a política ter sendo aplicada a todos os usuários do domínio inicialmente, após a alteração ter sido realizada, a configuração dos computadores não a refletia.

Mesmo após forçar a replicação entre os (02) controladores do domínio, utilizar "gpupdate /force" nas estações de trabalho, reiniciá-las, nada fazia com que a política fosse aplicada de forma a refletir os novos valores do parâmetro alterado. Pior que isso: alterei, numa estação de usuário o parâmetro "Ativar configurações de proxy" para o status "Desabilitado" e executei o "gpupdate /target:user /force" para testar a correta aplicação da GPO e o parâmetro continuou como eu havia deixado, ou seja, a GPO não forçou a mudança do valor para Habilitado, como deveria!!!

Para confirmar se não havia nenhuma corrupção na estrutura do AD ou mesmo das GPOs, e se as mesmas estavam efetivamente sendo aplicadas na estação de trabalho, recorri à opção "Group Policy Results" da ferramenta GPMC e gerei um relatório da aplicação das políticas no computador e usuário atuais. Para minha surpresa, as GPOs esperadas estavam sendo aplicadas sem conflitos ao computador/usuário correto, o que só complicava a situação.


Solução

Após mais alguns testes e investigação, descobri (olhando o relatório Group Policy Results) que havia uma GPO vinculada à Unidade Organizacional na qual o objeto do usuário está cadastrado (OU filha/abaixo do domínio), onde a política "Configurações do Usuário/Configuração do Windows/Manutenção do Internet Explorer/Conexão/Configurações de Proxy" estava sendo aplicada com o valor "Not configured".

Resultado: a política vinculada ao Domínio (nível hierárquico mais alto) aplicava parâmetros de configuração do proxy, depois a política vinculada à Unidade Organizacional (nível hierárquico mais baixo, portanto mais próximo do objeto-alvo) aplicava o valor "Not configured" aos mesmos parâmetros, deixando-os sem configuração nenhuma. O mais estranho é que o valor "Not configured" em uma política de GPO representa "nenhuma alteração" nos valores do parâmetro em questão, respeitando o que já estiver configurado.... (vai entender!)

O importante é que, para resolver o problema, bastou clicar com o botão direito do mouse sobre a política "Configurações do Usuário/Configuração do Windows/Manutenção do Internet Explorer/Conexão" e selecionar a opção "Redefinir configurações do navegador". Após isso, foi só forçar a replicação entre os controladores de domínio para garantir a equalização dos arquivos, executar o "gpupdate /target:user" e voilá!!!

Mais um problema resolvido ;)

Como habilitar VPN (Pass Through) em modems ADSL D-Link DSL-500G

Aproveitando a carona do artigo anterior sobre o estabelecimento de uma VPN Lan-toLan sobre ADSL, vamos supor que do outro lado da internet temos o nosso segundo "endpoint" atrás de um modem ADSL D-Link DSL 500G (Generation II, Versão C1).

Nossa missão então será (novamente) configurá-lo para permitir o repasse "transparente" dos pacotes do túnel VPN a ser estabelecido, respeitadas e lembradas as premissas apresentadas no artigo citado, só pra lembrar:

• Redirecionar (via NAT) tráfego externo chegando para a porta UDP/500 (ISAKMP) para endereço do "endpoint" do túnel, na mesma porta (UDP/500), na rede interna;
• Redirecionar (sem NAT/sem alterar cabeçalhos) tráfego externo chegando para o protocolo 50 (ESP) para o endereço do "endpoint" to túnel, na rede interna.
  

Como fazer:

1. Através de um computador conectado à mesma rede "interna" onde esteja o modem ADSL (o padrão é que ele venha com o IP 192.168.1.1/255.255.255.0), acessar sua console de administração Web via browser (ex.: http://192.168.1.1). Ao receber o pop-up solicitando usuário e senha, preencher com "admin" em ambos os campos (caso tenha alterado a senha, informar a correta);
   
2. No menu Services, acessar a opção NAT e no drop-down NAT Global Info selecionar NAT Rule Entry e acionar o botão ADD;
3. No formulário a seguir, preencher os campos com (respectivamente):

• Rule ID = n+1 (n=nr.última regra existente)
  
• Rule Flavor = RDR
• IF Name = ALL
• Protocol = UDP
  
• Local Address From = 192.168.1.x
• Local Address To = 192.168.1.x
• Global Address From = 0.0.0.0
• Global Address To = 0.0.0.0
• Destination Port From = 500
• Destination Port To = 500
• Local Port = 0

Adicionar agora a regra para o túnel ESP (esta regra deve ser mantida "sempre" como a última da lista)

• Rule ID = n+10 (n=nr.última regra existente)
• Rule Flavor = RDR
• IF Name = ALL
• Protocol = ANY (*)
  
• Local Address From = 192.168.1.x
• Local Address To = 192.168.1.x
• Global Address From = 0.0.0.0
• Global Address To = 0.0.0.0
• Destination Port From = 0
• Destination Port To = 0
• Local Port = 0

Ao terminar, ir ao menu Admin, Commit & Reboot e confirmar "Save" com a opção Reboot selecionada no drop-down.

(*) No caso específico deste modem tentei, de todas as maneiras que consegui imaginar, fazer o redirecionamento "apenas" do protocolo desejado (50/ESP), mas apesar do túnel se estabelecer na primeira fase (IKE), não trafegava nenhum pacote na segunda fase (ESP). Então "por acidente" descobri que somente com esta configuração os pacotes da segunda fase passavam. Infelizmente, por causa disso, as informações neste guia funcionaram para mim, mas não podem ser consideradas precisas, portanto, aceito sugestões/contribuições.

Como habilitar VPN (Pass Through) em modems ADSL Alcatel Speed Touch Pro

Tendo a necessidade de estabelecer uma VPN Lan-to-Lan com IPSec*, onde um dos lados (ou até ambos) encontrem-se "atrás" de um modem ADSL Alcatel Speed Touch Pro, deve-se configurá-lo para permitir o repasse "transparente" dos pacotes do túnel VPN a ser estabelecido.

Para isso, deve-se levar em conta que o estabelecimento do túnel requer conexões ponta-a-ponta:

• Porta UDP 500 (ISAKMP), para o processo IKE (Internet Key Exchange), ou seja, a troca de chaves de autenticação mútua das pontas. Nesta etapa deve-se fazer o NAT do endereço público (externo) do modem para o endereço privado (interno) do dispositivo com o qual o túnel será estabelecido (endpoint);
• Protocolo nr. 50 (ESP - Encryption Security Protocol), protocolo através do qual é estabelecido o túnel criptografado e por onde trafegam os pacotes. Esta etapa não admite NAT, o que alteraria o cabeçalho (header) dos pacotes e consequentemente comprometeria o processo criptográfico. Portanto, deve-se simplesmente redirecionar todos os pacotes que chegarem à interface externa através deste protocolo para o endereço IP interno do "endpoint".

Como fazer:

1. Através de um computador conectado à mesma rede "interna" onde esteja o modem ADSL (o padrão é que ele venha com o IP 10.0.0.138/255.0.0.0), acessar sua CLI (Command Line Interface) via telnet (ex.: [host]$ telnet 10.0.0.138). Ao receber o prompt solicitando usuário, deixar em branco e teclar [ENTER], e na senha, informar a senha para logar. Uma senha padrão conhecida nos Speed Touch instalados pela Brasil Telecom é "keycode&senh@01";
2. No prompt "=>", entrar com os comandos "nat protocol=udp inside_addr=10.0.0.x inside_port=500 outside_addr=0.0.0.0 outside_port=500" seguido de "nat unbind application=ESP" ou "nat unbind application=ESP port=1" ou ainda "nat protocolo=50 inside_addr=10.0.0.x outside_addr=0.0.0.0";
3. Os comandos não devem retornar nenhuma mensagem e devolver o prompt "=>" após serem confirmados com [ENTER]. O correto deverá ser a combinação do primeiro comando com um dos outros três, sendo incorreto para a sua versão de Modem/Firmware aquele comando que retornar uma mensagem de erro ao ser confirmado;
4. Salvar a configuração alterada com o comando "config save" de então sair (não há um comando "logout" ou "exit", então saia com [CTRL]+[C] mesmo).

(*) Neste cenário, estou utilizando um túnel IPSec que utiliza apenas IKE+ESP. No caso de utilizar também AH (Authentication Header), acrescentar na segunda etapa (após o ESP), também o redirecionamento do protocolo nr. 51 (AH).

(**) Agradeço à publicação da dica do Luciano no Abusar.org (http://www.abusar.org/manuais/m_alcatel.html) e ao artigo por ele citado (http://www.ozcableguy.com/alcatel.html#vpn), que me serviram de base para este.