Quand on joue avec des bases de données, il n’est pas rare de tout exploser. D’où l’importance de bien sauvegarder et de savoir restaurer.

Ici, on travaille avec slapd (OpenLDAP) sous Debian GNU/Linux.

La configuration du serveur est stockée sous forme de fichiers ldif dans /etc/ldap/slapd.d.

Je parle surtout d’un cas simple avec une seule base. S’il y a plus d’une base, il suffit d’adapter ce qui se fait là après avoir lu ça.

Sauvegarde:

# slapcat -b cn=config -l /var/backups/ldap/config.ldif # config
# slapcat -l /var/backups/ldap/data.ldif                # données

Restauration:

On commence par couper le serveur:

/etc/init.d/slapd stop

la config:

On fait le ménage:

rm -rf /etc/ldap/slapd.d
mkdir /etc/ldap/slapd.d

On restaure:

slapadd -F /etc/ldap/slapd.d -b cn=config -l /var/backups/ldap/config.ldif

Et on oublie pas les droits:

chown -R openldap:openldap /etc/ldap/slapd.d

Les données:

Même procédé.

Ménage:

rm -rf /var/lib/ldap
mkdir /var/lib/ldap

Restauration:

slapadd -F /etc/ldap/slapd.d -b $ROOTDN -l /var/backups/ldap/data.ldif

Et les droits:

chown -R openldap:openldap /var/lib/ldap

Et quand on a tout fini, on redémarre le daemon:

/etc/init.d/slapd start

Quelques notes en vrac:

Si on utilise du SSL/TLS avec slapd:

• il ne faut pas oublier de sauvegarder les certificats ;
• de mettre l’utilisateur openldap dans le group ssl-cert.

Si on utilise sasl et ldap, il faut aussi mettre l’utilisateur openldap dans le groupe sasl.

Original post of Guillaume Vaillant.Votez pour ce billet sur Planet Libre.

Dans un précédent article (ici), je proposais une méthode pour renouveler les certificats Letsencrypt en l'absence d'un mécanisme officiel pour le moment. Dans cette méthode (enfin ce script), je vérifiais la date du certificat avec "date -r", extrapolant la date de fin de validité à l'aide de la date de création du certificat et de la connaissance de la durée de validité par défaut des certificats de Letsencrypt.

Il y a en fait beaucoup plus intelligent ! Merci à mon beau-frère pour cette idée (toujours écouter au moins d'une oreille son beau-frère !)

Le manuel d'OpenSSL nous apprend l'existence de l'option suivante :

-checkend arg
checks if the certificate expires within the next arg seconds and exits non-zero if yes it will expire or zero if not.

Dès lors, il est facile de détecter si un certificat périme dans les 30 jours (2 592 000 secondes) :

if openssl x509 -checkend 2592000 -noout -in file.pem
then
  echo "Certificat valide encore au moins 30 jours"
else
  echo "Certificat périmant dans les 30 jours... à renouveler !"
fi

Original post of Pierre-Alain Bandinelli.Votez pour ce billet sur Planet Libre.

Neovim est un fork de Vim né il y a environ 2 ans et dont les premières versions publiques ont été mises à disposition à la fin de l'année dernière. Je suis un fervent utilisateur de Vim depuis... pfffiou une quinzaine d'année mais je trouve ce fork plutôt appropriée avec de bonnes idées. Par exemple Neovim permet d'éxécuter des tâches de manière asynchrone dans les plugins, j'aurais adoré avoir cette fonctionnalités quand je développais le plugin eZVim pour eZ Publish il y a quelques années.

Installation

L'installation de Neovim est bien détaillée dans Installing Neovim. Sur une Ubuntu (postérieure à 12.04 Precise Pangolin), pour l'installer, il suffit d'activer le PPA correspondant et ensuite d'installer le paquet neovim. En fonction des plugins, il sera peut-être nécessaire d'installer quelques paquets liés à Python. Cette même page propose également de configurer le système d'alternatives pour lancer Neovim avec les commandes vim, vi et editor, sinon il faudra impérativement utiliser nvim.

Configuration

Le fichier de configuration principal ~/.vimrc est remplacé par ~/.config/nvim/init.vim et le dossier ~/.vim est remplacé par ~/.config/nvim/. La documentation pour passer de Vim à Neovim conseille de faire des liens symboliques. Pour ma part, j'ai préfèré profiter de l'occasion pour remettre à plat ma configuration un peu vieillissante au niveau des plugins et pour notamment remplacer Pathogen par vim-plug.

Les différences entre Vim et Neovim sont bien documentées et au final, le changement s'est fait sans grosse difficulté avec 2 adaptations relativement mineures :

• La valeur par défaut de mouse est maintenant a mais je n'utilise quasiment jamais la souris dans mon éditeur et je préfère garder le fonctionnement du terminal intact, j'ai donc ajouté set mouse= à mon .vimrc euh init.vim ;-)
• dans les plugins que j'utilisais avec Vim, seul Powerline n'est pas compatible avec Neovim, heureusement vim-airline fournit une alternative fonctionnelle et compatible avec Neovim.

