Problème de gestion logrotate dans Ubuntu Server Bionic

Je reçois, sur Ubuntu Server Bionic, des messages de ce type :

/etc/cron.daily/logrotate:
logrotate_script: 2: logrotate_script: /usr/lib/rsyslog.hdd/rsyslog-rotate: not found
error: error running non-shared postrotate script for /var/log.hdd/syslog of ‘/var/log.hdd/syslog

logrotate_script: 2: logrotate_script: /usr/lib/rsyslog.hdd/rsyslog-rotate: not found
error: error running shared postrotate script for ‘/var/log.hdd/mail.info
/var/log.hdd/mail.warn
/var/log.hdd/mail.err
/var/log.hdd/mail.log
/var/log.hdd/daemon.log
/var/log.hdd/kern.log
/var/log.hdd/auth.log
/var/log.hdd/user.log
/var/log.hdd/lpr.log
/var/log.hdd/cron.log
/var/log.hdd/debug
/var/log.hdd/messages

run-parts: /etc/cron.daily/logrotate exited with return code 1

On retrouve, dans /etc/logrotate.d/rsyslog, une ligne « /usr/lib/rsyslog.hdd/rsyslog-rotate » au lieu de « /usr/lib/rsyslog/rsyslog-rotate », or /usr/lib/rsyslog.hdd n’existe pas. En attendant, pour s’affranchir des problèmes d’accumulation des fichiers de log, j’ai ajouté un lien symbolique pour faire disparaître cette erreur :

eric@moscou:/home/users/eric$sudo ln -s /usr/lib/rsyslog /usr/lib/rsyslog.hdd

Problème d’emballement des processeurs dans KDE

J’utilise KDE maintenant depuis quelques mois et j’en suis plus que satisfait. Il y a néanmoins un problème récurrent qui emballe les processeurs et donc la ventilation : c’est associé à un process nommé baloo_file_extractor.

Après enquête, il s’avère qu’il s’agit d’une « feature » de KDE qui consiste en la mise à jour d’une base de données (« dossier recherche ») pour retrouver des fichiers plus facilement. Cela peut être pratique mais sur un ultraportable c’est vite agaçant.

Pour s’affranchir de ce problème il faut donc aller dans la « Configuration du système », rubrique « Espace de travail/Démarrage et arrêt ». Les « Services d’arrière-plan s’affichent, et il faut désactiver la « Mise à jour du dossier Recherche », à la fois dans les « Services à la demande » et dans les « Services au démarrage ».

Test – validé – de la distribution Linux « Manjaro »

Ces derniers jours, j’ai souhaité tester la dernière version de l’environnement graphique KDE. En fouillant sur la toile, il m’a également semblé que l’une des distributions bien adaptée à ce DE (environnement graphique de bureau) n’était pas nécessairement KUbuntu : Manjaro testé Manjaro Linux.

Cette distribution est proposée prépackagée avec KDE (d’autres versions sont également disponibles).

L’installation se fait d’une façon aussi simple qu’avec Ubuntu, l’interface graphique étant très similaire.

Dès le premier redémarrage le système est parfaitement fonctionnel. je redécouvre KDE après plusieurs années, et c’est une énorme surprise. L’interface peut paraître confuse, mais c’est parce qu’elle est très riche, bien plus que Gnome. Je ne jetterais pas que Gnome au feu, il a toute sa place de par sa simplicité (je ne passerais certainement pas ma mère de Gnome (Ubuntu) sur KDE quelle que soit la distribution. Ceci dit, pour un amateur éclairé, un geek, KDE est bien plus enthousiasmant.

Je découvre en particulier les « plasmoïdes », ces sortes de widgets associés à Plasma, l’environnement graphique de base de KDE. Ils sont nombreux et permettent très facilement de se formater un bureau « aux petits oignons ».

Autre exemple, Latte Dock. Ce dock est très similaire au dock d’Apple, ou au dock de Gnome « Dash toDock ». Mais pour une raison de conception interne au DE j’imagine, le dock de Gnome ne fonctionnait pas bien chez moi (un portable HP X360 Spectre avec un i5 de 5e génération, et 8 Go de RAM), alors que Latte Dock est d’une fluidité déconcertante. Ci-dessous une image de mon bureau actuel :

 

Bureau KDE

Bref, pour mon portable je vais rester sur Manjaro et surtout sous KDE. Je mettrai prochainement quelques trucs pour « tuner » ce type d’installation sur un portable comme le mien (qui peut se replier comme une tablette).

Installation d’un client VPN pour utiliser transmission (gestion de torrents) de façon anonyme

Ayant trouvé ce tutoriel plutôt bien fait :

https://mondedie.fr/d/5933-Tuto-Faire-passer-le-traffic-bitTorrent-dans-un-tunnnel-VPN,

Je m’en suis inspiré  pour décrire comment installer correctement un client VPN avec un abonnement PureVPN et pour l’utilisation de transmission sur Ubuntu Server (sur un serveur HC1 de Hardkernel) :

1) Installer openvpn sur le serveur :

eric@boston:/home/eric$ sudo apt-get install openvpn

2) Créer une table de routage pour le VPN :

eric@boston:/home/eric$ mv /etc/openvpn eric@boston:/etc/openvpn$ sudo echo 1 VPN >> /etc/iproute2/rt_tables 

 

3) Editer le fichier /etc/network/interfaces :

eric@boston:/etc/openvpn$ sudonano /etc/network/interfaces

