Générer une CSR pour une paire de clé/certificat existante via le terminal sur IOS

Cette note peut être utile si vous devez renouveler votre certificat de push ou de distribution sur Apple et que l’outil Keychain rejette la demande de création de CSR sur le certificat existant.

Le contournement est d’utiliser le terminal et les bonnes vieilles commandes classiques :

  • exporter la clé privé dans un fichier p12 : depuis l’outil keychain, faireun click droit sur la clé ou le certificat et sélectionner « exporter », on considère le p12 s’appellera ma_cle.p12
  • Basculer le p12 en pem:
    openssl pkcs12 -in ma_cle.p12 -out ma_cle.pem
  • Générer la csr:
    openssl req -new -key ma_cle.pem -out ma_cle.csr
  • et voila, il suffit d’importer la CSR sur apple developper.

Ajouter un certificat de serveur dans AWS IAM

La console IAM ne permet pas de gérer les certificats de serveur qui ont été insérés à la volée dans IAM via l’ELB. Il faut donc passer par l’API :

(une fois les pré-requis de l’API installés), exécutez:

aws iam upload-server-certificate --server-certificate-name mon.serveur.com.2017 --certificate-body file:///home/cve/ssl/serveur_crt.pem --certificate-chain file:///home/cve/ssl/cert_chain.pem --private-key file:///home/cve/ssl/serveur_key.pem

Ensuite vous retrouvez votre nouveau certificat dans la liste des certificats IAM sur la page de mise à jour du certificat de l’ELB.

Tracer la latence avec NGINX

Extracted from nginx blog, article from Rick Nelson · January 7, 2016


Using the NGINX Built-In Timing Variables

NGINX provides a number of built-in timing variables that you can include in log entries. All are measured in seconds with millisecond resolution.

  • $request_time – Full request time, starting when NGINX reads the first byte from the client and ending when NGINX sends the last byte of the response body
  • $upstream_connect_time – Time spent establishing a connection with an upstream server
  • $upstream_header_time – Time between establishing a connection to an upstream server and receiving the first byte of the response header
  • $upstream_response_time – Time between establishing a connection to an upstream server and receiving the last byte of the response body

Here is a sample log format called apm that includes these four NGINX timing variables along with some other useful information:

log_format apm '"$time_local" client=$remote_addr '
               'method=$request_method request="$request" '
               'request_length=$request_length '
               'status=$status bytes_sent=$bytes_sent '
               'body_bytes_sent=$body_bytes_sent '
               'referer=$http_referer '
               'user_agent="$http_user_agent" '
               'upstream_addr=$upstream_addr '
               'upstream_status=$upstream_status '
               'request_time=$request_time '
               'upstream_response_time=$upstream_response_time '
               'upstream_connect_time=$upstream_connect_time '
               'upstream_header_time=$upstream_header_time';

 

Using Application-Defined Timing Values

To drill down, we capture timings in the application itself and include them as response headers, which NGINX then captures in its access log. How granular you want to get is up to you.

To continue with our example, we have the application return the following response headers which record processing time for the indicated internal operations:

  • db_read_time – Database lookup
  • db_write_time – Database write
  • analysis_time – Data analysis
  • other_time – All other types of processing

NGINX captures the timing values from the response headers by creating corresponding variables, which it names by prepending the string $upstream_http_ to the header name (for example, $upstream_http_db_read_time corresponds to db_read_time). You can then include the variables in log entries just like standard NGINX variables.

Here is the previous sample log format extended to include the application header values:

log_format apm 'timestamp="$time_local" client=$remote_addr '
               'request="$request" request_length=$request_length '
               'bytes_sent=$bytes_sent '
               'body_bytes_sent=$body_bytes_sent '
               'referer=$http_referer '
               'user_agent="$http_user_agent" '
               'upstream_addr=$upstream_addr '
               'upstream_status=$upstream_status '
               'request_time=$request_time '
               'upstream_response_time=$upstream_response_time '
               'upstream_connect_time=$upstream_connect_time '
               'upstream_header_time=$upstream_header_time '
               'app_db_read_time=$upstream_http_db_read_time '
               'app_db_write_time=$upstream_http_db_write_time '
               'app_analysis_time=$upstream_http_analysis_time '
               'app_other_time=$upstream_http_other_time ';

Format d’image avec compression lossless

Sur le papier le meilleur format d’image avec compression lossless semble être FLIF:

http://flif.info/

FLIF a aussi l’avantage d’être libre de droit (dixit leur site).

Le format BPG est un peu moins bon au vue des comparatifs :

http://cloudinary.com/blog/flif_the_new_lossless_image_format_that_outperforms_png_webp_and_bpg

Il reste une bonne option bien que susceptible de tomber sous licence dans certains pays à cause du HEVC :

https://bellard.org/bpg/

 

 

Drawing ASCII dans le message de bienvenue d’une debian

Le fichier /etc/motd est bien pratique pour customiser le message de bienvenue et éviter de se mélanger les pinceaux lorsque l’on administre un petit lot de serveur.

L’outil Figlet permet de faire un drawing ASCII en une ligne de commande :

$ figlet Mon-Serveur

l’option -f permet de choisir le style de la police utilisée. Ajoutez les polices « contrib » si vous voulez avoir du choix.

Résolution des liens symboliques avec Xdebug

Dans une configuration Xdebug + IDE (eclipse, phpStorm…) si vous commencez à avoir des liens symboliques, l’IDE ou xdebug commence à perdre les pédales sur la résolution des chemins ce qui fait que les breakpoints de l’IDE ne sont plus détectés.

Voici une technique pour continuer à utiliser le principe de lien symbolique et à utiliser xdebug :

  • vérifier que xdebug fonctionne bien : activer l’arret sur la première ligne de code dans l’IDE
  • vérifier que les mapping serveur sont corrects (dans la config du serveur dans l’IDE)
  • supprimer le lien symbolique et créer un bind (on perd en lisibilité mais ça réalise la même fonction à un niveau un peu plus bas).

Imaginons que le lien symbolique était dans le répertoire /opt/mon_projet/trunk/src/ avec cette résolution:

web -> /opt/mon_projet/trunk/skins/skin_1/web/

Avec un bind il suffit de faire ceci:

 cd /opt/mon_projet/trunk/src/
 mkdir web
 mount -B /opt/mon_projet/trunk/skins/skin_1/web/ web

Un tutoriel sur Gulp pour comprendre les dépendances, l’utilisation de tâches asynchrones ou synchrones

J’ai pris de le temps de faire ce tutoriel car je vois trop souvent des incompréhensions sur ces notions de tâches synchrones et asynchrones. En complément je rappelle le principe de dépendances dans gulp. Les dépendances ne sont pas ordonnées, seul la fin de la tâche déclenche l’exécution de la suivante, il faut donc s’assurer que les fins tâches sont déclenchées seulement lorsqu’elles sont effectivement terminés. Ceci amène à la notion de barrière et de promesses (je n’ai pas détaillé les promesses ici, les docs ne manquent pas sur ce sujet).

Au niveau dépendances

Les logs de ‘un’ se mixe avec ‘trois’ en asynchrone (c’est que l’on cherche) mais ‘deux’ ne se lance bien qu’après la fin de ‘trois’.

Mise en œuvre d’une barrière pour gérer correctement les fins de tâches asynchronesIl n’y a pas besoin de mettre en place de section critique en js, chaque fonction possède son propre contexte, donc la barrière qui gère la fin de l’ensemble des process est plutôt simple à mettre en œuvre.

Au niveau perf

En asynchrone je boucle la tâche ‘quatre’ en 3,6 secondes alors qu’en synchrone elle se boucle en 4,4 secondes. Cela commence à faire beaucoup sur si peu d’itérations.

Le code

J’ai commenté en anglais histoire de partager un peu.

var child_process = require('child_process');


function execScriptAsync(script, cb) {
//	var _script=script;
//	var _cb=cb;
    //this function is triggered on script is completed
	function onCompleted(error, stdout, stderr){
		if (error) {
        	console.log("Error on script: "+script+ " error = "+error);
        } else {
            console.log("Execution completed on : "+script);
		    console.log("   stdout: "+stdout);
	        if (stderr) console.log("   stderr: "+stderr);
		}
	    if (cb) {
	        cb(error);
	    }
	} 
	console.log("Executing script : "+script);
	child_process.exec(script, onCompleted);
};

