Cloner tous les repos d’une organisation sur Github

Je cherchais un moyen rapide de cloner tous les repos publics d’une organisation sur Github. D’autres se sont bien sûr posés la question mais les solutions proposées m’ont toutes semblées trop complexes / tordues.

Résultat, j’ai fait la mienne :

bash -x <(curl -s "https://api.github.com/orgs/alphagov/repos" | jq -r '.[].git_url | "git clone " + sub("git://"; "https://")')

L’organisation est ici alphagov, à remplacer évidemment.

Il y a trois étapes :

  1. curl -s "https://api.github.com/orgs/alphagov/repos" récupère la liste des repos de l’organisation au format JSON. Il y a pas mal d’informations dedans (toutes les URLs, nombre de forks, de watchers, etc.).
  2. On passe à jq, un outil (très puissant) en ligne de commande pour parser du JSON qui a son propre langage.
    1. .[].git_url indique de conserver uniquement l’URL du repo. Ce qui donne :
      $ curl -s "https://api.github.com/orgs/alphagov/repos" | jq -r '.[].git_url'
      git://github.com/alphagov/static.git
      git://github.com/alphagov/slimmer.git
      (...)
      
    2. sub("git://"; "https://") permet ainsi de remplacer les git:// par des https:// car je ne suis pas authentifié sur Github. Ce qui donne :
      $ curl -s "https://api.github.com/orgs/alphagov/repos" | jq -r '.[].git_url | "git clone " + sub("git://"; "https://")'
      git clone https://github.com/alphagov/static.git
      git clone https://github.com/alphagov/slimmer.git
      (...)
      
  3. Le tout est envoyé en entrée à bash qui va exécuter les commandes et cloner tous les répertoires !

Bonus : Pourquoi alphagov ? Car c’est une très bonne source d’inspiration tant en Ruby (la plupart sont des applications Rails) qu’en Puppet et en Terraform (ici et ici).

Installer Terraform avec Homebrew et chtf

Yleisradio propose sur Github un utilitaire dénommé chtf pour gérer plusieurs versions de Terraform, un peu à la façon de RVM. Il est fourni à travers une formule + un repo Homebrew.

Installation de chtf

On commence par ajouter le repository :

brew tap Yleisradio/terraforms

Installation proprement dite de chtf :

brew install chtf

Sortie :

Add the following to the ~/.bashrc or ~/.zshrc file:

    source /usr/local/opt/chtf/share/chtf/chtf.sh

Then you can choose (and automatically install) a specified Terraform
version, e.g.:

    chtf 0.6.8

A ajouter dans son .bash_profile :

[[ -s "/usr/local/share/chtf/chtf.sh" ]] && source "/usr/local/share/chtf/chtf.sh"

Utilisation

Pour lister les versions disponibles :

chtf_install

Sortie :

chtf: Installing Terraform version 
Error: Cask 'terraform-' is unavailable: No Cask with this name exists. Did you mean one of these?
terraform-0.10.0           terraform-0.10.0-rc1       terraform-0.10.3           terraform-0.10.6           terraform-0.11.0-beta1     terraform-0.6.12           terraform-0.6.14+cf
terraform-0.10.0-beta1     terraform-0.10.1           terraform-0.10.4           terraform-0.10.7           terraform-0.6.10           terraform-0.6.13           terraform-0.6.15
terraform-0.10.0-beta2     terraform-0.10.2           terraform-0.10.5           terraform-0.10.8           terraform-0.6.11           terraform-0.6.14

Ne reste plus qu’à en installer une, ici la dernière en date :

chtf_install 0.10.8
chtf: Installing Terraform version 0.10.8
==> Satisfying dependencies
==> Downloading https://releases.hashicorp.com/terraform/0.10.8/terraform_0.10.8_darwin_amd64.zip
######################################################################## 100,0%
==> Verifying checksum for Cask terraform-0.10.8
==> Installing Cask terraform-0.10.8
==> Extracting nested container terraform
🍺  terraform-0.10.8 was successfully installed!

La commande chtf retourne les versions installées :

$ chtf
 * 0.10.8
   0.6.15

Le choix se fait avec chtf_use [la version] :

chtf_use 0.10.8

Démonstration :

$ chtf_use 0.10.8 && terraform version
Terraform v0.10.8

$ chtf_use 0.6.15 && terraform version
Terraform v0.6.15

Your version of Terraform is out of date! The latest version
is 0.10.8. You can update by downloading from www.terraform.io

Attention : contrairement à RVM, il n’y a pas de version par défaut de Terraform. Si on ouvre un nouveau shell, il faut refaire un chtf_use sinon la commande n’existe pas.

Voir le changelog d’un package avec DNF (Fedora)

Pour voir le changelog (nouveautés) d’un package sous Fedora 22+ :

dnf updateinfo --info --refresh [nom du package]

Exemple avec libreoffice-core :

$ dnf updateinfo --info --refresh libreoffice-core
===============================================================================
  libreoffice-5.3.6.1-4.fc26
===============================================================================
ID de mise à jour : FEDORA-2017-76f5e02c37
             Type : correction d’anomalie
      Mis à jour  : 2017-09-09 22:54:31
      Description : - tdf#110737 animations starved of redraw events in dual head mode
                  : - fix redraw of embedded calc in writer

L’argument --refresh force DNF à récupérer les informations sur le repo (dnf update ne le fait pas).

Remplacer --info par --list pour avoir quelque chose de plus synthétique :

$ dnf updateinfo --list --refresh libreoffice-core
FEDORA-2017-76f5e02c37 correction d’anomalie libreoffice-core-1:5.3.6.1-4.fc26.x86_64

A noter que le package yum-changelog est toujours proposé dans les repos Fedora 26 mais que son installation n’est pas nécessaire, updateinfo fait parti intégrante de dnf.

