logs IPCop 1.4.5 sur ttty1

[fgth]

Salut tout le monde,
il m'arrive un truc que j'en perds mon latin. Et que je ne le retrouve pas dans les réponses aux posts du forum.
Alors, voilà l'histoire.
J'avais un peu de retard dans mes mises à jours IPCop (oui, je sais : honte), alors hier soir j'ai chargé coup sur coup la 1.4.3, .4 et .5 !
Tout a l'air ok, jusqu'à ce que je m'apercçoive ce matin que mes journaux de pare-feu étaient vides.
Un coup d'oeil à /var/log/messages : effectivement, il y a les messages courants (fcron, dnsupdate, ...) mais plus un seul message d'iptables ! Le firewall a l'air de tourner, un iptables -L et un test sur grc.com me disent que : OK.
Je ne vois rien de changé au rc.firewall (qui date de septembre 2004), rien non plus au syslogd.conf. J'ai tenté de forcer kern.* sur /var/log/messages : pas mieux !
Et là, la 3ème dimension : en désespoir de cause, j'extrais mon PC IPCop de sa grotte ) et je branche un écran.
Mes messages sont là ! sur tty1 ! Et tty12 voit bien les autres messages, conformément à ce qui est dit dans syslogd.conf...
Mais tty1 ??? Je n'ai trouvé nulle part de conf qui y fait référence.
Alors : késkispass ?
Est-ce que la mise à jour du noyau dans la 1.4.4 pourrait être suspecte ?

Merci de vos suggestion.

[fgth]

Ah d'accord je corrige : en fait les messages s'affichent sur la console active : si je passe sur tty2, au bout d'un moment ils arrivent à l'écran.
Donc : affichage sur la console par défaut. Mais pourquoi ?

[fgth]

Un peu comme si iptables ne faisait plus appel à syslogd ? Mmmm ?

[fgth]

J'avance, j'avance, mais je ne sais pas où je vais.
dmesg me renvoie tout les messages iptables, qui sont visibles aussi dans /proc/kmsg (dmesg y piocherait-il ses informations ?). Mais toujours rien dans messages...
Au fait, ça n'est pas klogd qui est sensé gérer les messages du noyau ?

[fgth]

Bon je continue à me répondre.
J'étais pas mal avec mon idée de klogd. J'ai finalement trouvé ça dans le fouillis des messages de boot d'IPCop :

Apr 7 08:48:09 systear1 kernel: klogd 1.4.1, log source = /proc/kmsg started.
Apr 7 08:48:09 systear1 kernel: Inspecting /boot/System.map-2.4.29
Apr 7 08:48:10 systear1 kernel: Loaded 11714 symbols from /boot/System.map-2.4.29.
Apr 7 08:48:10 systear1 kernel: Symbols match kernel version 2.4.29.
Apr 7 08:48:10 systear1 kernel: Loaded 250 symbols from 12 modules.
Apr 7 08:48:10 systear1 kernel: klogd: failed to drop root
Apr 7 08:48:10 systear1 kernel: Kernel logging (proc) stopped.
Apr 7 08:48:10 systear1 kernel: Kernel log daemon terminating.

OK. Donc klogd ne démarre pas, donc il n'envoie rien à syslogd : CQFD.
Maintenant, je crois que j'étais pas mal non plus avec mon idée sur la mise à jour du noyau par la 1.4.3 : il va chercher System.map-2.4.29. Doit-on chercher là-dedans la raison qui le fait se planter ?...
Que signifie "failed to drop root" ?

A suivre.

[fgth]

Ooooooook.
Le démarrage de klogd se trouve dans rc.sysinit : "/usr/sbin/klogd -u klogd -j empty".
A priori, on se dit comme ça : -u, ça serait bien pour "user".
On retire donc -u klogd, et le bidule nous insulte en nous disant plus ou moins "-j pas possible si pas -u". Bon d'accord. On enlève donc tout, et un "/usr/sbin/klogd" tout seul démarre impec'. Les logs sont à nouveau dans log/messages.

On avance !!!

Maintenant pourquoi "-u" ? D'autres distros (j'ai regardé un Mandrake, une Fedora et même une Debian) démarrent simplement klogd en root sans se poser de questions. Je comprends bien que sur une distro comme notre cher IPCop, il y ait un minimum de sécurité, et que les démons ne démarrent pas forcément en root. Mais pourquoi ça marchait avant les mises à jour et plus maintenant ???
Ben voilà : l'utilisateur klogd n'existe pas. Yanapa dans etc/passwd. Pourtant le fichier n'a pas bougé non plus (du moins, sa date). Alors ?
Une re-création du user klogd suffit à ce que le démon soit content et démarre. Allélouïa (à propos, vous savez que le pape est mort ? Bon je déconne. Mais heureusement que le petit prince est venu mettre son grain de sable, sinon on en aurait bouffé 24/24 depuis 15 jours, du JP2) Excusez-moi, je suis content d'avoir trouvé, je me lâche un peu.

Bref. LA question est donc : comment ça marchait avant. Est-ce que certains pourraient comparer leur rc.sysinit pour me dire si la ligne de commande est la même, et leut etc/passwd pour voir si l'utilisateur klogd existe ? Et ces certains pourraient-ils me dire à quelle mise à jour ils en sont ? Qu'on essait de trouver le pourquoi du comment ?

En attendant, merci pour ton aide, fgth.

Mais de rien, fgth

[Gesp]

Tu avais la v1.4.2 officielle ou une v1.4.2test1?

Parce que à priori, je ne pense pas que "/usr/sbin/klogd -u klogd -j empty ait été inclu dans une version officielle et je l'ai retiré avant v1.4.2 parce qu'il y avait quelques problèmes au redémarrage du log par cron

[fgth]

Je suis carrément parti de la 1.4.0, avec les mises à jour au fur et à mesure.

[fgth]

Le nom de mon image de départ étant "ipcop-1.4.0.iso", chargée le 29/09/2004, je pense qu'il s'agissait d'une officielle. Non ?

[Gesp]

Oui alors ce n'est pas cela.

Ton problème doit être lié à la disquette de sauvegarde.

Si un bloc de la disquette est défecteux, la réinstallation du backup peut être incomplète et en particulier certains changements entre v1.3 et v1.4 ne sont pas effectués.

Il y a bien un message d'erreur mais comme cela a l'air de fonctionner, on n'y prend pas garde et en v1.3, il n'y avait pas de user klog

C'est corrigé en v1.4.1 il me semble ou l'on teste la lecture de toute la disquette avant d'installer le backup.

Si c'est cela, tu as intérêt de jeter la disquette. si tu n'as pas d'autre backups, je te conseillerais de refaire un backup avec une disquette neuve et peut-être de réinstaller avec backup, voir sans pour être sùr de la configuration.

[fgth]

Pas possible : j'ai sauvegardé ma 1.3 sur un poste du réseau avant la mise à jour. La config de la 1.4.0 a été reprise de cette sauvegarde.
De plus, pourquoi est-ce que klogd n'a rien dit jusque là, et qu'il se met à planter au moment où j'installe les patchs 1.4.3 .4 et .5 (comme je les ai installés en batterie, du coup, je ne sais pas lequel a posé problème).
Mais bon : ça n'est peut-être pas important, du moment que ça fonctionne maintenant.