Pelle la tarte.

Articles avec le tag ‘NAS’

Le système d’exploitation embarqué dans les NAS Synology, le DSM, est un système plutôt sympathique à utiliser, et qui permet de s’éviter des heures de configuration. Activer un serveur ftp en 2 clics est assez appréciable.

Quand on veut aller plus loin, avoir une configuration apache particulière, utiliser screen + irssi, et toutes ces choses qui ne sont pas prévus par le fabriquant, cela devient plus compliqué. Même si obtenir un accès SSH root est très facile, on tombe sur des consoles qui ne sont pas en UTF-8, avec un busybox énervant, un système de paquet obsolète avec un choix limité. Et surtout, on risque de casser le système en bidouillant la configuration, qui est assez tentaculaire, et régénérée en partie à chaque changement dans l’interface.

Il y a une solution que je trouve assez élégante à ce problème, c’est d’installer une Debian en parallèle du système de base, grâce à debootstrap et un chroot. Dit comme ça, ça a l’air bien compliqué, mais en réalité, c’est plus simple et moins risqué que de triturer le DSM, avec en bonus, toute la puissance de Debian. Le principe est que nous allons ’embarquer’ une Debian sur le NAS, qui va tourner dans un compartiment restreint, le chroot. Nous aurons donc les deux systèmes qui tournent en parallèle, les deux faisant des appels au même noyaux, celui du DSM.

Mise en place de Debian

Il va nous falloir une Debian qui tourne quelque part pour générer un système de base. Si vous n’en avez pas, vous pouvez l’installer dans une machine virtuelle le temps de faire la manip (Debian net-install et Virtualbox font très bien l’affaire). Un fois ceci fait, on va utiliser debootstrap de nous générer une archive minimale pour notre architecture cible, l’ARM :

Transférez l’archive obtenue sur votre NAS, placez la dans /volume1/, connectez vous au NAS grâce à telnet et désarchivez la :

Mise en place du chroot

Debian aura besoin de faire des appels au noyau linux du DSM. Nous allons donc rendre accessible dans le chroot les répertoires spéciaux comme /proc, /dev …

On va utiliser un petit script shell qui va nous permettre de faire les quelques opérations nécessaires et d’entrer dans le chroot. Éditez un fichier chroot.sh, et copiez y les commandes suivantes:

Executez le en root, et vous serez dans le chroot. Il reste maintenant à finaliser l’installation de Debian :

Générez un fichier sources.list correct grâce à http://debgen.simplylinux.ch, et placez le dans /etc/apt/sources.list.

Une petite mise à jour de Debian:

Ajout d’un compte utilisateur:

J’ai du corriger quelques droits d’accès qui se sont perdus dans la bataille. Il y en a probablement d’autres, à vous de corriger si nécessaire.

Installation du minimum vital:

Pour que la Debian soit fonctionnelle, il faut maintenant faire tourner un certain nombre de services. Sur une Debian normale, ces services sont lancés par init, mais ce n’est pas notre cas. Il faudra donc les lancer manuellement. Éditez un fichier services.sh que vous placerez dans votre $HOME, et placez y le contenu suivant :

Et voilà, votre Debian est fonctionnelle ! Vous avez virtuellement deux systèmes qui tournent en parallèle. Si votre NAS s’éteint, vous devrez lancer le script chroot.sh, qui vous emmène dans la Debian, puis le script services.sh. Si vous vous connectez en telnet, vous tomberez sur le DSM, et en ssh, sur Debian.

Installation d’apache et de mysql

Le DSM fait déjà tourner deux apache, un pour l’interface web, l’autre pour les web station et photo station. L’un des deux écoute sur le port 80, et redirige vers l’interface web (port 5000/5001) si nécessaire. Si vous voulez faire tourner un apache sur le port par défaut, il va falloir faire deux choses:

• Allez dans l’interface d’administration et activez la web station
• Arrêtez le deuxième apache par telnet:

Après installation d’apache et de mysql, pensez à dé-commenter les lignes correspondantes dans les deux scripts. On a perdu au passage les web et photo stations, mais si vous voulez un apache personnalisé, c’est probablement que vous n’en avez pas besoin. Si vous changez d’avis, vous pouvez toujours réactiver le service apache du DSM, la configuration est restée intacte.

Conclusion

