Récupérer l’accès au back office Magento

Pourquoi ce genre d’informations est toujours difficile à trouver ?! C’est chiant, vraiment, surtout lorsque pour des applications basées sur Magento, je suis du côté de l’administrateur/hébergeur et non du côté du développeur, donc je n’ai aucune idée de la manière dont fonctionne le bouzin (et oui ce truc est bien une machine à vapeur)

Bref, voici une requête SQL (à adapter) permettant d’ajouter un nouvel administrateur et donc retrouver l’accès au back office de Magento.

-- disable old admins
UPDATE admin_user SET is_active=0;

-- creating a new user
INSERT INTO admin_user(firstname, lastname, email, username, password, created)
	VALUES('Lord', 'Veovis', 'got@is-here.fr', 'veovis', CONCAT(MD5(CONCAT('rr', 'my new password')), ':rr'), NOW());

-- granting the new user as GOD
INSERT INTO admin_role(parent_id, tree_level, role_type, user_id, role_name)
	SELECT (SELECT role_id FROM admin_role WHERE role_name = 'Administrators'), 2, 'U', LAST_INSERT_ID(), 'veovis';

-- only if the domain name has changed.
-- WARNING: config_id controlling domain name in plain an secure http are probably not static and different on your deployment
UPDATE core_config_data SET value='http://new-domaine.name.fr/' WHERE config_id IN (3,4);

Stocker les certificats OpenVPN dans le magasin de certificats de Windows

J’ai très fortuitement découvert une fonctionnalité dans OpenVPN permettant non plus de charger le certificat utilisateur depuis un fichier non chiffré (ou dont le chiffrage présente très peu d’intérêt) mais directement depuis le magasin de certificats Windows, rendant ainsi très difficile l’extraction du certificat une fois installé.

C’est entre autre pratique dans les cas suivants :

  • environnement multi-administrateur
  • vol
  • faible contrôle sur la machine physique

Cela se fait via le paramètre cryptoapicert , et remplace logiquement les paramètres cert  et key . Il s’utilise de la manière suivante :

  • En précisant le sujet du certificat à utiliser : cryptoapicert « SUBJ:Peter Runestig »
  • En précisant l’empreinte du certificat à utiliser : cryptoapicert « THUMB:f6 49 24 41 01 b4 … »

Note : OpenVPN dans sa version 2.3 ne supporte toujours pas les certificats encore exotiques, comme ceux utilisant des courbes elliptiques. Il faudra se limiter à du classique RSA/SHA1.

Redémarrer proprement un hôte Windows hébergeant des vms

Depuis la version 8 de VMware Workstation, Vmware a semble-t-il combiné VMware Workstation avec VMware Server en terme de fonctionnalités. On remarquera d’ailleurs que VMware Server n’est plus mis à jour depuis 2009 et plus supporté depuis 2011 par l’éditeur.
Il est donc possible désormais de démarrer des machines virtuelles en même tant que l’hôte. Il n’est plus nécessaire d’ouvrir VMware Workstation à chaque fois, il n’est plus nécessaire d’ouvrir une session et de la laisser ouverte tant qu’on en a besoin. C’est très pratique cependant s’il est possible d’avoir un démarrage automatique, il n’y a pas d’arrêt automatique autre qu’un arrêt brutal des machines virtuelles lorsque l’hôte s’arrête. Du moins il n’y a pas d’interface graphique ni de documentation officielle permettant de paramétrer ce point.

Voici donc la documentation non-officielle pour paramétrer l’auto-stop. Je n’ai pas poussé afin de savoir s’il était possible de configurer l’auto-stop par vm ni qu’elles sont toutes les possibilités, mais je pense que la méthode décrite ci-dessous suffira.

  • Éditez le fichier %ProgramData%\VMware\hostd\vmAutoStart.xml
  • Remplacez PowerOff  par Suspend  dans le nœud stopAction . Cela aura pour effet de suspendre les vms à l’arrêt de l’hôte. Shutdown  marche peut-être également mais je ne l’ai pas testé.
  • Redémarrez le service gérant les machines virtuelles, éventuellement en prenant soin d’éteindre proprement les machines virtuelles.
  • Le tour est joué.

