Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Post - INVY

Pagine: [1] 2 3 ... 5
1
Server / MySQL 5.5 e memcached
« il: 09 Novembre 2015, 18:01:41 »
Ciao,

qualcuno ha già implementato memcached  su MySQL 5.5?



2
Supporto Generale / Re:Controllo stato dei dischi raid
« il: 28 Aprile 2014, 08:59:34 »
Grazie :-)

3
Supporto Generale / Controllo stato dei dischi raid
« il: 27 Aprile 2014, 12:13:52 »
Su una macchina con Linux Centos come posso fare per controllare/monitorare lo stato dei dischi raid? cioè, essere avvisato se un disco è prossimo alla rottura?

Grazie per gli eventuali consigli :-)

4
Server / error_log: disabilitare tutti i warn
« il: 02 Febbraio 2014, 10:52:43 »
Ciao,

vorrei che il file error_log contenesse solo gli [error] e non i [warn], nessun [warn] di alcun genere.

ho inserito nel file php.ini il comando:

error_reporting = E_ALL & ~E_WARNING & ~E_DEPRECATED

e riavviato httpd, ma nei log si registrano ancora dei [warn]

Dove sbaglio?

5
Supporto Generale / Re:Error: Multilib version problems found.
« il: 11 Dicembre 2013, 17:35:01 »
Grazie, è andato tutto a posto con la sequenza dei comandi indicata (semplice... come ogni cosa quando si fanno le cose giuste!)

 ;D


6
Supporto Generale / Error: Multilib version problems found.
« il: 08 Dicembre 2013, 23:25:19 »
Ciao,

mi trovo questo errore durante l'aggiornamento:

Codice: [Seleziona]

Error:  Multilib version problems found. This often means that the root
       cause is something else and multilib version checking is just
       pointing out that there is a problem. Eg.:
       
         1. You have an upgrade for nss-softokn-freebl which is missing some
            dependency that another package requires. Yum is trying to
            solve this by installing an older version of nss-softokn-freebl of the
            different architecture. If you exclude the bad architecture
            yum will tell you what the root cause is (which package
            requires what). You can try redoing the upgrade with
            --exclude nss-softokn-freebl.otherarch ... this should give you an error
            message showing the root cause of the problem.
       
         2. You have multiple architectures of nss-softokn-freebl installed, but
            yum can only see an upgrade for one of those arcitectures.
            If you don't want/need both architectures anymore then you
            can remove the one with the missing update and everything
            will work.
       
         3. You have duplicate versions of nss-softokn-freebl installed already.
            You can use "yum check" to get yum show these errors.
       
       ...you can also use --setopt=protected_multilib=false to remove
       this checking, however this is almost never the correct thing to
       do as something else is very likely to go wrong (often causing
       much more problems).
       
       Protected multilib versions: nss-softokn-freebl-3.14.3-9.el6.x86_64 != nss-softokn-freebl-3.14.3-3.el6_4.i686
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

e non ne vengo fuori...

Qualche consiglio? grazie :-)

7
Server / Re: Aggiornamento PHP non riuscito
« il: 27 Febbraio 2013, 08:35:58 »
mi rispondo da me:

ho disinstallato php-eaccelerator (pacchetto obsoleto) con

yum remove php-eaccelerator.x86_64

ed è bastato questo per permettere l'update di PHP e di tutte le sue dipendenze :-)

8
Server / Aggiornamento PHP non riuscito
« il: 27 Febbraio 2013, 07:31:19 »
Ciao,

su un server con CentOS6.3 - con reposity atomic attivato oltre che quelli di default - ho provato ad aggiornare PHP dalla versione 5.3.21 alla 5.3.22, cosa che ho eseguito su altri server senza problemi, ma non ci sono riuscito per via di "Protected multilib versions":

Loading mirror speeds from cached hostfile
 * atomic: mir01.syntis.net
 * base: mirrors.prometeus.net
 * extras: mirrors.prometeus.net
 * updates: mirrors.prometeus.net
183 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
....
Error: Protected multilib versions: php-common-5.3.22-15.el6.art.x86_64 != php-common-5.3.21-14.el6.art.i686
Error: Protected multilib versions: php-5.3.21-14.el6.art.i686 != php-5.3.22-15.el6.art.x86_64
Error: Protected multilib versions: php-cli-5.3.21-14.el6.art.i686 != php-cli-5.3.22-15.el6.art.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
.. install failed!

