Pesquisar este blog

domingo, 16 de dezembro de 2007

Configurações APACHE (Parte II)

Antes de continuar com a segunda parte do tutorial que testei achei melhor publicar algumas observações sobre o tunning do apache que encontrei na rede a mais algumas dicas minhas que testei com sucesso (e algumas vezes nem tanto).


Um fator de extrema importância para um servidor web é a freqüência com que ele utiliza swap. Devido à natureza do serviço espera-se sempre uma resposta rápida do servidor e o processo de swap é um fator altamente degradante para o tempo de resposta. Quando a memória física (RAM) se esgota, o sistema operacional salva algumas informações pouco acessadas da memória no disco rígido, em um processo denominado troca ou swap. Esse processo apesar de necessário não deve ser utilizado com freqüência pois a leitura e a escrita no disco são de 10 a 100 vezes mais lentas do que na RAM, dependendo da máquina. Por isso devemos dimensionar o servidor web baseado exclusivamente na quantidade de memória RAM.


Façamos a seguinte conta:


Quantidade de memória RAM total - (menos) Quantidade de memória ocupada por programas quando o servidor web está desligado.


Agora vamos dividir o resultado pela quantidade média de memória ocupada por um processo filho do Apache (em torno 3M quando utiliza-se html puro, sem nenhuma linguagem interpretada e em torno de 20M para html+php) - você pode utilizar o top para descobrir esse valor.


O resultado obtido da divisão anterior deve ser o número máximo de clientes que seu host pode atender simultaneamente sem utilizar swap. Não se espante se o número for baixo (20, 30, 50,..). Mais adiante vamos fazer algumas contas que vão mostrar quantas requisições o seu servidor pode atender por minuto. Coloque este número como o valor MaxClients do Apache.


Se o seu host trabalha sempre perto da capacidade máxima configure o valor do StartServers, MinSpareServers e MaxSpareServers próximo ao valor do MaxClients (ex:80%), se não você pode trabalhar com um valor perto de 50% ou menos. Perceba que não há razão para utilizar valores de StartServers e MinSpareServers diferentes já que o serviço vai iniciar com o número de processos igual a StartServers e vai aumentar até atingir o número de MinSpareServers em poucos segundos. Diferenciar MinSpareServers e MaxSpareServers só fará sentido se seu servidor alterna entre períodos de grande e pequena demanda.


Vejamos agora um pouco do conceito de KeepAlive. Este recurso do Apache permite que um cliente faça várias requisições utilizando uma mesma conexão TCP. Isso economiza tempo e processamento evitando que novos sockets e novos processos sejam criados. A conexão TCP é terminada quando o cliente passa um tempo sem fazer requisições (KeepAliveTimeout) ou quando o processo responsável pela conexão atender o número de requisições igual a MaxKeepAliveRequests. Portanto utilizar este recurso é bom mas devemos tomar cuidado para não ocupar um processo por muito tempo evitando que novos clientes sejam atendidos. Valores que têm se mostrado razoáveis para o KeepAliveTimeout estão entre 1 e 5 segundos (é claro que utilizar um ou outro valor é uma decisão que você deve tomar baseado na quantidade de usuários e na qualidade do serviço que você quer prestar - valores mais baixos proporcionam maior rotatividade e valores mais altos maior qualidade no serviço do usuário que está sendo atendido. É como um médico cuja consulta dura 10 minutos e outro que dura 50). O mesmo conceito se aplica para o MaxKeepAliveRequests. Quanto maior esse número, mais requisições um mesmo usuário poderá fazer antes de liberar a conexão para outro. Valores típicos estão entre 100 e 500 (0 significa que não há limite).


Agora vamos fazer mais algumas contas. Supondo que, pelos cálculos anteriores, você possa atender 20 clientes simultaneamente e que você escolha 1 segundo para o KeepAliveTimeout. Na melhor das hipóteses e em uma situação ideal o servidor seria capaz de atender 1200 novas conexões por minuto. É claro que esse valor não representa 1200 usuários simultâneos porque um mesmo usuário pode abrir novas conexões à medida que vai navegando pelo site. Perceba que limitar o número de conexões simultâneas à um número pequeno não significa necessariamente que você só poderá atender poucos usuários.