A l’usage, c’est une solution très efficace. Les services avancés du NAS d’un coté, la simplicité et la puissance de Debian de l’autre. La différence se situe au niveau de l’occupation en RAM, même si cela reste bien raisonnable. Après 20 jours d’uptime, l’occupation mémoire est de 170Mo sur 512Mo, sachant que Linux à tendance à ne pas trop nettoyer la mémoire s’il n’en a pas besoin.

Source:

http://www.seken.co.uk

Edit: meLIanTQ a proposé une solution pour un lancement automatique du chroot au démarrage du NAS: Le commentaire

Ajaxterm est un terminal dans une page web, accessible donc simplement par un navigateur web. Les avantages? Il est accessible de partout, quelque soit le proxy, pare-feu, antivirus, ou n’importe quelle protection mise en place, du moment que le http/https passe. Les inconvénients : c’est un peu lent, et pas sécurisé si vous ne passez pas par de l’https.

J’ai un peu galéré, mais j’ai fini par réussir à installer ajaxterm sur mon NAS Synology et à configurer son accès en https. Comme ça peut servir à d’autres (private : je vise personne :D ), voilà ma méthode.

1) Installation de python 2.5

Ajaxterm nécessite python pour fonctionner, donc il faut l’installer :

2) Installation d’ajaxterm

Téléchargez ajaxterm :

Extraire les fichiers :

Éditez le fichier ajaxterm.py et modifiez la ligne suivante en remplaçant localhost par l’IP de votre NAS :

Je ne sais pas pourquoi, je n’ai pas réussi sans cette manip. 127.0.0.1 ou localhost ne fonctionnent pas, il faut vraiment mettre l’IP de votre NAS sur votre LAN (192.168.0.X en général).

Copiez le dossier Ajaxterm-0.10 où bon vous semble, ajaxterm ne « s’installe » pas plus que ça. Tout ce qui est nécessaire est dans ce dossier, que vous pouvez mettre n’importe où.

Pour lancer ajaxterm, c’est tout simplement, dans le dossier Ajaxterm-0.10 :

A ce stade, vous pouvez normalement accéder à ajaxterm à l’adresse : http://ip.de.votre.nas:8022/

Mise en place de l’accès https par apache

Etant donné qu’il y a déjà un apache d’installé sur les NAS Synology, configuré de manière (très) particulière, et qu’il sert à accéder à l’interface d’administration du NAS, on va éviter de le casser :)
J’ai opté pour l’installation d’un second apache, avec ipkg :

Ce nouvel apache ne sera pas accessible sur le port 80 puisque celui-ci est déjà utilisé par l’apache d’origine. Par contre, il est à l’écoute sur le port 8000, et vous devriez avoir accès à la célèbre page « It works! » à l’adresse http://ip.de.votre.nas:8000

Pour info, l’arrêt/relance de ce nouvel apache se fait avec les commandes suivantes :

Editez la configuration https d’apache : /opt/etc/apache2/extra/httpd-ssl.conf
Il faut apporter les modifications suivantes :

--------------------------------------------------------------------
Listen 443
Listen 4430 (vous pouvez mettre un autre port)
--------------------------------------------------------------------
<VirtualHost _default_:4430>
NameVirtualHost *:4430
<VirtualHost *:4430>
--------------------------------------------------------------------
DocumentRoot "/opt/share/www"
ServerName www.example.com:443
ServerAdmin you@example.com
ErrorLog "/opt/var/apache2/log/error_log"
TransferLog "/opt/var/apache2/log/access_log"
ServerName localhost
--------------------------------------------------------------------

Et ajouter les lignes suivantes juste avant la balise :

--------------------------------------------------------------------
ProxyRequests Off
    Order deny,allow
    Allow from all

ProxyPass /ajaxterm/ http://ip.de.votre.nas:8022/
ProxyPassReverse /ajaxterm/ http://ip.de.votre.nas:8022/
--------------------------------------------------------------------

Une dernière chose : il est plus propre d’utiliser le certificat déjà présent sur le nas. C’est tout simple :

Relancez apache, et normalement c’est tout bon! Vous avez accès en https à votre ajaxterm à l’adresse suivante : https://ip.de.votre.nas:4430/ajaxterm/

Remarques

– Ajaxterm semble ne pas fonctionner sous Firefox 3.6 sous Linux. Je n’ai pas encore trouvé pourquoi. Ca fonctionne par contre correctement sous Chrome et Firefox 4.0 sous Linux, et sous toutes les versions de Firefox sous Windows (en fait ça fonctionne sans doute dans toutes les autres configurations…)
– Je ne suis pas sur de la fiabilité de la configuration apache donnée ici. Elle fonctionne mais je ne vous garantie pas qu’elle est sure à 100% vu que je n’ai pas encore vraiment compris l’organisation particulière de la configuration d’apache installée avec ipkg.

