Vous faites du E-commerce, et comme beaucoup de monde, les pannes, les notions de sécurité informatique et de maintenance ne sont pas votre tasse de thé . Demain d’ailleurs si votre site de commerce electronique tombe, imaginez les pertes financières que ça pourrai impliquer ?
La solution pourtant existe en demandant à un amis par exemple de vous aider comme vous l’avez surement fait pour vous lancer … Mais demain aura t’il le temps et l’expérience pour vous dépanner, et sous combien de temps ?
Si vous vous posez cette question, alors demandez donc à un professionnel, un Hacker en anglais, un Administrateur système Web en français de vous conseiller et d’être la tous les jours à surveiller, prévoir et corriger les soucis de votre système informatique en ligne, personnellement c’est mon métier et je met mes 10 ans d’expériences à votre disposition, tout en vous assurant de ma capacité à m’adapter aux projets les plus difficiles . Plus de renseignements sur Infogérancesous linux

Posté dans Pub.

il fut un temps ou avoir un serveur dedié et y mettre une boutique de commerce électronique étaient des choses impensables . Et pourtant de nos jours plus personne ne doute du modèle de la net-économie . En même temps alors que l’on a entendu parler de hackers pendant des années jusqu’a en faire des films , de nos jour, l’on a oublié leurs fonctions premières . En effet ils existent toujours mais aujourd’hui leur passion est devenu un métier et ça se nomme un administrateur système Web . C’est justement l’interlocuteur à connaitre pour être sur de la réussite de son projet sur le web, car celui ci, habile sous linux, connaitra les modalités pour rendre fiable votre Oscommerce ou votre Prestashop et éviter les soucis de sécurités informatiques . En même temps lui demander de faire l’infogérance de votre linux sera le meilleur moyen de vous assurer la tranquilité d’esprit, et d’être sur que personne ne penètre votre système pour le détourner de son usage .

Renseignez vous donc aupres d’un pro de l’infogerance linux

Posté dans Pub.

Debian Lenny – nut / Onduleur – Z3 Zenergy 700 VA (INFOSEC)
Publié le Février 23, 2011

Configuration de nut pour l’onduleur Z3 Zenergy 700 – USB de INFOSEC

System : Gnu/Linux Debian 5 – Lenny
kernel : 2.6.26-2-486
Nut : 2.2.2-6.5

Vous avez acquis un onduleur. Malheureusement, celui-ci est partiellement supporté par nut (voir la hardware compatibility list de nut). Bien que l’onduleur soit pourvu d’un port USB, celui-ci est mal détecté par le système Debian Linux Lenny. Le système linux détecte la présence d’un convertisseur USB / Série : Cypress USB to Serial. Son port série virtuel /dev/ttyUSB0 n’étant pas créé automatiquement. Ce port en mode raw est quand même exploitable comme nous allons le voir.

Voyons si les concentrateurs USB détectent la présence de l’onduleur :

# lsusb
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0665:5161 Cypress Semiconductor USB to Serial
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Détaillons les informations USB sur ce périphérique :

#lsusb -v
Bus 001 Device 002: ID 0665:5161 Cypress Semiconductor USB to Serial
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0×0665 Cypress Semiconductor
idProduct 0×5161 USB to Serial
bcdDevice 0.02
iManufacturer 1 INNO TECH
iProduct 2 USB to Serial
iSerial 3 20100813
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 3 20100813
bmAttributes 0×80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 4 Sample HID
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.00
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 27
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0×81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0×0008 1x 8 bytes
bInterval 32
Device Status: 0×0000
(Bus Powered)

Malheureusement, aucun port série (virtuel) n’est créé lors de la connection de l’onduleur. Un device standard /dev/hidraw0 sera quand même créé automatiquement pour que le système puisse communiquer en mode directe avec l’onduleur.
Installation de nut

L’installation de nut se fait sans aucun soucis :

#apt-get install nut

Après avoir testé en vain le driver megatec_usb qui aurait dû communiquer avec l’onduleur, j’ai du procéder à l’installation du paquet deb de nut de Debian 6 Squeeze ! Ce paquet (nut_2.4.6.deb minimum) contient le driver blazer_usb utile à nut pour communiquer avec le périphérique.

