Pesquisar este blog

sexta-feira, 4 de janeiro de 2008

Arquivo de configuração httpd.conf TRADUZIDO

Conforme prometi em nossa comunidade no orkut, seque abaixo o arquivo httpd.conf (configuração do servidor apache WEB 1.3.XX):

##
## httpd.conf -- Arquivo de configuração do servidor httpd Apache
##

#
# Baseado nos arquivos de configuração originais do servidor NCSA por Rob McCool.
# Modificado para distribuição junto ao guia Foca GNU/Linux Avançado
# http://focalinux.cipsga.org.br/
#
# Este é o arquivo de configuração principal do servidor Apache. Ele contém as
# diretivas de configuração que dão ao servidor suas instruções.
# Veja para informações detalhadas sobre as
# diretivas.
#
# NÃO leia simplesmente as instruções deste arquivo sem entender o que significam
# e o que fazem, se não tiver certeza do que está fazendo consulte a documentação
# on-line ou leia as seções apropriadas do guia. Você foi avisado.
#
# Após este arquivo ser processado, o servidor procurará e processará o arquivo
# /etc/apache/srm.conf e então /etc/apache/access.conf
# a não ser que você tenha modificado o nome dos arquivos acima através das
# diretivas ResourceConfig e/ou AccessConfig neste arquivo.
#
# Configuração e nomes de arquivos de log: Se os nomes de arquivos que
# especificar para os arquivos de controle do servidor iniciam com uma
# "/", o servidor usará aquele caminho explicitamente. Se os nomes *não*
# iniciarem com uma "/", o valor de ServerRoot é adicionado -- assim
# "logs/foo.log" com ServerRoot ajustado para "/usr/local/apache" será
# interpretado pelo servidor como "/usr/local/apache/logs/foo.log".
#
# Originalmente por Rob McCool
# modificado por Gleydson Mazioli da Silva para o guia Foca GNU/Linux

# Carga dos Módulos de Objetos Compartilhados:
# Para você ser capaz de usa a funcionalidade de um módulo que foi construído como
# um módulo compartilhado, será necessário adicionar as linhas 'LoadModule'
# correspondente a sua localização, assim as diretivas que os módulos contém
# estarão disponíveis _antes_ de serem usadas.
# Exemplo:

#
# ServerType pode ser inetd, ou standalone. O modo Inetd somente é suportado nas
# plataformas Unix. O modo standalone inicia o servidor como um daemon.
#

ServerType standalone

# Se estiver executando a partir do inetd, vá até a diretiva "ServerAdmin".

# Port: A porta que o servidor standalone escutará. Para portas < org="" docs="" mod="" lockfile="">);
# e se salvará de vários problemas.
#
# Não adicione uma barra no fim do caminho do diretório.
#

ServerRoot /etc/apache

# BindAddress: Você pode usar esta opção em virtual hosts. Esta
# opção é usada para dizer ao servidor que endereço IP escutar. Ele pode
# conter ou "*", um endereço IP, ou um nome de domínio completamente qualificado
# (FQDN). Veja também a diretiva VirtualHost.

BindAddress *

