Linux and Unix tips
A partir de la version 8, Red Hat et CentOS n'utilisent plus iptables mais firewalld.
Par défaut, celui-ci est activé. On peut voir la liste des ports ouverts :
firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: enp1s0 sources: services: cockpit dhcpv6-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
Les ports correspondant aux services listés sont ouverts :
Par défaut, CentOS 7 (et RHEL) embarquent une version 5.4.16 de PHP, qui est datée et peut présenter des problèmes de sécurité.
On trouve sur le web pas mal de tutoriels qui expliquent comment passer en version 7.x, en ajoutant les dépôts REMI.
Dans mon cas, le serveur est dans un réseau d'entreprise qui dispose de ses propres serveurs de dépôts, et on ne peut donc pas accéder aux dépôts externes.
On a quand même pu passer en version 7.3, en récupérant les rpm puis en les installant.
Je décris ici les étapes à mener.
J'ai récemment migré mon serveur d'une version 18.04 LTS Ubuntu vers une version 20.04.
Lors de la migration, j'ai du passer sur la version snap de LXD, en version 4. Et suite à cette migration, les containers n'avaient plus d'adresse IP (que ce soit en V4 ou en V6).
Après de nombreuses recherches sur les forums LXD, j'ai trouvé la source du problème, en analysant les différents symptômes.
Sur le serveur, le service dnsmasq ne tournait pas. ce qu'on peut vérifier par :
Analyse et résolution d'un problème curieux, arrivé après un reboot sur un serveur Rise1 OVH.
Après installation LXD, et transfert d'images entre 2 machines, tout fonctionnait bien. Le storage par défaut a été créé lors de l'installation (par la commande lxd init) de type btrfs.
Au redémarrage, les containers ne veulent plus redémarrer :
lxc start openldap
Error: Common start logic: no such device
Try `lxc info --show-log openldap` for more info
On essaie donc la commande :
Depuis quelques temps, je trouve que le temps de démarrage de mon PC sous Ubuntu est bien long... alors que le disque principal est un SSD.
Sur les O.S. qui utilisent systemd, il existe une commande permettant de connaître le temps nécessaire au démarrage : systemd-analyze.
Sans option, cette commande donne juste le temps total nécessaire au démarrage, ainsi que le temps après lequel on arrive à l'écran de connexion. Exemple :
Lors d'un précédent article sur chkconfig, j'avais décrit comment activer les services sous Red Hat, avec les scripts init.d (à la mode SysV).
Depuis, la majorité des distributions GNU/Linux est passée sous systemd, qui apporte son lot de changement.
LA commande à connaître est maintenant systemctl. C'est elle qui permet de gérer la grande majorité des interactions au niveau administrateur.
La syntaxe est la suivante :
Je suis intervenu récemment chez un client dont le certificat https expirait dans les quinze jours, mais dont le serveur webmail est un Lotus Domino, dans une version qui n'est pas compatible avec des certiifcats encodés en autre chose que SHA1.
Leur prestataire ne pouvant générer que des certiicats en SHA256 leur a proposé 2 options :
J'utilisais déjà les containers LXC depuis pas mal de temps, ce qui me semblait une solution intéressante pour une virtualisation légère, par rapport à du KVM et bien avant Docker (et tout le foin qu'on fait autour de ça).
J'ai donc une dizaine de containers LXC, que j'utilisais sur un disque externe, sous Ubuntu 14.04 LTS.
J'ai migré récemment certains sites d'un VPS sous Debian Squeeze vers Jessie, et suite à cette migration, les sites étaient KO.
Par d'erreur dans les logs nginx, mais une simple page blanche. Pas de code html généré, rien.
J'ai regardé les permissions sur les répertoires, tout était OK. Un test avec une page HTML simple renvoie bien ce qu'il faut.
Après quelques investigations, il apparaît que ceci est lié à la version de nginx utilisée :
J'ai acquis récemment un NAS Synology DS215J , afin de m'en servir comme serveur de fichiers à la maison.
Vu la capacité installée (2 x 2 To en RAID 1), je me suis dit que je pouvais aussi l'utiliser pour la sauvegarde externalisée des VPS utilisés pour mon activité d'hébergeur HebInWeb.com
J'avais déjà un script shell que je lançais sur mon PC perso, qui allait récupérer par rsync les données sur les VPS.