HOWTO install TWRP on a Fairphone2

… from a Linux station and with a quite clear documentation 🙂

Step 1: Prepare the phone

  1. Enable Developer options: go into Settings > About and find the Build Number and tap on it 7 times.
  2. Enable USB debugging: go to Settings > Developer Options and find the suitable option.
  3. Enable root access: go to Settings > Developer Options > Root access, and enable root access for ADB.

Step 2: Connect the Fairphone with ADB

First get ADB and Fastboot. Command line tools is sufficient, you do not need the whole Android Studio.

  1. Start abd server with sudo adb start-server
  2. Connect the Fairphone to the computer, and verify its presence with adb devices -l

Step 3: Download TWRP

Grab the last .img file from the TWRP download page for FP2. Store it somewhere on your computer (say in Downloads directory).

Rename your file from twrp-x.y.z-t-FP2.img to twrp.img.

Step 4: Install and run TWRP

  1. Reboot the phone on bootloader mode: adb reboot bootloader. The screens displays a black background with a white « Fairphone »  and « Powered by Android » at the bottom.
  2. Copy the TWRP img file: sudo fastboot flash recovery twrp.img
  3. Here is the tricky part, you’ll need at least three hands or be organized :
    • From your Linux console, type sudo fastboot reboot without hitting the Return key.
    • On the Fairphone, press Volume UP + Power (and keep it pressed until the phone reboots and you see the TWRP screen).
    • Hit the Return key.

Step 5: use TWRP

For example to make a backup or upgrade to LineageOS

 

Coloriser ses logs avec CCZE et LESS

CCZE (apt-get install ccze) permet de coloriser les logs.

Une utilisation possible:

tail -f fichier.log | ccze

Mais pour consulter un fichier de log existant avec un pager comme less, il faut sortir les options :

ccze -A <fichier.log | less -R

(attention à bien ajouter le "<" devant le nom de fichier)

OSS Talk Reactive architecture – mes notes

Voici mes notes prises en séance lors du OSS Talk Reactive Architecture du 20/10/2016.

Les slides Retour d’expérience: architecure réactive sont en ligne.

Retour d'Expériences : architectures Réactives / micro-services / Symfony

Préparation

  • Domain Driven Developpement : découper les tâches et responsabilités par domaine métier

Going Reactive

Reactive Manifesto i.e. :

  • responsive
  • resilient
  • elastic
  • message-driven /!\ les messages doivent être asynchrones

Let’s migrate

  • commençons par les briques techniques
  • ExchangeBundle (lib PHP en symfony) avec RabbitMQ dedans –> fail, ne respecte pas le Reactive Manifessto
  • Quid du format d’échange des message ? –> Canonical Data Model

Un standard pour le transport ?

Cahier des charges :

  • stateless
  • scalable
  • gérer les cas d’erreurs

–> HTTP

ApiBundle

Point reactive

Valide sur tout sauf message

Introduction du Enterprise Service Bus

ce qu’on attend de l’ESB

  • très haute dispo
  • garantie de livraison d’un message
  • doit être asynchrone i.e. message-oriented
  • support coomplet de REST et des codes d’erreurs HTTP (i.e. 404 signifie quelque chose)
  • un service locator: pour ne pas avoir à placer une adresse en dure

Chez Auchan, l’ESB est Talend ESB (aurait pu être WSO2 ou Spring-Integration ou en beaucoup plus light Apache Camel)

EOT (End Of Tranmission)

Memento gestion de paquet avec DPKG et APT

Pour Ubuntu et Debian.

Lister les paquets fournissant le fichier « monfichier »

apt-get intall apt-file
apt-file update
apt-file search "monfichier"

Lister les fichiers d’un paquet *pas* installé

Pré-requis : avoir apt-file installé et mis à jour (i.e. apt-get intall apt-file && apt-file update)

apt-file search mon-paquet-pas-installé

Lister les fichiers d’un fichier .deb *pas* installé

dpkg -c mon-fichier-pas-installé.deb

Lister les scripts pre-install / post-install d’un fichier .deb *pas* installé

dpkg -e mon-fichier-pas-installé.de

Lister les fichiers d’un paquet installé

dpkg -L mon-paquet-installé

Ressources

SuperUser : How to list files of a Debian package without install

