Archive for Mac OS X Server

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é.

Mac mini Server : le meilleur serveur ?

(Attention, billet un poil long)

Mini_serveurJe suis tombé comme bien d’autres ce soir sur cet article (dans l’ensemble très bon) sur MacGe à propos du Mac mini Server. Et comme j’ai eu quelques (bon, au moins un) commentaire me demandant mon avis sur cette bécane, je vais non seulement vous donner celui-ci, mais je vais en plus compléter (voire corriger) certains points de l’article susnommé. Car oui, je suis un éternel insatisfait et parfois un véritable enfileur de lépidoptères.

Oh, Mac mini Server, I’ve been waiting for you for so long !

Déjà, mon opinion : le Mac mini Server est exactement la machine que j’attendais d’Apple depuis trop longtemps. Il répond à tout ce qu’on attend d’un produit serveur pour le marché PME/PMI (le SMB – Small and Medium Business – comme on dit dans not’ jargon) :
– Un serveur à tarif accessible, moins de 1000€ TTC ;
– Un produit simple d’emploi, livré sans superflu ;
– Un produit fiable, et là, l’expérience autant que les retours de revendeurs montrent que le Mac mini est un produit dont la fiabilité est parmi les meilleures de tous les produits Apple ;
– Un Mac compact et silencieux, là où les Xserve sont très puissants, très gros et très bruyants ;
– Un serveur capable de gérer l’ensemble des tâches qui lui sont confiées avec un processeur qui tient la route ;
– Deux disques durs, idéal pour améliorer la disponibilité avec du RAID 1 ou les performances avec du RAID 0 (je reviens plus tard sur la sauvegarde) ;
– Pas de lecteur DVD, pas forcément utile sur ce type de configuration (en tout cas bien moins qu’un deuxième disque dur) ;
– Extensible : cinq ports USB 2 et un port FW 800 sont largement suffisants pour la plupart des besoins PME/PMI.

Et encore, j’oublie sûrement quelques-uns des attraits du nouveau Mac mini. Comme serveur de test, c’est une machine idéale, qui supportera même un peu de virtualisation light. Et c’est un serveur qu’on peut emporter partout avec soi ! Envie d’une solution de déploiement qui tient dans un sac à dos ? La voici !

Hello Mac mini, je te présente PME, ta nouvelle amie. Vous allez bien vous entendre tous les deux.

Revenons sur les besoins de l’entreprise. Pour beaucoup de structures, il n’y a pas besoin d’avoir un monstre de puissance comme serveur. J’ai des clients qui utilisent des Mac mini 24h/24 et 7j/7 comme serveurs de mail, de fichiers, de base de données et bien d’autres sans problème majeur. Certes, un argument revient souvent : « le disque dur du Mac mini en 2,5″ est pénalisant en termes de performances ». Pas entièrement faux, mais c’est surtout dû à la vitesse même de ces disques, pas au format (saviez-vous que HP et bien d’autres vendent des solutions de stockage basées sur des disques 2,5″ ?). Et dans bien des cas, les performances du disque seront largement suffisantes par rapport aux besoins : honnêtement, vous pensez que transférer un fichier Word de 100 Ko, ça va fondamentalement plus vite sur un disque 7200 tr/mn par rapport à un 5400 ?

Sur le sujet des performances, il faut bien voir que beaucoup d’entreprises ont des serveurs totalement surdimensionnés par rapport à leurs besoins. Toutes les entreprises n’ont pas un site web à 10000 hits/seconde, ne reçoivent pas 300 e-mails à la minute ou ont besoin de diffuser des vidéos en streaming. Parfois mes clients me demandent s’il ne faut pas changer le serveur car il n’est pas assez puissant, mais ouvrir Server Admin et regarder les courbes d’utilisation mémoire ou CPU confirme en un clin d’œil que la machine est très loin de souffrir.

Il faut voir que pour bien des serveurs, le simple service de partage de fichiers suffit à combler d’aise le client… Mais le package Mac OS X Server + Mac mini est complet, simple à mettre en œuvre, et propose des services qui font parfois bien plaisir : calendriers partagés, wikis, distribution de mises à jour, DHCP, FTP, ou encore VPN (miam) font partie de ces services qu’on peut facilement mettre en place aujourd’hui avec Mac OS X Server. Et le Mac mini, c’est le serveur qu’on pose dans un coin et qu’on peut oublier. Il tourne juste tout seul, sans poser de questions… N’oubliez juste pas de le mettre à jour !

De la bonne utilisation du DNS

Maintenant, revenons sur l’article de MacGe, et en particulier sa deuxième partie. S’il précise à très juste titre que les services Open Directory et DNS sont fondamentaux au bon fonctionnement du serveur (je vous l’ai déjà expliqué ici et là dans une belle fiche pratique), il y a un point sur lequel je vais sensiblement différer : il s’agit du choix du nom de domaine du serveur, et là, attention, je vais causer technique (âmes sensibles s’abstenir).

Selon MacGe : « Nous entrerons, pour l’exemple, serveur.macgeneration.lan. Pourquoi « .lan » ? Pour être certain que la différence est bien visible, votre serveur DNS ne fonctionnera qu’en interne, c’est à dire sur le LAN (Local Area Network) de l’entreprise ou de la maison. Libre à vous d’utiliser l’extension que vous voulez, tant que la structure est bonne. Par exemple, serveur.steve.jobs pourrait tout à fait convenir aussi. »