Pour le reste quasi rien n'a changé, ou alors je n'ai pas encore remarqué ;-)

Et alors ça marche ?

Neovim fonctionne très bien pour moi, je l'ai adopté depuis une petite semaine et jusqu'à présent je n'ai noté aucun problème dans mon usage relativement intensif en tant qu'IDE au bureau, dans l'édition de divers fichiers ou lors de la rédaction de ce billet. Bref, Neovim a l'air bien installé sur ma machine et il va maintenant falloir aller fouiller dans les quelques plugins qui tirent partie de Neovim et refaire le tour des plugins Vim compatibles qui valent le coup.

Original post of Damien Pobel.Votez pour ce billet sur Planet Libre.

Un petit retour sur les quelques expériences que j’ai eu lors d’échanges avec des développeurs.
Ce billet fera suite à celui sur le maillon manquant mais en l’étendant à la plupart des projets.

Comme il est souvent dit à propos de comment contribuer pour les projets libres autrement qu’en codant, un élément important est de tester afin de découvrir des bugs ou faire des sujetions d’amélioration à l’équipe de développement. Je ne prendrai pas de cas particulier mais il m’est arrivé parfois de signaler des problèmes ou de proposer de nouvelles fonctionnalités et je vais tenter de vous décrire comment j’ai vécu la chose.

D’abord, il faut avouer que souvent le premier retour est plutôt positif, "merci de l’intérêt pour notre projet" et je n’ai jamais eu de fin de non recevoir mais la seconde partie est souvent beaucoup plus mitigée. Si on propose une fonctionnalité sur un logiciel dont l’auteur est sur autre chose, il nous invite gentiment à le faire par nous-même, j’aurais parfois bien aimé mais même si j’ai déjà écrit du code dans une autre vie (et d’autres technologies), j’ai vite perçu mes limites et cela ne m’intéresse plus.

Une autre réaction que j’ai déjà eu, c’est "ah oui, cette idée là est sympa, je la prendrai en compte pour les futurs développement (cool), par contre, cette idée là, non, il n’y a aucun intérêt de pouvoir faire comme on veut, tout le monde doit faire comme j’ai choisi" alors que la fonction existait ou existe sur d’autres applications. Et c’est là où l’on se dit que le développeur dicte un peu la façon dont il veut que l’utilisateur se comporte.

Pour ce qui est des bugs, c’est souvent pire. Lorsque l’on fait un gentil mail, la première chose que l’on nous dit, c’est qu’il faut passer par le tracker, le forum ou tout autre outil que le projet a choisi. Bon, gentiment, on va donc s’inscrire sur le truc en question, on doit souvent faire des manip supplémentaires pour récupérer les logs, passe encore (mais pas à la portée de tout le monde en général) et après, on apprend que le bug est, soit déjà répertorié, non fondé ou, bien souvent, dû à l’architecture/l’environnement sur lesquels on tourne. Bref, cela ne marche pas mais ce n’est pas la faute du projet, donc à nous de changer de machine ou de remonter le bug au niveau de l’environnement ou de la distro.

Le dernier cas, c’est que le problème rencontré est gentiment ignoré. Sans doute le plus frustrant.

Bref, la plupart de mes tentatives se sont avérées peu probantes et j’y vois principalement deux problèmes :

• les systèmes de report de bug sont souvent imbitables. Qu’ils soient utiles aux développeurs pour hiérarchiser les priorités et voir où en sont les résolutions, j’en suis persuadé mais pour l’utilisateur quelconque, c’est quelque chose de totalement incompréhensible, souvent en anglais, avec un classement totalement obscur pour quelqu’un qui ne connaît pas le projet, avec toutes les chances de ne pas décrire correctement le bug ou de faire des doublons.
• un manque de rapport direct avec quelqu’un qui connaît le projet, est au courant des problèmes connus, peut aider à mieux définir le problème et faire un minimum de retour sur la possibilité ou non de faire avancer le problème.

