Archive for Mac OS X Server

TechnoIT fait le point sur Apple en entreprise

J’ai été invité il y a quelques jours par Lionel du blog TechnoIT à participer à une de ses émissions diffusée en balladodiffusion©™® [1]. Et imaginez-vous qu’à peine enregistrée hier soir, l’émission est déjà en ligne ! Un grand merci à Lionel donc pour ce débat de haute volée sur l’implication d’Apple en entreprise. Vous verrez qu’on y parle vraiment de tout : de Mac, de Mac OS X Server, d’iPad, d’iPhone, de déploiement, d’intégration… L’émission s’écoute donc sur le blog de TechnoIT, et vous pouvez vous abonner directement à son podcast ici ! Et vous pouvez suivre TechnoIT sur Twitter.

  1. Je sais, c’est ridicule.

MacSysBrain #2 à Lyon !

C’est officiel : la conférence MacSysBrain numéro 2 aura lieu à Lyon entre le 16 et 22 octobre au sein de l’université Lumière Lyon 2 (ma fac… Snif !). Plus de détails sur le site.

Et je vous rappelle que le premier épisode (avec ma maaaaagnifique conf sur les ACL) se trouve ici !

VPN et Open Directory : quand ça coince

Il arrive (trop régulièrement) que, pour une raison inconnue (appelons-ça un bug, c’est plus simple), des utilisateurs qui s’authentifient à l’aide d’un compte Open Directory sur un serveur VPN tournant sous Mac OS X Server ne puissent plus se connecter. Il leur est alors répondu que le serveur VPN ne répond pas correctement. Curieusement, les comptes locaux du serveur arrivent toujours à se connecter.

Si cela vous arrive, tentez tout d’abord simplement de redémarrer le service Open Directory. Pour cela, le plus simple est de cocher la case Activer SSL dans Server Admin > Open Directory > Réglages > LDAP. Enregistrez la modification, puis décochez la case et enregistrez à nouveau immédiatement.

Si cela ne suffit pas, il faudra peut-être réinitialiser un compte spécifique du serveur. Pour cela :

– Ouvrez le Gestionnaire de groupe de travail ;
– Dans le menu Présentation, cochez Afficher les fiches système ;
– Dans la liste des utilisateurs Open Directory (branche /LDAPv3/127.0.0.1), cherchez l’utilisateur de UID 57 : son nom est VPN MPPE Key Access User.

