Esta semana tive que restringir o acesso ao webmail de uma das empresas em que faço suporte. O Pessoal queria que apenas alguns colaboradores tivessem acesso ao webmail.

O webmail utiliza o protocolo IMAP para acessar as caixas postais e autenticar os usuários, o servidor utilizado é o Courier Imap que possui suporte a autenticação PAM.

O PAM (Pluggable Autentication Module) fornece um biblioteca para autenticar usuários em sistemas linux e outros sabores de *nix. Aplicações desenvolvidas com suporte ao PAM utilizam uma biblioteca de alto nível para realizar rotinas de autenticação é as bibliotecas PAM de baixo nível cuidam da interação com os diversos mecanismos de autenticação existentes (ldap, kerberos, etc...). Desta forma uma aplicação com suporte ao PAM poderá ser utilizada com diferentes mecanismos de autenticação e o programador só precisa se preocupar com as rotinas de alto nível do PAM.

Voltando para o propósito deste texto que é o controle de acesso aos serviços de um servidor, tinha uma lista de 6 usuários que poderiam acessar o webmail.

O PAM possui um módulo chamado listfile.so que permite liberar ou bloquear um serviço baseado em informações obtidas de um arquivo.

O Courier Imap deste servidor está confrigurado com suporte a PAM, então o que tive que fazer foi adicionar uma linha ao /etc/pam.d/imap. No meu caso eu substitui a linha referente a autenticação do usuário (auth) por esta:

auth required pam_listfile.so onerr=fail item=user sense=allow file=/etc/webmail_access

Opções do pam_listfile.so

onerr – Que ação tomar caso alguma coisa errada aconteça. No meu caso o acessa vai falhar (fail) ou pode aceitar (suceed)

item – O que estará listado no arquivo. No meu caso será o nome dos usuários (user) mas pode ser também; tty,rhost,ruser,group,shell

sense – Qual ação tomar. No meu caso permitir (allow), pode ser também negar (deny).

file - Arquivo contendo um item por linha. Deverá ser um arquivo texto comum e não poderá ter permissão de escrita para todos.

Com a linha acima todos os usuários que terão acesso ao Webmail terão os nomes adiconados no arquivo /etc/webmail_access. Para os demais usuários o acesso será negado.

Para obter maiores informações sobre o PAM, veja o link logo abaixo.

http://www.ibm.com/developerworks/br/library/l-pam/index.html

É isso ai, espero que ajude e qualquer dúvida, crítica ou observação deixe um comentário.

Um abraço a todos!

Tenho um cliente que possuia uma conta de hospedagem em servidores linux porém não a utilizava. A empresa possui servidor de e-mail próprio e a Insite até então direcionava o MX de seus DNS apontando para seu servidor.

Minha dor de cabeça começou ontém por volta das 12:00. Este cliente passará a utilizar um sistema via WEB que roda sob ASP e por isso houve a necessidade de mudar o plano de hospedagem de linux para windows, até ai tudo bem, liguei para o suporte e me informei sobre o procedimento para realizartal migração, durante a conversa com o atendente, deixei bem claro que algumas configurações no DNS precisavam ser mantidas, pois a empresa possui servidor de e-mail próprio e da necessidade de não interrupção de e-mail.

Seguindo as orientações do atendente, deixei tudo muito bem claro, tanto sobre o novo plano de hospedagem, quanto aos registros no DNS.

Pois bem, ontém as 12:00 meu cliente me liga e diz que não estão recebendo os e-mails, na hora já imaginei que a migração estava sendo feita e fiz uma verificação de DNS utilizando o nslookup.

As 15:00 do dia 07/09/2008 liguei para o suporte e fui informado que a migração estava sendo realizada e todas as configurações necessárias para manutenção dos apontamentos do DNS seriam refeitas e até as 18:00 estaria tudo funcionando.

Fui para a faculdade e quando cheguei em casa por volta de 23:00 tinha recebido um e-mail so prórpio suporte me informando sobre a realização com sucesso da migração do plano de hospedagem.

Sabendo da atual necessidade de configuração do domínio do cliente, já fui logo fazendo um teste no DNS e apra minha surpresa, os apontamentos no DNS necessários para que o server de e-mail do meu cliente pudesse receber e-mails não foi criado.

