Youtube à plein tube

C’est pas une nouveauté, Youtube + Free = caca lorsqu’on a l’IPv6 d’activé. Voici une démarche permettant de contourner ce problème aisément.
Le tutoriel ne fonctionnera que sous Windows Vista ou Windows 7, mais l’idée peut être adaptée partout. Elle consiste simplement à filtrer les IPv6 utilisées par Youtube.

Voici donc la procédure :

  1. Accédez au pare-feu, via par exemple le bouton Démarrer > wf.msc (il faut évidemment être administrateur de sa machine)
  2. Ajoutez une règle de trafic sortant avec les paramètres suivants (voir plus bas pour la version en images) :
    • Type de règle: personnalisé
    • Appliqué à tous les programmes
    • Le protocole TCP sur le port distant 80
    • Lorsque les IP distantes sont dans la rangée : 2a00:1450::/32 ou 2607:f8b0::/32
    • Bloquer la connexion
    • sur tous les emplacements (Domaine, Privé et Public)
    • avec le nom suivant : Youtube IPv6
    • C’est tout. Il n’y a plus qu’à rafraîchir la page du navigateur

Les IPs s’obtiennent avec n’importe quel analyseur réseau comme Wireshark, Firebug ou les Outils de développements intégrés à Chrome. Ensuite, l’utilisation du bon RIR (Ripe pour les IPs européennes, ARIN pour le continent américain, APNIC pour l’Asie et le Pacifique) permet d’obtenir le bloc contenant l’IP cherchées qui a été affecté. On vérifiera que le propriétaire des 2 blocs est bien Google, propriétaire de Youtube.

En images :

youtube_templateyoutube_programyoutube_portyoutube_hostyoutube_actionyoutube_profilyoutube_name

SQL Server ne démarre plus avec SSL activé

SQL Server supporte, au moins depuis la version 2005, les connexions sécurisés en utilisant SSL.
En suivant la procédure décrite par Microsoft, ça se fait relativement bien… mais les règles semblent avoir changées avec la version 2008 R2.

En effet, à partir de cette version, une étape supplémentaire est requise afin d’autoriser et de s’assurer que l’utilisateur qui exécute le service puisse accéder à la clé privée associée au certificat. Dans le cas contraire, SQL Server balance plusieurs erreurs abscons dont la première a pour EventID 26014 avec pour seules explications que le certificat spécifié n’existe pas et pourtant, il est bien là !

Revoyons les étapes nécessaires pour activer SSL sur une instance SQL Server :

  1. Installer le certificat de sécurité sur la machine qui exécute SQL Server en utilisant la MMC gérant les certificats. Le certificat DEVRA bien entendu être au format PFX pour qu’il puisse être importé dans un magasin de certificats géré par Windows.
    • il est important de noter que le certificat DOIT ÊTRE accessible par l’utilisateur qui exécute SQL Server, donc on ne peut pas utiliser par exemple le magasin de certificat du compte administrateur (à moins que ce soit lui qui exécute SQL Server, auquel cas c’est complètement débile d’un point de vue sécurité). Le certificat peut donc être installé ou bien dans le magasin de la machine locale, ou bien dans le magasin du compte utilisateur. J’ai testé avec le magasin de la machine locale, mais ça devrait aussi fonctionner avec le magasin du compte utilisateur SQL Server. A noter que sous Windows Server 2003, je recommande l’utilisation du magasin de la machine locale pour faciliter la manipulation à l’étape suivante.
    • c’est là que les choses changent : il faut vérifier que l’utilisateur SQL Server peut lire la clé privée, ce qui ne semble plus être le cas par défaut. Pour se faire, ou bien on dispose de Windows Server 2008 R2 et cela se fait directement dans la MMC, ou bien on tourne encore sous Windows Server 2003 et il faut faire appel à un outil nommé winhttpcrtcfg disponible dans le Ressource Kit de Windows Server 2003. La commande à taper ressemblera à winhttpcrtcfg -g -c LOCAL_MACHINE\My -s « le.sujet.du.certificat.kveer.com » -a utilisateur_sql_server et on pourra le vérifier avec la commande winhttpcrtcfg -l -c LOCAL_MACHINE\MY -s « le.sujet.du.certificat.kveer.com »
  2. Reconfigurer SQL Server grâce au SQL Server Configuration Manager
    • je ne détaillerai pas cette étape car elle n’a pas changé, et consiste en une dizaine de clics dans le SQL Server Configuration Manager. Se référer aux liens dans la section Source pour la procédure étape par étape.

