1083 – Jeans et Sneakers fabriqués en France

Savez-vous qu’un jeans parcourt jusqu’à 65000 km lors de sa fabrication, alors que 1083 km seulement séparent les 2 villes les plus éloignées de l’hexagone ? (Menton au sud-est, et Porspoder un petit village Breton).

Je vous propose de relever avec moi ce défi : Fabriquer un jeans et une paire de basket, à moins de 1083km de chez vous !

Je tenais à vous présenter un projet ambitieux et sympathique, porté par un ami qui tient une boutique de mode éthique à Romans.
L’idée du projet 1083, c’est de lancer une marque de textiles de qualité, écologique et locale, et dont les matériaux ne font pas quatre fois le tour du monde en aller-retour entre la Chine et l’Europe lors de la production.

La première production est financée via le site de financement participatif Ulule. En moins d’une semaine, 71% de l’objectif de financement a été atteint (il reste deux mois…).
Le site de 1083 présente plus en détails les modèles.

Grepping processes

Grepping ps output will result in grep showing its own process:
[skanx@po-sr-nm ~]$ ps -efH|grep bash
skanx 28142 8787 0 11:59 pts/6 00:00:00 bash
skanx 28346 28142 0 12:01 pts/6 00:00:00 grep –color=auto bash

Instead, use ps -efH|grep [b]ash:
[skanx@po-sr-nm ~]$ ps -efH|grep [b]ash
skanx 28142 8787 0 11:59 pts/6 00:00:00 bash

Problème de connexion au portail VPN SSL FortiGate

Sur certains FortiGate, impossible de se connecter au portail VPN depuis Windows.

Il semblerait que le problème survienne après l’installation de la KB2585542.
Une solution donnée est de désinstaller cette KB, mais cela ne fonctionne pas chez moi.

L’autre solution est de changer une entrée de la base de registre, ce qui fonctionne pour moi (Windows 7) :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"SendExtraRecord"=dword:00000002

Source

ESX / VM Linux : libérer de l’espace disque (thin provisining)

Je viens de faire quelques tests, et il est possible de récupérer de l’espace disque quand on supprime des fichiers sur une VM Linux dont le disque est en thin provisioning.

Bref, je vois deux solutions :
– Si on peut utiliser storage vMotion, et qu’on a deux datastore, super, on va pouvoir le faire online !
– Si on n’a pas la licence qui va bien pour vmotion, on doit le faire offline…

L’idée générale, c’est de créer un gros fichier rempli de zéros, de la taille que l’on veut gagner, que vmware va reconnaître lors de la migration : il va remplacer les zéros contigus par du vide. Ensuite, on migre le disque d’un datastore à un autre (important, sinon ça ne fait rien), on sélectionne thin provisioning pour le format du disque, et hop on gagne de la place. Reste ensuite à re-migrer le disque vers son datastore d’origine.
Evidemment, lors de la création du gros fichier rempli de zéros, on va occuper encore plus de place sur le datastore, c’est donc à prévoir…

Un petit exemple :
J’ai un vmdk thin, avec 20 Go réellement occupés par des fichiers sur 100 Go disponibles. Par le passé, j’ai rempli mon disque, donc le vmdk va occuper en réalité environ 100 Go sur le vmfs. Quand j’ai voulu supprimer ces fichiers, évidemment j’ai gagné de la place à l’intérieur de la VM, mais le vmdk occupe toujours ses 100 Go…
Je regarde mon espace disque avec df -h ; je constate qu’il me reste 80 Go de libre sur mon système de fichiers. Attention, si il y a plusieurs partitions, il faudra peut-être créer des fichier « zero » un peu partout, mais en général c’est à faire là où se trouvent les datas…
Je vais donc créer un gros fichier de 75 Go environ (histoire de pas saturer le serveur en prod…), rempli de zéros, et le supprimer.
# dd if=/dev/zero of= bigZeroedFile bs=1M count=75000
# sync
# rm bigZeroedFile

Ensuite, sous vcenter, je migre ma VM en la changeant de datastore (offline, ou online si on est riche !). Je constate que j’ai libéré plein de place \o/. Ensuite je la re-migre vers le datastore d’origine.
Pfiou…

Autre possibilité, si on ne craint pas de saturer le disque (à ne pas faire sur un Zimbra !), on peut tout simplement créer un fichier qui va occuper tout l’espace libre, en remplaçant la commande dd par un cat, qui s’arrêtera lorsque le disque sera plein.
# cat /dev/zero > bigZeroedFile
# sync
# rm bigZeroedFile

Cette méthode a l’avantage de libérer tout l’espace disque lors de la migration, mais si le système tente d’écrire un fichier de travail pendant ce temps là, on risque l’explosion… La méthode dd permet de conserver une marge de manœuvre.
J’ai aussi vu qu’il existait un outil appelé zerofree, qui a le même fonctionnement que sdelete sous Windows, mais il faut l’utiliser sur un système de fichiers en lecture seule, ce qui complique encore pas mal les choses…

