[Mac OS X Server - 10.4.9] Utilisateurs et groupes inaccessibles

MagalieJ <mag@lery.nom.fr> wrote:

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

Ok, et les utilisateurs sont donc dans la base LDAP du serveur ?

Normalement, oui.

Ok.

Les autres informations résumées sur la "vue d'ensemble" sont :
<snip>

Kerberos : arrêté

Kerberos arrêté, erreur dans le DNS :)

Vi... D'ailleurs, faudra que je me penche sur la question un de ces
quatre matins ! ;-)

D'urgence oui. Les fonctionnalités Open Directory et Mail fonctionnent
largement mieux avec un DNS bien configuré.

Pour le moment, ma philosophie est : si j'ai un doute sur un service et
que la documentation me semble obscure, je ne le lance pas et j'attends
d'en savoir un peu plus !

Euh, ok, c'est un bon début. Un service mal configuré est pire que pas
de service du tout. Mais le DNS est une des bases, malheureusement.

Ceci dit, je me demande si justement je n'ai pas "bidouillé" le DNS
avant que tout ceci tombe en panne... Parce que je n'ai lancé ce service
que très récemment, pensant avoir un peu mieux appréhendé le
fonctionnement global... Mais je me demande si je n'ai pas un peu
présumé de ma compréhension globale, là...

Alors, le DNS est un outil puissant, très utile mais aussi dangereux.
Cela dit, il ne faut pas en avoir peur.

Si tu le trouves encore, le bouquin de Jacques Foucry explique ça très
bien :

<http://www.lmet.fr/fiche.cgi?_ISBN—82952726603>

Sinon, en gros, il faut créer un nom de domaine dans le DNS et entrer au
moins l'adresse IP du serveur, ce qui doit se faire automatiquement si
c'est hébergé sur la même machine. Ensuite, il faut que tes postes
utilisent, serveur compris, uniquement ce DNS et pas ceux de ton FAI. En
gros, dans la config réseau de tes postes tu mets l'adresse IP de ton
serveur dans la case DNS, y compris donc sur le serveur lui-même qui
s'interrogera lui-même.

Bon, est-ce que dans l'utilitaire Format de Répertoire, LDAPv3, tu as
bien le serveur qui se référence lui-même : 127.0.0.1. De même dans
l'onglet Authentification du même utilitaire.

Non mais bon sang mais c'est bien sûr ! ;-)

:-)

Je m'explique : sur l'onglet "Services", l'activité LDAPv3 est bien
cochée (version 1.7.4). Si je clique sur "Configurer", j'ai les
informations suivantes (j'ai cliqué sur "masquer les options" pour voir
un maximum d'infos) :
- Décoché => "Ajouter les serveurs LDAP fournis par DHCP aux règles de
recherche automatique"
- Tableau "Activer ; Nom de la configuration ; Nom serveur/adresse IP ;
Mappages LDAP ; SSL" => complètement vide

Par contre, j'ai bien /LDAPv3/127.0.0.1 dans l'onglet
"Authentification".

Du coup, j'ai ajouté une ligne dans le tableau dans "Services" avec
comme adresse IP 127.0.0.1... Et ça marche !!!

Joie.

Quand même, je me pose une question : comment cette ligne a-t-elle pu
"disparaître" ? Je veux dire par là : quelle énorme gourance ai-je
commise pour en arriver là ???

Ah ça, je ne sais pas. J'ai vu une fois une MAJ en 10.3.x enlever cette
ligne, sans que j'arrive à le reproduire.

Bon et quand je dis que ça marche, ce n'est pas tout à fait exact...
J'ai de nouveau accès à mes dossiers partagés avec les logins de mes
comptes paramétrés par Gestionnaire de Groupe de Travail. J'ai également
pu de nouveau accéder à Gestionnaire de Groupe de Travail et tous mes
comptes et groupes sont bien présents tels qu'avant la "disparition".

C'est un bon début.

Par contre, Mail.app n'arrive toujours pas à se connecter avec le
serveur... Ceci dit, l'erreur a changé de type : maintenant, c'est
"Erreur détectée par le serveur : Échec de la tentative de lecture de
données depuis le serveur licorne.local" (Licorne est le nom de mon
serveur).