Voir aussi

Backup par mail

Le pipe (|), opérateur exclusivement Unix, et trop rarement utilisé (tout du moins par moi), m’a permis de réaliser en une seule ligne, une sauvegarde de base de données, compressée, et envoyé par mail.

Voyons la commande finale :

mysqldump --hex-blob --opt -pyourVerySecretPassword -u backup -B my_database | bzip2 -9 | uuencode bdd_mabase_prod_`date +%Y%m%d-%H%M%S`.sql.bz2 | mail -s "Backup BDD" storage_mail@gmail.com

Détaillons cette chaîne :

  1. on dump la ou les bases de données, pour se faire, je conseille fortement l’utilisation d’un utilisateur dédié qui n’aura qu’un accès limité à la lecture et éventuellement à l’utilisation des verrous pour assurer l’intégrité de la sauvegarde
  2. le flux de sortie, un script SQL, est envoyé à bzip pour être compressé
  3. le flux compressé est envoyé à uuencode. Cette opération va encoder avec des caractères ASCII afin d’être pouvoir transmis en pièce jointe et en lui donnant un nom
  4. enfin on expédie le mail avec un sujet et un destinataire

Et si on chiffrait la sauvegarde ?

Il y a plusieurs intérêt à chiffrer la sauvegarde :

  • la sauvegarde peut être placé dans un endroit non sécurisé ou faiblement
  • toute altération sur la sauvegarde sera impossible ou visible

Encore faut-il s’y prendre convenablement. En effet, on a immédiatement 2 façons naïves de chiffrer :

  • soit en utilisant un chiffrage symétrique
  • soit en utilisant un chiffrage asymétrique

Il se trouve que ces deux approches sont après coup débiles. En effet prenons d’abord le chiffrage symétrique ; que se passe-t-il si le serveur qu’on sauvegarde est compromis ? On peut estimer que le contenu des sauvegardes, y compris celles faites AVANT le piratage du serveur ne sont plus sûres, puisque le serveur compromis a non seulement un accès en écriture au site de sauvegarde, mais également la clé de déchiffrage des sauvegardes.

Examinons maintenant le chiffrage asymétrique, qui corrige bien le problème précédent mais présente deux problèmes :

  • le premier est un problème purement pratique : openssl, le couteau suisse du chiffrage pète en rsa lorsque le flux dépasse une certaine taille (très inférieure à 1Mo)
  • le second est d’ordre plus général : les chiffrages asymétriques coûtent très cher en temps processeur (autrement dit un chiffrage asymétrique prendre beaucoup plus de temps qu’un chiffrage symétrique sur le même flux), pour peu que la quantité de données soit « assez » conséquente, le chiffrage pourrait dégrader de façon significative et pendant un temps estimé trop long le serveur sur lequel les calculs s’effectuent.

La méthode que je qualifierais de bonne, (merci à Denis Altudov pour l’astuce), consiste à utiliser se qui se fait déjà dans les mails avec S/MIME : le contenu à protéger est chiffré avec un algorithme symétrique, dont la clé, générée à la demande et donc unique, est chiffrée par un algorithme asymétrique en utilisant la clé privée du destinataire ; ainsi seul le destinataire du mail est capable de lire le contenu protégé.