A fu**u, ontem logo pela manha já começou a fala-fala com o suporte e nada do problema ser resolvido. Já abri um chamado logo pela manhã e fui informado que seria dado prioridade para a resoluçao do problema e o tempo foi passando, a cada ligação uma pessoa diferente na linha, tem que explicar tudo novamente e por ai vai.

Eu já enviei e-mail para tudo quanto é setor dentro desta empresa mais até agora nada.

talvés para quem não é da área de T.I possa parecer muito complicado, mas basicamente o que eu preciso e que foi muito bem detalhado e explicado ao suporte desta empresa, é que alguns apontamentos sejam criados no registro de DNS do domínio do meu cliente:

os hosts:

mercurio.dominiodocliente.com.br deve apontar para o IP XXX.XXX.XXX.XXX

smtp.dominiodocliente.com.br deve apontar para o IP XXX.XXX.XXX.XXX

pop.dominiodocliente.com.br deve apontar para o IP XXX.XXX.XXX.XXX

webmail.dominiodocliente.com.br deve apontar para o IP XXX.XXX.XXX.XXX

e o registro MX (Mail exchange) do DNS deve apontar par op host:

mercurio.dominiodocliente.com.br

Sinceramente não consigo entender qual o dificuldade em se fazer isso. As entras em um DNS são criadas da seguinte forma:

dominiodocliente.com.br IN MX 5 mercurio.dominiodocliente.com.br

mercurio.dominiodocliente.com.br IN A XXX.XXX.XXX.XXX

smtp.dominiodocliente.com.br IN A XXX.XXX.XXX.XXX

pop.dominiodocliente.com.br IN A XXX.XXX.XXX.XXX

webmail.dominiodocliente.com.br IN A XXX.XXX.XXX.XXX

Desta forma meu problema será resolvido e tudo voltará ao normal.

Na minha opinião isso é pura falta de capacidade técnica. Daqui a pouco lá vai eu novamente ter que enfrentar uma tempestade de navalha para tentar solucionar meu problema.

Obs.:  para resolução de problemas só há mesmo o telefone para falar com o suporte técnico e um e-mail de suporte, no site deles também encontrei um formulário onde emcaminhei para o setor de "relação com o cliente" uma mensagem muito parecida com este post.

Daqui a pouco tem mais,

Na primeira parte deste post foi feita a instalação do apache e do mod_python veja aqui (Post Anterior).Agora vamos dar seqüencia no processo de instalação do ambiente que tem como foco a preparação do servidor para utilização do subversion e do trac para gerenciar projetos que estou desenvolvendo em trac.

Este server também será preparado para a instalação futura do framework django para o desenvolvimento de uma novo projeto.

Vale lembrar que todos os pacotes foram descompactados em /usr/src e instalados como root:

Instalação do Swig

./configure -with-python=/usr/bin/python
make
make install

Instalação do Subversion

./configure --with-apxs=/usr/local/apache2/bin/apxs --with-apr=/usr/local/apr/ --with-apr-util=/usr/local/apr/ --without-neon

make
make install

Obs.: realizando a instalação sem a opção -without-neon compilará o neon que é uma biblioteca para acessa a servidores remotos pelo protocolo webdav. No meu setup aqui apresentou falhas na construção dos módulos python. Não perdi nenhuma funcionalidade desativando o neon. Caso tenha algum problema volto para corrigir.

Para começar a utilizar o subversion, precisamos configurar o servidor subversion utilizado para prover o serviço. Temos o svnserve e o apache via dav para prover tal serviço e segue a configuração para cada método. Mas antes vamos iniciar um repositório.

Criar novo repositório svnadmin create /caminho/para/repositorio

Iniciar servidor subversion

Para utilizar o svnserve como server temos duas formas de configurar:

Iniciando como Daemon

# svnserve -d

Iniciando pelo Inetd

# vi /etc/inetd

e adicione as linha

svn stream tcp nowait svnowner /usr/bin/svnserve svnserve -i

svnowner é um usuário criado para executar o svnserve, em meu server utilizo o usuário svn

Reinicie o serviço inetd.