Plus étrange, dans les logs du service "Courrier", j'ai bien la
connexion de l'utilisateur sans message d'erreur...

Mmmm, est-ce que les boîtes IMAP ne sont pas vérolées, ça peut aussi
arriver. Essaie de les reconstruire avec Admin Serveur. Attention, si tu
reconstruis tu perdras les flags indiquant que les messages sont lus.

Sinon, tu peux essayer avec SirAdmin :

<http://blogs.cofa.unsw.edu.au/blog/nigelkersten/osxserver/?permalink=Si
rAdmin-a-GUI-replacement-for-cyradm.html&smm=y>

Lire l'aide pour savoir comment le configurer.

Que donne cette commande :

$ dscl localhost -list /LDAPv3/127.0.0.1/Users

[Avant la correction]

list: Invalid Path

[Après la correction]

la liste de mes users

Ca, c'est normal, il avait perdu la connexion avec lui-même et donc ne
pouvait s'interroger pour se répondre.

En tout cas, déjà mille mercis !!! J'ai de nouveau accès "normalement"
aux répertoires partagés.
Il ne me manque plus que l'accès à mon compte imap... Surtout que ce
sont toutes les archives de mes messages électroniques des 3 ou 4
dernières années ! Plus tout mon courrier professionnel "traité"...
Bref, plein de messages que j'aimerai autant ne pas perdre ! :-)

Ils ne doivent pas être loin, il faut juste faire comprendre à Cyrus que
tout est revenu.

As-tu essayé de relancer le service de courrier ?

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

MagalieJ <mag@lery.nom.fr> wrote:

Si tu le trouves encore, le bouquin de Jacques Foucry explique ça très
bien :

<http://www.lmet.fr/fiche.cgi?_ISBN—82952726603>

Héhé, je l'ai reçu ce matin tout chaud par un charmant livreur ! J'en
suis déjà à la page 121. Bon, je ne vais pas pouvoir tout l'avaler dans
la journée non plus : faut que je bosse pour mes clients aussi un peu !
;-)

Quand même, je me pose une question : comment cette ligne a-t-elle pu
"disparaître" ? Je veux dire par là : quelle énorme gourance ai-je
commise pour en arriver là ???

Ah ça, je ne sais pas. J'ai vu une fois une MAJ en 10.3.x enlever cette
ligne, sans que j'arrive à le reproduire.

Bon, on peut donc mettre ça sur une énorme malchance et peut-être se
dire que je n'ai pas fait une grosse bêtise, alors ! Chouette ! Mon
amour-propre se requinque, là ! :-)

Mmmm, est-ce que les boîtes IMAP ne sont pas vérolées, ça peut aussi
arriver. Essaie de les reconstruire avec Admin Serveur. Attention, si tu
reconstruis tu perdras les flags indiquant que les messages sont lus.

J'avais déjà remarqué que les logs de l'admin m'indiquait la connexion
de l'utilisateur presque normalement alors que du côté client, j'avais
mon petit drapeau "attention, problème".

Jun 12 16:03:59 Licorne imap[7083]: login: phenix.local
[fe80::211:24ff:febf:9ac1%en0] diradmin plaintext User logged in
Jun 12 16:03:59 Licorne master[6988]: process 7083 exited, signaled to
death by 10

J'ai d'abord essayé en donnant à un autre utilisateur le droit d'avoir
un compte. J'ai ajouté ce compte à Mail (sur mon client). Enfin je n'ai
pas été au bout de la procédure, mais juste jusqu'à la vérification de
la connexion sur le serveur et celle-ci fonctionne parfaitement.
J'ai donc essayé de reconstruire la base et là, j'ai eu droit à ça dans
les logs :

Jun 12 16:17:03 Licorne ctl_cyrusdb[8729]: verifying cyrus databases
Jun 12 16:17:03 Licorne ctl_cyrusdb[8729]: skiplist: recovered
/var/imap/mailboxes.db (58 records, 8300 bytes) in 0 seconds
Jun 12 16:17:03 Licorne ctl_cyrusdb[8729]: skiplist: recovered
/var/imap/annotations.db (0 records, 144 bytes) in 0 seconds
Jun 12 16:17:03 Licorne ctl_cyrusdb[8729]: done verifying cyrus
databases
Jun 12 16:17:14 Licorne imap[8513]: DBERROR db4: PANIC: fatal region
error detected; run recovery
Jun 12 16:17:14 Licorne imap[8513]: DBERROR: critical database situation
Jun 12 16:17:14 Licorne master[6988]: service imap pid 8513 in READY
state: terminated abnormally
Jun 12 16:17:16 Licorne imap[8756]: login: phenix.local
[fe80::211:24ff:febf:9ac1%en0] diradmin plaintext User logged in
Jun 12 16:17:17 Licorne master[6988]: process 8756 exited, signaled to
death by 10