C’est exactement ce qu’on va faire, en utilisant openssl, et plus spécifiquement la sous-commande smime de openssl.
Il faudra au préalable un certificat (avec sa clé privée), au format PEM pour simplifier l’exemple. Reprenons l’exemple initial en ajoutant du chiffrage :

mysqldump --hex-blob --opt -pyourVerySecretPassword -u backup -B my_database | bzip2 -9 | openssl smime -encrypt -binary -aes128 -outform DER yourPrivateKey.crt | uuencode bdd_mabase_prod_`date +%Y%m%d-%H%M%S`.sql.bz2.ssl | mail -s "Backup BDD" storage_mail@gmail.com

# version openssl smime autonome (ou presque)
mysqldump --hex-blob --opt -pyourVerySecretPassword -u backup -B my_database | bzip2 -9 | openssl smime -encrypt -binary -aes128 -from sender@kveer.com -to storage_mail@gmail.com -subject "Bacup BDD" yourPrivateKey.crt | sendmail storage_mail@gmail.com

Note : openssl smime est capable de générer un mail lui-même comme on peut le voir dans la seconde commande, mais cela aurait donné un mail avec une pièce jointe nommée smime.p7m, ce qui n’est pas terrible pour identifier ce qui était chiffré, en particulier le type de fichier, c’est pourquoi j’ai préféré rester à utiliser uuencode.

Et voilà, plus besoin d’un script dédié pour des plans de sauvegarde simple, il n’y a plus qu’à cronifier.

Déchiffrage

Par rapport à l’exemple donné, voici la commande miroir pour déchiffrer les pièces jointes :

openssl smime -decrypt -binary -aes128 -inform DER yourPrivateKey.crt -in your_encrypted_file.sql.bz2.ssl -out your_decrypted_file.sql.bz2

Les arguments -aes128  et -binary  sont peut-être superflus, je n’ai pas testé précisément ces points là.

Plusieurs pièces jointes dans un mail

Toujours avec le même exemple, voici comment on peut joindre plusieurs pièces jointes, et même un corps de message à son mail :

(
echo -e $YOUR_MESSAGE;
mysqldump --hex-blob --opt -pyourVerySecretPassword -u backup -B my_database | bzip2 -9 | openssl smime -encrypt -binary -aes128 -outform DER yourPrivateKey.crt | uuencode bdd_mabase_prod_`date +%Y%m%d-%H%M%S`.sql.bz2.ssl;
mysqldump --hex-blob --opt -pyourVerySecretPassword -u backup -B another_database | bzip2 -9 | openssl smime -encrypt -binary -aes128 -outform DER yourPrivateKey.crt | uuencode bdd_another_base_prod_`date +%Y%m%d-%H%M%S`.sql.bz2.ssl
)
| mail -s "Backup BDD" storage_mail@gmail.com

Où sauvegarder

Où vous le souhaitez. Pour ma part, j’ai choisi Google, car il propose 8Go par boîte mail gratuitement et accepte des pièces jointes allant jusqu’à 25Mo et parce que je suis pauvre. Pour une sauvegarde à pas chère, les mails via Google constituent une excellente opportunité.

Les paquets à installer

  • uuencode se trouve dans le paquet app-arch/sharutils
  • mail se trouve dans le paquet mail-client/mailx

Exemple de script

A peu de chose près, voici ce que j’utilise comme script de sauvegarde. Ce script se trouve dans @@/etc/cron.daily@@, ce qui lui permet d’être automatiquement exécuté avec les bons privilèges tous les jours.

#!/bin/bash
MYSQL_PASS=verySecretPassword
MYSQL_USER=backup_user
DATE=`date +%Y%m%d-%H%M%S`
HOSTNAME=`hostname`
RECIPIENT=backup@gmail.com
CERT=/root/backup.gmail.com.crt
WWW_WEB1='/var/www/web1/htdocs/ /var/www/web1/reset_acl.sh'
WWW_WEB2=/var/www/web2/htdocs
WWW_WEB3='/var/www/web3/forum /var/www/web3/www'