A título de exemplo, vamos considerar um servidor com 512M de RAM que serve páginas web dinâmicas feitas em PHP e que os processos residentes, desconsiderando o Apache, ocupam 100M da memória RAM. Então,


512 - 100 = 412
412 / 20 = 20 e uns quebrados


Uma configuração que provavelmente otimizaria o seu Apache seria:


KeepAlive On
KeepAliveTimeout 1
MaxKeepAliveRequests 100


StartServers 15
MinSpareServers 15
MaxSpareServers 15
MaxClients 20
MaxRequestsPerChild 0


O valor de MaxRequestsPerChild representa o número de requisições que um processo filho do Apache pode atender antes de ser forçado a terminar. Isso era muito utilizado em sistemas operacionais com problemas de vazamento de memória (ex:Solaris). Se você utiliza Linux ou BSD é seguro utilizar 0 (infinito). Caso você note que depois de alguns dias a quantidade de memória utilizada por um processo está crescendo de forma anormal, mude esse valor para um valor finito porém grande (entre 5000 e 50000).


Além disso, se as aplicações que você hospeda demandam PHP considere utilizar uma extensão que faça cache do código intermediário (APC , Turck MMCache ,…). Essas extensões podem tornar o acesso até 5 vezes mais rápido.



Aviso: Todos os tutoriais postados pelo autor foram testados em ambiente de produção. Porem o mesmo não se responsabiliza por problemas ou bugs existentes nos sistemas usados de terceiros ou por erros durante a instalação dos recursos/scripts testados - o uso dos mesmos é por conta e risco de seus usuários

quarta-feira, 28 de novembro de 2007

Configurações APACHE (Parte I)

Creio que o maior calcanhar de aquiles de qualquer servidor de hospedagem que se preze é realmente o WebServer (no meu caso o Apache). Principalmente após o lançamento definitivo do Apache 2.0 e depois suas versões correlatas, devido a suas mudanças (é praticamente um outro sistema totalmente diferente) e possibilidades de configuração.

Muitos acham que o Servidor de Email é o que dá mais trabalho, mas basicamente o trabalho em um MTA é a luta contar o SPAM. O resto é de funcionamento e configuração bem simples, desde que você entenda a "linguagem" de configuração que praticamente terá de aprender para configurar corretamente um Sendmail da vida.

Mas eu acho que você "tunar" corretamnente o Apache é muito mais complicado, devido a suas possibilidades e diferentes configurações.

Este post pretende ser o primeiro de uma série exatamente sobre o Apache.

Primeiro, alguns passos básicos sobre a configuração. eu achei o artigo (muito bom) em http://www.howtoforge.com/configuring_apache_for_maximum_performance (ingles) e (com algumas alterações minhas) o traduzi. É um texto bastante explicativo.

Devido ao tamanho eu o dividi em 2 partes distintas. A primeira parte segue logo abaixo:

Carregue apenas os módulos necessários

O servidor Apache é um programa modular onde o administrador pode escolher entre as funcinalidade que deseja incluir no servidor selecionando um pacote de módukis. Os módulos podem ser compilados estaticamente no binário httpd ou dinamicamente como DSOs(Dynamic Shared Objects). Módulos DSO podem ser compilados quando o servidor for compilado ou poem ser compilados utilizando o apxs para adicioná-los mais tarde. O modulo mod_so deve ser compilado estaticamente no Apache para que o suporte a DSO seja ativo.

Execute o apache apenas com os módulos necessários. Isto reduz o consumo de memória aumenta a performance do servidor. Compilar os módulos estaticamente irá reduzir o consumo de RAM que é utilizado para suportar módulos compilados dinamicamente, mas será necessário recompilar o apache toda vez que um módulo for adicionado ou removido. È aqui que o DSO se torna útil. Uma vez que o modulo mod_so seja compilado estaticamente, qualquer outro módulo pode ser inserido ou removido utilizando o comando LoadModule no arquivo httpd.conf - , mas você terá que compilar os módulos utilizando apxs se ele não foi compilado quando o servidor foi feito.

Escolha o MPM apropriado

O apache vem com uma selação de Módulos Multi-Processadores (MPMs) que são responsáveis por abrir as portas de rede na máquina, aceitando requisições, e despachando processos para cuidar das requisições. Apenas um MPM pode ser carregado por vez.

