Thursday, September 29, 2016

CentOS - à la ligne de commande - 10 : les modes de secours et d'urgence

Dans mon billet précédent, j'ai fait démarrer mon serveur CentOS à partir du média d'installation (un fichier .iso en l'occurrence) afin de changer un mot de passe root que j'aurais oublié. Nous pourrions sans doute recourir à cette méthode pour effectuer d'autres opérations. Je dois penser que l'option de démarrage "Rescue a CentOs system" (Secourir un système CentOS) permet de faire autre chose que la seule ré-initialisation du mot de passe root.

Il semble donc que, dans les cas les plus graves, nous puissions faire démarrer le système à partir du média d'installation et tenter une réparation, peut-être en remplaçant des fichiers endommagés ou supprimés par mégarde.

Mais il paraît que d'autres options existent pour des cas un peu moins graves. A ce stade de mes recherches sur Linux (et CentOS en particulier), j'en connais deux :

  1. le mode de secours (Rescue mode). C'est l'équivalent du mode mono-utilisateur (Single-user mode).
  2. le mode d'urgence (Emergency mode)

En fait, je crois que tous les deux sont des modes "mono-utilisateur", ce qui signifie, en substance, qu'un seul utilisateur a la capacité (ou le "droit") d'ouvrir une session : root.

Le mode mono-utilisateur correspond à un des sept "niveaux de fonctionnement" ou "run levels" en version (anglaise) originale. Les niveaux de fonctionnement (que je viens de découvrir) constituent un sujet à part que je compte examiner dans un billet à venir (peut-être même le prochain).

Note : je présente ce qui suit sous toute réserve dans la mesure où je ne fais que commencer à acquérir des notions de gestion du système CentOS. Grâce à Internet, j'ai accès à une surabondance d'informations qui sont plus ou moins exactes. Il arrive parfois que je me heurte à des incertitudes : les interfaces réseau sont-elles activées en mode mono-utilisateur? Non (du moins, pas par défaut). Peuvent-elles l'être ? Il semble que oui. Alors comment ?


***


Voici comment se présentent ces deux options de démarrage...


Le mode de secours


  • C'est un mode "mono-utilisateur"
  • Il essaie de monter tous les systèmes de fichiers locaux (Il y a plus qu'un seul? Je n'ai pas encore étudié de près cet aspect de CentOS).
  • Il démarre des services système importants (mais pas tous ?).
  • Par contre, les interfaces réseau ne sont pas activées (par défaut).


Mais comment recourir au mode de secours ?

Nous mettons le serveur sous tension et lorsque GRUB affiche le choix des systèmes d'exploitation que nous pouvons faire démarrer, nous appuyons sur la touche "e" :



Ce qui nous amène à cet écran :



En manipulant les flèches, nous devons faire descendre le curseur jusqu'à la ligne qui commence par "linux16".

Note: si nous avons affaire à UEFI, ce sera plutôt "linuxefi".

Et nous ajoutons le texte...

systemd.unit=rescue.target



Nous pourrions ajouter "single", "s" ou "1" au lieu de systemd.unit=rescue.target. C'est plus court et l'effet est le même.

Quoi qu'il en soit, nous appuyons sur Ctrl+x pour passer en mode de secours.

Chose bizarre, nous sommes accueillis avec la mention "Welcome to emergency mode!". Je croyais que nous serions plutôt en "mode de secours" (rescue mode)?



Deux remarques :

  1. Nous devons saisir le mot de passe de root qui protège l'accès au mode de secours. Nous ne pouvons pas utiliser celui-ci pour contourner le mot de passe.
  2. Si nous exécutons la commande "runlevel", le résultat est "N 1", ce qui équivaut au mode mono-utilisateur.



Le mode d'urgence

Il fournit un environnement "le plus minimaliste possible", apte à permettre le dépannage du système dans des cas où même le mode de secours ne réussirait pas.

  • C'est aussi un mode "mono-utilisateur".
  • Il monte seulement le système de fichiers root - et seulement en lecture seule. 
  • Il démarre seulement une poignée de services "essentiels".
  • Comme pour le mode de secours, les interfaces réseau ne sont pas activées.

A priori, nous suivrions exactement les mêmes étapes pour le mode d'urgence sauf qu'au lieu de "systemd.unit=rescue.target" nous mettrions plutôt "systemd.unit=emergency.target".

Note: nous pourrions mettre encore "emergency" pour faire démarrer en mode d'urgence.

A première vue, rien ne différencie le mode de secours du mode d'urgence. Nous avons le même message d'accueil en anglais "Welcome to emergency mode!".

Toutefois, je constate déjà deux différences :

  1. Le démarrage semble plus rapide avec le mode d'urgence, ce qui serait logique : moins de services sont lancés, et seul le système de fichiers root.
  2. En mode de secours, la commande "runlevel" donne "N 1" tandis qu'en mode d'urgence le résultat est "unknown" (inconnu).

Note: je me sers du terme "run level" (niveau de fonctionnement) mais s'agissant de CentOS 7, il convient de préciser que cette dernière version remplace le concept de "niveaux de fonctionnement" par "cibles" (target en anglais). Pourtant, les commandes et les paramètres qui renvoient aux niveaux de fonctionnement semblent bel et bien fonctionner encore, par example la commande "runlevel" ou le numéro "1" qu'on peut utiliser au lieu de "systemd.unit=rescue.target".

En effet, le démarrage est effectivement plus ou moins rapide selon les différents modes. Nous pouvons l'observer dans le détail avec la commande systemd-analyze :

Niveau de fonctionnement 3 (Run level 3)




Mode de secours / Niveau de fonctionnement 1 (Run level 1)



Mode d'urgence



Nous pouvons comparer le nombre de services en cours d'exécution avec la commande systemctl (et utiliser grep pour isoler seuls les services en exécution).

Niveau de fonctionnement 3 (Run level 3)




Mode de secours / Niveau de fonctionnement 1 (Run level 1)



Mode d'urgence




***

Que faire ensuite ? Cela dépend des résultats de notre analyse de la panne. Une fois dans tel ou tel mode, les mesures à prendre seraient différentes selon le type de panne et dépassent le cadre de ce billet.

Cependant, en réponse à une question que je me suis posée plus haut, je voudrais vérifier s'il est possible de faire démarrer un service, le service "network" (réseau), en mode de secours. Allons voir...


Commentaire :

  • Nous sommes bien en mode de secours (niveau de fonctionnement 1).
  • Le service réseau (network.service) n'est pas activé. Impossible d'envoyer un ping.
  • J'arrive à faire démarrer le service avec la commande systemctl start network.service
  • Il est maintenant possible d'envoyer un ping à l'extérieur.

En mode d'urgence, je n'ai pas pu faire démarrer le service "network".


***

Ressources:

Guide de l'administrateur système - RHEL 7 (section sur les modes secours et urgence) :




Saturday, September 24, 2016

CentOS - à la ligne de commande - 09 : réinitialiser le mot de passe root

J'ai oublié le mot de passe root ! Que faire ?

Selon les recherches que j'ai faites, nous avons plusieurs options mais la plus simple serait de faire démarrer le serveur depuis le média d'installation et de suivre la procédure que je vais présenter dans les paragraphes ci-dessous.

Note: il va de soi qu'il vaudrait mieux avoir sous la main le média d'installation. Dans le cas contraire, nous pourrions toujours en créer un nouveau, en faisant bien attention à faire correspondre la version de CentOS déjà installée et la version de CentOS du nouveau média d'installation.

Dans cet exemple, j'exécute CentOS 7 en tant que machine virtuelle invitée sur un hôte Windows 10 / Hyper-V. Je fais démarrer à partir d'un média d'installation en désignant un fichier .iso :



J'ouvre une console (la marche à suivre variera selon votre logiciel de virtualisation) et choisis l'option "Troubleshooting" (Dépannage) :


Note: j'appuie sur "Retour" / "Entrée" pour passer à l'écran suivant. Je monte ou descends parmi les options en appuyant sur les touches flèches de mon clavier.


Je choisis l'option : "Rescue a CentOS system" » (Secourir un système CentOS) :



Je choisis l'option "1" - Continue :



Je clique sur "Retour" :




Je saisis alors la commande passwd et puis le nouveau mot de passe :




Le guide de l'administrateur (voir le lien en fin de billet) nous recommande de supprimer le fichier "autorelabel" afin d'éviter un ré-étiquetage du disque qui prendrait beaucoup de temps :

rm -f /.autorelabel



Nous saisissons la commande exit deux fois (une fois comme dans la capture d'écran ci-dessus et puis une seconde fois) et, malgré la suppression du fichier autorelabel, une certaine réinitialisation s'effectue tout de même :


Il est à supposer que sans la suppression du fichier en question le processus qui a lieu prenne encore plus de temps.

Quoi qu'il en soit, j'ai mis le serveur hors tension (le redémarrage ne semblait pas vouloir se faire tout seul) et avant de le faire redémarrer manuellement, j'ai remis le paramètre pour le lecteur de DVD à "Aucun" (voir la première capture d'écran tout en haut).

Et j'ai bel et bien pu ouvrir une session avec le nouveau mot de passe.

***

Ressources :

Le guide de l'administrateur - RHEL 7 :

24.6.3. Modifier et reconfigurer le mot de passe root

Pour le texte original en anglais, reportez-vous ici :

System Administrator's Guide - Basic System Configuration

Thursday, September 22, 2016

CentOS - à la ligne de commande - 08 : GRUB et le démarrage

Savoir comment se déroule le démarrage d'un système d'exploitation ("OS") peut se révéler utile pour le dépannage ou l'optimisation des performances. Quant à moi, cela fait bien longtemps que je n'ai pas eu à m'occuper de cet aspect dans le monde de Windows mais je garde en tête les notions de base. En ce qui concerne Linux, et CentOS en particulier, je veux passer en revue le processus de démarrage et éventuellement (dans un billet de blogue à venir) des options comme l'équivalent du mode sans échec. Je me demande, par exemple, comment je m'y prendrais si CentOS refusait de démarrer suite à l'installation d'un nouveau pilote ou d'une mise à jour ?

***

Voici les étapes du démarrage telles que je les comprends (on pourrait présenter ce processus avec moins de détails ou encore plus).

BIOS/MBR

Cette première étape du démarrage se fait au niveau du BIOS (système élémentaire d'entrée et de sortie). Le BIOS constitue une sorte de lien entre le matériel et le logiciel. Il réside dans une puce de la carte mère (mémoire en lecture seule) et s'active avant même qu'un système d'exploitation soit chargé.

Quand j'appuie sur le bouton de démarrage du serveur, le BIOS lance le POST (auto-vérification d'allumage), une sorte de diagnostic, et détecte le matériel disponible avec lequel l'OS pourra fonctionner (sous réserve d'avoir les bons pilotes).

