tj - Wiki

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== ReadyNas Duo ======

===== Installation =====

Ce que la doc ne dit pas !

  -Toujours installer au moins 1 disk *avant* de l'allumer !
  -Le 1er boot est trés long ! (une dizaine de minute): on a accès à l'interface aprés cette phase.
  -On peut installer le "RAIDar" pour Linux, l'interface d'admin: ''http://IP_DU_NAS/admin'' ( Mon mien est [[ https://nas.thierry-jaouen.local/admin|là ]] )
  - Le mot de passe par defaut ... login: __admin__  password: __netgear1__
  - Petite instabilité lorsqu'on change l'IP (il faut debrancher et rebrancher le cable ethernet)

Installer la dernière version de RAIDar:

  *<del>http://www.readynas.com/download/RAIDar/4.1.6/RAIDar_Linux_4_1_6.sh</del> Marche po! (pas plus que la version Windoz)
  *http://www.readynas.com/download/RAIDar/4.1.5/RAIDar_Linux_4_1_5.sh

===== Bug =====

**Oups**: j'ai un problème similaire à ça: http://www.readynas.com/forum/viewtopic.php?f=66&t=35209&p=203690

Le 2ieme disk n'est pas reconnu.
La seule solution proposé, c'est de remettre les paramètres par defaut (reset total), en laissant les 2 disk dedans !

| :!: On perd toute la config __ET__ les données : ca commence fort pour un NAS :-X |

Ensuite, ca semble fonctionner comme attendu.

===== Mémoire =====
Actuellement, il n'y a que 256 MB.

On peut l'augmenter, mais le gain en performance n'est pas enorme si j'en crois ce que j'ai lu. 

| :!: l'interface web ne repond plus (trés lentement) si on copie un fichier a 100Mb/s (sur un lien giga) |

===== Modules =====
http://www.readynas.com/?page_id=617

On peut activer ssh et root ... mais pour faire quoi ?

| :!: parce que ça bug un peu dans des cas classiques... RAID 0 qui tombe, les partages ne sont pas retirés de la liste... grrrr |

==== ssh ====

Installer ToggleSSH (demarre sshd):
  $ wget http://www.readynas.com/download/addons/4.00/ToggleSSH_1.0.bin
Puis dans la console web du NAS: 
  => System => Update => Installer une image ou un module => ... => Redemarrer !
Installer EnableRootSSH (permet a "root" (admin) de se connecter):
  $ wget http://www.readynas.com/download/addons/4.00/EnableRootSSH_1.0.bin
Puis procéder comme ci-avant...


==== iscsi ====

| :!: Ce module pète des trucs, je l'ai vu ! Et c'est aussi dit là: http://www.readynas.com/forum/viewtopic.php?f=64&t=37527&p=209320 |

  *http://www.readynas.com/forum/viewtopic.php?f=47&t=34170
  *http://readynasfreeware.org/projects/nas-iscsi-target/wiki/New_Version

=== module ===
Il s'installe simplement.

Ensuite, il faut utiliser ssh !

=== partage ===
Pour le fun, j'ai créé un partage non public et pouf: je le trouve pas!

| :!: c'est bêêêête. mais comment font les non-geeks? |

En fait, il est caché dans la conf samba, là:
  /etc/frontview/samba/Shares.conf

Le repertoire n'existe pas... grrr, donc je vais le faire:
  # mkdir /c/iscsi
  # chown admin: /c/iscsi

Je créé un volume/target , nommé "test_0" de 4GB :
  # dd if=/dev/zero of=/c/iscsi/test_0 bs=1M count=4096

=== ietd.conf ===

Creer/modifions le fichier "/etc/ietd.conf" afin d'avoir:
  Target iqn.2010-01.local.thierry-jaouen.xencave:readyduo.iscsi.target0
        Lun 0 Path=/c/iscsi/test_0,Type=fileio

Restart:
  /etc/init.d/rfw-iscsi-target restart 

Verifions:
  # cat /proc/net/iet/volume
  tid:1 name:iqn.2010-01.local.thierry-jaouen.xencave:readyduo.iscsi.target0
          lun:0 state:0 iotype:fileio iomode:wt path:/c/iscsi/test_0

=== xen ===
Lien:
  *http://perso.ens-lyon.fr/sebastien.mei/wiki/doku.php?id=documentations:xen-iscsi
  *http://www.performancemagic.com/iscsi-xen-howto/iSCSI.html

