Console/Shell :

Une commande rentrée passe par Console >; Shell >; kernel.

On a différents shells: Bourne shell sh, Bourne Again shell bash, C shell csh, Korn shell ksh…

La console est une IHM, le shell un interpréteur de commandes qui parle au kernel.

halt now est devenu halt -p. halt, poweroff sont des raccourcis de la commande shutdown. Exemple de reboot : shutdown -r now

mkdir -p #permet de créer des dossiers récursifs.
mkdir -p /var/coucou/salut #En chemin absolu
mkdir -p coucou/salut/ #Chemin relatif

cp /var/log/syslog . #Va copier syslog dans mon répertoire courant, vive le point
cp -r /var/log /home/justine/ #Copie le dossier log vers mon home (le dossier complet, pas juste le #contenu)

mv fichier /dossier/ #Déplace fichier dans dossier ; pas besoin de mv fichier /dossier/fichier

Commande cat:

cat fichier1 fichier2 #Affiche le contenu des deux fichiers à la suite.

Commande find:

Les arguments d’action : -print (affiche le NOM) -delete -exec -name (faire une recherche dans le nom du fichier) <syntaxhighlight lang="bash"> find / coucou -print #Cherche le fichier coucou dans / et l’affiche find / -name password* -print #rechercher les fichiers dont le nom commence par password dans / #et afficher leur chemin find / -size 15M #Rechercher des fichiers de de 15 mégaoctets ; k pour kilo M pour méga G #pour giga find / -type f -exec cat {}\ ; #Exécute cat sur le résultat

Ici je cherche dans / un fichier (‘-type f’, je peux faire ‘-type d’ pour un dossier) puis j’éxecute (-exec) la commande cat sur la trouvaille {} et je finis ma liste de commande avec \
Trouve et efface avec une regex

find . -name "*2018*gz" -exec rm -r '{}' \; </syntaxhighlight>

{} signifie « ce que j’ai trouvé », apparement un find -exec finit toujours par \ ;
Je peux y rajouter du -name , du -print, etc

Configuration d'interfaces

Les noms d'interfaces sont désormais déterminés en fonction de la configuration matérielle:

<type d'interface><numéro du bus><numéro du slot>
<en>p(pour la carte PCI)<0><3> soit enp0s3

Sur Ubuntu

Sur Ubuntu Desktop, ce n’est pas /etc/network/interfaces qui est utilisé mais /etc/netplan: le fichier à modifier a l'extension .yaml

!!! Dans ce fichier, il ne faut pas utiliser de tabulations et bien positionner ses espaces !

Exemple en ip fixe :

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      addresses:
        - 10.10.10.2/24
      gateway4: 10.10.10.1
      nameservers:
          search: [mydomain, otherdomain]
          addresses: [10.10.10.1, 1.1.1.1]

Et pour appliquer les changements:

sudo netplan apply #(on peut ajouter un –debug en cas de problèmes)

!!! Même resolv.conf n’est plus utilisé : c’est systemd-resolve qui s’occupe de resolver les adresses. Plus d'informations sur les serveurs DNS avec la commande :

systemd-resolve –status

Les redirections

Lorsque je lance une commande, celle-ci lance un processus qui lui même possède un flux de données avec plusieurs entrées/sorties:

La sortie standard (stdout) : redirige par défaut vers l'écran, c'est ce qui se passe quand tout va bien
La sortie d'erreur (stderr) : ce sont tous les messages d'erreur, par défaut elle redirige aussi vers l'écran
L'entrée standard (stdin) : Le processus lit les données entrées par l'utilisateur (par le clavier)

Le but d'une redirection est de rediriger ces flux.

En pratique

Rediriger stdout vers un fichier avec ">": Si par exemple je veux faire la liste des fichiers de log de mon système et en faire une copie dans un fichier texte, je peux utiliser ls -l /var/log > liste-log.txt. Rien ne s'affiche à l'écran et un fichier est bel et bien créé à l'endroit où j'ai rentré la commande. Attention, si un autre fichier liste-log.txt existait déjà, il aurait été écrasé!
Rediriger une commande (stdout) à la fin d'un fichier avec ">>" : Le principe est le même, sauf que le texte est redirigé par concaténation à la fin d'un fichier. Ainsi si le fichier existe déjà, il ne sera pas supprimé mais recevra simplement les nouvelles informations à la fin de celui-ci.
Rediriger les erreurs (stderr) avec "2>" ou "2>>" : le principe est le même que le simple/double chevron sauf que cette fois on ne redirige le flux d'erreurs, au lieu de la sortie standard.
Rediriger les données venant d'un fichier vers une commande avec "<" (on redirige vers stdin): Au lieu d'utiliser le clavier comme entrée, on va utiliser un fichier. Par exemple, si je l'utilise avec cat pour lire un fichier, je peux faire un cat < fichier.txt. Le résultat est le même qu'un cat fichier.txt, mais le processus est différent.
Je peux rediriger les erreurs ainsi que la sortie standard en même temps avec 2>&1.
<< Permet de rediriger depuis le clavier.

Les pipes

Les pipes permettent d'enchaîner des commandes, en branchant la sortie d'une commande sur l'entrée d'une autre commande. La syntaxe générique est la suivante:

commande1 | commande2

Un exemple : la commande du permet d'afficher la taille des fichiers et dossiers en octets, et la commande sort -nr permet de trier , avec -n pour les valeurs numériques et -r pour afficher les résultats inversés, c'est-à-dire du plus grand au plus petit:

