City-blog.net - Linux : Console

La recherche de fichiers/répertoires dans la console

ldb — Wed, 14 May 2008 18:24:41 +0000

Il existe bien sûr de bons programmes qui permettent en mode graphique de rechercher un fichier ou un dossier. Mais lorsque j'ai découvert la commande locate, qui permet de recherche via la console, je n'ai plus utilisé une interface graphique. Pour commencer, créer ou mettez à jour votre base de donnée qui vous permettra de rechercher des fichiers dedans :

user@localhost~$ su -
Password :
[root@localhost ~]# updatedb

Cela peut prendre plusieurs minutes avant de se finir. Une fois que c'est fait, recherchez votre fichier ou votre répertoire par son nom en tapant :

locate nom du fichier ou du répertoire

Mais attention, car si vous recherchez un répertoire qui contient de nombreux fichiers et dossiers, vous allez vous retrouver avec une liste démeusurée de résultats. locate (ou slocate dans sa version sécurisée) possède un certains nombre d'options qui vous permettront d'affiner vos résultats. Voici un extrait du manuel de locate à la rubrique Options.

      -u 

   Créer une base de données slocate débutant au chemin /.

      -U <rép>

   Créer une base de données slocate débutant au chemin <rép>.

      -e <rép1,rép2,...>

    Exclure des répertoires de la base de données slocate.

      -f <type_sf1,...>

    Exclure  les  fichiers  situés  dans  des   systèmes   de   fichiers spécifiques de la base de données slocate.

      -c 

    Analyser « /etc/updatedb.conf » lors de la mise à jour de la base de
             données slocate.

      -l <niveau>

    Niveau de sécurité. 0 désactive la sécurisation. Cela accélérera  la recherche.  1  active  la  sécurisation.  C’est  le comportement par défaut.

      -i

    Effectuer une recherche non sensible à la casse.

      -q

    Mode silencieux. Les messages d’erreur sont supprimés.

      -n <nombre>

    Limiter le nombre de résultats affichés à <nombre>.

      -r <regexp>

      --regexp=<regexp>

    Rechercher des fichiers dans la base de données en utilisant une expression rationnelle POSIX de base.

      -o <fichier>

      --output=<fichier>

    Spécifier la base de données à créer.

      -d <chemin>

      --database=<chemin>

    Spécifier  le  chemin  des  bases de données où chercher.

Killer un processus simplement

ldb — Wed, 14 May 2008 17:50:19 +0000

Les utilisateurs de Windows connaissent bien cela : le plantage d'un programme ou d'un service. Et parfois, il n'y a pas d'autre choix que de directement tuer le processus. Sous Windows, il faut appuyer sur Ctrl+Alt+Suppr mais sous Linux c'est différent. Plusieurs méthodes existent. La plus intéressante et aussi la plus simple (pour moi) reste de tuer le processus directement via la console. Voici un exemple avec Gedit :

ldb@localhost:~$ ps aux | grep gedit
ldb 18087 0.4 5.0 333768 22224 ? S 17:35 0:01 gedit
ldb 25076 0.0 0.1 84308 808 pts/1 R+ 17:41 0:00 grep gedit

Il suffit alors de tuer la première ligne en tapant ceci :

kill 18087

Et voilà, le processus de gedit est "tué". A noter que le nombre que j'ai tapé après kill est celui présent sur la première ligne.

Une autre méthode existe en mode graphique, mais personnellement je reste persuadée que via la console, c'est plus simple et plus facile. Voici la méthode graphique pour ceux qui le souhaitent.

Pour que la méthode graphique fonctionne, il faut que les paquets du moniteur système soient installés. Si c'est le cas, voici comment on procède sous Fedora :

Cliquez sur Applications et allez dans le menu Outils système. Ensuite cliquez sur Moniteur système. Quand cela est fait, une fenêtre apparaît avec plusieurs onglet, dont un qui s'appelle Processus. Il s'agit de la liste des processus lancés.
Dans la liste, choisissez celui que vous souhaitez arrêter en cliquant dessus puis cliquez en bas à droite sur Terminer le processus. Votre processus sera alors arrêté.

