[severn]

ho lo stesso problema, plesk 9.5 su centOS 64 bit ed una email all'ora di warning.

Hai risolto Gianpaolo ? Se sì come ? grazie

[Giampaolo]

Aspetta aspetta,i motori di ricerca sono strumenti utilissimi,ma devi comunque guardare quello che trovi nel contesto in cui è scritto

*Li si parla di un bug che riguarda un software che si chiama logwatch,che dopo aver fatto l'update del sistema sembra non inviare più i report via mail (a te invece è proprio il fatto che invia mail il problema)

*Quella che hai letto era un post di una discussione abbastanza lunga dove si ipotizzavano le cause (per la cronaca alla fine hanno concluso che era un problema di Plesk,che "impallava" sendmail) del fatto che logwatch non inviava più mail (anzi per la precisione era sendmail a non funzionare più,visto che logwatch funzionava regolarmente)

*Quello che hai estratto dal testo è un'ipotesi,tra l'altro se guardi il msg successivo,un tizio senza lo script mcelog.cron lamentava lo stesso problema,dunque non è la causa,cmq ti ripeto li il problema è che le mail di report non arrivavano,mentre tu hai il problema opposto

Cerco di farti una rapida "Traduzione" di quello che ho scritto:

Cron esegue comandi al posto di un utente,i "canali" standard di comunicazione in linux sono tre:

StdInput Collegato alla tastiera
StdOutput Collegato al Video
StdError Collegato al Video

Ora la differenza tra StdOut e StdErr è che quest'ultimo visualizza solo quelli che vengono classificati come messaggi di errore da parte di un programma.

Tali "Canali" standard possono essere redirezionati in diversi modi,tra cui quello di utilizzare l'operatore >>

per esempio se fai "ls >> prova" invece di visualizzare a video il risultato del comando ls,lo memorizza nel file "prova",questo perchè hai redirezionato lo StdOut di "ls" verso il file "prova".

Con Cron è lo stesso,quando esegue il comando alla data ora del dato giorno,tutto quello che compare a video viene inviato dal demone cron all'indirizzo mail dell'utente per conto del quale cron esegue il comando.

quando nel tuo file cron,lo script esegue:

/usr/sbin/mcelog --ignorenodev --filter >> /var/log/mcelog

esegue mcelog e redireziona il suo StdOut verso il file mcelog,in modo che cron non generi una mail contenente l'output di mcelog,ma,fa attenzione,non redireziona lo StdErr,sul quale giunge il messaggio di warning,ecco perchè a te arriva la mail,se redirezionassi anche lo StdErr verso un file,quella mail non ti arriverebbe più,cmq questo non vorrebbe dire che mcelog funzioni correttamente.

Spero di essere stato abbastanza comprensibile,sono stupidate,più facili da fare che da scrivere,comunque se cerchi documentazione sull'StdIN,l'stdOUT e l'stdERR probabilmente ste cose so scritte meglio

Sei di un'altra categoria! Grazie!

[Liftoff]

Premesso che di quello che mi hai scritto non ci ho capito praticamente nulla , sul link che ho postato si legge...

The "xen" kernel with Centos 5.4 may have bug. The system keeps adding load average (adding by 1 hourly), and when the number goes to 64, sendmail fails sending/receiving email.

What I did is: delete "mcelog.cron" from "/etc/cron.hourly" and rebooted my server . You may also load a kernel without "xen".

... che ne pensi?
Ciao, grazie

Aspetta aspetta,i motori di ricerca sono strumenti utilissimi,ma devi comunque guardare quello che trovi nel contesto in cui è scritto

*Li si parla di un bug che riguarda un software che si chiama logwatch,che dopo aver fatto l'update del sistema sembra non inviare più i report via mail (a te invece è proprio il fatto che invia mail il problema)

*Quella che hai letto era un post di una discussione abbastanza lunga dove si ipotizzavano le cause (per la cronaca alla fine hanno concluso che era un problema di Plesk,che "impallava" sendmail) del fatto che logwatch non inviava più mail (anzi per la precisione era sendmail a non funzionare più,visto che logwatch funzionava regolarmente)

