To achieve that, you are using the subprocess.Popen command, right.

But the subprocess is very slow, and it outputs data during it runtime, so you would like to output this data to the user as well, so that the user does not wait for the end of the subprocess before getting the information?

Example of a slow subprocess:

#!/bin/bash
for i in 1 2 3 4 5 6; do sleep 5 && echo "${i}th output" && echo "err output num ${i}" >&2; done

Well, that’s fairly easy, just redirect the subprocess’s stdout to your own stdout:

import sys
from subprocess import Popen
Popen("./slow_cmd_output.sh", stdout=sys.stdout, stderr=sys.stderr).communicate()

Although the catch here is the .communicate(). This will allow your program to wait for the end of the subprocess before executing the next line of code. So that your programm does not terminate execution before its subprocess, for instance.

Not that if you want to deamonize the script / zombify it, you can remove the .communicate() and the redirection of stdout and stderr will still work after your program’s termination.

I just went accross an interesting article about which of « print » or « echo » we should use in PHP.

The author has benchmarked the two solutions (though the data are certainly a bit old) shows that, although there is not much difference between the two, echo seems to be more efficient.

Great, I believe you.

Echo multiple statements / arguments vs. Concatenation

But at the end of the article, the author also suggest to use multiple parameters given to one echo statement instead of concatenation because concatenation is slow… bla bla…

As I have always been using concatenation (did not even know echo could take multiple arguments) and I never had any performance issue, I decided to check that and make a benchmark: echo 100,000 times two concatenated strings and do the same thing with two parameters and two echos statements…

The benchmark was clear: concatenation IS FASTER than the two other solutions.

String caching? Making a more relevant benchmark

As it appeared a bit weird to me, having been doing Java / C# mostly recently (with their slow concatenation that recreated a new object blabla), I thought « maybe the PHP VM is caching the result of the concatenated string, thus the benchmark is not relevant ».

OK, let’s check with a counter-possible-caching benchmark then:

$t0 = microtime(true);

define("MAX", 2000000);
File_put_ConTents("echobench._log", "");
function _log($str)
{
	File_put_ConTents("echobench._log", file_get_contents("echobench._log") . $str);
}

// Generating a bunch of string to concatenate to avoid PHP VM-caching
$strs = array();
for ($i=0; $i < MAX+1; $i++) { 
	$m = mt_rand(0, 200);
	$strs[$i] = '';
	for ($j=0; $j < $m; $j++) { 
		$strs[$i] .= chr(mt_rand(0, 255));
	}
}

// Loop where string concatenation caching is possible :
$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo "Hello" . "World! 
";
}
$t2 = microtime(true);
_log("Concatenation, cached: " . ($t2-$t1) . "s\n");

// Loop where is is not :
$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo $strs[$i] . $strs[$i + 1];
}
$t2 = microtime(true);
_log("Concatenation, not cached: " . ($t2-$t1) . "s\n");

// Other ways to display stuff, with and without caching possible each time:
$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo $strs[$i];
	echo $strs[$i + 1];
}
$t2 = microtime(true);
_log("Two echos, not cached: " . ($t2-$t1) . "s\n");

$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo "Hello" , "
";
	echo "World" , "
";
}
$t2 = microtime(true);
_log("Two echos, cached: " . ($t2-$t1) . "s\n");

$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo $strs[$i], $strs[$i + 1];;
}
$t2 = microtime(true);
_log("Two parameters, not cached: " . ($t2-$t1) . "s\n");

$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo "Hello" , "World!" , "
";
}
$t2 = microtime(true);
_log("Two parameters, cached: " . ($t2-$t1) . "s\n");

$t3 = microtime(true);

_log("Total benchmark time: " . ($t3-$t0)."\n");

I generated random strings at the beginning of the script. And I concatenate them after, in the loop. Thus, there is not even once the same concatenation happening, thus, no possible caching or whatever.

The benchmarked has been run on a 1.6GHz Atom processor, with the following command:

sudo nice -n -19 php -q echobanchmark.php > /dev/null