MYSQL_CMD="mysqldump --hex-blob --opt -u ${MYSQL_USER} -p${MYSQL_PASS} -B"
OPENSSL_CMD="openssl smime -encrypt -binary -aes128 -outform DER $CERT"

CONF='/etc/bash/bashrc
/etc/ahbot.conf
/etc/bind
/etc/clam*.conf
/etc/conf.d
/etc/courier*
/etc/cron*
/etc/dhcp
/etc/env.d
/etc/fail2ban
/etc/freshclam.conf
/etc/group
/etc/passwd
/etc/shadow
/etc/hosts
/etc/init.d
/etc/ipsec*
/etc/kernels
/etc/layman
/etc/locale.gen
/etc/make.conf
/etc/munin
/etc/mysql
/etc/nginx
/etc/ntp.conf
/etc/opendkim
/etc/openvpn
/etc/pam.d
/etc/php
/etc/postfix
/etc/pureftpd.*
/etc/realmd.conf
/etc/revdep-rebuild
/etc/screenrc
/etc/scriptdev2.conf
/etc/security
/etc/selinux
/etc/sysctl.conf
/etc/syslog-ng
/etc/teamspeak3-server
/etc/unrealircd'

T=$( cat <<EOF
Type your texte here\n
with \n if you want your mail to be readable.
EOF
)

( echo -e $T;
uuencode $CERT my_cert.crt;
$MYSQL_CMD base1 | bzip2 -9 | $OPENSSL_CMD | uuencode ${HOSTNAME}_bdd_base1_${DATE}.sql.bz2.ssl;
$MYSQL_CMD base2 | bzip2 -9 | $OPENSSL_CMD | uuencode ${HOSTNAME}_bdd_base2_${DATE}.sql.bz2.ssl;
$MYSQL_CMD base3 | bzip2 -9 | $OPENSSL_CMD | uuencode ${HOSTNAME}_bdd_base3_${DATE}.sql.bz2.ssl;
tar cj ${WWW_WEB1} | $OPENSSL_CMD | uuencode ${HOSTNAME}_www_web1_${DATE}.tar.bz2.ssl;
tar cj ${WWW_WEB2} | $OPENSSL_CMD | uuencode ${HOSTNAME}_www_web2_${DATE}.tar.bz2.ssl;
tar cj ${WWW_WEB3} | $OPENSSL_CMD | uuencode ${HOSTNAME}_www_web3_${DATE}.tar.bz2.ssl;
tar cj ${CONF} | $OPENSSL_CMD | uuencode ${HOSTNAME}_etc_${DATE}.tar.bz2.ssl
) | mail -s "Backup $HOSTNAME bdd $DATE" $RECIPIENT

Voir aussi

Configuration robuste d’un serveur SSL

En visitant le site cacert.org, notamment pour voir où en était leur intégration dans les différents systèmes d’exploitation et navigateurs, je suis tombé sur Qualys SSL Server Test un site permettant de scanner la partie SSL d’un site web.

Je passe le test pour mon blog, on va voir ce que ça donne…
Pour note, mon blog est desservi par nginx, lui-même linké à openssl pour tous se qui se rapport au chiffrage.
C’est long… et surprise, je décroche un F ! Bravo, je ne peux pas faire pire !

