Ubuntu-fr

Il faudrait une copie de ton LDIF.

Dans un DIT LDAP, chaque entrée doit avoir un seul objectclass dit structural. La définition des objectclass étant faite sous la forme d'un arbre d'héritage, c'est le dernier objectclass dans la branche qui compte.

Par exemple, si l'objectclass structural C hérite de l'objectclass structural B qui hérite de l'objectclass structural A, une entrée FOO qui a comme objectclass C a aussi comme objectclass B et A. Mais comme il y a un héritage, on est dans la même branche, et donc il n'y a pas de problème (en fait, on ne devrait même pas voir les objectclass B et A, puisqu'elles sont impliquées par la présence de C, mais dans les faits et pour des raisons technico-historiques, les objectclass A et B apparaîtront). Par contre si tu as un objectclass structural D qui hérite de l'objectclass A, tu ne peux pas avoir une entrée qui ait à la fois l'objectclass C et l'objectclass D. C'est normal, un objectclass structural est ce qui ...structure.. le plus ton entrée.

Si tu as besoin de combiner des objectclass pour une même entrée, tu utilises une seule objectclass structural, et des objectclass auxilliaires pour rajouter les attributs qu'il te manque.

Donc la première chose à faire, c'est de définir comment tu va structurer les entrées qui tu manipules en terme d'objectclass, puis d'attributs.

Tu peux utiliser des navigateurs LDAP qui te permettent d'avoir plus d'information sur les objectclass et les attributs. A ce titre, Apache Directory Studio est bien plus performant que LdapBrowser.

Moi j'ai résolu le problème de la façon suivante: j'ai un utilisateur du nom du groupe voulu, et qui a comme nom et id le nom et id du groupe (par exemple UID=home,GID=gprhome)

Je monte le partage avec NFS en précisant comme UID/GID cet utilisateur et ce groupe, et en forçant les droits à 770.

Les membres du groupes font tous partie du groupe gprhome. Ils peuvent tous lire et écrire. Problème: s'ils écrivent, par défaut les fichiers et répertoires auront leur propre masque et pas ceux du groupe. J'ai donc une tâche périodique qui force le propriétaire et le groupe de chaque fichier/répertoire pour mettre celui du groupe.

Sinon je pense qu'on peut utiliser les options de montage des partitions en montant la partition vue par le client NFS chez tous les membres du groupe. Mais je n'ai jamais essayé.

SSH se fiche bien de savoir combien une machine à de coeurs ou pas. Je pense que ton problème est ailleurs. Vraiment.

ensuite toutes tes machines ont au moins 2 adresses IP pusiqu'elles sont reliés à un commutateur: localhost et une autre. Quand tu utilises localhost, alors tu envoie un paquet dans l'interface virtuelle de loopback de la machine, et ça ne passe même pas par la couche réseau matériel (la carte). Si tu utilises l'adresse IP 192..., alors le paquet est envoyé à la carte réseau, mais normalement elle résout directement l'adresse, puisque c'est elle même: tu ne passes pas par le fil et le commutateur.

l'avantage de localhost, c'est que si ta carte réseau n'est pas branchée, elle n'est pas configurée, et l'adresse IP 192xxx n'est pas connue, alors que localhost n'est pas rattaché à une carte: l'adresse existe toujours.

upstart est un simple script shell:

$ file /lib/init/upstart-job 
/lib/init/upstart-job: POSIX shell script, ASCII text executable

si tu regardes ce qu'il fait, il encapsule le démarrage des commandes start, stop, status... qui sont dans /sbin.

Ces commandes sont des liens vers initctl:

$ ls -alF /sbin | grep initctl
-rwxr-xr-x  1 root root   198936 janv. 18 17:09 initctl*
lrwxrwxrwx  1 root root        7 janv. 18 17:09 reload -> initctl*
lrwxrwxrwx  1 root root        7 janv. 18 17:09 restart -> initctl*
lrwxrwxrwx  1 root root        7 janv. 18 17:09 start -> initctl*
lrwxrwxrwx  1 root root        7 janv. 18 17:09 status -> initctl*
lrwxrwxrwx  1 root root        7 janv. 18 17:09 stop -> initctl*

qui lui fait le boulot. inittcl est un exécutable binaire.
service, lui, est déclaré dans /usr/bin et est un lien vers le service de /usr/sbin:

$ ls -alF /usr/sbin/service /usr/bin/service
lrwxrwxrwx 1 root root   17 juil. 26  2012 /usr/bin/service -> /usr/sbin/service*
-rwxr-xr-x 1 root root 4768 juil. 26  2012 /usr/sbin/service*

lequel est un script shell. Si tu regardes ce qu'il fait, il encapsule l'appel à start, stop, status, ... pour le service passé en paramètre si celui-ci a été converti à upstart, sinon il utilise l'ancienne méthode. Il détecte si le service est converti à upstart s'il existe un fichier de conf /etc/init/service.conf (ou service est le nom du service).

Conclusion: à la fin on arrive à la même chose. Si le service a été défini dans un script de démarrage dans le répertoire /etc/init.d (nommé par exemple rsyslog) et que c'est un lien vers upstart, alors service rsyslog start, start rsyslog et initctl start rsyslog vont faire la même chose: lire le fichier /etc/init/rsyslog.conf et exécuter ce qui est demandé.

Si tu regardes la conf en question, tu voit les pré-requis, et la commande finalement lancée par initctl: rsyslogd.

Donc pour savoir quel démon est lancé par un script d'init, soit il n'est pas converti à upstart, et on trouve la réponse dans /etc/init.d/service, soit il est converti à upstart et on trouve la réponse dans /etc/init/service.conf.

Finalement ta question m'a permis de creuser un peu upstart. Sympa...

La gestion par script du crontab sous debian est différente.

Tu ne changes pas les ordres via crontab -e. En fait il vaut mieux virer tout ça et utiliser les fichiers dans /etc/cron.{hourly,daily,weekly,monthly} et/ou /etc/cron.d.

En gros tu mets tes fichiers dans ces répertoires et ils sont lus par cron directement.

Par exemple dans /etc/cron.daily, tu mets un fichier ma-moman-a-moi qui contient les 2 commandes en question et ces commandes seront exécutées tous les jours à 06h25.

Les restrictions portent sur les droits d'accès (root ou pas) et le droit d'exécution.

Regardes la page de manuel de cron qui est complète.

Ceci a été fait sous debian pour permettre aux packages de manipuler facilement les cron lors d'installation, mise à jour et suppression. Je crois que ça été copié ensuite sous RedHat.

Sinon c'est une véritable horreur.

Normalement, le mot de passe demandé est celui du compte ayant les droits admin. Je suppose qie c'est ton compte.

Quand tu démarres ubuntu, est-ce que tu es connecté automatiquement ou bien tu as une fenêtre de login qui apparaît ?

Quand tu dis ne marche plus, tu ne précises pas en quoi il ne marche plus: rien ne se passe dans l'interface graphique?

Qu'est-ce qui se passe dans un terminal quand tu fais sudo su - ? Il te demande le mot de passe et la que se passe-t-il ?

mount -l

seulement il y a tellement de façon d'avoir une partition montée sur un répertoire que gérer tous les cas via la récupération de mount -l me parait un sacré travail....

Tu mélanges un peu plusieurs choses.

d'abord PHP, c'est de la m.... voila, ça c'est fait.

ensuite, PHP c'est un langage de scripting conçu pour le Web.

Postfix, c'est un MTA (Mail Transfert Agent) conçu pour transférer des messages SMTP d'un point à un autre de manière fiable et sécurisée. ca n'a rien à voir avec le Web, et les logs de Postfix sont des logs de messagerie SMTP. Si tu veux voir apparaître des choses spécifiques dans les logs Postfix, alors tu doit te conformer à ce qu'attend Postfix, voir le paramétrer dans la mesure du possible.

Ton script PHP génère un message SMTP. Avec ce que tu as codé, tu t'attends à un certain contenu du message, alors le module mail de PHP ne fait pas tout à fait ce que tu attends, et Postfix se conforme aux nornes. D'ou le résultat qui t'étonnes.

N'étant pas un spécialiste de PHP, dieu soit loué, je ne peux que te conseiller une chose: cherche un autre module de gestion de message SMTP en PHP qui lui te permet de complètement manipuler les messages suivants les normes liées à SMTP (et il y en a plusieurs).

Pour le log, c'est une autre chanson: une application bien faite (comme Postfix) va écrire les logs la ou on lui dit de les écrire. En général, les logs sont écrits:

• soit directement pas l'application dans un fichier de log, souvent dans /var/log, et donc c'est dans le fichier de conf de l'application,

• soit indirectement via un loggeur comme syslog et/ou rsyslog, et donc le fait d'utiliser le loggeur est dans l'application, et l'endroit ou le loggeur mettra les logs est dans la configuration du loggeur,

• soit un mix de tout ça,

Bien dit. Et je rajoute:

• toujours lire les CGU/CGV, c'est très instructif,

• ne jamais croire que la loi nous protège; non pas qu'elle ne le fait pas, mais elle le fait probablement pas comme on le pense...

Oui, c'est du temps perdu.

On ne monte pas un serveur LDAP en cluster de cette manière.

Les serveurs LDAP sont conçus pour supporter nativement la réplication au fil de l'eau, et la reprise de réplication en cas d'arrêt d'un des noeuds: c'est une configuration en maître-esclave. Par définition, l'esclave ne sert qu'en lecture, pas en écriture.

Les serveurs LDAP sont conçus pour supporter nativement la réplication croisée, et la reprise de réplication en cas d'arrêt d'un des noeuds: c'est une configuration en double-maîtres.  Par définition, les deux noeuds supportent les lectures et écritures et se répliquent mutuellement.

Enfin OpenLDAP supporte le mode mirroir: les 2 noeuds sont maîtres, mais un seul récupère les écriture, on bascule le mirroir de l'un à l'autre au moment voulu.

Tu peux combiner le mode multi maître et le mode maître esclave si tu veux de la redondance, de la répartition de charge et équilibrer un peu logiquement les accès: 2 noeuds maitres qui se répliquent mutuellement et qui répliquent sur 2 noeuds esclaves. La seule chose qui est gérée par le cluster est une bascule des adresses IP de service (ou la bascule du mode mirroir si tu optes pour ce mode la).

Je gère un gros annuaire au boulot dans ce mode avec pas mal de clients en lecture/écriture, et ça marche bien.

Normal pour le slapd.conf: ça n'existe plus. Maintenant la config est gérée directement dans le LDAP, dans la branch cn=config.

Le principe: tu installes ton serveur, tu crées à la main un fichier LDIF contenant la config au format LDIF, tu fait un slapadd sur ta base en tant que root (le compte Unix), et la config est dans le serveur. La config contient aussi les définitions des droits d'accès à l'arbre LDAP de production (un truc du genre dc=MaSociete.fr), et aussi la déclaration du compte Manager de l'arbre de production. Ensuite tu peux gérer un certain nombre de paramètre avec un navigateur LDAP (mais pas tout quand même) si tu connait le mot de passe du compte cn=Config.

La différence en mode mirroir et mode multi-master est très fine. Il faut de toute façon déclarer le multi-master comme un mode mirroir, mais en plus mettre des réplicats dans les 2 sens. Le multi-master est un avantage si tu as une charge importante sur le maître que tu répartis alors avec un load-balancer (HAProxy pu BalanceNG par exemple). Ca permet d'être plus souple en production aussi (tu arrêtes un des 2 noeuds sans trop te préoccuper des impacts). Le miroir est plus "sûr" côté intégrité de données (un seul endroit ou les modifications arrivent) mais il faut être sûr qu'en cas de bascule des flux, tu récupères correctement tes petits.

Aprsè je comprend pas ta notion de back-end et front-end.

C'est pas plutôt ça que tu veux ? Ou encore ça ?

Je ne suis pas sûr qu'on puisse installer un service de messagerie complet qui marche impeccablement (pas question de rater une commande en cuisine, hein) en 1/2 journée quand on ne l'a jamais fait.