Disponible sur le site de networkupstools.org, téléchargez le paquet dans la section Download /Binary packages. Un lien vous ramène directement sur la page de téléchargement de nut : http://packages.debian.org/squeeze/nut

Direct link : nut_2.4.3-1.1squeeze1_i386.deb

Installation du paquet :

#dpkg -i nut_2.4.6.deb

Configuration de nut

Fichier : /etc/nut/nut.conf

MODE=standalone
UPSD_OPTIONS=” »
UPSMON_OPTIONS=” »

Fichier : /etc/nut/ups.conf

[Z3_700]
driver = blazer_usb
port = /dev/hidraw0
vendorid = 0665
productid = 5161
desc = “Server Linux Internet”

Ce fichier donne les paramètres associés à votre onduleur. Le nom de l’onduleur, par lequel le système l’identifiera, est indiqué entre les crochets.

Pour les onduleurs en usb, le port = auto pourrait aussi fonctionner. Dans mon cas j’ai dû spécifier le port /dev/hidraw0 créé par le système. Dans l’idéal, un port série virtuel serait disponible pour communiquer avec l’onduleur tel que /dev/ttyS0 ou /dev/ttyUSB0.

Fichier : /etc/nut/upsd.users

[z3]
password = pass_ups
upsmon master

Il s’agit d’un “compte” au sens du service nut.

Fichier : /etc/nut/upsmon.conf

RUN_AS_USER
MONITOR Z3_700@localhost 1 z3 pass_ups master
SHUTDOWNCMD “/sbin/shutdown -h +0″
MINSUPPLIES 1
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 30
DEADTIME 15
POWERDOWNFLAG /etc/killpower
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

Ce fichier de configuration du moniteur reprend des informations sur l’onduleur du fichier ups.conf

Fichier : /etc/nut/upssched.conf

CMDSCRIPT /upssched-cmd

Une fois tous ces fichiers configurés, vous pouvez tester la communication du driver avec l’onduleur via la commande :

#/lib/nut/blazer_usb -a Z3_700 -DDD -u root

