Archive for the ‘Evolix’ Category

Ouverture d’un bureau Evolix au Canada

Tuesday, September 22nd, 2015

evolix_erable
Mon dernier article a plus d’un an, il se finit sur une prédiction pour 2024 : « C’est désormais une équipe de 20 personnes réparties entre Marseille/Paris/Montréal, permettant un développement international et une infogérance continue 24h/24. »

Septembre 2015 : Evolix se lance à la conquête du monde en ouvrant un bureau à Montréal au Canada ! Nos bureaux sont situés au cœur du quartier du Plateau, proche du centre-ville et des datacenters Cologix où nous sommes en cours d’installation de nos infrastructures d’hébergement. Dès octobre, on pourra donc proposer la location de serveurs à Montréal ! Grâce au décalage horaire France-Québec, on va également améliorer notre offre de surveillance et support 24h/24 : le pic d’activité du soir des sites e-commerce français (20-23h) pourra être étroitement surveillé par notre équipe technique au Canada, c’est ce qu’on appelle l’infogérance Follow-the-Sun.

J’aime à dire qu’Evolix devient donc une  « petite multinationale » …on exporte notre savoir-faire, on s’ouvre à une nouvelle culture, on s’améliore en permanence tout en gardant bien ancrées nos valeurs : proximité avec nos clients, excellence technique et passion pour notre métier et les Logiciels Libres.

2004-2014 : Evolix a 10 ans !

Monday, June 23rd, 2014

evolix-10ans-bougies

2003. La préhistoire d’Evolix. En stage à la Ville de Marseille, l’idée de création d’une start-up germe début juillet. J’ai discuté par email de ce projet avec Sébastien Dubois (alors en stage en Ecosse) puis Maxime Keller (jeune diplômé). Au départ, le but était un peu vague : promouvoir les Logiciels Libres auprès des particuliers et des entreprises. L’idée était surtout axée sur la vente de PCs sous Linux et des services associés ! Le premier nom évoqué pour la structure à créer : Prisunix… (évidemment non retenu ;-)

2004. Coincé dans un local de quelques m²  prêté par l’ESM2, avec un contrat de stage trafiqué (il y a prescription), je n’imaginais pas encore que 10 ans plus tard on serait une belle équipe de 8 personnes dans 170 m² de bureaux loués à la Ville de Marseille. Le PC bas de gamme en guise de serveur qui tournait 24h/24 dans ma chambre était loin de notre actuelle infrastructure multi-datacenters. Le chiffre d’affaires annuel de 7500€, 100 fois moins élevé qu’aujourd’hui. Après avoir vendu quelques PCs sous Linux (les fameux EvoPC et EvoPortable vendus en quelques exemplaires), on a rapidement trouvé un vrai marché : l’infogérance de serveurs Linux pour entreprises.

2014. De nombreux défis relevés plus tard, on prend un peu de temps pour se retourner sur ces années passées. Notre activité d’infogérance s’est développée, elle concerne désormais 400 serveurs Linux/BSD pour une centaine de clients. En complément, nous avons mis en place une solide offre d’hébergement. En fait, on n’est plus vraiment une start-up, même si l’on en a gardé les côtés positifs (souplesse, ambiance de travail). Mais ce qui n’a pas changé depuis nos débuts : notre motivation et notre passion ! On a fêté nos 10 ans avec nos clients, partenaires et amis lors de notre soirée anniversaire.

2024. Projection dans le futur. Evolix a ouvert un établissement à Paris et une succursale à Montréal. C’est désormais une équipe de 20 personnes réparties entre Marseille/Paris/Montréal, permettant un développement international et une infogérance continue 24h/24. La plupart des serveurs sont désormais assemblés par Evolix, avec des boîtiers réalisés avec une imprimante 3D, et installés dans l’un des points de présence d’Evolix en datacenter. La soirée pour fêter nos 20 ans se passera cette fois sur le toit du Mucem à Marseille !

Informations à propos d’Heartbleed, la faille de sécurité d’OpenSSL

Monday, April 14th, 2014

Voilà maintenant une semaine a été révélée la faille Heartbleed touchant certaines versions récentes de la bibliothèque OpenSSL. OpenSSL est un Logiciel Libre notamment utilisé pour les protocoles sécurisés HTTPS ou IMAPS. Cette faille a été surmédiatisée et plusieurs clients nous ont interrogé à ce sujet. Même si cela date un peu, il s’avère plus pratique et plus transparent de mettre nos réponses sur ce blog.