Et si on n’a qu’un seul datastore ?!
Et bien apparemment, on peut utiliser cette commande, guest arrêté, pour duplique le disque :
vmkfstools -i test_thin_linux.vmdk test_thin_linux_thinned.vmdk -d thin
Mais chez moi, ça ne marche pas… le disque ne rétrécit pas…

Je suis d’ailleurs surpris : apparemment, c’est tout aussi galère à faire sous Windows : l’option « shrink » dans les vmtools n’apparaît pas quand le disque virtuel est en thin provisioning (c’est à se demander à quoi elle sert… J’ai vérifié de mon côté, je ne peux pas shrinker un disque virtuel sous Windows quand le disque est en fomat thin. Par contre, quand il est en format thick, j’ai l’option, mais je ne vois pas trop à quoi elle sert, du coup…).
Peut-être que shrinker un disque thick, ça sert à faire des backups plus lights ?
Sous windows, on me souffle qu’il faut faire la même manip, mais avec sdelete -c à la place de dd ?!

Remove a deleted virtual disk LUN on a Linux system (MD3000i SAN array)

When you delete a Virtual Disk on a MD3000i array, that was previously used by a Linux system, the device is not removed from the system, and Linux will still try to access it (if you use LVM for example, you’ll see lots of errors while the system scans the disks to identify PVs). This can be very inconvenient if you reassign a previously assigned LUN, as the system won’t detect the new parameters of the device.
I did not find a command similar to hot_add (used to detect new devices) to automatically remove deleted disks.

By trial and error, though, I understood that you can delete a scsi device with this method:
echo "1" > /sys/class/scsi_device/adapter:bus:target:lun/device/delete

I also wrote a small script that will try and guess the paths to your devices, when you tell it the LUN number you just deleted on the SAN array :
md300i_delete_lun bash script
Warning: this script comes with no guarantee and I won’t take any responsibility if you try to use it :-). I could just test it on two RHEL 5.3 systems, and I don’t know if it will work anywhere else. Since it can be a little bit dangerous, it won’t actually delete anything, just tell you what commands you could use to delete the devices. At your own risk. :-)

Get the ip address in a shell script

Using ifconfig was not a good idea at all.
Here is a more distro-agnostic way:

ip addr show eth0 | grep "inet "| awk '{ print $2}' | awk -F '/' '{ print $1 }'


# set the language to English, to avoid translation problems with ifconfig
export LANG=C
# get IP address of eth0 network interface
ifconfig eth0 | awk '/inet addr/ {split ($2,A,":"); print A[2]}'


source

dpkg-reconfigure locales on ubuntu

dpkg-reconfigure locales doesn’t seem ask what locales you want to enable anymore (ubuntu 8.10), whatever the priority of questions you set in debconf…

The locales to be generated are listed in this file : /var/lib/locales/supported.d/local

Just add your locales there, then do a dpkg-reconfigure locales, it should generate you new locales :

skanx@tipica:~$ cat /var/lib/locales/supported.d/local
en_US.UTF-8 UTF-8
fr_FR UTF-8

skanx@tipica:~$ sudo dpkg-reconfigure locales
Generating locales…
en_US.UTF-8… up-to-date
fr_FR.UTF-8… done

atl2 bug on the eeepc: txs packet size do not coinsist with txd

On my eeePC 700 running ubuntu 8.10 (kernel 2.6.27-11-server), I experienced constant network disconnections with the LAN card, and found these messages in the logs :
[ 1355.131236] eth0: txs packet size do not coinsist with txd txd_:0x000005ea, txs_:0x20000754!
[ 1355.131244] txd read ptr: 0x166c
[ 1355.131249] txs-behind:0x000105ea
[ 1355.131254] txs-before:0x000105ea
[ 1365.041754] atl2: eth0 NIC Link is Up<100 Mbps Full Duplex>

I resolved the issue by installing a newer version of the atl2 module :

Get the lastest atl2 driver from: http://people.redhat.com/csnook/atl2/
Make sure you have the linux-header package corresponding to your kernel installed (package linux-headers-2.6.27-11-server in my case)

– Untar the driver source, compile with make
– Backup the atl2 module that shipped with your kernel (/lib/modules/2.6.27-11-server/kernel/ubuntu/atl2/atl2.ko in my case)
– Replace it with your new version
– sudo depmod
– reboot the computer or stop the network and reload the atl2 module

more info: https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/147639

edit: http://people.redhat.com/csnook/atl2/ seems to be unavailable… I still have the driver source, but don’t know if I can post it here… If you need it, just ask and I’ll send it by e-mail :)