Windows Vista : Licence to Kill (Bill) ?

Vous aimez lire les contrats régissant les accords de licence, les fameux EULA ? Non ? Pourtant vous devriez. Outre qu’une société se soit amusé il y a quelques temps à cacher un lien dans son EULA pour faire gagner 1000 dollars si on la lisait jusqu’au bout, il y a plein de petites choses intéressantes à découvrir de temps en temps. Par exemple, quand j’indique en formation qu’il est interdit d’installer les logiciels Apple dans une centrale nucléaire, un système de navigation aérien ou pour contrôler un équipement d’appareil de survie artificielle, on pouffe… Or ,c’est exactement ce qui est écrit dans les accords de licence. Vérifiez vous-même.

Or donc, des juristes ont commencé à se poser des questions sur les licences EULA de Windows Vista… Et certains de ses éléments sont pour le moins… irritants. Comme la capacité de Vista à être bloqué (mais sans dire de quelle façon) si Microsoft décide de façon unilatérale que vous avez violé le contrat d’utilisation. Cet article assez éloquent (en anglais) montre que pour Microsoft, il n’y a pas de limite au contrôle… Ça en est presque effrayant.

Note par ailleurs aux entreprises : fini les clés universelles de licence pour vos parcs, il va falloir penser à investir dans un serveur de clés Windows Vista… Un casse-tête de plus à gérer.

Venez donc sur Mac, l’herbe est plus verte, et les systèmes de contrôle (presque) inexistants :)

Les XServe Intel arrivent, Gete.Net Consulting fait promo

Première photos d’un XServe Intel chez PowerMax. C’est beau… comme un XServe, quoi. À noter quelques subtilités intéressantes :

– On peut verrouiller le serveur via une vis à l’arrière. Ça sécurise déjà plus qu’avant, où on pouvait ouvrir le serveur avec une simple clé allen ;
– La vidéo intégrée fait son retour. Amusant, au moment où Apple propose une formation sur l’administration de Mac OS X Server en ligne de commande… Bon, de toute façon, moi ça fait un paquet de temps que je gère mes serveurs en headless, et le prix d’une licence ARD, c’est donné ;
– L’arrivée du Lights-out Management (LOM) ravira les administrateurs dont les serveurs sont à 10 km de leur bureau. Désormais, plus besoin de se déplacer pour les démarrer. À noter que la version 3.1 d’Apple Remote Desktop (plus d’infos à ce sujet plus tard) gère le LOM des XServe ;
– L’alimentation peut être redondante et est échangeable à chaud. Good !
– En revanche, certains sysadmins de la liste Mac OS X Server d’Apple se plaignent de la difficulté à le racker correctement dans leur armoire. Mais d’autres disent qu’au contraire, le rackage (c’est français ça ?) s’est fait sans problème… Partagez vos expériences en commentaire ;
– Attention, il faut choisir le bon kit de rack avant de commander le serveur. Et oui, Apple ne livre plus les deux kits en standard… Dommage ;
– Les radiateurs sont gros, et la RAM a aussi des dissipateurs de chaleur. Attention aux extensions de RAM à bas prix qui n’auraient pas les bons systèmes de refroidissement… De toute façon, on parle serveur, donc il faut avoir de la RAM de bonne qualité. Ne discutez pas, c’est comme ça.

Et pour fêter la disponibilité (enfin !) annoncée de ces serveurs, Gete.Net Consulting offre 25% de remise sur toute première journée d’installation d’un XServe Intel pour toute commande passée avant le 31 décembre 2006. Pour toute information, me contacter directement.

DNS, DNS, DNS !!!

On ne le dira jamais assez : la règle d’or, quand on installe Mac OS X Server, est d’avoir un service DNS fonctionnel sur le réseau. Un petit rappel : le DNS (Domain Name System) est utilisé pour faire la correspondance entre une adresse IP et le nom d’une machine ou d’un service sur le réseau. C’est ce qui vous permet par exemple, lorsque vous tapez www.apple.com, d’atterrir sur le serveur d’Apple, dont l’adresse IP est 17.254.0.91. Tout cela grâce à un serveur DNS, situé quelque part entre votre ordinateur et le serveur recherché. Le DNS est donc l’annuaire des services réseau par excellence et une des clés de voute d’Internet.

