Non è possibile rimuovere i redirect in cPanel redirects

a volte a seguito di spostamenti server, migrazioni cPanel. o restore di backup ci si potrebbe trovare nella comoda situazione in cui collegandosi al pannello non è possibile disabilitare i redirects tramite il whm cPanel.

cPanel infatti ci proporrà:

Are you sure you wish to permanently remove the redirect ** All Requests ** on ** All Public Domains **

e premendo su si si otterrà:

The redirect ** All Requests ** on ** All Public Domains ** has been removed.

Per risolvere questa scomoda situazione (oserei chiamarlo BUG) bisogna semplicemente collegarsi al proprio spazio web via ftp o ssh e editare manualmente il file .htaccess andando a rimuovere la o le righe riguardanti il redirect

 

 

Ottimizzare Server MySQL / Tuning MySQL Server

Oggi vedremo come migliorare le performance di un server mysql attraverso la customizzazione ( personalizzazione ) del file di configurazione my.cnf:

Questa operazione insieme all ottimizzazione del server web Apache (nel nostro caso) può portare a riduzione dei consumi oltre al 50% che si traduce in un vantaggio economico :

1) per il Service Provider permetterà di offrire performance migliori e/o Hostare piu clienti su un singolo server.
2) per il cliente che acquista una VPS si traduce in minori risorse necessarie e quindi un taglio VPS meno costoso.

di base il file my.cnf è vuoto e mysql utilizza i valori di default : questi vanno bene per un 99% degli usi tradizionali, ma a volte sopratutto in ambiendi di shared hosting, questa politica porta ad uno spreco di risorse che si traduce in rallentamenti del server.

una volta effettuata una copia di backup del file my.cnf, editiamolo con un editor ( in questo caso VI ), nel mio caso il file è situalto in /et/my.cnf

apriamo il file ed inseriamo al suo interno :

[mysqld]
set-variable = max_connections=200
query_cache_type=1
query_cache_size=32M
query_cache_limit=1M
sort_buffer_size=2M
read_rnd_buffer_size=512K
tmp_table_size=32M
max_heap_table_size=32M
thread_cache_size=24
key_buffer_size=16M
table_cache=128
join_buffer_size=1M
log-slow-queries=/var/lib/mysql/slow.log

in questo modo inseriremo dei valori piu adatti al nostro scopo e abiliteremo ( tramite l’ultima riga) il log delle query lente.
Riavviamo il server mysql e nel caso non partisse ripristiniamo il file my.cnf originale.
Non ci resta che attendere 24 ore e lanciare da shell il comando ./mysqltuner.pl
(assicuriamoci di averlo installato ne l caso non sia presente.) il quale ci indicherà eventuali altri ottimizzazioni da effettuare. a correzzioni fatte , riavviamo il server e attendiamo altre 24 ore. Questa operazione puo essere ripetuta finche non otterremo il limite di prestazioni oltre il quale per motivi pratici il server non migliorerà piu. Esistono dei tool di benchmark che eseguono query specifiche per testare la risposta del server. ne parleremo eventualmente in un altro articolo.

 

Questo risultato è stato ottenuto dopo una prima grossolana ottimizzazione, si evince che la strada seguita è giusta, d’ora in avanti si cercherà il fine tuning per spremere il motore MySQL fino all ultimo Mhz.

post-ottimizzazione-mysql

 

 

edit 1:

dopo 20 ore abbontanti ecco cosa ci propone il mysqltuner :

 

——– General Statistics ————————————————–
[–] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.69-cll
[OK] Operating on 64-bit architecture

——– Storage Engine Statistics ——————————————-
[–] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[–] Data in MyISAM tables: 457M (Tables: 1994)
[–] Data in InnoDB tables: 70M (Tables: 238)
[!!] Total fragmented tables: 63

