De nerd para nerd, de Geek para Geek, de nerd para não nerd!

E quem disse que precisa de pânico?

Siga os passos como root:

yum update -y && yum install libevent libevent-devel -y
yum install libevent-devel libevent gcc make -y
wget http://memcached.googlecode.com/files/memcached-1.4.5.tar.gz
tar xvf memcached-1.4.5.tar.gz && cd memcached-1.4.5 && ./configure && make && make install

Inserindo valores no conf:

vim /etc/memcached.conf

Dentro do conf informe:

#Memory a usar
-m 16
# default port
-p 11211
# user to run daemon nobody/apache/www-data
-u nobody
# only listen locally
-l 127.0.0.1

criando scripts de inicialização:

touch /etc/init.d/memcached
dando permissões ao script:
chmod +x /etc/init.d/memcached

Abra o script /etc/init.d/memcached e insira nele:

#!/bin/bash
#
# memcached This shell script takes care of starting and stopping
# standalone memcached.
#
# chkconfig: - 80 12
# description: memcached is a high-performance, distributed memory
# object caching system, generic in nature, but
# intended for use in speeding up dynamic web
# applications by alleviating database load.
# processname: memcached
# config: /etc/memcached.conf
# Source function library.
. /etc/rc.d/init.d/functions
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/local/bin/memcached
DAEMONBOOTSTRAP=/usr/local/bin/start-memcached
DAEMONCONF=/etc/memcached.conf
NAME=memcached
DESC=memcached
PIDFILE=/var/run/$NAME.pid
[ -x $DAEMON ] || exit 0
[ -x $DAEMONBOOTSTRAP ] || exit 0
RETVAL=0
start() {
echo -n $"Starting $DESC: "
daemon $DAEMONBOOTSTRAP $DAEMONCONF
RETVAL=$?
[ $RETVAL -eq 0 ] && touch $PIDFILE
echo
return $RETVAL
}
stop() {
echo -n $"Shutting down $DESC: "
killproc $NAME
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f $PIDFILE
return $RETVAL
}
# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
restart|reload)
stop
start
RETVAL=$?
;;
status)
status $prog
RETVAL=$?
;;
*)
echo $"Usage: $0 {start|stop|restart|status}"
exit 1
esac
exit $RETVAL


Criando script secundário:
touch /usr/local/bin/start-memcached
Dando permissões ao script:
chmod +x /usr/local/bin/start-memcached

Abra o script /usr/local/bin/start-memcached e dentro dele informe:


#!/usr/bin/perl -w
# start-memcached
# 2003/2004 - Jay Bonci
# This script handles the parsing of the /etc/memcached.conf file
# and was originally created for the Debian distribution.
# Anyone may use this little script under the same terms as
# memcached itself.
use strict;
if ($> != 0 and $< != 0) {
print STDERR "Only root wants to run start-memcached.\n";
exit;
}
my $etcfile = shift || "/etc/memcached.conf";
my $params = [];
my $etchandle;
# This script assumes that memcached is located at /usr/bin/memcached, and
# that the pidfile is writable at /var/run/memcached.pid
my $memcached = "/usr/local/bin/memcached";
my $pidfile = "/var/run/memcached.pid";
# If we don't get a valid logfile parameter in the /etc/memcached.conf file,
# we'll just throw away all of our in-daemon output. We need to re-tie it so
# that non-bash shells will not hang on logout. Thanks to Michael Renner for
# the tip
my $fd_reopened = "/dev/null";
sub handle_logfile {
my ($logfile) = @_;
$fd_reopened = $logfile;
}
sub reopen_logfile {
my ($logfile) = @_;
open *STDERR, ">>$logfile";
open *STDOUT, ">>$logfile";
open *STDIN, ">>/dev/null";
$fd_reopened = $logfile;
}
# This is set up in place here to support other non -[a-z] directives
my $conf_directives = {
"logfile" => \&handle_logfile
};
if (open $etchandle, $etcfile) {
foreach my $line (<$etchandle>) {
$line =~ s/\#.*//go;
$line = join ' ', split ' ', $line;
next unless $line;
next if $line =~ /^\-[dh]/o;
if ($line =~ /^[^\-]/o) {
my ($directive, $arg) = $line =~ /^(.*?)\s+(.*)/;
$conf_directives->{$directive}->($arg);
next;
}
push @$params, $line;
}
}
unshift @$params, "-u root" unless (grep $_ eq '-u', @$params);
$params = join " ", @$params;
if (-e $pidfile) {
open PIDHANDLE, "$pidfile";
my $localpid = ;
close PIDHANDLE;
chomp $localpid;
if (-d "/proc/$localpid") {
print STDERR "memcached is already running.\n";
exit;
} else {
`rm -f $localpid`;
}
}
my $pid = fork();
if ($pid == 0) {
reopen_logfile($fd_reopened);
exec "$memcached $params";
exit(0);
} elsif (open PIDHANDLE,">$pidfile") {
print PIDHANDLE $pid;
close PIDHANDLE;
} else {
print STDERR "Can't write pidfile to $pidfile.\n";
}