var runnerAsync = function (name, iteration, cb) {
    var i=0;
    var j=iteration;
    // this function is used as a barrier, once all process are completed, trigger the callback so the task will be ended properly.
    var wait = function() {
        j--;
        console.log("   Remaining '"+name+"' process="+j);
        if (j==0) {
            // do not forget to call the callback, gulp is using this to trigger the task ended
            cb();
        }
    }
    for (i=0; i<iteration; i++) {
        execScriptAsync('echo '+name, wait);
        //we are reaching this code even if the echo command is not ended, so we can have several echo called simultaneously
        // the number of echo in parallel depends on how many process can be started simultaneously on the box
    }
    // do not call the callback here otherwise you will have the task completed while 'echo' cmd are still running
};

var runnerSync = function (name, iteration, cb) {
    for (var i=0; i<iteration; i++) {
        var echo = child_process.spawnSync('echo', [name], {shell: true});
        //we are reaching this code only once the echo command is ended
        if (echo && echo.stdout) {
            console.log('stdout: '+echo.stdout);
        }
    }
    cb();
};

// switch from runnerSync to runnerAsync this to see the difference between synchronous and asynchronous
var runner=runnerAsync; // runnerAsync;

gulp.task('one', function(cb) {
    runner('one', 100, cb);
});

gulp.task('two', ['three'],function(cb) {
    runner('two', 100, cb);
});

gulp.task('three', function(cb) {
    runner('three', 100, cb);
});

var Q = require('q');
// keep start time of gulp
var startTime=new Date();
// here we can see dependencies behavior, 'two' should be triggered before 'three', but 'two' depends on 'three' so 'three' comes first.
gulp.task('four', ['one', 'two', 'three'], function() {
    //in this task, I'm using a promise which is a better way to handle async process response
    //(with gulp it is not simple to add functional rules between tasks, everything rely on dependencies)
    var deferred = Q.defer();
    var cb=function(data){
        var end=new Date();
        var elapsed=end.getTime() - startTime.getTime();
        console.log("Total time elapsed="+elapsed+' ms');
        // resolve the task 'four'
        deferred.resolve();
    }
    // start processes
    runner('four', 100, cb);
    // return the promise so gulp will be able to process the task completion properly
    return deferred.promise;
});


Problème GTK sur Eclipse-Neon2 avec une Lubuntu

Version ubuntu:

Distributor ID:	Ubuntu
Description:	Ubuntu 16.10
Release:	16.10
Codename:	yakkety

Cas de la perte des icônes de base et message d’erreur au lancement

Si les messages sont du type:

(Eclipse:14401): Gtk-WARNING **: Theme parsing error: gtk-lubuntu.css:309:15: The 'icon-shadow' property has been renamed to '-gtk-icon-shadow'
(Eclipse:14401): GLib-CRITICAL **: g_base64_encode_step: assertion 'in != NULL' failed

Créer le script sh suivant :

#!/bin/bash
export GDK_BACKEND=x11
export SWT_GTK3=0
ECLIPSE_PATH=`dirname "$(readlink -f "$0")"`
echo $ECLIPSE_PATH
$ECLIPSE_PATH/eclipse

puis lancer eclipse via ce script.

Cas d’une exception

Si eclipse plante complètement avec ce message :

Exception in thread "DLTK indexing" java.lang.ExceptionInInitializerError
	at org.eclipse.dltk.internal.core.index.lucene.LuceneIndexer.getDocuments(LuceneIndexer.java:104)
	at org.eclipse.dltk.internal.core.index2.AbstractIndexRequest.analyzeSourceModuleChanges(AbstractIndexRequest.java:124)
	at org.eclipse.dltk.internal.core.index2.SourceModulesRequest.run(SourceModulesRequest.java:64)
	at org.eclipse.dltk.core.search.indexing.AbstractJob.execute(AbstractJob.java:80)
	at org.eclipse.dltk.internal.core.search.processing.JobManager.run(JobManager.java:482)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
	at org.eclipse.dltk.internal.core.index.lucene.LuceneManager.<init>(LuceneManager.java:212)
	at org.eclipse.dltk.internal.core.index.lucene.LuceneManager.<clinit>(LuceneManager.java:74)
	... 6 more

Dans ce cas il faut supprimer le workspace et le recréer.

Problème de clavier avec Synergy entre un serveur window et un client Linux.

Si vous avez un problème de mauvais mapping de votre clavier sur le client Linux, vous pouvez essayer de forcer le mapping du client linux avec cette commande (il faut que le client soit connecté) :

Depuis une console sur le client linux:

 setxkbmap fr

nb: il y a aussi une autre façon de faire via le fichier de conf du serveur mais il faut que je remette la main dessus.