Des DNS, du Bind avec du Gandi et de l’Ovh

Comme j’en parlait dans un article précédent, Transfert de nom de domaine d’OVH vers Gandi. Il me fallait ensuite configuré correctement les dns de mes domaines, en exploitant les possibilités offertes par Gandi et Ovh.

Un petit état des lieux :

  • Les dns sont géré par un serveur bind9.
  • Le serveur dédié étant chez OVH, un service de dns secondaire est proposé dans les options.
  • Gandi fourni également son service de dns secondaire, pour les domaines dont ils sont le registar.

La mise en pratique :

  1. Se rendre dans les options du serveur bind, et ajouter pour chaque domaine, diverses informations.
    • Trouver le fichier named.conf.local (Il se trouve par exemple dans /etc/bind/)
    • Rajouter pour chaque domaine :
      allow-transfer {
      127.0.0.1;
      localnets;
      217.70.177.40;
      213.186.33.199;
      };
      also-notify {
      217.70.177.40;
      213.186.33.199;
      };
      notify yes;

      Petite explication :
      217.70.177.40 est l’adresse IP  du serveur de dns de gandi (ns6.gandi.net)
      213.186.33.199 est l’adresse IP du serveur de dns d’OVH (ns.kimsufi.com)
      allow-transfer : Va autortiser la récupération d’une copie complète des dns. Dans notre cas, uniquement par les serveurs dns locaux ou secondaire.
      also-notify : Lors d’une changement dans les dns, le serveur enverra un signal aux autres ns configuré pour le domaine, les notifiant d’un changement.
      notify : active réellement la fonction also-notify.
    • Enregistrer et appliquer les changements. Par un rechargement des paramètres ou un redémarrage du serveur bind.
  2. Se rendre sur le manager d’OVH dans la section des services du serveur dédié. Introduire le nom de domaine avec son extension, choisir l’adresse ip sur lequel le serveur principal se trouve et l’ajouter.
  3. Se rendre sur le manager de Gandi, et changer pour chaque domaine, les serveurs dns.
    • DNS1 : mettre le hostname de votre serveur.
    • DNS2 et DNS 3 : introduire ns6.gandi.net et ns.kimsufi.com dans l’ordre de votre choix

Après 10-15 minutes, faites un tour sur un vérificateur de nom de domaine. Telles que http://www.kloth.net/services/nslookup-fr.php, introduisez votre domain, mettez ns.kimsufi.com dans serveur, choisisez mode de recherche any. Si tout est bien configuré, vous devriez-voir votre zone dns complète apparaître. Refaites le test avec dans serveur, ns6.gandi.net.

Si cela n’a pas fonctionné, retenté un redémarrage de votre serveur bind, et vérifier les fichiers log.

Transfert de nom de domaine d’OVH vers Gandi

ovh-gandiDepuis 2003, j’était fidèle à OVH pour la gestion de mes noms de domaine.
Pourtant, voici qu’une partie de ceux si sont maintenant chez Gandi.

Des changements au niveau des informations de propriétaire devait être fait. Hors, mon expériences passé (pas si vieille que celà) m’ont appris une chose, il est bien plu facile de faire un transfert de registar, que de faire la procédure chez OVH. Non seulement elle est loin d’être pratique, demande via le support, formulaire à remplir … pour au final un résultat qui ne me satisfaisait pas totalement.

J’ai dorénavant les informations que je désire, un tarif de transfert de 7,18€ et une interface équivalente à OVH pour la gestion. Autre avantage, la séparation entre la gestion des domaines et du serveur dédié.

Dans un an, ils risquent tout de même de retourner chez OVH vu le prix moindre des domaines en .be chez eux. Enfin, il me reste 364 jours pour me décidé 😉

En attendant, cela fait 5 domaines chez Gandi !

Navision 4.0 : Un chantier qui se termine

Microsoft DynamicsIl y a plusieurs mois, nous lancions au boulot, un grand chantier d’optimisation et de sécurisation de notre ERP Navision 4.0 SP3. En voici enfin le résultat.

Au niveau sécurisation, nous avons abandonné les comptes d’accès SQL au profit de l’authentification via le compte Windows. Chaque compte à dorénavant accès en écriture qu’au information auxquelles il à droit de par sa fonction. La majorité du reste étant accessible en lecture tout de même. Certaines tables ont en plus des logs de modification très détaillé.
L’accès n’est aussi dorénavant possible que via le client Navision. De quoi évité l’export de données via un Excel par exemple. Dont le moteur à la fâcheuse tendance à tout bloqué et donc de ralentir les performances.

