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
Archives des mots-clé: linux
Serveur dédié
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
Onduleur XP 500VA Infosec
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
Routage IProute 2
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 | MDLog:/sysadmin
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
cirpack et asterisk / Freephonie
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
stress complet d’un serveur linux
stress –cpu 16 –vm 90 –vm-bytes 1024M –io 512 –vm-keep –hdd 200 –verbose –timeout 3600
ou : –cpu = nombre de core
– vm-bytes : 1024 mo par vm
–io : 512 entrée sorties par vm
–vm-keep : on charge la ram de vm * vm-bytes
–hdd : 200 fichiers de 1 go
stresser sa machine sous linux
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
gestion et limitation de la ram sous linux
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
2010 November 24 « Juanma’s Blog
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.