[JE SUIS UN ÂNE]logrotate : stat of @ failed (No such file or directory)
15 réponses
Laurent Hugé
Bonjour à tous,
Et désolé de m'emporter ainsi contre moi-même devant tant de beau
monde !
J'avais donc un problème avec logrotate :
reading config file /etc/logrotate.conf
reading config info for /var/log/messages
Handling 1 logs
rotating pattern: /var/log
messages 104857600 bytes (5 rotations)
empty log files are not rotated, old logs are removed
considering log pW@h\@
stat of pW@h\@ failed: No such file or directory
Après avoir fait vérifier par tous ma bonne configuration, monté la
version (en 3.6.8), j'obtiends toujours la même chose.
Puis gerard patel me glisse un début de réponse
> - la lecture des fichiers de journal à compacter se fait dans
> le fichier config.c, routine readConfigFile; cette routine
> d'environ 600 lignes de C avec des while, if, imbriqués a
> gogo est un exemple de code susceptible de donner des
> résultats semi-aléatoires lors de toute variation imprévue
> des entrées. Il est envisageable qu'une erreur plus ou moins
> énorme de configuration se répercute dans cette construction
> d'une manière imprévisible.
qu'il détaille dans un autre post.
Et paf ! Je part en vacances (personne n'est parfais et je m'en
excuse), pensant appliquer cette solution à mon retour.
Et bien sûr (application directe des lois de Murphy), Knode à
"nettoyé" ma base, et le serveur de news aussi. Donc plus de
solution :`-(
J'ai bien essayé de trouver par moi-même (on a sa fierté quand
même ;-) mais le config.c est un brin confus pour moi (les pointeurs
de pointeurs, j'ai jamais réussi à suivre).
Une âme bien intentionnée pourrait-elle me souffler la réponse ?
Merci,
--
Laurent Hugé (pour m'écrire, ôter PasDeSpam de l'adresse de courriel)
GPG fingerprint = 3AFF A106 39D9 DB2C 885D 41C3 76DC 2C3F 01BE 5D4A
On Sat, 01 May 2004 09:14:30 +0200, Laurent Hugé wrote:
[...]
locate glob.h ne donne rien ? Mea culpa, j'ai dû le passer sans le voir, mais il est bien dans /usr
include.
Bon l'essentiel, c'st de le retrouver :-)
[...]
Mais si kerberos le remplace, ça explique le problème ! Il doit y avoir une différence entre les headers: la libc supporte le 64 bits, par ex, et les structures retournées par les versions 32 bits et 64 bits ne sont pas les mêmes... Ca peut causer de sérieux problèmes ! J'ai comparé les deux fichiers, et ils sont complètement différents !
Je confirme donc les sérieux problèmes :`-(
Faut-il que je réinstalle la glibc (avec exactement les mêmes options que lors de son installation) pour retrouver un glob.h qui tourne ?
Ca parait sage... D'accord, mais alors là, j'ai un peu peur (du temps où j'avais la
Mandrake, je m'étais déjà rendu compte de la valeur de la glibc en essayant d'en changer de version).
Ce que je me propose de faire est donc de refaire un configure de Kerberos5, puis un make uninstall (à la main s'il n'est pas prévu dans les sources, mais j'en doute), sachant que *normalement*, aucun produit que j'ai installé par la suite ne l'utilise. Ensuite, je recompile la glibc, et je la réinstalle.
Ca semble bien.
Ce qui me chagrine, c'est qu'en désinstallant Kerberos5, je devrais normalement supprimer glob.h. Cela va-t'il perturber la compilation de la glibc (sachant qu'il y a peut-être d'autre headers que Kerberos5 remplace) ? Faudrait-il que je garde Kerberos5 et que je réinstalle la glibc par dessus ?
A priori, la libc ne devrait pas avoir besoin de ses propres headers installés pour compiler. Par précaution, tu peux importer le glob.h de l'autre machine le temps de recompiler la glibc. Comme c'est un header POSIX, il y a peu de risque d'incompatibilités si les versions sont différentes.
On Sat, 01 May 2004 09:14:30 +0200, Laurent Hugé wrote:
[...]
locate glob.h ne donne rien ?
Mea culpa, j'ai dû le passer sans le voir, mais il est bien dans /usr
include.
Bon l'essentiel, c'st de le retrouver :-)
[...]
Mais si kerberos le remplace, ça explique le problème !
Il doit y avoir une différence entre les headers: la libc supporte
le 64 bits, par ex, et les structures retournées par les versions
32 bits et 64 bits ne sont pas les mêmes... Ca peut causer de
sérieux problèmes !
J'ai comparé les deux fichiers, et ils sont complètement différents !
Je confirme donc les sérieux problèmes :`-(
Faut-il que je réinstalle la glibc (avec exactement les mêmes
options que lors de son installation) pour retrouver un glob.h qui
tourne ?
Ca parait sage...
D'accord, mais alors là, j'ai un peu peur (du temps où j'avais la
Mandrake, je m'étais déjà rendu compte de la valeur de la glibc en
essayant d'en changer de version).
Ce que je me propose de faire est donc de refaire un configure de
Kerberos5, puis un make uninstall (à la main s'il n'est pas prévu
dans les sources, mais j'en doute), sachant que *normalement*, aucun
produit que j'ai installé par la suite ne l'utilise.
Ensuite, je recompile la glibc, et je la réinstalle.
Ca semble bien.
Ce qui me chagrine, c'est qu'en désinstallant Kerberos5, je devrais
normalement supprimer glob.h. Cela va-t'il perturber la compilation
de la glibc (sachant qu'il y a peut-être d'autre headers que
Kerberos5 remplace) ?
Faudrait-il que je garde Kerberos5 et que je réinstalle la glibc par
dessus ?
A priori, la libc ne devrait pas avoir besoin de ses propres headers
installés pour compiler. Par précaution, tu peux importer le glob.h
de l'autre machine le temps de recompiler la glibc. Comme c'est
un header POSIX, il y a peu de risque d'incompatibilités si les
versions sont différentes.
On Sat, 01 May 2004 09:14:30 +0200, Laurent Hugé wrote:
[...]
locate glob.h ne donne rien ? Mea culpa, j'ai dû le passer sans le voir, mais il est bien dans /usr
include.
Bon l'essentiel, c'st de le retrouver :-)
[...]
Mais si kerberos le remplace, ça explique le problème ! Il doit y avoir une différence entre les headers: la libc supporte le 64 bits, par ex, et les structures retournées par les versions 32 bits et 64 bits ne sont pas les mêmes... Ca peut causer de sérieux problèmes ! J'ai comparé les deux fichiers, et ils sont complètement différents !
Je confirme donc les sérieux problèmes :`-(
Faut-il que je réinstalle la glibc (avec exactement les mêmes options que lors de son installation) pour retrouver un glob.h qui tourne ?
Ca parait sage... D'accord, mais alors là, j'ai un peu peur (du temps où j'avais la
Mandrake, je m'étais déjà rendu compte de la valeur de la glibc en essayant d'en changer de version).
Ce que je me propose de faire est donc de refaire un configure de Kerberos5, puis un make uninstall (à la main s'il n'est pas prévu dans les sources, mais j'en doute), sachant que *normalement*, aucun produit que j'ai installé par la suite ne l'utilise. Ensuite, je recompile la glibc, et je la réinstalle.
Ca semble bien.
Ce qui me chagrine, c'est qu'en désinstallant Kerberos5, je devrais normalement supprimer glob.h. Cela va-t'il perturber la compilation de la glibc (sachant qu'il y a peut-être d'autre headers que Kerberos5 remplace) ? Faudrait-il que je garde Kerberos5 et que je réinstalle la glibc par dessus ?
A priori, la libc ne devrait pas avoir besoin de ses propres headers installés pour compiler. Par précaution, tu peux importer le glob.h de l'autre machine le temps de recompiler la glibc. Comme c'est un header POSIX, il y a peu de risque d'incompatibilités si les versions sont différentes.
Laurent Hugé
Ce qui me chagrine, c'est qu'en désinstallant Kerberos5, je devrais normalement supprimer glob.h. Cela va-t'il perturber la compilation de la glibc (sachant qu'il y a peut-être d'autre headers que Kerberos5 remplace) ? Faudrait-il que je garde Kerberos5 et que je réinstalle la glibc par dessus ?
A priori, la libc ne devrait pas avoir besoin de ses propres headers installés pour compiler. Par précaution, tu peux importer le glob.h de l'autre machine le temps de recompiler la glibc. Comme c'est un header POSIX, il y a peu de risque d'incompatibilités si les versions sont différentes. J'ai dû mal m'exprimer : ce que je voulais dire, c'est que si la
compilation de la glibc plante, je suppose évidement que c'est glob.h et je le repique sur mon autre machine ! Mais si c'est un autre header qui lui manque (les messages d'erreur n'étant pas toujours explicites) ? C'est ce manque de contrôle que me gêne. -- Laurent Hugé (pour m'écrire, ôter PasDeSpam de l'adresse de courriel) GPG fingerprint = 3AFF A106 39D9 DB2C 885D 41C3 76DC 2C3F 01BE 5D4A
Ce qui me chagrine, c'est qu'en désinstallant Kerberos5, je devrais
normalement supprimer glob.h. Cela va-t'il perturber la compilation
de la glibc (sachant qu'il y a peut-être d'autre headers que
Kerberos5 remplace) ?
Faudrait-il que je garde Kerberos5 et que je réinstalle la glibc
par dessus ?
A priori, la libc ne devrait pas avoir besoin de ses propres headers
installés pour compiler. Par précaution, tu peux importer le glob.h
de l'autre machine le temps de recompiler la glibc. Comme c'est
un header POSIX, il y a peu de risque d'incompatibilités si les
versions sont différentes.
J'ai dû mal m'exprimer : ce que je voulais dire, c'est que si la
compilation de la glibc plante, je suppose évidement que c'est glob.h
et je le repique sur mon autre machine ! Mais si c'est un autre
header qui lui manque (les messages d'erreur n'étant pas toujours
explicites) ? C'est ce manque de contrôle que me gêne.
--
Laurent Hugé (pour m'écrire, ôter PasDeSpam de l'adresse de courriel)
GPG fingerprint = 3AFF A106 39D9 DB2C 885D 41C3 76DC 2C3F 01BE 5D4A
Ce qui me chagrine, c'est qu'en désinstallant Kerberos5, je devrais normalement supprimer glob.h. Cela va-t'il perturber la compilation de la glibc (sachant qu'il y a peut-être d'autre headers que Kerberos5 remplace) ? Faudrait-il que je garde Kerberos5 et que je réinstalle la glibc par dessus ?
A priori, la libc ne devrait pas avoir besoin de ses propres headers installés pour compiler. Par précaution, tu peux importer le glob.h de l'autre machine le temps de recompiler la glibc. Comme c'est un header POSIX, il y a peu de risque d'incompatibilités si les versions sont différentes. J'ai dû mal m'exprimer : ce que je voulais dire, c'est que si la
compilation de la glibc plante, je suppose évidement que c'est glob.h et je le repique sur mon autre machine ! Mais si c'est un autre header qui lui manque (les messages d'erreur n'étant pas toujours explicites) ? C'est ce manque de contrôle que me gêne. -- Laurent Hugé (pour m'écrire, ôter PasDeSpam de l'adresse de courriel) GPG fingerprint = 3AFF A106 39D9 DB2C 885D 41C3 76DC 2C3F 01BE 5D4A
no_spam
On Sat, 01 May 2004 16:09:17 +0200, Laurent Hugé wrote:
Ce qui me chagrine, c'est qu'en désinstallant Kerberos5, je devrais normalement supprimer glob.h. Cela va-t'il perturber la compilation de la glibc (sachant qu'il y a peut-être d'autre headers que Kerberos5 remplace) ? Faudrait-il que je garde Kerberos5 et que je réinstalle la glibc par dessus ?
A priori, la libc ne devrait pas avoir besoin de ses propres headers installés pour compiler. Par précaution, tu peux importer le glob.h de l'autre machine le temps de recompiler la glibc. Comme c'est un header POSIX, il y a peu de risque d'incompatibilités si les versions sont différentes. J'ai dû mal m'exprimer : ce que je voulais dire, c'est que si la
compilation de la glibc plante, je suppose évidement que c'est glob.h et je le repique sur mon autre machine ! Mais si c'est un autre header qui lui manque (les messages d'erreur n'étant pas toujours explicites) ? C'est ce manque de contrôle que me gêne.
En principe, la glibc ne se sert que des headers du kernel, comme headers systèmes. Elle ne dépend d'aucune autre librairie, et ce serait un bug de configuration qu'elle essaye d'utiliser des headers installés. Il y a juste gcc qui se servira de ses propres headers pour ses helpers internes. Et heureusement: comment ferait-on pour installer un toolchain de cross-compilation (binutils + gcc + glibc) pour cross-compiler s'il fallait avoir les headers de la target installé _avant_ ?
Donc, s'il y a une erreur de compil, c'est peu probable que ça vienne d'un pb de headers (à part éventuellement ceux du kernel).
On Sat, 01 May 2004 16:09:17 +0200, Laurent Hugé wrote:
Ce qui me chagrine, c'est qu'en désinstallant Kerberos5, je devrais
normalement supprimer glob.h. Cela va-t'il perturber la compilation
de la glibc (sachant qu'il y a peut-être d'autre headers que
Kerberos5 remplace) ?
Faudrait-il que je garde Kerberos5 et que je réinstalle la glibc
par dessus ?
A priori, la libc ne devrait pas avoir besoin de ses propres headers
installés pour compiler. Par précaution, tu peux importer le glob.h
de l'autre machine le temps de recompiler la glibc. Comme c'est
un header POSIX, il y a peu de risque d'incompatibilités si les
versions sont différentes.
J'ai dû mal m'exprimer : ce que je voulais dire, c'est que si la
compilation de la glibc plante, je suppose évidement que c'est glob.h
et je le repique sur mon autre machine ! Mais si c'est un autre
header qui lui manque (les messages d'erreur n'étant pas toujours
explicites) ? C'est ce manque de contrôle que me gêne.
En principe, la glibc ne se sert que des headers du kernel,
comme headers systèmes. Elle ne dépend d'aucune autre librairie,
et ce serait un bug de configuration qu'elle essaye d'utiliser des
headers installés. Il y a juste gcc qui se servira de ses propres
headers pour ses helpers internes.
Et heureusement: comment ferait-on pour installer un toolchain de
cross-compilation (binutils + gcc + glibc) pour cross-compiler
s'il fallait avoir les headers de la target installé _avant_ ?
Donc, s'il y a une erreur de compil, c'est peu probable que ça vienne
d'un pb de headers (à part éventuellement ceux du kernel).
On Sat, 01 May 2004 16:09:17 +0200, Laurent Hugé wrote:
Ce qui me chagrine, c'est qu'en désinstallant Kerberos5, je devrais normalement supprimer glob.h. Cela va-t'il perturber la compilation de la glibc (sachant qu'il y a peut-être d'autre headers que Kerberos5 remplace) ? Faudrait-il que je garde Kerberos5 et que je réinstalle la glibc par dessus ?
A priori, la libc ne devrait pas avoir besoin de ses propres headers installés pour compiler. Par précaution, tu peux importer le glob.h de l'autre machine le temps de recompiler la glibc. Comme c'est un header POSIX, il y a peu de risque d'incompatibilités si les versions sont différentes. J'ai dû mal m'exprimer : ce que je voulais dire, c'est que si la
compilation de la glibc plante, je suppose évidement que c'est glob.h et je le repique sur mon autre machine ! Mais si c'est un autre header qui lui manque (les messages d'erreur n'étant pas toujours explicites) ? C'est ce manque de contrôle que me gêne.
En principe, la glibc ne se sert que des headers du kernel, comme headers systèmes. Elle ne dépend d'aucune autre librairie, et ce serait un bug de configuration qu'elle essaye d'utiliser des headers installés. Il y a juste gcc qui se servira de ses propres headers pour ses helpers internes. Et heureusement: comment ferait-on pour installer un toolchain de cross-compilation (binutils + gcc + glibc) pour cross-compiler s'il fallait avoir les headers de la target installé _avant_ ?
Donc, s'il y a une erreur de compil, c'est peu probable que ça vienne d'un pb de headers (à part éventuellement ceux du kernel).
g.patel
On Sat, 01 May 2004 13:57:47 +0200, Laurent =?ISO-8859-15?Q?Hugé? wrote:
C'est http://linuxfromscratch.org/pipermail hints/2003-September/001904.html
ah je n'avais pas percuté, c'est une implémentation indépendante de kerberos.
(...)
Cela dit, je vais faire le remplacement de glob.h (même pas peur ;-)
ne voyant pas de suivi, j'ai fait appel à Google et effectivement il y en avait un, mon serveur de groupe de nouvelles a mangé le message :-/ :
Je l'ai fait. Ça marche (ouf ;-). Je considère que c'est bon ? (ou faut-il que je me mette à la désinstallation de Kerberos5 (je pourrais par exemple passer à celle du MIT, si elle ne touche pas à glob.h)).
Oui. Je ne vois vraiment pas pourquoi il y a toute cette duplication des fonctions de la glibc dans Kerberos Heimdal. Effectivement la fonction glob utilise ici une structure :
typedef struct { int gl_pathc; /* Count of total paths so far. */ int gl_matchc; /* Count of paths matching pattern. */ int gl_offs; /* Reserved at beginning of gl_pathv. */ int gl_flags; /* Copy of flags parameter to glob. */ char **gl_pathv; /* List of paths matching pattern. */
incompatible avec celle de la glibc :
typedef struct { __size_t gl_pathc; /* Count of paths matched by the pattern. */ char **gl_pathv; /* List of matched pathnames. */
c'est clair qu'il y a un problème ici si on accède à gl_pathv :-/ Je ne sais pas comment ce problème peut etre résolu, peut-etre avec un chemin particulier pour les include dans le configure de ce Kerberos ?
Soit dit en passant, la version de Kerberos MIT n'apparaît pas dans Freshmeat (je sais qu'il faut inscrire son projet dans Freshmeat, mais il me semblait que c'était un peu la référence).
oui, c'est le Massachusetts Institute of Technology qui a inventé Kerberos, je ne pense pas qu'ils estiment indispensable à leur réputation d'etre reconnu par Freshmeat :-)
Je pense que l'implémentation d'Heimdal avait pour but de contourner les restrictions du gouvernement des USA sur l'exportation de certaines technologies, mais ces restrictions ont été abandonnées : Mandrake distribue l'implémentation du MIT, par exemple.
En tout cas, si je désinstalle Kerberos5, je dois quand même réinstaller la glibc, n'est-il pas (au cas où il me supprime des fichiers de cette glibc autre que glob.h) ?
Je réinstallerais la glibc simplement, pour écraser les fichiers de cette implémentation de Kerberos qui sont en conflit.
Gérard Patel
On Sat, 01 May 2004 13:57:47 +0200, Laurent =?ISO-8859-15?Q?Hugé? <hugePasDeSpam.root@freePasDeSpam.fr> wrote:
C'est http://linuxfromscratch.org/pipermail
hints/2003-September/001904.html
ah je n'avais pas percuté, c'est une implémentation indépendante
de kerberos.
(...)
Cela dit, je vais faire le remplacement de glob.h (même pas peur ;-)
ne voyant pas de suivi, j'ai fait appel à Google et effectivement
il y en avait un, mon serveur de groupe de nouvelles a mangé
le message :-/ :
Je l'ai fait. Ça marche (ouf ;-). Je considère que c'est bon ? (ou
faut-il que je me mette à la désinstallation de Kerberos5 (je
pourrais par exemple passer à celle du MIT, si elle ne touche pas à
glob.h)).
Oui. Je ne vois vraiment pas pourquoi il y a toute cette duplication
des fonctions de la glibc dans Kerberos Heimdal. Effectivement
la fonction glob utilise ici une structure :
typedef struct {
int gl_pathc; /* Count of total paths so far. */
int gl_matchc; /* Count of paths matching pattern. */
int gl_offs; /* Reserved at beginning of gl_pathv.
*/
int gl_flags; /* Copy of flags parameter to glob. */
char **gl_pathv; /* List of paths matching pattern. */
incompatible avec celle de la glibc :
typedef struct
{
__size_t gl_pathc; /* Count of paths matched by the
pattern. */
char **gl_pathv; /* List of matched pathnames. */
c'est clair qu'il y a un problème ici si on accède à gl_pathv :-/
Je ne sais pas comment ce problème peut etre résolu, peut-etre
avec un chemin particulier pour les include dans le configure de
ce Kerberos ?
Soit dit en passant, la version de Kerberos MIT n'apparaît pas dans
Freshmeat (je sais qu'il faut inscrire son projet dans Freshmeat,
mais il me semblait que c'était un peu la référence).
oui, c'est le Massachusetts Institute of Technology qui a inventé
Kerberos, je ne pense pas qu'ils estiment indispensable à leur
réputation d'etre reconnu par Freshmeat :-)
Je pense que l'implémentation d'Heimdal avait pour but de
contourner les restrictions du gouvernement des USA sur
l'exportation de certaines technologies, mais ces restrictions
ont été abandonnées : Mandrake distribue l'implémentation du MIT,
par exemple.
En tout cas, si je désinstalle Kerberos5, je dois quand même
réinstaller la glibc, n'est-il pas (au cas où il me supprime des
fichiers de cette glibc autre que glob.h) ?
Je réinstallerais la glibc simplement, pour écraser les fichiers
de cette implémentation de Kerberos qui sont en conflit.
ah je n'avais pas percuté, c'est une implémentation indépendante de kerberos.
(...)
Cela dit, je vais faire le remplacement de glob.h (même pas peur ;-)
ne voyant pas de suivi, j'ai fait appel à Google et effectivement il y en avait un, mon serveur de groupe de nouvelles a mangé le message :-/ :
Je l'ai fait. Ça marche (ouf ;-). Je considère que c'est bon ? (ou faut-il que je me mette à la désinstallation de Kerberos5 (je pourrais par exemple passer à celle du MIT, si elle ne touche pas à glob.h)).
Oui. Je ne vois vraiment pas pourquoi il y a toute cette duplication des fonctions de la glibc dans Kerberos Heimdal. Effectivement la fonction glob utilise ici une structure :
typedef struct { int gl_pathc; /* Count of total paths so far. */ int gl_matchc; /* Count of paths matching pattern. */ int gl_offs; /* Reserved at beginning of gl_pathv. */ int gl_flags; /* Copy of flags parameter to glob. */ char **gl_pathv; /* List of paths matching pattern. */
incompatible avec celle de la glibc :
typedef struct { __size_t gl_pathc; /* Count of paths matched by the pattern. */ char **gl_pathv; /* List of matched pathnames. */
c'est clair qu'il y a un problème ici si on accède à gl_pathv :-/ Je ne sais pas comment ce problème peut etre résolu, peut-etre avec un chemin particulier pour les include dans le configure de ce Kerberos ?
Soit dit en passant, la version de Kerberos MIT n'apparaît pas dans Freshmeat (je sais qu'il faut inscrire son projet dans Freshmeat, mais il me semblait que c'était un peu la référence).
oui, c'est le Massachusetts Institute of Technology qui a inventé Kerberos, je ne pense pas qu'ils estiment indispensable à leur réputation d'etre reconnu par Freshmeat :-)
Je pense que l'implémentation d'Heimdal avait pour but de contourner les restrictions du gouvernement des USA sur l'exportation de certaines technologies, mais ces restrictions ont été abandonnées : Mandrake distribue l'implémentation du MIT, par exemple.
En tout cas, si je désinstalle Kerberos5, je dois quand même réinstaller la glibc, n'est-il pas (au cas où il me supprime des fichiers de cette glibc autre que glob.h) ?
Je réinstallerais la glibc simplement, pour écraser les fichiers de cette implémentation de Kerberos qui sont en conflit.
Gérard Patel
Laurent Hugé
On Sat, 01 May 2004 13:57:47 +0200, Laurent =?ISO-8859-15?Q?Hugé? > wrote:
C'est http://linuxfromscratch.org/pipermail hints/2003-September/001904.html
pas moyen d'accéder à ce post :-/ Effectivement, il y eu une césure sauvage de knode : il y un / entre
pipermail et hints !
oui, c'est le Massachusetts Institute of Technology qui a inventé Kerberos, je ne pense pas qu'ils estiment indispensable à leur réputation d'etre reconnu par Freshmeat :-) Soit, soit, mais, ça m'aurait évité bien des problèmes :-(
Je pense que l'implémentation d'Heimdal avait pour but de contourner les restrictions du gouvernement des USA sur l'exportation de certaines technologies, mais ces restrictions ont été abandonnées : Mandrake distribue l'implémentation du MIT, par exemple.
En tout cas, si je désinstalle Kerberos5, je dois quand même réinstaller la glibc, n'est-il pas (au cas où il me supprime des fichiers de cette glibc autre que glob.h) ?
Je réinstallerais la glibc simplement, pour écraser les fichiers de cette implémentation de Kerberos qui sont en conflit. Oui, mais pour faire un truc un peu plus propre, ne vaut-il pas mieux
que je désinstalle Kerberos 5 Heimdal, que je réinstalle la glibc, puis que je me lance dans Kerberos 5 MIT ? -- Laurent Hugé (pour m'écrire, ôter PasDeSpam de l'adresse de courriel) GPG fingerprint = 3AFF A106 39D9 DB2C 885D 41C3 76DC 2C3F 01BE 5D4A
On Sat, 01 May 2004 13:57:47 +0200, Laurent =?ISO-8859-15?Q?Hugé? > <hugePasDeSpam.root@freePasDeSpam.fr> wrote:
C'est http://linuxfromscratch.org/pipermail
hints/2003-September/001904.html
pas moyen d'accéder à ce post :-/
Effectivement, il y eu une césure sauvage de knode : il y un / entre
pipermail et hints !
oui, c'est le Massachusetts Institute of Technology qui a inventé
Kerberos, je ne pense pas qu'ils estiment indispensable à leur
réputation d'etre reconnu par Freshmeat :-)
Soit, soit, mais, ça m'aurait évité bien des problèmes :-(
Je pense que l'implémentation d'Heimdal avait pour but de
contourner les restrictions du gouvernement des USA sur
l'exportation de certaines technologies, mais ces restrictions
ont été abandonnées : Mandrake distribue l'implémentation du MIT,
par exemple.
En tout cas, si je désinstalle Kerberos5, je dois quand même
réinstaller la glibc, n'est-il pas (au cas où il me supprime des
fichiers de cette glibc autre que glob.h) ?
Je réinstallerais la glibc simplement, pour écraser les fichiers
de cette implémentation de Kerberos qui sont en conflit.
Oui, mais pour faire un truc un peu plus propre, ne vaut-il pas mieux
que je désinstalle Kerberos 5 Heimdal, que je réinstalle la glibc,
puis que je me lance dans Kerberos 5 MIT ?
--
Laurent Hugé (pour m'écrire, ôter PasDeSpam de l'adresse de courriel)
GPG fingerprint = 3AFF A106 39D9 DB2C 885D 41C3 76DC 2C3F 01BE 5D4A
On Sat, 01 May 2004 13:57:47 +0200, Laurent =?ISO-8859-15?Q?Hugé? > wrote:
C'est http://linuxfromscratch.org/pipermail hints/2003-September/001904.html
pas moyen d'accéder à ce post :-/ Effectivement, il y eu une césure sauvage de knode : il y un / entre
pipermail et hints !
oui, c'est le Massachusetts Institute of Technology qui a inventé Kerberos, je ne pense pas qu'ils estiment indispensable à leur réputation d'etre reconnu par Freshmeat :-) Soit, soit, mais, ça m'aurait évité bien des problèmes :-(
Je pense que l'implémentation d'Heimdal avait pour but de contourner les restrictions du gouvernement des USA sur l'exportation de certaines technologies, mais ces restrictions ont été abandonnées : Mandrake distribue l'implémentation du MIT, par exemple.
En tout cas, si je désinstalle Kerberos5, je dois quand même réinstaller la glibc, n'est-il pas (au cas où il me supprime des fichiers de cette glibc autre que glob.h) ?
Je réinstallerais la glibc simplement, pour écraser les fichiers de cette implémentation de Kerberos qui sont en conflit. Oui, mais pour faire un truc un peu plus propre, ne vaut-il pas mieux
que je désinstalle Kerberos 5 Heimdal, que je réinstalle la glibc, puis que je me lance dans Kerberos 5 MIT ? -- Laurent Hugé (pour m'écrire, ôter PasDeSpam de l'adresse de courriel) GPG fingerprint = 3AFF A106 39D9 DB2C 885D 41C3 76DC 2C3F 01BE 5D4A