Qu’est-ce que la faille Heartbleed ?

Il s’agit d’une faille de sécurité touchant OpenSSL permettant d’accéder à une partie (64 Ko) quasi-aléatoire de la mémoire d’une application via le protocole SSL/TLS. Cela concerne évidemment les services utilisant SSL/TLS accessibles publiquement comme HTTPS, IMAPS, POPS, SMTPS ou encore SMTP over TLS. Cela peut aussi concerner les logiciels client faisant des requêtes via SSL/TLS sur des serveurs malicieux.

La partie de la mémoire dévoilée étant plus ou moins aléatoire, on peut considérer que de multiples requêtes permettent de révéler l’ensemble de la mémoire de l’application concernée. Cela concerne évidemment la clé privée SSL utilisée mais les autres données système et applicative chargée en mémoire par l’application (mot de passe d’une base de données, contenu de /etc/passwd, contenu d’une base de données, etc.). Certains experts affirment même que l’ensemble de la mémoire d’une machine impactée pourrait être accessible.

Mon serveur infogéré par Evolix a-t-il été concerné ?

Nous gérons des serveurs avec le système Debian GNU/Linux. Les serveurs utilisant Squeeze (Debian 6) ne sont pas impactés. Les serveurs utilisant Wheezy (Debian 7) sont directement concernés si ils ont un service HTTPS ou  POPS/IMAPS ou SMTP publiquement accessibles, et indirectement si ils peuvent faire de nombreuses requêtes SSL/TLS vers des serveurs non sûrs situés à l’extérieur.

Mon serveur infogéré par Evolix a été concerné, que dois-je faire ?

La faille a été révélée lundi 7 avril 2014 vers 21h. Nous nous sommes penchés sur cette faille à partir de 00h15 (bug signalé sur notre IRC privé, merci Arnaud) et nous avons mis à jour tous les serveurs directement concernés dans les heures qui ont suivi et le lendemain. Votre serveur n’est donc plus vulnérable. Mais il a pu l’être pendant au moins quelques heures. Une analyse du trafic réseau et des logs suspects (connexions STARTTLS via SMTP, requêtes HTTPS sans contenu, etc.) nous laissent penser qu’il n’y a pas eu d’attaque sur ce laps de temps. Cela étant dit, par principe de précaution et car dans tous les cas cela doit être fait régulièrement, nous conseillons tout de même de renouveler toutes les informations secrètes sur les serveurs directement impactés (mots de passe, clés privées, etc.). Vous devez également relancer toutes les applications qui utilisent libssl (démons en Python ou Ruby, etc.).

Et sur mon poste de travail, que dois-je faire ?

Vous devez mettre-à-jour vos postes de travail immédiatement. Avant de vous connecter à un site en HTTPS, vous pouvez vérifier qu’il n’est plus vulnérable. Il est également conseillé de renouveler vos mots de passe sur les différents services en ligne (notamment Google, Github, Facebook, Twitter, Amazon…) : de toutes façons vous devez le faire régulièrement, c’est donc une bonne occasion de le faire !

Des conclusions à tirer de cette affaire ?

Il n’y a rien de vraiment nouveau, si ce n’est qu’il est désormais difficile d’ignorer que :
– l’application régulière des mises-à-jour de sécurité est essentielle, vous ne pouvez pas vous contenter d’installer un serveur et ne pas vous en occuper, surtout si il est accessible publiquement ;
– vous devez exposer publiquement le moins de choses possibles : cela passe par un firewall qui va restreindre un maximum de services par adresse IP, et par la désactivation de tous les fonctionnalités inutiles (avez-vous vraiment besoin d’Apache/SSL si votre site web ne tourne pas en HTTPS ?  l’activation de STARTTLS sur votre Postfix est-elle vraiment nécessaire ?) ;
– toutes les informations secrètes doivent être changés régulièrement (clés privés, mots de passe, certificats, etc.) et changeables rapidement en cas de besoin… l’utilisation d’un gestionnaire de mot de passe étant indispensable.

Bug MySQL : pas de cache avec des tables InnoDB et un nom de base/table foo-bar

Monday, December 2nd, 2013