Analysons le résultat :

  • tout d’abord, mon certificat est trusted, mais il semble qu’il y ait un problème sur la chaîne de certification. Une petite vérification m’a permis de confirmer qu’effectivement le serveur ne contient que le certificat du site et le certificat racine, en oubliant le certificat intermédiaire (chaîne de 3 certificats). Qu’à cela ne tienne, une petite concaténation m’a permis de corriger ce soucis. Le problème que ça aurait pu engendrer est qu’un navigateur qui n’a jamais visité un site certifié par Start SSL (qui est l’entité émettrice de mon certificat) aurait jugé que le certificat n’est pas valide, puisqu’il n’arrive pas à remonter de mon certificat à un des certificats racines du navigateur, vu qu’il lui manque le fameux certificat intermédiaire que je n’ai pas présenté.
  • second problème, j’ai des algorithmes de chiffrages qui sont considéré insecure. oups ? J’avais pourtant bien restreint les algorithmes à HIGH:-DES pourtant ! Il se trouve après avoir trouvé le dénominateur commun aux algorithmes non secure que le coupable est anonymous DH, ou bien ADH. Je change donc dans nginx la liste des algorithmes autorisés à HIGH:-DES:ADH  et je repasse le test… avec succès 🙂 Dans les sources, j’ai pu trouver un lien expliquant de façon succincte pourquoi cette famille d’algorithmes n’est pas sûre : du fait que le Diffie-Hellman est effectué en clair (anonymous), l’échange de clé reste secret (cela est assuré par le procédé Diffie-Hellman), mais n’empêche pas une attaque du milieu, à savoir un agent positionné entre deux participants et qui intercepterait les échanges des deux participant pour proposer ses propres paramètres Diffie-Hellman ; le procédé Diffie-Hellman a été bien réalisé… mais pas avec la bonne personne !
  • dernier problème, mineur celui-là, l’incapacité à renégocier une session chiffrée. Une petite ligne de configuration à rajouter, plus difficile à trouver cependant. Corrigé, je repasse le test, et cette fois, tout est vert, j’ai un A 🙂

Pour résumer, voici à quoi ressemble la configuration SSL dans le fichier de configuration de nginx :

ssl_ciphers HIGH:-DES:-ADH;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 SSLv3;
ssl_session_cache shared:SSL:1m;

Pour comparer, j’ai balancé le test sur un serveur sous Windows Server 2003, et un autre sous Windows Server 2008 R2, tous deux avec les configurations par défaut.
L’un est catastrophique, l’autre est parfait, plus parfait même que mon nginx tuné, notamment par le support du protocol TLS 1.2.
Il est dommage toutefois de constater le faible choix disponible dans la liste des algorithmes proposés sous Windows Server 2003.
Je vais essayer de désactiver SSLv2 sous Windows Server 2003 et voir ce que cela donne…

Bien que les notes fournies par Qualys puissent paraître sévères en rapport avec le monde réel (qui utilise encore ADH parmi les navigateurs modernes ?), reconfigurer proprement la partie ssl d’un serveur ne mange pas de pain (mis à part le cas IIS où la configuration est on ne peut plus restreinte), alors go on !

Voir aussi

Impact de la virtualisation sur les performances brutes

Sur les serveurs dédiés sous ma responsabilité, il m’arrive d’y installer un client BOINC. C’est un logiciel qui rapatrie, pour divers projets scientifiques, du travail à effectuer par la machine, laquelle fait alors partie d’une grille de calcul. Bien entendu, BOINC ne travaille que lorsque le serveur ne fait rien, ou plutôt utilise les cœurs non utilisés des CPUs des serveurs. Il n’est pas question que les services en production souffrent de la présence de BOINC. Sous ces conditions, pourquoi pas, ça permet d’utiliser les ressources non utilisées pour une bonne cause, on évite le gâchis.
Ce programme m’a permis de comparer la puissance de calcul brute de plusieurs configuration, sachant que tous les clients BOINC sont configurés pour travailler sur le même projet. En particulier, il y avait deux machines identiques en RAM (non saturées) et en CPU, un Core i5.