Là, pas d’accord : il est préférable dès le départ de mettre un nom de domaine correspondant à un Top Level Domain (TLD), même si vous ne l’avez pas acheté. Non, en fait, achetez-le au préalable. Investissez dans un domaine réservé, par exemple en .org ou en .eu (environ 15€ TTC/an), et configurez votre serveur DNS interne avec ce nom . Pourquoi ? Imaginez la situation : vous utilisez votre ordinateur portable, vous êtes connecté à l’intérieur de votre réseau, et quand vous vous connectez à votre wiki, vous devez aller sur serveur.macgeneration.lan. OK. Maintenant, vous sortez de votre réseau, rentrez chez vous et tapez serveur.macgeneration.lan pour continuer à travailler sur votre zouli wiki.

Et là, c’est le drame (©M6) : impossible d’accéder à votre wiki. Et oui, les serveurs DNS externes pointent sur… rien. .lan, ça n’existe pour personne d’autre que les ordinateurs sur votre réseau interne. Dommage, non ?

Maintenant, imaginons que vous ayez commencé par .lan, puis vous souhaitez créer plusieurs sites web distincts par leur nom et accessibles de l’extérieur, par exemple un site public, un intranet, un extranet… Il faudrait alors idéalement acheter votre nom de domaine puis configurer à nouveau le serveur pour qu’il utilise le nouveau domaine… Malheureusement le changement de nom DNS doit être fait de façon correcte (en particulier en préparant le serveur avec la commande changeip), ce que personne ou presque ne fait.

Certes tout cela peut sembler trivial, ou très compliqué selon les points de vue, mais ce n’est pas à négliger : une très grosse partie des problèmes sur Mac OS X Server viennent d’un DNS mal configuré. Le choix du nom de domaine n’a donc rien de trivial.

Accès mobile : « I’m not your fracking VPN ! »

Concernant l’accès mobile, il ne s’agit pas vraiment d’un VPN SSL. En effet, selon les principes du VPN SSL, il faudrait au préalable s’authentifier sur une page web pour chiffrer tout le trafic vers le serveur interne. Ici, le but est plutôt de rediriger certains flux bien précis vers un serveur interne en utilisant le serveur d’accès mobile comme routeur pour certains services bien précis (iCal, Carnet d’adresses, mail et web). Et c’est indiqué page 183 de la doc des services réseau : il faut utiliser une configuration en split DNS pour que cela fonctionne. Encore une bonne raison de ne pas utiliser de domaine en .lan ;-) Enfin le service d’accès mobile nécessite effectivement un serveur qui effectuera le routage, et par conséquent un serveur différent de celui hébergeant tous les services. Le service d’accès mobile peut être plus avantageux que le VPN car il donne accès aux services essentiels du serveur interne de façon sécurisée, et transparente pour l’utilisateur, sans pour autant donner accès à tout le réseau.

Quand à dire que le protocole Bonjour ne peut pas passer à travers le VPN… ce n’est pas totalement vrai, puisqu’on peut aussi enregistrer des services Bonjour à travers le serveur DNS. Mais il est vrai que c’est quasiment un miracle quand on arrive à faire tomber cette fonction en marche… Enfin, il reste un point à ne pas négliger : qu’il s’agisse du VPN ou du service d’accès mobile, il faudra procéder à des redirections de ports dans les réglages du routeur, opération pas forcément anodine (ou plutôt, pas forcément évidente si on ne connaît pas les rouages de base d’un réseau TCP/IP).

Le DVD, c’est tellement XXè siècle

Concernant le point de l’installation, il est vrai qu’il faut normalement passer par l’outil d’installation de système à distance pour restaurer l’OS en cas de panne. Mais on peut aussi être prévoyant, et simplement réserver une partition de système d’un disque externe en y clonant le DVD d’installation. Avantage : on boote et on réinstalle le système bien plus vite… C’est la solution que j’utilise, et elle marche fichtrement bien. Sinon, on installe l’outil d’installation à distance sur un Mac ou PC du réseau, et zou !

En revanche, un point important signalé par MacGe à très, très juste titre : le RAID 1 (miroir) n’est pas une sauvegarde. C’est juste un système pour s’assurer que votre système continue de tourner en cas de perte d’un disque, mais il ne pourra jamais permettre de récupérer un fichier effacé par erreur ! Donc, sauvegardez vos données, quelque soit l’outil que vous utilisez.

Sorry, Mac mini, but your server is in another castle ! (1)

Pour conclure, je serai encore plus enthousiaste que MacGe sur le marché du Mac mini Server : c’est un produit archi-sexy, simple à administrer (j’ai scié récemment un consultant Linux en lui montrant comment on gère le serveur), silencieux, efficace et très certainement suffisant pour 90% des utilisateurs du marché PME/PMI. Et des échos que j’ai eus, les ventes seraient déjà à la hauteur des attentes sur cette machine.

Go, Mac mini, go get them !

(1) En fait le sous-titre compte pour du beurre, c’est juste que je voulais faire un clin d’œil à la sortie de New Super Mario Bros Wiiiiiiiiiiiiiiiiiiiiiiii.