:::: MENU ::::

Posts Categorized / Linux

  • Sep 16 / 2016
  • 0
Linux

Renew a GPG key when you get “GPG error – KEYEXPIRED”Renouveler une clé GPG quand vous obtenez “GPG error – KEYEXPIRED”

Getting this error when trying to update packages on your linux distro using apt?

This just means that the GPG key is expired and that you need to renew it.

You can list expired keys and get the ID by using this command:

Here, we can see that ID “4BD6EC30” is expired and is leading to the issue.

Let’s now update this key:

And you can now perform the update properly, you won’t get error anymore.

Vous obtenez cette erreur lorsque vous essayez de mettre à jour des paquets sur votre distribution linux en utilisant apt ?

Cela signifie juste qu’une clé GPG est expirée et que vous devez la renouveler.

Vous pouvez lister les clés expirées et obtenir leurs IDs, en utilisant la commande :

Ici, vous pouvez voir que l’ID “4BD6EC30” est expiré et vous mène à une erreur.

Mettez alors à jour la clé :

Et vous pouvez maintenant effectuer la mise à jour correctement, vous n’aurez plus l’erreur.

  • Sep 07 / 2016
  • 0
Linux

Send an UDP packet with NetCatEnvoyer un paquet UDP avec NetCat

It can be needed to test an UDP connection with a server to ensure that connectivity is working and double check the data received.

Let’s take a simple example with a remote logstash server:
– Server mylogstash.mydomain.local
– Listening on port 5000

On emitter side, we are sending an UDP packet simulating a log line coming from an application:

On receiving server side, we are executing a tcpdump to check that packet is correctly coming with good content:

Here we are! It’s very simple to control UDP flows or simply check connection between 2 servers.Il peut être nécessaire de tester une connexion UDP avec un serveur pour vérifier la connectivité et les données échangées.

Prenons l’exemple d’un serveur logstash distant:
– Serveur mylogstash.mydomain.local
– Ecoutant sur le port 5000

Côté serveur émetteur, nous envoyons un paquet UDP simulant une ligne de log provenant d’une application :

Du côté du serveur de réception, on execute un tcpdump pour vérifier que le paquet arrive bien avec le bon contenu :

Voilà, il est donc simple de contrôler les flux UDP ou de simplement tester une connexion entre 2 serveurs.

  • Aug 22 / 2016
  • 0
Linux

Find and identify where inodes are usedTrouver et identifier où les inodes sont utilisés

Your monitoring system is claiming that your server is running out of free inodes but your disks are not full at all? Maybe you just need to check your filesystem usage and how many files are being used at the same time… Here are some tips to check and identify the inodes being used.

First of all, you can check percentage of inodes used with this simple command:

You will see inode usage for your partitions and mouting points:

Here, we can easily see that /var is using 83% of inodes, which is quite high.

Let’s now identify how those inodes are used with a compound command using find:

You will get a sorted result like this (I truncated to display only the last lines which are the most important):

We can clearly see that inodes are mostly used by /var/spool/postfix/maildrop. You just have to go in that folder and check if files are useful and/or if you can do some cleaning there.
Then, once files are removed and directory clean, your inodes will be freed and everything will be back to normal!Votre système de monitoring vous indique que votre serveur est en manque d’inodes disponibles mais vos disques sont loin d’être pleins? Peut-être que vous avez juste besoin de vérifier l’utilisation de vos systèmes de fichiers et le nombre de fichiers qui sont utilisés en même temps … Voici quelques conseils pour vérifier et identifier les inodes qui sont utilisés.

Prémièrement, vous pouvez vérifier le pourcentage d’inodes utilisés avec cette simple commande :

Vous verrez alors l’utilisation en inode pour vos partitions et vos points de montage:

Ici, nous pouvons facilement voir que /var utilise 83% des inodes, ce qui est assez élevé.

Allons maintenant identifier comment ces inodes sont utilisés avec une commande composée utilisant find :

Vous obtiendrez alors un résultat trié comme cela (j’ai volontairement coupé l’affichage pour n’afficher que les dernières lignes qui sont importantes) :

