SME 7.5.1 - Problème avec ''Software Updater''

[HP77]

Bonjour,

C'est encore moi...

Depuis quelques temps, je reçois des e-mails m'informant que des mises à jour sont disponibles pour mon serveur SME 7.5.1 à la maison (celui-ci est derière une "Box", pas dans un campus...

Très bien, merci à admin@MonServeur de m'envoyer un e-mail à chaque fois MAIS voilà, lorsque j'ouvre une session Admin avec Server-Manager, il ne m'indique rien du tout à mettre à jour... Juste que je peux changer les "settings" de la vérification que j'ai paramétré à "Daily" sans gestion indépendante des packages (là, j'aurais bien quelques questions sur ce point également mais, on verra par la suite ).

Bon, comme j'ai une tendance naturelle à ramasser les ennuis informatique depuis quelques temps, je vais dire que cela ne concerne que moi mais, bon, si je ne suis pas le seul, ça reservira.


Les infos utiles :
- e-mail reçu :

===
=== yum reports available updates:
===

lvm2.i386 2.02.42-5.el4_8.4 updates
setup.noarch 2.5.37-4.el4_8.1 updates
tcsh.i386 6.13-10.el4_8.1 updates

- Ce que je vois sous SME :

Software installer
This system is up to date.
All updates have been installed.
════════════════════════════════════
Check for updates Enabled
Manage individual packages Disabled
Change software installer settings
══════════════════════════════════════════════════════════════════════════

SME Server 7.5.1
Copyright 1999-2006 Mitel Corporation
All rights reserved.


Copyright 2006 SME Server, Inc.https://localhost/server-manager/cgi-bi ... FIGURATION

- puis, si je je veux changer les "Settings" :

Software installer

Check for updates [Daily___]
The software installer can manage groups of related package or individual packages. By default, only groups of packages are presented.
If you wish to manage individual packages, enable this option. This should only be done by experienced administrators.
Manage individual packages [Disabled]
The software installer can install software from any of enabled repositories. To enable a repository, select it from the list. To
disable a repository, de-select it from the list. By default, only stable, tested software is available for installation.
[X] CentOS - os
[X] CentOS - updates
[X] SME Server - addons
Enabled repositories [X] SME Server - extras
[X] SME Server - os
[X] SME Server - updates
[ ] SME Server - updates testing

[ Save ]

SME Server 7.5.1
Copyright 1999-2006 Mitel Corporation
All rights reserved.
Copyright 2006 SME Server, Inc.


Select field, name yum_check4updates

- Enfin, j'utilise PuTTY pour accéder à mon serveur depuis le boulot => Y a-t-il un moyen de nettoyer le cache de Elinks et surtout, ou se cache le cache sur SME ? (pas encore trouvé)
Si ça se trouve c'est un bête problème de cache car j'ai souvent besoin de quitter Elinks et de me "re-loguer" pour voir si les changements demandés ont été appliqués ou non (redirection de ports, à tous les coups j'y ai droit... )

- J'ajouterais aussi ceci :

PuTTY releqse 0.60 - 1997-2007 (R) Simon Tatham...

Voilà tout ce qu'il me vient à l'esprit lors de cette rédaction.


Cordialement,
HP

[bethebeast]

Salut,

Personnellement, j'ai jamais eu ce type de "contradiction".

Mais comme SME est basée sur CentOS, c'est ton jour de chance

Dans un terminal, essaie ceci :

Code: Tout sélectionner

# yum clean all && yum update

Ceci va vider le cache de Yum et vérifier de nouveau les MàJ en rapatriant la dernière liste des packages dsipo.

Pour ce qui est de Elinks, je ne sais pas s'il peut être en cause. J'essaierai d'abord avec la commande citée plus haut, ensuite, si le "problème" persiste., on avisera...

D'ailleurs, il me semble que Elinks est configuré pour "cacher" les pages visitées. Pour y remédier, c'est comme d'hab => les templates.

@+

[HP77]

Hello,

...
Mais comme SME est basée sur CentOS, c'est ton jour de chance

que veux-tu dire par là ?? Je m'attendais une histoire de bugtracking tout a propos...

Dans un terminal, essaie ceci :

Code: Tout sélectionner

# yum clean all && yum update

Ceci va vider le cache de Yum et vérifier de nouveau les MàJ en rapatriant la dernière liste des packages dsipo.

Ok, c'est en cours mais j'ai préféré faire ainsi :

Code: Tout sélectionner

# script
# yum clean all && yum update

Par contre, est-ce que "script" a une limitation de taille de fichier ? ??

...
Pour ce qui est de Elinks, je ne sais pas s'il peut être en cause. J'essaierai d'abord avec la commande citée plus haut, ensuite, si le "problème" persiste., on avisera...

Ok The Beast !

...
D'ailleurs, il me semble que Elinks est configuré pour "cacher" les pages visitées. Pour y remédier, c'est comme d'hab => les templates.

Pas glop !

Merci pour la commande Yum, je laisse tourner et on verra le résultat après.

Cordialement,
HP

[HP77]

Bonjour,

Les mises à jour semblent avoir été faites correctement grâce aux commandes indiquées.
Merci pour le tuyau, ça aide.

Maintenant, le problème persiste... Je reçois toujours des e-mails d'alertes sans que les-dites mises à jour ne soient disponibles depuis l'interface "Ad Hoc" de Server-Manager...

Que pourrait-on y faire pour éviter de passer en ligne de commande SSH et tapper les commandes "à la mano" ?


Autrement, juste pour info, ceci ne concerne que mon serveur à la maison, lequel fonctionne en mode 'Server & Gateway' placé dans la DMZ d'une "Box" (depuis plus de 8 mois maintenant).

Mon serveur au boulot, lui, fonctionne en mode 'Private Server Only' et doit passer le firewall du campus pour accéder à Internet. Je ne sais pas si ça pause un problème ou bien si le mode "Private Server Only" a une incidence mais je n'ai point vu d'e-mail "From: admin@Mon.Serveur To admin@Mon.Serveur" (donc, qui devraient exister dans la boîte e-mail Admin comme certaines erreurs "PostMaster" et cie liées au fait que le port 25 est bloqué vers l'extérieur du campus) alertant sur les mises à jour...
Bon, on verra ça plus tard, c'est l'affaire d'un autre sujet à créer sur le forum s'il n'existe pas encore.


Cordialement,
HP

[bethebeast]

Salut

Par hasard, est ce que c'est toujours les mêmes MàJ proposées ou pas ?

Si c'est le cas, je pense que le mail en question doit bloquer dans la file d'attente, ou ya une sorte de boucle.

Dans le cas contraire, faudrait vérifier les entêtes (complètes) du mail, et/ou voir s'il ny a pas un bout de cron templatisé qui traîne quelque part... (vraiment au pif là).

Ton problème m'intrigue...

Personnellement, j'ai pas encore eu ce type de phénomène paranormal...

J'ai désactivé la vérification des MàJ.

Tiens nous au courant.

@+

PS : essaie de vérifier les logs au moment où tu reçois le mail, genre :

Code: Tout sélectionner

/var/log/sqsmtpd/current
/var/log/cron
/var/log/qmail/current
...

[HP77]

Hello,

...
Par hasard, est ce que c'est toujours les mêmes MàJ proposées ou pas ?

Non, pas les mêmes.
Là, j'avais un e-mail à propos d'un "truc" nommé "...freetype...", quelque chose dans ce genre-là.
J'ai un peu honte car je n'ai pas cherché à en savoir plus sur ce machin-là.
Il y a tellement d'éléments logiciels sur SME (et pire encore quand une "distro" embarque un gestionaire de bureau et autres suites logicielles...) que je n'ai fait qu'appliquer la mise à jour (habitudes "Windozienne"... tu cliques, re-cliques, re-re-cliques... ; re-boot, re-re-boot... etc... )

...
Si c'est le cas, je pense que le mail en question doit bloquer dans la file d'attente, ou ya une sorte de boucle.

Dans le cas contraire, faudrait vérifier les entêtes (complètes) du mail, et/ou voir s'il ny a pas un bout de cron templatisé qui traîne quelque part... (vraiment au pif là).

Ton problème m'intrigue...

Me too !

Je croît pas au cron envouté (même si c'est le 7ème mois du calendrier Chinois où il paraît que les fantômes sont de sortie depuis hier minuit (...) quote="bethebeast"]thebeast"]...
Personnellement, j'ai pas encore eu ce type de phénomène paranormal... [/quote]
Je doute du paranormal, mon problème ayant démarré avant la sortie des fantômes Chinois...

...
PS : essaie de vérifier les logs au moment où tu reçois le mail, genre :

Code: Tout sélectionner

/var/log/sqsmtpd/current
/var/log/cron
/var/log/qmail/current
...

On va tenter mais, je ne sais pas si je verrais quelque chose car je lis mes e-mails (persos, pas ceux sur le serveur) que quand j'ai le temps, parfois plusieurs jours après l'apparition de la mise à jour...
Bref, c'est pour ça que j'aurait voulu voir les choses sur Server-?anager que je consulte plus fréquemment pour surveiller la température de la machine de test et les ressources consommées, principalement.

Je vais tenter mon possible.

Merci bien The Beast,
A++
HP

[bethebeast]

Bon, on va arrêter les boules de cristal...

Que donne cette commande (poste le résultat) :

Code: Tout sélectionner

# check4updates 

C'est elle qui vérifie quotidiennement la présence (ou non) des MàJ; et qui envoie le résultat (positif) par mail.

Si elle ne donne rien, vérifier qu'il n-y-a aucun mail dans la file d'attente.

Si c'est positif, poster le résultat de ceci :

Code: Tout sélectionner

# yum clean all && yum update

Pour infos :

L'entrée crontab :

Code: Tout sélectionner

02 4 * * * root /sbin/e-smith/check4updates -m

Je sais pas à quoi correspond l'option "m", si quelqu'un peut me l'expliquer...

Le template :

Code: Tout sélectionner

{
    return "\n# yum check for updates is disabled\n" unless $yum{status} eq 'enabled';

    my $freq = $yum{check4updates} || 'daily';

    if ($freq eq 'weekly') {
        return "\n22 4 * * 0 root /sbin/e-smith/check4updates -m\n";
    } elsif ($freq eq 'monthly') {
        return "\n42 4 1 * * root /sbin/e-smith/check4updates -m\n";
    } else {
        return "\n02 4 * * * root /sbin/e-smith/check4updates -m\n"
    }
}

Qui se trouve ici :

Code: Tout sélectionner

/etc/e-smith/templates/etc/crontab/

@+

[jibe]

Salut,

J'ai lu rapidement et en diagonale

La première chose à tenter, en cas de problèmes avec les mises à jour, c'est :

Code: Tout sélectionner

signal-event post-upgrade
signal-event reboot

Selon les bizarreries constatées, et de toutes manières ça ne peux pas faire de mal, il peut être utile d'ajouter préalablement (ou après, mais en suivant par un nouveau reboot) :

Code: Tout sélectionner

signal-event console-save

Bon, ayant lu vite, je ne sais pas si c'est la solution ici, en tous cas, ça permet de partir sur de bonnes bases si certaines mises à jour n'ont pas été menées totalement à bout pour une quelconque raison (et cela ne se voit pas toujours, même rarement !). C'est ce que je tente en premier, à tout hasard, dès que j'ai des trucs bizarres. Ça les résout souvent...

[HP77]

Bonjour The Beast,

Bon, on va arrêter les boules de cristal...

Désolé d'avoir réveillé la bête...

Que donne cette commande (poste le résultat) :

Code: Tout sélectionner

# check4updates 

C'est elle qui vérifie quotidiennement la présence (ou non) des MàJ; et qui envoie le résultat (positif) par mail.

La commande semble s'exécuter (plus d'invite shell pendant quelques secondes... Mais comment en être vraiment sûr ?) mais n'affiche rien à l'écran au final.

Tiens, je vais chercher ce script dans le système (je pense script PERL ou autre car pas de page de manuel (je sais, c'est un peu stupide de ma part... ))

...
Si elle ne donne rien, vérifier qu'il n-y-a aucun mail dans la file d'attente.

J'y verrais peut-être plus clair en mettant le nez dans le script check4updates sinon, je te demanderais où trouver plus d'informations sur la "queue" d'attente.

...
Si c'est positif, poster le résultat de ceci :

Code: Tout sélectionner

# yum clean all && yum update

Pour infos :

L'entrée crontab :

Code: Tout sélectionner

02 4 * * * root /sbin/e-smith/check4updates -m

Je sais pas à quoi correspond l'option "m", si quelqu'un peut me l'expliquer...

Le template :

Code: Tout sélectionner

{
    return "\n# yum check for updates is disabled\n" unless $yum{status} eq 'enabled';

    my $freq = $yum{check4updates} || 'daily';

    if ($freq eq 'weekly') {
        return "\n22 4 * * 0 root /sbin/e-smith/check4updates -m\n";
    } elsif ($freq eq 'monthly') {
        return "\n42 4 1 * * root /sbin/e-smith/check4updates -m\n";
    } else {
        return "\n02 4 * * * root /sbin/e-smith/check4updates -m\n"
    }
}

Qui se trouve ici :

Code: Tout sélectionner

/etc/e-smith/templates/etc/crontab/

@+

Je te remercie pour ces informations détaillées, je vais jeter un oeil "illico presto".

Cordialement,
HP



P.S.
Une recherche basique avec check4updates m'a donné ceci :
- what's running check4updates?
- Bug 4169 - check4updates script error
J'ai vaguement apperçu un problème lié à une double instance de yum, peut-être ,ieux que je désactive les mises à jour automatiques la prochaine fois que j'installe une contribution...

[HP77]

Bonjour Jibé,

...
J'ai lu rapidement et en diagonale

Pas de problème, tu es tout excusé.
(pour le moment car si je "tue" mon serveur avec ce que tu me conseilles, il en sera autrement )

...
La première chose à tenter, en cas de problèmes avec les mises à jour, c'est :

Code: Tout sélectionner

signal-event post-upgrade
signal-event reboot

Selon les bizarreries constatées, et de toutes manières ça ne peux pas faire de mal, il peut être utile d'ajouter préalablement (ou après, mais en suivant par un nouveau reboot) :

Code: Tout sélectionner

signal-event console-save

Bon, ayant lu vite, je ne sais pas si c'est la solution ici, en tous cas, ça permet de partir sur de bonnes bases si certaines mises à jour n'ont pas été menées totalement à bout pour une quelconque raison (et cela ne se voit pas toujours, même rarement !). C'est ce que je tente en premier, à tout hasard, dès que j'ai des trucs bizarres. Ça les résout souvent...

J'ai bien envie d'essayer ça de suite mais, j'aimerais mieux tenter de comprendre ce qui a bien pu se passer ou, à défaut, arriver à en savoir un peu plus sur cette "moulinette".
J''espère que tu ne m'en voudras pas de mettre un délai là-dedans.

Merci pour ta réponse, bone journée à toi aussi !

Cordialement,
HP


P.S.
Faudra que je prenne la peine de vraiment lire la doc écrite sur SME car toutes ces commandes "signal-event", ça me démange un peu d'en voir la liste et les applications.
Bon, là, je dois trouver les plus petits, les moins chers et les plus performants modules GSM du moment => encore des yeux tout rouges à force de lire des quantités de choses le plus souvent peu intéressantes... M'enfin, ça fait aussi partie des "plaisirs" des ingénieurs.

[bethebeast]

Bon...

J'ai trouvé quelques infos :

Ton problèmes semble être signalé comme étant un bug depuis la v7.3. Tu n'est donc pas les seul

Bref,

# Ce que j'aurai voulu voire, c'est le contenu du mail que tu reçois, si tu peux le poster...

# La commande check4updates seule sans options, affiche les MàJ dispos.
check4updates suivie de l'option -m quant à elle, n'affiche rien, mais envoie le résultat (positif) par mail.

# Normalement, il suffit de modifier les propriétés de yum pour résoudre le problème :

Code: Tout sélectionner

config setprop yum check4updates monthly;signal-event yum-modify

Ce qui modifier la fréquence de vérification, du quotidien au mensuel.

Après, comme l'a conseillé jibe :

Code: Tout sélectionner

signal-event console-save ; signal-event post-upgrade ; signal-event reboot

# Sinon, pour vérifier dans la journée si le problème est résolvable (oui je sais...)

On modifie l'heure pendant laquelle check4updates fait son boulot :

Code: Tout sélectionner

/etc/e-smith/templates-custom/etc/crontab/check4updates

On mets ceci :

Code: Tout sélectionner

# vérification de la présence des Màj quotidienne à 13h02 et on envoi le résultat par mail
02 4 * * * root /sbin/e-smith/check4updates -m

Puis :

Code: Tout sélectionner

expand-template /etc/crontab

Et :

Code: Tout sélectionner

signal-event console-save ; signal-event post-upgrade ; signal-event reboot

Juste pour le plaisir...

Sinon, dans le pire des cas, voir les bugs ouverts et/ou en ouvrir un...
http://bugs.contribs.org/buglist.cgi?qu ... ck4updates

Allé, j'attends de tes nouvelles

@+

[unnilennium]

le problème est lié a elink.

Un problème similaire existe quand on modifie les propriétés d'une ibay : elink continue à afficher les premiers paramètres quand on fait de nouveau appel à la page.


Maintenant quand tu passe par la console pour faire une mise a jour il est bien plus simple de faire :

yum update


que :

console
#sélectionner accéder au server manager
# taper le mot de passe après avoir accepté le message
# choisir l'interface
# etc...



Si tu veux absolument passer sur une interface web , installe open vpn fait un tunnel vpn entre ton pc et le sme et accède au manager...

[HP77]

Bon...

J'ai trouvé quelques infos :

Ton problèmes semble être signalé comme étant un bug depuis la v7.3. Tu n'est donc pas les seul

Bref,

# Ce que j'aurai voulu voire, c'est le contenu du mail que tu reçois, si tu peux le poster...

Pas de problème, voici la prose demandée, en direct de Horde (webmail pour le réseau local seulement) :

___________________________________________________________________________

Date: 9 Aug 2010 20:02:20 -0000 [08/10/2010 04:02:20 AM SGT]
Date: 8 Aug 2010 20:02:27 -0000 [08/09/2010 04:02:27 AM SGT]
Date: 7 Aug 2010 20:02:19 -0000 [08/08/2010 04:02:19 AM SGT]
From: ro.ot@hp-ho.me.sg
To: ad.min-yum@hp-ho.me.sg
Subject: Updates available for sme7.5_home

===
=== yum reports available updates:
===

freetype.i386 2.1.9-15.el4.8 updates
___________________________________________________________________________

Date: 4 Aug 2010 20:02:23 -0000 [08/05/2010 04:02:23 AM SGT]
Date: 3 Aug 2010 20:02:30 -0000 [08/04/2010 04:02:30 AM SGT]
Date: 2 Aug 2010 20:02:25 -0000 [08/03/2010 04:02:25 AM SGT]
From: ro.ot@hp-ho.me.sg
To: ad.min-yum@hp-ho.me.sg
Subject: Updates available for sme7.5_home

===
=== yum reports available updates:
===

lvm2.i386 2.02.42-5.el4_8.4 updates
setup.noarch 2.5.37-4.el4_8.1 updates
tcsh.i386 6.13-10.el4_8.1 updates
___________________________________________________________________________

Date: 26 Jul 2010 20:02:21 -0000 [07/27/2010 04:02:21 AM SGT]
Date: 25 Jul 2010 20:02:34 -0000 [07/26/2010 04:02:34 AM SGT]
Date: 23 Jul 2010 20:02:20 -0000 [07/24/2010 04:02:20 AM SGT]
From: ro.ot@hp-ho.me.sg
To: ad.min-yum@hp-ho.me.sg
Subject: Updates available for sme7.5_home

===
=== yum reports available updates:
===

cups-libs.i386 1:1.1.22-0.rc1.9.32.el updates
libpng.i386 2:1.2.7-3.el4_8.3 updates
libtiff.i386 3.6.1-12.el4_8.5 updates
openldap.i386 2.2.13-12.el4_8.3 updates
openldap-servers.i386 2.2.13-12.el4_8.3 updates
openssh.i386 3.9p1-11.el4_8.1 updates
openssh-clients.i386 3.9p1-11.el4_8.1 updates
openssh-server.i386 3.9p1-11.el4_8.1 updates
pam.i386 0.77-66.26.el4_8.2 updates
samba.i386 3.0.33-0.19.el4_8.1 updates
samba-client.i386 3.0.33-0.19.el4_8.1 updates
samba-common.i386 3.0.33-0.19.el4_8.1 updates
strace.i386 4.5.16-1.el4_8.11 updates
___________________________________________________________________________

# La commande check4updates seule sans options, affiche les MàJ dispos.
check4updates suivie de l'option -m quant à elle, n'affiche rien, mais envoie le résultat (positif) par mail.

Dans mon cas actuel, absolument aucun affichage => rien à mettre à jour pour le moment.

# Normalement, il suffit de modifier les propriétés de yum pour résoudre le problème :

Code: Tout sélectionner

config setprop yum check4updates monthly;signal-event yum-modify

Ce qui modifier la fréquence de vérification, du quotidien au mensuel.

Après, comme l'a conseillé jibe :

Code: Tout sélectionner

signal-event console-save ; signal-event post-upgrade ; signal-event reboot

# Sinon, pour vérifier dans la journée si le problème est résolvable (oui je sais...)

Tu sais quoi ?
Moi, je ne sais pas ou alors cùest à cause du français et dans ce cas, je dirais "solvable".

On modifie l'heure pendant laquelle check4updates fait son boulot :

Code: Tout sélectionner

/etc/e-smith/templates-custom/etc/crontab/check4updates

On mets ceci :

Code: Tout sélectionner

# vérification de la présence des Màj quotidienne à 13h02 et on envoi le résultat par mail
02 4 * * * root /sbin/e-smith/check4updates -m

Puis :

Code: Tout sélectionner

expand-template /etc/crontab

Et :

Code: Tout sélectionner

signal-event console-save ; signal-event post-upgrade ; signal-event reboot

Juste pour le plaisir...

Sinon, dans le pire des cas, voir les bugs ouverts et/ou en ouvrir un...
http://bugs.contribs.org/buglist.cgi?qu ... ck4updates

Allé, j'attends de tes nouvelles

@+

Bien merci pour la procédure détaillée.

Maintenant, j'hésite entre...
- laisser comme c'est et attendre la prochaine 1ère annonce de mise à jour pour metre en place et voir la différence lors de la 2ème alerte e-mail
ET
- faire la cuisine, maintenant, selon la recette indiquée et laisser mijoter jusqu'au prochain débordement de la casserole


Dur, dur de décider quand j'ai déjà les allumettes pour tenir les paupières...

Bon, je vais laisser passer une nuit de sommeil pour me porter conseil. Ce sera plus sâge.

Sur ce, bonne fin de journée et merci encore pour cet accompagnement.


Cordialement,
HP

[jibe]

Salut,

Le problème semblant maintenant à peu près cerné, je reviens juste sur ce point :

J'ai bien envie d'essayer ça de suite mais, j'aimerais mieux tenter de comprendre ce qui a bien pu se passer ou, à défaut, arriver à en savoir un peu plus sur cette "moulinette".

Sans rentrer dans les détails, le signal-event post-upgrade doit être lancé après une mise à jour, et suivi d'un reboot du serveur (effectué via un signal-event reboot). Au passage, on peut s'étonner (j'ai plutôt envie d'écrire "se révolter") de cette procédure "à la windows" sur un serveur en prod, mais c'est ainsi. Cela parachève le chargement et l'installation des mises à jour, qui ne se fait pas aussi simplement sur un système comme SME (templates etc.) que sur un linux "normal" comme une CentOS.

Le signal-event console-save, quant à lui, parachève la modification de la configuration. Il est normalement lancé automatiquement en fin de re-configuration via l'option 2 du menu admin.

Ces procédures peuvent avoir été omises, effectuées partiellement, avoir échoué pour une quelconque raison... Bref, il peut être nécessaire dans certains cas de les re-lancer. En effet, si elles n'ont pas été effectuées avec succès (et on ne voit pas toujours de message d'erreur...), le système peut être instable et donc montrer des symptômes bizarres. Relancer ces commandes ramène la stabilité, et n'a aucun inconvénient (si ce n'est celui du reboot )

[unnilennium]

# Sinon, pour vérifier dans la journée si le problème est résolvable (oui je sais...)

Tu sais quoi ?
Moi, je ne sais pas ou alors cùest à cause du français et dans ce cas, je dirais "solvable".

HP

à moins que tu sois un créancier du problème et que tu cherche à le faire payer, je préférerais "possible à résoudre"