Au niveau performance, nous avons également regardé du côté du serveur physique, de Windows et du serveur Microsoft SQL.
La machine physique à vue sa mémoire passé de 3,5Gb à 8Gb. Il aura fallu modifier le fichier boot.ini de Windows avec l’option /PAE. Ceci afin que le système 32 bits puisse exploiter les 8GB. Un système 32 bits étant limité à une gestion mémoire de 4Gb de part la taille des adresses mémoire.
Dernière chose activé, c’est l’activation de l’option /3GB, toujours dans le boot.ini. Ceci afin d’autoriser Windows à donner plus de jusqu’à 3Gb à une application « gourmande ». La limite standard étant 2GB.

Une optimisation plus « anecdotique », c’est le changement du switch réseau qui gère dorénavant que des ports 1Gbit.

Nous sommes arrivé au bouts des optimisation faisable facilement et sans gros risque. La dernière possibilité existante, est de revoir tous les indexe existant dans les différentes tables de Navision, et les adapter à nos besoins. Un travail de titan qui demande une connaissance complète et parfaite des tables. Mais aussi un temps énorme …

La prochaine étape en cas de nouveau ralentissement sera assez simple. Passage à un système 64 bits afin d’exploiter de façon optimale la mémoire mise à disposition pour le serveur SQL et profiter de la puissance du 64 bits. Mais cela, c’est une autre histoire, et surtout, de belle et grosse nouvelle licence à acheté. Windows 64 Bits, SQL 64 Bits etc…

Upgrade Windows 2008 vers Windows 2008 R2

Si vous avez du temps à passer, une bonne solution est de mettre à jour des serveurs tournant sous Windows 2008 (64 Bits), vers la même version, mais en Windows 2008 R2 (64 Bits).

Programme des festivités

Mise à jour de deux machines hébergeant un environnement VMWare Server 2.0.
La mise à jour au niveau des machines virtuelles d’un contrôleur de domaine et d’un serveur Exchange 2007.
Début des opérations, avec une machine « physique ». Je découvrirais que le disque C: doit avoir 10,6 Go de libre pour faire la mise à jour. Après un nettoyage, la mise à jour débute. Un long processus, 2-3 redémarrages et nous voilà avec la machine à jour.

Seconde machine, la mise à jour du contrôleur de domaine en machine virtuelle. Aucun problème d’espace disque.

Reste à faire la mise à jour de la « forest » et du domaine. Seule avertissement, avoir installé sur les contrôleurs de domaine tournant sous Windows 2000, le service Pack 4.

Les commandes à lancer sont

  • D:\support\adprep\adprep /forestprep (Ou D représente le DVD de Windows 2008 R2)
  • D:\support\adprep\adprep /domainprep

La mise à jour sera aussi longue, mais se passera sans aucun problème.

Vient le tour du serveur où se trouve Microsoft Exchange 2007. Petit problème, l’assistant m’annonce que pour mettre le Windows 2008 à jour, il me faudra … désinstaller Exchange 2007. La solution que j’ai retenue sera, lorsque cela sera vraiment nécessaire, d’installer un nouveau Windows 2008 R2, d’y installer un Exchange 2007 (voir 2010 ?) et de transférer les boites d’un serveur à l’autre.

Pas de grande nouveautés, un changement de design plus proche de Windows 7, quelques améliorations au niveau de l’interface des outils et autres assistant.

J’étais plus étonné que mise à jour se soit passé sans problème, aussi bien pour les applications Microsoft, que pour les applications tiers. La base identique n’y est bien sûr pas étrangère.

J’ai par la même occasion passer un produit que nous commercialisons, d’une machine 2003 32 bits vers un 64 bits sous Windows 2008 R2. Mais via une nouvelle installation. Installations rapide sans soucis … excepté l’oubli de l’activation du .NET Framework 3.5.1 dans Windows pour l’application.

La dernière machine physique devrait suivre d’ici quelques jours.

D:\support\adprep\adprep /forestprep

The system administrator has set policies to prevent this installation

VmwareIl me restait une machine avec un VMWare Server 1.x dans notre environement. J’ai donc décidé de le mettre à jour vers la version 2. Mais voilà, je recevais le message : « the system administrator has set policies to prevent this installation ».