*Quello che hai estratto dal testo è un'ipotesi,tra l'altro se guardi il msg successivo,un tizio senza lo script mcelog.cron lamentava lo stesso problema,dunque non è la causa,cmq ti ripeto li il problema è che le mail di report non arrivavano,mentre tu hai il problema opposto

Cerco di farti una rapida "Traduzione" di quello che ho scritto:

Cron esegue comandi al posto di un utente,i "canali" standard di comunicazione in linux sono tre:

StdInput Collegato alla tastiera
StdOutput Collegato al Video
StdError Collegato al Video

Ora la differenza tra StdOut e StdErr è che quest'ultimo visualizza solo quelli che vengono classificati come messaggi di errore da parte di un programma.

Tali "Canali" standard possono essere redirezionati in diversi modi,tra cui quello di utilizzare l'operatore >>

per esempio se fai "ls >> prova" invece di visualizzare a video il risultato del comando ls,lo memorizza nel file "prova",questo perchè hai redirezionato lo StdOut di "ls" verso il file "prova".

Con Cron è lo stesso,quando esegue il comando alla data ora del dato giorno,tutto quello che compare a video viene inviato dal demone cron all'indirizzo mail dell'utente per conto del quale cron esegue il comando.

quando nel tuo file cron,lo script esegue:

/usr/sbin/mcelog --ignorenodev --filter >> /var/log/mcelog

esegue mcelog e redireziona il suo StdOut verso il file mcelog,in modo che cron non generi una mail contenente l'output di mcelog,ma,fa attenzione,non redireziona lo StdErr,sul quale giunge il messaggio di warning,ecco perchè a te arriva la mail,se redirezionassi anche lo StdErr verso un file,quella mail non ti arriverebbe più,cmq questo non vorrebbe dire che mcelog funzioni correttamente.

Spero di essere stato abbastanza comprensibile,sono stupidate,più facili da fare che da scrivere,comunque se cerchi documentazione sull'StdIN,l'stdOUT e l'stdERR probabilmente ste cose so scritte meglio

[Giampaolo]

Si aspetta ma questo non c'entra con il tuo problema (li si parla di logwatch),a te il msg te lo invia crontab,perchè mcelog va a scrivere sul stderr,mentre lo stdoutput è redirezionato verso il file /var/log/mcelog attraverso l'operatore >>,sono due cose diverse Imho

Premesso che di quello che mi hai scritto non ci ho capito praticamente nulla , sul link che ho postato si legge...

The "xen" kernel with Centos 5.4 may have bug. The system keeps adding load average (adding by 1 hourly), and when the number goes to 64, sendmail fails sending/receiving email.

What I did is: delete "mcelog.cron" from "/etc/cron.hourly" and rebooted my server . You may also load a kernel without "xen".

... che ne pensi?
Ciao, grazie

[Liftoff]

Interessante...
http://bugs.centos.org/view.php?id=3942
Ciao

Si aspetta ma questo non c'entra con il tuo problema (li si parla di logwatch),a te il msg te lo invia crontab,perchè mcelog va a scrivere sul stderr,mentre lo stdoutput è redirezionato verso il file /var/log/mcelog attraverso l'operatore >>,sono due cose diverse Imho

[Giampaolo]

Ho dato un'occhiata veloce alla pagina del link,in particolare è interessante la discussione che si è sviluppata nella parte finale del documento,se ho capito bene c'è un mismatch tra la struttura "mce" definita nei sorgenti del programma e quella definita nei sorgenti del Kernel di linux,qualcuno sembra aver risolto modificando i sorgenti del programma andando a "sbirciare" i sorgenti della versione del Kernel che usa,ricompilando poi il programma con le modifiche apportate.

Non so come funziona con CentOS,ma almeno per debian alcuni repository (ma non tutti) sono macchine Ovh,però non so se sono semplici mirror o qualcosa di più.

Interessante...
http://bugs.centos.org/view.php?id=3942
Ciao

[Liftoff]