A supposer que votre réseau interne est en 192.168.1.x, il faut créer une deuxième boucle locale sur un autre réseau non accessible du principal, par ex. 192.168.0.x ou 10.0.0.x etc. Dans ce cas, ajouter le bloc ci-dessous dans le fichier interfaces :

auto lo:1
        iface lo:1 inet static
        address 192.168.0.1
        netmask 255.255.255.255

4) Télécharger les fichiers de conf de PureVPN :

eric@boston/etc/openvpn$ sudo wget 'https://s3-us-west-1.amazonaws.com/heartbleed/linux/linux-files.zip

5) Extraire le fichier linux-files.zip dans /etc/openvpn et renommer le dossier PureVPN :

eric@boston/etc/openvpn$ sudo unzip linux-files.zip && mv Linux\ OpenVPN\ Updated\ Files PureVPN 

6)  Créer les lien symbolique suivant dans le répertoire /etc/openvpn :

eric@boston:/etc/openvpn$ sudo ln -s PureVPN/UDP/Belgium-udp.ovp client.conf

Le lien est ici en exemple sur le serveur UDP belge mais on peut bien entendu choisir n’importe lequel des serveurs du dossier (ou du côté TCP c’est possible aussi).

5) Créer le répertoire scripts dans /etc/openvpn et créer les scripts checkVPN, up.sh et down.sh :

eric@boston:/etc/openvpn$ sudo mkdir scripts
eric@boston:/etc/openvpn$ sudo vi scripts/checkVPN 
eric@boston:/etc/openvpn$ sudo vi scripts/up.sh
eric@boston:/etc/openvpn$ sudo vi scripts/down.sh
eric@boston:/etc/openvpn$ sudo chmod +x scripts/

Insérer le contenu de checkVPN  dans checkVPN, celui de down dans down.sh et celui de up dans up.sh. Il faut bien entendu adapter la valeur du réseau de la boucle locale dans ces fichiers en fonction de votre propre configuration, cf point 3) ci-dessus.

6) Créer un fichier pass.txt et un lien symbolique sur ce fichier qui contiendra les informations de connexion fournies par PureVPN :

eric@boston:/etc/openvpn$ sudo vi PureVPN/pass.txt
eric@boston:/etc/openvpn$ sudo ln -s PureVPN/pass.txt PureVPN/pass

Contenu de pass.txt sur deux lignes, la première étant le login et la deuxième le pot de passe, par exemple  :

purevpnXYZabc
VPN123456

7) Sécuriser le fichier pass.txt :

eric@boston:/etc/openvpn$ sudo chmod 700 PureVPN/pass.txt

8) Adapter la configuration du fichier de conf du serveur :

client
dev tun
proto udp
route-nopull
script-security 2
up /etc/openvpn/scripts/up.sh
down /etc/openvpn/scripts/down.sh
remote be1-ovpn-udp.pointtoserver.com 53
resolv-retry infinite
keepalive 10 60
persist-key
persist-tun
ns-cert-type server
ca /etc/openvpn/PureVPN/ca.crt
tls-auth /etc/openvpn/PureVPN/Wdc.key 1
cipher AES-256-CBC
auth-user-pass /etc/openvpn/PureVPN/pass
auth-retry nointeract
comp-lzo
verb 1
explicit-exit-notify 2
mute 20
ifconfig-nowarn

9) Configurer transmission-daemon pour qu’il utilise le tunnel VPN :

a) Arrêter le daemon :

eric@boston:/etc/openvpn$ sudo service transmission-daemon stop

b) Editer la configuration de transmission. Le fichier settings .json peut éventuellement se situer à un autre endroit.

eric@boston:/etc/openvpn$ sudo nano /var/lib/transmission-daemon/.config/transmission-daemon/settings.json

c) Modifier la configuration « bind-address-ipv4 » pour y déclarer la boucle locale mise en place dans le point 3) :

"bind-address-ipv4": "192.168.0.1",

 

10) Lancer le serveur openvpn :

eric@boston:/etc/openvpn$ sudo service openvpn start

En théorie, le serveur openvpn se lance, se connecte au serveur de PureVPN, et lance automatiquement le serveur transmission-daemon. Il est toujours possible de vérifier que tout fonctionne bien :

1) en tentant une connexion de l’extérieur (d’internet) sur la box (si celle-ci a une adresse dynamique par exemple), elle doit être accessible. Sinon cela signifie que tout le réseau passe par le VPN et pas seulement transmission.

2) En démarrant un téléchargement de torrent « CheckMyTorrent » :

https://torguard.net/checkmytorrentipaddress.php?hash=5b7c19bd6b427b8fb87f80c74e5c1e6e441f31ba

Le torrent, dans le programme de gestion de torrent (transmission-remote dans mon cas par exemple) doit afficher un message d’erreur (normal) ainsi qu’une adresse IP  : si cette adresse n’est pas celle de la box internet, c’est gagné !

 

Sécurisation de ssh par fail2ban

Il semblerait que fail2ban ne bloque pas les tentatives d’authentification par ssh/clé privée. Effectivement, l’authentification sur le ssh de ma « banane » est basée sur ce mode, en ajoutant dans /etc/ssh/sshd.config la config « PermitRootLogin without-password » qui bloque les tentatives de login en root tout en le permettant sur la base d’authentification par clé.
Heureusement, le support de PLESK assure que le risque est inexistant : https://support.plesk.com/hc/en-us/articles/213395289 .

Ouf !