So the process was the most prioritized one on the OS and then there is no reason for any interference between the loops (moreover, the system was idle during the test (and there are 3 other virtual processors for doing whatever work the OS would need to do).

And do you know the result?

Here it goes:

Concatenation, cached: 7.4381861686707s
Concatenation, not cached: 9.9010219573975s
Two echos, not cached: 10.4353120327s
Two echos, cached: 14.883654117584s
Two parameters, not cached: 10.179102897644s
Two parameters, cached: 11.904446840286s
Total benchmark time: 928.97792601585

Conclusion: Concatenation is fast, very fast. It is rougly 30% faster than using the two parameters for echo (26.9268987% exactly) and roughly 30% faster than two echo statements as well (28.720999% exactly) and

The other conclusion here is that PHP does not seem to be caching strings very well. Both the two-parameters and two-statements echo loops are much slower when using a fresh new string and much faster when using something from the previously generated array. The difference between cached / non-cached loop for the concatenation loop is also not that impressive if we observe that my « not cached » loop is using strings of random length that can go until 200 chars whereas the « cached » one is a very short string (so the difference of 2 seconds is certainly also due to the difference in length of the strings).

If you have any suggestion to improve the benchmark, feel free to post a comment.

English readers : see at the bottom of the French version !!

Hello les amis,

Aujourd’hui, petite astuce qui pourrait faire gagner 1h à des gens qui comme moi, pensent qu’il suffit de résoudre un conflit pour… qu’il soit résolu !

Eh bien non, cela ne semble pas marcher tout à fait pareil avec le plug-in Subclipse pour Eclipse.

Si vous avez le malheur d’avoir un conflit, normalement, il vous suffit de faire clic-droit sur le fichier puis « Team » puis « Mark as resolved ».

SAUF QUE le .cproject n’apparaît bien évidemment pas dans la perspective « ressources » (par défaut) de Eclipse !! Impossible donc de le résoudre !

Or, si vous le résolvez en utilisant SVN via la console par exemple, Subclipse ne s’en « rendra pas compte » (ne me demandez pas pourquoi) et refusera encore et toujours de commiter les futurs changements.

Pour résoudre le conflit, il faut que vous ouvriez la « perspective » « Team Synchronizing », à ce moment-là, vous devriez enfin voir votre .cproject et vous pourrez alors faire Mark as resolved (en sélectionnant ensuite l’option de votre choix sur la résolution du conflit).

Voilà ! Et Subclipse arrêtera de vous harceler avec ce conflit qui n’en est plus un…

Bon dev’ !

————————English version (summerized) ———————–

Hi folks,

The .cproject file won’t be displayed on the « resources » perspective (view), so you can’t resolve the conflict by right-clicking and then selecting options « Team » and « Mark as resolved ».

Moreover, solving the conflict using the SVN command line interface won’t work, Subclipse will « remember » the conflict.

To get this working, you have to open the « Team Synchronizing » perspective in Eclipse. There, you should be able to find the .cproject file and so Mark it as resolved (and then select the option you want for the conflict solving way).

Here it is ! Subclipse will stop harassing you !

Have a nice dev’ !

Tout d’abord, il vous faudra, si ce n’est pas encore fait, installer les dépôts RPM Fusion (merci à Mezzo pour le rappel ). Ces dépôts contiennent à peu près… beaucoup de choses dont vous aurez besoin ! Notamment les pilotes graphiques pour Nvidia… etc. etc. … Bref, c’est un must-have, installons-les, pour cela, tapez les commandes suivantes dans une console (il va vous demander le mots de passe root, c’est normal vous allez installer un logiciel !) :

su -lc ‘yum install --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm‘
su -lc ‘yum install --nogpgcheck http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm‘

Si cette page est très intéressant, elle n’est cependant pas à jour. Dorénavant, Amarok sous Fedora utilise GStreamer, pour avoir les MP3 il vous faut donc installer les paquets suivants :

# yum install gstreamer-plugins-ugly gstreamer-ffmpeg

Un petit redémarrage d’Amarok peut s’imposer afin que ça fonctionne…

As usual, for international readers, the english version is below, at the end of the French version

Alors, on va encore m’accuser de publier que des billets geeks, et court pour celui-ci en plus, mais c’est tellement galère à chercher sur le net, que je ne peux m’empêcher de partager cette astuce avec vous

Passons aux choses intéressantes : Il peut être intéressant, voire indispensable (et ça vous intéressera majoritairement dans le cas où c’est indispensable, n’est-ce pas ) de pouvoir utiliser une vieille version de autoconf, notamment la fameuse 2.13, à la place votre super version hyper à jour utilisée par votre système GNU/Linux. Cependant, la question toute bête : bordel comment on fait pour dire à buildconf d’utiliser une autre version que celle par défaut du système ?

Eh bien, si vous avez passé une heure à chercher sur internet avant d’atterrir ici, vous allez être peut-être un peu déçu par la simplicité de la chose, mais bon, on n’échappe pas aux lois de Murphy ! :

export PHP_AUTOCONF=`which autoconf-2.13`

Note : ceci est l’exemple pour la compilation de PHP, pour la compilation d’un autre programme cela ressemblera très certainement à cela, je ne peux cependant pas donner de généralité !

Voilà c’est fini. Il suffit de taper cela dans votre console juste avant d’exécuter la commande « ./builconf » (ou généralement « ./buildconf –force » mais peu importe). Attention, cependant, vous devez taper cette commande et celle du buildconf dans la même console, évidemment.

J’espère que vous vous sentez soulagés Notamment si vous étiez en train d’essayer d’installer…humm… php depuis les sources ?

Merci à MaGeekGuy pour l’astuce

————————————————————————————————-

Well, I’m going to be again accused to publish only geek articles, and moreover, short, for this one, but it’s such a real pain to find that on the Internet, then I can’t resist to share it with you folks

Interesting things now : It can be useful, not to say essential (and it will interest you more in the case it’s essential, won’t it ) to be able to use an old version of autoconf, for exemple the famous 2.13, instead of your state-of-the-heart version used by default by your GNU/Linux operating system. However, what a stupid question : how the hell do you explain to buildconf that it must use an older version instead of the default one ?

Well, if you’ve just spent about an hour searching on the Internet before coming here, you may be a bit disapointed by the simplicity of the solution. But, after all, no one escape from Murphy’s laws ! :

export PHP_AUTOCONF=`which autoconf-2.13`

NB : this is an example for PHP compilation, for other soft compilation it will certainly be much like that, but I can’t exhibate a general case here.

Voilà, it’s over ! You now only need to type that in your shell just before the « ./buildconf » command (or more often « ./buildconf –force » but it doesn’t really matter). Beware, however, you must type this command in the same shell as the buildconf one, obviously.

I hope you feel distressed Specifically if you were trying to install…well… php from the sources ?

Thanks to MaGeekGuy for this tip .

Nous allons donc voir aujourd’hui comment configurer des DNS externes (ses propres DNS par exemple) pour son domaine 1&1

La procédure est assez simplissime, aussi je me suis permis de faire un tuto screenshots :

Allez sur le site de 1&1 : en cliquant ici par exemple.

Cliquez en haut à gauche sur le lien « Espace client » :

home page 1and1

Puis connectez-vous avec votre domaine pour login (sauf si vous connaissez votre identifiant client par coeur, bravo!) et votre mot de passe :

Boîte de connexion espace client 1&1

Maintenant, cliquez sur cette icône :

icones gestion des domaines

Sélectionnez le domaine dont vous souhaitez changer les DNS, puis sur « DNS » en haut :

Gestion des domaines

Maintenant cliquez sur « Modifier » :

Cliquer sur modifier

Suivez les indications dans l’odre : rentrez votre DNS externe primaire (ici nttserv.fr.nf, mon DNS) puis secondaire (spit.free-h.org le DNS secondaire de mon hébergeur).

Étapes pour rentrer vos DNS

Voilà c’est terminé, validez tout le bazar et attendez que la MàJ se fasse.

Attention, les MàJ sont non seulement plus ou moins lentes selon les extensions (le .fr par exemple doit attendre la revalidation de l’AFNIC), mais en plus votre FAI peut être lent voire très lent (comme citons Darty, Orange Nord-Pas-de-Calais (DNS de Reims de mémoire), et Numéricâble département 69 (pour ceux que je connais en tout cas) ). Darty étant le pire, jusqu’à 7 jours. Vous pouvez décider de changer les DNS de votre ordinateur si vous en avez marre d’attendre.

L’astuce est toute simple, elle consiste à tenter d’ouvrir le fichier, avec une fonction qui elle, prend en charge le HTTP :

function FichierDistantExiste($url) {
   if(!@fopen($url, 'r')) return false;
   else return true;
}

Ce fut bref, mais j’espère que cela vous sera utile

Attention par contre, sauf erreur de ma part certaines configurations PHP (notamment sur des mutualisés évidemment, mais pas tous hein) empêchent fopen() d’utiliser le HTTP. Dans ce cas, on serait bien tenté d’utiliser la fonction file_get_contents() sauf qu’en fait ce n’est qu’une espèce de raccourci pour les fonction fopen(), fgets() et fclose() les un après les autres. Donc si l’un est bridé l’autre devrait l’être aussi. À vous de tester, on ne sait jamais.

D’ailleurs, au passage, comme je suis un gentil Troll, je vous l’ai traduite

// Récupérer la date de dernière modification d'un fichier distant (la fonction retourne un timestamp unix, cf. http://wiki.pcinfo-web.com/timestamp )
function RecupDateModifDistant( $uri )
{
// default
$unixtime = 0;
$fp = fopen( $uri, "r" );
if( !$fp ) {return;}

$MetaData = stream_get_meta_data( $fp );

foreach( $MetaData['wrapper_data'] as $response )
{
// Dans le cas d'une redirection vers une autre page / un autre fichier
if( substr( strtolower($response), 0, 10 ) == 'location: ' )
{
$newUri = substr( $response, 10 );
fclose( $fp );
return RecupDateModifDistant( $newUri );
}
// Dans le cas où on a bien l'en-tête "last-modified"
elseif( substr( strtolower($response), 0, 15 ) == 'last-modified: ' )
{
$unixtime = strtotime( substr($response, 15) );
break;
}
}
fclose( $fp );
return $unixtime;
}

Voilà, pour toute demande d’explication du code, les commentaires sont là pour ça, ils vous attendent pour vous faire des calins ! (gratuit !)

Après avoir fait joujou une première fois avec les tâches planifiées sous cron gnu/linux, je vous avais promis de vous en dire plus sur les procédés et les possibilités du système de planification des tâches de GNU/Linux : cron.

Résumé de ce que vous savez déjà faire si vous avez lu la première partie sur les tâches planifiées cron :

• Créer une tâche planifiée simple qui lance un fichier exécutable avec l’utilisateur courant (celui qui a créé le cron) à l’aide la commande crontab
• Faire des tâches planifiées à exécution unique (planification non régulière/récurrente)
• (Utiliser un autre éditeur pour la commande crontab -e)

Ce que je vais vous apprendre en plus dans cet article :

• Gérer des dates complexes : Répétitions, récurrence des tâches planifiées (jokers, répétitions, sélections multiples)
• Définition d’un fichier personnalisé de tâches planifiées
• Définir une tâche exécutée par un utilisateur précis.
• Éxécuter une tâche planifiée dans un répertoire particulier.
• Éxécuter une tâche planifiée graphique.
• Gérer les sorties des commandes exécutées par CRON : logs, mails, etc.

Je vous donnerai également quelques filons pour l’utilisation de PHP avec CRON.

Retour sur la planification des tâches : la syntaxe des dates avancées avec CRON.

Je ne refais pas les explications sur les dates simples dans CRON, c’est le sujet de la première approche (dont vous avez les liens au début de cet article). Nous allons voir comment créer une tâche récurrente, à l’aide des jokers, répétitions et sélections multiples.

Le joker : *

Comme dans beaucoup d’applications informatique, le joker chez Cron est l’étoile « * ». Ainsi, si vous remplacez un quelconque paramètre d’une date par une étoile, cela signifie pour cron « quelque-soit la valeur de ce paramètre ».

Exemple : Quelque-soit le jour, je veux que à 7h05 tu dises bonjour, durant tout le mois de février :

05 07 * 02 * echo 'Hello World !'

Ici nous avons remplacé le numéro du jour dans le mois, ainsi que le jour de la semaine (qui est également susceptible de varier !) par le joker « * », ainsi, quelque-soit les valeurs de ces paramètres, si les autres paramètres (heure, minute, mois) sont vérifiés, CRON dira bonjour au monde.

La répétition : /

Le joker permet de spécifier, au maximum, une répétition toutes les unités de temps d’un paramètre précis. En effet, si je mets un joker pour l’heure, alors cela sera exécuté toutes les une heure, puisque cela sera « quelque-soit l’heure ». Ainsi, avec les jokers, vous pouvez répéter au mieux : tous les jours, toutes les heures, toutes les minutes, tous les lundis, tous les mois… Bref, pas terrible comme flexibilité tout de même. C’est à cela que sert la répétition, elle vous permet de dire tous les combien de variation d’un paramètre vous voulez que cela se répète. Une variation d’un paramètre, c’est +1 minutes, +1 heure, +1 jour, etc. …

L’opérateur de répétition s’utilise comme suit : valeur_param/intervalle_de_repetition

Ainsi, si je veux que toutes les 15 minutes, une action se répète, quelque-soit la date :

*/15 * * * * /usr/bin/monaction

On utilise ici également le joker, puisque l’action se répète quelque-soit la minute, l’heure, ou la date…

Les intervalles et les sélections multiples

Vous pouvez également définir plusieurs valeurs d’un paramètre pour lesquelles la tâche sera exécutée. On procède soit en donnant un intervalle de valeurs, soit une liste de valeurs.

Opérateur d’intervalle : -

Utilisation : borne1-borne2 ou borne1 et borne2 sont les bornes de l’intervalle ( [borne1 ; borne2] ) et incluses.

Exemple : La précédente action se répète toutes les 15 minutes, du 1er au 10 du mois

*/15 * 1-10 * * /usr/bin/monaction

Opérateur de valeurs multiples : ,

Utilisation : valeur1, valeur2, valeur3…

Exemple : La précédente action se répète toutes les 15 minutes mais seulement entre 02h et 03h puis entre 05h et 06h

*/15 2,5 * * * /usr/bin/monaction

Définir une fichier cron personnalisé : Cron en mode admin

Jusqu’à présent, vous avez utilisé la commande crontab afin de modifier votre fichier cron et d’ajouter ou de supprimer des tâches.

En réalité vous n’avez utilisé que le côté « utilisateur » de cron. La suite n’est ouverte qu’à un accès root, autrement dit l’administateur de la machine, car elle permet notamment de décider de sous quel utilisateur vont être exécutées les tâches, ce que nous verrons en même temps.

Si ce mode d’utilisation de cron n’est réservé qu’à l’administateur, c’est pour plusieurs raisons :

1. Il va permettre, comme je l’ai dit, de choisir l’utilisateur qui exécute la commande
2. Le répertoire dans lequel nous allons créer le fichier appartient à root
3. Seul root peut demander à cron de recharger les fichiers de configuration, or nous en aurons besoin car comme nous allons éditer de simples fichiers, la commande crontab ne sera pas là pour, à la fin de l’édition du fichier, dire à cron « Hey hey, ouhou, on a modifié le fichier là, viens y jeter un coup d’oeil » et par défaut cron ne verra donc pas vos modifs sans reload, et donc sans droits d’admin.

Créer votre fichier de tâches planifiées : le répertoire /etc/cron.d/

Vous êtes donc maintenant loggé en root, ou, si vous n’avez pas le su sur votre machine, vous exécuterez le reste des commandes avec un « sudo » devant.

Les fichiers de tâches planifiées sont placés dans le répertoire /etc/cron.d/, qui appartient à root.

Créons-y un fichier :

vim /etc/cron.d/monfichiercron

Voilà, tout le travail est fait… ou presque. Dans ce fichier, vous pouvez placer des tâches planifiées exactement de la même façon qu’avec la commande crontab à la différence prêt… qu’il faut spécifier l’utilisateur d’exécution !

Cela donne :

mm HH JJ MM joursemaine utilisateur /chemin/commande

Exemple, je suis l’utilisateur Troll, je veux que l’utilisateur Toto fasse le ménage dans son dossier personnel chaque semaine (vision geek du Range ta chambre ! maternel/paternel), on dira qu’on est un peu radical, si le dimanche il n’a pas vidé son dossier perso (il est censé le faire le samedi) tant pis : tout poubelle !
Note : A NE PAS TESTER CHEZ VOUS ! Vous risqueriez d’avoir de sérieux ennui ^^

01 00 * * sun toto rm -fR /home/toto/*

Bien sûr l’utilisateur peut aussi être root… But, be careful !

Ensuite, une fois que vous avez sauvegardé votre fichier, il faut dire à cron de le relire pour l’intégrer :

(encore une commande à faire en root, si vous avez bien lu le début de ce paragraphe !)
/etc/init.d/crond reload

Cron a bien rechargé s’il dit ça normalement :

Reloading crond: [ OK ]

Les autres fichiers préconfigurés de cron :

Cron a également des dossiers préconfigurés, dans lesquels il vous suffit de mettre un script (ou un lien symbolique, solution la plus souvent utilisée) exécutable.

Ces dossiers sont les suivants :

• /etc/crond.daily : exécution quotidienne (chaque jour à 4h02)
• /etc/crond.hourly : exécution chaque heure (chaque heure + 1 minute)
• /etc/crond.weekly : exécution hebdomadaire (le dimanche à 4h22)
• /etc/crond.monthly : exécution mensuelle (le 1er du mois à 4h42)

Comme je suis gentil, je vous donne même les commandes :

Création d’un script exécutable dans un dossier :
(en root encore et toujours)
vim /mon/chemin/de/fichier && chmod +x /mon/chemin/de/fichier

Création d’un lien symbolique dans /etc/crond.daily (par exemple) pointant vers /mon/chemin/de/fichier :

ln -s /mon/chemin/de/fichier /etc/crond.daily/monscript && chmod +x /etc/crond.daily/monscript

L’avantage du lien symbolique c’est que vous pouvez mettre votre script dans un dossier où vous le retrouvez et vous pouvez placer un lien dans plusieurs dossiers /etc/crond.XXX/ sans avoir à modifier tous les fichiers quand vous modifiez le script (principe du lien symbolique).

Éxécuter des tâches planifiées dans un répertoire particlier

Il peut s’avérer que vous ayiez besoin d’exécuter une commande qui va chercher des fichiers ou autres dans son répertoire courant et qui sera donc perdue si vous la lancez avec cron de la manière /chemin/commande

Pour cela, utilisez tout simplement la commande cd :

03 01 * * * tutu cd /home/tutu/scripts/ && ./macommande

Éxécution d’une tâche planifiée graphique

La console, y’a rien de mieux, ça plante pas, ça vous cache rien… Mais c’est pas très esthétique. Puis si vous voulez par exemple lancer Amarok pour vous reveiller en musique, Amarok va avoir besoin d’une interface graphique (sauf si vous connaissez une interface ligne de commande pour amarok, auquel cas je veux bien que vous partagiez l’info avec moi !).

Pour cela, procédez comme suit : placez DISPLAY=:0 après le jour de la semaine, ou après le nom d’utilisateur quand celui-ci est spécifié.

Si vous utilisez une commande composée, du type :

/chemin/premierecommande && /chemin/deuxiemecommande

(ce qui est notamment le cas lorsque vous exécutez dans un répertoire particulier) alors vous devez mettre le DISPLAY=:0 juste avant la commande qui aura besoin de l’affichage.

Gérer les sorties des commandes exécutées par CRON : logs, mails, etc.

Par défaut, notamment lors de la définition d’une tâche planifiée avec crontab -e, si votre commande génère une sortie vous devez – en théorie (désactivé sur certaines distrib’) – recevoir un « mail » ( dans /var/spool/votrelogin ) avec la sortie générée.

Ce n’est pas vraiment un mode très pratique pour logger et retrouver les sorties de vos tâches planifiées préférées.

Je vais donc vous montrer comment enregistrer dans un fichier log la sortie de vos tâches planifiées.

En fait, cela revient au même que pour enregistrer dans un fichier log une commande console standard. Cela revient à faire comme ceci :

Enregistrer tout dans monfichier.log (sortie normale + erreurs)
/chemin/macomandequigenereunesortie > monfichier.log 2>&1

Enregistrer seulement les erreurs dans monfichier.log :

/chemin/macomandequigenereunesortie > /dev/null 2> monfichier.log

Ne rien enregistrer :

/chemin/macomandequigenereunesortie > /dev/null 2>&1

Attention, tel que c’est présenté ici, chaque nouvelle exécution remplace le contenu de monfichier.log

Si vous voulez logger sur plus d’un seul lancement, vous devez créer le fichier monfichier.log avant (ce qui n’était pas nécessaire précédemment) et remplacer systématiquement dans les précédentes commandes, le « > » par « >> » (enfin presque, pas tous, regardez ci-dessous).

Ce qui donne :

/chemin/macomandequigenereunesortie >> monfichier.log 2>&1
/chemin/macomandequigenereunesortie > /dev/null 2>> monfichier.log
/chemin/macomandequigenereunesortie > /dev/null 2>&1

Annexes : Utilisation de PHP avec CRON

Pour lancer une tâche écrite en PHP avec cron, saisissez une tâche de la manière suivante :

mm HH JJ MM joursemaine [user] /usr/bin/php -f /chemin/de/fichier.php

Ou, ce qui est conseillé avec PHP, avec exécution dans un repértoire particulier :

mm HH JJ MM joursemaine [user] cd /chemin/de/ && /usr/bin/php -f ./fichier.php

Bien évidemment, vous pouvez logger dans un .log avec les .php comme avec n’importe quelle autre commande.

Voilà, c’est terminé : des remarques, des erreurs à signaler, des questions -> Les commentaires sont là pour ça ! J’espère avoir été clair et que cet article sera utile au plus grand nombre

Attention cependant, cette méthode fonctionne pour une table ne comprenant qu’un seul champs de type auto_increment et pour MySQL. Je vous laisse le soin de tester (et de nous dire ce que ça donne en laissant un petit commentaire ) et d’adapter pour d’autres situations, celle situation-ci restant la plus courante.

L’astuce est d’appeler la commande SHOW TABLE STATUS.

En effet si vous tapez par exemple cette requête SQL dans PhpMyAdmin, vous verrez apparaître plein d’informations sur toutes les tables de votre base de données courante.

Si vous souhaitez réduire les lignes à une table précise :

SHOW TABLE STATUS
LIKE 'NomDeLaTable'

Vous allez alors voir qu’une colonne est nommée Auto_increment (attention à la majuscule, importante !). Cette colonne contient la prochine valeur que prendra le champs de type auto_increment de cette table. Attention : la PROCHAINE. Si vous souhaitez connaître la dernière valeur prise par l’auto_increment il faut donc soustraire 1. Je rappelle au passage que l’utilisation de la commande MAX() ou d’un SELECT avec un ORDER BY DESC LIMIT 0,1 derrière ne fonctionnera pas car vous avez la possibilité que des lignes de la table aient été supprimées.

Si vous utilisez par exemple PHP et la fonction mysql_fetch_assoc() (ou mysql_fetch_array() pour les non-éclairés ou ceux qui ont besoin des clés numériques & textuelles), vous récupérerez alors dans votre tableau associatif cette valeur dans la clé nommée ‘Auto_increment’.

Tout d’abord, petit retour rapide sur le fonctionnement de DTC :

DTC crée un utilisateur « dtc » et un groupe « dtcgrp » avec lesquels il fait la plupart de ce qu’il a à faire. Ainsi le ftp est géré par l’utilisateur DTC, les connexions en SSH également (mais justement il y a de sacrés bugs là-dessus), les connexions imap, smtp, etc… etc… et également les connexions HTTP, et donc les lancements d’Apache2 !

Concrètement, DTC est fait pour gérer un serveur dédié et donc proposer divers hébergements à divers sites.

Il crée toute une arborescence à laquelle on adhère ou non mais qui a le mérite d’être relativement claire et facile à utiliser et retenir.

Tous les fichiers de tous les sites appartiennent ainsi à un seul et unique couple user/groupe : dtc/dtcgrp.

DTC utilise énormément le principe plus ou moins bon des chroot pour lancer ses scripts de manière à les « endiguer » et qu’ils n’aillent pas faire n’importe quoi, particulièrement sur les fichiers appartenant à DTC sur le serveur.

Cependant DTC n’a pas prévu une chose… c’est l’utilisation de la commande shell_exec() de PHP (PHP 5 notamment, je ne sais pas pour le 4).

Par défaut, le safe_mode étant activé avec PHP, la commande shell_exec est quasiment inutilisable.

Cependant, si par malheur vous désactiver le safe_mode sur un domaine particulier… catastrophe ! Vous venez d’autoriser la personne qui s’occupe du site de ce domaine, à faire n’importe quoi sur le serveur (enfin sauf tâches d’administration (root) ).

Non seulement parce-qu’elle peut maintenant utiliser shell_exec() pour effectuer des actions au niveau de l’utilisateur dtc, mais surtout parce-que, même si certaines commandes sont bridées, shell_exec() permet d’utiliser la commande crontab.

Or, crontab permet de définir des tâches cron (je vous renvoie à Google si vous ne savez pas ce que c’est : cron est un gestionnaire de tâches planifiées). Or, quand cron lance la tâche, qu’elle qu’elle soit, elle est lancée au niveau de l’utilisateur auquel le cron appartient.

Concrètement si je fais ceci :

file_put_contents('temp.cron', '* * * * * cp /chemin/dun/autre/site/includes/passwordsdatabase.inc.php /chemin/de/mon/site/');
shell_exec('crontab -u dtc /chemin/de/mon/site/temp.cron');

Hop, plus qu’à attendre une minute et j’aurais dans mes fichiers… les mots de passe de la base de données de mon voisin sur le serveur.

C’est un problème très important, donc, et je ne sais pas du tout comment DTC compte gérer les choses dans le futur puisque le safe_mode est amené à disparaîre : déjà considéré comme obsolète dans PHP 5, il sera définitivement supprimé avec PHP 6.

Il est possible que – comme souvent en informatique – GPLHost (éditeur de DTC) dise simplement « Logiciel compatible uniquement avec les versions suivantes de PHP : …. ».

En attendant, vous êtes donc maintenant au courant : NE DESACTIVEZ PAS LE SAFE_MODE PHP SI VOUS UTILISEZ DTC AVEC PLUSIEURS SITES DIFFERENTS.

Cependant, il y a certainement une alternative à cela : j’imagine bien que PHP ou Apache ont la possibilité d’interdire certaines commandes. Ainsi lorsque vous désactivez le safe_mode, pensez à interdire l’utilisation de la commande shell_exec().

Voilà c’était le bulletin sécurité (en exclu !!) du Troll

Alors aujourd’hui et comme tous les ans à Noël j’ai décidé de mettre un petit peu de nouveau, un petit détail qui met du piment dans la vie du visiteur, sur mes sites Internet. Mise à part changer – quand on a un graphiste sous la main – la bannière ou son avatar pour y rajouter des décos de Noël, quand on est plutôt tourné développement web, on fait tomber des flocons !

Le code que je vais vous proposer n’est pas de moi, mais j’y ai tout de même fait un certain nombre de modification, et notamment une qui permet de le rendre compatible avec Google Chrome et Firefox quand un doctype est présent (car cela ne fonctionnait, sous ces navigateurs, que lorsqu’il n’y avait pas de doctype ).

Ce code est à placer où vous voulez, il a été modifié de manière à attendre la fin du chargement de la page pour se lancer, pour éviter les problèmes de compatibilité des commandes faites sur document.XXX et puis tout simplement pour ne pas ralentir l’affichage de la page

Après m’être battu une bonne demi-heure avec WordPress pour gagner le droit d’insérer du code dans un post, et qui plus est, sans que celui-ci soit interprété, voici donc le code à utiliser :

Je vous remercie d’avance d’HEBERGER L’IMAGE SUR VOTRE PROPRE SITE et non de la charger depuis l’url qui est dans le script.
De toutes façons ça va planter car je vais mettre un .htaccess anti-pompage d’image

<SCRIPT type="text/javascript" >
var snowsrc='http://trollfactory.fr/img/snow.gif'; // VOUS ETES PRIE DE BIEN VOULOIR HEBERGE L'IMAGE CHEZ VOUS !
var no = 12;
var ns4up, ie4up, nn6up, doc_width, doc_height;
var dx, xp, yp;
var am, stx, sty;

document.onload=initsnow();
</SCRIPT>


Les paramètres suivantes sont modifiables :

Variable « no » : Nombre d’images / flocons qui seront affichés.
Variable « speed snow » : Sa valeur peut varier de 1 (pas 0 sinon ça risque fort de planter) à 500, mais je vous déconseille d’aller au delà de 200 ou en dessous de 10. Plus la valeur est petit, plus les flocons bougent vite (oui c’est un peu l’inverse du mot « speed », mais ça vous ira !).

Et… c’est tout Ca ne fait pas beaucoup de paramètres, mais pour faire tomber des flocons, on est quand même pas en train de paramétrer Gentoo non plus

Pour ceux qui utilisent WordPress et qui souhaiterait mettre en place cette animation sympathique (à noter que ce n’est pas du flash mais du javascript, donc compatibilité avec une grand majorité de navigateurs) je vous conseille de placer le code dans le fichier « Pied de page » (footer.php). Que vous pouvez modifier en faisant depuis votre tableau de bord : Apparence >> Editeur >> Cliquer sur « Pied de page » dans la colonne de droite.

Voilà, enjoy

Demain je vous parle (en théorie) du safe_mode de PHP utilisé avec le panel DTC (Digital Technology Control) ainsi que la création d’un principe de tâches cron léger et réellement géré en cron… mais contrôlé par PHP (ça aurait dû être aujourd’hui, mais petit contre-temps dirons-nous )

PS : Je ne connais pas l’auteur initial du script, je l’ai trouvé sur un petit site dont j’ai la certitude totale que ce n’est pas le gérant qui a créé le script, c’est pourquoi je n’ai pas cité de source