Grazie per i consigli, li seguirò alla lettera partendo da qui! Alla pagina che mi hai indicato mi ci sono già imbattuto ieri... è che , non ci ho capito granchè!
Ciao

EDIT: Repository OVH? Dove???

Ho dato un'occhiata veloce alla pagina del link,in particolare è interessante la discussione che si è sviluppata nella parte finale del documento,se ho capito bene c'è un mismatch tra la struttura "mce" definita nei sorgenti del programma e quella definita nei sorgenti del Kernel di linux,qualcuno sembra aver risolto modificando i sorgenti del programma andando a "sbirciare" i sorgenti della versione del Kernel che usa,ricompilando poi il programma con le modifiche apportate.

Non so come funziona con CentOS,ma almeno per debian alcuni repository (ma non tutti) sono macchine Ovh,però non so se sono semplici mirror o qualcosa di più.

[Giampaolo]

Bah non so se si può fare,ma in genere credo che non sia una buona idea affidarsi a repository non official (ovviamente la cosa cambia se il repository è messo a disposizione del fornitore da cui hai preso il server,tipo come fa Ovh).

L'ultima spiaggia in genere è quella di ricompilare/configurare il software a mano,non è detto che questo debba essere fatto necessariamente sulla macchina dove il software andrà a girare.

Il problema è che la ricompilazione a volte (ma non sempre) può essere un'operazione molto complicata,specie se il software usa librerie condivise,a quel punto si porta dietro tante cose (le librerie devono essere tutte installate e avere una versione compatibile con quella del soft).....

Oppure se sei fortunato quelli del software di tuo interesse mettono a disposizione lo stesso sottoforma già di pachetto,ed a quel punto se il pachetto è compatibile con la tua distribuzione "salti" un bel pò di sbattimento.

Bah io lascerei perdere i manualoni per ora,Imho mi procurerei qualche documento non troppo complesso dove si parla di Linux (preferibilmente non vincolato a nessuna distribuzione),concetti di base,tipo com'è organizzato il filesystem,il sistema di logging (fondamentale per capire cosa succede nel sistema) etc.

Una volta presa confidenza con il sistema ti accorgerai che in linux l'unica cosa che non manca è la disponibilità di documentazione.

Prova un pò a vedere sul sito del Linux Documentation Project,forse trovi qualcosa che t'interessa.

Ps:
Qui ho trovato qualcosa che ti può essere utile:

https://bugzilla.redhat.com/show_bug.cgi?id=507026

Grazie per i consigli, li seguirò alla lettera partendo da qui! Alla pagina che mi hai indicato mi ci sono già imbattuto ieri... è che , non ci ho capito granchè!
Ciao

EDIT: Repository OVH? Dove???

[Liftoff]

Quindi potrebbe esserci una versione di Mcelog più nuova della mia che non è però presente nei default Repository di CentOS, dico bene?
Se è così e volessi installarla comunque (nel mio caso con Yum) sarebbe proprio il caso che mi hai portato come esempio, giusto? Dovrei aggiungere altri Repository, riprovare con Yum e fare gli scongiuri?

P.S.: dove trovo un bel manualone .pdf in italiano di CentOS 5.4 e/o della basi di GNU/Linux?

Bah non so se si può fare,ma in genere credo che non sia una buona idea affidarsi a repository non official (ovviamente la cosa cambia se il repository è messo a disposizione del fornitore da cui hai preso il server,tipo come fa Ovh).

L'ultima spiaggia in genere è quella di ricompilare/configurare il software a mano,non è detto che questo debba essere fatto necessariamente sulla macchina dove il software andrà a girare.

Il problema è che la ricompilazione a volte (ma non sempre) può essere un'operazione molto complicata,specie se il software usa librerie condivise,a quel punto si porta dietro tante cose (le librerie devono essere tutte installate e avere una versione compatibile con quella del soft).....

Oppure se sei fortunato quelli del software di tuo interesse mettono a disposizione lo stesso sottoforma già di pachetto,ed a quel punto se il pachetto è compatibile con la tua distribuzione "salti" un bel pò di sbattimento.

