Database Mail n’envoi rien / Database Mail not sending

Au boulot, j’ai rencontré un problème d’envoi d’e-mail depuis un serveur Microsoft SQL. Alors même que la configuration était, visiblement, correct. L’envoi d’un e-mail ne fonctionne pas.

Après quelques recherches, il s’avère que le programme DatabaseMail.exe a besoin du .NET Framework 3.5. Sachant que le .NET Framework 3.5 n’est pas un pré-requis sur la version 2016 du SQL Serveur.

Pour corriger le problème, on peut réaliser l’installation de la fonctionnalité pour résoudre le problème :

Installation fonctionnalité .NET Framework 3.5

Si vous aviez des e-mails non envoyer (unsent) dans Database Mail dès que le framework est installer, les e-mails vont être envoyer.

Pour voir le journal :

Voir le journal de Database Mail
Le contenu du journal

Au besoin, on peut également utiliser la requête SQL suivante :

USE msdb SELECT sent_status, * FROM sysmail_allitems

Cette requête affiche tous les e-mails (envoyé, non envoyé, en erreur).

On peut également utiliser une requête pour supprimer les e-mails en attente d’envoi.

Erreur de GPG : repo.mysql.com / MySQL Repository Key Expired

Une erreur lors de la mise à jour du système d’exploitation :

apt-get update && apt-get upgrade
W: Erreur de GPG : http://repo.mysql.com jessie InRelease : Les signatures suivantes ne sont pas valables : KEYEXPIRED 1550412832 KEYEXPIRED 1550412832 KEYEXPIRED 1550412832

On vérifie la liste des clés enregistrer sur la distrib’ :

sudo apt-key list

On recherche les clés qui sont expirer :

sudo apt-key adv --keyserver pgp.mit.edu --recv-keys A4A9406876FCBD3C456770C88C718D3B5072E1F5

Le problème est résolu !

Paquet apticron / Package apticron

Dans la même lignée que unattended-upgrade, le paquet apticron permet d’être informer (par e-mail) quand une mise à jour d’un logiciel est disponible sur la distribution linux que l’on utilise.

Pour ce faire, on installe le paquet :

sudo apt-get install apticron

On copie le fichier de configuration (par défaut) vers le répertoire /etc/apticron

sudo cp /usr/lib/apticron/apticron.conf /etc/apticron/

On édite le fichier de configuration apticron.conf

sudo nano /etc/apticron/apticron.conf

On peut éventuellement changer les paramètres, en autres, ci-dessous :

EMAIL=""
CUSTOM_SUBJECT=""
CUSTOM_FROM=""

Il y a d’autres paramètres dans le fichier de configuration, à voir à l’utilisation.

Pour ma part, j’ai changé la valeur :

SYSTEM=""

Une fois la modification enregistrée, on peut lancer le programme :

sudo apticron

Si des mises à jours sont disponibles alors on reçoit un e-mail à l’adresse indiquée dans le fichier.

La vérification est faite de manière quotidienne.

Paquet unattended-upgrades / Package unattended-upgrades

Si vous souhaitez garder votre distribution linux à jour, vous pouvez installer le package unattended-upgrades. Ce paquet permet d’installer les mises à jour de sécurité ainsi que les mises à jour de logiciel installés sur le système d’exploitation.

Sur une ancienne version (dans le cas présent, 0.83.3.2+deb8u1) de unattended-upgrades, on peut rencontrer l’erreur suivante :

Extracting content from '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log' since '2020-02-04 09:53:03.304883'

Traceback (most recent call last):

  File "/usr/bin/unattended-upgrade", line 1326, in <module>

    main(options)

  File "/usr/bin/unattended-upgrade", line 1271, in main

    log_content = get_dpkg_log_content(logfile_dpkg, install_start_time)

  File "/usr/bin/unattended-upgrade", line 1020, in get_dpkg_log_content

    with open(logfile_dpkg) as fp:

FileNotFoundError: [Errno 2] No such file or directory: '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log'

La dernière ligne indique que le fichier log n’a pu être trouver… et par la même, il n’a pas réussi à le créer alors qu’on lance la commande en sudo. Pour résoudre le problème, rien de plus simple :

sudo touch /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

On créé le fichier manuellement, et on relance la commande :

sudo unattended-upgrade -d

Plus d’erreur !

Lien symbolique sous Windows / Symbolic Link on Windows

Si vous souhaitez utiliser les liens symboliques sous Windows, voici la procédure à suivre.

On utilise la commande mklink disponible dans l’invite de commandes :

Pour créer un lien symbolique vers un répertoire :

mklink /d RepertoireTravail "R:\MONPROJET\PERSO\TRAVAIL"

Pour créer un lien symbolique vers un fichier (dans le cas présent un exécutable) :

mklink FichierEXE "R:\MONPROJET\PERSO\TRAVAIL\test.exe"

Quand on utilise la commande en local sur une machine, ça fonctionne sans autre action, par contre, si vous souhaitez utiliser des liens symboliques sur le réseau alors, il faut réaliser une petite action.