Sur le DomU:
  # aptitude install open-iscsi

Interrogeons le serveur iscsi ( dont le petit nom est "nas" ):
  # iscsiadm --mode discovery --type sendtargets --portal nas
  192.168.6.10:3260,1 iqn.2010-01.local.thierry-jaouen.xencave:readyduo.iscsi.target0
Il m'a repondu !

FIXME finir!

===== Developpements =====
http://www.readynas.com/?page_id=62

J'ai essayé l'exemple fournit, et ca ne fonctionne pas: il semble s'installer normalement, mais à la fin, il n'y a rien. :-(

===== UPS =====

==== par defaut ====
Un __serveur__ NUT existe. Il ne fonctionne pas en "client" (sauf modification via ssh, voir plus loin).

Il faut brancher l'onduleur via USB au ReadyNas...

Je n'ai pas essayé.

==== slave ====

Lien:
  * (pour creer un slave nut) http://ovanhoof.developpez.com/upsusb/
  * La conf nut sur un ReadyNAS... pas trés claire: http://www.readynas.com/forum/viewtopic.php?f=11&t=16744

| :!: le NAS met un peu plus de 30 secondes pour s'eteindre (dans de bonnes conditions)... ne pas couper le jus trop tôt ! |

=== sur le nas ===

Voila ce que j'ai fait, et je ne sais pas si ca fera correctement son boulot en cas de coupure...

Via ssh...

Creer un fichier **''/etc/default/nut''** avec dedans:
  # start upsd
  START_UPSD=no
  
  # start upsmon
  START_UPSMON=yes

Dans **''/etc/nut/upsmon.conf''** , avoir ça:
  # define the ups to monitor and the permissions
  MONITOR <UPS_NAME>@<SERVER_IP> 1 <USER> <PASSWORD> slave
  
  # define the shutdown comand
  SHUTDOWNCMD "/sbin/shutdown -h now"

Et puis, retour sous shell:
  # /etc/init.d/nut start

=== start a chaque boot ===

Nouveau challenge: faire demarrer "nut" a chaque redemarrage du NAS.

== mauvaise solution 1 ==
**''update-rc.d''**  ne vous aidera pas.

Le "nas" semble ignorer les scripts de demarre dans ''/etc/rc*/'' 

== mauvaise solution 2 ==
J'ai essayé de faire un petit module, mais sans succès. 

Même l'exemple donné par "netgear" ne s'installe pas. Pire: les fichiers se sont "vaporés" à l'installation et j'ai l'impression que ça a pété des petites choses. (comme par exemple, mon "nas" ne redemarre plus via la console www)

== solution 1 ==

Sur un autre poste, j'ai un petit scripte qui se connecte en ssh sur le nas, pour demarrer nut. C'est moyen. Le voila:
  #!/bin/sh
  
  # Demarrer "nut slave" sur le NAS
  # Sauf si la connexion existe déjà
  
  NAS_IP="192.168.6.10"
  NAME=`basename $0`
  
  # -------------------------
  # Liste les connexions
  # a la recherche d'une connexion deja etablie
  # -------------------------
  if [ -n "$( netstat -anp | egrep "$NAS_IP.*ESTABLISHED.*upsd" )" ]; then
    echo "upsd Ok"
  else
    # ---------------------------------------
    # Est-ce qu'on peut pinguer le nas
    # (sinon, inutile d'aller plus loin
    # ----------------------------------------
    if ping -w 10 -i 2 -n -c 1 "$NAS_IP" 1>/dev/null ; then
      echo "$NAME: ping Ok!" >&2
      # ----------------------------------------
      # Est-ce que le serveur ssh repond ?
      # (sinon, inutile d'aller plus loin
      # ----------------------------------------
      if [ -n "$( echo "" | nc -n -q 1 -w 5 $NAS_IP 22 | grep "SSH-2.0-OpenSSH_4.3p2 Debian-5~bpo.1.netgear1" )" ]; then
        echo "$NAME: ssh Ok!!" >&2
        # ----------------------------------------
        # Ok. alors faire executer la commande.
        # On doit d'abord être autorisé à ce connecter sans mot de passe!
        # ----------------------------------------
        if [ "$( ssh -q root@$NAS_IP "/etc/init.d/nut restart" )" = "Restarting Network UPS Tools: upsmon."  ]; then
          echo "$NAME: nut Ok!!!" >&2
        else
          echo "$NAME: nut start fail" >&2
        fi
      else
        echo "$NAME: nc fail" >&2
      fi
    else
      echo "$NAME: ping fail" >&2
    fi
  fi
  
  exit 0

Il suffit de le mettre dans un cron.

== solution 2 ==

Une solution trouvée par hasard.

Créér un petit script dans **''/var/spool/frontview/boot''** , comme cela:

  # cd /var/spool/frontview/boot
  # touch 10_nutslave
  # chmod 0700 10_nutslave
  # chown admin:  10_nutslave
Puis faire en sorte d'avoir dans **''10_nutslave''** :
  #!/bin/bash
  
  /etc/init.d/nut start
  
  exit 0
Adapter selon votre convenance...

Je suppose qu'il y a un priorité dans l'execution des scripts, d'ou le "10_" en debut de nom.

On peut faire un script d'arrêt dans **''/var/spool/frontview/shutdown''** .

Voila.

=== le serveur "master" ===

Dans la conf du "master", j'ai ajouté ceci pour laisser le temps a nut (du NAS) de s'arreter:
  # TJ ---------
  #HOSTSYNC 15
  HOSTSYNC 120
  # ------------
2 minutes, ca devrait être suffisant...

Créer un compte dans **''/etc/nut/upsd.users''**, par exemple:
  [<USER>]
  password        = <PASSWORD>
  allowfrom       = localhost <ACL_IP_DU_NAS_ou_NETWORK>
  upsmon slave

J'ai l'impression que le "readynas" envoi un ordre d'extinction de l'ondulateur, si on lui donne les droits:
  actions         = SET
  instcmds        = ALL
A vérifier....

===== RAID 0 =====
Par defaut, c'est en RAID 1, et c'est bien.

Il semble qu'on puisse faire du RAID 0 ici:

http://www.netgear-forum.com/forum/index.php?showtopic=58586

Si j'ai bien pigé:
  * X-RAID => RAID 1 qu'on peut facilement agrandir, en acquerant un (puis deux) disk plus grand
  * Flex-RAID => RAID 0 et/ou RAID 1, mais qu'on pourra pas agrandir aussi simplement.

J'ai eu un peu de mal (redemarrage nombreux) pour obtenir le menu me proposant de choisir "Flex-RAID".

Ceci fait. Il propose simplement de creer un volume pour le disk entier  !
Au redemarrage suivant, on peut effacer ce volume, et creer un volume RAID 1 et un autre en RAID 0 (pas plus de 2 volumes)

===== RAIDs Dégradés =====

==== remplacement du disk ====

Lien: http://www.readynas.com/forum/faq.php#How_do_I_replace_a_failed_disk%3F

En réalité, le ReadyNAS Duo n'est pas "hot plug".
On peut virer un disk a chaud, en remettre un nouveau, mais il faut redemarrer pour qu'il soit reconnu !

| :!: Redemarrer en appuyant 5 secondes sur le gros bouton... puis le NAS s'eteind ! |

Et oui, lors du test, je n'ai pas pu redemarrer a partir de la console web. Mes ordres semblaient sans effet.\\
Donc, il a fallu éteindre (avec le bouton), et attendre 5 bonnes minutes avant l'extinction.

**Enfin** , ce n'est qu'au demarrage, que la resynchronisation s'effectue.

Un bilan:
  *Le volume sur le RAID 1 est intact, ainsi que les partages (normal).
  *Le volume sur le RAID 0 a disparu (normal).
  *Les partages configurés sur ce volume ont aussi disparu (normal aussi).
  *Le "recouvrement" (synchronisation) a durée un peu moins de 4h ... pour 1To de disk.
  *Lorsque vous recréez un volume (mon RAID 0 disparu par exemple): il faudra encore __redemarrer__


Donc:
  -Il faut redemarrer pour que le nouveau disque soit reconnu
  -Il faut redemarrer aprés avoir créé un nouveau volume
Ca fait un peu beaucoup pour un "NAS" soit disant "hot(de)plug"...

==== partages du RAID 0 ====
Sauf que les partages du RAID 0 ne sont pas re-installable aussi simplement... car ils existent, sans exister...

J'ai ce problème: http://www.readynas.com/forum/viewtopic.php?f=66&t=36336&p=202429

Il faut installer SSH !

Et puis dans mon cas:
  $ ssh root@nas
  ... on est sur le nas en route et on voit:
  # ls / -lart | grep public
  lrwxrwxrwx    1 root     root            9 jan  2 18:24 public -> /d/public
Ce lien ne pointe sur rien, ce doit être le probleme...

Ne pas faire: <del>rm /public</del> à moins de vouloir modifier tous les fichiers de conf sur le NAS (samba,nfs,etc...)

Mais faire:
  # mkdir /d/public
  # chown public:nogroup /d/public
  # chmod a+wr /d/public
  # ln -s /d/public /.

Proceder de même pour chaque partage disparu. (Exemple: ''/d/media'' (voir section suivante))

Et puis **redemarrer** le NAS !

On a recréé le repertoire manquant: tous les services associés (samba, nfs, etc...) sont récupérés.

Ceci a été testé 2 fois:
  -Suite a une degradation volontaire
  -Suite a une véritable panne d'un disk

===== DLNA =====

J'ai voulu changer de partage "media" du DLNA. 

Au lieu du RAID 1 ( en **''/c/media''** ) je le voudrais ce partage sur mon RAID 0 ( en **''/d/media''** ).

| :!: Il faut au moins créér convenablement le nouveau partage sur "D:" dans la console www |

Rapidement, ca marche pas bien via  la console www **''frontview''**.

Via ssh, editer le fichier **''/etc/minidlna.conf''** et changer la ligne concernée en:
  media_dir=/d/media/
(Au lieu de ''/c/media/'' )

  *Redemarrer (arrêt/demarre) le service **''ReadyDLNA''** dans la console www.
  *Cliquer sur "Refaire analyse"

Et voila.

===== Admin =====
Le compte "admin" existe , bien sur, et il semble être l'equivalent du compte "root": \\
On peut monter des partages "cifs" avec ce compte "admin".


| :!: Il existe le compte "root" et "admin" . Le premier est plutôt pour ssh, et le second pour **''frontview''** |

===== reset firmware =====

A cause d'un module capricieux (iscsi) et/ou d'une tentative de création de modules, j'ai "frontview" (l'interface www) qui refuse de:
  -redemarrer/eteindre le nas (via la console)
  -desinstaller le module iscsi
  -faire une mise a jour du firmware
  -et autres problèmes, à priori mineures, que j'ai oublié.