– Sélectionnez-le, et… supprimez-le.
– Stoppez le service VPN (avec Server Admin, ou en utilisant la commande sudo serveradmin stop vpn.
– Ouvrez le Terminal, et tapez la commande suivante :
sudo /usr/sbin/vpnaddkeyagentuser /LDAPv3/127.0.0.1
Validez en tapant votre mot de passe d’administrateur.
– Redémarrez le service VPN.

Si tout va bien, cela recréera la fiche VPN MPPE Key Access User et vos utilisateurs Open Directory pourront enfin se connecter en VPN.

Boot Camp et Mac OS X Server : mais si, ça marche !

MacGeneration se fait l’écho d’un article d’Apple qui explique que Boot Camp n’est pas officiellement supporté avec Mac OS X Server.

Alors attention : non supporté, chez un constructeur, ça veut dire « on n’apporte pas de support en cas de problème technique ». En réalité, ce qui se passe est que l’assistant Boot Camp n’est pas installé quand on installe Mac OS X Server et (et c’est le point le plus sensible) les pilotes Boot Camp que l’on installe sous Windows ne sont pas livrés avec le DVD de Mac OS X Server.

Donc, a priori, Apple a raison : on ne peut pas installer Windows sur son Mac s’il est pré-équipé de Mac OS X Server… et si c’est un XServe. Mais sur un Mac Pro ou un Mac mini Server, on peut très bien :
– créer une partition DOS sur votre disque dur à la main avec Utilitaire de disque ;
– démarrer sur un DVD Windows pour lancer l’installation ;
– et installer les pilotes Boot Camp en utilisant un DVD de Mac OS X version client. Ce qui ne pose donc pas de souci pour le Mac Pro ou pour le Mac mini : si vous connaissez quelqu’un qui dispose du DVD d’installation de Mac OS X d’une de ces machines, il vous faut juste vous le procurer pour pouvoir ensuite installer Windows. En revanche, pas de solution pour les Xserve : le seul DVD qu’ils acceptent, c’est celui de Mac OS X Server (normal).

L’article d’Apple pourrait donc faire croire que l’installation de Windows n’est pas possible si votre Mac est pré-équipé de Mac OS X Server… C’est faux (heureusement). Facile, pas forcément, mais faux, du moins pour les Mac Pro et les Mac mini Server.

Et pour ceux qui se demandent qui peut donc bien vouloir utiliser Windows sur une machine qui aurait déjà Mac OS X Server installé… ben y’a moi, et c’est suffisant, nan mais !

Conférence : Voyage au pays des ACL

J’ai eu le plaisir d’être invité il y a quelques semaines à la première conférence MacSysBrain des administrateurs Mac francophones. J’y ai présenté une conférence de 20 mn environ, que vous pouvez désormais télécharger par ici. Elle est consacrée aux fameuses Listes de Contrôles d’Accès (les ACLs) et leur intégration dans Mac OS X Server. Vous pourrez également découvrir avant ma conf une présentation de Yoann Gini sur la fameuse technologie Wide Area Bonjour, alors que Franck Lefèbre s’est attaqué à SSH.

Bon visionnage !

Sous les (pa)VPN, la plage (IP)

C’est l’été, période propice aux tests… Alors voici un petit article technique, ça faisait longtemps hein ?

Depuis quelques années, les technologies VPN ont permis de faciliter l’accès à distance aux réseaux des entreprises. Petit rappel rapide de la technologie : en se connectant à l’aide d’un client VPN, un ordinateur situé à l’extérieur du réseau d’une entreprise établit un tunnel sécurisé vers un serveur VPN et ainsi se connecter au réseau de l’entreprise comme s’il s’agissait d’une connexion locale.

Dans l’absolu, cette technologie est géniale. Pour quelqu’un d’assez mobile comme moi, elle permet de me connecter aux ordinateurs des réseaux de mes clients pour corriger rapidement un dysfonctionnement ou mettre en place un service. Dans la pratique, elle est la plupart du temps aussi efficace qu’annoncée en théorie.

Il y a cependant un point parfois gênant. Quand vous configurez un routeur, il est par défaut configuré sur la plage 192.168.0.1/24 ou 192.168.1.1/24. Et on la laisse par défaut sur cette plage, sans se poser de questions. Et on monte donc son réseau sur cette plage, en se disant que ça va bien youpi. Et à mon goût, c’est une erreur.

En effet, lorsqu’un client VPN se connecte sur votre réseau, il va se voir attribué une adresse IP privée de votre plage distante. Mais que se passe-t-il si ce client est déjà connecté côté LAN sur un réseau utilisant la même plage que la plage distante ?

Voyez-vous où se trouve le problème ?

Cas concret : ma machine est sur un réseau en 192.168.1.1/24. Elle a l’adresse IP 192.168.1.2. Maintenant, je me connecte sur un réseau VPN dont la plage privée est également 192.168.1.1/24. Que se passe-t-il si, lors de la connexion distante, vous devez vous connecter vers un serveur en 192.168.1.100 ? Est-ce que votre client va devoir chercher cette adresse sur son réseau LAN, ou sur le réseau VPN ?

C’est là qu’il faut être futé. Car si on ne fait pas attention, boum, on se retrouve avec une connexion qui se fait, mais des postes distants inaccessibles. La meilleure solution est d’utiliser une plage réseau inutilisée d’habitude. Vous avez là l’embarras du choix, moi par exemple j’utilise une plage en 10.0.254.0/24 (et je vous interdis d’utiliser la même, non mais). Le tout est d’avoir une plage qui risque peu d’être utilisée en dehors de votre entreprise, 192.168.192.0, 10.0.77.0, 172.16.25.0… Vous choisissez. Mais PAS les plages par défaut !!!

Avec Mac OS X Server comme serveur VPN, il y a quelques astuces qui permettent cependant de limiter la casse sans changer tout le réseau. La première est d’ajouter dans les réglages du service VPN (avec Server Admin) la définition de votre réseau local. Ça permet au poste distant de mieux retrouver ses petits.

Ma plage est en 10.0.254.0, je l'ai donc définie comme plage privée dans mon VPN.

Une autre idée : dans les réglages du VPN côté client, vous pouvez forcer à envoyer tout le trafic réseau sur la connexion VPN distante. Attention : cela signifie que vos périphériques locaux ne fonctionneront plus…

En envoyant tout le trafic sur la connexion distante, vous augmentez les chances d'accéder à vos périphériques distants.

Voilà, vous savez tout. Mais vraiment, vraiment, si vous souhaitez limiter la casse, je vous invite à changer votre plage réseau si ce n’est pas déjà fait. Certes, cela demande une certaine planification pour les parcs importants, mais cela vous simplifiera certainement la vie dans le futur…

Tour de France Mac OS X Server à Lyon

En plus des dates que j’ai rajoutées ces jours-ci dans l’article précédent, je serai chez Ephesus dans la capitale des Gaules le 13 juillet pour une session unique le matin (10h – 13h).

Il y aura sûrement un formulaire à remplir sur le site pour s’inscrire, je vous tiens au courant.

Et pour ceux qui aimeraient voir plus de mises à jour du blog en ce moment, ben je suis juste un peu débordé, mais ça va reviendre sous peu, promis ! Vous pouvez toujours me suivre sur Twitter si vous avez du temps à perdre :)