Dans regedit, on change la valeur de 0 à 1 de ces 2 DWORD (capture ci-dessous) pour permettre les liens symboliques sur le réseau :

Ordinateur\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

Il s'agit de SymlinkRemoteToLocalEvaluation et SymlinkRemoteToRemoteEvaluation

Il n’est pas nécessaire de redémarrer la machine suite à la modification de la clé.

Si on ne fait pas cette petite manipulation, on obtiendra le message d’erreur sur les liens symboliques réseau.

Erreur lien symbolique

Tableau de la version 2018.1 à 2018.2 ou + / Tableau from version 2018.1 to 2018.2 or higher

Au travail, j’ai du mettre à jour une installation du logiciel Tableau (Décisionnelle) ou Business Intelligence (BI pour les intimes) en anglais.

Pour ce faire, j’ai utilisé la procédure officielle sur le site internet de l’éditeur ICI.

Il faut savoir que le fonctionnement de Tableau a changer depuis la version 2018.2.

Je suis donc la procédure et j’obtiens une erreur lorsque l’étape du script upgrade-tsm.cmd arrive. Dans un premier temps, le script est lancé de manière automatique suite au setup d’installation du programme. Cela échoue…

Dans un second temps, j’exécute le script de manière manuel, et là, j’ai, également, un message d’erreur. J’utilise les arguments du script tel que –username –password et –service-runas-password mais le résultat est le même, le script se termine en erreur.

Après plusieurs essais qui finissent tous dans les choux…

Je relis la procédure et là, j’y découvre ceci :

Le fichier de sauvegarde créé par la désinstallation est utilisé ultérieurement, pour la mise à niveau, et est enregistré sous la forme de uninstall-version.tsbak dans le répertoire de données Tableau par défaut : C:\ProgramData\Tableau\Tableau Server.

Sauf que dans le répertoire ci-dessus, on n’y trouve pas le fameux fichier uninstall-version.tsbak.

Réfléchissement, Jean-Pierre comme dit un célèbre humoriste

Si le script upgrade-tsm.cmd ne trouve pas le fichier recherché, il ne nous l’indique pas clairement. Aucun message nous demandant le répertoire pour trouver le fichier.

Comme, j’avais fait une sauvegarde de tableau avant de faire la mise à jour et que cette fameuse sauvegarde est un fichier au format .tsbak. Je me dis tient prenons cette sauvegarde et passons là au script avec l’argument –backup-path chemin+fichier.tsbak

upgrade-tsm.cmd --backup-path c:\exemple\sauvegarde.tsbak --username nom-utilisateur --password mot-de-passe --service-runas-password mot-de-passe

Et là, miracle, le script s’exécute sans difficulté et s’achève sans erreur !

Une fois valider le fait que Tableau fonctionné correctement dans la version 2018.2.17. Je testait la mise à jour de 2018.2.17 vers la dernière version en date du 23 janvier 2020 à savoir la 2019.4.2.

Et là, pas de souci de script qui ne trouve pas une sauvegarde .tsbak dans le répertoire par défaut.

Logo de l’éditeur

Formation sécurité informatique

Si vous souhaitez acquérir des bases dans le domaine de la sécurité informatique, vous pouvez vous tourner vers la société Sysdream (en autres) qui propose ce genre de formation accessible à un public non technique. La formation en question est d’une durée de 2 jours. Pour plus d’informations voir le site internet :

https://sysdream.com/formation-securite-informatique/securite-offensive-ethical-hacking/hacking-securite-les-fondamentaux/


Fibre chez Bouygues Telecom

Cela fait quelques temps à présent, que je migré la fibre de Sosh à mon opérateur ADSL à savoir Bouygues Télécom. L’installation de la fibre en elle même c’est super bien passé, les techniciens qui était venus avait fait un boulot propre 🙂 De nos jours c’est rare pour le signaler, surtout quand je vois le travail effectué par un sous traitant Orange chez une voisine de pallier… 🙁

La fibre BT fonctionne bien, le débit est là 🙂 Ceci a permis de mettre en place des petits projets à la maison 🙂

Moxa Nport 5110

Si vous cherchez de quoi mettre un matériel disposant d’un port série sur l’ethernet, je ne peux que vous conseiller la marque Moxa qui propose un large choix de matériel pour répondre à ce genre de besoin. Cela se nomme un serveur de périphérique.

J’ai eu l’occasion de tester dernièrement le modèle Nport 5110 qui dispose d’un port série.

Très facile de prise en main, on le configure pour quelques réglages par une interface web sinon via une application (NPort Administration Suite) que propose le fabricant sur son site internet.

Moxa Nport 5110

Serveur de périphérique série Moxa Nport 5110.

D’autres modèles sont disponibles, modèle POE, modèle Wifi, modèle répondant à la norme Atex.

Si vous chercher un site où acheter ce matériel, vous avez éventuellement adm21.