Escolher o MPM depende de vários fatores, por exemplo se o SO suporta threads, quanta memória está disponível, escalabilidade versus estabilidade, modulos externos,etc .. Sistemas Linux podem escolher entr utilizar um MPM com suporte (worker) a threads ou um prefork sem threads:

O MPM Worker utiliza múltiplos processos. Ele é multi-threaded com cada processo e cada thread cuidando de uma única conexão. Esté é mais rápido e mais escalável e a memória consumida e relativamente baixa. Funciona bem com múltiplos processadores. Porém, o worker é menos tolerante a módulos defeituosos, e threads defeituosas podem afetar todas as outras threads de um processo.

O MPM Prefork utiliza múltiplos processos filhos, cada filho cuidad de apenas uma conexão por vez. Prefork é muito bem gerenciada por processadores simples ou múlitplos, a velocidade é comparável ao worker e é mais tolerante a falhas em modulos e processos que terminam inesperadamente. Mas o consumo de memória é alto, mais tráfego leva a mais consumo de memória.

Opções de Configuração em Tempo de Execução

DNS lookup

A diretiva HostnameLookips habilita a consulta de DNS, então os hostnames podem ser logados ao invés de endereços IP. Isto adiciona latência em cada requisição desde que a consulta do DNS tem que ser completada antes que a requisição seja terminada. Esta opção é desabilitada por padrão no Apache 1.3 e superiores. Deixe isto inativo e utilize programas pós-processamento como o logresolve para determinar os IPs dos logs. Logresolve vem com Apache.

Quando utilizar as diretivas Allow from ou Deny from, utilize endereços IP ao invés de nomes de domínios. Caso contrário uma consulta dupla ao DNS será executada para ter certeza de que o domínio ou host não está sendo spoofado.

AllowOverride

Se o AllowOverride está setado para 'None', então o Apache irá tentar abrir o arquivo .htaccess (especificada pela diretiva AccessFileName) em cada diretório que for acessado. Por exemplo:
DocumentRoot /var/www/html

AllowOverride all
Se uma requisição for feita para acessar /index.html, o Apache irá tentar abrir /.htaccess, /var/.htaccess, /var/www/.htaccess, and /var/www/html/.htaccess. Estas tentativas aumentam a latência. Se o arquivo .htaccess for necessário para um diretório, habilite apenas para este diretório.

FollowSymLinks e SymLinksIfOwnerMatch

Se a opção FollowSymLinks estiver setada, então o servidor permitirá que links simbólicos possam ser seguidos neste diretório. Se a opção SymLinksIfOwnerMatch estiver setada, então o servidor permitirá acessar o link apenas se o destino dele bater com o dono do link.

Se a opção SymLinksIfOwnerMatch estiver setada, então o Apache terá que realizar consultas adicionais ao sistema para verificar se os donos coincidem. Chamadas adicionais também são necessárias quando a opção FollowSymLinks NÃO está setada. Por exemplo:
DocumentRoot /vaw/www/html

Options SymLinksIfOwnerMatch

Para uma requisição feita para /index.html, o Apache irá executar lstat() em /var, /var/www, /var/www/html, and /var/www/html/index.html. Estas requisições adicionais também irão aumentar a lantência. Os resultados do lstat não são cacheados, então as consultas irão ocorrer em cada requisição.

Para uma máxima performance, sete FollowSymLinks em cada lugar e nunca sete SymLinksIfOwnerMatch. Ou então, se SymLinksIfOwnerMatch for necessário para um diretório, sete ele para apenas este diretório.

FIM DA PRIMEIRA PARTE

Aviso: Todos os tutoriais postados pelo autor foram testados em ambiente de produção. Porem o mesmo não se responsabiliza por problemas ou bugs existentes nos sistemas usados de terceiros ou por erros durante a instalação dos recursos/scripts testados - o uso dos mesmos é por conta e risco de seus usuários


>br>

terça-feira, 27 de novembro de 2007

Erro na atualização do sistema FANTASTCO

Sobre erros na atualização do sistema FANTASTCO, eu identifiquei alguns problemas com as atualizações o sistema FANTASTICO em alguns servidores. Futucando um pouco na net eu encontrei a solução e principalmente a explicação da origem do problema.