L’équipe Evolix a récemment découvert un bug assez incroyable : les versions 5.1 à 5.6.8 de MySQL ne gèrent pas le Query Cache (un mécanisme essentiel) sur les tables InnoDB si le nom de la table ou base contient un caractère particulier, notamment le tiret () !! Ce n’est pas une véritable découverte car le bug a été corrigé pour la version 5.6.9 en décembre 2012, mais il a été peu « médiatisé » et surtout il impacte de nombreuses distributions Linux. Concrètement si vous avez Debian (Squeeze/Wheezy/Testing/Sid) ou Ubuntu (toutes les versions depuis 4 ans) et vous utilisez le paquet mysql-server, toutes vos bases ou tables nommées foo-bar sont impactées. Toutes vos requêtes sensées être servies par le cache MySQL ne le sont pas, et il en découle des problèmes de performance (parfois très significatifs). Au passage, pour vérifier qu’une requête MySQL utilise bien le Query Cache, vous pouvez observer le compteur de hits via show status like ‘Qcache_hits’ (parfois difficile sur des serveurs en production, mais vous avez bien sûr des serveurs de préproduction ;-).

Mise en évidence du bug avec un nom de base foo-bar :

mysql> create database `foo-bar`;
mysql> create table `foo-bar`.baz (a int) engine=InnoDB;
mysql> insert into `foo-bar`.baz values (1);
mysql> select * from `foo-bar`.baz;
mysql> show status like 'Qcache_hits';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Qcache_hits   | 42     |
+---------------+--------+
mysql> select * from baz;
mysql> show status like 'Qcache_hits';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Qcache_hits   | 42     |
+---------------+--------+

Mise en évidence du bug avec un nom de table baz-qux :

mysql> create database foobar;
mysql> create table foobar.`baz-qux` (a int) engine=InnoDB;
mysql> insert into foobar.`baz-qux` values (1);
mysql> select * from foobar.`baz-qux`;
mysql> show status like 'Qcache_hits';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Qcache_hits   | 42     |
+---------------+--------+
mysql> select * from foobar.`baz-qux`;
mysql> show status like 'Qcache_hits';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Qcache_hits   | 42     |
+---------------+--------+

Si vous n’êtes pas encore parti en courant vérifier le nom de vos bases et tables MySQL/MariaDB, je vais vous expliquer comment ce bug a été découvert et pourquoi cela illustre bien le travail d’infogérance d’Evolix. En effet, un abonnement à l’infogérance est une sorte d’assurance : outre les opérations visibles (surveillance 24/24, veille technologique, mises-à-jour, support technique), c’est aussi la garantie que l’on mettra tout en œuvre si il vous arrive un incident. Pendant plusieurs mois/années vous n’aurez peut-être pas d’incident sérieux (et tant mieux pour tout le monde), mais un jour vous aurez besoin d’une attention de plusieurs heures voire plusieurs jours. C’est ce qui est arrivé ces dernières semaines avec ce bug MySQL : un client d’Evolix a signalé une lenteur sur certaines pages d’un site d’e-commerce suite à une migration de serveurs. Après pas mal d’analyses, nous n’étions pas convaincus, la lenteur s’expliquait par des milliers de requêtes SQL faites sur chaque page, et surtout cette lenteur était également présente sur l’ancien serveur. Néanmoins, nous avons fini par découvrir que sur un très vieux serveur en Debian Lenny, les pages étaient moins lentes. Après de nombreux tests (passage en SSD, utilisation de TMPFS pour éliminer les I/O disque, tests sur différents serveurs dont un ultra puissant, strace des process, etc.), nous avons mis en évidence que l’exécution des milliers de requêtes SQL étaient tout simplement plus rapides sur le très vieux serveur en Debian Lenny. Ce constat était un peu effrayant pour nous, et presque tout l’équipe s’est mis sur ce problème. On a identifié que les requêtes n’utilisaient pas le Query Cache, et l’on a donc relu toute la documentation concernant le cache MySQL… mais rien à faire, des requêtes SQL simples n’étaient toujours pas mises en cache. Même résultats avec MySQL 5.1/5.5 ou MariaDB 5.5. Puis l’on a découvert ce fameux bug : la base concernée ayant un tiret dans son nom, on l’a fébrilement renommée et *bingo* les requêtes sont désormais cachées !

