dimanche 19 mai 2013

fun_plug sur clé USB pour D-Link DNS-320LW

Comme moi, vous avez peut-être profité de l'offre de TopAchat proposant un NAS D-Link DNS-320LW + 2x2To (soit 4To) à 200€ (soit le prix des 2 disque sur, en fait).
De base, le NAS propose déjà pas mal de fonctions (FTPS, SMB, NFS, DLNA, des droits suffisamment fin, JBOD, interface de téléchargement, et j'en passe pas mal), mais il est possible (merci à D-Link pour cela) d'augmenter encore ses capacités !

Une petite information au passage, parce que j'ai cherché moi aussi : matériellement, la version 320L (et W pour white of course) est très proche du 320, mais possède le double de mémoire (256Mo) et un processeur de 1Ghz (contre 800MHz). Le firmware semble être vraiment différent cependant, peut-être pas au niveau de l'interface, mais le 320 en est à la 2 alors que le 320L à la 1.

Revenons à ce qui nous intéresse : fun_plug (ffp). Grâce à D-Link, il est possible d’exécuter un script au démarrage du NAS, parce que si un fichier fun_plug est présent sur le volume 1, il est appelé à la fin du démarrage, justement pour tolérer ce fonctionnement. Des gens ont donc compilé des binaires fonctionnants sur le NAS et on peut retrouver un vrai petit environnement Linux.

Dans le fonctionnement de base, un place fun_plug et une archive fun_plug.tgz à la racine du volume 1, au 1er boot celle-ci est décompressé puis supprimé et offre un accès telnet, ce fut ma 1ère tentative (en passant par l'interface web d'envoi de fichier, qui own les fichier en root:root et mode en 777). Bien, on retrouve un accès root, un shell, c'est gagné.

Mais au reboot, le 320L devient chiant car un effectue un chmod 777 -R sur tout les volumes, nos fichiers (ah oui au fait, en interne c'est de l'ext4) perdent donc leurs modes et par exemple :
  • tout les scripts de /ffp/start/ (le init.d de ffp) sont +x, les services se retrouvent tous lancés au 2ème reboot
  • les fichiers clés d'sshd sont aussi en 777, accès libre pour tous, et comme sshd n'aime pas cela, il refuse de se lancer, plus de ssh, ou renvoi des erreurs dans les logs.
Autre petit souci, les scripts/binaires étant situés sur les disque dur, cela oblige ces derniers à être relancés régulièrement, on perd une partie du coté "éco". Il est possible de placer fun_plug sur une clé USB, et c'est ce que je vais expliquer (du moins, à ma façon). Arrivé ici, j'ai déjà un fun_plug installé sur le disque dur, rebooté seulement pour son installation (avant le 2ème reboot qui chmod tout), avec juste le telnet. Sur le 320L, la clé USB est monté sur /mnt/USB/USB_c1 (il faut adapter).

Formater la clé USB

umount /dev/sdxx
fdisk /dev/sdx
d
c
p
1
w
mkfs.ext4 -O ^has_journal -E stride=2,stripe-width=1024 -b 4096 /dev/sdxx
En me fiant à http://blogofterje.wordpress.com/2012/01/14/optimizing-fs-on-sd-card/ pour les options de formattage car ma clé USB est en fait un lecteur de carte, mais je pense que ça s'applique de la même façon à une "vrai" clé USB.

Installer fun_plug dessus

cd /mnt/USB/USB1_c1
wget http://ffp.inreto.de/ffp/0.7/arm/fun_plug.tgz
tar xzf fun_plug.tgz -C ffp/
/ffp/bin/tar xzf fun_plug.tgz -C ffp/

Utiliser un fun_plug compatible USB

J'ai utilisé ce fun_plug (venant d'ici) qui est une variante de l'original a peine modifié (je préfère) pour fonctionner en USB lorsque c'est possible. Le fichier fun_plug lui reste sur le volume 1 (c'est ici que le firmware le cherchera), mais tout le dossier /ffp/ sera situé sur la clé USB. Celle-ci se trouve d'ailleurs dans /mnt/USB/USB_c1/ et non HD_c1, il faut donc modifier le fichier fun_plug : 
sed -ie 's#USB/HD_c1#USB/USB1_c1#g' /mnt/HD/HD_a2/fun_plug
Je l'ai aussi modifié pour qu'il remonte la clé USB en noatime et nodiratime (qui feraient trop d'accès sur la clé) et sauve une copie du dmesg au boot, au final on obtient ceci : 

#!/bin/sh

# switch to safe working directory on ramdisk
cd /

# fichier de trace
exec >>/mnt/HD/HD_a2/ffp.log 2>&1

# Bootlog
dmesg > /var/log/boot.log

# Activation de autoboot USB (O ou N)
AUTOBOOT_USB=O
# Emplacement du repertoire FFP
FFP_USB_DRIVE=/mnt/USB/USB1_c1
FFP_PATH_USB=$FFP_USB_DRIVE/ffp
FFP_PATH=/mnt/HD/HD_a2/ffp

# Si on utilise ffp sur USB et qu'elle est présente, on change les options de montage
if [ "$AUTOBOOT_USB" = "O" ] && [ -d $FFP_PATH_USB ]; then
  FFP_PATH=$FFP_PATH_USB
  mount -o remount,noatime,nodiratime $FFP_USB_DRIVE
fi

# where to search for the install tarball
FFP_TARBALL=/mnt/HD/HD_a2/fun_plug.tgz

# rc file path
FFP_RC=/ffp/etc/rc

echo "**** fun_plug script for DNS-320/325  ****"
echo "Demarrage sur $FFP_PATH"
date

# create /ffp link
echo "ln -snf $FFP_PATH /ffp"
ln -snf $FFP_PATH /ffp

# install tarball
if [ -r $FFP_TARBALL ]; then
    echo "* Installing $FFP_TARBALL ..."
    mkdir -p $FFP_PATH && tar xzf $FFP_TARBALL -C $FFP_PATH && /ffp/bin/tar xzf $FFP_TARBALL -C $FFP_PATH
    if [ $? -eq 0 ]; then
        echo "* OK"
    fi
    rm $FFP_TARBALL
fi

# suid busybox
if [ -x /ffp/bin/busybox ]; then
    chown root.root /ffp/bin/busybox
    chmod 0755 /ffp/bin/busybox
    chmod u+s /ffp/bin/busybox
fi

# run fun_plug.init, if present
if [ -x /ffp/etc/fun_plug.init ]; then
    echo "* Running /ffp/etc/fun_plug.init ..."
    /ffp/etc/fun_plug.init
fi

# run fun_plug.local, if present
if [ -x /ffp/etc/fun_plug.local ]; then
    echo "* Running /ffp/etc/fun_plug.local ..."
    /ffp/etc/fun_plug.local
fi

# run commands
if [ -x $FFP_RC ]; then
    echo "* Running $FFP_RC ..."
    $FFP_RC
    echo "*  OK"
else
    echo "$FFP_RC: Not found or not executable"
fi

Empêcher le chmod 777

Comme je disais, le NAS effectue un bon gros chmod 777 sur tout les volumes, cela inclut la clé USB, il faut modifier un peu le système pour l'empêcher d'effectuer ceci au moins sur la clé USB, on commence par créer le fichier qui remplace chmod : 
cd /usr/local/config/
vi chmod_usb.sh

#!/bin/sh

# log everything to a file
exec >>/usr/local/config/chmod.log 2>&1

args="$@"
NOW=$(date +"%Y-%m-%d %T")
HD=USB1_c1

#these are the chmod args we want to suppress
suppress_args="777 -R /mnt/USB/$HD"

if [ "$args" != "$suppress_args" ]; then
    echo "[$NOW] Executing chmod $args"
    /bin/busybox chmod $@
else
   echo "[$NOW] Suppressing chmod $args"
fi
Suivi d'un chmod 777 chmod_usb.sh

Puis on effectuera le "remplacement" à chaque démarrage grâce au rc.init.sh (on conserve une copie du init.rc) :

cd /usr/local/config/
cp -pf rc.init.sh rc.init.sh.orig
echo "# USB chmod Patch" >>rc.init.sh
echo "[ -x /usr/local/config/chmod_usb.sh ] && ln -nfs /usr/local/config/chmod_usb.sh /bin/chmod">>rc.init.sh

On peut effectuer le ln -nfs /usr/local/config/chmod_usb.sh /bin/chmod et s'assurer que la commande chmod fonctionne toujours.

Supprimer fun_plug du disque dur

Dans mon cas, je ne veux pas que fun_plug puisse fonctionner sur le disque dur, seulement la clé USB, la solution est donc simple et à effectuer avant le redémarrage qui lancera fun_plug depuis la clé USB : 
rm -rf /mnt/HD/HD_a2/ffp/

On peut redémarrer le NAS, on devrait retrouver l'accès telnet au bout de 2-3 minutes mais cette fois avec un fun_plug contenu dans la clé USB !

Personnaliser SSH

Un des avantages de fun_plug est d'avoit un accès SSH au NAS, il y a cependant quelques modifications à effectuer (maintenant et pas avant car on modifie des fichiers de la clé) ; pour ma part j'utilise une clé privé pour me connecter en SSH, je laisse donc le mot de passe root intouché (ie. vide), mais ce n'est pas gênant.

mkdir -p /ffp/home/root/.ssh
chmod og-w -R /ffp/home/root/.ssh
vi authorized_keys
cd /usr/local/config
sed -ie 's#:/home/root:#:/ffp/home/root:#g' passwd
sed -ie 's#root:/bin/sh#root:/ffp/bin/sh#g' passwd
cd /etc
cd /usr/local/config
sed -ie 's#:/home/root:#:/ffp/home/root:#g' passwd
sed -ie 's#root:/bin/sh#root:/ffp/bin/sh#g' passwd
pwconv

On défini la/les clés ssh autorisés pour le compte root, puis on modifie le HOME (c'est ici que sshd cherchera les clés) et le shell (pour un beau bash) de root dans le dossier permanent (/usr/local/config qui est dans la flash du NAS) et dans le dossier chargé actuellement (pour éviter un reboot), on assure la prise en compte avec un pwconv.

Ah, il faut aussi changer un petit test dans /ffp/start/sshd.sh car il y a une référence à /etc/ssh et non /ffp/etc/ssh.

Enfin j'assure la sécurité en modifiant /ffp/etc/ssh/sshd_config

PermitRootLogin yes
PermitEmptyPasswords no
# Perso
AllowUsers root Alex

Root peut se connecter, pas de mot de passe vide possible (ça tombe bien, celui de root est vide, on ne pourra donc utiliser que la clé privé). Enfin seul root et Alex peuvent faire du SSH (si un utilisateur à un mot de passe faible, il pourrait offrir un accès SSH, on limite donc).

Enfin on peut lancer SSH : 

chmod +x /ffp/start/sshd.sh
/ffp/start/sshd.sh start

On peut de nouveau redémarrer le NAS, on attend 2-3 minutes puis on s'assure de l'accès SSH. Si c'est ok, on peut couper telnet : 

/ffp/start/telnetd.sh stop
chmod -x /ffp/start/telnetd.sh

Et voila !
Je n'ai pour l'instant pas été beaucoup plus moins, mais j'ai déjà un accès ssh root, tout est donc possible à partir de maintenant :)
Oh, et le NAS est parfaitement compatible IPv6 (l'interface web aussi !).

Quelques liens



jeudi 9 mai 2013

Mises à jour Windows Defender automatiques sous Windows 8

Je n'utilise pas le paramètre recommandé "Installer les mises à jour automatiquement" pour Windows Update, principalement parce que celui-ci génère un message invitant à redémarrer le PC lorsque des mises à jour le demandent.
C'est donc "Télécharger les mises à jour mais me laisser choisir s'il convient de les installer" que j'utilise. Un des effets de ce paramètre est que les mises à jour Windows Defender, proposant chaque jour un nouveau fichier de définitions, ne sont pas non plus installées et je suis donc invité chaque jour à les installer ... Enfin j'étais.


Le problème était le même sous Windows 7 et j'avais trouvé le "truc", et visiblement sous Windows 8 certaines personnes cherchent aussi comment faire :

Ma solution ne permet pas d'avoir les mises à jour "manuelles" mais seulement d'avoir les mises à jour majeures en manuel (celles qui demandent un redémarrage), les mineures comme les définitions de Defender seront automatiques.

Cela consiste donc à : 
  • mettre le paramètre sur "Télécharger les mises à jour mais me laisser choisir s'il convient de les installer" pour toutes les autres
  • et pour les mineures, ajouter une clé dans le registre dans :
    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
    créez une valeur DWORD "AutoInstallMinorUpdates" avec la valeur 1
    (Doc WSUS : http://technet.microsoft.com/en-us/library/dd939844(v=ws.10).aspx)
Cette clé autorise donc l'installation automatique des mise à jour ne nécessitant pas de redémarrage.
On retrouve aussi ce paramètre dans gpedit.msc (Windows Components/Windows Update).

Mises à jour automatiques : oui, mais sans être dérangé (cette option devrait être disponible tiens).

Migrer ses jeux Steam lors d'une réinstallation

Besoin de réinstaller ou changer de PC, mais pas envie de re-télécharger 150Go de jeux Steam ?
C'est possible, et sans utiliser la fonction d'exportation des jeux (qui plante en plus) :).


Les étapes :
  • Faire une copie du dossier SteamApps qui se trouve dans le dossier de Steam (C:\Program Files (x86)\Steam par exemple) vers la nouvelle destination (lecteur, mais pas le dossier final)
  • Supprimer les fichiers appmanifest_<id-jeu>.acf qui s'y trouvent : il est possible de les conserver, mais alors Steam n’exécutera pas les actions effectuées au 1er lancement et qui peuvent être nécessaires (installation d'OpenAL, création de clés dans le registre, définition de l'emplacement des executables, ...)
  • Réinstaller Steam (SteamInstall.msi demande la langue à utiliser) à l'emplacement voulu (qui peut-être dans Program Files, mais aussi sur une autre partition)
  • Le lancer, attendre les mises à jour du client, le fermer complètement
  • Remettre le dossier SteamApps en place dans le nouveau dossier d'installation de Steam
    Note : depuis une mise à jour, il est possible pour certains jeux (les non-steam principalement) de les installer à un autre emplacement, il suffit alors d'indiquer dans les préférences cet emplacement pour ces jeux.
  • Relancer Steam, attendre plusieurs minutes pour les jeux qu'il détecte tout seul, pour les autres il suffit de lancer la demande d'installation, il va alors découvrir les fichiers déjà présents sur le disque et les valider ; normalement il ne lui reste quasiment rien à télécharger
  • Voilà, les jeux sont de nouveaux disponibles en quelques heures et non en quelques jours de téléchargement :)