26 Aug 2013, 00:00

Dossier Program Files sous Windows 7

Sous win 7 (et vista ?), lorsqu’un programme lancé avec de simples droits utilisateurs cherche à écrire dans le dossier Program Files, il n’a pas les droits. Pour permettre la compatibilité avec toutes les applications ayant ce comportement, une surcouche a été mise en place : le dossier C:\Users\Username\AppData\Local\VirtualStore. Tous les fichiers devant être mis dans C:\Program Files iront dans Virtualstore, et overrideront le cas échéant ceux présent au niveau système.

13 Jul 2013, 00:00

<3 Debian

Sous Wheezy, tout notre bazar pour faire tourner python correctement se résume à :

sudo aptitude install bundler

Puis dans le répertoire racine du projet Ruby : bundle install

./generate

Content :)

22 May 2013, 00:00

Ports SMTP POP IMAP

Ci-dessous, les ports des différents protocoles :

HTTP

de base : 80
+ ssl   : 443

SMTP

de base : 25
+ auth  : 587
+ ssl   : 465

POP

de base : 110
+ ssl   : 995

IMAP

de base : 143
+ ssl   : 993

02 May 2013, 00:00

Chmod récursif sur dossiers uniquement

Il faut utiliser le paramètre X (x majuscule) à la commande chmod pour indiquer que le flag éxecutable ne doit être mis que sur les dossiers (ou les fichiers qui le possèdent déjà) :