En attendant une éventuelle correction du bug par Debian, nous conseillons de renommer vos bases et tables impactées. Au passage, le tiret () est un caractère particulier pour MySQL et il est préférable de prendre l’habitude d’utiliser l’underscore (_) dans le nom de vos bases et tables.

Evolix : Augmentation de Capital

Tuesday, June 25th, 2013

J’ai le plaisir de vous informer d’une augmentation du capital social d’Evolix, passant d’un montant de 7.500 EUR à 105.000 EUR.

Cette opération a été réalisée en incorporant une partie des profits des dernières années, c’est-à-dire que la répartition du capital reste inchangée : entièrement détenu par Sébastien Dubois et moi-même. Concrètement c’est surtout un moyen de démontrer notre bonne gestion et solidité financière. Nous hébergeons et infogérons des infrastructures web critiques, et la confiance et la stabilité sont des critères importants pour nos clients actuels et futurs. Grâce à cette augmentation de capital et notre croissance régulière (CA de 650k en 2012), l’objectif est de parvenir dans les prochaines années à un chiffre d’affaires d’un million d’euro. Cette ambition maîtrisée vise à poursuivre notre évolution tout en restant fidèles à nos convictions basées sur les valeurs des Logiciels Libres et la stratégie de rester une équipe à échelle humaine : croître « lentement mais sûrement ».

Pour sa 10ème année d’existence, Evolix prouve ainsi être devenue une entreprise stable et pérenne.

Pourquoi il faut éviter les alias mail vers Orange, Gmail, Hotmail, Free, Yahoo etc.

Tuesday, April 23rd, 2013

Une coutume s’est installée depuis quelques années dans le monde de la messagerie : mettre en place des alias ou redirections de messagerie. Le problème c’est lorsque ces redirections sont d’un domaine vers un autre. Exemple typique : j’achète un nom de domaine “monnouveausite.com” et je crée une redirection de contact@monnouveausite.com qui renvoie vers ma messagerie Orange/Hotmail/Gmail/Free/Yahoo. C’est mal… il faut vraiment éviter de faire cela !

Pourquoi c’est mal ? Car votre alias va inévitablement finir par recevoir du spam. Et ce spam sera donc redirigé “tel quel” des serveurs gérant les MX de “monnouveausite.com” vers Orange/Hotmail/Gmail/Free/Yahoo. Du coup, Orange/Hotmail/Gmail/Free/Yahoo vont identifier les MX comme étant des relais de spams et blacklister ces serveurs ! C’est d’autant plus vrai avec les politiques antispam de plus en plus strictes d’Orange ou Yahoo par exemple.

Alors que faire ? Plusieurs éléments de réponses :
– Évitez d’avoir une messagerie chez Orange/Hotmail/Gmail/Free/Yahoo ! Hotmail ne respecte les standards, Gmail ne répond JAMAIS aux demandes sur abuse@, Yahoo et Free ont une politique antispam trop violent, etc. bref, il y a de nombreuses raisons à avoir une messagerie auto-hébergée par vous, vos amis ou des petites entreprises comme Evolix.
– Créez de vrais comptes mail pour héberger “monnouveausite.com” et récupérez les en POP/IMAP/webmail.
– Si vous désirez vraiment centraliser différentes adresses sur une seule messagerie, utiliser une récupération automatique en POP ou IMAP. Si vous avez une messagerie Open Source, vous pouvez utiliser le logiciel libre fetchmail qui récupèrera pour vous tous vos messages. À défaut, si confier vos mots de passe au FBI ne vous fait pas peur, vous pouvez utiliser un service de récupération de messages comme celui de Gmail.

Evolix rachète le datacenter SFR de Marseille

Monday, April 1st, 2013

Pour faire face au succès de notre nouvelle offre de location de serveurs dédiés infogérés, nous avons réfléchi depuis plusieurs mois avec un fond d’investissement qatari pour racheter l’ensemble du datacenter SFR de Marseille. Situé à quelques minutes de nos bureaux, ce datacenter est idéalement placé et va permettre une croissance rapide de nos offres d’hébergement. Nous détaillerons toutes les conséquences de cette acquisition dans les prochains jours, mais nous avons voulu partager au plus tôt l’annonce de cette opération exceptionnelle !

DIY : réparer son écran plat programmé pour l’obsolescence

Wednesday, January 23rd, 2013