Et à ces problèmes, je répète ce que j’ai déjà dit à ce sujet sur le projet Firefox OS (Monsieur BORNE, je vous entends ricaner au fond de la classe), il manque un maillon : l’humain qui fait interface entre l’aspect technique et les utilisateurs, qui est capable de gérer les rapports de bug à partir de n’importe quel échange (téléphone, mail, irc, forum ou réseaux sociaux), qui peut dire : ça c’est dans les tuyaux, ça c’est connu, ça ce n’est pas possible ou ça c’est une bonne idée.

Souvent, c’est le cas lorsque les projets sont petits et reposent sur une seule personne et c’est là où je rejoins Cyrille qui a besoin de ce contact humain et direct et qui justement ne fait des retours et de contributions que pour ce genre de projets.
Mais pourquoi n’est-ce plus possible lorsqu’un projet grandit ? Forcément, cela demande de la communication avec les différents développeurs et d’être disponible pour les utilisateurs, d’être capable de se mettre à leur niveau et comprendre leurs problèmes ou besoins. Bref, faire du réseau social quoi !
Ah bon ça veut dire autre chose que mâter des vidéos de chat et s’étriper pour savoir qui est le plus fâcho ?

Original post of alterlibriste.Votez pour ce billet sur Planet Libre.

Depuis un an et demi que nous tenons le blog Raspbian France, nous avons eu l’occasion de recevoir de nombreux mail d’utilisateurs se posant des questions sur des sujets très divers.

Parmi toutes ces questions, le fait de savoir comment prendre le contrôle de la Raspberry Pi à distance revient très fréquemment !

Alors, vous avez achetez et installer votre Raspberry Pi (si ce n’est pas encore fait, qu’attendez-des vous ? Foncez !) mais vous n’avez pas d’écran et vous souhaitez la contrôler depuis votre ordinateur ? Pas de panique, nous allons vous aider !

 

SSH c’est quoi ?

Avant de voir comment contrôler la Raspberry Pi avec SSH, voyons exactement ce qu’est SSH.

SSH (pour Secure SHell) désigne à la fois un logiciel et un protocole de communication informatique. Ce protocole possède par ailleurs la particularité d’être entièrement chiffré. Cela signifie donc que toutes les commandes que vous exécuterez via SSH seront totalement secrètes !

SSH a été créé en 1995 avec pour principale but de permettre la prise de contrôle à distance d’une machine à travers une interface en ligne de commande.

Aujourd’hui, SSH est principalement utilisé à travers l’implémentation libre OpenSSH qui est présent dans la plupart des distributions Linux.

 

Comment fonctionne SSH ?

Nous ne rentrerons pas ici dans les détails cryptographique et autres. Nous nous contenterons de faire un rapide tour d’horizon afin que vous saisissiez un peu mieux comment utiliser SSH.

De façon générale, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine.

Pour cela, l’ordinateur qui doit se connecter à la machine distante va fournir à celle-ci le nom de l’utilisateur à utiliser et son mot de passe. Il est possible dans certains cas d’utiliser un jeu de certificats sur l’ordinateur et la machine distante, permettant ainsi d’obtenir une connexion sécurisée sans avoir à taper un mot de passe. Il s’agit là d’un cas d’utilisation plus poussé que nous n’aborderons pas ici.

Par défaut SSH propose uniquement une prise de contrôle en ligne de commande. Il est possible dans certains cas d’ajouter une interface graphique mais il s’agit là d’une méthode plus complexe que nous ne verrons pas ici.

 

Installer SSH pour prendre le contrôle de votre Raspberry Pi

Maintenant que nous en savons un peu plus sur SSH, voyons comment le mettre en place pour contrôler votre Raspberry Pi !

Tout d’abord, vous devez savoir que l’installation de SSH se découpe en deux parties. En effet, vous aurez besoin d’un coté d’un serveur SSH sur votre Raspberry Pi et d’un autre d’un client SSH sur votre ordinateur. Le premier recevra les commandes à lancer tandis que le second les enverra.

 

Installer le serveur SSH sur votre Raspberry Pi

Vous voulez une bonne nouvelle ? Le serveur SSH est installé et activé par défaut sur la Raspberry Pi !

Si toutes fois, pour une raison inconnue, cela n’était pas le cas, il est très facile d’installer SSH. Pour cela, il vous suffit de lancer la commande suivante :

sudo apt-get update && sudo apt-get install openssh-server

Validez l’installation et voilà, c’est fait !

 

Normalement SSH devrait démarrer automatiquement au démarrage du système. Là aussi si ce n’était pas le cas, cela peut se régler en une seule commande :