Cependant, si Mac OS X arrive encore à fonctionner correctement même sans serveur DNS sur le réseau, la mise en place d’un DNS bien configuré devient incontournable quand on installe Mac OS X Server. La règle d’or est ici : Tout poste sur lequel est installé Mac OS X Server doit être capable de faire une requête sur sa propre adresse IP et d’obtenir les informations DNS en forward (recherche d’une adresse IP à partir d’un nom de domaine) et en reverse (recherche d’un nom de domaine à partir d’une adresse IP. Si vous souhaitez mettre en place un serveur maître Open Directory, la question ne se pose même pas : si vous n’avez pas de DNS bien configuré pour votre serveur, le service fonctionnera mal, et Kerberos ne se lancera pas.

Mac OS X Server 10.4.6 et suivant ont rajouté une règle supplémentaire : le nom d’hôte du serveur (hostname) doit être identique au nom DNS du serveur. Quand vous tapez la commande hostname sur votre serveur, celui-ci doit vous renvoyer un nom correspondant à son entrée DNS dans le serveur. De plus, avant la 10.4.6, il était d’usage de renseigner le hostname dans le fichier /etc/hostconfig en remplaçant la ligne HOSTNAME=-AUTOMATIC- par HOSTNAME=serveur.exemple.com. Or, depuis la 10.4.6, il ne faut pas agir ainsi : il est indispensable de laisser la ligne HOSTNAME=-AUTOMATIC- telle quelle. Sans cela, votre serveur affichera de nombreux messages d’erreur dans la Console. Tous ces changements sont renseignés en français dans les articles 303495 et 303697, de plus en français : aucune excuse pour ne pas les lire donc !

Maintenant, une recommandation : lorsque vous entrez votre serveur, créez une entrée sous forme d’alias pour chaque service qui sera exploité sur votre serveur. Ainsi, vous avez créé serveur.exemple.com : très bien, mais dans ce cas, si vous activez le service web, ajoutez www.exemple.com qui pointera vers serveur.exemple.com. Vous activez le service ftp ? Ajoutez ftp.exemple.com et dites à vos utilisateurs de pointer dessus. Ne leur dites même pas qu’il s’agit de la même machine. Cette approche a au moins deux mérites :
1) Si un service monte en charge et que vous décidez de rajouter une nouvelle machine pour gérer ce service, vous n’avez pas besoin de vous prendre la tête pour la configuration : il suffit de faire pointer l’alias vers la nouvelle machine (que vous aurez évidemment pris soin de référencer au préalable dans le DNS) ;
2) certains services distinguent l’adresse DNS utilisée pour se connecter vers le serveur afin de donner accès à des ressources particulières. Ainsi, le service web peut donner accès à des sites différents selon que l’on utilise un nom de domaine ou un autre pour se connecter. Pratique pour héberger plusieurs sites distincts en interne sur le même serveur… Et là encore, si vous souhaitez un jour faire migrer un de ces sites sur une autre plate-forme, ce sera bien plus simple qu’avec l’adresse IP intégrée.

Pour plus de renseignements sur l’art de bien configurer le DNS, je vous renvoie à l’excellent travail de traduction d’un article de l’exceeeellent site AFP548 effectué par les soins du non moins exceeeellent Laurent Pertois en personne sur mosx.net il y a quelques temps de ça.

Et bien évidemment, si vous avez peur de faire vous-même la configuration DNS de votre serveur, vous pouvez toujours demander à un consultant de le faire pour vous. Cela a l’air de rien, mais un serveur DNS bien configuré en interne peut considérablement assouplir l’accès à vos serveurs, améliorer les performances du réseau (grâce à un cache DNS) et facilitera l’accroissement de votre architecture informatique, si votre activité venait à s’intensifier (et c’est tout le mal que je vous souhaite !).

Les noms à ne PAS déposer

On s’est fait l’écho ici ou de la fermeture de certains sites qui ont eu le malheur d’utiliser des noms de domaine qu’Apple a jugés inopportuns… Mais en quoi est-ce une surprise ? Les règles d’utilisation de termes déposés par Apple sont strictes, et c’est normal : Apple ne souhaite pas que son nom soit utilisé par n’importe qui, pour n’importe quoi. Lionel se demandant si il n’y avait pas de risque avec les noms déposés en Mac quelque chose, ce n’est heureusement pas à l’ordre du jour. Pour s’en assurer, et avant d’aller déposer le nom d’un nouveau produit pour un Mac ou lancer votre nouveau site, consultez les conditions d’utilisation des marques déposées d’Apple. Ça vous évitera de devoir retirer votre produit ou fermer votre site pour un bête problème de nom.

Tester votre anti-virus

Bon, mon ami Laurent va se foutre de ma gu… en me disant que c’est super connu, mais je n’ai appris ce truc qu’il y a peu. Si vous utilisez un logiciel antivirus et souhaitez en éprouver la fiabilité, il existe une méthode simple : trouver un vrai virus, et se l’envoyer. Bon, ok, c’est pas si simple que ça, et c’est dangereux… Précipitez-vous plutôt sur ce site et téléchargez l’un des fichiers de test. Il ne reste plus qu’à l’envoyer à votre machine de test, et zou, le logiciel doit détecter correctement s’il s’agit d’un virus. Utile par exemple pour tester votre installation de ClamAV sur Mac OS X Server…

Mac OS X Server 10.4.8 et les partages AFP

L’excellent Nigel Kersten expliquait il y a quelques temps sur afp548.com que la version Universal Binary de Mac OS X Server 10.4.7 contenait des curieuses différences sur sa partie AppleShare avec la version de Mac OS X Server 10.4.7 qu’on obtient en installant la 10.4 puis les mises à jour (ou la mise à jour 10.4.7 combo, c’est plus simple). L’une de ses optimisations concernait directement le service AFP (Apple Filing Protocol), apparemment bien plus robuste en cas de charge importante.

Joie et bonheur, plus besoin de faire la quête auprès d’Apple pour demander cette version magique du dévédé de Mac OS X Server, car les modifications apportées sont désormais intégrées à la toute jeune version serveur de la 10.4.8. Donc, théoriquement, ça devrait marcher bien vite et bien mieux…

Mac OS X 10.4.8 dispo

Comme vous l’avez lu partout, Mac OS X 10.4.8 est disponible depuis quelques jours, avec plein de nouvelles fonctions géniales, comme le zoom à la molette avec la touche Contrôle.

Bon, ça c’est le bon côté. Le mauvais, c’est qu’il y a des choses qui fonctionnent moins bien, comme on peut le voir un peu partout sur les forums. Une critique qui revient souvent, c’est le manque d’entrain d’Airport à se reconnecter automatiquement aux réseaux protégés via WPA2. Coup de chance, le problème est connu et documenté, pour une fois, et donc la réponse se trouve par là : Mac OS X 10.4.8: AirPort does not auto-connect to existing networks after restart or wake from sleep.

Le meilleur blog Mac de le monde. Ou pas.