Depuis quelques temps, j’ai un écran TV LCD qui avait du mal à s’allumer. Le sortir de veille nécessitait d’appuyer plusieurs fois sur le bouton marche/arrêt : deux fois, trois fois… et ça s’empirait mois après mois : jusqu’à des dizaines fois voire impossible de l’allumer.

Intéressé par la théorie de l’obsolescence programmée, j’avais vu un documentaire évoquant un problème avec certains écrans plats. J’ai d’ailleurs retrouvé ce documentaire (Cash Investigation, France2, “La mort programmée de nos appareils”) et la partie sur les écrans débute à 06:42 : http://www.youtube.com/watch?v=f3a42dMgvkU#t=412s Au passage, vous pouvez regardez en entier ce reportage qui dénonce l’obsolescence programmée des écrans plats Samsung et LG, d’ordinateurs portables HP et évidemment les iPod/iPhone d’Apple. Mais surtout, regardez absolument l’excellent documentaire d’Arte “Prêt à jeter ou l’obsolescence programmée” : http://www.youtube.com/watch?v=XMfz8Cbyxl0

Bref, je consultais déjà le prix d’un écran neuf, mais le vague souvenir de ce reportage et mon récent intérêt pour le DIY (Do It Yourself) m’ont poussé à faire quelques recherches sur le web. Sans trop de conviction au départ, j’ai eu la bonne surprise de découvrir de nombreux témoignages décrivant exactement le même phénomène de sortie difficile de veille. Voici un exemple sur un forum parlant exactement du même modèle que mon écran LG 32LC45 : http://forums.futura-sciences.com/depannage/419609-sortie-de-veille-tv-lg-lcd-32lc45-resolu.html La cause serait donc bien ces fameux condensateurs qui auraient gonflés !

J’ai donc amené mon écran LCD dans le “hacklab” Evolix et je l’ai ouvert : sur l’une des cartes électroniques, j’ai effectivement trouvé 4 condensateurs légèrement gonflés. J’ai commandé des condensateurs de remplacement pour quelques euros.

Restait la partie la plus délicate pour moi : déssouder les anciens condensateurs et souder les nouveaux. Je n’avais jamais vraiment réalisé de soudures électroniques, mais avec quelques bons conseils de la dream team Evolix, j’ai pu réaliser les soudures (un peu grossières il est vrai).

J’ai ensuite remonté la carte électronique et… l’écran s’allume à nouveau parfaitement !

Conclusion : avec un peu de bidouille et quelques euros, on peut résister un peu à l’obsolescence programmée.

Raisons techniques pour ne pas utiliser Hotmail

Sunday, August 26th, 2012

Si le service de messagerie Hotmail est peu utilisé dans le milieu professionnel, il reste très répandu chez les particuliers (des millions de français utilisent une adresse @hotmail.com c’est davantage que Wanadoo/Orange !). Pourtant, Hotmail est une véritable plaie : il ne respecte pas certains standards de la messagerie, et c’est un casse-tête pour les sysadmins… doit-on tenter d’expliquer cela aux utilisateurs ? ou doit-on bidouiller des solutions pour prendre en compte la position dominante d’Hotmail ?

Comme souvent, la réponse est entre les deux : si l’on tâche de s’adapter aux différents “caprices” d’Hotmail, ce blog-post essaye d’expliquer pourquoi vous ne devez pas utiliser Hotmail ! Et je ne parlerai pas ici des problèmes de confidentialité posés par l’utilisation d’une usine à emails (tout comme Yahoo, Gmail, etc.), ni de l’interface web horrible d’Hotmail, ni même de l’impossibilité d’avoir un accès à sa messagerie avec un protocole aussi standard que l’IMAP. Je vais plutôt parler des problèmes d’envoi d’email, et notamment du non respect du protocole SMTP ! Voici les dernières facéties d’Hotmail :

– Hotmail cesse en quelques minutes ses tentatives d’envoi lors qu’il reçoit un code de réponse 4xx (signifiant une erreur temporaire pour rappel). D’après une observations récente, il essaye uniquement 4 fois en 3 minutes… puis abandonne définitivement en informant l’expéditeur : This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. Conséquence assez simple : dès qu’un souci temporaire de plus de 3 minutes survient sur un serveur (maintenance, problème DNS, etc.), les messages n’arriveront jamais ! Pire, dans le cas assez répandu d’une protection antispam via greylisting, qui consiste à renvoyer volontairement un code 4xx pendant un certain temps (souvent 5 minutes), tous les messages seront rejetés ! En bref, si vous envoyez vos emails via Hotmail, une bonne partie de vos correspondants ne les recevront pas…