Eh oui, encore une bizarrerie du linux-like de Synology : pas de scp ni de sftp par défaut. Ces deux softs faisant quand même partie de la base des utilitaires indispensables, voilà comment les installer sans tout casser.

Tout d’abord, installez les paquets zlib et openssl :

Pour installer scp et sftp il faut faire un peu attention : il y a une version spécifique de ssh installée sur les NAS Synology, c’est pourquoi il ne faut pas installer directement le paquet openssh par ipkg.

Commencez par créer un répertoire de travail :

Téléchargez le paquet openssh (sans l’installer!) :

Extrayez les fichiers contenus dans le paquet openssh :

Copiez les exécutables scp et sftp dans /bin :

Renommez openssh-scp :

Créez le lien symbolique suivant (essayez sans, mais chez moi c’était nécessaire) :

Supprimez votre dossier de travail :

Et c’est tout!

Article rédigé d’après cet article, avec quelques mises à jour. Merci à son auteur.

Deuxième article sur mon NAS Synology DS411j, cette fois ci simplement pour passer outre une limitation mise en place par Synology : l’accès en ssh est réservé à l’utilisateur root (ou admin).

Cette limitation a sans doute du être mise en place dans un souci de simplicité pour le grand public, limitant ainsi l’accès au propriétaire du NAS, qui est supposé savoir ce qu’il fait s’il a activé l’accès ssh.

Cependant, cette limitation pose 2 problèmes :
– Tout d’abord, il est déconseillé d’activer l’accès ssh en root à une machine GNU/Linux, pour des raisons de sécurité. Cette limitation va complètement à l’encontre de ce principe élémentaire.
– En plus, dans l’optique de l’utilisation de rsync sur le protocole ssh, ce que je veux mettre en place pour mon futur système de sauvegarde (ça fera l’objet d’un autre article), il faut absolument que chaque utilisateur ait un accès ssh au NAS

La procédure n’est pas très compliquée, mais il faut faire attention à ce que l’on fait car on peut très vite tout casser (et ne plus pouvoir se connecter en ssh du tout par exemple…).

1) Créer un utilisateur ordinaire depuis l’interface web du NAS.

Appelons le julien dans la suite. Je l’ai configuré pour appartenir au groupe « users ».

2) Se connecter en root au NAS.

Il faut bien sûr activer le service ssh au préalable, par l’interface web du NAS. Je conseille d’également activer le telnet pour la durée des manipulations décrites ici, cela permettra un accès de secours au NAS si on casse le SSH…
Pour se connecter en ssh, c’est comme toujours, depuis un terminal Linux :

Le mot de passe est le même que celui de l’administrateur dans l’interface web.

3) Créer le profil de l’utilisateur.

Je conseille la création d’un dossier /volume1/users/ avec dans ce dossier un dossier par utilisateur « standard », qui permettra de mettre tout ce qui est administration des utilisateurs dans ce dossier et non pas dans /volume1/homes/ car ce dossier sera accessible directement par le navigateur de fichier de l’interface web (FileStation). Les fichiers « d’administration » de l’utilisateur (le .profile en l’occurrence) y seront visibles. Cependant, si vous préférez, vous pouvez vous passer de ce nouveau dossier et utiliser /volume1/homes/.
Ensuite, il faut créer (dans le dossier /volume1/users/julien donc) le fichier .profile de julien, sur la base de celui de root.
C’est parti :

Changer la ligne suivante :

Par celle-ci :

4) Adapter le fichier /etc/passwd.

Sauvegarder le fichier /etc/passwd original et adapter sa copie :

Modifier la ligne suivante (elle peut varier légèrement chez vous) :

Pour cette ligne là :

Le dossier « /volume1/users/julien » indique le dossier dans lequel se placer quand l’utilisateur se connecte. C’est aussi dans ce dossier que sera cherché le fichier .profile, pensez donc à adapter ce dossier si vous avez mis votre .profile ailleurs.

5.a) Configurer la lecture du .profile du nouvel utilisateur

Ici, il y a 2 cas de figures.

– Vous avez choisi de n’avoir qu’un seul dossier pour l’utilisateur (/volume1/homes/julien à priori) et le fait de voir le fichier .profile trainer dans l’interface de FileStation ne vous gène pas : passez à l’étape 6).