C'est pas bon, ça...

Je l'ai relancé un peu après et j'ai eu :

Jun 12 16:26:30 Licorne ctl_cyrusdb[9929]: verifying cyrus databases
Jun 12 16:26:30 Licorne ctl_cyrusdb[9929]: skiplist: recovered
/var/imap/mailboxes.db (58 records, 8300 bytes) in 0 seconds
Jun 12 16:26:30 Licorne ctl_cyrusdb[9929]: skiplist: recovered
/var/imap/annotations.db (0 records, 144 bytes) in 0 seconds
Jun 12 16:26:30 Licorne ctl_cyrusdb[9929]: done verifying cyrus
databases
Jun 12 16:28:24 Licorne imap[10168]: login: phenix.local
[fe80::211:24ff:febf:9ac1%en0] diradmin plaintext User logged in
Jun 12 16:28:25 Licorne master[6988]: process 10168 exited, signaled to
death by 10

Sinon, tu peux essayer avec SirAdmin :

Je télécharge, j'installe, j'essaie et je voie ce que ça fait !

As-tu essayé de relancer le service de courrier ?

Vi. Même punition... Mais je sens que j'en vois le bout, là (enfin avec
votre aide, parce que toute seule...) ! J'ai retrouvé une lueur
d'espoir. Merci !

--
Mag'

MagalieJ <mag@lery.nom.fr> wrote:

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

Sinon, tu peux essayer avec SirAdmin :

Je télécharge, j'installe, j'essaie et je voie ce que ça fait !

J'ai téléchargé, installé, paramétré et j'accède à la liste de mes
boites. Signe qu'elles n'ont pas disparues...
Cependant, la reconstruction n'a rien donné... Que puis-je faire de plus
???

Extrait des logs au moment de l'intervention SirAdmin :

Jun 12 17:01:30 Licorne imap[14346]: login: phenix.local
[fe80::211:24ff:febf:9ac1%en0] cyrusadmin plaintext User logged in
Jun 12 17:02:00 Licorne imap[14413]: Reconstructing 'user.diradmin' (not
recursive) for user 'cyrusadmin'
Jun 12 17:02:00 Licorne imap[14414]: Regenerating quota roots starting
with 'user.diradmin' for user 'cyrusadmin'

--
Mag'

MagalieJ <mag@lery.nom.fr> wrote:

Cependant, la reconstruction n'a rien donné... Que puis-je faire de plus
???

Recontruire la base principale :

<http://docs.info.apple.com/article.html?artnum7996>

Prendre la seconde partie.

Attention, je te l'ai déjà dit, on perd les flags messages lus.

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

MagalieJ <mag@lery.nom.fr> wrote:

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

<http://www.lmet.fr/fiche.cgi?_ISBN—82952726603>

Héhé, je l'ai reçu ce matin tout chaud par un charmant livreur ! J'en
suis déjà à la page 121. Bon, je ne vais pas pouvoir tout l'avaler dans
la journée non plus : faut que je bosse pour mes clients aussi un peu !
;-)

Bonne lecture :)

Ah ça, je ne sais pas. J'ai vu une fois une MAJ en 10.3.x enlever cette
ligne, sans que j'arrive à le reproduire.

Bon, on peut donc mettre ça sur une énorme malchance et peut-être se
dire que je n'ai pas fait une grosse bêtise, alors ! Chouette ! Mon
amour-propre se requinque, là ! :-)

Ca rassure hein ?

Mmmm, est-ce que les boîtes IMAP ne sont pas vérolées, ça peut aussi
arriver. Essaie de les reconstruire avec Admin Serveur. Attention, si tu
reconstruis tu perdras les flags indiquant que les messages sont lus.