L’une de ces machines était sous VMware ESXi avec une seule VM sous Windows Server 2003, l’autre était directement sous Windows Server 2008 R2.
La configuration CPU/RAM identique m’a permis de comparer quantitativement la perte de performance induite par la couche ESXi simplement en regardant le score de BOINC par client.
J’avais entendu parler au cours d’une conférence d’évangélisation que la perte induite par des outils de virtualisation comme VMware Workstation ou Hyper-V R1 était de 15%, tandis que celle de ESXi était seulement de 5%, grâce à son noyau super léger, mais qu’en est-il réellement ?
Pour ce qui est de Workstation, j’en ai aucune idée, je m’en sers que pour le développement donc pas en continue. En revanche on voit une différence de… 15% de entre l’utilisation ou non de VMware ESXi. Wow ! ce n’est pas rien !

On m’aurait menti ? J’ai attendu plusieurs jours pour que le score quotidien des clients BOINC se stabilise et on note toujours cette nette différence de 15%, quelque soit le travail effectué (mais toujours sur le même projet). Il est à noter également que concernant ces deux serveurs, ils ne faisaient quasiment que de l’idle, donc normalement pas perturbés par d’autres processus. C’est un test approximatif et il vaut ce qu’il vaut, mais a l’avantage de donner une assez bonne précision de ce qu’on perd en CPU brut avec cette couche de virtualisation.

Pour autant, la virtualisation n’est pas à jeter, ça dépend de l’utilisation de la machine. Pour mon cas où le CPU est loin d’être le goulet d’étranglement sur ces machines, surtout un Core i5, cette perte est significative, mais acceptable.

Copier/Coller avec vSphere ESXi

Ça fait quelques années maintenant que je suis adepte d’outils de virtualisation, que ça soit les solutions de VMware (Workstation et Server) ou VirtualBox, donc principalement à des fins de tests sur ma bécane de travail. Bref le but de ce billet n’est pas de les comparer, de toute manière je les ais tous utilisé et chacun ses avantages et défauts.

Depuis peu, je me suis dit, et pourquoi pas ESXi ? Il faut savoir que VMware Workstatation ou VirtualBox, il n’y a pas mieux pour tester un programme, avoir un autre OS etc… mais ça te flingue pas mal les ressources alors que dans le cas de ESXi, on parle non pas de logiciel mais de système d’exploitation, du coup la perte en ressources dû à la virtualisation est minime.

En langage technique, on dit que ESXi est un hyperviseur de type 1, alors que VMware Workstation et VirtualBox sont des hyperviseurs de type 2. Le type 1 EST un OS et a donc un accès direct au matériel, alors que le type 2 repose sur un OS et doit donc passer par lui pour avoir accès aux ressources matériel, d’où la perte de performance plus importante dans le cas de ces hyperviseurs.

J’ai pu donc mettre en œuvre ESXi sur un dédié pour un client. La livraison est nickel, ça marche plutôt bien, quoique je trouve le client vSphere un peu lent, comme s’il s’agissait d’une page web… C’est peut-être le cas, je n’en sais rien.
L’autre point négatif est que le serveur pris ne disposait pas de RAID hard (bah oui ça coûte plutôt cher), et que ESXi ne supporte pas le RAD-soft. Tant pis, mais de toute façon je savais dans quoi je m’engageais.

J’utilise donc la console de vSphere client pour installer l’OS client (au passage, c’est toujours très agréable de charger un DVD à la vitesse des 100Mbps garantis par l’hébergeur). Rien à signaler de ce côté, jusqu’à ce que j’aborde la configuration de l’OS invité. Tiens bizarre, le copier/coller ne marche pas…

Bah non il ne marche pas. Mon poste n’est pas en cause, c’est la faute à vSphere Client. En effet depuis la version 4.1, donc la dernière au moment où je rédige ce billet, cette fonctionnalité est désactivé par défaut, sécurité oblige. Zut alors !