– Vous avez choisi de suivre ma configuration, avec un dossier « technique » (/volume1/users/julien), dans lequel vous avez mis le .profile, et un dossier « utilisateur » (/volume1/homes/julien) : il faut bidouiller un peu pour s’en sortir. Si vous voulez juste appliquer ce que je dis sans trop comprendre le problème, passez au 5.b).

Sinon je vous explique le problème : il faut que le fichier .profile ne soit pas dans le dossier de connexion de l’utilisateur (configuré dans le /etc/passwd). En effet, FileStation utilise le dossier configuré dans /etc/passwd comme dossier « racine » pour l’utilisateur et on fini par tourner en rond :

– soit on a /volume1/users/julien/ dans /etc/passwd et lors de la connexion en ssh tout se passe bien, le fichier .profile est pris en compte mais dans FileStation on se retrouve aussi dans ce dossier /volume1/users/julien/ alors qu’on voulait être dans /volume1/homes/julien/ (et en plus on voit le fichier .profile du coup ^^ )

– soit on a /volume1/homes/julien/ dans /etc/passwd et on est au bon endroit dans FileStation, mais à la connexion en ssh le .profile sera cherché dans /volume1/homes/julien/, ne sera pas trouvé, et le profile par défaut sera appliqué. On sera bien connecté dans /volume1/homes/julien/ mais la variable $HOME vaudra par exemple « /root », ce qui fait que lorsqu’on passe la commande suivante, on n’a pas vraiment le résultat espéré :

Inattendu hein? :p
L’astuce consiste en fait à modifier le fichier de profile par défaut : /etc/profile. J’explique cela dans le paragraphe suivant.

5.b) Modifier le fichier /etc/profile

Au final, nous voulons donc avoir le dossier /volume1/homes/julien/ comme dossier de connexion par défaut, aussi bien pour le ssh que pour FileStation, tout en prenant en compte le fichier de profile /volume1/users/julien/.profile.
Cela se fait en modifiant le fichier /etc/profile de la manière suivante (ajout des 3 dernières lignes) :

6) Vérifier la bonne configuration de l’utilisateur.

Exécuter les commandes suivantes :

Le résultat de toutes ces commandes est très important. La seule chose qui doit changer chez vous est « julien ». Vous remarquerez que comme le dossier de connexion configuré (/volume1/users/julien) est différent de la valeur attribuée à la variable $HOME à l’étape 3 (/volume1/homes/julien), la commande cd ne nous met pas dans notre répertoire de connexion, mais bien dans notre home. Vous pouvez bien sur mettre un autre dossier dans $HOME à l’étape 3 (comme le dossier /volume1/users/julien, je ne l’ai pas fait parce que je veux garder ce dossier strictement administratif).

7) Configurer sshd.

Commencer par sauvegarder la configuration originale :

Puis adapter la configuration à votre convenance. Les points essentiels sont les suivants :
– Changer la ligne « #Protocol 2,1 » pour « Protocol 2 » (désactivation de ssh v1) si ce n’est pas fait
– Changer la ligne « #PermitRootLogin yes » pour « PermitRootLogin no » pour interdire la connexion en ssh de root (conseillé d’un point de vue sécurité, je ne l’ai pas fait pour des raisons pratiques pour le moment)

Vous pouvez également adapter les 2 lignes suivantes en fonction de ce qui vous parait raisonnable d’un point de vue sécurité :
– « #LoginGraceTime 2m » (par défaut, 2 minutes) : Le serveur se déconnecte après ce délai si l’utilisateur ne s’est pas connecté. Si la valeur est 0, il n’y a aucune limite de temps.
– « #MaxAuthTries 6 » (par défaut, 6 essais) : Nombre maximum d’essais de mot de passe pour la connexion.
– Pour les autre options : « man ssh » dans google =)

8) Redémarrer le démon sshd.

Avant de redémarrer sshd, je vous conseille encore une fois d’activer (provisoirement si vous voulez) le telnet sur votre NAS.
Le démon sshd peut être redémarré de plusieurs manières. La plus simple est de désactiver puis de réactiver le service ssh dans l’interface web. Déconnectez vous avant de faire ça. Sinon, vous pouvez utiliser la commande suivante :

Ou alors, plus brutal, vous pouvez éteindre et rallumer votre NAS.

9) Tester que ça fonctionne!

Se connecter en tant que julien pour voir si ça fonctionne, depuis votre poste Linux :