epp(): Invalid EPP: This Variable has no effect. A value was produced and then forgotten

Contexte : Puppet 5.1.0, template au format EPP

Message d’erreur à l’exécution :

Error: Evaluation Error: Error while evaluating a Function Call, epp(): Invalid EPP: This Variable has no effect. A value was produced and then forgotten (one or more preceding expressions may have the wrong form) at /opt/puppetlabs/puppet/modules/monitoring/templates/mongodb.epp:11:98

Cette erreur cryptique indique qu’une variable dans le template EPP ne sert pas.

Exemple :

<% $user %>

$user n’est ni affichée (ce serait ), ni dans une condition ni utilisée pour une boucle.

La plupart du temps, c’est afficher la variable que l’on souhaite, ne manque donc que le = :

<%= $user %>

Puppet : Autorise %wheel à passer root sans mot de passe

Puppet offre plusieurs façons de manipuler /etc/sudoers : en remplaçant le fichier entier (via une ressource file), en éditant ou en ajoutant une ligne précise (via file_line) ou via la ressource augeas.

Méconnu, augeas est un utilitaire – non lié à Puppet – permettant de manipuler un grand nombre de types de fichiers avec une syntaxe similaire à https://fr.wikipedia.org/wiki/XPathXPath. Contrairement à file et file_line, il a l’immense avantage de ne pas provoquer d’erreur de syntaxe.

Voici ce que cela donne pour éditer /etc/sudoers :

augeas { 'sudoers-wheel-nopasswd':
  incl    => '/etc/sudoers',
  lens    => 'Sudoers.lns',
  changes => 'set spec[user=\'%wheel\']/host_group/command/tag NOPASSWD',
  require => Package['augeas'],
}

Requière d’installer préalablement le package augeas :

if ! defined(Package['augeas']) {
  package { 'augeas': ensure => present, }
}

A noter qu’il existe un module tout fait pour éditer sudoers : saz/puppet-sudo, lequel s’appuie sur Augeas.

Cyberduck : Désactiver les notifications Bonjour

Le client FTP/SFTP/WebDav Cyberduck (pour Mac uniquement) a cette fâcheuse manie d’afficher une notification à chaque fois qu’un ordinateur avec Bonjour activé est détecté. A la longue, cela devient pénible en entreprise (beaucoup de postes) avec des notifications sans arrêt.

notifications

Pour désactiver ce comportement, pas d’option dans les préférences, la seule solution est de passer par la ligne de commande :

defaults write ch.sudo.cyberduck rendezvous.enable false

Relancer ensuite Cyberduck.

Source : https://this-is-useful.blogspot.fr/2010/08/disable-bonjour-in-cyberduck.html

Source de l’image : https://groups.google.com/forum/#!topic/cyberduck/12CYvKR7M34

Nettoyer les sessions Gitlab < 7.3 dans la base Redis

Prior to GitLab 7.3, user sessions did not automatically expire from Redis. If you have been running a large GitLab server (thousands of users) since before GitLab 7.3 we recommend cleaning up stale sessions to compact the Redis database after you upgrade to GitLab 7.3.

Les versions de Gitlab entre la 6.2 et la 7.2 stockent leurs sessions dans une base Redis sans définir de date d’expiration. Conséquence : celles-ci vont s’accumuler au fil du temps sans aucun intérêt.

La documentation de Gitlab donne deux commandes :

# Voir toutes les sessions stockées dans Redis
redis-cli keys '*' | grep '^[a-f0-9]\{32\}$' | wc -l

# Faire expirer toutes les sessions dans dix minutes
redis-cli keys '*' | grep '^[a-f0-9]\{32\}$' | awk '{ print "expire", $0, 600 }' | redis-cli

La commande ci-dessus pose un problème : à chaque exécution, il repositionne la date d’expiration à 600 secondes. Et ce, même si la session allait expirée avant ! Impossible donc de l’exécuter telle quelle via une tâche cron.

Voici un script shell conçu pour être exécuté via cron. Il s’inspire de celui la documentation mais ignore toutes les sessions qui ont déjà une date d’expiration et définit pour les autres une échéance à +1 heure :

#!/bin/sh
#
# Avant Gitlab 7.3, les sessions ne possèdent pas de date d'expiration.
#
# Cela a pour conséquence une augmentation progressive de la base Redis
# sans aucune plus-value.
#
# Ce script se charge de définir une date d'expiration pour toutes les sessions
# dont le nom est formaté sous la forme de 32 caractères hexadécimales
#
# Le script fournit sur la documentation de Gitlab propose une expiration d'un quart
# d'heure, ce qui me semble trop court, le délai ici est donc d'une heure.
#
# Source :
# https://docs.gitlab.com/ce/administration/operations/cleaning_up_redis_sessions.sh
#

# Durée d'une session en secondes
SESSION_EXPIRE="3600"

rcli="$(command -v redis-cli)"

# Pour voir le nombre de sessions dans la base
# $rcli keys '*' | grep '^[a-f0-9]\{32\}$' | wc -l

# Expiration au bout d'une heure - 3600 secondes
$rcli keys '*' | grep '^[a-f0-9]\{32\}$' | while read LINE
do
  # Identifiant de la session
  key_id="$(echo $LINE | awk '{ print $0 }')"

  # Récupération de la date d'échéance correspondante
  key_ttl="$($rcli ttl $key_id)"

  # On ne prend que les sessions dont le TTL est -1 (= pas d'expiration)
  test "${key_ttl}" = -1 || continue

  echo "$key_id = $key_ttl"

  # Définit une date d'expiration
  $rcli expire "${key_id}" "${SESSION_EXPIRE}"
done

L’idéal étant évidemment de passer à une version plus récente de Gitlab 🙂