Si le diagnostic réussit, le BIOS va chercher un chargeur de démarrage ("bootloader") dans le MBR ("Master Boot Record") qui se trouve d'habitude dans le premier secteur du premier lecteur (disque) du serveur (il en occupe précisément les premiers 512 Ko du lecteur de démarrage ou "boot drive"). Désormais, c'est le chargeur de démarrage qui gère les opérations.

Note: en l'absence d'un OS, le démarrage peut se faire à partir d'un CD, DVD ou plus récemment, d'une clé USB. C'est typique d'ailleurs lors d'une nouvelle installation.


Chargeur de démarrage (niveau 1)

Je ne me souviens pas d'une distinction entre les chargeurs de démarrage de niveau 1 et de niveau 2 chez Windows mais une telle distinction, paraît-il, existe chez Linux. Le chargeur de démarrage de niveau 1 (présent dans le MBR) lance le chargeur de démarrage de niveau 2 qu'on trouve dans le répertoire /boot :



Chez Linux, le chargeur de démarrage s'appelle "GRUB" (GRand Unified Bootloader). CentOS 7 (et RHEL 7) utilise une nouvelle version de GRUB : GRUB version 2 ou GRUB2. Les versions précédentes utilisaient simplement "GRUB" qu'on appelle maintenent "legacy GRUB" ("GRUB hérité") qui semble rester présent d'ailleurs, comme on voit dans la capture d'écran ci-dessus.