Donc, il a fallut que je fasse un "reset du firmware":
  -Eteindre
  -maintenir le (petit) bouton reset enfoncé
  -allumer et au premier flash des leds des disks: relachez le bouton reset !
  -attendre que le nas demarre

Et , oh! surprise:
  *Le mot de passe "admin" redevient celui par defaut
  *mon 'nut slave' ne demarre plus . (ca se repare trés vite)
  *mes partages et mes users sont intacts: ainsi que le reste de la conf.

Donc, ca à "réparé" :)
J'ai pu , aussi, virer le module "iscsi". Youhou! 

===== Recuperation RAID 1 =====

Il n'aura fallu que quelques semaines pour que l'un des disks du RAID de mon "ReadyNAS Duo" defaille...

Donc, j'ai récupéré le disk "Mort" (dixit la console du ReadyNAS) afin d'analyse:

Les partitions:
  # fdisk -u -l /dev/sdd
  
  Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
  255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
  Units = sectors of 1 * 512 = 512 bytes
  Disk identifier: 0x00000000
  
     Device Boot      Start         End      Blocks   Id  System
  /dev/sdd1               1     4096000     2048000   fd  Linux raid autodetect
  Partition 1 does not end on cylinder boundary.
  /dev/sdd2         4096001     5144576      524288   fd  Linux raid autodetect
  Partition 2 does not end on cylinder boundary.
  /dev/sdd3         5144577  1605031936   799943680   fd  Linux raid autodetect
  /dev/sdd4      1605031937  1953507328   174237696   fd  Linux raid autodetect

