Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue150:certifie_linux [2019/10/30 13:29] – auntiee
+++ issue150:certifie_linux [2019/11/04 09:49] (Version actuelle) – auntiee
@@ Ligne 1: / Ligne 1: @@
-Where we are: https://www.lpi.org/ourcertifications/exam-201 -objectives (Topic 202: System Startup). In your LPIC study guide, mine is the second edition, this will be chapter 1 (pages 4 – 27). If you are using the <nowiki>** free book</nowiki> above, it is chapter 2 (pages 47-76).
+**Where we are: https://www.lpi.org/ourcertifications/exam-201 -objectives (Topic 202: System Startup). In your LPIC study guide, mine is the second edition, this will be chapter 1 (pages 4 – 27). If you are using the <nowiki>** free book</nowiki> above, it is chapter 2 (pages 47-76).
-Welcome back learners, and a nod to those “just interested”. Since this is the 201 exam, you should be familiar with the FSH (File System Hierarchy) and LSB (Linux Standards Base). You can quickly Google those, I will wait... Right, memory refreshed!
+Welcome back learners, and a nod to those “just interested”.
-Though we are mostly using Ubuntu here, you need to know the Red Hat side of things too. Init is the first process called during SysV boot. This initial process will now start all the other processes that are listed in the runlevel
+Since this is the 201 exam, you should be familiar with the FSH (File System Hierarchy) and LSB (Linux Standards Base). You can quickly Google those, I will wait... Right, memory refreshed!**
-target. Don’t believe me? Look at the PID of init. If Linux was a first person shooter game, the init process would be the spawn point. The init levels today are still the same 0-6 levels (there are more, but unused) that I encountered back in the day; it has not changed, just know the differences between .deb-based systems and .rpmbased
-systems. You need to know that in older systems, you can usually see what is defined by printing out ‘/etc/inittab’. At the time of writing this, it is 2019, and most distributions run on Systemd, so you may get an error with ‘cat
-/etc/inittab’ if you are following along on a desktop version of Linux. That is OK. Try to run an old version of Fedora or CentOS in a VM to check it out. Be sure to look inside ‘/etc/rc.d’ folder while you are at it.
-The ‘/etc’-folder is chock full of stuff. See if you can find the rc scripts. (Runlevels 1 through 5).
+Où nous en sommes :
+https://www.lpi.org/our-certifications/exam-201-objectives
+(Sujet 202 : System Startup (Démarrage du système). Dans votre guide d'étude du LPIC (j'ai la seconde édition), ce sera au chapitre 1 (pages 4-27). Si vous utilisez le livre <nowiki> ** du dessus</nowiki>, c'est le chapitre 2 (pages 47-76).
-Let us talk about those file names you see. K20xxxxx and S20xxxxx first. Kill scripts range from 01-99 and so do start scripts. I know you are smart enough to realize the K or S at the beginning means Kill or Start. They are
+Bonjour aux apprenants et un signe de tête à ceux qui sont « juste intéressés ».
-symbolic links. Your homework is to follow them through. If you don’t already know, this will be a light-bulb moment. The number is the sequence in which it starts, so if you see two with the same number, they will start in parallel. Very simple, no? Well, SysV init is simple compared to systemd. That is also why so many people want rc
-over systemd (and the fact that it is now binary blobs instead of plain text files). To change startup on SysV init should also be simple, right? Stopping, starting, restarting services are as simple as that, you should know that by now. The LPIC study guide glances right over this subject. I really recommend reading the above free study guide.
-Now an old CentOS system is not the only one you need to start in a VM, I would suggest an old version of Debian or newer Devuan. Otherwise, the next part will be hard for you to follow. You are expected to know, not only the startup process, but how to customise said process. I need you to look at the man pages: man update-rc.d - have a look at the synopsis. You will also see they refer you to the Debian policy manual. You may ask how this worked in the real word. Well let’s say you want to add the printing service to a runlevel, say CUPS. The service you want to start has to be in: /etc/init.d – you cannot just add a service that does not exist. So the syntax would be:
+Comme c'est l'examen 201, vous devriez être à l'aise avec le FSH (File System Hierarchy - Hiérarchie des systèmes de fichiers) et le LSB (Linux Standards Base - base des standards de Linux). Vous pouvez rapidement les rechercher sur Google, j'attendrai... Bien. Mémoire rafraîchie !
+**Though we are mostly using Ubuntu here, you need to know the Red Hat side of things too. Init is the first process called during SysV boot. This initial process will now start all the other processes that are listed in the runlevel target. Don’t believe me? Look at the PID of init. If Linux was a first person shooter game, the init process would be the spawn point. The init levels today are still the same 0-6 levels (there are more, but unused) that I encountered back in the day; it has not changed, just know the differences between .deb-based systems and .rpmbased systems. You need to know that in older systems, you can usually see what is defined by printing out ‘/etc/inittab’. At the time of writing this, it is 2019, and most distributions run on Systemd, so you may get an error with ‘cat/etc/inittab’ if you are following along on a desktop version of Linux. That is OK. Try to run an old version of Fedora or CentOS in a VM to check it out. Be sure to look inside ‘/etc/rc.d’ folder while you are at it.
+The ‘/etc’-folder is chock full of stuff. See if you can find the rc scripts. (Runlevels 1 through 5).**
+Bien que nous utilisions principalement Ubuntu ici, nous devons connaître aussi la partie concernant Red Hat. Init est le premier traitement appelé pendant le démarrage de SysV. Le processus initial amorcera alors tous les autres processus qui sont listés dans la cible des niveaux d'exécution (runlevel). Vous ne me croyez pas ? Regardez le PID (rang du processus) d'init. Si Linux était un jeu de tir à la première personne, le processus init serait le point d'apparition. De nos jours, les niveaux d'init sont toujours les niveaux 0 à 6 (il y en a plus, mais non utilisés) que j'ai rencontrés il y a longtemps ; ils n'ont pas changé, connaissez juste la différence entre les systèmes basés sur .deb et ceux basés sur .rpm. Vous devez savoir que dans les systèmes plus anciens, vous pouvez habituellement voir ce qui est défini en affichant « /etc/inittab ». Au moment où j'écris ces lignes, nous sommes en 2019, et la plupart des distributions tournent avec Systemd ; aussi, vous pourriez avoir une erreur avec « cat /etc/inittab » si vous suivez l'article avec une version de bureau de Linux. C'est normal. Essayez de lancer une vieille version de Fedora ou de CentOS dans une VM (machine virtuelle) pour le vérifier. Profitez-en pour regarder dans le dossier « /etc/rc.d » pendant que vous y êtes.
+Le dossier « /etc » est plein de choses. Regardez si vous pouvez trouver les scripts rc. (niveaux d'exécution de 1 à 5).
+**Let us talk about those file names you see. K20xxxxx and S20xxxxx first. Kill scripts range from 01-99 and so do start scripts. I know you are smart enough to realize the K or S at the beginning means Kill or Start. They are symbolic links. Your homework is to follow them through. If you don’t already know, this will be a light-bulb moment. The number is the sequence in which it starts, so if you see two with the same number, they will start in parallel. Very simple, no? Well, SysV init is simple compared to systemd. That is also why so many people want rc over systemd (and the fact that it is now binary blobs instead of plain text files). To change startup on SysV init should also be simple, right? Stopping, starting, restarting services are as simple as that, you should know that by now. The LPIC study guide glances right over this subject. I really recommend reading the above free study guide.**
+Parlons des noms des fichiers que vous voyez. K20xxxxx et S20xxxxx d'abord. La gamme des scripts d'arrêt varie entre 01 et 99 tout comme les scripts de démarrage. Je sais que vous êtes assez intelligent pour réaliser que les K et les S au début des mots signifient Kill (arrêter) et Start (démarrer). Ce sont des liens symboliques. Votre travail personnel est de les suivre. Si vous ne le savez pas encore, ce sera une révélation. Le chiffre correspond à la séquence dans laquelle il démarre, de telle sorte que, si vous en voyez deux avec le même chiffre, ils démarreront en parallèle. Très simple, non ? Eh bien, SysV init est simple, en comparaison de systemd. C'est aussi pourquoi tant de gens veulent mettre rc à la place de systemd (et le fait qu'il y ait maintenant des bouts de binaire à la place des fichiers en texte brut). La modification du démarrage sur SysV init devrait être simple aussi, n'est-ce-pas ? Arrêter, démarrer, redémarrer des services sont aussi simples que ça, vous devriez le savoir maintenant. Le guide d'étude de LPIC ne donne qu'un bref aperçu du sujet. Je vous recommande vraiment de lire le guide d'étude gratuit cité au-dessus.
+**Now an old CentOS system is not the only one you need to start in a VM, I would suggest an old version of Debian or newer Devuan. Otherwise, the next part will be hard for you to follow. You are expected to know, not only the startup process, but how to customise said process. I need you to look at the man pages: man update-rc.d - have a look at the synopsis. You will also see they refer you to the Debian policy manual. You may ask how this worked in the real word. Well let’s say you want to add the printing service to a runlevel, say CUPS. The service you want to start has to be in: /etc/init.d – you cannot just add a service that does not exist. So the syntax would be:
 update-rc.d <service name>
