Bonjour,
Suite à une panne de routeur, j'ai eu l'occasion de tester grandeur
nature mon BDC sur Xserve !!!
Echec : ni la réplique ldap (conne client Mac), ni le BDC (comme client
PC) ne fonctionnent quand le maître est HS.
Je me pose de fait plusieurs questions :
1) Est-ce normal que le serveur Kerberos ne fonctionne pas sur la
réplique en régime normal ?
2) Apple dit :
"en cas de panne, les clients trouvent automatiquement la réplique".
Soit !
Mais comment font-ils si ils ne sont pas sur le même sous-réseau ?
Dans "Format de répertoire" je n'ai placé que le maître, pas la
réplique. Je ne vois pas comment les clients peuvent trouver seuls
l'adresse IP de la réplique ?
3) La case "navigateur maitre de domaine" dans le réglage windows de la
réplique ne m'est pas accessible et n'est pas cochée.
Or si le maitre est HS, c'est bien la réplique qui devient maître ?
4) Dans le serveur WINS (sur un PC) mon BDC ne figure qu'en tant que
workstation, pas en contrôleur de domaine.
Plus généralement j'ai la quasi conviction que l'authentification sur
mon domaine windows se fait toujours sur le maître et jamais sur le BDC,
même si le client est distant et n'est pas sur le même sous-réseau.
Sinon, ma configuration :
2 x XServe en 10.4 sur deux sous réseaux distincts reliés par un tunnel
VPN IPsec.
L'un est Maître OD et PDC, l'autre est Réplique et BDC.
Mais comment font-ils si ils ne sont pas sur le même sous-réseau ? Dans "Format de répertoire" je n'ai placé que le maître, pas la réplique. Je ne vois pas comment les clients peuvent trouver seuls l'adresse IP de la réplique ?
ldapsearch a du mal avec l'UTF-8, du coup certaines entrées sont encodées en base-64 et apparaissent illisibles, avec des clients adaptés, on voit un plist.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick ESNAULT <patrick.noXmail.esnault@cfd.noXmail.fr> wrote:
Mais comment font-ils si ils ne sont pas sur le même sous-réseau ?
Dans "Format de répertoire" je n'ai placé que le maître, pas la
réplique. Je ne vois pas comment les clients peuvent trouver seuls
l'adresse IP de la réplique ?
ldapsearch a du mal avec l'UTF-8, du coup certaines entrées sont
encodées en base-64 et apparaissent illisibles, avec des clients
adaptés, on voit un plist.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Mais comment font-ils si ils ne sont pas sur le même sous-réseau ? Dans "Format de répertoire" je n'ai placé que le maître, pas la réplique. Je ne vois pas comment les clients peuvent trouver seuls l'adresse IP de la réplique ?
ldapsearch a du mal avec l'UTF-8, du coup certaines entrées sont encodées en base-64 et apparaissent illisibles, avec des clients adaptés, on voit un plist.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patrick.noXmail.esnault
Laurent Pertois wrote:
Patrick ESNAULT wrote:
Mais comment font-ils si ils ne sont pas sur le même sous-réseau ? Dans "Format de répertoire" je n'ai placé que le maître, pas la réplique. Je ne vois pas comment les clients peuvent trouver seuls l'adresse IP de la réplique ?
Effectivement, la réplique apparaît. Mais c'est l'histoire de la poule et de l'oeuf : si il faut interroger le maître pour savoir où est la réplique quand le maître est en panne !
Patrick ESNAULT <patrick.noXmail.esnault@cfd.noXmail.fr> wrote:
Mais comment font-ils si ils ne sont pas sur le même sous-réseau ?
Dans "Format de répertoire" je n'ai placé que le maître, pas la
réplique. Je ne vois pas comment les clients peuvent trouver seuls
l'adresse IP de la réplique ?
Effectivement, la réplique apparaît.
Mais c'est l'histoire de la poule et de l'oeuf : si il faut interroger
le maître pour savoir où est la réplique quand le maître est en panne !
Mais comment font-ils si ils ne sont pas sur le même sous-réseau ? Dans "Format de répertoire" je n'ai placé que le maître, pas la réplique. Je ne vois pas comment les clients peuvent trouver seuls l'adresse IP de la réplique ?
Effectivement, la réplique apparaît. Mais c'est l'histoire de la poule et de l'oeuf : si il faut interroger le maître pour savoir où est la réplique quand le maître est en panne !
Effectivement, la réplique apparaît. Mais c'est l'histoire de la poule et de l'oeuf : si il faut interroger le maître pour savoir où est la réplique quand le maître est en panne !
lors de la première connexion, ensuite, l'info est vérifiée régulièrement et mise à jour s'il y a changements.
Si j'arrête le maître rien ne marche !
Ca, c'est un bug, ça ne doit pas faire ça. Si tu redémarres un client, il ne fait rien ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick ESNAULT <patrick.noXmail.esnault@cfd.noXmail.fr> wrote:
Effectivement, la réplique apparaît.
Mais c'est l'histoire de la poule et de l'oeuf : si il faut interroger
le maître pour savoir où est la réplique quand le maître est en panne !
lors de la première connexion, ensuite, l'info est vérifiée
régulièrement et mise à jour s'il y a changements.
Si j'arrête le maître rien ne marche !
Ca, c'est un bug, ça ne doit pas faire ça. Si tu redémarres un client,
il ne fait rien ?
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Effectivement, la réplique apparaît. Mais c'est l'histoire de la poule et de l'oeuf : si il faut interroger le maître pour savoir où est la réplique quand le maître est en panne !
lors de la première connexion, ensuite, l'info est vérifiée régulièrement et mise à jour s'il y a changements.
Si j'arrête le maître rien ne marche !
Ca, c'est un bug, ça ne doit pas faire ça. Si tu redémarres un client, il ne fait rien ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patrick.noXmail.esnault
Laurent Pertois wrote:
Non, le client stocke cette information dans : /Library/Preferences/DirectoryService/DSLDAPv3PlugInConfig.plist OK, la réplique est bien là !
Si j'arrête le maître rien ne marche !
Ca, c'est un bug, ça ne doit pas faire ça. Si tu redémarres un client, il ne fait rien ? Non, j'ai arrêté le maitre, puis le client.
=> Login impossible puis redémarrage du maître => Login possible
Encore une fois, c'est normal que Kerberos soit arrêté sur la réplique ?
Non, le client stocke cette information dans : /Library/Preferences/DirectoryService/DSLDAPv3PlugInConfig.plist OK, la réplique est bien là !
Si j'arrête le maître rien ne marche !
Ca, c'est un bug, ça ne doit pas faire ça. Si tu redémarres un client, il ne fait rien ? Non, j'ai arrêté le maitre, puis le client.
=> Login impossible puis redémarrage du maître => Login possible
Encore une fois, c'est normal que Kerberos soit arrêté sur la réplique ?
laurent.pertois
Patrick ESNAULT wrote:
Laurent Pertois wrote:
Ca, c'est un bug, ça ne doit pas faire ça. Si tu redémarres un client, il ne fait rien ? Non, j'ai arrêté le maitre, puis le client.
=> Login impossible
Anormal.
puis redémarrage du maître => Login possible
Logique, mais anormal par rapport à ce test.
Encore une fois, c'est normal que Kerberos soit arrêté sur la réplique ?
Non.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick ESNAULT <patrick.noXmail.esnault@cfd.noXmail.fr> wrote:
Ca, c'est un bug, ça ne doit pas faire ça. Si tu redémarres un client,
il ne fait rien ?
Non, j'ai arrêté le maitre, puis le client.
=> Login impossible
Anormal.
puis redémarrage du maître
=> Login possible
Logique, mais anormal par rapport à ce test.
Encore une fois, c'est normal que Kerberos soit arrêté sur la réplique ?
Non.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Ca, c'est un bug, ça ne doit pas faire ça. Si tu redémarres un client, il ne fait rien ? Non, j'ai arrêté le maitre, puis le client.
=> Login impossible
Anormal.
puis redémarrage du maître => Login possible
Logique, mais anormal par rapport à ce test.
Encore une fois, c'est normal que Kerberos soit arrêté sur la réplique ?
Non.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patrick.noXmail.esnault
Encore une fois, c'est normal que Kerberos soit arrêté sur la réplique ?
Non. Bon.
J'ai tout réinstallé : * Le maître depuis une archive : rétrogradé sans OD, puis repromu maître (ouf : mes PC sous XP retrouvent le domaine windows)
* J'ai relancé la promotion de la réplique (en passant : comme ma réplique avait antérieurement le maître dans Format de répertoire, rien ne marchait...mais bon, ça c'était dans la doc !)
* Kerberos ne démarre toujours pas sur la réplique et je ne sais pas où chercher. Accessoirement je n'arrive pas à élever à réplique en BDC, mais j'imagine que c'est lié.
J'ai ça dans le log kdc de la réplique qui se répète souvent au démarrage :
Oct 03 18:01:22 zeus.cfd.fr krb5kdc[285](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.145.2: UNKNOWN_SERVER: authtime 1128354565, for ldap/, Server not found in Kerberos database
puis après une vingtaine de fois, la fin ceci :
krb5kdc: Interrupted system call - while selecting for network input(1) Oct 03 18:02:11 zeus.cfd.fr krb5kdc[285](info): shutting down
Pourtant mon dns est bon, à l'endroit et à l'envers. la réplique est : zeus.cfd.fr à l'adresse 192.168.145.2
Le "UNKNOWN_SERVER" me laisse perplexe.
Encore une fois, c'est normal que Kerberos soit arrêté sur la réplique ?
Non.
Bon.
J'ai tout réinstallé :
* Le maître depuis une archive : rétrogradé sans OD, puis repromu maître
(ouf : mes PC sous XP retrouvent le domaine windows)
* J'ai relancé la promotion de la réplique
(en passant : comme ma réplique avait antérieurement le maître dans
Format de répertoire, rien ne marchait...mais bon, ça c'était dans la
doc !)
* Kerberos ne démarre toujours pas sur la réplique et je ne sais pas où
chercher.
Accessoirement je n'arrive pas à élever à réplique en BDC, mais
j'imagine que c'est lié.
J'ai ça dans le log kdc de la réplique qui se répète souvent au
démarrage :
Oct 03 18:01:22 zeus.cfd.fr krb5kdc[285](info): TGS_REQ (7 etypes {18 17
16 23 1 3 2}) 192.168.145.2: UNKNOWN_SERVER: authtime 1128354565,
admin@ZEUS.CFD.FR for ldap/localhost@ZEUS.CFD.FR, Server not found in
Kerberos database
puis après une vingtaine de fois, la fin ceci :
krb5kdc: Interrupted system call - while selecting for network input(1)
Oct 03 18:02:11 zeus.cfd.fr krb5kdc[285](info): shutting down
Pourtant mon dns est bon, à l'endroit et à l'envers.
la réplique est : zeus.cfd.fr à l'adresse 192.168.145.2
Encore une fois, c'est normal que Kerberos soit arrêté sur la réplique ?
Non. Bon.
J'ai tout réinstallé : * Le maître depuis une archive : rétrogradé sans OD, puis repromu maître (ouf : mes PC sous XP retrouvent le domaine windows)
* J'ai relancé la promotion de la réplique (en passant : comme ma réplique avait antérieurement le maître dans Format de répertoire, rien ne marchait...mais bon, ça c'était dans la doc !)
* Kerberos ne démarre toujours pas sur la réplique et je ne sais pas où chercher. Accessoirement je n'arrive pas à élever à réplique en BDC, mais j'imagine que c'est lié.
J'ai ça dans le log kdc de la réplique qui se répète souvent au démarrage :
Oct 03 18:01:22 zeus.cfd.fr krb5kdc[285](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.145.2: UNKNOWN_SERVER: authtime 1128354565, for ldap/, Server not found in Kerberos database
puis après une vingtaine de fois, la fin ceci :
krb5kdc: Interrupted system call - while selecting for network input(1) Oct 03 18:02:11 zeus.cfd.fr krb5kdc[285](info): shutting down
Pourtant mon dns est bon, à l'endroit et à l'envers. la réplique est : zeus.cfd.fr à l'adresse 192.168.145.2
Le "UNKNOWN_SERVER" me laisse perplexe.
laurent.pertois
Patrick ESNAULT wrote:
* Kerberos ne démarre toujours pas sur la réplique et je ne sais pas où chercher.
Remets ta réplique en Serveur Autonome, vérifie qu'elle se trouve bien dans les DNS (reverse et forward), lance Console (ou un truc permettant de voir les logs sur ton serveur) et ouvre slapconfig.log :
/Library/Logs/slapconfig.log
Laisse ouvert pour regarder, lance la réplication, regarde, éventuellement poste ici le contenu.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick ESNAULT <patrick.noXmail.esnault@cfd.noXmail.fr> wrote:
* Kerberos ne démarre toujours pas sur la réplique et je ne sais pas où
chercher.
Remets ta réplique en Serveur Autonome, vérifie qu'elle se trouve bien
dans les DNS (reverse et forward), lance Console (ou un truc permettant
de voir les logs sur ton serveur) et ouvre slapconfig.log :
/Library/Logs/slapconfig.log
Laisse ouvert pour regarder, lance la réplication, regarde,
éventuellement poste ici le contenu.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
* Kerberos ne démarre toujours pas sur la réplique et je ne sais pas où chercher.
Remets ta réplique en Serveur Autonome, vérifie qu'elle se trouve bien dans les DNS (reverse et forward), lance Console (ou un truc permettant de voir les logs sur ton serveur) et ouvre slapconfig.log :
/Library/Logs/slapconfig.log
Laisse ouvert pour regarder, lance la réplication, regarde, éventuellement poste ici le contenu.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patrick.noXmail.esnault
Laurent Pertois wrote:
Remets ta réplique en Serveur Autonome, vérifie qu'elle se trouve bien dans les DNS (reverse et forward), lance Console (ou un truc permettant de voir les logs sur ton serveur) et ouvre slapconfig.log :
/Library/Logs/slapconfig.log
Laisse ouvert pour regarder, lance la réplication, regarde, éventuellement poste ici le contenu.
Rien de bien clair. En fait même le retour en serveur autonome se fait dans la douleur. Serveur Admin se bloque et le redémarrage du serveur est nécessaire.
En refléchissant, je suis passé d'un état de 10.3.9 / maître OD / PDC en 10.4. par upgrade. Puis élévation en réplique OD en oubliant de rétrograder le PDC. Je me suis donc trouvé avec une réplique OD qui est restée PDC sur un domaine, alors que le maître OD était PDC d'un autre domaine.
J'ai alors rétrogradé mon PDC de la réplique : le server s'est figé/redémarrage obligatoire et début de mes soucis.
Donc j'arrête et je réinstalle tout sans faire d'upgrade.
Dans l'immédiat, j'ai écrasé le système avec un backup en 10.3.9 qui marche et referai un installation clean plus tard (le serveur est à 1000 km de mon bureau...).
Remets ta réplique en Serveur Autonome, vérifie qu'elle se trouve bien
dans les DNS (reverse et forward), lance Console (ou un truc permettant
de voir les logs sur ton serveur) et ouvre slapconfig.log :
/Library/Logs/slapconfig.log
Laisse ouvert pour regarder, lance la réplication, regarde,
éventuellement poste ici le contenu.
Rien de bien clair.
En fait même le retour en serveur autonome se fait dans la douleur.
Serveur Admin se bloque et le redémarrage du serveur est nécessaire.
En refléchissant, je suis passé d'un état de 10.3.9 / maître OD / PDC en
10.4. par upgrade.
Puis élévation en réplique OD en oubliant de rétrograder le PDC.
Je me suis donc trouvé avec une réplique OD qui est restée PDC sur un
domaine, alors que le maître OD était PDC d'un autre domaine.
J'ai alors rétrogradé mon PDC de la réplique : le server s'est
figé/redémarrage obligatoire et début de mes soucis.
Donc j'arrête et je réinstalle tout sans faire d'upgrade.
Dans l'immédiat, j'ai écrasé le système avec un backup en 10.3.9 qui
marche et referai un installation clean plus tard (le serveur est à 1000
km de mon bureau...).
Remets ta réplique en Serveur Autonome, vérifie qu'elle se trouve bien dans les DNS (reverse et forward), lance Console (ou un truc permettant de voir les logs sur ton serveur) et ouvre slapconfig.log :
/Library/Logs/slapconfig.log
Laisse ouvert pour regarder, lance la réplication, regarde, éventuellement poste ici le contenu.
Rien de bien clair. En fait même le retour en serveur autonome se fait dans la douleur. Serveur Admin se bloque et le redémarrage du serveur est nécessaire.
En refléchissant, je suis passé d'un état de 10.3.9 / maître OD / PDC en 10.4. par upgrade. Puis élévation en réplique OD en oubliant de rétrograder le PDC. Je me suis donc trouvé avec une réplique OD qui est restée PDC sur un domaine, alors que le maître OD était PDC d'un autre domaine.
J'ai alors rétrogradé mon PDC de la réplique : le server s'est figé/redémarrage obligatoire et début de mes soucis.
Donc j'arrête et je réinstalle tout sans faire d'upgrade.
Dans l'immédiat, j'ai écrasé le système avec un backup en 10.3.9 qui marche et referai un installation clean plus tard (le serveur est à 1000 km de mon bureau...).
Merci quand même et à plus tard...
laurent.pertois
Patrick ESNAULT wrote:
Rien de bien clair.
Juste pour info, tu pourrais envoyer ce retour ?
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Patrick ESNAULT <patrick.noXmail.esnault@cfd.noXmail.fr> wrote:
Rien de bien clair.
Juste pour info, tu pourrais envoyer ce retour ?
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patrick.noxmail.esnault
Laurent Pertois wrote:
Juste pour info, tu pourrais envoyer ce retour ? Désolé, j'ai tout écrasé avec le backup.