==== montage ====

=== mdadm ===

Installons **''mdadm''** :

  # aptitude install mdadm

Examinons chaque partition... et je decouvre:
  # mdadm --examine /dev/sdd3
  /dev/sdd3:
            Magic : a92b4efc
          Version : 00.90.03
             UUID : 39d8c833:4008b140:ad8bcd80:94540ca6
    Creation Time : Sat Jan  2 17:00:24 2010
       Raid Level : raid1
    Used Dev Size : 799943616 (762.89 GiB 819.14 GB)
       Array Size : 799943616 (762.89 GiB 819.14 GB)
     Raid Devices : 2
    Total Devices : 2
  Preferred Minor : 2
  
      Update Time : Thu Apr 15 13:19:12 2010
            State : clean
   Active Devices : 2
  Working Devices : 2
   Failed Devices : 0
    Spare Devices : 0
         Checksum : 2bad5e37 - expected cdbc4e95
           Events : 1712635389149184
  
  
        Number   Major   Minor   RaidDevice State
  this     0      22        3        0      active sync
  
     0     0      22        3        0      active sync
     1     1      33        3        1      active sync

C'est donc "ma" partition RAID 1, en **''/dev/sdd3''** !

On la monte ainsi:
  # mdadm -C /dev/md0 --level=raid1 --raid-devices=2 /dev/sdd3 missing
  mdadm: /dev/sdd3 appears to be part of a raid array:
      level=raid1 devices=2 ctime=Sat Jan  2 17:00:24 2010
  Continue creating array? y
  mdadm: array /dev/md0 started.