Si vous avez bien tout suivi, ça devrait fonctionner. Sinon, vous pouvez toujours tenter de me poser une question, je ferai ce que je peux pour vous aider…

Attention

J’ai vu sur le net que le fait de modifier les caractéristique des utilisateurs pour lesquels on a activé le ssh par l’interface web remettait la configuration par défaut et que du coup le ssh ne fonctionnait plus. Si c’est le cas, il vous suffit de ré-appliquer la procédure ci-dessus, ça devrait fonctionner. Au pire, faites les manips en vous connectant via telnet en root. Cela dit, je n’ai pas encore essayé ceci. Synology a peut-être corrigé ce problème maintenant.

Sources utilisées pour cet article

http://bernhard.hensler.net/blog/synology-enable-ssh-user-login-other-than-root/
http://www.delafond.org/traducmanfr/man/man1/ssh.1.html
http://unixhelp.ed.ac.uk/CGI/man-cgi?ssh+1

J’ai fini par craquer, et je me suis acheté un nouveau jouet : un NAS Synology DS411j \o/
Voilà la bête (la photo est plus moche que toutes celles que vous trouverez sur le net mais c’est moi qu’a fait!) :

Bref. Tout ça pour dire que je suis vraiment pas déçu de l’engin. Silencieux (ou pourrait dormir à coté je pense), compact pour un 4 baies, et surtout niveau fonctionnalités, c’est un festival. Voici donc un premier article dédié au DS411j, sachant que bien sûr tout ce que je dis dois s’appliquer à n’importe quel NAS Synology à priori. Il y en aura surement d’autres, au fur et à mesure que je casserai bidouillerai des trucs. Dans cet article :
– accès root en SSH au NAS
– installation d’un gestionnaire de paquets : ipkg
– utilisation de base d’ipkg et exemple d’installation de quelques logiciels

Accès root en SSH :

Pour commencer, il faut activer le SSH dans le panneau de configuration du NAS. Ca se passe dans Panneau de configuration -> Terminal, cochez la case « Activer le service SSH ». Le SSH sera alors actif pour l’utilisateur « admin » (celui créé à l’initialisation du NAS) et pour l’utilisateur « root ». Le mot de passe de root est le même que celui que vous avez mis pour admin. Il est sans doute possible d’utiliser le SSH avec d’autres utilisateurs, mais j’ai pas tout compris à la gestion des utilisateurs encore, donc pour le moment ça sera root. De toutes façons, on en a besoin pour la suite.
C’est tout, le SSH est activé.

Installation d’un gestionnaire de paquets : ipkg

Le seul manque que j’ai remarqué pour le moment est l’absence d’un gestionnaire de paquet installé de base. Mais comme il est possible (et pas trop compliqué) d’en mettre un, pour les quelques geek qui s’en serviront, c’est pas très gênant.
Apparemment, le gestionnaire de paquets « officiel » de Synology est ipkg. Son utilisation ressemble beaucoup à l’apt-get de Debian. Il est peut-être possible d’en installer un autre, mais ça doit être un peu (beaucoup?) plus compliqué. Le processus d’installation d’ipkg est donné sur le wiki de Synology, mais je vous en fait une version française.
– Vérifiez quel type de CPU est installé sur votre NAS : ici
– Connectez vous en SSH (utilisateur root) à votre NAS
– Téléchargez le bootstrap (script d’installation d’ipkg) qui correspond à votre CPU : ici. Conseil, faites le avec wget. Par exemple, pour le DS411j :

– Exécutez le script que vous venez de télécharger. Exemple, pour les CPU de type ARM :

– Enjoy !

Utilisation de base d’ipkg et exemple d’installation de quelques logiciels

2 commandes de base, qui sont les mêmes que pour apt-get :
– Mise à jour de la table répertoriant les paquets disponibles :

– Mise à jour de tous les paquets ipkg installés sur votre NAS dans leur dernière version
Et pour installer un paquet, c’est encore comme apt-get :

Deux exemples :
– Parce que ça peut servir ^^ (ça aurait pu y être de base d’ailleurs…) :

– Parce que vi c’est bien, et vim c’est mieux :

Conclusion (provisoire!)

Le premier truc qui me vient à l’esprit : franchement, il est bien cool ce NAS. Si vous hésitez entre plusieurs marques, je recommande donc sans aucune hésitation Synology (après le modèle à vous de voir ce dont vous avez besoin, les fonctionnalités sont globalement les mêmes sur tous). Et la suite est plus que prometteuse ! To be continued !