On peut clairement voir que les inodes sont principalement utilisés par /var/spool/postfix/maildrop. Il suffit donc juste d’aller dans ce répertoire vérifier les fichiers qui sont utilisés et effectuer un peu de nettoyage.
Ensuite, une fois les fichiers inutiles supprimés et le répertoire nettoyé, vos inodes seront libérés et tout pourra alors rentrer dans l’ordre !

  • Aug 02 / 2016
  • 0
Linux

Skype group chat not working on linux

With Linux version for Skype, it can happen that group conversation are not working as expected (conversations do not start, or updates are not working, or group members do not appear, …).

You can check MSNP version you are using by typing this command in any conversation chat:

If you are getting this message (“LoggedOut”), this means that you have the MSNP issue:

You can so enter in the chat:

Then, restart Skype.

Once restarted, you can check again the MSNP version:

You should now get “LoggedIn”:

Et voila, Skype will now work correctly 🙂Avec la version Linux de Skype, il arrive parfois que les conversations de groupe rencontrent des soucis (elles ne démarrent pas, ou les mises à jour ne se font pas, ou les participants n’apparaissent pas, …).

Vous pouvez vérifier la version de MSNP utilisée en tapant cette commande dans n’importe quelle conversation :

Si vous obtenez ce message (“LoggedOut”), c’est que vous avez le problème de MSNP :

Vous pouvez alors taper :

Puis redémarrez votre Skype.

Une fois redémarré, vous pouvez vérifier à nouveau la version de MSNP :

Et vous devriez maintenant avoir “LoggedIn” :

Et voilà, Skype fonctionnera désormais correctement 🙂

  • Jul 21 / 2016
  • 0
Linux

Open bash session into a docker containerOuvrir une session bash dans un conteneur Docker

Once a docker container is started, it’s always hard to get access into and see what’s happening inside. As a workaround, the easiest way to understand what’s happening in a container is to get a CLI on it and investigate.

Since version 1.3, you can easily open a bash session into a running container by using:

  • The ID of the container:
  • Or the name of the container:

You will get access with a bash session to your container:

Une fois qu’un conteneur Docker est démarré, il est toujours difficile d’obtenir un accès et de voir ce qu’il se passe à l’intérieur. Afin de contourner cela, le meilleur moyen de comprendre ce qu’il se passe dans le conteneur est d’avoir un accès commande dessus et d’investiguer.

Depuis la version 1.3, il est facile d’ouvrir une session bash dans un conteneur en cours de fonctionnement en utilisant :

  • L’ID du conteneur :
  • Ou le nom du conteneur :

Vous aurez alors un accès à votre conteneur avec une session bash :

  • Jun 09 / 2016
  • 0
Linux, Python

openssl/pyOpenSSL – “SSL23_GET_SERVER_HELLO:tlsv1 alert internal error”openssl/pyOpenSSL – “SSL23_GET_SERVER_HELLO:tlsv1 alert internal error”

You’re getting this annoying error message again and again when trying to fetch certificate and/or establish a connection to your website using openssl:

This issue is well known in several openssl versions, and a bug has been addressed for Ubuntu repositories:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1475228

For now, there’s a simple workaround that works to quickly fix it!

For openssl

If you’re facing it while using openssl directly, you can fix it by specifying the servername on command-line:

For pyOpenSSL

If you’re having this issue while using pyOpenSSL (python wrapper for OpenSSL), it can also be fixed with a quick workaround by adding the option set_tlsext_host_name() to specify the server name in your “Connection” object.
You will get something like this:

Vous avez ce message ennuyeux encore et encore lorsque vous essayer de récupérer le certificat ou tout simplement en essayant d’établir une connexion à votre site web en utilisant openssl :

Ce problème est bien connu sur de nombreuses versions d’openssl, et un bug a même été remonté pour les dépôts Ubuntu :
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1475228

Pour le moment, il y a un moyen simple de rapidement contourner le problème !

Pour openssl

Si vous rencontrez le problème lorsque vous utilisez openssl directement, vous pouvez corriger le souci en spécifiant l’option servername sur la ligne de commande :

Pour pyOpenSSL

Si vous avez le problème en utilisant pyOpenSSL (un wrapper python pour OpenSSL), il est également possible de contourner le problème en ajoutant l’option set_tlsext_host_name() pour spécifier le nom du serveur dans votre objet “Connection” :
Vous aurez alors quelque chose comme :

Question ? Contact