Ok?
  # cat /proc/mdstat
  Personalities : [raid1]
  md0 : active raid1 sdd3[0]
        799943616 blocks [2/1] [U_]
  
  unused devices: <none>

Essayons de monter **''/dev/md0''** :
  # mount /dev/md0 /mnt/test/
  mount: unknown filesystem type 'lvm2pv'

Tiens, on dirait une partition **''lvm''** ...

=== lvm2 ===

Donc, installer **''lvm2''** :
  # aptitude install lvm2   

Lors de l'install, il semblerait que **''lvm''** a trouvé quelque chose:
  Setting up LVM Volume Groups  Reading all physical volumes.  This may take a while...
  Found volume group "c" using metadata type lvm2
  1 logical volume(s) in volume group "c" now active

Effectivement:
  # pvs
  PV         VG   Fmt  Attr PSize   PFree
  /dev/md0   c    lvm2 a-   762,88G    0

Un **''/dev/c''** est apparu !

  # mount /dev/c/c /mnt/test
  mount: wrong fs type, bad option, bad superblock on /dev/mapper/c-c,
  ...

  # dmesg | tail
  [56267.599889] EXT3-fs: bad blocksize 16384.

Probleme de "blocksize" ...

Lien pour aider: http://ubuntuforums.org/archive/index.php/t-1283950.html

Et là: http://www.readynas.com/forum/viewtopic.php?f=65&t=39973

==== ext2fuse ====

=== compilation ===

La solution:
  ..." the 16k block issue is addressed by using ext2fuse, a userland filesystem driver -- smart " 
  ???

Autre lien: http://www.jamesandclare.net/2009/12/06/mounting-readynas-duo-drives-in-ubuntu/

Donc: télécharger les sources de "ext2fuse".

  # aptitude  install fuse-utils libfuse-dev

  $ tar xvzf ext2fuse-src-0.8.1.tar.gz
  $ ./configure
  $ ./make
  # make install

Si necessaire:
  # modprobe fuse

  # ext2fuse /dev/c/c /mnt/test
  /dev/c/c is to be mounted at /mnt/test
  fuse-ext2: Can't read an inode bitmap while reading inode bitmap

Mais ca marche pas trop bien, donc:
  # fusermount -u /mnt/test

Ne pas oublier:
  # make uninstall
Parce qu'on va faire autrement.

=== LA SOLUTION ===

En fait, il y a un bug dans les dernières versions de "ext2fuse", mais ca fonctionne avec la version "0.7".

   # aptitude install e2fslibs-dev

Et puis
  $ tar xvzf ext2fuse-0.7.src.tgz
  $ cd ext2fuse-0.7
  $ su
  # make
  # ./ext2fuse /dev/c/c /mnt/test
  /dev/c/c is to be mounted at /mnt/test
  ext2fuse: op_init(device_name /dev/c/c)
  block size is 16384

Ca y est, je vois les fichiers !!!!!!

A la fin :
  # fusermount -u /mnt/test

Et le reste aussi ...