quarta-feira, 15 de setembro de 2010

Resolvendo problemas de conectividade do McAfee Total Protection

Esses dias estive num cliente com o seguinte cenário: McAfee Total Protection instalado na rede como solução de segurança. Por razões internas, o firewall é desativado nas estações e servidores. Mas acontece que foi liberada uma atualização da versão, que, ao instalar, ativou o firewall.
Resultado: ninguém na rede conseguia acessar o servidor.
Como não era a primeira vez que isso acontecia, partiram para a desinstalação do produto e instalação, sem o firewall. Isso foi realizado com o suporte McAfee. Mesmo assim, não tinha comunicação entre servidor e estações de trabalho.
A parte engraçada era que o servidor conseguia acessar outros serviços de rede como cliente (proxy, banco de dados e até unidades de rede mapeadas - NetBIOS), mas não conseguia resposta de um comando ping e ninguém conseguia acessar seus arquivos.
Depois de muito bater a cabeça, desinstalando várias vezes o AV, sem sucesso, resetando o protocolo TCP/IP, achei este artigo "How to uninstall or reinstall supported McAfee consumer products using the McAfee Consumer Products Removal tool (MCPR.exe)" que foi minha salvação. E olha que já havia usado o próprio desinstalador do Total Protection, disponibilizado na página de gerenciamento do produto.
Após seguir os procedimentos descritos, baixar a ferramenta, reinicializar o servidor, tudo voltou ao normal.
Fica a dica!

Para baixar o MCPR.exe, clique aqui.

quinta-feira, 2 de setembro de 2010

Instalando ntop no CentOS - tutorial rápido

Uma maneira prática e rápida para instalar o ntop (www.ntop.org) no CentOS 5.
Para quem não conhece, o ntop é uma ferramenta que mostra o tráfego de rede, similar ao conhecido comando 'top' do mundo *nix. Pode ser instalado também em plataformas Win32.

Nosso tutorial vai utilizar as maravilhas oferecidas pelos gerenciadores de pacotes, evitando perder precioso tempo desvendando dependências, etc., etc., etc.


Pré-Requisitos:

# yum install libpcap-devel libpcap

Instalação

Resolvi fazer a instalação pelo yum, para isso acionei o repositório DAG:

# rpm -Uhv http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.5.1-1.el5.rf.i386.rpm
# yum update
# yum install rrdtool
# yum install ntop

Executando:

Precisamos definir uma senha para o usuário 'admin' do ntop, para isso vamos executar o comando abaixo:

# ntop

Acessando o Ntop

Para acessar o ntop utilize o endereço:



Ok, está instalado, mas se eu quiser que o ntop inicialize junto com meu servidor, executo o comando:

# chkconfig ntop on

Pronto. Mas este pacote tem um pequeno problema no script de inicialização e dá um erro, que pode ser visualizado após o comando:

# service ntop start

Starting ntop:    Processing file /etc/ntop.conf for parameters...
Mon Aug  3 19:49:38 2009  NOTE: Interface merge enabled by default
Mon Aug  3 19:49:38 2009  Initializing gdbm databases
FATAL ERROR: Unrecognized/unprocessed ntop options...
, --user=ntop, , --db-file-path=/var/ntop, , ,  ,  --use-syslog=local3, , , , , , , 
--daemon,
run ntop --help for usage information

    Common problems:
        -B "filter expressions" (quotes are required)
        --use-syslog=facilty (the = is required)

                                                           [FAILED]

Que lindo...
Basta editar o arquivo /etc/init.d/ntop:

start () {
    echo -n $"Starting $prog: "
#   daemon $prog -d -L @/etc/ntop.conf
    daemon $prog @/etc/ntop.conf -d -L 

Os parâmetros '-d -L' devem estar no final do comando.

Um pequeno arremate, para o usuário ntop poder gerar os gráficos rrd:

# chown ntop.ntop /var/ntop/rrd/ -R

Ufa! agora, sim! podemos usar o ntop e monitorar nossa rede.

Quero deixar meus agradecimentos a Diego Fucitalo (http://diegofucitalo.blogspot.com/) que foi o blog que me ajudou a montar este tutorial, Hemingway, onde encontrei a correção (http://poweredbyapathy.com/service-ntop-start-causes-fatal-error-on-centos/) para inicializar o ntop. Parabéns a estes companheiros que compartilham conhecimento para a comunidade!

quarta-feira, 16 de junho de 2010

Exchange: Banco de Dados é restaurado do backup com status "Dirty Shutdown"

Esta semana me deparei com a seguinte situação: tive que restaurar um grupo de armazenamento do Exchange Server, porém o database não montava.

Ao verificar o status do mesmo, através do comando eseutil.exe, opção file dump (eseutil /mh .edb), o status me retornava o seguinte:
State: Dirty Shutdown
A partir daí, fiz o seguinte procedimento:
  1. Efetuar um restore do banco de dados do grupo de armazenamento que apresenta este problema;
  2. Desabilite a opção "Last Restore Set (Log file will replay after this restore completes.)"
  3. Execute o comando, no diretório de restauração do banco de dados:
    eseutil /cc /f  
  4. Após a conclusão, executar o comando:
    eseutil /mh .edb
  5. Verificar o status do banco, que deve estar da seguinte forma:

    State: Clean Shutdown
Sendo assim, já podemos montar o banco pelo System Manager e liberar o uso para os usuários.

Estes procedimentos foram realizados em um servidor MS Exchange Server 2003.

Aproveito para deixar aqui um link que pode ser muito útil, caso seja necessário recuperar o Information Store:

How to recover the information store on Exchange 2000 Server or Exchange Server 2003 in a single site

terça-feira, 4 de maio de 2010

ADPREP no Windows Server 2008 R2

É sabido que, quando se tem um controlador de domínio na rede, não basta aparecer com um servidor com a versão mais recente do Windows Server e simplesmente promover a controlador de domínio.
Cada versão, além dos novos recursos, tem suas melhorias de segurança, e tem alguns requisitos que devem ser satisfeitos antes que esta versão funcione como controlador de domínio.

Para isso utilizamos o adprep.exe, que se encontra na mídia de instalação do sistema operacional.
No caso do Windows Server 2008 R2, fica em \support\adprep.
Porém, o Windows Server 2008 R2 só foi disponibilizado na plataforma 64 bits. Para plataformas x64, execute o adprep.exe que se encontra neste diretório. Se for 32 bits, adprep32.exe.

Primeiro executamos o seguinte comando:

adprep.exe /forestprep


Prepara a floresta para a introdução de um controlador de domínio que roda o Windows Server 2008. Esse comando é executado somente uma vez na floresta. Deve ser executado no controlador de domínio que tem a função de mestre de operações de esquema (schema operations master) para a floresta. Você deve ser membro dos seguintes grupos para executar este comando:
  • Enterprise Admins
  • Schema Admins
  • Domain Admins (do domínio que hospeda o mestre de esquema - schema master)
Então executamos:

adprep.exe /domainprep


Prepara o domínio para a introdução de um controlador de domínio que executa o Windows Server 2008. Ele é executado após o forestprep concluir e após a alterações serem replicadas em todos os controladores de domínio da floresta. Execute este comando em cada domínio que você planeja ter um controlador de domínio Windows Server 2008. Deverá rodar no controlador de domínio que tem a função de mestre de infraestrutura (infrastructure master) e seu usuário deverá estar no grupo Domain Admins para executar este comando.

Há ainda a opção "/domainprep /gpprep" que é similar ao /domainprep, porém ele fornece atualizações necessárias para habilitar a funcionalidade do modo de planejamento do Conjunto de Diretivas Resultante (Resultant Set of Policy - RSoP - Planning Mode). Atualiza permissões de sistema de arquivos e objetos de diretivas de grupo (Group Policy Objects - GPOs) existentes. Veja mais em Resultant Set of Policy (RSoP).

O Windows Server introduziu o recurso de Controladores de Domínio Somente Leitura (Read-Only Domain Controller - RODC). Quando não é possível garantir a segurança física de um controlador de domínio, pode ser instalado um RODC, que hospeda uma partição do AD somente para leitura. Neste caso, podemos usar o

adprep.exe /rodcprep

em qualquer computador da floresta e você deve ser membro do grupo Enterprise Admins para poder rodar este comando.

Para maiores detalhes:
http://technet.microsoft.com/pt-br/library/cc731728%28WS.10%29.aspx

quinta-feira, 1 de abril de 2010

Dica Oracle: recuperando senha

Ontem me deparei com um pequeno desafio: efetuar backup de uma instância Oracle em um servidor Windows Server 2003.
Até aí, nada de mais, porém, as contas sys e system estavam bloqueadas:
ORA-28000: the account is locked
Muito legal. Comecei uma busca que me levou a algumas informações interessantes que valem a pena ser registradas, uma vez que resolveu meu problema.

  1. Conectar à instância sem senha alguma.
    Tive que garantir no arquivo SQLNET.ORA a linha com este parâmetro SQLNET.AUTHENTICATION_SERVICES = (NTS). Como eu estava logado como o Administrador local, que fazia parte do grupo ORA_DBA, pude conectar à instância com o seguinte comando:

    C:\> sqlplus /nolog

    sql> connect / @ as sysdba;

  2. Desbloqueando a conta.
    Agora as coisas começam a melhorar, porque sofri um pouco até chegar neste ponto. Foi só executar o comando para permitir o acesso da conta:

    sql> alter user system account unlock;

    sql> alter user sys account unlock;

  3. Definindo a senha.
    E como eu já estava com a faca e o queijo na mão, restou definir uma senha para as contas:

    sql> alter user system identified by sua_senha;

    sql> alter user sys identified by sua_senha;

Assim pude executar as rotinas de backup, acessar o Enterprise Manager e tudo mais.

quarta-feira, 13 de janeiro de 2010

Dica Linux: Convertendo timestamp do log do squid

Quem já se aventurou em visualizar o log de acesso do squid (/var/log/squid/access.log em distribuições Red Hat like) sabe que a primeira coluna é o horário de acesso, vejam o exemplo, só com os primeiros campos de um registro do log:

1263314279.013 671 192.168.1.195 TCP_MISS/200 ...

Aí vem a pergunta: como eu sei que data/horário foi feito esse acesso, em linguagem mais acessível?

Esse formato é o timestamp unix que é simplesmente um contador que teve seu valor zero associado com a data 01/01/1970 00:00:00UTC, e que é incrementado a cada segundo. Quem viveu o bug do milênio, vai se deparar com algo parecido em 2038, pois esse formato trata-se de um inteiro sinalizado de 32 bits (signed int32), que atingirá seu limite no ano citado. Após isso, o calendário voltaria para 13/12/1901 20:45:52 UTC (uau!). A solução seria portar as aplicações para utilizar um inteiro sinalizado de 64 bits (signed int64) o que dá uma folga de uns 290 bilhões de anos! :D

Voltando ao nosso assunto, para fazer uma conversão durante a leitura dos logs, podemos utilizar um simples script em perl que é descrito abaixo:

#!/usr/bin/perl -p
s/^\d+\.\d+/localtime $&/e;

Salve o arquivo, dê permissão de execução ao script (que eu chamei de timeconvert.pl)

chmod +x timeconvert.pl

Agora redirecione a saída do log para este script, da seguinte forma (estou assumindo que o script está no seu diretório atual, caso contrário, especifique o caminho completo):

cat /var/log/squid/access.log | ./timeconvert.pl

A saída deverá ser a seguinte:

Tue Jan 12 11:37:59 2010 671 192.168.1.195 TCP_MISS/200 ...

Com certeza, muito melhor de visualizar e analisar.

Mais informações:

http://pt.wikipedia.org/wiki/Era_Unix

http://en.wikipedia.org/wiki/Unix_time