@@ Ligne 25: / Ligne 36: @@
 “update-rc.d cups start 58 5
-. stop 58 0 6 .“
+. stop 58 0 6 .“**
-Note the delimiters - period after start and period after stop. You may get a warning message when changing a service (if it is not the default).
+Disons qu'un vieux CentOS n'est pas le seul système que vous devriez démarrer dans une VM ; je vous suggère aussi une vieille version de Debian, ou du plus récent Devuan. Autrement, la suite de l'article sera difficile à suivre. Vous êtes censés connaître, non seulement le processus de démarrage, mais comment personnaliser ledit processus. J'ai besoin que vous regardiez les pages man : man update-rc-d - regardez le résumé. Vous verrez aussi qu'il fait référence au manuel de définition de Debian. Vous pourriez vous demander comment ça fonctionne dans la vraie vie. Bon. Admettons que vous voulez ajouter le service d'impression, disons CUPS, dans un niveau d'exécution. Le service que vous voulez démarrer doit être dans : /etc/init.d - vous ne pouvez tout simplement pas ajouter un service qui n'existe pas. Aussi, la syntaxe sera :
+update-rc.d <service name>
+start <sequence number>
+<runlevel(s)> . stop
+<sequence number>
+<runlevel(s)
+Waouh, ça parait horrible, mais en pratique, c'est quelque chose comme ceci :
+“update-rc.d cups start 58 5 . stop 58 0 6 .“
+**Note the delimiters - period after start and period after stop. You may get a warning message when changing a service (if it is not the default).
 To remove a service, the syntax is simply: update-rc.d <service name> remove