Au cas où il y aurait des utilisateurs de VMware Workstation sous Linux (y en a-t-il ?), je suppose que la méthode est similaire et que le fichier correspondant se trouve quelque part dans /var/lib .

Mise en garde : C’est peu probable mais VMware pourrait très bien retirer cette fonctionnalités dans une prochaine version ou mise à jour de VMware Workstation.

Installer PHP sous Windows mais sans Apache

Vu l’incapacité de l’équipe PHP à fournir des instructions d’installation correctes (genre à jour) sous Windows (ou le manque de volonté, cela revient au même), et parce qu’Apache sous Windows est une hérésie (alors que sous Linux, c’est simplement de la débilité), je m’atèle à résoudre ce problème.

Installation automatique

Je ne m’étendrai pas beaucoup là-dessus, il suffit de suivre les instructions de cette page. La dernière fois que j’ai tenté cette installation, j’ai eu quelques soucis mineurs, on va dire que pour une install rapide, ça ne marche pas trop mal.

Installation manuelle pour IIS6

A quelques détails près, la procédure à suivre est similaire à celle pour IIS7. Par contre continuer à utiliser II6 et surtout pour autre chose que du .NET, ça craint d’un point de vue sécurité.

Installation manuelle pour IIS7 et +

La procédure est identique en tout point à celle pour IIS Express (plus bas), sauf qu’il faut être admin de la machine et que le bon fichier de configuration se trouve dans C:\Windows\System32\inetsrv\config .
L’avantage néanmoins d’avoir un IIS pas express, c’est qu’il y a une interface graphique, c’est probablement plus simple et safe que de sortir directement le burin.

Je détaillerai prochainement la partie graphique (avec des screen) et complètement cette section.

Installation manuelle pour IIS Express

  • Installez IIS Express si ce n’est pas déjà fait en le téléchargeant ici. C’est la seule étape qui nécessite d’être administrateur de la machine, tout le reste peut être réalisé par un utilisateur lambda.
  • Téléchargez la (dernière de préférence) version de PHP ici en prenant soin de préférer la version non thread-safe (NTS) : http://windows.php.net/download/#php-5.4
  • Décompressez php où vous le souhaitez, par exemple dans %ProgramFiles(x86)%\PHP 5.4.17  si vous êtes administrateur ou bien dans %USERPROFILE\AppData\Local\PHP 5.4.17 s’il s’agit d’une installation locale à un utilisateur particulier. Pour la suite de la procédure, on considèrera %INSTALL% %INSTALL%  comme le répertoire d’installation de PHP.
  • Éditez le fichier %USERPROFILE%\Documents\IISExpress\config\applicationhost.config de l’utilisateur souhaitant bénéficier de PHP sur sa plateforme IIS Express
  • Cherchez le nœud fastCgi  dans le nœud system.webServer  et ajoutez-y le nœud suivant : <application fullPath= »%INSTALL%\php-cgi.exe » />
  • Ajoutez ensuite le handler suivant (nœud à ajouter dans le nœud handlers) <add name= »php5″ path= »*.php » verb= »* » modules= »FastCgiModule » scriptProcessor= »%INSTALL%\php-cgi.exe » resourceType= »File » /> . Attention, ce handler doit être ajouté avant les handlers génériques, en particuliers les handlers suivants : StaticFileModule  et les ExtentionlessUrl* .
  • Éditez le fichier %INSTALL%\php.ini  en prenant comme base le fichier php.ini-production  (par exemple) qui se trouve dans le même répertoire
    • Fixez le path comme suit : include_path = « .;%INSTALL%\ext »
    • Fixez cgi.force_redirect = 0
    • Dans la section [Date] , fixez le timezone comme suit : date.timezone = Europe/Paris
    • Spécifiez la variable ext à ext
    • [Optionnel] Mettez la variable short_tags  à On
  • C’est normalement terminé, il n’y a plus qu’à tester le bon fonctionnement de PHP avec le classique <?php phpinfo();

Note