Enregistrer une commande dans un fichier

ldb — Wed, 30 Apr 2008 20:20:09 +0000

Vous avez un problème avec une commande et vous souhaitez demander de l'aide ? Alors plutôt que de sélectionner toute la commande (et son résultat), de la copier et de la coller dans votre message d'appel au secours, vous pouvez enregistrer la commande dans un fichier et le proposer. Pour résumer, il existe une commande qui permet d'enregistrer une [autre] commande dans un fichier. Elle se présente sous cette forme :

| tee fichier

Par exemple, je veux faire une mise à jour par la console, et comme la dernière fois j'ai eut un problème, cette fois si j'enregistre la mise à jour dans mon fichier pour l'envoyer à ceux qui m'apporteront leur aide. Je tape alors ceci dans ma console :

yum update | tee /home/utilisateur/pb-maj-yum

La mise à jour va s'exécuter et que le problème se reproduise ou non, tout ce qui s'affichera sur ma console sera enregistré dans mon fichier. Cela peut s'avérer pratique quand le déroulement de l'opération est long et plein d'informations utiles.

Par contre, j'ai essayé de taper commande 1 && commande 2 | tee fichier, et ça n'a enregistré que la dernière action. Je suppose donc qu'on ne peut appliquer celle-ci qu'à une seule commande à la fois.

Récupérer plusieurs fichiers simultanément avec WGET

ldb — Wed, 30 Apr 2008 19:32:07 +0000

La commande WGET permet de télécharger des fichiers, lorsque vous en connaissez l'adresse. Rapide, cette méthode de récupération est pratique puisqu'elle ne nécessite pas d'ouvrir un navigateur. C'est également celle qui permet de télécharger des fichiers depuis un serveur ou quand on est connecté via SSH sur un ordinateur distant. Elle se présente sous cette forme :

wget adresse exacte du fichier

WGET permet aussi de récupérer plusieurs fichiers en même temps. La méthode est simple :

Créez un fichier qu'on va appeler liste pour notre exemple ;
Ajoutez dans liste les adresses de vos fichiers. Il faut qu'il y ait une adresse par ligne ;
Tapez ensuite cette commande dans votre console :

wget -i liste

Tous les fichiers seront alors téléchargés sans qu'il soit nécessaire de retaper la commande plusieurs fois.

Une capture en ligne de commande

ldb — Mon, 21 Apr 2008 19:54:37 +0000

Si pour certains cela est inutile (et donc indispensable ! ), il existe une ligne de commande très simple qui permet de prendre au choix des screenshots (captures d'écran) d'un bureau entier ou bien des screenshot d'une zone en particulier (et pas seulement d'une seule fenêtre). Cette commande "appartient" à Imagemagick (qui normalement est installé sur Fedora, en tout cas je n'ai pas eut besoin de cocher sa case à l'installation).

$ import -window root nom_image.extension

Cette commande permet de prendre une capture de l'écran entier. L'extension est affaire de goût, du moment que Imagemagick peut la lire.

$ import -pause N nom_image.extension

N permet de choisir le nombre de secondes avant que votre curseur devienne une croix qui vous permettra de choisir la zone à "shooter" (en glisser/déposer).

Si effectivement une ligne de commande pour prendre un screenshot de l'écran entier peut sembler inutile, en revanche la deuxième commande peut s'avérer nécessaire, par exemple, pour prendre une capture d'un bout d'écran sur lequel (par exemple) se superpose plusieurs fenêtres, sans devoir ouvrir un programme d'édition (TheGimp par exemple) pour redimensionner. Le résultat est celui-ci :

Vous pouvez au passage découvrir sur ce screenshot le résultat de la commande $ df -h que m'a suggéré Pingoured sur un précédent billet. Cela affiche toujours l'espace disque, mais en Giga-Octets