Inicie o memcached:
/etc/init.d/memcached restart

Vamos setar o memcached para iniciar com o server:
/sbin/chkconfig memcached on

Agora vamos integrar pecl + memcached (parte do PHP):

wget http://pecl.php.net/get/memcache-2.2.5.tgz
tar xvf memcache-2.2.5.tgz && cd memcache-2.2.5 && phpize && ./configure && make && make install

abra o arquivo php.ini global do server e vamos arrumar a muamba:

vim /usr/local/lib/php.ini

Procure pela parte de Extension e informe o seguinte:

extension=memcache.so

Reinicie o apache:

service httpd restart

Pronto, depois disso é so lazer.

Quer conferir?

vim teste.php
Dentro dele informe

php -f test.php | grep “memcache support”

A saída será:

memcache support => enabled

Fonte? Sim, os caras mais pauleiras de hosting que já vi (tirando Softlayer, é claro):

http://sudomakeinstall.com/linux-systems/install-memcached-to-cpanel

Para resolver este problema em seu Cpanel/WHM não é tão difícil assim.
Um dos fatores principais deste erro sem dúvidas é alguma zona de DNS que o domínio que você tentou restaurar o backup ainda existe.
Para descobrir isso procure na área de DNS (DNS Functions) a opção Delete a DNS zone.
Coloque o nome do domínio que você queria restaurar os backups.
Em seguida delete a zona de DNS confirmando.
O problema deverá estar sanado.

Logue-se como root em seu servidor.

Em seguida digite:

exim -bp | awk '/^ *[0-9]+[mhd]/{print "exim -Mrm " $3}' | bash

Outro comando útil é:
exim -bp | exiqgrep -i | xargs exim -Mrm

Se você está tentando enviar emails pelo RoundCube e sabe que o mesmo fica somente apresentando a mensagem “Enviando mensagem…” e não faz nada, tente as soluções abaixo:

1 – Como root use o comando:

(http://www.nerdblog.info/2009/11/04/webmail-no-cpanel-whm-nao-envia-mais-mensagens/)

Caso não resolva ainda podemos aplicar uma solução mais leve:

2 – Verifique se o CSF está instalado em seu servidor, cas0 sim, acesse o csf em seu WHM -> Plugins -> ConfigServer Security&Firewall -> clique em Firewall Configuration e procure por SMTP_ALLOWLOCAL, caso esteja como “0″ coloque “1″, save as configurações e reinicie seu CSF/LFD.

Caso não resolve (muito difícil de não sanar), vamos mergulhar mais fundo no problema, force uma atualização do RoundCube com o comando:

3 – logado como root:

Caso ainda assim não alcance o resultado esperado, apele para update geral:

4 – Procure pelo arquivo -> /usr/local/cpanel/base/3rdparty/roundcube/config/main.inc.php, abra-o e edite procure pela linha:

$rcmail_config['smtp_user'] = ‘%u’;

e substitua a mesma por:

$rcmail_config['smtp_user'] = ‘ ‘;

Salve e saia, em seguida tente ver se o roudcube opera como desejado.

5 – Como root execute:

Caso resolva, dê um whois neste domínio e envie uma caneca do Ubuntu, Uma camisa do Ubuntu ou uma caixa de bis!

Abraços.

Bem, para viciado em Gnu/Linux existe solução, mas e quando você vai à uma empresa prestar consultoria e se depara com uma besteirinha dessas aqui:

Um amigo meu, dooguinha ficou louquinho de tanto que insisti com ele para ele bater foto disso… lol, mas parece ou não parece?

Cpanel -> R$ 69 reais,
Celeron 1.7 -> R$ 110 reais,
Ser viciado em Cpanel Não tem preço!

Olá ALL,

Uma coisa comum para combater uso indevido de cgi é impedir o uso de cgi (perl) em um servidor de hospedagem de sites compartilhada, mas nem sempre dá para impedir o uso.
Então uma das formas de contornar o uso indevido é aplicar regras do mod_security do apache afim de que possamos filtrar o máximo de requisições e ainda por cima ganhar com segurança.
Antemão quero salientar que uma das pragas mais comuns da web é o DM.CGI, esse carinha faz um estrago grandinho com spam, podendo levar um servidor para as mais conceituadas rbls. Como resolver?

No WHM, como root, siga para o último menu (PLUGINS) e procure pelo Mod Security.
CLique nele, dentro dele clique em Edit Configuration.
Dentro dela adicione as seguintes linhas:

SecRule REQUEST_URI “dm.cgi”
SecRule REQUEST_URI “dark.cgi”
SecRule REQUEST_URI “udp.pl”
SecRule REQUEST_BODY|REQUEST_URI “\.cgi\?m\=state”
SecRule REQUEST_BODY|REQUEST_URI “cgi\?m\=snd”
SecRule REQUEST_BODY|REQUEST_URI “cgi\?m\=icfg”
SecRule REQUEST_BODY|REQUEST_URI “\.pl\?m\=state”
SecRule REQUEST_BODY|REQUEST_URI “pl\?m\=snd”
SecRule REQUEST_BODY|REQUEST_URI “pl\?m\=icfg”

Isto irá salvar sua pele!

fonte: http://www.forumcpanel.com.br/index.php?showtopic=8608&hl=secrule

Um amigo forista me passou nesta manha uma ferramenta interessante que foi desenvolvida por terceiros, mas que dá suporte ao Subversion no WHM/Cpanel. Quando conversei com Seto Ichitaka ele confirmou mesmo que a ferramenta funciona de forma bacaninha.

Algumas notas da empreitada podem ser vistas em:

http://forums.cpanel.net/f77/cpanelsvnmanager-beta-released-install-subversion-easily-149713.html

ou com a nota do site aonde o projeto está:

http://opensourcebattlefield.com/news/1

É fato que saibamos do seguinte:

1 – O plugin é iniciativa de terceiros,
2 – O plugin não está em stable, por isso qualquer update ou problema só tem 1 destino->reportBUG();

Abraços galera!

Recentemente, um cliente reclamou que seus emails não chegavam à caixa postal do destinatário.
Verifiquei que o domínio do destinatário em questão está hospedado em uma conta Windows na Locaweb, mas com os MX apontando para a Alog.
Eu tenho vários clientes com o Google Apps. Ou seja, estão hospedados no meu servidor mas utilizando o MX do Google. Todos funcionando beleza e nunca precisei editar configurações específicas no Exim do meu servidor. Mas neste caso, enquanto não se resolve a questão da configuração do DNS na Locaweb, optei por um recurso que eu desconhecia mas que atendeu ao meu cliente que agora consegue enviar os emails.
Resolvi compartilhar esta informação. Quem sabe alguem passe pelo mesma situação…
O problema foi resolvido adicionando a linha abaixo ao /etc/exim.conf:
allow_mx_to_ip = yes

Fonte: Luiz_Araujo:

http://www.forumcpanel.com.br/index.php?showtopic=8971&pid=40431&st=0&#entry40431

Se você está recebendo a mensagem de erro ao tentar entrar no phpmyadmin do Cpanel (incorret user or password) peça para o administrador do servidor atualizar o cpanel usando o comando:

/scripts/upcp –force

Stable, Release, Current e Edge apresentam correção.

Caso isto não resolva veja se o arquivo:

/usr/local/cpanel/base/3rdparty/phpMyAdmin/config.inc.php

Está com as linhas:

$cfgServers[$i]['controluser']
$cfgServers[$i]['controlpass']

comentadas.

Caso sim, descomente.

Abraços galera.

Se você utiliza-se do Fantástico DELUXE e nem em sonho entende o por que que este bendito pede shell_exec ativo, ou mesmo, conhece sobre shell_exec mas sabe que isto é um ponto a menos na segurança em um ambiente compartilhado, PSIU, se está precisando dele OFF esta dica é para você!

Para acabar de vez com a mensagem Warning: shell_exec() siga os passos abaixo:

(por prevensão vamos desabilitar o shell_exec no lugar correto)
Entre no /usr/local/lib/php.ini e insira a função shell_exec no parâmetro disable_functions
Em seguida use o seguinte comando:

/scripts/makecpphp

O Cpanel vai processar o php interno (não é o de uso dos domínios) do Cpanel e ajustar tudo .

Hoje eu passei por algo bem contraditório em minhas pesquisas sobre cpanel.
Desde 2008 utilizo current no estilo de updates que seto nas máquinas de clientes e hoje (05/04/2010) me deparei com algo bem maluco, recebi a seguinte mensagem:

Specified package does not exist

Quando um usuário tentava mudar um plano (pacote) de sua revenda.

Como resolver?

A indicação dada é de que, em casos como este deixe o update em modo RELEASE e atualize seu painel de controle (/scripts/upcp –force).

Abraços pessoALL.

rode os comandos como root para remover o apf:

/etc/rc.d/init.d/apf stop

rm -Rf /etc/apf
rm -Rf /etc/rc.d/init.d/apf
rm -Rf /var/log/apf_log
rm -Rf /var/log/apfados_log
rm -Rf /usr/local/sbin/apf

Desabilite o serviço do apf

/sbin/chkconfig –level 345 apf off

vim /etc/cron.daily/fw

e remova a linha abaixo:

/etc/rc.d/init.d/apf restart >> /dev/null 2>&1

Pronto, o script firewall APF agora não mais está ativo em seu servidor.

É uma cara de pau dos sysadmins omitirem qualquer ajuda simples e ainda falarem: “É complexo fazer o aumento a quantidade de envios de emails por hora no exim cpanel”.
Esta solução serve para quando o cliente precisa que um domínio em especial envie mais emails que o padrão do servidor.
Este how to foi feito por mim (little_oak) e estou postando com exclusividade aqui.
É simples, como root entre no arquivo:

/var/cpanel/maxemails

Informe o domínio que deseja, por exemplo nerdblog.info e complete com a sintaxe final:

nerdblog.info=2000

Essa sintaxe habilita 2000 emails por hora para o domínio nerdblog.info.
Após o ajuste /scripts/build_maxemails_config

Pronto.

Deus é fiel e nós somos os caras (eu e vc) lol!

Abração!

Em /usr/local/apache/conf/httpd.conf procure a linha abaixo:
ScriptAliasMatch ^/?controlpanel/?$ /usr/local/cpanel/cgi-sys/redirect.cgi

Abaixo dela, cole:
ScriptAliasMatch ^/?painell/?$ /usr/local/cpanel/cgi-sys/redirect.cgi

Salve e feche o arquivo e execute o comando abaixo:
/usr/local/cpanel/bin/apache_conf_distiller –update;/usr/local/cpanel/bin/build_apache_conf

Após, reinicie o httpd:
service httpd restart

Fonte:

http://www.forumcpanel.com.br/index.php?showtopic=8912&pid=40102&st=0&#entry40102

Em inglês seria how to recovery packages, em pt_br, como recuperar pacotes de um servidor formatado?
A idéia é salvar desde pessoas que procuram como americanos ou brasileiros.
Isto é uma dúvida comum para as pessoas que migram seus servidores (ou recuperam após um grave problema) e não sabem como recuperar os pacotes do servidor.
Bem, nada de preocupação!

Assim que o servidor for formatado, acesse o disco antigo e copie a pasta /antigo_disco_montado/var/cpanel/packages /var/cpanel/packages

Pronto, para conferir você pode listar todas as contas e verá que os respectivos pacotes estarão ok

Abraços.

Boa tarde ALL,

Super simples, logue-se como root e rode os seguintes comandos:

/scripts/checkimagemagick

Caso Não seja exibido “OK” rode o comando abaixo:

/scripts/installimagemagick

Pronto!

Para quem usa CSF e deseja aumentar a quantidade de tentativas de acesso no firewall antes que ele dê um lock no ip, basta acessar o arquivo de configuração do CSF e modificar a quantidade de tentativas em:

LF_SSHD = para tentativas ssh,

LF_FTPD = para tentativas ftp,

LF_SMTPAUTH = para tentativas smtp,

LF_POP3D = para tentativas pop,

LF_IMAPD = para tentativas imap,

LF_HTACCESS = para tentativas de acesso por htaccess.
Informe valores numéricos após o  =

Abraços.

Abaixo ensino como instalar o clickbe em um ambiente CPANEL/WHM, siga os passos logando-se como root:

mkdir -p /var/netenberg/click_be/installer/
cd /var/netenberg/click_be/
wget http://www.netenberg.com/files/click_be/free/click_be_installer.bz2
tar -xjpf click_be_installer.bz2
cd /var/netenberg/click_be/installer/
php click_be.php status

pico /var/netenberg/click_be/settings/private_settings.ini
pico /var/netenberg/click_be/settings/public_settings.ini
cd /var/netenberg/click_be/installer
php click_be.php install

Nos arquivos INI procure deixar de acordo com seu server, ou seja, Se suexec estiver on, na linha de suexec diga On, se o Open_Basedir tiver on no server, diga On e assim por diante. Tome cuidado com maiúsculas e minúsculas (o trosso é case sensitive).

Em tese, é isto aqui:

/var/netenberg/click_be/settings/private_settings.ini
wget -> O caminho do wget (cuidado com o bug da Netenberg em cima do wget)

/var/netenberg/click_be/settings/public_settings.ini
Others -> User_Name (não mexa)
Others -> Group_Name (não mexa)
suEXEC -> Status (ajuste caso esteja ON)

—————–

Com os passos acima tudo deve ficar ok, mas abaixo complemento com mais informações:

Normal Update:
cd /var/netenberg/click_be/installer
php click_be.php update

Forced Update:
cd /var/netenberg/click_be/installer
php click_be.php update force

Run a cron job for automatic updates:
cd /var/netenberg/click_be/installer
php click_be.php cron install

Remove the cron job for automatic updates:
cd /var/netenberg/click_be/installer
php click_be.php cron uninstall

Part IV – How to install sites

cd /var/netenberg/click_be/installer
php click_be.php sites install $USER $GROUP $HOME $WWW $DOMAIN $DIRECTORY
$USER = name of the user
$GROUP = name of the group
$HOME = home directory (trailing slash is absolutely neccessary)
$WWW = www (public_html) directory (trailing slash is absolutely neccessary)
$DOMAIN = domain name
$DIRECTORY = the directory where you want to install it (optional)

Example:

cd /var/netenberg/click_be/installer
php click_be.php sites install joe joe /home/joe/ /home/joe/public_html/ joesdomain.com site/new/

This will install the site at http://joesdomain.com/site/new/

cd /var/netenberg/click_be/installer
php click_be.php sites install user user /home/user/ /var/www/html/ user.com

This will install the site at http://user.com/

If you leave the $DIRECTORY variable as empty, the site will be installed in the root (http://joesdomain.com/)

How to login?
It is simple, just use your FTP Username and Password.

Alternatively, you can create a file called demo.php inside the folder $WWW/.click_be/:
The contents of demo.php should be as follows:
<?php
$Username = ‘user’ ;
$Password = ‘pass’ ;
?>
Now you can login with “user” as your username and “pass” as your password.
A demo installation of Click Be! does not need FTP login data (and in the final version it will not send out any emails, ie Newsletter).

Part V – How to uninstall sites?

cd /var/netenberg/click_be/installer
php click_be.php sites uninstall $USER $DOMAIN $DIRECTORY
$USER = name of the user
$DIRECTORY = the directory where you had installed it

Part VI – Help Me! I still do not understand!

cd /var/netenberg/click_be/installer
php click_be.php usage

Para instalar/reparar o rvskin siga os passos abaixo:

dir /root/rvadmin; cd /root/rvadmin; wget http://download.rvglobalsoft.com/download.php/download/rvskin-auto/saveto/rvauto.tar.bz2; bunzip2 -d rvauto.tar.bz2; tar -xvf rvauto.tar; perl /root/rvadmin/auto_rvskin.pl
rm -f /usr/local/cpanel/Cpanel/rvversion
perl /root/rvadmin/auto_rvskin.pl

Sempre que houver algum problema de execução do cron, parte dos problemas dá-se pelas permissões incorretas, para isto basta corrigir com o seguinte comando (dentro de seu server e como root):

chmod 4755 /usr/bin/crontab

Abraços galera.