Voici donc la manip à effectuer pour réactiver cette fonctionnalité très pratique :

  1. Éteindre la machine virtuelle concernée
  2. Éditer les paramètres de la machine virtuelle
  3. Aller à Options > Advanced > General puis cliquer sur Configuration Parameters (vu que l’interface graphique ne le permet pas)
  4. Cliquer sur Add Row et ajouter ces deux paramètres :
    1. isolation.tools.copy.disable  avec la valeur false
    2. isolation.tools.paste.disable  avec la valeur false
  5. Valider le tout. Voilà on peut redémarrer la VM, le copier/coller fonctionne à nouveau.

Il est possible de faire cette modification directement depuis le shell SSH en éditant le fichier vmx dans le datastore.
Vu que c’est beaucoup moins pratique et sale, je n’ai pas détaillé cette technique, le shell de ESXi n’étant pas extrêmement bien fourni.

Voir aussi

Mot de passe root de MySQL perdu

À tout ceux qui ont oublié le mot de passe du super-user requis pour administrer MySQL (et qui ont également un accès root à la machine qui héberge le serveur de base de données), voici un tutoriel qui va permettre de réinitialiser ce mot de passe sans tout péter :

  1. La première étape indispensable est d’arrêter MySQL, d’où le besoin d’avoir des privilèges élevés sur la machine hôte.
  2. Bloquez tous les accès externes à MySQL via iptables  si vous être trop lent au clavier 🙂
  3. Lancez MySQL avec le paramètre –skip-grant-tables , cela a pour effet de désactiver toute politique d’accès, en d’autre terme c’est tournée gratuite pour tout le monde, d’où le blocage de l’étape 2.
  4. Tapez mysql -u root , et hop vous avez la main sans avoir eu à taper de mot de passe
  5. Dans ce mode de fonctionnement, les commandes de gestion des accès ne fonctionnent pas : il n’est donc pas envisageable d’utiliser l’une de ces commandes : GRANT  ou REVOKE . En revanche on peut désormais taper sur la table mysql (la table système) avec les commandes de base : SELECT et UPDATE. Pour réinitialiser les mots de passe root, vous pouvez utiliser cette requête SQL en remplaçant le mot de passe :
    UPDATE mysql.user SET Password=PASSWORD('MyNewPass') WHERE User='root';
    FLUSH PRIVILEGES;
  6. Étape finale. En théorie, l’instruction FLUSH PRIVILEGES  recharge les accès, et il n’est donc plus possible de se connecter au serveur MySQL sans s’identifier. Pour ma part, j’ai redémarré le serveur MySQL en mode « normal », je ne perds rien si ce n’est 10 petites secondes.

MySQL propose une solution alternative plus rapide, en permettant d’exécuter un fichier SQL au démarrage du serveur avec bien évidemment les privilèges root. La technique est donc identique sauf qu’au lieu de taper la requête SQL en console, on la prépare dans un fichier, qui est ensuite lancé avec le switch –init-file=fichier_reinitialisation.sql. Il n’est plus nécessaire alors d’utiliser le paramètre –skip-grant-table, mais gare à ne pas se tromper dans la requête.

Voir aussi

Associer un utilisateur de base de données à une connexion SQL Server

Lorsqu’on fait des imports d’un serveur SQL Server à l’autre et que l’on utilise l’authentification en mode SQL, il peut arriver que des connexions SQL soient refusées. En réalité, le lien entre une connexion SQL Server et un utilisateur de base de données n’existe plus.

La méthode barbare auquel on pourrait penser au premier abord pour remédier à ce problème est alors de supprimer l’utilisateur de la base de données pour le recréer, mais si cet utilisateur a des droits particuliers, tous ces droits sautent et il faut les réattribuer.

Microsoft fournit une fonctionnalité permettant de modifier les mappages entre utilisateurs de base de données et connexions SQL Server, très utile dans ce cas précis.

Exemple d’utilisation : exec sp_change_users_login ‘Update_one’, ‘username’, ‘loginname’
username  est un utilisateur de base de données et loginname  une connexion SQL Server.

Cette méthode semble dépréciée par Microsoft, mais est toujours utile pour une utilisation exceptionnelle.

Voir aussi