L’équipe PHP ne propose que des builds 32 bits. Il y a des builds 64 bits, mais elles ne sont actuellement pas considérées comme stable.

Monter un tunnel IPSec sous Linux

Ce billet détaille comment monter un tunnel IPSec sous Linux. C’est à mon sens un must have, principalement parce qu’IPSec est une merde ignoble sous Linux.
Mais avant de procéder plus avant, une question se pose.

Pourquoi IPSec ?

Actuellement je souhaite relier :

  • plusieurs serveurs sur Internet
  • plusieurs réseau locaux (celui du bureau et ceux des machines virtuelles derrières le routeur qui détient l’IP publique)

Voici mes possibilités pour réaliser ce « gros » réseau :

  • créer plein de règles nat sur chaque routeurs.
    • c’est pénible à maintenir
    • oblige à reconfigurer les services pour n’utiliser que certaines plages de ports, et sans chevauchement d’une machine/vm à l’autre
    • oblige à avoir une feuille avec la table de mapping et utiliser des ports non standards
      Pas géniale comme solution, et les tuyaux ne sont pas sécurisés.
      On peut alors reconfigurer tous les services pour protéger chaque flux, mais la manière de faire et la possibilité dépendent du service. Désormais on a la plupart des tuyaux qui sont sécurisés et encore plus de maintenance.
  • mettre en place OpenVPN qui répond entièrement à la problématique, mais :
    • il est architecturé en étoile (1 serveur, plusieurs clients). On peut aussi installer OpenVPN sur chaque routeur en mode serveur, mais c’est pas mal de configuration.
    • il fonctionne en faisant le transport sur la couche applicative du modèle OSI (les paquets sont encapsulé dans un flux SSL sur du TCP ou UDP), cela induit un peu d’overhead
      C’est la solution qui est actuellement en place chez moi.

Par rapport à OpenVPN, voici les avantages d’IPSec :

  • c’est du P2P, il n’y a pas de notion « serveur », les routeurs se connectent donc en direct
  • comme OpenVPN, la communication entre les 2 pairs est chiffrée
  • il est kernel-space sous Linux et Windows, il est donc moins lourd qu’OpenVPN et ne nécessite aucune installation sous Windows
  • son intégration aux protocoles IPs lui permet d’avoir un overhead plus faible qu’avec OpenVPN, donc une bande passante plus large
  • les tunnels d’OpenVPN semblent saturer vite vers 10Mbps chez moi

Quelle implémentation d’IPSec ?

C’est une question qui ne se pose que pour le monde Unix. Avoir le choix c’est bien, mais dans le cas d’IPSec, c’est un peu compliqué. Côté logiciel, il y a eu FreeSwan, puis OpenSwan, puis StrongSwan ; côté noyau également, il a existé plusieurs implémentations : klips et netkey.
Aujourd’hui, j’ai jeté mon dévolu sur strongswan. Klips n’existe plus et les autres logiciels ne sont plus maintenus depuis plusieurs années, c’est donc quasiment un choix par défaut, mais également pour la négociation par certificats que strongswan est le seul à proposer (et que je trouve beaucoup plus simple à configurer que le Pre-Shared Key).

La conf !

Elle est très simple. Voici un exemple fonctionnel ci-dessous qui utilise l’authentification mutuelle par certificat, pour le détail: RTFM, ce dernier est plutôt à jour et bien réalisé.
Je ne détaille pas comment générer les certificats, ce n’est pas le but du billet, et puis j’ai déjà traité ça ici.

config setup
cachecrls=yes
# uniqueids = no

# Add connections here.
conn %default
auto=start
compress=no # ne fonctionne pas
dpdaction=restart
esp=aes128-sha1!
ike=aes128-sha1-modp2048,aes128-sha1-modp1024!
rightallowany=yes
left=2001:41d0:fe1c:1300:20c:29ff:fe99:fbf
#left=%any
leftauth=pubkey
rightauth=pubkey
leftid="C=FR, O=Kveer, OU=Kveer IPSec Services, CN=Tefnout"
leftca="C=FR, O=Kveer, OU=Kveer IPSec Services, CN=Kveer IPSec CA"
rightca=%same
leftcert=tefnout.crt
leftfirewall=no
mobike=no
keyexchange=ikev2