O problema ocorre principalmente na versão LINUX CentOs 5, Fedora Core 7 e Red Hat Enterprise 5 (versões red hat e derivadas), que por sua vez, apresentam o WGET (utilitário de download de arquivos) incompatível com a ferramenta de autoinstall do Fantastico De Luxe 2.10.4 r10 (LATEST and STABLE releases), sendo uma das saídas atualizar o Wget ou fazer DownGrade de Versão, e lembrando que não baixe uma versão muito antiga pois pode tornar-se ineficiente para futuras operações de Administração do Servidor.


O tutorial segue logo abaixo (já testado) Antes de mais nada baixe o Wget com os passos abaixo. No ajuste feito Hoje em Um servidor Dedicado Opteron 1200 series apliquei a seguinte versão do Wget -> ftp://ftp.gnu.org/gnu/wget/wget-1.10.1.tar.gz. REMOVA O WGET “BUGGADO”, com o comando abaixo:

yum remove wget (quando ele pedir confirmação confirme com “Y”)


Esta versão (que citei acima), apesar de ser ”obsoleta” é bastante estável.Para instalar use os seguintes comandos (Após baixar):

tar -zxvf wget-1.10.2.tar.gz


cd wget (ou use o comando a direita para entrar na pasta -> cd pastaqueOtargzGEROU).Em seguida use os comandos:


./configure –prefix=/usr/local/


Depois:


make && make all && make install


Por último, localize o wget com o comando abaixo:


find / -name wget


Acesse a pasta aonde ele se encontra. Ao Acessar copie o arquivo para o diretório /usr/bin com o comando abaixo:


cp wget /usr/bin/


Feito isto, basta tentar Reinstalar o Fantastico De Luxe 2.10.4 r10


Aviso: Todos os tutoriais postados pelo autor foram testados em ambiente de produção. Porem o mesmo não se responsabiliza por problemas ou bugs existentes nos sistemas usados de terceiros ou por erros durante a instalação dos recursos/scripts testados - o uso dos mesmos é por conta e risco de seus usuários

sexta-feira, 23 de novembro de 2007

Upgrade do CPANEL/WHM

Eu tenho recebido alguns emails falando sobre problemas de upgrade do CPANEL/WHM para a nova versão lançada a alguns meses (CPANEL11). O problema (para variar) é sempre em relação ao upgrade automático do CPANEL. Até hoje não entendo porque um upgrade com 4 níveis de verões e distros dá tanto problema.


Antes de efetuar o upgrade é necessário que o admin do servidor execute alguns procedimentos para não dar xabu, principalmente com a versão do PERL instalada. Por algum mistério insondável o CPANEL NÂO faz o update do PERL, provavelmente por causa dos módulos que são compilados com ele (módulos necessários par ao correto funcionamento do CPANEL e que demoram algum tempo para serem compilados).


Para ver se você necessita fazer este update manualmente acesse seu servidor via SHH e execute:


perl -v


A versão do perl correta é a 5.8.8 – qualquer versão anterior a esta será necessário ser atualizada. Para isso execute:


wget http://layer2.cpanel.net/perl588installer.tar.gz
tar zxvf perl588installer.tar.gz
cd perl588installer
perl install


Estes comandos acima baixam o pacote PERL já pre-compilado com todos os módulos necessários. Agora saia do micro e beba um café e leia um livro. O bicho demora um pouco (embora não gere muito load/processamento da máquina, é de bom tom executar apenas de madrugada ou em outro horário de menor uso do servidor).


Após finalizado execute:


/usr/local/cpanel/bin/checkperlmodules


Isso atualiza e reintegra os pacotes com os módulos PERL recém instalados no CPANEL. Existem outros dois módulso que você deve instalar manualmente:


/scripts/realperlinstaller YAML::Syck
/scripts/realperlinstaller File::Copy::Recursive


Pronto, CPANEL pronto para atualização para o CPANEL11:


/scripts/upcp –force (para atualizar o CPANEL completamente – por favor usem as distros REALEASE ou STABLE apenas)


Este pequeno tutorial também serve caso você já esteja usando a versão 11, não sendo necessário o /scripts/upcp –force.

quarta-feira, 1 de agosto de 2007

Vulnerabilidade do CPANEL