J'avais déjà remarqué que les logs de l'admin m'indiquait la connexion
de l'utilisateur presque normalement alors que du côté client, j'avais
mon petit drapeau "attention, problème".

Jun 12 16:03:59 Licorne imap[7083]: login: phenix.local
[fe80::211:24ff:febf:9ac1%en0] diradmin plaintext User logged in
Jun 12 16:03:59 Licorne master[6988]: process 7083 exited, signaled to
death by 10

Pas bon...

J'ai d'abord essayé en donnant à un autre utilisateur le droit d'avoir
un compte. J'ai ajouté ce compte à Mail (sur mon client). Enfin je n'ai
pas été au bout de la procédure, mais juste jusqu'à la vérification de
la connexion sur le serveur et celle-ci fonctionne parfaitement.
J'ai donc essayé de reconstruire la base et là, j'ai eu droit à ça dans
les logs :

Jun 12 16:17:03 Licorne ctl_cyrusdb[8729]: verifying cyrus databases
Jun 12 16:17:03 Licorne ctl_cyrusdb[8729]: skiplist: recovered
/var/imap/mailboxes.db (58 records, 8300 bytes) in 0 seconds
Jun 12 16:17:03 Licorne ctl_cyrusdb[8729]: skiplist: recovered
/var/imap/annotations.db (0 records, 144 bytes) in 0 seconds
Jun 12 16:17:03 Licorne ctl_cyrusdb[8729]: done verifying cyrus
databases
Jun 12 16:17:14 Licorne imap[8513]: DBERROR db4: PANIC: fatal region
error detected; run recovery
Jun 12 16:17:14 Licorne imap[8513]: DBERROR: critical database situation
Jun 12 16:17:14 Licorne master[6988]: service imap pid 8513 in READY
state: terminated abnormally
Jun 12 16:17:16 Licorne imap[8756]: login: phenix.local
[fe80::211:24ff:febf:9ac1%en0] diradmin plaintext User logged in
Jun 12 16:17:17 Licorne master[6988]: process 8756 exited, signaled to
death by 10

IMAP vérolé... cf mon message en réponse au tien après.

As-tu essayé de relancer le service de courrier ?

Vi. Même punition... Mais je sens que j'en vois le bout, là (enfin avec
votre aide, parce que toute seule...) ! J'ai retrouvé une lueur
d'espoir. Merci !

De nada.

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

Recontruire la base principale :
<http://docs.info.apple.com/article.html?artnum7996>
Prendre la seconde partie.

Alleluia !!!! Ça y est ! J'ai perdu des heures de boulot, mais j'ai
beaucoup appris, sur ce coup-là !!!

Attention, je te l'ai déjà dit, on perd les flags messages lus.

Vraiment un moindre mal à côté de tout perdre !!! ;-)

Merci infiniment !!! Et SirAdmin m'a vraiment beaucoup plu aussi et m'a
ouvert des horizons inattendus...

Promis, je lis le bouquin avant de revenir poser des questions !
--
Mag'

MagalieJ <mag@lery.nom.fr> wrote:

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

Recontruire la base principale :
<http://docs.info.apple.com/article.html?artnum7996>
Prendre la seconde partie.

Alleluia !!!! Ça y est ! J'ai perdu des heures de boulot, mais j'ai
beaucoup appris, sur ce coup-là !!!

Euh, perdu... Ah, le temps :-)

Attention, je te l'ai déjà dit, on perd les flags messages lus.

Vraiment un moindre mal à côté de tout perdre !!! ;-)

Clair, mais il faut le savoir quand on n'est pas seul concerné.

Merci infiniment !!!

Mais de rien. Euh, je mets la facture à quel nom ? ;-)

Et SirAdmin m'a vraiment beaucoup plu aussi et m'a
ouvert des horizons inattendus...

Regarde, dans l'aide, la notion de boîtes partagées. Très pratique.

Promis, je lis le bouquin avant de revenir poser des questions !

Bonne et saine lecture.

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

MagalieJ <mag@lery.nom.fr> wrote:

Ah ! Un rayon de soleil dans ma compréhension du système ! Je comprends
maintenant ce que c'est que ce "mDNS" et à quoi il sert ! Merci !

De rien :)
En fait je ne suis pas coutumier des problèmes réseau donc ça me fait
une révision, c'est très bien pour moi aussi.