Rodando o svnserver por padrão o serviço escutará na porta 3690 tcp caso tenha acesso externo ao servidor libera esta porta no firewall.

Agora já temos um servidor configurado com apache, mod_python e subversion.

Em um próximo post vamos configurar o apache para prover acesso ao repositório subversion e a população inicial de um repositório e checkout e commit de uma cópia de trabalho.

Referências:

Apache - www.apache.org

Mod_Python - www.modpython.org

Python - www.python.org

Subversion - subversion.tigris.org

Trac - trac.edgewall.org/

Decidi aceitar o desafio mais por uma questão didática, acho a experiência de compilar pacotes grandes e com variadas dependências essencial para conhecer profundamente determinado software.

O ambiente foi montado sobre um servidor Debian Etch e não utilizei as versões empacotadas dos respectivos softwares instalados. Antes de mais nada quero salientar que não tenho nada contra os pacotes deb muito pelo contrário. O debian possui excelentes ferramentas para gerenciamento de pacotes. Tive apenas a necessidade de utilizar versões mais atuais do apache e do subversion para poder utilizar o Trac e trabalhar em meus projetos em python

Softwares necessários

Apache 2.2.9
http://www.apache.org/dist/httpd/httpd-2.2.9.tar.gz
HTTP Server propriamente dito em sua última versão

Mod_Python 3.3.1

http://www.apache.org/dist/httpd/modpython/mod_python-3.3.1.tgz
Módulo do apache que permite utilizemos a linguagem python para desenvolver para web.

APR 1.3.2

http://www.apache.org/dist/apr/apr-1.3.2.tar.gz

Biblioteca utilizado tanto pelo apache como pelo subversion que provê uma API que assegura que o código desenvolvido tenha o mesmo comportamento em plataformas específicas.

APR-Util 1.3.2

http://www.apache.org/dist/apr/apr-util-1.3.2.tar.gz

Mais bibliotecas utilizadas pelo APR

Subversion 1.4.6

http://subversion.tigris.org/downloads/subversion-1.4.6.tar.gz

Sistema de controle de versões.

SWIG 1.3.35

http://ufpr.dl.sourceforge.net/sourceforge/swig/swig-1.3.35.tar.gz

Ferramenta de desenvolvimento que conecta programas escritos em c/c++ com uma enorme variedade de linguagens de alto nível.

Instalando

Para facilitar vou citar apenas o processo de compilação dos softwares. O processo de descompactação está bem explicado em outros tutoriais pela internet e os pacotes foram descompactado em /usr/src e a instalação será feita como root.

Instalação das bibliotecas apr e apr-util

O Pacote apr e apr-util serão instalados em /usr/local/apr

Para compilar o apr

# ./configure

# make

# install

Entre nos diretórios dos fontes do apr-util e execute:

#./configure -with-apr=/usr/local/apr/

# make

# make install

Instalação do Apache

Os pacotes foram instalados com os comandos abaixo. As opções utilizadas em ./configure serão detalhadas em outro artigo. A instalação padrão será no diretório /usr/local/apache2

# ./configure --enable-rewrite=shared --enable-speling=shared --enable-so --enable-dav --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr/bin/apu-1-config --enable-proxy --enable-proxy-connect --enable-proxy-ftp --enable-proxy-http --enable-ssl --enable-http --enable-info --enable-dav --enable-suexec --enable-cgi --enable-dav-fs --enable-dav-lock --enable-vhost-alias # make

# make install

Instalação Mod_Python# ./configure --with-apxs=/usr/local/apache2/bin/apxs -with-python=/usr/bin/python

# make

# make install

Acesse o arquivo de configuração do apache em:

# /usr/local/apache2/conf/httpd.conf

Descomente a linha ServerName e adicione o nome do seu servidor, ex.

ServerName server.exemplo.com.br

Vamos iniciar o apache com o comando:

# /usr/local/apache2/bin/apachectl start

Agora já temos um servidor http instalado e configurado com os módulos dav e mod_python.

Voltaremos a configuração do servidor em um próximo post, contendo a instalação do subversion e o trac.

Referências:

Apache - www.apache.org

Mod_Python - www.modpython.org

Python - www.python.org

Subversion - subversion.tigris.org

Trac - trac.edgewall.org/