Bah io lascerei perdere i manualoni per ora,Imho mi procurerei qualche documento non troppo complesso dove si parla di Linux (preferibilmente non vincolato a nessuna distribuzione),concetti di base,tipo com'è organizzato il filesystem,il sistema di logging (fondamentale per capire cosa succede nel sistema) etc.

Una volta presa confidenza con il sistema ti accorgerai che in linux l'unica cosa che non manca è la disponibilità di documentazione.

Prova un pò a vedere sul sito del Linux Documentation Project,forse trovi qualcosa che t'interessa.

Ps:
Qui ho trovato qualcosa che ti può essere utile:

https://bugzilla.redhat.com/show_bug.cgi?id=507026

[Giampaolo]

Allora... il codice che genera il warning che arriva via eMail è questo

#!/bin/bash

if [ -e /proc/xen ] && [ `cat /sys/hypervisor/uuid` != "00000000-0000-0000-0000-000000000000" ]; then
        # this is a PV Xen guest.  Do not run mcelog.
        exit 1;
else
        /usr/sbin/mcelog --ignorenodev --filter >> /var/log/mcelog
fi

Mi aiutate a capire?
Grazie

Mi aiutate a capire?
Grazie

[Giampaolo]

... intanto sto studiando Cron/Crontab ed ho appena trovato - forse - il modo di non fargli più mandare l'eMail dello stesso warning ad ogni santissima ora!

Funziona!!!

[Giampaolo]

Ed un giorno ti scontrerai immancabilemnte con la necessità di dover aggiungere per forza l'ultima versione di un software,e li si balla

Quindi potrebbe esserci una versione di Mcelog più nuova della mia che non è però presente nei default Repository di CentOS, dico bene?
Se è così e volessi installarla comunque (nel mio caso con Yum) sarebbe proprio il caso che mi hai portato come esempio, giusto? Dovrei aggiungere altri Repository, riprovare con Yum e fare gli scongiuri?

P.S.: dove trovo un bel manualone .pdf in italiano di CentOS 5.4 e/o della basi di GNU/Linux?

[Liftoff]

Quando tento di aggiornare Mcelog, CentOS dice che è già aggiornato...

Guarda non so come funziona CentOS,ho usato solo Debian ed in un passato remoto la Slackware,però se l'update del sistema/applicazione è basato sui repository,fin quando chi gestisce la distribuzione "stabile" non decide di inserire la nuova update di un software nel repository,la tua distribuzione non lo sa.......

Ed un giorno ti scontrerai immancabilemnte con la necessità di dover aggiungere per forza l'ultima versione di un software,e li si balla

Giusto per rimanere in tema,qualche giorno fa ho dovuto scaricare e "costruire" il pacchetto .deb dell'ultima versione della Sun JVM perchè quella del repository era un pò vecchiotta ed usandola con un software c'era il rischio di un potenziale exploit per far eseguire codice arbitrario

Ciao, e grazie!

e de che

[Giampaolo]

Uhm guarda che è solo un warning,ergo non un errore vero e proprio,si trova con una lunghezza di record (vai a capì esattamente di che dato/variabile si tratta) più lunga di quella che si aspetta,e ti suggerisce di considerare l'update,di mcelog suppongo

Non ho idea di come si faccia l'update su un sistema CentOS,tra l'altro non uso neanche sistemi a 64 bit,ai quali mcelog è destinato.

Non sapevo che Mcelog fosse solo per architetture a 64bit! Quando tento di aggiornare Mcelog, CentOS dice che è già aggiornato... intanto sto studiando Cron/Crontab ed ho appena trovato - forse - il modo di non fargli più mandare l'eMail dello stesso warning ad ogni santissima ora!
Ciao, e grazie!

[Liftoff]

/etc/cron.hourly/mcelog.cron:

mcelog: warning: record length longer than expected. Consider update.

Uhm guarda che è solo un warning,ergo non un errore vero e proprio,si trova con una lunghezza di record (vai a capì esattamente di che dato/variabile si tratta) più lunga di quella che si aspetta,e ti suggerisce di considerare l'update,di mcelog suppongo