Esta é antiga (setembro de 2006), mas fiz questão de deixar reforçado aqui para todos e para mostrar que muitas vezes o nosso cPanel também é uma bela dor de cabeça. Eu upei o vídeo que o artigo informa para o http://www.youtube.com.br para posta-lo aqui diretamente.


É interessante você testar se seu sistema realmente esta seguro e sem esta falha (se bem que esta é bem antiga, mas nunca se sabe). aliás um ótimo site que todos devem acessar periodicamente é o WebSense


Esta notícia fez muito "sucesso" no meio pois afetou um dos grandes (talvez o maior) host que usa o cPanel profissionalmente.


Eu retirei o artigo do portal MeioBit


Uma vulnerabilidade antiga do cPanel, mas que só foi descoberta agora, que permite a um usuário local ganhar privilégios de root, foi descoberto após a infecção de centenas (ou milhares, as informações são vagas) de sites hospedados no HostGator.


Um script não compilado utilizado do MySqlAdmin permitiria que um usuário, com acesso local, sobrescrevesse este arquivo e esta cópia teria precedência sobre o MySqlAdmin correto, em função da ordem de preferência da pesquisa por módulos do perl.


Com esse script seria possível escalar privilégios, inclusive ganhando acessos de root.


A vulnerabilidade afeta todas as versões do cPanel tanto Stable, Release, Current quanto Edge lançadas até o dia 23/09/2006.


Rodar o script de atualização do cpanel (/scripts/upcp), após o dia 23/09/2006, é o suficiente para resolver o problema, caso o cPanel não esteja configurado para atualização automática.


No caso específico da HostGator, esse exploit foi usado para deformar 650 sites e redirecionar os usuários para páginas que se aproveitavam de uma brecha de segurança no VML do Internet Explorer para instalar um trojan que enviaria qualquer dado digitado em qualquer formulário para os e-mails dos crackers.


Este Vídeo demonstra claramente como funciona o trojan.


ATENÇÃO: Não acesse o site que aparece no vídeo, sua máquina será infectada, o site exibido explora várias brechas de segurança, mesmo acessando – o com o Firefox, você não estará seguro.


O cPanel vem apresentando algumas falhas esquisitas nestas últimas semanas, recomendo fortemente que a atualização automática esteja sempre ativa.


O cPanel é, muito provavelmente, o painel de controle mais utilizado em hospedagem de sites e muitos administradores (inclusive alguns que eu conheço) não gostam de deixar a atualização no automático, ou seja, mesmo com a atualização disponível não garante que estamos totalmente seguros.


Mas o mais impressionante desta história (além, é claro, de um problema como estes nunca deveria ter chegado em um produto final), são as novas formas que os crackers estão usando para fazer suas vítimas.


Cruzar bugs de dois sistemas diferentes é bastante engenhoso e que mesmo tomando os devidos cuidados, não estamos seguros.


Dica: É Importante deixar a opção de "Update de segurança" do WHM habilitada no automático. Embora o sistema de update do cPanel seja um verdadeiro caos - eu ainda posto aqui minhas experiências a respeito, acho que é por isso que estou perdendo o cabelo.

domingo, 29 de julho de 2007

Sistema de Atendimento ao Cliente

Eu recebo sempre pedidos de usuários e clientes nossos de revenda sobre sistemas de atendimento automatizado a clientes (ticket de atendimento). O melhor que já usamos (e por isso mesmo usamos até hoje) é o KAYAKO - http://www.kayako.com/

O problema do KAYAKO é que o mesmo é caro, mas na minha humilde opinião este sistema é o que os americanos definem como "estado da arte" em sistemas de atendimento.

Existem outros sistemas menos completos entre gratuitos e pagos eu destacaria o http://osticket.com/ (licença GPL), onde vc tem a possibilidade de (como qualquer scritp GPL) modificar o código de acordo com a sua necessidade e para atendimento específico via chat online temos o http://www.craftysyntax.com/ também sob licença GPL, ambos disponíveis no FANTASTICO em seu CPANEL.