conn illidan
right=illidan.kveer.fr
rightid="C=FR, O=Kveer, OU=Kveer IPSec Services, CN=Illidan"
leftsubnet=192.168.3.0/24
rightsubnet=192.168.14.128/27
# les règles iptables à ajouter.
iptables -A INPUT -p udp -m multiport --dport isakmp,ipsec-nat-t -m comment --comment ipsec -j ACCEPT
iptables -A INPUT -p esp -j ACCEPT
iptables -t nat -I POSTROUTING 1 -m policy --dir out --pol ipsec -j ACCEPT

La dernière règle iptables est à ne pas oublier si l’on souhaite faire fonctionner le tunnel pour les routeurs eux-mêmes. Dans le cas d’un tunnel IPv4, ça ne marchera pas, dans le cas d’un tunnel IPv6, le kernel va générer un Oops (la règle est obligatoire sous peine de non-sens, mais cela n’autorise pas le kernel à planter, c’est bien un bug, en attente de correction)

Intégration des modules vmware à linux

Il n’y a pas si longtemps, j’avais écrit un billet permettant de compiler soit-même les quelques modules VMware fournit dans les VMware Tools.
J’ai pu tester ce script à plusieurs reprises d’ailleurs, à chaque mise à jour de kernel en fait, et ça dépanne bien.
Il y a juste un patch, celui concernant le module vmci , qui est à faire manuellement. Pour une raison qui m’échappe encore (je n’ai pas trop cherché non plus, mais je penche vers un problème d’espaces), le copier/coller depuis le script ne fonctionne pas.

Et bien ce billet annonce la bonne nouvelle : ce script va faire partie des vieilleries car depuis la branche 3.9 du noyau Linux, ces modules font désormais partie intégrante du noyau.
Voici le nom des modules (j’en profite également pour rappeler l’existence du pilote vmxnet3 ):

  • CONIG_VMWARE_VSOCKETS
  • CONFIG_VMWARE_VMCI_VSOCKETS
  • CONFIG_VMWARE_BALLOON
  • CONFIG_VMWARE_VMCI
  • CONFIG_VMXNET3

Les re-voici dans le menuconfig, pour vous faciliter la recherche :

 

* Device Drivers --->
** Misc Devices --->
*** \[*\] VMware Balloon Driver
*** \[*\] VMware VMCI Driver
** \[*\] Network device support --->
*** VMware VMXNET3 ethernet driver
* \[*\] Networking support --->
** Networking options --->
*** <*> Virtual Socket protocol
*** <*> VMware VMCI transport for Virtual Sockets

Adieu les vmware tools sous Linux (et sans regrets) !

Exchange ne veut plus recevoir de mails

J’ai eu le cas d’un serveur Exchange 2010 qui s’est mis à ne plus recevoir de messages de l’extérieur.
Tout semblait fonctionner :

  • les services étaient tous au vert
  • aucune erreurs ou alertes dans les journaux d’événements
  • les clients pouvaient consulter leurs mails, leurs contacts et leurs taches
  • aucune mise à jour n’a été installé récemment
  • aucun changement de configuration faite récemment

Et pourtant impossible de recevoir et/ou envoyer.
J’ai pu trouver la solution, faute de mieux, en loguant une conversation SMTP avec le serveur Exchange afin de voir ce qu’il se passait réellement, et la bingo : le serveur a répondu 4.3.1 Insufficient System Resources.

Après une courte recherche, il s’est avéré qu’Exchange estimait ne plus avoir suffisamment d’espace disque pour fonctionner convenablement, c’est à dire moins de 4~5 Go de libre. C’est par design, une mesure de sécurité permettant d’avoir un système online en interdisant de dévorer le peu d’espace libre restant.