Connaître l'espace disque en deux lettres

ldb — Sat, 19 Apr 2008 19:13:26 +0000

Et oui ! Deux lettres vous suffiront pour connaître ce qu'il reste sur vos partitions

Ouvrez la console et tapez :

$ df

Inutile d'être root, ça marche en simple utilisateur.

Voilà le résultat :

Personnaliser votre console en différenciant le root du prompt

ldb — Sat, 19 Apr 2008 17:07:00 +0000

Il arrive qu'on soit obligé d'utiliser la console pour faire certaines chose, ou même qu'on préfère l'utiliser (par exemple, pour les mises à jour). Parois, on alterne entre le prompt (l'user ; l'utilisateur) et le root dans la console. Afin de rendre la différence plus flagrante, voici deux lignes à rajouter dans les fichiers .bashrc des deux.

Commencez par ouvrir la console et tapez ceci en utilisateur :

$ vim /home/ldb/.bashrc

Ensuite rajoutez cette ligne à la fin :

export PS1=[\t][\e[1;32m]\u[\e[0m]@[\e[1;33m]\h[\e[0m]:[\e[1;37m]\w[\e[0m]\$

Enregistrez et sortez puis connectez vous en root sur la console en tapant su - suivi et votre mot de passe root. Tapez alors ceci dans la console :

# vim /root/.bashrc

Vous n'avez alors plus qu'à ajouter cette ligne avant d'enregistrer et quitter :

export PS1='[\t][\e[41;1;37m]\u@\h:\w[\e[0m]\$'

Fermez puis rouvrez votre console et voilà. Non seulement vous avez une différence de couleur au niveau du prompt et du root, mais en plus vous avez l'heure qui s'affiche.

D'autres couleurs et d'autres formes de personnalisation existent. Vous pouvez trouver une traduction du manuel ici : Shell Linux : personnalisez votre console avec des astuces en tout genre.

Rediriger les mails root

ldb — Fri, 18 Apr 2008 17:58:10 +0000

Si vous trouvez que la commande mail n'est pas pratique alors la solution est de faire suivre les mails que reçoit le root de votre distribution vers une autre adresse mail. Une solution simple et facile à mettre en place (à condition d'avoir postfix ou sendmail, ce qui je crois est installé par défaut sous Fedora).

Commencez par vous logger en root dans une console et éditez le fichier /etc/aliases :

# vim /etc/aliases

En bas de la liste ajoutez ceci :

root: mail@domaine.com

Bien évidemment remplacer mon@domaine.com par votre e-mail.
Enregistrez votre travail puis quittez en tapant :wq. Ensuite vous n'avez plus qu'à recharger les alias comme suit :

# newaliases

Voilà, vous recevrez maintenant vos mails root dans la boîte mail de votre choix. Pour être sûr que cela marche, tapez ceci dans la console :

# echo "Salut ton test marche a la perfection" |mail -s test-mail root

Administration Linux à 200% : 100 trucs, secrets et techniques

ldb — Sat, 12 Apr 2008 16:12:41 +0000

Un collègue m'a filé un livre sur Linux il y a quelques semaines, et depuis, j'ai passé en revue le moindre de ses recoins., le titre du livre, qui est également le titre de ce billet, m'a fait pensé en premier lieu qu'il ne s'agissait que d'un livre destinés aux pros du pengouin, gérant de nombreux serveurs et recherchant des solutions de facilité pour leur travail.

En fait, j'avais à la fois tord et raison. Ce livre est bien entendu destiné aux administrateurs recherchant quelques astuces pour faciliter leur travail et améliorer les performences des machines qu'ils administrent. Mais il est également destiné à des utilisateurs (bien que ce ne soit pas le but final) d'un niveau intermédiaire cherchant à progresser et optimiser leur machine.

On y apprend ainsi quelques notions de base sur les serveurs Linux avec entre autre un cours complet sur comment allèger la gourmandise en ressources système de la machine, suppression des services inutils, accélération des compilations, suppression des exécutables inutiles, limitation de la monopolisation du disque dur, gestion des ressources système par processus, etc... Les autres chapitres nous apprennent à choisir et gérer les sauvegardes, monter et protéger son réseau, surveiller le système, utiliser et optimiser SSH. Mais le livre aborde également les serveurs web en plus de proposer des scripts pour améliorer sa machine.

Je conseil ce livre à tous, même s'il faut un certains niveau pour comprendre l'auteur et ce qu'il dsire nous faire faire.

Administration Linux à 200% 100 trucs, secrets et techniques
Par Rob Flickenger, traduit par Joëlle Cornavin & François Cerbelle
Edition O'REILLY
35 euros environ

Compiler son Kernel sous Linux

ldb — Sat, 12 Apr 2008 13:23:11 +0000

S’il y a une chose de “difficile” ou plutôt de “faillible” sous Linux, c’est bien ça, la compilation du noyau (kernel) ! Une erreur dans la manipulation ou la compilation, et vous obtenez un kernel panic très… emmerdant ! C’est pourquoi il est toujours recommandé de ne jamais remplacer les entrèes de Grub ou Lilo par le kernel que vous venez de compiler, mais plutôt d’ajouter l’entrée aux autres. Sans quoi, vous serez obligé de passer par un LiveCD pour réparer tout ça, ou pire, de formater si vous n’avez pas de LiveCD.

Voici donc une petit explications sur le Kernel et sa compilation, accompagnée de divers liens utils pour demander de l’aide, le télécharger, ou autre.

Le kernel, sa place et son histoire

Ce qu’il faut d’abord savoir, c’est que Linux est un “descendant” de Unix. Et qu’Unix, c’est un système d’exploitation qui était très apprécié, notamment pour son support de nombreuses architectures, mais aussi sa stabilité.

C’est alors que Linus Torvald, alors étudiant à l’université d’Helsinki (Finlande), dédice de créer une version d’Unix librement diffusable. Depuis beaucoup de programeurs participent à la construction et l’amélioration du noyau, surtout depuis le développement d’Internet. Toutes les personnes compétentes sont d’ailleurs invitées à participer.

Le 5 octobre 1991, Linus délivra la toute première version “officielle” de Linux (0.02), la version 0.01 n’étant pas executable, sauf sur les système Minix dont Linus se sera inspiré. A défaut d’autre chose, le système était à présent capable d’exécuter bash (le Bourne Again Shell de GNU) et gcc. Les premières moutures de Linux, en effet, étaient surtout destinées aux hackers et se focalisaient sur le développement du noyau, ce qui explique l’absence de service d’assistance technique, de documentation, etc. Dans une moindre mesure, la communauté Linux considère encore aujourd’hui ces aspects comme très secondaires en regard de la “vraie programmation” : le développement du noyau.

Voici un appel de Linus Torvald effectué à l’époque de comp.os.minix :

Vous regrettez les beaux jours de Minix-1.1, époque bénie où les hommes étaient dignes de ce nom et écrivaient leurs propres pilotes de périphériques ? Vous cherchez à vous investir dans un projet original et vous vous languissez d’un système modifiable à votre convenance ? Vous êtres frustré que tout fonctionne sous Minix ? Vous regrettez les nuits blanches passées à tenter d’implanter un programme récalcitrant ? Si tel est le cas, lisez ce qui suit : Comme signalé il y a un mois, je travaille actuellement sur une version libre d’un système analogue à Minix pour ordinateur AT-386. Ce système est à présent utilisable (mais peut-être ne vous conviendra-t-il pas, tout dépend de ce que vous recherchez) et je compte en diffuser les sources. Il s’agit pour l’instant de la version 0.02, capable néanmoins d’exécuter bash, gcc, gnu-make, gnu-sed, compress, etc.

Depuis, les noyaux n’ont de cesse de se succéder, s’améliorant à chaque fois et supportant de plus en plus de périphériques, parfois mieux que d’autres OS (Opérateur Système) Aujourd’hui, le noyau Linux est concidéré comme l’un des meilleurs avec BSD et celui de MacOS basé également sur Unix.

Le kernel : son rôle, pourquoi le mettre à jour, etc…

Le rôle du noyau Le kernel joue le rôle d’intermédiaire entre vos programmes et votre matériel. Premièrement, il gère la mémoire pour tous les programmes en cours d’exécution (processus), et s’assure qu’ils occupent tous une part équitable (ou non) du temps processeur. En plus, il fournit une interface (simple à utiliser) aux programmes pour communiquer avec votre matériel (appels système).

Bien sûr c’est un petit peu plus compliqué que ça, mais ces fonctions de bases sont les plus importantes à connaître.

Pourquoi le mettre à jour ? Les nouveaux noyaux offrent plus de facilité pour communiquer avec plus de matériels (c’est-à-dire qu’ils gèrent plus de périphériques…), ils peuvent avoir une meilleure gestion des processus, tourner plus rapidement que les anciennes versions, être plus stables et ils corrigent les erreurs stupides des versions précédentes. Beaucoup de gens mettent à jour leurs noyaux car ils veulent avoir les nouveaux pilotes de périphériques et les corrections d’erreurs.

Les modules chargeables ? Kesako ? Ce sont des parties du noyau (pilotes de périphériques généralement) qui ne sont pas compilées dans celui-ci. On peut les compiler séparément, les insérer et les retirer du noyau à n’importe quel moment. En raison de cette souplesse, c’est devenu la méthode préférée pour coder certaines fonctionnalités du noyau. Bon nombre de pilotes de périphériques tels que PCMCIA et les gestionnaires de cartouches QIC-80/40 sont des modules chargeables.

Voilà, j’espère que ces quelques explications vous auront été utiles. Passons maintenant aux choses sérieuses, la compilation !

La compilation

Tout d’abord, il va vus falloir réccupérer les sources de votre noyau pour pouvoir le compiler. Pour cela, il suffit de vous rendre sur le site officiel et de télécharger la dernière version stable (en haut de la liste) en cliquant sur le “F” qui vous permettra de télécharge toutes les sources du kernel.

Enregistrez le dans votre dossier personnel et décompressez le (clique droit si vous avez KDE avec Ark d’installé, sinon tapez tar xvf linux.*version*.tar.bz2 dans la console.

Maintenant que vous avez les sources, vous allez pouvoir commencer à le configurer et le compiler.

Pour cela : - Ouvrez la console (le shell) - loggez vous en root en tapant : su Il va alors vous demander votre passe root. - allez dans le dossier dans lequel vous avez décompressé vos sources en tapant ‘cd’ suivit du chemin du dossier

Ensuite, vous allez devoir suivre ces instructions à la lettre pour éviter tous les problèmes.

Dans la console faites :

make oldconfig -> Il va alors réccupérer votre ancienne config pour la calquer sur celle du future kernel afin de ne pas perdre votre configuration actuelle. Il se peut qu’il vous demande quelques trucs, si vous n’êtes pas sùr, mettez la réponse par défaut (en majuscule parmi celles entre crochets).

make menuconfig -> Cela vous permettra de revoir votre configuration et de changer ou non quelques trucs. Nous verrons après à quoi correspond les titres du menu principal.

make clean make bzImage -> Notez bien le dossier d’installation du fichier bzImage qu’il va vous indiquer. Cela nous servira pour la suite.

make modules make modules_install make install

Et voilà votre kernel compilé et installé.

Normalement, lilo a déjà été modifié et rechargé, et vous n'avez plus qu'à redémarrer pour tester votre nouveau Kernel...

Posté le 23 Septembre 2005 sur mon Blog d'origine.