Ma configuration exacte est : "modem câble" + lien ethernet sur port Wan
d'une borne Airport Extreme + lien ethernet de la borne sur le MacMini
J'ai changé la config matérielle ce WE.

Le NAT est effectivement sur la borne (même si je ne l'ai pas
re-paramétré suite à mes modifs du WE). Il ne me semble pas qu'il y ait
de DNS ni sur le modem ni sur la borne. Quant au DHCP, il est activé sur
la borne.

Ok.
Manque quelques info :
Quel est l'IP du modem-routeur
Quel est l'IP de la borne

Quel est le range dhcp du modem
Quel est le range dhcp de la borne

Quel est le netmask reçu par ces dhcp ?
Le netmask est il correct sur le serveur ?

Le mac mini peut-il communiquer de façon transparente avec les machines
en wifi ?

(...)

dig @10.0.1.1 -x 10.0.1.1

Ici, quelle machine a cette IP ?

; <<>> DiG 9.3.4 <<>> @10.0.1.1 -x 10.0.1.1
; (1 server found)
;; global options: printcmd
;; Got answer:

Cette dernière ligne signifie :
J'ai reçu une réponse de la part de la machine "@10.0.1.1".
Donc la machine (ou borne, ou modem) qui a cette adresse est un dns.

;; [snip]

Il manque le "ANSWER SECTION".
Donc ce dns ne connais même pas sa propre adresse :)
Etrange. Je ne pratique pas les bornes wifi ni les modem adsl, donc je
ne sais pas si c'est normal mais ça ne me parait pas souhaitable.

dig -x @10.0.1.254 10.0.1.1

Ici, juste pour expliquer la commande :
dig est un outil qui interroge les dns

@10.0.1.254 spécifie qu'on ne veux pas interroger le premier serveur
vennu, mais spécifiquement celui qui a cette IP.

-x signifies : 'Quel est le nom de domaine de telle adresse IP ?'.
On parle alors de résolution inverse

Enfin la dernière partie, "10.0.1.1" est l'objet de la question :
Quel est le hostname de cette IP, en l'occurence.

;; ANSWER SECTION:
10.0.1.1. 655360 IN A 10.0.1.1

Ici on a la réponse du dns :
il ne connais pas de hostname pour cette IP.
Soit cette IP est dans ses "compétances" mais personne n'a pris la peine
de lui donner un hostname, soit cette IP "ne lui appartient pas" mais il
ne sais pas à quel autre DNS demander pour avoir ue réponse
Note que dans un dns (dumoins celui de M$, je ne les connais pas tous),
il y a 2 tables : une pour les requêtes d'IP et une pour les "reverse".
Il est donc possible d'avoir des erreur où un hostname aboutit à une IP
mais la question inverse n'aboutit pas à un hostname.

Je ne suis pas sûre de bien comprendre les informations fournies par
"dig" (en fait, je suis même sûre de ne rien comprendre pour le moment
!)...

En fait c'est "assez simple", il y a des sections explicites :
QUESTION SECTION et ANSWER SECTION, pour citer les principales.
la première décrit la question, la seconde donne la réponse :)
Il y a également des info complémentaires comme
SERVER: xxx.xxx.xxx.xxx qui indique l'IP du serveur dns qui a répondu.
Si ce serveur n'est pas "authoritatif", c'est à dire que le hostname
n'est pas chez lui et qu'il a dû demander à un autre DNS, alors tu auras
une section "AUTHORITY SECTION" qui dit qui ton dns a dû interroger pour
obtennir la réponse.

Cependant, je n'avais pas mis en route le service "DNS" tout de suite et
pourtant, mon serveur IMAP fonctionnait... Là, j'ai essayé plusieurs
choses, mais je ne vois pas pourquoi il n'arrive plus à se connecter sur
le compte de l'utilisateur...

avant tu étais en wifi sur le serveur, si j'ai tout suivis, et à présent
il est câblé et tu attaques depuis un client wifi. C'est peut-être ça la
différence. Les logs disent quoi ?
(regarder dans /Applications/Utilities/Console.app )

Tu peux aussi tenter de mettre dans les réglage du client IMAP l'IP du
serveur au lieu de son nom, pour éviter les problèmes de dns.

Bon courrage :)

--
Nicolas