J’ai ensuite récupéré un peu d’espace disque là où je pouvais, notamment en supprimant des archives laissées par l’installation des cumulative updates Exchange (soit quelques 2Go quand même), ce qui m’a permis de constater le retour à la normal d’Exchange, me laissant ainsi le temps de planifier une petite maintenance pour étendre le disque dur devenu trop petit (facile dans un environnement virtuel ;)).

Voir aussi

IPv6 sous Linux

Autant sous Windows l’IPv6 se configure tout seul, autant sous Linux, c’est une autre histoire, en particulier si ce dernier fait office de routeur IPv6 et qu’on a configuré proprement le pare-feu (ou alors je n’ai rien capté, c’est aussi possible).

Il y a deux aspects à voir, tout d’abord lorsque l’OS sert de routeur IPv6 (qu’il soit ou pas routeur IPv4 n’importe pas), c’est à dire lorsque net.ipv6.conf.default.forwarding = 1 , ce dernier n’écoute plus les Router Advertisement, même si net.ipv6.conf.default.accept_ra = 1  et par conséquent, l’IPv6, le masque de sous-réseau ainsi que les routes sont à configurer manuellement. Cela peut surprendre de prime abord.

Le second aspect se situe au niveau de la découverte de ses voisins. En IPv4, cela se fait avec des paquets ARP, alors qu’en IPv6, cela se fait avec des paquets ICMPv6.
Pour rappel, ARP est un protocole de lien, ce n’est pas encapsulé dans un paquet IP.
D’un point de vue du pare-feu, c’est pratique car alors que iptables ne peux filtrer des paquets ARP, puisque ces derniers n’ont rien à voir avec la couche IP (c’est le rôle d’ebtables), ip6tables sait parfaitement filtrer des paquets ICMPv6, eux-mêmes étant encapsulés dans un paquet IPv6. Mais il faut y penser lorsqu’on active son pare-feu.
Cela donne par exemple pour Gentoo :

# /etc/conf/net
config_eth0="192.168.3.2/24
2001:41d0:fe1c:1300:20c:29ff:fe99:fbf/56"
routes_eth0="
default via 192.168.3.1
"2000::/3 via fe80::5a98:35ff:fea1:a7ea" # ça ne sert à rien de router autre chose que des adresses internet pour un serveur dédié "normal"

La première chose qu’on fait en général avec le pare-feu, c’est de passer la stratégie par défaut à DROP, en ajoutant le minimum syndical, à savoir un accès SSH notamment si on n’est pas en local sur la machine. Mais faire cette manip coupe également le bon fonctionnement de l’IPv6.

Après analyse avec tcpdump des trames réseau, on en vient à la configuration d’un pare-feu stateful suivante :

# attention: on flush toute la table, et on change la règle par défaut afin de rester connecté
ip6tables -P INPUT ACCEPT
ip6tables -F INPUT
ip6tables -A INPUT -m ctstate --ctstate INVALID -j DROP
ip6tables -A INPUT -m ctstate --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT
ip6tables -P INPUT DROP
# vos règles d'accès commencent ici

 

Les deux premières règles permettent un minimum de protection contre des paquets éventuellement forgés.
La troisième permet d’autoriser toute connexion sur la boucle locale.

Les règles 4 et 5 sont celles qui font marcher le schmilblick et permet au système de découvrir ses voisins, en particulier l’adresse MAC de sa passerelle vers internet. Il n’est pas possible de filtrer par adresse source, car les requêtes peuvent être légitimement émises par des adresses locales (fe80::/10 ), multicast (ff00:/8 ) ou unicast routables (2000::/3 ), en conséquences on filtre sur le nombre de sauts, qui doit être de 1 avec le filtre hl (hop limit), sachant que dans le cas d’un serveur dédié, seul les réponses et requêtes de la passerelle sont désirées et légitimes.

Compiler les modules vmware sous linux

Afin d’améliorer le fonctionnement et les performances des machines virtuelles, VMware fournit les VMware tools.
Ces  »tools » se décomposent en :

  • une application graphique (wait whaaat ? did you say UI ??)
  • des kernel modules pré-compilés, ainsi que les sources pour les autres noyaux.