@@ Ligne 33: / Ligne 56: @@
 Regardless if a service ‘usually’ runs in say, only runlevel 5, you can manually start it from /etc/init.d
-Back to our Red Hat-based system. Here we use chkconfig. Starting on page 58 in the free study guide, I need you to read it. If you did your homework... and followed the links all the way through... you will know where this is heading. If you looked inside the scripts you may have noticed that right near the top, there is a “chkconfig : “ followed by a number. These are your runlevels. So if you saw “345” following chkconfig, it was not the number three hundred and forty five, but runlevels 3,4,5. Now you can remove or add a runlevel here, but think it through thoroughly before doing so. Let’s say we would like to add cron to another runlevel (example only); then we would add say a two to the list , so it reads “2345” and save the file. This alone does nothing. To ‘pull the changes
+Back to our Red Hat-based system. Here we use chkconfig. Starting on page 58 in the free study guide, I need you to read it. If you did your homework... and followed the links all the way through... you will know where this is heading. If you looked inside the scripts you may have noticed that right near the top, there is a “chkconfig : “ followed by a number. These are your runlevels. So if you saw “345” following chkconfig, it was not the number three hundred and forty five, but runlevels 3,4,5. Now you can remove or add a runlevel here, but think it through thoroughly before doing so. Let’s say we would like to add cron to another runlevel (example only); then we would add say a two to the list , so it reads “2345” and save the file. This alone does nothing. To ‘pull the changes through, so to speak, in the rc.d folders you need to say the magic phrase in the terminal: chkconfig - -add cron**
-through, so to speak, in the rc.d folders you need to say the magic phrase in the terminal: chkconfig - -add cron
-To see what changes were made, navigate to /etc/rc.d/rc2.d/ and you should see cron – in our case – has been created. Since the chkconfig was preceded by an octothorpe – it is a comment, but chkconfig read the comments! Neat hey! This is not the only thing chkconfig can do, it is handy beyond this when it comes to services. Linux firewalls work on services, yes, I know, we need a decent application firewall program in Linux, but we do not have any. So a quick way to see which services are on, for firewall configuration, type: chkconfig - - list That said, if you edited cron to run in runlevel 2, you should see “on” in the column that represents runlevel 2. This holds true for any changes you may make – double check it here. If you turn a service on or off with chkconfig, immediately check with the: - -  list option. If you want a more finegrained control, you can use the - - level 2 on / off option. Example: chkconfig cron - - level 3 off
+Notez la ponctuation. Un point après start, un point après stop. Vous pourriez recevoir un avetissement après la modification d'un service (si ce n'est pas la valeur par défaut).
-Just be aware of the differences in systems syntax between Debian-based and Red Hat-based distributions.
+Pour supprimer un service, la syntaxe est simple : update-rc.d <service name> remove
-No practice exam questions this month, I just want you to physically do it in a Red Hat-based VM and see how it is done. Keep your peepers peeled in the exam for questions that specify RED HAT.
+Sans tenir compte de tel ou tel service qui ne tourne habituellement, disons, qu'au runlevel 5, vous pouvez le démarrer manuellement à partir de /etc/init.d.
+Revenons à notre système basé sur Red Hat. Là, nous utilisons chkconfig. Je vous demande de lire notre guide d'étude gratuit à partir de la page 58. Si vous avez fait vos devoirs... et suivi les liens pendant ce temps... vous saurez où cela vous mène. Si vous avez regardé dans les scripts, vous avez peut-être noté que tout près du haut, il y a un « chkconfig : » suivi d'un chffre. Ce sont vos niveaux d'exécution. Aussi, si vous voyez que « 345 » suit chkconfig, ce n'est pas le nombre trois cent quarante-cinq mais les runlevels 3, 4 et 5. Il est possible d'enlever ou d'y ajouter un niveau d'exécution, mais réfléchissez bien avant de le faire. Mettons que nous voudrions ajouter cron dans un autre runlevel (c'est seulement un exemple), nous ajouterions un 2 dans la liste, de façon à lire « 2345 » et nous sauvegarderions le fichier. Tout seul, ça ne marche pas. Pour vous en sortir, façon de parler, en étant dans les dossiers rc.d, vous avez besoin d'écrire la phrase magique dans un terminal : chkconfig --add cron
+**To see what changes were made, navigate to /etc/rc.d/rc2.d/ and you should see cron – in our case – has been created. Since the chkconfig was preceded by an octothorpe – it is a comment, but chkconfig read the comments! Neat hey! This is not the only thing chkconfig can do, it is handy beyond this when it comes to services. Linux firewalls work on services, yes, I know, we need a decent application firewall program in Linux, but we do not have any. So a quick way to see which services are on, for firewall configuration, type: chkconfig - - list That said, if you edited cron to run in runlevel 2, you should see “on” in the column that represents runlevel 2. This holds true for any changes you may make – double check it here. If you turn a service on or off with chkconfig, immediately check with the: - -  list option. If you want a more finegrained control, you can use the - - level 2 on / off option. Example: chkconfig cron - - level 3 off
+Just be aware of the differences in systems syntax between Debian-based and Red Hat-based distributions.**
+Pour voir ce qui a changé, naviguez vers /etc/rc.d/rc2.d/ et vous devriez voir que cron - dans notre cas - a été créé. Comme le chkconfig etait précédé par un #, c'est un commentaire - mais chkconfig lit les commentaires ! Pas mal, hein ! Ce n'est pas la seule chose que chkconfig sache faire ; il est encore plus pratique quand il s'agit des services. Les pare-feux de Linux fonctionnent comme des services ; oui, je sais, nous avons besoin d'un programme applicatif de pare-feu décent dans Linux, mais il n'y en a pas. Aussi, pour une façon rapide de voir quels services sont actifs, pour la configuration du pare-feu, saisissez : chkconfig -- list. Cela dit, si vous modifiez cron pour le faire tourner au runlevel 2, vous devriez voir « on » (actif) dans la colonne qui représente le niveau d'exacution 2. Cela reste vrai pour toutes les modifications que vous pouvez faire, vérifiez-le attentivement maintenant. Si vous démarrez ou arrêtez un service avec chkconfig, vérifiez-le tout de suite avec l'option --list. Si vous voulez un pilotage encore plus fin, vous pouvez utiliser l'option --level 2 on / off. Exemple : chkconfig cron --level 3 off.
+Soyez simplement au courant des différences de syntaxe des systèmes, entre les distributions basées sur Debian et celles basées sur Red Hat.
+**No practice exam questions this month, I just want you to physically do it in a Red Hat-based VM and see how it is done. Keep your peepers peeled in the exam for questions that specify RED HAT.
 If you would like to jump ahead, or test your skills at an LPI exam, do a test paper here: https://www.itexams.com/exam/117-201 (these were once valid LPI questions and will ease you into the format):