Tour de France Mac OS X Server : c’est parti ! (MàJ)

Hop, c’est bientôt l’été, et on va faire chauffer les processeurs des serveurs. Si vous avez envie d’en savoir plus sur Mac OS X Server, je présenterai les solutions autour de Mac OS X Server et du Mac mini serveur durant les prochaines semaines, dans le cadre des séminaires Apple pour l’entreprise. Au programme, tout ce que vous voulez savoir sur Snow Leopard Server et le Mac mini Serveur, un produit dont j’ai déjà dit tout le bien que je pensais ici.

Marquez donc dans votre calepin, tout ça va se passer :

– Chez DXM Brest, le 8 juin à 10h et 14h ;
– Chez DWM Rennes, le 9 juin à 10h et 14h ;
– Chez DXM Nantes, le 11 juin à 10h et 14h ;
Attention, inscription obligatoire par ici !

Je serai également :
– Chez O2i Paris, le 17 juin, à 10h et 14h (lien d’inscription disponible sous peu) ;
– Au Salon des Entrepreneurs de Lyon Rhône-Alpes, toute la journée, les 23 et 24 juin, sur le stand Apple Premium Reseller ;
– Chez iCLG Paris, le29 juin (lien d’inscription bientôt disponible).

Il y aura également (mais là ce sera sans moi) 2 présentations chez O2i Lille le 22 juin (9h et 14h) et O2i Dunkerque le 23 juin (10h et 14h).

Et on m’informe aussi qu’il y aura aussi deux dates en Alsace : le 17 juin à Mulhouse et le 24 juin à Strasbourg avec Bemac.

Et pis si tout va bien, le 1er juillet à Amiens chez iSmith, et le 30/06 à Rennes chez Symbiose.

Et on ajoute :
– Le 18 juin chez iConcept à Anglet ;
– le 23 juin chez Argos à Tours ;
– Le 29 juin à Marseille chez iCLG Pro ;
– Et le 1er juillet à Montpellier chez iTribu .

Venez nombreux ! Et si vous avez envie de vous faire dédicacer votre exemplaire de Snow Leopard Efficace ou Leopard Efficace, n’hésitez pas à venir avec :-)

MàJ : je n’ai peut-être pas été assez clair: pour le moment, les dates affichées sont celles que je CONNAIS. Dès que je connais les dates pour d’autres villes, je vous les transmets. Donc ne vous offusquez pas si votre graaaaaaaaande ville n’est pas référencée : c’est pas parce qu’on ne vous aime pas, juste que je ne connais pas la date ! Voili Voilou :-)

Comprendre et mettre en place Wide Area Bonjour

Yoann Gini a mis en ligne sur son blog quatre exceeeeeellents articles pour implémenter la technologie Wide Area Bonjour avec Mac OS X Server :

Wide Area Bonjour – Introduction et données statiques
Wide Area Bonjour – Une zone modifiable par tous
Wide Area Bonjour – Un peu plus loin dans l’enregistrement
Wide Area Bonjour – Authentification des clients par secret partagé

Et à quoi sert Wide Area Bonjour ? Principalement trois choses :
– Permettre de voir un périphérique sur le réseau dans une zone prédéfinie ;
– Rendre visible des services sur le réseau à l’aide du DNS, y compris à travers Internet ;
– Permettre à des périphériques du réseau d’ajouter leurs propres informations dans le service DNS Bonjour, fort utile là encore pour retrouver des périphériques à distance.

Une technologie magique, que Yoann a décortiqué avec talent, et vu le peu de docs, c’était pas gagné… Bravo à lui !

Supprimer les utilisateurs récalcitrants dans un maître Open Directory

Il arrive parfois que l’on n’arrive pas à supprimer certains comptes d’utilisateurs stockés dans un serveur maître OD. Une erreur est alors renvoyée :

Erreur de type eDSRecordNotFound (-14136) sur la ligne 1993 de /SourceCache/WorkgroupManager/WorkgroupManager-361.2.1/Plugins/UserAccounts/UserAdvancedPluginView.mm

J’ai rencontré ce problème plus d’une fois, et j’ai trouvé pour le moment deux solutions  :
– Basculer le mot de passe de type Open Directory vers un mot de passe chiffré, puis supprimer le compte ;
– Si cela ne suffit pas, une astuce donnée par Fabri dans un fil consacré à ce sujet sur le site de discussion d’Apple : à partir d’Admin Serveur, dans les préférences Open Directory, activez SSL, enregistrez puis désactivez immédiatement SSL et enregistrez à nouveau. Cela forcera l’ensemble des services liés à la partie LDAP du serveur à redémarrer. Vous devriez maintenant pouvoir supprimer les utilisateurs récalcitrants sans trop de difficulté.