– Hotmail semble lire à l’envers les poids des champs MX d’un nom de domaine ! J’ai vu mention de cela sur quelques forums et après quelques tests, Hotmail envoie bien vers le serveur MX du poids le plus fort ! C’est exactement l’inverse du fonctionnement correct. À première vue, cela n’est pas grave, mais les serveurs MX de poids le plus fort ne sont utilisés qu’en cas de souci sur les serveurs principaux et : ils sont parfois moins bien maintenus ; ils ont souvent des règles antispam strictes (comme du greylisting) ; pire, ils sont parfois hors-service (j’ai déjà découvert une grosse structure publique qui a eu un MX secondaire renvoyant des erreurs 5xx pendant plusieurs mois !). En bref, outre que c’est non conforme aux standards (c’est même une technique de spammeurs…), cela augmente encore les chances que les emails envoyés via Hotmail ne soient jamais reçus.

En résumé, Hotmail ne respecte pas les standards et en ce moment, les messages envoyés via Hotmail ont une bonne chance de ne jamais être délivrés ! C’est l’une des bonnes raisons pour laquelle on ne doit pas utiliser Hotmail. Et changer @hotmail.com en @outlook.com ne changera rien…

Astuces pour gérer un répertoire ext3 bien rempli

Wednesday, August 1st, 2012

Disclaimer : Valable pour de l’ext3 sous Linux (utilisable sur d’autres filesystems ou Unix à vos disques et péril)

Vous avez un répertoire rempli à rabord de nombreux fichiers, et il est impossible de connaître sa taille, le lister ou l’effacer sans impact sur la production ?

Voici quelques astuces :

– Avec un “ls -ld” sur le répertoire, vous pouvez estimer grossièrement le nombre de fichiers présents dans un répertoire. En effet, un répertoire vide fait 4 Ko (je simplifie). Et plus il contient de fichiers, plus sa taille va augmenter. Par exemple, un répertoire contenant 2 millions de fichiers pourra faire une taille de 100 Mo (je parle bien de la taille du répertoire et non pas de la taille du contenu). Attention, c’est variable selon la longueur des noms des fichiers. Et prendre garde aussi que ce n’est pas dynamique : si vous videz complètement un répertoire bien rempli, il gardera sa taille volumineuse (d’où l’intérêt de recréer un répertoire qui s’est rempli “par erreur”).

– Pour lister les fichiers du répertoire, utiliser la commande “ls” n’est pas une bonne idée car elle accède à toute la liste avant de l’afficher. Voici comment lister 10 fichiers sans attendre :

perl -le 'opendir DIR, "." or die; $i=0; while ($i<10) { my $f = readdir DIR; print $f; $i++; }; closedir DIR'

Grâce à leurs noms, vous pouvez désormais examiner (ouvrir, connaître sa taille) un échantillon de fichiers contenus dans votre fameux répertoire.

Pour lister l’ensemble des fichiers sans attendre comme “ls” :

perl -le 'opendir DIR, "." or die; print while $_ = readdir DIR; closedir DIR'

– Pour effacer le contenu du répertoire en limitant l’impact sur la production, oubliez “rm -rf” qui va saturer vos I/O disque mais préférez le faire par blocs de N fichiers avec des pauses de quelques secondes ! Voici une commande “conviviale” qui va faire cela par blocs de 300 fichiers avec des pauses de 5 secondes :

perl -le 'use POSIX qw/strftime/; opendir DIR, "." or die; $i=0; printf "DELETING IN PROGRESS...";
 while (my $f = readdir DIR) {unlink $f;  $i++;
 if ($i % 300 == 0) {printf "...$i files deleted\n".strftime("%Y-%m-%d %H:%M:%S",localtime)." : PAUSE...";
 $| = 1; sleep 5 ; printf "...DONE. "; printf "DELETING IN PROGRESS..."}}; printf "...DONE"; closedir DIR'

EDIT : en complément, on n’oubliera pas que l’on peut aussi gérer la priorité d’ordonnancement des I/O avec la commande ionice
(merci à Sylvain B. de l’avoir souligné)