Procurando links com informações na rede encontrei algumas soluções de atendimento via chat online que merecem ser testadas:
Agora sem sombra de dúvida o campeão de sistemas de atendimento via chat é o PHPliveSupport (http://www.phplivesupport.com/), que inclusive usamos (mesmo a KAYAKO tendo um sistema de chat junto com o seu poderoso sistema de atendimento via ticket).

Bom, gastei este texto todo apenas para passar um link de DOWNLOAD do sistema comercial livre para uso que já usamos - este é infinitamente superior a qualquer sistema de atendimento GPL (livre) existente.

Podem instalar e testar a vontade : Sistema de atendimento InverseFlow

Esta é a mesma versão que usávamos antes de comprarmos a KAYAKO.

Divirtam-se !!! Aos que desejarem testar as outras soluções ou que tenham conhecimento de outros sistemas e quiserem compartilhar fiquem a vontade.

quinta-feira, 24 de maio de 2007

RoudCube webmail


Já que o assunto está sendo sobre webmails, vamos a instalação do sistema RoudCube, ao meu ver um dos melhores webmails que temos disponíveis (bem melhor que o "famoso" uebimiau). Com este tutorial você pode disponibilizar o RoudCube como um novo webmail para ocupar o lugar do antigo Neomail (já retirado das distros do CPANEL).

1º Baixe o roudcube e descompacte-o no local correto no seu servidor CPANEL:

cd /usr/local/cpanel/base

wget -O roundcube.tar.gz http://puzzle.dl.sourceforge.net/sourceforge/roundcubemail/roundcubemail-0.1beta2.tar.gz
tar -zxvf roundcube.tar.gz

2º configure as permissões de acesso e criação de seu banco de dados (troque o SENHA pela senha root de seu banco mysql):

mv -f roundcubemail-0.1beta2 roundcube
cd roundcube
chmod -R 777 temp
chmod -R 777 logs
mysql -e "CREATE DATABASE roundcube;" -pSENHA
mysql -e "use roundcube; source SQL/mysql.initial.sql;" -pSENHA


3º edite as configurações do sistema


cd config; mv db.inc.php.dist db.inc.php; mv main.inc.php.dist main.inc.php
pico db.inc.php


troque a linha
$rcmail_config['db_dsnw'] = 'mysql://roundcube:pass@localhost/roundcubemail';
para
$rcmail_config['db_dsnw'] = 'mysql://root:SENHA@localhost/roundcube';

pico main.inc.php

troque a linha
$rcmail_config['default_host'] = '';
para
$rcmail_config['default_host'] = 'localhost';

4º editar as configurações de logotipo no CPANEL

cd /usr/local/cpanel/base/roundcube/skins/default/images/
cp /usr/local/cpanel/base/roundcube/skins/default/images/roundcube_logo.png /usr/local/cpanel/base/frontend/x/images/roundcube_logo.png
cp /usr/local/cpanel/base/roundcube/skins/default/images/roundcube_logo.png /usr/local/cpanel/base/webmail/x/images/roundcube_logo.png
cp /usr/local/cpanel/base/roundcube/skins/default/images/roundcube_logo.png /usr/local/cpanel/base/frontend/rvblue/themeimages/roundcube_logo.png


5º baixe o path para atualizar o roundcube para o uso no sistema CPANEL

wget http://www.insidehost.com.br/distros/install/HGpatch-roundcube-1.0BETA2
patch -p0 <>6º instale o pacote de língua portuguesa
cd /usr/local/cpanel/base/roundcube/program/localization
wget http://easynews.dl.sourceforge.net/sourceforge/roundcubemail/roundcube_brazilian-0.1-beta2.tar.gz
tar -zxvf roundcube_brazilian-0.1-beta2.tar.gz
chown -R root:root /usr/local/cpanel/base/roundcube


Pronto. Falta apenas um único detalhe, um bug que descobri. Você deve editar o arquivo compose:

pico /usr/local/cpanel/base/roundcube/skins/default/templates/compose.html

Na linha
form name="form" action="./" method="post"
troque por
form name="form" action="index.php" method="post"

Rode o comando abaixo para que sua instalação não seja sobrescrita pelas atualizações do CPANEL:

chattr +i /usr/local/cpanel/base/frontend/x/webmaillogin.html
chattr +i /usr/local/cpanel/base/webmaillogin.cgi


Pronto, você já tem um novo webmail.

Aviso: Todos os tutoriais postados pelo autor foram testados em ambiente de produção. Porem o mesmo não se responsabiliza por problemas ou bugs existentes nos sistemas usados de terceiros ou por erros durante a instalação dos recursos/scripts testados - o uso dos mesmos é por conta e risco de seus usuários.

Nova skin para o SquirrelMail


No primeiro tutorial uma coisa bem simples, mas que não vejo em praticamente em nenhum host: uma pele (skin, free ) disponível para o webmail SquirrelMail.

Encontrei este recurso por acaso, vasculhando no site SourceForge, e de brazuca.

Passo a Passo:

1º - acesse uma pasta em seu servidor, por exemplo, usr/scr ou outra qualquer que vc use para os códigos fontes, baixe e descompacte o pacote .tgz:

cd /usr/scr
wget http://easynews.dl.sourceforge.net/sourceforge/squirreloutlook/squirreloutlook-1.0.3.tar.gz
tar -xzf squirreloutlook-1.0.3.tar.gz

2º - acesse o diretório onde esta armazenado o SquirrelMail original do CPANEL e faça uma cópia/backup do mesmo:

cd /usr/local/cpanel/base/3rdparty
mv squirrelmail squirrelmail.BACKUP


3º - copie o novo SquirrelMail para o local, renomeando a pasta para squirrelmail, e aplicando as permissões de usuário CPANEL:

mv /usr/scr/squirreloutlook-1.0.3 /usr/local/cpanel/base/3rdparty/squirrelmail
chown cpanel:cpanel -R squirrelmail
chmod 777 /usr/local/cpanel/base/3rdparty/squirrelmail/data

4º - copie e atualize a configuração (diretório config) do novo SquirrelMail com a versão do CPANEL original:

rm -fr /usr/local/cpanel/base/3rdparty/squirrelmail/config
cd /usr/local/cpanel/base/3rdparty/squirrelmail
cp -R /usr/local/cpanel/base/3rdparty/squirrelmail.BACKUP/config .
chown cpanel:cpanel -R squirrelmail
chmod 777 /usr/local/cpanel/base/3rdparty/squirrelmail/data

Pronto. Tente acessar e testar, enviando e recebendo emails. É uma pele muito melhor que a atual, e ainda permite você aplicar as variações de cores, etc…
Aviso: Todos os tutoriais postados pelo autor foram testados em ambiente de produção. Porem o mesmo não se responsabiliza por problemas ou bugs existentes nos sistemas usados de terceiros ou por erros durante a instalação dos recursos/scripts testados - o uso dos mesmos é por conta e risco de seus usuários.

Blog Lançado !!!

Pode-se dizer que seja uma questão de puro narcisismo ou algo semelhante (se parar para pensar deve ser isso mesmo). Mas sempre desejei ter um BLOG para publicar opiniões e informações sobre algum tema. E qual seria o melhor tema/assunto para criar um BLOG que o assunto com o qual gasto 90% de meu tempo ?

A resposta me pareceu óbvia (até demais), o assunto que escolhi para esta BLOG não poderia ser outro: Tudo que tenha relação a administração de um Servidor Dedicado. Preferencialmente com o Sistema de controle CPANEL/WHM (mas publicarei informações sobre outros sistemas também).

Neste espaço eu pretendo publicar tutoriais e informações sobre o CPANEL/WHM e sobre Gerenciamento de Servidores dedicados, trabalho que faço a quase 10 anos (cacete… tô ficando velho) e compartilhar um pouco de minha experiência com outros. Tô ficando velho mesmo… sempre achei que compartilhar experiência é coisa de marmanjo.

Eu pretendo com o tempo ir modificando o layout e os textos publicados. É lógico que isso vai depender mais do tempo que eu tiver disponível.

Para a coisa ficar mais agradável eu crie também alguns links FIXOS em sites/portais e Fóruns sobre o CPANEL e sobre LINUX:

Uma comunidade no ORKUT sobre este BLOG, para ajudar a difundir o mesmo e os textos/tutoriais que serão publicados em http://www.orkut.com/Community.aspx?cmm=32839857

Logicamente (não poderia faltar) um post no Fórum do CPANEL em http://forums.cpanel.net/showthread.php?p=309176#post309176

Um post público no Fórum sobre o CPANEL (não oficial) em português em http://www.forumcpanel.com.br/index.php?showtopic=2721

Um abraço a todos e Sucesso !!!