CentOS/RHEL: kit de survie pour Debian-eux ou Ubuntu-ist

Logo CentOSContexte : Centos 7

Packages

Chercher un paquet

yum search nom-du-paquet

Lister les paquets installés

rpm -qa

Lister les fichiers d’un package installé

rpm -ql nom-du-paquet-installé

Lister les fichiers d’un paquet *pas* installé

Utiliser repoquery:

yum -y install yum-utils
repoquery -l nom-du-paquet-PAS-installé

Lister les paquets fournissant le fichier “monfichier”

yum whatprovides monfichier

 

Liens

 

 

Heures de publication des modèles Windguru

Petit mémo pour les voileux impatients de pécho la dernière météo au top avant la réunion moniteur de 8h30 🙂

On parle là de l’heure de publication, c’est-à-dire l’heure à laquelle tu peux réellement consulter le site. Il ne s’agit pas de l’heure de « run« , i.e. l’heure à laquelle le modèle a été lancé. La différence entre les deux, c’est le temps que les serveurs mettent à calculer si tu vas pouvoir bananer avec ton thermique ou pas !

Heures de publication hiver

  • 6:05 GFS run de 0:00
  • 6:30 WRF-27 run de 0:00
  • 9:00 WRF-9 run de 0:00
  • 12:05 GFS run de 6:00
  • 12:30 WRF-27 run de 6:00
  • 15:00 WRF-9 run de 6:00
  • 18:05 GFS run de 12:00
  • 18:30 WRF-27 run de 12:00
  • 21:00 WRF-9 run de 12:00
  • 0:05 j+1 GFS run de 18:00
  • 0:30 j+1 WRF-27 run de 18:00
  • 3:00 j+1 WRF-9 run de 18:00

Heures de publication été

  • 7:05 GFS run de 0:00
  • 7:30 WRF-27 run de 0:00
  • 10:00 WRF-9 run de 0:00
  • 13:05 GFS run de 6:00
  • 13:30 WRF-27 run de 6:00
  • 16:00 WRF-9 run de 6:00
  • 19:05 GFS run de 12:00
  • 19:30 WRF-27 run de 12:00
  • 22:00 WRF-9 run de 12:00
  • 1:05 j+1 GFS run de 18:00
  • 1:30 j+1 WRF-27 run de 18:00
  • 4:00 j+1 WRF-9 run de 18:00

Heures de publication (par modèle)

Modèle GFS

Run Publication UTC Publication hiver Publication été
0:00 5:05 6:05 7:05
6:00 11:05 12:05 13:05
12:00 17:05 18:05 19:05
18:00 23:05 0:05 (j+1) 1:05 (j+1)

Modèle WRF-27

Run Publication UTC Publication hiver Publication été
0:00 5:30 6:30 7:30
6:00 11:30 12:30 13:30
12:00 17:30 18:30 19:30
18:00 23:30 0:30 (j+1) 1:30 (j+1)

Modèle WRF-9

Run Publication UTC Publication hiver Publication été
0:00 8:00 9:00 10:00
6:00 14:00 15:00 16:00
12:00 20:00 21:00 22:00
18:00 02:00 (j+1) 3:00 (j+1) 4:00 (j+1)

Notes

Je suis preneur de toute correction (les horaires annoncées ne correspondent pas forcément à me souvenirs). Feel free to comment !

Certificat SSL auto-signé pour HTTPS avec OwnCloud et DAVdroid / CAdroid

J’ai un serveur Owncloud qui me sert pour synchroniser d’une part mon Thunderbird et d’autre part mon téléphone (contacts + agenda). Pour éviter de laisser circuler les mots de passe en clair sur le réseau, je mets du HTTPS avec un certificat SSL auto-signé (en attendant de jouer sérieusement avec Let’s Encrypt).

Générer un certificat auto-signé SSL

Une recette simple reprise chez Akadia pour faire un certificat auto-signé :

Depuis le serveur :

openssl genrsa -des3 -out server.key 2048
openssl req -new -key server.key -out server.csr
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Il faudra saisir une passphrase qui sera supprimée en ligne 4, et aussi quelques informations dont la plus importante est le Common Name, à savoir le nom du domaine sur lequel on veut mettre du HTTPS.