——– Performance Metrics ————————————————-
[–] Up for: 20h 13m 3s (5M q [74.746 qps], 99K conn, TX: 19B, RX: 790M)
[–] Reads / Writes: 88% / 12%
[–] Total buffers: 162.0M global + 3.9M per thread (200 max threads)
[OK] Maximum possible memory usage: 937.0M (16% of installed RAM)
[OK] Slow queries: 0% (6/5M)
[OK] Highest usage of available connections: 21% (43/200)
[OK] Key buffer size / total MyISAM indexes: 16.0M/128.8M
[OK] Key buffer hit rate: 99.1% (202M cached / 1M reads)
[OK] Query cache efficiency: 81.2% (3M cached / 4M selects)
[!!] Query cache prunes per day: 501755
[OK] Sorts requiring temporary tables: 0% (2 temp sorts / 148K sorts)
[!!] Joins performed without indexes: 1423
[!!] Temporary tables created on disk: 34% (63K on disk / 183K total)
[OK] Thread cache hit rate: 99% (62 created / 99K connections)
[!!] Table cache hit rate: 0% (128 open / 1M opened)
[OK] Open file limit used: 1% (217/13K)
[OK] Table locks acquired immediately: 99% (1M immediate / 1M locks)
[OK] InnoDB data size / buffer pool: 70.3M/80.0M

——– Recommendations —————————————————–
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours – recommendations may be inaccurate
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
query_cache_size (> 32M)
join_buffer_size (> 1.0M, or always use indexes with joins)
tmp_table_size (> 32M)
max_heap_table_size (> 32M)
table_cache (> 128)

ho eseguito queste modifiche

query_cache_size (> 32M) – portato a 64mb
join_buffer_size (> 1.0M, or always use indexes with joins) – portato a 2 mb
tmp_table_size (> 32M) – portato a 64mb
max_heap_table_size (> 32M) – portato a 64mb
table_cache (> 128) portato a 192

 

Problemi con MAC OSX e VPN ? – riavvia racoon

Problemi con MAC OSX e VPN  ? – riavvia racoon

Nel caso improvvisamente il nostro amato mac non ci facesse connettere in vpn, al posto di riavviare il portatile (cosa alquanto fastidiosa se abituati all’ affidabilità tipica di un Mac) potete riavviare il demone che si occupa delle connessioni VPN, ovvero Racoon.

Per riavviarlo, da terminale, inseriamo ( una riga per volta):

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.racoon.plist
sudo launchctl load /System/Library/LaunchDaemons/com.apple.racoon.plist

a questo punto riprovando a connetterci dovrebbe andare tutto a buon fine !

Qual’è la URL dei feed RSS del mio blog WordPress?

WordPress utilizza uno standard per gestire i Feed RSS, ci sono 2 possibilità:

nel caso non avessi attivato l’url rewriting i feed sono raggiungibili da:

http://dominio.estensione/?feed=rss
http://dominio.estensione/?feed=rss2
http://dominio.estensione/?feed=rdf
http://dominio.estensione/?feed=atom

Mentre se hai attivato l’url rewriting puoi travare il feed a questi indirizzi:

http://dominio.estensione/feed/
http://dominio.estensione/feed/rss/
http://dominio.estensione/feed/rss2/
http://dominio.estensione/feed/rdf/
http://dominio.estensione/feed/atom/

Disabilitare o limitare il revision dei Post su WP (also Disable or limit WordPress Post revisions)

WordPress e i database immensi……

Ieri ero alle prese con la migrazione di un cliente sulla nuova infrastruttura quando per la prima volta in uno shared hosting WordPress mi sono imbattuto in un database di dimensioni “Bibliche”

dopo una breve analisi ho individuato la tabella wp_post come colpevole, e analizzandola a fondo ho realizzato che erano i revision wp.

ci sono 2 strade percorribili per evitare questo fastidioso (e ingombrante ) problema :

La prima è tramite modifica del file wp-config.php :

andando a inserire in fondo al file la riga :

define('WP_POST_REVISIONS', false );

disabiliteremo completamente le Post_revision, mentre inserendo questa:

define('WP_POST_REVISIONS', 3);

andremo a limitare tutte le revision ad un numero da noi stabilito, in questo caso 3

 

Per chi non volesse o non potesse eseguire modifiche al file wp-config segnalo infine un comodo plugin ( e gratis ): Revision control. Tramite questo, potrete impostare il numero massimo di revisioni per messaggi e pagine, e il range di revisioni totale, in modo da poter impostare uno specifico numero di revisioni per ogni tipologia di post.
Naturalmente, se non si imposta nulla di specifico verrà utilizzato il valore di default del plugin.

 

una volta fermata l’emorragia di spazio e risorse potremo tramite phpmyadmin andare a cancellare le fastidisose revisioni :

Cancellare le revisioni esistenti.

Aprire phpmyadmin, andare in SQL options e lanciare questa query:

DELETE FROM wp_posts WHERE post_type = "revision";

Questa query cancellerà tutti i post di tipo revision e le revisioni di pagina. Potete comunque estendere ( e limitare) la cancellazione su uno specifico range temporale. Per esempio, se volessimo cancellare le revisioni antecedenti al 5 gennaio 2013 dovremmo scrivere :

DELETE FROM wp_posts WHERE post_type = "revision" AND post_modified < "2013-01-05 00:00:00";

Ricordate che il formato data è anno,mese,giorno.

Per conclusere – La post revision o revisione dei post che dir si voglia è una funzione davvero comoda, ma solo se tenuta sotto oculato controllo 😉

Spero che questo articolo possa aiutare molti di voi ! Buon uso di WordPress

cPanel & WHM si aggiorna alla versione 11.38

I tecnici di cPanel non dormono mai. Dopo una lunga attesa, finalmente, ( si spera XD) nel changelog della futura release vediamo:

Improved SSL Management System

In 11.38, the SSL Management System has been updated. These updates include: SNI support: You can now host multiple SSL Certificates, for different domains, on the same IP address. Server owners and users can now determine the primary virtualhost for an IP address Improved Wildcard and UCC/SAN certificate support, which allows users to use the same certificate for multiple subdomains. UCC/SAN certificates allow for simplified certificate sharing across multiple domains. Updated interfaces that provide more guidance through the various workflows of managing certificates and their assets. Certificate data is UTF8 safe, which allows for native language support in certificates and their assets. OSCP stapling support is available on systems using Apache 2.4.

Finalmente potremmo fornire il supporto ai certificati ai clienti senza per forza dovergli assegnare un IP dedicato…. e visto che l’ultima classe A ipv4 è stata assegnata quale notizia migliore?

 

Tra le novità salienti troviamo infine :

Improved Backup System

In 11.38, WHM offers a new interface to create backups. This new interface has several features that give system administrators the opportunity to customize the backup configuration.

Speriamo che l’ormai arcaico e semplicistico sistema di backup oltre che il look ci porti nuove ( e attese ) Features ,….. la backup retention sembra comunque ancora lontana…

 

Magari nella versione 11.40 ci daranno possibilità di fare del TOMCAT virtual host… chissà

Installazione VMware Tools Centos 6.x

Presupposti : essere collegati a un server Vsphere 5.x tramite client.

Per prima cosa dal menu della macchina virtuale andiamo a montare il cd virtuale  i vmware-tools

Una volta eseguito ciò, da shell andiamo a creare la cartella dove montare il cdrom

mkdir /media/cdrom 

montiamo il cd virtuale nel percorso appena creato

mount /dev/cdrom /media/cdrom

ci spostiamo nella cartella temporanea

cd /tmp 

esplodiamo il tar

tar xzvf /media/cdrom/VM* 

ci spostiamo nella cartella appena creata

cd vm* 

lanciamo l’installer dei tool

./vmware-install.pl

a fine installazione torniamo nella root

cd ..
cd ..

e rimuoviamo la cartella temporanea creata

rm -rf /tmp/vmware-tools-distrib

fine.