No packages were installed. Check the messages above for the cause of the error.

Prima di combinare guai, mi date delle "dritte" su come proseguire?

Grazie :-)

9
Server / Re: killare processi httpd in caso di sovraccarico...
« il: 11 Febbraio 2013, 13:51:37 »
Grazie :-)

10
Server / Re: killare processi httpd in caso di sovraccarico...
« il: 11 Febbraio 2013, 13:41:38 »
ok, mettiamo che il problema possa essere un aumento anomalo dei visitatori dei siti web, come si potrebbe contenerlo?

11
Server / Re: killare processi httpd in caso di sovraccarico...
« il: 11 Febbraio 2013, 13:18:10 »
e un suggerimento alternativo no?

12
Server / Re: killare processi httpd in caso di sovraccarico...
« il: 11 Febbraio 2013, 10:51:16 »
be', sì... certo!

Ma nel caso sia qualcosa di momentaneo, di improvviso, prima che arrivi l'avviso del sovraccarico e prima che si possa intervenire, anche se si trattasse di una decina di minuti, per intanto potrebbe essere utile?

13
Server / Re: mantenere aggiornato kernel
« il: 11 Febbraio 2013, 10:22:16 »
Mai dovuto riavviare quando aggiorno il kernel. A differenza di windows, che è un riavvio continuo, linux ha bisogno di riavviare (riavviare la macchina si intende) in pratica ogni morte di papa :-)

Può succedere che dopo un aggiornamento di un servizio, a me è capitato per MySQL (ma solo su un server, sugli altri non c'è stata necessità: non so perché!), si debba riavviare quel determinato servizio ma riavviare la macchina è proprio un evento raro (a meno che non si sia incasinato qualcosa, ma questo è un altro discorso...)

Comunque direi che sarebbe sempre meglio non eseguire l'update in automatico, ma farsi inviare una email con l'elenco di tutti i pacchetti che si potrebbero aggiornare: la sicurezza non sta solo nel kernel!

14
Server / killare processi httpd in caso di sovraccarico...
« il: 11 Febbraio 2013, 09:44:53 »
Ciao a tutti,

a volte capita che un server abbia dei sovraccarichi e che il riavvio automatico di httpd avvenga solo proprio quando il server non ce la fa più...

Così ho pensato a uno script che ogni tot di tempo controlli il carico e nel caso esegua un killall dei processi httpd.

A voi chiedo: può essere una buona soluzione?

Vi posto li script con le varianti di "killaggio", così mi date un parere:

Codice: [Seleziona]

#!/bin/sh
checkload=`uptime | cut -d, -f4 | cut -d: -f2 | cut -d. -f1`
if [ $checkload -ge 10 ]
then

#/etc/init.d/httpd restart
# kill -9 `ps -ef | grep ?httpd? | grep -v grep | awk ?{print $2}?`
# killall -HUP httpd
 killall -9 httpd


echo "Killing httpd processes - Load Average $checkload" | mail -s "Load Monitor" mia@email.xx
fi



Quale "killaggio" è consigliato?

#/etc/init.d/httpd restart
# kill -9 `ps -ef | grep ?httpd? | grep -v grep | awk ?{print $2}?`
# killall -HUP httpd
# killall -9 httpd

Grazie e buona navigazione

15
Server / Re: plesk e webmin possono coesistere?
« il: 11 Febbraio 2013, 09:35:33 »
Ciao,

possono coesistere a patto che alcune cose siano gestite solo da PLESK.

Io sono anni che li utilizzo entrambi in questo modo: PLESK per la gestione dei domini e dei database, in pratica tutto quanto deve fare PLESK (la posta non la uso su plesk, cioè è su server dedicati alla posta, ma se la usassi sarebbe PLESK a gestirla), mentre WEBMIN lo adopero solo per consultare i processi in corso, per riavviare servizi, per il comodo file manager stile windows e anche per aggiornare il server.

Oltre a queste poche funzioni (ma utili per me), non mi arrischio oltre per evitare di entrare in conflitto con PLESK che in fondo è un software "delicato" che se si incasina è meglio cambiare server (o formattare tutto e ricaricare) piuttosto che metterci una pezza!

Mi piacerebbe leggere anche considerazioni di altri...

Buon lavoro!

Pagine: [1] 2 3 ... 5