J’aurais pu me contenter de fournir les patches, lesquels auraient été suffisant pour compiler les modules, mais en plus d’avoir des codes sources obsolètes, l’installeur s’est mis à dysfonctionner. Impossible donc de compter sur lui pour faire le boulot.

En décortiquant l’installeur, je suis arrivé à un binaire, qui est responsable de la localisation des linux headers sur ma machine, c’est lui qui pour une raison qui m’échappe, ne trouve plus les linux-headers, mais de par sa forme binaire, c’est une voie sans issue (je ne suis pas expert en reverse engineering, et encore moins sous Linux)…

Aucune importance : j’ai trouvé mieux. En décompressant les sources qui se trouvent dans ~/lib/modules/sources , il m’a suffit de lancer un make  et la magie s’est opérée : j’avais mes modules (enfin… après quelques petites modifications) !!

Ce script fonctionne précisément pour les kernels de la branche 3.8 patchés avec grsec. En enlevant les appels à pax_open_kernel  et pax_close_kernel  ou en mettant la bonne pré-condition, on pourrait le rendre compatible avec n’importe quel kernel  de la branche 3.8 je pense.

J’aurais pu fournir les fichiers patch à part, mais j’ai préféré ne garder qu’un seul fichier, afin de conserver une certaine simplicité de gestion pour la maintenance du script.

# sources:
# https://bugs.gentoo.org/attachment.cgi?id=289757&action=edit
# http://pastebin.com/dVPszctW
# https://bugs.gentoo.org/show_bug.cgi?id=461872
mount /mnt/cdrom
tar -xvzf /mnt/cdrom/vmware-tools-distrib.tar.gz /root/
cd /root/vmware-tools-distrib/lib/modules/source

echo compiling vmmemctl...
tar -xvf vmmemctl.tar
cd vmmemctl-only
make
cd ..