En fait, le répertoire grub est vide. Seul le répertoire grub2 contient des fichiers dont le fichier grub.cfg :



Nous pouvons configurer des options pour GRUB en modifiant les paramètres dans ce fichier-ci :

/etc/default/grub

Pour que les modifications prennent effet, il faut régénérer le fichier grub.cfg avec la commande suivante :

grub2-mkconfig –o /boot/grub2/grub.cfg



Par exemple, j'ai ajouté les éléments suivants pour que le nom d'une interface réseau s'affiche d'une certaine manière:

biosdevname=0 net.ifnames=0

C'est bien ce fichier que j'ai édité (avec vi) :

/etc/default/grub



Et non pas celui-ci :

/boot/grub2/grub.cfg




Chargeur de démarrage (niveau 2)

Il charge le noyau dans la mémoire vive. Le noyau s'appelle vmlinuz et il semble qu'il y ait plusieurs instances qu'on entre-aperçoit dans la capture d'écran plus haut. En voici une meilleure prise :



Ces instances semblent correspondre aux options qu'on voit juste après le démarrage du serveur:




Le chargeur de démarrage monte l'image initramfs (un système de fichier de base qui se monte avant le "vrai" système de fichier).

Le noyau utilise initramfs pour charger certains modules pour IDE, SCSI ou RAID (qui doivent être chargés avant que le noyau puisse accéder au disque ?).