du | sort -nr

S'affichent alors à l'écran mes dossiers et fichiers triées du plus grand au plus petit, avec leur taille en octets. On pourrait aussi ajouter une troisième commande, less, pour lire les résultats page par page.

On peut également combiner les redirections et les pipes:

du | sort -nr >> monfichier.txt

Les services

Sur un système Linux, le programme gérant les services est le premier programme à être lancé, et il porte le pid numéro 1; il s'agit en général de Systemd (System Daemon). Avant cela on utilisait init System V (AKA SysVinit), dont on retrouve encore certaines traces de nos jours dans les systèmes.

Les services, ou daemons, sont des programmes qui assurent des tâches bien particulières (affichage, réseau, etc...) en arrière-plan, sans que l'on ait nécessairement à les démarrer. Ils sont en fait lancés par des scripts, qui vont permettre de lancer, redémarrer... le service.

Avec Systemd, les configurations sont dans le répertoire : /lib/systemd/system

Avec SystemV, ils sont dans /etc/init.d (ou /etc/rc/d/init.d)

Lorsque l'on se rend dans ce dossier, on peut regarder le contenu des scripts pour avoir une description de leur fonctionnement; on pourra également y ajouter nos propres scripts, pour lancer des programmes au démarrage.

Manipulation des servies avec SystemD

Avec SystemD, tous les services se manipulent via la commande systemctl. Celle-ci a la syntaxe:

systemctl <action> <service>

Si <service> est le nom du service, l'action peut être :

start
stop
restart
reload
status
enable
disable

Par exemple, si je veux redémarrer le serveur web:

systemctl restart apache2

La commande servant à lister les services en cours d'utilisation est:

systemctl list-units --type=service

`Manipulation des services avec SystemV`

La plupart des systèmes utilisent SystemD tout en conservant des commandes (service) SystemV pour la rétrocompatibilité. Les commandes de base sont :

Lister les services et leur état : service --status-all
Redémarrer un service : service <service> restart

Avec les scripts

On peut aussi manipuler les services "à l'ancienne" en utilisant directement les scripts présents dans le dossier /etc/init.d

Pour se faire, la syntaxe est la suivante :

/etc/init.d/<service> <action>

Avec les actions :

start
stop
restart
reload
status

Par exemple, avec mon serveur web je pourrais faire:

/etc/init.d/apache2 restart

Les processus

Les processus (ou tâches) sont les programmes qui sont executés sur la machine. Il en existe deux types:

Des processus système qui sont lancés automatiquement, à une date/heure ou au boot
Des processus lancés par les utilisateurs

Lorsque l'on lance une commande, un processus lui correspondant est créé. Les processus ont diverse caractéristiques:

Un numéro d'identification (Process ID, ou PID)
Un propriétaire
Un groupe propriétaire
Le terminal auquel il est attaché
Un état du processus
Une priorité
Un répertoire de travail

À savoir : le programme init (/sbin/init) est le premier lancé par le système, il a le PID 1 : c'est SystemD !

Un processus a toujours un processus père, appellé PPID (Parent PID), sauf pour init. Ainsi, on a une structure arborescente, avec des processus pères et des processus fils, et init l'ancêtre de tout les processus (la racine de l'arbre, en somme).

Les états : Un processus peut avoir trois états possibles:

prêt (suspendu par l'OS)
élu (en exécution)
bloqué (en attente de quelque chose pour poursuivre)

La commande ps

La commande principalement utilisée pour voir les processus est la commande ps. Elle renvoie 4 colonnes:

PID : Le numéro identifiant le processus
TTY : Le nom de la console depuis laquelle le processus est lancé
TIME : La durée pendant laquelle le processus a consommé du temps auprès du CPU pendant le lancement
CMD : Le programme qui génère le processus

On peut utiliser des arguments :

ps -u <utilisateur> : On peut voir tous les processus lancés par un utilisateur.
ps -ef : voir tous les processus de tous les utilisateurs sur toutes les consoles
pstree -p : affiche les processus sous forme d'arbre.
ps -u <utilisateur> | grep <processus> pour trouver le PID d'un processus (équivalent à pgrep).
kill <PID> : arrêter un processus
kill -9 <PID> : arrêter violemment un processus
killall <nom> : tuer tousles processus en lien à un programme

Installer à partir des sources

Pour extraire une archive .tar.gz : tar -zxvf archive.tar.gz

Vérifier les dépendances : ./configure

puis make et sudo make install

Modifier une variable d'environnement

Pour modifier une variable d'environnement, par exemple PATH:

export PATH=${PATH}:/home/justine/bin #ajouter des choses à la variable

export PATH=/home/justine/bin #Modifier la variable

Cron : le vérifier

Les scripts (si ont les droits en exécution et les bonnes permissions) situés dans les dossiers cron.daily, cron.hourly... etc doivent s'exécuter à intervalles réguliers, sans qu'on ait à passer par un crontab.

Pour vérifier que c'est bien le cas, on peut utiliser la commande :

run-parts --test /etc/cron.daily

Le nom de notre script doit alors s'afficher.

ATTENTION : le fait de laisser l'extension .sh à notre script semble poser problème : il faut l'enlever !

Vider un fichier en cours d'utilisation

Le plus simple pour cela est d'utiliser la redirection suivante :

>/fichier/a/vider

On redirige depuis rien du tout vers le fichier, ce qui le vide.

Linux

Sommaire