sudo update-rc.d ssh defaults

Notez bien que maintenant que SSH est installé, tout compte créé sur votre Raspberry Pi peut être utilisé pour se connecter via SSH. Assurez-vous donc d’employer des mots de passe forts !

 

Installer le client SSH sur votre ordinateur

Cette fois, pas de bonne nouvelle, à priori vous n’avez pas client SSH installé chez vous. Il y a donc deux possibilités (en fait trois, mais si vous avez un mac vous vous débrouillerez tout seul), soit vous avez un ordinateur sous Windows (et nous nous demandons bien pourquoi :b), soit vous avez un ordinateur sous Linux (et les femmes – ou les hommes d’ailleurs – se jettent à vos pieds, vos ennemis vous craignent et vos amis vous envient).

Nous allons donc voir l’installation d’un client SSH pour les deux cas.

 

Installer un client SSH sur Linux

Si vous êtes sous Linux, vous le savez déjà, le monde est plus beau ! Pour installer un client SSH, rien de plus simple, il vous suffit de lancer la commande suivante :

 sudo apt-get update && sudo apt-get install openssh-client 

Vous voyez, tout est plus simple sous Linux (oui, nous sommes de mauvaise foi) !

 

Installer un client SSH pour Windows

Vous avez fait le mauvais choix mais il vous sera beaucoup pardonner (enfin peut-être)…

Vous allez devoir installer le logiciel Putty qui est un client SSH et TelNet. Vous pourrez trouver cet excellent outil sur le site dédié.

Point intéressant, Putty fait parti des ces logiciels qui ne nécessitent pas d’installation !

 

Utiliser SSH pour vous connecter à la Raspberry Pi

Maintenant que nous avons installer un serveur et un client SSH, il ne nous reste plus qu’à les utiliser.

Là encore, deux méthodes différentes selon que vous soyez sous Linux (béni soit le grand pingouin) ou sous Windows (que se brise ses carreaux).

Dans le fond, le principe reste néanmoins le même, utilisez le client SSH pour communiquer avec le serveur, ceci à l’aide de l’adresse du serveur, d’un nom utilisateur et du mot de passe associé.

 

Utilisez SSH avec Linux

Comme toujours avec Linux, il vous suffit d’une seule ligne de commande pour vous connecter à la Raspberry Pi.

ssh utilisateur@adresse_ip_ou_url_serveur

Bien entendu, vous devrez remplacer « utilisateur » par le nom de l’utilisateur avec lequel vous souhaitez vous connecter et « adresse_ip_ou_url_serveur » par l’IP du serveur ou son adresse URL si il en possède une.

Une fois que vous aurez rentré le mot de passe du compte utilisateur (lequel, pour des questions de sécurité, ne s’affiche pas quand vous le taper), vous serez connecté au terminal de la Raspberry Pi et toutes les commandes tapées seront faites sur la Raspberry Pi ! Pour quitter SSH il vous suffit d’utiliser la commande « exit ».

 

Utilisez SSH avec Windows et Putty

Pour Windows, comme souvent, il va falloir passer par l’interface graphique. Vous allez donc devoir lancer Putty et remplir les informations comme sur l’image si-dessous.

 

Là aussi, remplacer « adresse_ip » par l’adresse IP ou l’URL du serveur. Pour information, le numéro du port (22) est le port par défaut de SSH. 

Une fois ceci fait, cliquez sur le bouton « Open ». Une fenêtre de console devrait s’ouvrir en vous demandant le nom d’utilisateur que vous souhaitez utiliser puis son mot de passe. Une fois ceci fait, vous serez connecté à la Raspberry Pi, comme sous Linux il vous suffit de taper « exit » pour quitter la connexion.

Sachez qu’il est possible d’enregistrer des configurations SSH avec Putty. Si vous souhaitez employer cette fonction, nous ne pouvons que vous conseiller de ne pas enregistrer le mot de passe, ceci étant véritablement une mauvaise pratique en terme de sécurité !

 

Conclusion

Voilà, vous savez maintenant comment contrôler votre Raspberry Pi à distance avec SSH !

Il ne vous reste plus qu’à en profiter pour aller installer votre cloud chez vous ! Et si vous préférez utiliser un bon vielle écran et un clavier, allez donc faire un tour sur notre article sur les accessoires !

Cet article Contrôlez votre Raspberry Pi avec SSH depuis votre ordinateur est apparu en premier sur Raspbian-France.

Original post of RaspbianFrance.Votez pour ce billet sur Planet Libre.