Une fois le noyau chargé (ainsi que ces autres modules), le chargeur de démarrage lui passe le relais.


Noyau

D'autres pourraient entrer plus encore dans le détail, mais pour ma part, j'ai compris que le noyau accomplit les deux tâches suivantes :
  • Le noyau monte la partition racine / en lecture seule.
  • Le noyau lance systemd (il s'agissait plutôt de /sbin/init dans les versions précédentes de CentOS, 5 et 6 par exemple).


Systemd

A son tour, systemd accomplit ces opérations :
  • systemd monte les partitions, l'environnement utilisateur et les services.
  • systemd présente l'invite de connexion à l'utilisateur:




***

Selon mes priorités, toujours changeantes, je voudrais, dans un billet à venir, examiner des options de GRUB et peut-être les démarrage de secours et d'urgence.

Sunday, September 11, 2016

Office 365 - hybrid configuration - change Mail Flow

As readers may have observed when consulting previous blog posts, I have an Office 365 subscription associated with on-premises Exchange servers in what is known as a hybrid deployment. Concerning mail flow, I had configured the MX records so that incoming messages would be directed to my on-premises Exchange servers (after 1 to 1 NAT at the perimeter firewall and transiting by a Citrix NetScaler VPX load balancer). This configuration has a significant disadvantage: I do not benefit from the antimalware and antispam services of Exchange Online Protection. This is less critical in a practice or test environment where the future of the business is not at stake, but after my test users started receiving suspicious emails (apparently someone is reading my blog... ), I thought is would be prudent to adjust mail flow so that incoming messages are routed to Exchange Online and, when necessary, forwarded to on-premises mailboxes via the organization send and receive connectors configured for Office 365.

According to the sources I consulted, it would be a simple matter of changing my MX records and then re-running the Office 365 Hybrid Configuration Wizard.

For more information on this wizard, you can consult this previous blog post:

The new Office 365 Hybrid Configuration Wizard

***


Change MX records

For this step, we have to use whatever interface we normally use to manage our DNS records. In my case, this would be No-IP which I will use as an example.

Note: I have edited the images (screenshots) below to conceal certain details.

So I log in and go to the "Manage Domains" section...




I select the domain associated with the MX records that I want to change:




We have a number of "hosts" which are essentially A records (or CNAME). In the No-IP management interface, we have to open the A record to see any associated MX records. Since my email address uses the format "someone@mitserv.net", I will modify the A record (in fact the associated MX record) for "mitserv.net" (click on the "Modfiy" icon):



In the following screen, we have to scroll to the very bottom where we see the section for MX records. This is what was configured before the modification:



The MX record (which is not displayed as in other interfaces - it seems that we do not see the record itself) points to the A record for "mail.mitserv.net" which in turn points to the external IP address of my test network (where 1 to 1 NAT forwards incoming messages to my Citrix NetScaler VPX).

Regardless, I change the MX record so it points to the following A record:



But wait! Where did I find that record?

We have to access our Office 365 account and in the Admin center, we click on "Domains":



I select my domain:




Here is the MX record that should be entered:





Run the Office 365 Hybrid Configuration Wizard (again)

Please consult the blog post referenced in the hyperlink above.

We repeat exactly the same steps with one exception:


 We do not check the "Enable centralized mail transport" option.


***

And that's all.

Additional testing confirmed that incoming messages are routed to Office 365 instead of the on-premise servers. If the test user has a mailbox hosted by Office 365 (Aisha Bhari), the message is delivered directly. If the test user has a mailbox that is still hosted by an on-premises server (Alannah Shaw), Exchange Online forwards the message to that final destination via the send and receive connectors configured for the hybrid deployment.