chmod -R u=rwX,go=rX /my/path/*

11 Apr 2013, 00:00

serveur openvpn sous windows 7 x64

Prérequis : Notepad ++

  1. Installer le package OpenVPN en version 64 bits, penser à cocher les scripts RSA
  • Éditer C:\Program Files\OpenVPN\easy-rsa\vars.bat avec N++
  • ouvrir cmd en admin
  • cd “c:\program files\openvpn\easy-rsa”
  • init-config pour copier vars.bat.sample en vars.bat
  • exécuter vars
  • exécuter clean-all pour initialiser serial et index.txt
  • build-dh
  • lancer les commandes build-ca, build-key-server et build-client AVEC un argument ; bien que non repris dans les champs à remplir, ça sera le nom du fichier créé (sinon, nom vide)
  • ajouter la ligne crl-verify “C:\Program Files\OpenVPN\easy-rsa\crl.pem” dans la conf du serveur pour gérer les certificats révoqués (mais fait planter le serveur si crl.pem est absent ou vide => révoquer un certificat test pour initialiser le fichier)

démarrage du service en automatique

désactiver pare-feu sur réseaux publics

redirection routeur 1194

si plusieurs connexions (sur serveur ou client), adapter le nom de la carte réseau à la conf ovpn

15 Mar 2013, 00:00

cohabitation office 2003 2007

Le seul nom d’un executable (et non son chemin entier) est pris en compte par windows pour identifier un programme qui ouvrira une extension. Ex : .doc ouvert par Microsoft Office Word, alias WINWORD.EXE.

Ceci se voit à la clé registre HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.doc\OpenWithList\.

Office 2003 et 2007 ont le même nom d’executable pour Word, ce qui empêche les 2 d’être présents dans la liste « Ouvrir avec ».

Il faut donc renommer l’executable C:\Program Files\Microsoft Office\Office11\WINWORD.EXE en WINWORD2003.EXE

On peut ensuite associer les fichiers .doc au programme WINWORD2003.EXE qui sera différencié de WINWORD.EXE (word 2007, dont le nom d’executable ne peut être modifié, sous peine d’avoir un message d’erreur se rapportant à un problème de mémoire pour Outlook).

Si l’on veut ensuite personnaliser le nom du programme dans la liste « Ouvrir avec », pour que « Word 2003 » et « Word 2007 » soient différenciés, il faut modifier la valeurs de WINWORD.EXE et WINWORD2003.EXE dans la clé registre HKCU\Software\Microsoft\Windows\ShellNoRoam\MUICache\. (les valeurs sont le chemin de l’executable)

Ainsi, on peut aisément différencier les 2 versions de word et ouvrir à son gré celle que l’on préfère.

01 Dec 2012, 00:00

Réappropriation de dossiers et fichiers sous 7 Pro

Dans certains cas de migration de données d’un poste Windows à l’autre, il peut arriver qu’un dossier et tout ce qu’il contient n’ait plus aucun propriétaire. Il est possible de remettre un propriétaire graphiquement et récursivement, mais dans ce cas, cela n’affecte que les dossiers.

La solution est de tout réaffecter à l’administrateur, et alors seulement de redonner les droits à la bonne personne.

Pour ceci : ouvrir une invite de commandes en administrateur (rechercher cmd, puis clic droit et “ouvrir en tant qu’administrateur”) et taper


REM L’administrateur devient propriétaire de tous les dossiers, sous-dossiers et fichiers
REM Contrairement à icacls, ceci fonctionne même en l'absence de droits d'écriture/modification
takeown /f “C:\mon\chemin” /r /D o
REM avec /A, on peut donner l'appartenance au groupe "Administrateurs"

REM On peut donner des droits supplémentaires (ici accès complet) à tel utilisateur ou groupe
icacls "C:\mon\chemin" /grant user1:(OI)(CI)F /grant group2:(OI)(CI)F /C /Q
REM (OI) et (CI) mettent en place l'héritage des droits pour les sous-objets et conteneurs

REM Les droits de tous les sous-dossiers et sous-fichiers sont réinitialisés pour hériter de "mon\chemin"
REM Voir ici : https://serverfault.com/questions/475612/replace-permission-entries-on-all-child-objects-using-icacls
REM /q pour supprimer les messages de réussite ; /t pour la recursivité ; /c pour continuer en cas d'erreur sur un élément
icacls "c:\mon\chemin" /inheritancelevel:e /t /q /c
REM Sans cette étape, l'ajout de droits sur un fichier/conteneur qui a été sorti de l'héritage ne semble pas fonctionner

REM L’utilisateur choisi devient propriétaire de la racine et les fichiers/dossiers directement dedans
icacls “C:\mon\chemin” /setowner userProprio /T /L

Note : sous XP, cela devrait être à peu près similaire, mais avec la commande cacls au lieu de icacls.

24 Sep 2012, 00:00

Réinitialisation de la prise en compte des pilotes matériels sous XP (et probablement Vista/7)

Les informations pour la prise en compte des fichiers de pilotes matériels se trouvent dans le registre, à la clé HKLM\System\CurrentControlSet\Control\Class*

Chaque clé contenue représente un type de périphérique (Processeur, Imprimantes…) et est une suite de caractères non aléatoires. Par exemple, les claviers sont à la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D36E96B-E325-11CE-BFC1-08002BE10318}

et les souris à le clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D36E96F-E325-11CE-BFC1-08002BE10318}

Si il est utile de réinitialiser la facon dont le système prend en compte ces clés (par exemple en cas de conflit IRQ entre les 2…), il sufit de supprimer ces clés et des les remplacer par les clés vierges de Windows. Une manière de les avoir est d’utiliser le Hiren’s Boot CD, utiliser l’outil Registry -> RegistryEditor PE. On renseigne l’install de Windows et il importe les anciennes clés comme un grand, dans HKLM_REMOTE_SYSTEM , HKLM_REMOTE_SOFTWARE etc.

On va chercher la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D36E96B-E325-11CE-BFC1-08002BE10318} (celle du MiniXP live), on l’exporte, puis on la modifie en remplacant HKLM\SYSTEM\CurrentControlSet\ par HKLM_REMOTE_\SYSTEM\ControlSet001 . Le cas échéant, on duplique la ligne en changeant ControlSet002 (autant de fois que de clés existent).

On supprime les clés de l’ancienne installation (HKLM_REMOTE_\SYSTEM\ControlSet00*{4D36E96B-E325-11CE-BFC1-08002BE10318} ), puis on fusionne le .reg modifié.

En redémarrant, le système considèrera le clavier de manière native, en enlevant tout paramétrage fait par les pilotes, les bugs et les antivirus. Idem pour la souris (en adaptant le numéro de clé).

Note : après test, il suffit pour les autres périphériques, de supprimer la clé concernée (fouiller dans la clé Class pour trouver le bon périphérique). Après redémarrage, le périphérique sera listé dans le gestionnaire de périphériques (car “connu” au niveau du pci ID), mais avec pas la moindre information de pilote. Les fichiers de pilote étant encore présents, lancer une détection automatique les retrouvera et les installera automatiquement (même version donc). Ceci doit marcher avec les claviers/souris, mais veiller à toujours en avoir un des deux qui marche…

10 Jun 2012, 00:00

Création d’un utilisateur mobile sous OSX Lion Server

Réalisé avec un Mac Mini sous Lion (10.7.4) fraichement installé, et un client MacBook Pro sous la même version.

Etapes :

Sur le serveur :

  • Installer l’application Server (vendue sur l’app store), et les Server admin Tools v10.7.4 disponibles ici : http://support.apple.com/kb/DL1528 (le français est inclus dans l’installeur)

  • créer un annuiare ldap (Open Directory) sur le serveur. Dans l’appli Server, aller dans le menu Gérer -> Gérer les comptes réseau. Ceci déclenche la procédure de création d’annuaire. L’utilisateur diradmin est créé.

  • ajouter un utilisateur (usermobile) via l’application Server. Maitenant que le serveur héberge un annuaire, le compte créé sera un utilisateur réseau. On le reconait grâce au petit rond bleu a coté de lui. L’utilisateur est pour l’instant seulement présent dans l’annuaire. il n’a pas encore de répertoire.

Note : Une fois qu’un serveur d’annuaire est créé, un ajoure d’utilisateur via l’application Server créera un compte réseau. Si on veut créer un compte local, il faut passer par les préférences système.

  • Dans l’appli Server, ouvrir la partie Partage de Fichiers. Double-cliquer sur Users, et sélectionner “Mettre a disposition des dossiers de départ par AFP”. Eventuellement déselectionner le partage SMB (si environnement homogène mac). Ceci permet la création (et l’accès) à ce dossier pour héberger un dossier home entier. Bien évidemment, penser à activer le partage de fichiers.

  • Ouvrir le Gestionnaire de Groupe de travail (Workgroup Manager) disponible dans les Server Admin Tools 10.7. Se connecter à l’annuaire LDAPv3/127.0.0.1 (pas le local). Cliquer sur le cadenas en haut à droite pour déverrouiller avec l’utilisateur diradmin. Sélectionner usermobile, puis aller sur l’onglet “Départ”. Sélectionner /Users et cliquer le symbole – en bas pour supprimer ce dossier Home (sinon, le client obéira betement et créera betement un dossier /Users/usermobile chez lui ! ) Puis séléectionner la ligne afp://server.local/Users et cliquer sur Créer Départ (en bas). Ainsi, le répertoire physique sera créé sur le serveur (/Users/usermobile). Cliquer sur Enregistrer.

  • Toujours dans le Workgroup Manager, sélectionner usermobile, et cliquer sur l’icône Préférences (en haut de la fenêtre). Séléctionner “Mobilité”, aller dans l’onglet “Création de compte”, puis “Création”. Cocher Gérer : “Toujours” puis cocher “Créer un compte si l’ouverture…”. Valider par “Appliquer”

————————

On passe maintenant sur le portable (client). Il a bien sûr déjà un compte avec privilèges administrateur, que je nommerai ici admin. L’install est fraîche, c’est donc le seul compte existant (si vous déjà un compte du même nom que usermobile, sauvegardez les données et supprimez-le ! )

  • Ouvrir les préférences système puis “Utilisateurs et groupes”. Déverrouiller avec le cadenas en bas à gauche. Cliquer sur Options. A côté de Compte serveur réseau, cliquer sur “Rejoindre”. Rentrer l’IP (ou mieux, le hostname du server, type “mac-mini-de-bidule.local” que l’on peut trouver dans les informations de l’appli Server ) et valider. Accepter les certificats SSL. Continuer sur l’avertissement de non-sécurisation du réseau.

  • Toujours dans les Options, devant “Ouverture de session par” sélectionner “nom et mot de passe”.

–> Le portable est maintenant connecté à l’annuaire du serveur. Ainsi, si un utilisateur demande à se connecter et n’existe pas dans les utilisateurs locaux, il ira vérifier si cet utilisateur existe sur le serveur.

  • Se déconnecter de la session admin. Rentrer les identifiants et mot de passe de usermobile. Confirmer la création du compte mobile.

–> Il crée le dossier utilisateur en local, et lance la première synchronisation. A partir de la, la synchronisation se fera automatiquement. Vous pouvez définir les options de synchronisation dans Paramètres système –> Utilisateurs et groupes –> sélectionner usermobile –> réglages du compte mobile. Vous avez aussi une icône dans la barre de notification qui indiqué l’état et permet de faire une synchro.

  • Maintenant que l’utilisateur existe en local, vous pouvez si vous le souhaitez remettre les utilisateurs à la fenêtre de login.

03 Jun 2012, 00:00

Débriquer un routeur WRT54GL (v1.1)

Suite à une tentative d’upgrader le firmware DD-WRT de mon WRT54GL, la procédure ne s’est jamais terminée, et au reboot suivant, le routeur était briqué : impossibilité de s’y connecter, d’abtenir une adresse ip ou de l’administrer. Le voyant power clignotait rapidement, toutes les autres leds étaient éteintes.

J’ai donc trouvé, suivi et validé cette procédure (http://mediatux.com/openwrt54g.php) que je répète ici :

  • télécharger le firmware OpenWRT ici
  • ouvrir le routeur. Il faut d’abord retirer les antennes wifi. J’y suis personnellement arrivé en forçant très fort sur les pieds avants du routeur (partie bleue), vers l’avant.
  • relier une antenne wifi à la 16e patte du chip sous la puce broadcom avec un fil de cuivre (dans mon cas, un cable d’enceinte a parfaitement fait l’affaire)
  • préparer un pc sous linux avec une carte réseau attribuée en ip fixe à l’adresse 192.168.1.3. Relier cette carte au routeur par ethernet.
  • se placer dans le dossier contenant le firmware sus-mentionné
  • lancer la commande tftp 192.168.1.1 puis > binary > trace >rexmt 1 > timeout 90

Mettre le routeur sous tension. Lorsque seule la diode power est allumée et clignote, lancer sur le pc linux la commande suivante : > put openwrt-wrt54g-squashfs.bin

L’envoi du nouveau firmware est en cours et défile à l’écran. Une fois l’opération terminée (quelques secondes), attendre que le routeur redémarre (SANS LE REBOOTER MANUELLEMENT). une fois opérationnel, le voyant power sera fixe, et OpenWrt bien installé sur le routeur !