Hors, il n’y a aucune restriction d’en notre domaine. En est pour preuve que j’ai pu l’installer sur d’autre système sans problème.
Celà concernait un Windows 2003 SP2.

Après quelque recherche, je trouve une référence à une mauvaise installation/configuration/reconnaisance de Windows Installer.

La solution ?

Lancer l’invité de commande : Executer > cmd
Lancer les commandes : msiexec /unregistred et ensuite un msiexec /regserver

Pas besoin de redemarer la machine, on relance l’installation et celà fonctionne sans problème.

Postfix – Spamassassin – load average & spam

PostfixDepuis quelques temps, j’avais remarqué une hausse d’en la réception de spam sur le serveur que je gère.
Heureusement, spamassassin avait assez de règle et de filtre interne ou externe pour bloquer les spams. Malheureusement, vu l’augmentation du spam, les filtres deviennent de plus en plus lourd, mais le nombre de mail aussi.

Le résultat vu une augmentation de la charge du serveur. Le load average fleuretait en moyenne à 2.5 voir 3.

J’ai donc replongé dans la documentation de postfix et de spamassassin. J’ai fini par tomber sur la règle « reject_rbl_client ». Cette règle permet de vérifié si l’adresse ip du serveur qui essaye de m’envoyer un email est blacklisté pour l’envoi de mail. Et là paf eurêka, spamhaus, spamcob etc…. Dire que j’ai déja utilisé cette technique, mais je n’y pensait plus du tout. Mais c’était avec un Qmail à l’époque.

Dans le répertoire de configuration de postfix, /etc/postfix/ sous ubuntu, se trouve un fichier nommé main.cf.
On retrouve le paramètre smtpd_client_restrictions, s’il ne s’y trouve pas, on le rajoute.

J’ai donc rajouté des éléments telles que reject_rbl_client zen.spamhaus.org ou reject_rbl_client bl.spamcop.net.

Le résultat fut sans appel, le load average est en moyenne à 0.22 !

Je me retrouve donc avec un serveur, qui n’accepte plus une bonne partie du spam, ceux qui passe encore sont assez bien filtré et avec un serveur beaucoup moins chargé qu’avant. Le bonheur pour un administrateur 🙂
Comme quoi, les règles les plus simples sont souvent les meilleures !

[0x80070534] No mapping between account names and security IDs was done.

SQL Server 2008

Voici le message qui m’a occupé pendant une bonne journée : « Error 0x80070534, No mapping between account names and security IDs was done ».

Après des recherches, des tentatives infructueuses, j’ai fini par trouver la raison de cette erreur. Cela se passait lors de l’installation d’Office Communication Server 2007 R2 sous Windows 2008 64 bits en virtualisé.

Cette erreur est provoquée par Microsoft SQL Server et peut se produire avec les versions 2000, 2005, 2008. Version express et complète.

La raison est « simple », lorsqu’on installe un Windows, un identifiant unique est généré par machine. Cet identifiant est généré dès qu’on rentre dans l’interface graphique de l’installation (Dès le premier redémarrage donc).

Cet identifiant unique est donc copié si on vient à faire des Ghost ou des images virtuelles pré-configuré. Si pour la plupart des applications, cela ne pose pas de problème, pour SQL, le problème empêche de créer le lien entre les login utilisés et où ils le sont.

Pour information, un contrôleur de domaine et les contrôleurs de domaine secondaire ont eu un même numéro de système. D’où le fait qu’il est déconseillé (en plus des problèmes de sécurité) d’installer un SQL sur un contrôleur de domaine primaire et secondaire.

Il faut savoir que cet identifiant n’est pratiquement jamais modifié. L’ajout ou la suppression de la machine d’un domaine ne le modifie pas par exemple.

Quelle solution donc si on souhaite continué à utiliser Ghost ou des images virtuelles pré-configuré ?

Utilisé l’utilitaire newSID permettant de généré et de modifier le System ID de façon automatique. Il est disponible dans la section sysinternals de Microsoft sous NewSID.

La procédure la plus propre est :

  • Installer Windows
  • Installer les softwares ne devant pas être identifié sous le domaine explicitement.
  • Faire la copie Ghost ou du disque Virtuelle.
  • Lancer/installer la copie
  • Lancer l’utilitaire newSID
  • Ajouter la machine dans le domaine
  • L’utilisé normalement

De cette manière, vous ne soufrerez plus de ce problème de SID.