je me doutais bien qu'un tel netmask était destiné à une organisation de grande taille
Je suis curieux d'avoir un retour sur le fonctionnement de Zentyal dans ces conditions.
Ayant mis en places des solutions d'IAM dans d'autres environnement, je me demande bien comment l'interface de Zentyal peu être utilisée pour gérer un nombre significatif de comptes et de groupes. Idem en ce qui concerne la gestion d'un nombre important de partages.
Mais ça marche peut-être. Tout retour est le bienvenu bien sûr.
Il n'y a par exemple, sauf si ce point a été corrigé récemment, pas de possibilité de déplacer un compte LDAP d'une OU à une autre. Le mode multi-branche est donc peu utile pour le moment. De même le schéma LDAP est difficilement modifiable, ce qui peut poser des problèmes pour des applications clients. A ce propos, il faut noter que le port LDAP (en 389
) n'est par défaut pas ouvert en dehors du serveur car dans le design initial, ce serveur LDAP est destiné à Zentyal et non pas au appli externes.
Je ne suis pas en train de dire qu'il ne faut pas essayer mais je pense qu'il est bon également de comprendre ou au moins d'essayer d'appréhender les limites de l'exercice.
Pour le netmask: un workaround, si Zentyal n'est pas serveur DHCP (et j'espère que c'est le cas car dans ce domaine, ce n'est pas nom plus la meilleure solution
) : Il suffit de mettre le serveur Zenryal derrière un routeur, dans un subnet réduit et de propager ailleurs sur le réseau une route vers le serveur Zentyal. Le problème de netmask n'en est alors plus un.... à condition que les protocoles mis en œuvre soient routables
Topic: Définir un netmask à 255.252.0.0 sur une interface (Read 1708 times)