echo compiling vmsync
tar -xvf vmsync.tar
cd vmsync-only
echo '
--- driver/sync.c 2013-04-16 21:52:23.277342798 +0200
+++ driver/sync.c 2013-04-16 21:53:43.094056640 +0200
@@ -162,7 +162,7 @@
cancel_delayed_work(&state->thawTask);
list_for_each_safe(cur, tmp, &state->devices) {
dev = list_entry(cur, VmSyncBlockDevice, list);
- if (dev->sb != NULL && dev->sb->s_frozen != SB_UNFROZEN) {
+ if (dev->sb != NULL && dev->sb->s_writers.frozen != SB_UNFROZEN) {
thaw_bdev(dev->bdev, dev->sb);
atomic_dec(&gFreezeCount);
}
@@ -237,7 +237,7 @@
* the superblock is already frozen.
*/
if (inode->i_sb->s_bdev == NULL ||
- inode->i_sb->s_frozen != SB_UNFROZEN) {
+ inode->i_sb->s_writers.frozen != SB_UNFROZEN) {
result = (inode->i_sb->s_bdev == NULL) ? -EINVAL : -EALREADY;
compat_path_release(&nd);
goto exit;
' | patch sync.c
make
cd ..

echo compiling vmci
tar -xvf vmci.tar
cd vmci-only
echo '
--- linux/driver.c 2013-04-17 20:19:38.778514246 +0200
+++ linux/driver.c 2013-04-17 20:43:31.109809776 +0200
@@ -124,7 +124,7 @@
.name = "vmci",
.id_table = vmci_ids,
.probe = vmci_probe_device,
- .remove = __devexit_p(vmci_remove_device),
+ .remove = vmci_remove_device,
};

#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 19)
@@ -252,7 +252,21 @@
#define LinuxDriverUnlockIoctlPerFD(mutex) do {} while (0)
#endif

-static struct file_operations vmuser_fops;
+/* Initialize the file_operations structure */
+static struct file_operations vmuser_fops = {
+ .owner = THIS_MODULE,
+ .poll = LinuxDriverPoll,
+#ifdef HAVE_UNLOCKED_IOCTL
+ .unlocked_ioctl = LinuxDriver_UnlockedIoctl,
+#else
+ .ioctl = LinuxDriver_Ioctl,
+#endif
+#ifdef HAVE_COMPAT_IOCTL
+ .compat_ioctl = LinuxDriver_UnlockedIoctl,
+#endif
+ .open = LinuxDriver_Open,
+ .release = LinuxDriver_Close
+};


/*
@@ -389,26 +403,6 @@
return -ENOMEM;
}

- /*
- * Initialize the file_operations structure. Because this code is always
- * compiled as a module, this is fine to do it here and not in a static
- * initializer.
- */
-
- memset(&vmuser_fops, 0, sizeof vmuser_fops);
- vmuser_fops.owner = THIS_MODULE;
- vmuser_fops.poll = LinuxDriverPoll;
-#ifdef HAVE_UNLOCKED_IOCTL
- vmuser_fops.unlocked_ioctl = LinuxDriver_UnlockedIoctl;
-#else
- vmuser_fops.ioctl = LinuxDriver_Ioctl;
-#endif
-#ifdef HAVE_COMPAT_IOCTL
- vmuser_fops.compat_ioctl = LinuxDriver_UnlockedIoctl;
-#endif
- vmuser_fops.open = LinuxDriver_Open;
- vmuser_fops.release = LinuxDriver_Close;
-
sprintf(linuxState.deviceName, "vmci");
linuxState.major = 10;
linuxState.misc.minor = MISC_DYNAMIC_MINOR;
@@ -1750,7 +1744,7 @@
*-----------------------------------------------------------------------------
*/

-static int __devinit
+static int
vmci_probe_device(struct pci_dev *pdev, // IN: vmci PCI device
const struct pci_device_id *id) // IN: matching device ID
{
@@ -1978,7 +1972,7 @@
*-----------------------------------------------------------------------------
*/

-static void __devexit
+static void
vmci_remove_device(struct pci_dev* pdev)
{
struct vmci_device *dev = pci_get_drvdata(pdev);
' | patch linux/driver.c
make
cd ..

echo compiling vsock
tar -xvf vsock.tar
cd vsock-only
cat ../vmci-only/Module.symvers >> Module.symvers
cp linux/af_vsock.c linux/af_vsock.c.bak
echo '
--- linux/af_vsock.c 2013-04-17 20:25:44.093536289 +0200
+++ linux/af_vsock.c 2013-04-17 20:27:51.518312015 +0200
@@ -3160,11 +3160,15 @@
* else in the future.
*/
for (i = NPROTO - 1; i >= 0; i--) {
- vsockVmciFamilyOps.family = i;
+ pax_open_kernel();
+ *(int *)&vsockVmciFamilyOps.family = i;
+ pax_close_kernel();
err = sock_register(&vsockVmciFamilyOps);
if (err) {
Warning("Could not register address family %d.\n", i);
- vsockVmciFamilyOps.family = VSOCK_INVALID_FAMILY;
+ pax_open_kernel();
+ *(int *)&vsockVmciFamilyOps.family = VSOCK_INVALID_FAMILY;
+ pax_close_kernel();
} else {
vsockVmciDgramOps.family = i;
vsockVmciStreamOps.family = i;
@@ -3202,7 +3206,9 @@
sock_unregister(vsockVmciFamilyOps.family);
}

- vsockVmciDgramOps.family = vsockVmciFamilyOps.family = VSOCK_INVALID_FAMILY;
+ pax_open_kernel();
+ vsockVmciDgramOps.family = *(int*)&vsockVmciFamilyOps.family = VSOCK_INVALID_FAMILY;
+ pax_close_kernel();
vsockVmciStreamOps.family = vsockVmciFamilyOps.family;
}' | patch -l linux/af_sock.c
make
cd ..

if [ -f pvscsi.tar ]
tar -xvf pvscsi.tar
cd pvscsi-only
echo '
--- pvscsi.c 2013-05-14 23:24:04.801773269 +0200
+++ pvscsi.c 2013-05-14 23:25:34.701065554 +0200
@@ -455,7 +455,7 @@
SCSI_SENSE_BUFFERSIZE, PCI_DMA_FROMDEVICE);
}

-static int __devinit pvscsi_allocate_rings(struct pvscsi_adapter *adapter)
+static int pvscsi_allocate_rings(struct pvscsi_adapter *adapter)
{
adapter->rings_state = pci_alloc_consistent(adapter->dev, PAGE_SIZE,
&adapter->ringStatePA);
@@ -1234,7 +1234,7 @@
* just use a statically allocated scatter list.
*
*/
-static int __devinit pvscsi_allocate_sg(struct pvscsi_adapter *adapter)
+static int pvscsi_allocate_sg(struct pvscsi_adapter *adapter)
{
struct pvscsi_ctx *ctx;
int i;
@@ -1317,7 +1317,7 @@
return numPhys;
}

-static int __devinit pvscsi_probe(struct pci_dev *pdev,
+static int pvscsi_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
struct pvscsi_adapter *adapter;
@@ -1535,7 +1535,7 @@
.name = "pvscsi",
.id_table = pvscsi_pci_tbl,
.probe = pvscsi_probe,
- .remove = __devexit_p(pvscsi_remove),
+ .remove = pvscsi_remove,
COMPAT_PCI_SHUTDOWN(pvscsi_shutdown)
};' | patch pvscsi.c
make
cd ..
fi

echo installing
LIBDIR=/lib/modules/`uname -r`/misc
[ -d "$LIBDIR" ] || mkdir "$LIBDIR"
cp vmmemctl.o "$LIBDIR/vmmemctl.ko"
cp vmsync.o "$LIBDIR/vmsync.ko"
cp vmci.o "$LIBDIR/vmci.ko"
cp vsock.o "$LIBDIR/vsock.ko"
[ -f pvscsi.o ] && cp pvscsi.o "$LIBDIR/pvscsi.o"

// clean up
rm -R vmci-only vmsync-only vsock-only vmmemctl-only
[ -d pvscsi-only ] && rm -R pvscsi-only

// finished !
# refresh modules.dep.bin for modprobe
depmod

echo "You just have to add this line on /etc/conf.d/modules to auto-load the vmware modules"
echo "module_$(uname -r | sed -e 's/[-.]/_/g')=\"vmmemctl vmsync vmci vsock pvscsi\""

Le petit plus du script : il évite d’installer les VMware tools. Sans interface graphique, ils ne servent à rien, et sous Gentoo, ça pollue la sortie de revdep-rebuild .

Ce script ne compile pas les modules vmxnet  ni vmxnet3 , le premier parce qu’il est déprécié et parce que je ne l’utilise pas, le second parce qu’il est déjà intégré au noyau linux.
Dans des versions ultérieures de linux, il se pourrait que je n’ai même plus à gérer la compilation de vmci  et vsock  : en effet ces derniers pourraient faire une entrée dans le noyau linux.

Notes

J’ai finis de rédiger le script hier soir en compilant mes commandes balancées dans le terminal. Je n’ai jamais testé le script, donc à vos risques et périls !
En revanche, je peux prendre en compte vos remarques.

Utiliser TLSv1.1 et TLSv1.2 sous nginx

Suite à mes 2 précédents billets sur une bonne configuration SSL de son serveur web :

Alléluia, openssl 1.0.1 est enfin marqué stable pour Gentoo. Avec lui, le support de TLS en version 1.1 et 1.2 arrive, lesquels permettent notamment de corriger la fameuse attaque BEAST.

Pour utiliser ces protocoles sous nginx, il suffit juste de compiler openssl, recompiler nginx, redémarrer nginx et le tour est joué 😉

Et maintenant on arrive à la grosse blague du billet : Chrome, que je considère comme l’un des 3 navigateurs majeurs, avec Internet Explorer et Firefox, ne supporte que TLS en version 1.0, lequel est sensible à l’attaque BEAST. Difficile sous ces conditions de désactiver TLS 1.0 et inférieur.

Ci-dessous le score donné par les tests SSL de Qualys de mon serveur web avec TLS v1.0 désactivé par rapport à avant :

qualys_2013

ERRATA : il semble que Chrome, au moins dans sa version 24.0.1312.57, supporte TLS v1.1.