Network UPS Tools – Megatec/Q1 protocol USB driver 0.03 (2.4.3)
0.000000 debug level is ’3′
0.040693 Checking device (0665/5161) (001/002)
0.077674 - VendorID: 0665
0.077760 - ProductID: 5161
0.077776 - Manufacturer: INNO TECH
0.077792 - Product: USB to Serial
0.077807 - Serial Number: *********
0.077822 - Bus: 001
0.077836 Trying to match device
0.078023 Device matches
0.078122 failed to claim USB device: could not claim interface 0: Device or resource busy
0.080628 detached kernel driver from USB device…
0.083726 Trying megatec protocol…
0.087616 send: Q1
1.089450 read: could not claim interface 0: Device or resource busy
1.089548 blazer_status: short reply
1.089570 Status read 1 failed
1.093459 send: Q1
1.151423 read: Q1
1.151487 blazer_status: short reply
1.151506 Status read 2 failed
1.155442 send: Q1
1.215440 read: Q1
1.215539 blazer_status: short reply
1.215562 Status read 3 failed
1.215581 Trying mustek protocol…
1.219435 send: QS
1.471366 read: (235.6 235.6 235.6 — 50.1 13.6 –.- 00001001
1.471590 blazer_status: non numerical value [---]
1.471645 blazer_status: non numerical value [--.-]
1.471687 Status read in 1 tries
1.471706 Supported UPS detected with mustek protocol
1.475396 send: F
1.599348 read: #230.0 002 12.00 50.0
1.599536 Ratings read in 1 tries
1.603375 send: I
1.663341 read: I
1.663408 blazer_vendor: short reply
1.663429 Vendor information read 1 failed
1.667352 send: I

Broadcast Message from ….
(somewhere) at 0:45 …

Communications with UPS Z3_700@localhost lost

1.727365 read: I
1.727466 blazer_vendor: short reply
1.727488 Vendor information read 2 failed
1.731350 send: I
1.791325 read: I
1.791403 blazer_vendor: short reply
1.791423 Vendor information read 3 failed
1.791440 Vendor information unavailable
1.791462 Battery runtime will not be calculated (runtimecal not set)
1.795338 send: QS
2.047274 read: (235.6 235.6 235.6 — 50.1 13.6 –.- 00001001
2.047437 blazer_status: non numerical value [---]
2.047481 blazer_status: non numerical value [--.-]
2.047805 dstate_init: sock /var/run/nut/blazer_usb-Z3_700 open on fd 5
2.051302 send: QS
2.303228 read: (236.1 236.1 236.1 — 50.1 13.6 –.- 00001001
2.303385 blazer_status: non numerical value [---]
2.303427 blazer_status: non numerical value [--.-]

Le driver

Vous devez recharger les fichiers de configuration après chaque modification :

$ sudo udevadm control –reload_rules
$ sudo udevadm control trigger

Note : ces commandes sont optionnelles pour les onduleurs USB.

Test de la communication entre le driver et l’onduleur

$sudo upsdrvctl start

Network UPS Tools – UPS driver controller 2.4.3
Network UPS Tools – Megatec/Q1 protocol USB driver 0.03 (2.4.3)
Supported UPS detected with mustek protocol
Vendor information unavailable
Battery runtime will not be calculated (runtimecal not set)

Broadcast Message from user@Debian
(somewhere) at 23:16 …

Communications with UPS Z3_700@localhost established

upsd et upsmon

upsd communique avec le driver que nous venons de démarrer. Le moniteur upsmon communique avec le service upsd. De multiples moniteurs sur différentes machines peuvent partager le même onduleur physique. Le moniteur enverra la commande d’extinction de leur machine hôte.

Fichier du moniteur : /etc/nut/upsmon.conf

Fichier du serveur : /etc/nut/upsd.conf

# MAXAGE 15
# LISTEN 127.0.0.1 3493

Ces fichiers doivent être protégés contre la lecture des utilisateurs !

$ sudo chown root:nut /etc/nut/*
$ sudo chmod 640 /etc/nut/*

Redémarrer le service nut

$ sudo /etc/init.d/nut restart

Regardez vos log système pour voir si tout s’est bien passé.
Client ups

Le programme upsc permet d’interroger votre onduleur

$ upsc -L localhost donne une liste des onduleurs géré par le serveur sur l’hôte.

$ upsc z3_700

battery.voltage: 13.60
battery.voltage.nominal: 12.0
beeper.status: enabled
device.type: ups
driver.name: blazer_usb
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/hidraw0
driver.parameter.productid: 5161
driver.parameter.vendorid: 0665
driver.version: 2.4.3
driver.version.internal: 0.03
input.current.nominal: 2.0
input.frequency: 50.1
input.frequency.nominal: 50
input.voltage: 227.9
input.voltage.fault: 227.9
input.voltage.nominal: 230
output.voltage: 227.9
ups.delay.shutdown: 30
ups.delay.start: 180
ups.productid: 5161
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0665

Tout est prêt pour que votre onduleur prévienne le système lors des coupures du secteur.

Par défaut, upsmon attendra le signal de batterie critique pour déclencher l’arrêt de la machine ; ce qui peut se produire après une vingtaine de minutes voire 30 minutes s’il n’est pas trop chargé.

Note : Pour arrêter votre onduleur à distance :

$upsdrvctl shutdown

http://irp.nain-t.net/doku.php/100iproute:020_iproute2

Mise en place d’une règle de routage

Dans ce qui suit, la machine qui va servir de passerelle miroir s’appelle « saturne x.

La liste des tables qui existent sur votre machine se trouve dans le fichier /etc/iproute2/rt_tables. Vous ne pourrez pas créer de règles (rules) associées à une table qui n’est pas référencée dans ce fichier. Comme nous aurons besoin d’une table de routage spécifique pour le protocole POP3, nous allons créer une entrée supplémentaire dans ce fichier qui, après modification, aura l’allure suivante :

saturne:~# cat /etc/iproute2/rt_tables
#
# reserved values
#

200 pop3
255 local
254 main
253 default
0 unspec
#
# local
#
1 inr.ruhep

Cette manipulation, en elle même n’apporte rien aux règles en vigueur :

saturne:~# ip rule list
0: from all lookup local
32766: from all lookup main
32767: from all lookup default

Si nous voulons ajouter une règle, il faudra le dire explicitement de la façon suivante (prenez-le comme une recette pour le moment) :

saturne:~# ip rule add fwmark 6e table pop3

Ceci a pour effet d’ajouter une règle, que nous comprendrons mieux par la suite. Disons pour le moment que, lorsqu’un paquet contient la marque 0x6e (valeur hexadécimale), il devra être routé en fonction des informations contenues dans la table de routage pop3.

saturne:~# ip rule list
0: from all lookup local
32765: from all fwmark 6e lookup pop3
32766: from all lookup main
32767: from all lookup default

Nous voyons effectivement apparaitre une ligne supplémentaire dans la liste des règles.

Mais la table de routage pop3 est vide. Il faut la peupler un petit peu. En réalité, qu’avons-nous besoin de faire, en fonction de la topologie donnée ? Il nous suffit de dire que pour ces paquets, la route par défaut n’est pas 192.168.0.1, mais 192.168.0.3, adresse ip du serveur mandataire. Faisons le :

ip route add default via 192.168.0.3 dev eth0 table pop3

Bien. Pour vérifier :

saturne:~# ip route list table pop3
default via 192.168.0.3 dev eth0

Et si nous regardons la table de routage principale :

saturne:~# ip route list table main
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.2
default via 192.168.0.1 dev eth0

Autrement dit, si tout se passe comme prévu, tous les paquets sortant du poste de travail (qui est configuré pour voir 192.168.0.2 comme passerelle par défaut) seront aiguillés vers 192.168.0.1 (la vraie passerelle vers l’internet), sauf les paquets marqués “6e”, qui, eux, seront aiguillés vers 192.168.0.3 (le futur proxy transparent POP3).

Pour pouvoir vérifier si tout ça fonctionne, il faut commencer par pouvoir marquer ces paquets avec le label 6e, ce que nous n’avons pas encore fait.

Pour réaliser cette opération, nous aurons recours à Netfilter, avec IPtables.

Increase the speed of Linux Software RAID reconstruction

If you are in a situation where you sit in front of the console (or on a remote ssh connection) waiting for a Linux software RAID to finish rebuilding (either you added a new drive, or you replaced a failed one, etc.) then you might be frustrated by how slow this process is running. You are running cat on /proc/mdstat repeatedly (you should really use watch in this case ;) ), and this seems to never finish… Obviously that there is a logical reason for this ‘slowness‘ and on a production system you should leave it running with the defaults. But in case you want to speed up this process here is how you can do it. This will place a much higher load on the system so you should use it with care.

To see your Linux kernel speed limits imposed on the RAID reconstruction use:

cat /proc/sys/dev/raid/speed_limit_max
200000
cat /proc/sys/dev/raid/speed_limit_min
1000

In the system logs you can see something similar to:
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.

This means that the minimum guaranteed speed of the rebuild of the array is approx 1MB/s. The actual speed will be higher and will depend on the system load and what other processes are running at that time.
In case you want to increase this minimum speed you need to enter a higher value in speed_limit_min. For example to set this to approx 50 megabytes per second as minimum use:

echo 50000 >/proc/sys/dev/raid/speed_limit_min

The results are instant… you can return to the watch window to see it running, and hope that this will finish a little faster (this will really depend on the system you are running, the HDDs, controllers, etc.):

watch cat /proc/mdstat

Remarque très constructive de Ludovic L.

« Le message Cirpack n’est pas un bug, mais un message de keepalive pour
le nat upd des routeurs des internautes (maintien de l’entrée nat entre
votre poste et le serveur free).
Bref … pour asterisk le patch est ceci :

éditer le fichier :  ./channels/chan_sip.c


e = ast_skip_nonblanks(e);
if (*e)
*e++ = ‘\0′;
e = ast_skip_blanks(e);
+               if (!strcasecmp(req->rlPart1, « Cirpack ») &&
+                   !strcasecmp(req->rlPart2, « KeepAlive ») &&
+                   !strcasecmp(e, « Packet »)) {
+                       /* Silently drop bogus Cirpack keepalive packets */
+                       return -1;
+               }
if (strcasecmp(e, « SIP/2.0″) ) {
ast_log(LOG_WARNING, « Bad request protocol
%s\n », e);
return -1;
…..

le signe (+) c’est les lignes à ajouter. »

en effet c’est bcp plus propre que la regle du parefeu

aptitude install stress

stress –cpu 2 –io 1 –vm 2 –vm-bytes 128M –timeout 3600s –verbose

ou :

cpu : nombre de CPU

io : load par vm

vm : nb de vm

vm-bytes : la taille de chaque vm

timeout : le temp du test

verbose : pour connaitre ce qu’il fait

essayez ceci et en cas de linux mal réglé, vous le plantez direct :

stress –cpu 8 –io 1 –vm 1024 –vm-bytes 128M –timeout 3600s –verbose

Toujours plus de ram, mais aussi de process, et un jour on tombe sur des pannes, et des plantages de son linux sans comprendre …

Apres lecture approfondie de la gestion de la ram :

vm.overcommit_memory = 2
vm.overcommit_ratio = 95

dans le /etc/sysctl.conf

Le premier force linux à gerer au mieux la ram physique avant le swap et à ne considerer le swap que comme un complément .

Le second indique d’utiliser 95 % de la ram physique et d’en garder donc 5% pour l’hote en plus de 1/32 de ram codés dans le noyau réservés par defaut .

Ceci s’applique au kernel 2.6

Pour verifier : cat /proc/meminfo

ou : From the kernel docs:The CommitLimit is calculated with the following formula: CommitLimit = (‘vm.overcommit_ratio’ * Physical RAM) + Swap. For example, on a system with 1G of physical RAM and 7G of swap with a `vm.overcommit_ratio` of 30 it would yield a CommitLimit of 7.3G

The first thing you must learn about RAID technologies in Linux is that they have nothing in common with HP-UX, and I mean nothing! Yes there is LVM but that’s all, the mirror of a volume group for example is not done through LVM commands, in fact you are not going to mirror a volume group but the block device/s where the volume group resides.

There are two tools to manage RAID in Linux.

* dmraid

* mdadm

Dmraid is used to discover and activate software (ATA)RAID arrays, commonly known as fakeRAID, and mdadm is used to manage Linux Software RAID devices.

dmraid

Dmraid, uses libdevmapper and the device-mapper kernel driver to perform all the tasks.

The device-mapper is a component of the Linux Kernel. This the way the Linux Kernel do all the block device managment. It maps a block device onto another and forms the base of volume management (LVM2 and EVMS) and software raid. Multipathing support is also provided through the device-mapper. Device-mapper support is present in 2.6 kernels although there are patches for the most recent versions of 2.4 kernel version.

dmraid supports several array types.

[root@caladan ~]# dmraid -l

asr : Adaptec HostRAID ASR (0,1,10)

ddf1 : SNIA DDF1 (0,1,4,5,linear)

hpt37x : Highpoint HPT37X (S,0,1,10,01)

hpt45x : Highpoint HPT45X (S,0,1,10)

isw : Intel Software RAID (0,1)

jmicron : JMicron ATARAID (S,0,1)

lsi : LSI Logic MegaRAID (0,1,10)

nvidia : NVidia RAID (S,0,1,10,5)

pdc : Promise FastTrack (S,0,1,10)

sil : Silicon Image(tm) Medley(tm) (0,1,10)

via : VIA Software RAID (S,0,1,10)

dos : DOS partitions on SW RAIDs

[root@caladan ~]#

Following are a couple of examples to show dmraid operation.

* Array discovering

[root@caladan ~]# dmraid -r

/dev/dm-46: hpt45x, « hpt45x_chidjhaiaa-0″, striped, ok, 320172928 sectors, data@ 0

/dev/dm-50: hpt45x, « hpt45x_chidjhaiaa-0″, striped, ok, 320172928 sectors, data@ 0

/dev/dm-54: hpt45x, « hpt45x_chidjhaiaa-1″, striped, ok, 320172928 sectors, data@ 0

/dev/dm-58: hpt45x, « hpt45x_chidjhaiaa-1″, striped, ok, 320172928 sectors, data@ 0

[root@caladan ~]#

* Activate all discovered arrays

[root@caladan ~]# dmraid -ay

* Deactivate all discovered arrays

[root@caladan ~]# dmraid -an

mdadm

mdadm, is a tool to manage the Linux software RAID arrays. This tool has nothing to do with the device-mapper, in fact the device-mapper is not aware of the RAID arrays created with mdadm.

To illustrate this take a look at the screenshot below. I created a RAID1 device, /dev/md0, I then show its configuration with mdadm –detail. Later with dmsetup ls I list all the block devices seen by the device-mapper, as you can see there is no reference to /dev/md0.

Instead mdadm uses the MD (Multiple Devices) device driver, this driver provides virtual devices created from another independent devices. Currently the MD driver supports the following RAID levels and configurations

* RAID1

* RAID4

* RAID5

* RAID6

* RAID0

* LINEAR (a concatenated array)

* MULTIPATH

* FAULTY (an special failed array type for testing purposes)

The configuration of the MD devices is contained in the /etc/mdadm.conf file.

[root@caladan ~]# cat mdadm.conf

ARRAY /dev/md1 level=raid5 num-devices=3 spares=1 UUID=5c9d6a69:4a0f120b:f6b02789:3bbc8698

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=b36f1b1c:87cf9497:73b81e8c:79ee3c44

[root@caladan ~]#

The mdadm tool has seven operation modes.

1. Assemble

2. Build

3. Create

4. Manage

5. Misc

6. Follow or Monitor

7. Grow

A more detailed description of every major operation mode is provided in the mdadm man page.

Finally below are examples of some of the more common operations with mdadm.

* Create a RAID1 array

[root@caladan ~]# mdadm –create /dev/md1 –verbose –level raid1 –raid-devices 2 /dev/sd[de]1

mdadm: size set to 1044096K

mdadm: array /dev/md1 started.

[root@caladan ~]#

* Get detailed configuration of the array

[root@caladan ~]# mdadm –query –detail /dev/md1

/dev/md1:

Version : 00.90.01

Creation Time : Tue Nov 23 22:37:05 2010

Raid Level : raid1

Array Size : 1044096 (1019.80 MiB 1069.15 MB)

Device Size : 1044096 (1019.80 MiB 1069.15 MB)

Raid Devices : 2

Total Devices : 2

Preferred Minor : 1

Persistence : Superblock is persistent

Update Time : Tue Nov 23 22:37:11 2010

State : clean

Active Devices : 2

Working Devices : 2

Failed Devices : 0

Spare Devices : 0

UUID : c1893118:c1327582:7dc3a667:aa87dfeb

Events : 0.2

Number Major Minor RaidDevice State

0 8 49 0 active sync /dev/sdd1

1 8 65 1 active sync /dev/sde1

[root@caladan ~]#

* Destroy the array

[root@caladan ~]# mdadm –remove /dev/md1

[root@caladan ~]# mdadm –stop /dev/md1

[root@caladan ~]# mdadm –detail /dev/md1

mdadm: md device /dev/md1 does not appear to be active.

[root@caladan ~]#

* Create a RAID5 array with an spare device

[root@caladan ~]# mdadm –create /dev/md1 –verbose –level raid5 –raid-devices 3 –spare-devices 1 /dev/sd[def]1 /dev/sdg1

mdadm: array /dev/md1 started

[root@caladan ~]#

* Check for the status of a task into the /proc/mdstat file.

[root@caladan ~]# cat /proc/mdstat

Personalities : [raid6] [raid5] [raid4]

md0 : active raid6 sdi1[7] sdh1[6] sdg1[5] sdf1[4] sde1[3] sdd1[2] sdc1[1] sdb1[0]

226467456 blocks level 6, 64k chunk, algorithm 2 [8/8] [UUUUUUUU]

[=========>...........] resync = 49.1% (18552320/37744576) finish=11.4min speed=27963K/sec

unused devices: <none>

[root@caladan ~]#

* Generate the mdadm.conf file from the current active devices.

[root@caladan ~]# mdadm –detail –scan

ARRAY /dev/md1 level=raid5 num-devices=3 spares=1 UUID=5c9d6a69:4a0f120b:f6b02789:3bbc8698

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=b36f1b1c:87cf9497:73b81e8c:79ee3c44

[root@caladan ~]# mdadm –detail –scan >> mdadm.conf

As a final thought, my recommendation is that if there is hardware RAID controller available, like the HP Smart Array P400 for example, go hard-RAID five by five and if not always use mdadm even if there is an onboard RAID controller.

Juanma.

via2010 November 24 « Juanma’s Blog.