#
# Suporte a Objetos Compartilhados Dinamicamente (DSO - Dynamic Shared Object)
#
# Para ser capaz de usar a funcionalidade de um módulo que foi compilado como
# um módulo DSO, você terá que adicionar as linhas 'LoadModule' correspondentes
# nesta localização, assim as diretivas contidas nela estarão disponíveis
# _antes_ de serem usadas. Por favor leia o arquivo README.DSO na distribuição
# 1.3 do Apache para mais detalhes sobre o mecanismo DSO e execute o comando
# "apache -l" para a lista de módulos já compilados (estaticamente linkados e
# assim sempre disponíveis) em seu binário do Apache.
#
# Please keep this LoadModule: line here, it is needed for installation.
# LoadModule vhost_alias_module /usr/lib/apache/1.3/mod_vhost_alias.so
# LoadModule env_module /usr/lib/apache/1.3/mod_env.so
LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so
# LoadModule mime_magic_module /usr/lib/apache/1.3/mod_mime_magic.so
LoadModule mime_module /usr/lib/apache/1.3/mod_mime.so
LoadModule negotiation_module /usr/lib/apache/1.3/mod_negotiation.so
LoadModule status_module /usr/lib/apache/1.3/mod_status.so
# LoadModule info_module /usr/lib/apache/1.3/mod_info.so
# LoadModule includes_module /usr/lib/apache/1.3/mod_include.so
LoadModule autoindex_module /usr/lib/apache/1.3/mod_autoindex.so
LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so
LoadModule php3_module /usr/lib/apache/1.3/libphp3.so
LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so
# LoadModule asis_module /usr/lib/apache/1.3/mod_asis.so
# LoadModule imap_module /usr/lib/apache/1.3/mod_imap.so
# LoadModule action_module /usr/lib/apache/1.3/mod_actions.so
# LoadModule speling_module /usr/lib/apache/1.3/mod_speling.so
LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so
LoadModule alias_module /usr/lib/apache/1.3/mod_alias.so
LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so
LoadModule access_module /usr/lib/apache/1.3/mod_access.so
LoadModule auth_module /usr/lib/apache/1.3/mod_auth.so
# LoadModule anon_auth_module /usr/lib/apache/1.3/mod_auth_anon.so
# LoadModule dbm_auth_module /usr/lib/apache/1.3/mod_auth_dbm.so
# LoadModule db_auth_module /usr/lib/apache/1.3/mod_auth_db.so
# LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so
# LoadModule digest_module /usr/lib/apache/1.3/mod_digest.so
# LoadModule cern_meta_module /usr/lib/apache/1.3/mod_cern_meta.so
LoadModule expires_module /usr/lib/apache/1.3/mod_expires.so
# LoadModule headers_module /usr/lib/apache/1.3/mod_headers.so
# LoadModule usertrack_module /usr/lib/apache/1.3/mod_usertrack.so
LoadModule unique_id_module /usr/lib/apache/1.3/mod_unique_id.so
LoadModule setenvif_module /usr/lib/apache/1.3/mod_setenvif.so
# LoadModule sys_auth_module /usr/lib/apache/1.3/mod_auth_sys.so
# LoadModule put_module /usr/lib/apache/1.3/mod_put.so
# LoadModule throttle_module /usr/lib/apache/1.3/mod_throttle.so
# LoadModule allowdev_module /usr/lib/apache/1.3/mod_allowdev.so
# LoadModule auth_mysql_module /usr/lib/apache/1.3/mod_auth_mysql.so
# LoadModule pgsql_auth_module /usr/lib/apache/1.3/mod_auth_pgsql.so
# LoadModule eaccess_module /usr/lib/apache/1.3/mod_eaccess.so
# LoadModule roaming_module /usr/lib/apache/1.3/mod_roaming.so

#
# ExtendedStatus: Controla de o Apache gerará detalhes completos de status
# (ExtendedStatus On) ou apenas detalhes básicos (ExtendedStatus Off) quando o
# manipulador (handler) "server-status" for usado. O padrão é Off.
#
ExtendedStatus on

#
# ErrorLog: A localização do arquivo de log de erros.
# Se não estiver especificando a diretiva ErrorLog dentro de ,
# as mensagens de erros relativas aos hosts virtuais serão registradas neste
# arquivo. Se definir um arquivo de log de erros para , as
# mensagens relativas ao servidor controlados por ela serão registradas lá e
# não neste arquivo.
#
ErrorLog /var/log/apache/error.log

#
# LogLevel: Controla o número de mensagens registradas no ErrorLog.
# Facilidades possíveis incluem: debug, info, notice, warn, error, crit,
# alert, emerg.
# Veja as facilidades na seção do guia sobre o syslog para detalhes
#
LogLevel warn

# As seguintes diretivas definem alguns formatos de nomes que serão usadas com a
# diretiva CustomLog (veja abaixo).

LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i" %T %v" full
LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i" %P %T" debug
LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined
LogFormat "%h %l %u %t "%r" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

#
# A localização e formato do arquivo de log de acesso (definida pela diretiva
# LogFormat acima).
# Se não definir quaisquer arquivos de log de acesso dentro de um
# , elas serão registradas aqui. Se for definida dentro
# de o arquivo de log de acesso será registrado no
# arquivo especificado na diretiva e não aqui.
#
#CustomLog /var/log/apache/access.log common

# Se você desejar ter um arquivo de log separado para o agent (navegador usado)
# e referer, descomente as seguintes diretivas.

#CustomLog /var/log/apache/referer.log referer
#CustomLog /var/log/apache/agent.log agent

# Se preferir um arquivo de log simples, com os detalhes de acesso, agent, e
# referer (usando o formato combined da diretiva LogFile acima), use a seguinte
# diretiva.

CustomLog /var/log/apache/access.log combined

#
# Incluir uma linha contendo a versão do servidor e um nome de host virtual
# para as páginas geradas pelo servidor (documentos de erro, listagens
# de diretórios FTP, saída dos módulos mod_status e mod_info, etc., exceto
# para documentos gerados via CGI). Use o valor "EMail" para também incluir
# um link mailto: para o ServerAdmin. Escolha entre "On", "Off" ou "EMail".
#
ServerSignature On

#
# PidFile: O arquivo que o servidor gravará os detalhes sobre seu PID quando
# iniciar.
#
PidFile /var/run/apache.pid

#
# ScoreBoardFile: Arquivo usado para armazenar detalhes do processo interno do
# servidor. Nem todas as arquiteturas requerem esta diretiva, mas se a sua
# requerer (você saberá porque este arquivo será criado quando executar o
# Apache) então você *deverá* ter certeza que dois processos do Apache não
# utilizam o mesmo arquivo ScoreBoardFile.
#
ScoreBoardFile /var/run/apache.scoreboard

#
# Na configuração padrão, o servidor processará este arquivo, o
# srm.conf e o access.conf neste ordem. Você pode fazer o servidor
# ignorar estes arquivos usando "/dev/null".
#
ResourceConfig /etc/apache/srm.conf
AccessConfig /etc/apache/access.conf

#
# A diretiva LockFile define o caminho do lockfile usado quando o servidor
# Apache for compilado com a opção USE_FCNTL_SERIALIZED_ACCEPT ou
# USE_FLOCK_SERIALIZED_ACCEPT. Esta diretiva normalmente deve ser deixada em seu
# valor padrão. A razão principal de modifica-la é no caso do diretório de logs
# for montado via um servidor NFS< com="">
#ServerAdmin webmaster@host.some_domain.com
#DocumentRoot /var/www/host.some_domain.com
#ServerName host.some_domain.com
#ErrorLog /var/log/apache/host.some_domain.com-error.log
#TransferLog /var/log/apache/host.some_domain.com-access.log
#



# VirtualHost: Se você quiser manter múltiplos domínios/nomes de máquinas em sua
# máquina você pode ajustar o conteúdo de VirtualHost para eles.
# Por favor veja a documentação em
# para mais detalhes antes de tentar configurar seus hosts virtuais.
# Você pode usar a opção de linha de comando '-S' para verificar sua configuração
# de hosts virtuais.

#
# Se desejar usar hosts virtuais baseados em nome, será necessário definir no
# mínimo um endereço IP (e número de porta) para eles.
#
#NameVirtualHost 12.34.56.78:80
#NameVirtualHost 12.34.56.78

#
# Exemplo de um Host Virtual:
# Praticamente qualquer diretiva do Apache pode entrar na condicional
# VirtualHost.
#
#
# ServerAdmin webmaster@host.some_domain.com
# DocumentRoot /www/docs/host.some_domain.com
# ServerName host.some_domain.com
# ErrorLog logs/host.some_domain.com-error.log
# CustomLog logs/host.some_domain.com-access.log common
#

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.