Une fois ce certificat installé (détails donnés chez Akadia), il ne reste plus qu’à l’importer dans le smartphone à l’aide de CAdroid, pour pouvoir ensuite configurer DAVdroid.

Or le certificat généré avec les commandes ci-dessus n’est pas importé par CAdroid, l’erreur affichée étant la suivante :

Copie d'écran message d'erreur CAdroid
Message d’erreur CAdroid : There’s no CA flag=TRUE in this certificate

Pistes à creuser

Rien trouvé par là.

Solution trouvée

Les instructions d’Akadia sont globalement bonnes mais incomplètes. Je les reprends et ajoute ce qu’il manquait.

Étape 1

Générer la clé RSA en 2048, générer le « CSR » et lui enlever la passphrase :

openssl genrsa -des3 -out server.key 2048
openssl req -new -key server.key -out server.csr
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key

Étape 2

Pour ajouter le flag CA:true, il faut créer un fichier, disons openssl.cnf avec comme contenu :

basicConstraints=CA:TRUE

Étape 3

Puis générer le certificat :

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt -extfile openssl.cnf

Et le tour est joué, CAdroid accepte d’importer le certificat.

Nautilus / Nemo : icône de dossier en couleur

Il est possible de changer la couleur d’un dossier dans Nautilus / Nemo (bouton de droite sur le dossier, puis cliquer sur le l’icône, et choisir un fichier d’icone).

Des icônes de couleur sont déjà sur le système dans le chemin :

/usr/share/icons/default.kde4/256x256/places

 

Coulant au chocolat à 2T

La voila, la recette du coulant à 2T. Réalisée quelques centaines de fois, il en existe quelques variantes, je commence par la version « canonique ».

Ingrédients

  • 200g de chocolat dessert,
  • 150g de beurre,
  • 5 oeufs,
  • 150g de sucre,
  • 2 cuillères à soupe de farine.

Recette du fondant / coulant au chocolat

  1. Préchauffer le four à 180°C.
  2. Au bain-marie, faire fondre les 200g de chocolat avec les 150g de beurre. Une fois le chocolat et le beurre fondus et mélangés, les extraire du bain-marie, et laisser refroidir quelques minutes.
  3. Pendant ce temps dans un grand saladier, mélanger les 5 œufs et les 150g de sucre.
  4. Ajouter le mélange beurre-chocolat aux œufs-sucre.
  5. Ajouter les 2 cuillères à soupe de farine.
  6. Verser dans un plat à cake et enfourner 17 minutes, et pas une de plus !
  7. Laisser refroidir au moins une demi-heure avant de servir.

Le résultat est franchement difficile à servir, mais les gourmands ne s’arrêteront pas à ce détail !

Explications

Tout le truc de la cuisson est de saisir l’appareil dans le four. Il doit cuire à l’extérieur mais très peu à l’intérieur, d’où le temps de cuisson à la minute près.

Le temps de cuisson justement est à adapter de plus ou moins une minute selon le four. Dans mon four « à la ville », c’est 17 minutes ; dans un vieux four au gaz de gazinière, c’est plutôt 16 minutes en diminuant un peu l’intensité du four, idem dans le four du Sunfast 32i !

Critère visuel de bonne cuisson : à la sortie du four les bords doivent être cuits donc un peu durs, mais le centre doit encore être mou voire liquide. C’est l’étape de refroidissement qui va « terminer la cuisson » et le rendre un peu plus compact. Vous n’aviez évidemment pas oublier de le laisser reposer ?!

Docker sur VPS Cloud OVH

Edit 19/10/2015 : Guide OVH installation Docker sur VPS

Après cherché un bon moment comment faire tourner Docker sur un VPS Cloud d’OVH, voici ce qui a fonctionné pour moi.

  1. Suivre la procédure d’installation Docker pour Ubuntu 14.04 (toute belle avec des packages .deb, un PPA et la dernière version de Docker)
  2. Sur le VPS, installer un noyau « classique ubuntu » en remplacement de celui customisé par OVH :
apt-get install linux-image-server
mv /etc/grub.d/06_OVHkernel /etc/grub.d/25_OVHkernel
update-grub
shutdown -r now

Pointeurs qui m’ont permis d’arriver à cela :