Non ho idea di come si faccia l'update su un sistema CentOS,tra l'altro non uso neanche sistemi a 64 bit,ai quali mcelog è destinato.

[Giampaolo]

Allora... il codice che genera il warning che arriva via eMail è questo

#!/bin/bash

if [ -e /proc/xen ] && [ `cat /sys/hypervisor/uuid` != "00000000-0000-0000-0000-000000000000" ]; then
        # this is a PV Xen guest.  Do not run mcelog.
        exit 1;
else
        /usr/sbin/mcelog --ignorenodev --filter >> /var/log/mcelog
fi

Mi aiutate a capire?
Grazie

[Giampaolo]

devi aggiornare

Aggiornare cosa? Con quale comando?

[gio01]

devi aggiornare

[Giampaolo]

Buon per te

Dopo l'installazione mi arriva, ogni ora, questa eMail...

/etc/cron.hourly/mcelog.cron:

mcelog: warning: record length longer than expected. Consider update.

... chevvordì? Come si sistema???

[gio01]

Buon per te

[Giampaolo]

Congratulations!
Plesk has been successfully installed on your server.

[gio01]

installa

 the "libc.so.6" dependency.
    The "glibc-2.5-34.el5_3.1.i686" package resolves "libc.so.6".

Quindi guarda i pacchetti del warning ed instalalli

[Giampaolo]

Allora, ci ho provato...

... installo la CentOS 5.4 64bit OVH e seguo alla lettera il tutorial dal sito Parallels...

   1. Download the latest version of Parallels Products Installer that suits your operating system from http://www.parallels.com/en/download/plesk9/ and save it on your server's hard drive.
   2. Change your working directory to the directory where the downloaded Parallels Products Installer is located.
   3. Set the execution permission for Parallels Products Installer:

      # chmod +x parallels_products_installer_file_name

   4. Run the following command in console:

      #export LANG=C
      #export LANG_ALL=C

   5. Run Parallels Products Installer:

          * To install Parallels Plesk Panel through the web interface of Parallels Products Installer, run the following command:

            # ./parallels_products_installer_file_name --web-interface

            Open your browser and enter https://hostname:8447/ or https://IP-address:8447/ in the address bar. The Parallels Product Installer web interface will open. Log in as root.

... dall'interfaccia Web seleziono la 9.2.3 in versione Typical ma, qualcosa non va, di seguito il log...

Determining the packages that need to be installed.
Warning: unresolved requires 'sgpio' from dmraid-events-1.0.0.rc13-53.el5.x86_64
Warning: unresolved requires 'nash = 5.1.19.6-54' from mkinitrd-5.1.19.6-54.x86_64
Warning: unresolved requires 'glibc-common = 2.5-18.el5_1.1' from glibc-2.5-18.el5_1.1.x86_64
Warning: unresolved requires 'glibc-common = 2.5-34' from glibc-2.5-34.x86_64
Warning: unresolved requires '/usr/bin/fipscheck' from fipscheck-lib-1.2.0-1.el5.x86_64
Warning: unresolved requires 'glibc-headers = 2.5-42' from glibc-devel-2.5-42.x86_64
Unhappy catched; try to resolve again.
The requested package "psa-drweb-configurator" could not be installed.
Searching problems for the "psa-drweb-configurator" package.
    No suitable solutions were found for the "libc.so.6" dependency.
    The "glibc-2.5-34.el5_3.1.i686" package resolves "libc.so.6".
Could not add package glibc-2.5-34.el5_3.1.i686to the list of required packages.Problem occured during searching directly resolved dependencies for 'libc.so.6' of package psa-drweb-configurator-9.2.3-cos5.build92091016.19.x86_64 ERROR: Unable to install the "psa-drweb-configurator-9.2.3-cos5.build92091016.19.x86_64" package.
Not all packages were installed.
Please, contact product technical support.

... chi mi aiuta???
Ciao, grazie

[Giampaolo]

Qualcuno lo ha già fatto? Qualche dritta?
Ciao, grazie