@@ Ligne 47: / Ligne 81: @@
 • DO NOT learn these questions parrot fashion, as they are probably not real exam questions.
-Let us know how you did; good or bad, it does not matter. Good means you are ready to write and confident in your skills. Bad means you will be learning new stuff!! Yay! There is no downside here. If you do not know why an answer is
+Let us know how you did; good or bad, it does not matter. Good means you are ready to write and confident in your skills. Bad means you will be learning new stuff!! Yay! There is no downside here. If you do not know why an answer is the way it is, contact us.**
-the way it is, contact us.
+Ce mois-ci, pas de questions d'examen pour s'entraîner ; je veux simplement que vous fassiez réellement cela dans un Red Hat dans un VM et que vous voyiez ce que ça donne. Gardez vos mirettes grandes ouvertes pendant l'examen pour voir les questions qui précisent RED HAT.
+Si vous voulez aller plus loin ou tester vos connaissances pour l'examen du LPI, faites le test suivant : https://www.itexams.com/exam/117-201 (celles-ci furent des vraies questions d'un examen du LPI ; elles vous mettront à l'aise avec son format) :
+••Le nouvel numéro d'examen est 201-400 ; 117-201 était celui d'avant.
+••Le site nécessite une inscription, mais inscrivez-vous avec une adresse mail temporaire, pas votre mail réelle.
+••N'apprenez PAS ces questions par cœur, car ce ne sont probablement pas les questions de l'examen.
+Dites-nous comment ça s'est passé ! Bien ou mal, ça n'a pas d'importance. Bien, ça signifie que vous êtes prêt pour l'écrit et confiant dans vos connaissances. Mal, ça signifie que vous apprendrez de nouvelles choses ! Eh oui ! Ici, il n'y a pas de côté négatif ! Si vous ne  connaissez pas les raisons pour telle ou telle réponse, contactez-nous.