Utilisation de grep

[renaud26]

Bonjour à tous,

Je souhaiterais rechercher une ligne particulière dans tous les fichiers du serveur. Cette ligne est du genre :

/usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so

J'ai vu que la commande GREP pouvait faire ce genre de choses. J'ai essayé avec l'option -x mais on dirait que ça rame et que rien ne sort. Mais je voulais éviter les fichiers "permission denied" et autres inaccessibles.

Quelle serait la bonne méthode ?
Peut-être pas GREP ? Une autre option ?
Merci de vos lumières.

[becket]

Code :

1
2
 
find /CHEMIN  -type f -exec grep -l LIGNERECHERCHEE {} \; 2> /dev/null

[renaud26]

Bonsoir et merci de ta réponse,

Comme je suis débutant, peux tu me préciser :

find /CHEMIN -type f -exec grep -l LIGNERECHERCHEE {} \; 2> /dev/null

CHEMIN : si je veux une recherche complète, je dois mettre /root ?

Ce qui donnerait, pour mon exemple :

Code :

1
2
 
find /root  -type f -exec grep -l /usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so  {} \; 2> /dev/null

Ni guillemets ni apostrophe autour de LIGNE RECHERCHEE ?

[chardclo]

bonsoir,

Code :

grep -lR '/usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so' / 2>/dev/null

[renaud26]

Bonsoir, merci de ton passage.

Ton expression est différente. Du coup...


Je suis un peu paumé.
Je la teste. C'est sans danger pour le serveur ?

[frp31]

Envoyé par renaud26

Bonsoir, merci de ton passage.

Ton expression est différente. Du coup...


Je suis un peu paumé.
Je la teste. C'est sans danger pour le serveur ?

grep ne fait que "lire" du contenu et l'afficher il ne modifie rien.

[renaud26]

Bonjour,

Ok merci, c'est rassurant.
J'ai donc, hier soir, testé :

grep -lR '/usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so' / 2>/dev/null

Et ce matin, 12h00 plus tard, le curseur est toujours sous l'instruction et rien ne s'est affiché, comme si il devait "scanner" 1 milliard de lignes. Pourtant le serveur n'a encore aucun site installé...
Normal ou étrange?

[chardclo]

Bonjour,

Envoyé par renaud26

dans tous les fichiers du serveur

J'ai donc mis "/" comme dossier de base... grep va donc rechercher sur la totalité des dossiers qui sont connus par ton serveur....y compris les fichiers se trouvant dans l'arborescence des points de montage....

A toi de cibler ta recherche...

[renaud26]

Bonjour,

Euh...jour N° 2 et la console affiche toujours la même chose : le curseur est bloqué sous la ligne de commande et rien ne se passe. Je ne vois pas défiler de lignes, façon "scanner", il ne se passe rien. Mais ça fait maintenant 36 heures... Il y a tant que ça de fichiers à passer au crible ?
Cibler, je ne peux pas plus, j'ignore complètement où se trouve ce fichier.
Mais est-ce que la commande est correcte ? On dirait quand même que ça patine un peu.
Merci de vos conseils.

[Sve@r]

Envoyé par renaud26

Je la teste. C'est sans danger pour le serveur ?

Salut
Aucune action que tu peux faire n'est dangereuse pour le serveur (ou pour toute machine Unix) si
1) les droits ont bien été positionnés (ou simplement pas été ouverts par rapport aux droits mis par défaut)
2) si tu prends soin de ne jamais bosser sous root (devenir root ponctuellement pour un besoin précis oui, mais pas bosser de façon généralisée sous root)

Envoyé par renaud26

Ton expression est différente. Du coup...


Je suis un peu paumé.

becket a utilisé un mix de 2 commandes

Code :

find /chemin-type f -exec grep -l LIGNERECHERCHEE {} \; 2> /dev/null

1) la commande find qui permet de rechercher des fichiers à partir d'un point de départ "/chemin". Ici il demande la recherche de tout fichier classique "-type f" (on n'espère pas trouver une chaine dans un dossier ou un fichier spécial).
2) chaque fichier trouvé sera passé via "-exec" à la commande "grep" qui cherchera "lignecherchée" dans le fichier trouvé par find, fichier symbolisé par les accolades {}. Pour que find sache où s'arrête la commande "grep", il faut la terminer par un point-virgule mais ce point-virgule ne doit pas être intercepté par ton interpréteur shell donc on le protège par un backslash.

Et enfin il se peut que tu n'aies pas accès à toute l'arborescence (cause droits). Dans ce cas, find n'y a pas accès non plus et te renvoie un message disant qu'il ne peut pas y accéder, ce message transitant par le canal des erreurs n° 2. Pour ne pas que ce message te gêne, on le redirige dans /dev/null

chardclo utilise une commande grep un peu plus élaborée

Code :

grep -lR '/usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so' / 2>/dev/null

Il demande ici à grep d'assurer lui-même la recherche récursive avec l'option "-R". Bref il demande à grep de faire le travail de find.
Certaines commandes ont été en effet reprises pour faire un peu plus que les commandes d'origine.

La syntaxe de becket est une syntaxe généraliste, très dans le principe Unix qui dit qu'une commande ne fait qu'un travail mais le fait bien et c'est en les mixant ou les reliant plusieurs commandes les unes aux autres qu'on peut faire des traitements complexe. Cette syntaxe marchera sur tous les Unix du monde quel que soit ton besoin.
La syntaxe de chardclo est une syntaxe utilisant certaines commandes souvent utilisées dans certaines configuration qui ont alors été optimisées pour pouvoir intégrer elles-mêmes la configuration en question sans passer par une autre commande préalable. Ca ne marchera que dans des cas très spécifiques (sur les Unix récents pour une configuration précise)

Envoyé par renaud26

Et ce matin, 12h00 plus tard, le curseur est toujours sous l'instruction et rien ne s'est affiché, comme si il devait "scanner" 1 milliard de lignes. Pourtant le serveur n'a encore aucun site installé...
Normal ou étrange?

Pour moi c'est normal. chardclo a oublié que sa commande allait scanner tous les fichiers de l'arborescence, y compris les pipes. Or, tout processus qui lit un pipe reste bloqué tant qu'un autre processus ne vient pas y écrire dedans...
A moins que grep -R sache éviter les pipes et dans ce cas mon hypothèse n'est pas bonne (je ne connais pas les détails de l'option "-R"). Mais tu devrais essayer la syntaxe de becket pour voir car avec la sienne, en ne demandant que les fichiers de type f, tu es sûr de ne pas choper les fichiers de type p...

Envoyé par renaud26

CHEMIN : si je veux une recherche complète, je dois mettre /root ?

Si tu mets /root ta recherche ne débutera qu'à partir de /root. Si tu veux une recherche sur toute l'arborescence, il faut mettre la base de l'arborescence donc "/"

Envoyé par renaud26

Je ne vois pas défiler de lignes, façon "scanner"

Unix est un système de professionnels et non une série grand guignolesque à la façon des experts Miami. Il ne t'affiche que les infos que tu demandes et les infos d'échec...

Envoyé par renaud26

Mais ça fait maintenant 36 heures... Il y a tant que ça de fichiers à passer au crible ?

36 heures !!!??? Si une commande aussi basique qu'un grep tourne plus de 10 minutes tu peux l'arrêter, c'est qu'il y a un problème ; probablement le coup des pipes. Comme quoi parfois, les principes de nos sages ancêtres Unixiens avaient du bon et essayer de vouloir "gonfler" artificiellement certaines commandes en oubliant certains détails amène plus de malheurs qu'autre chose...

[renaud26]

Bonjour et merci beaucoup pour ton explication claire et détaillée.
J'ai donc lancé une recherche avec la commande de becket, on va bien voir.

Par contre :

2) si tu prends soin de ne jamais bosser sous root (devenir root ponctuellement pour un besoin précis oui, mais pas bosser de façon généralisée sous root)

Comme j'ignorais cela, je me logue toujours en root dans la console...tout ce qu'il ne faut pas faire, donc. Mais pourquoi ? Comment dois-je me loguer ?

En fait, le but de ma recherche, c'est que j'ai installé ssh2 avant hier et depuis, tous les matins, je reçois des emails du système (depuis Watchdog Plesk) :

PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so' - /usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so: cannot open shared object file: No such file or directory in Unknown on line 0

Et sur le forum PLesk, on ma conseillé de rechercher le fichier qui appelle l'extension ssh2 par cette commande "/usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so ...vu que sur ce serveur, il n'y a pas de dossier "extension" dans usr/lib64. Il faudrait donc que je trouve cette ligne et que je la modifie pour mettre le bon chemin vers les extensions de PHP.
Enfin je crois...
Parce que ce sont vraiment mes tous premiers pas dans le monde de Linux...

[Sve@r]

Envoyé par renaud26

Comme j'ignorais cela, je me logue toujours en root dans la console...tout ce qu'il ne faut pas faire, donc. Mais pourquoi ?

Parce que les droits Unix ne s'appliquent pas à root et qu'il peut tout faire y compris des conneries...

Envoyé par renaud26

Comment dois-je me loguer ?

Tu te crées un compte "renaud26" qui sera comme tout le monde et tu te logues sous ce compte. Et si t'as besoin d'exécuter une action précise en tant que root, alors tu tapes

Code :

1
2
3
4
5
6
su root
ta commande1
ta commande2 éventuelle
ta commande3 éventuelle
...
exit

Envoyé par renaud26

En fait, le but de ma recherche, c'est que j'ai installé ssh2 avant hier et depuis, tous les matins, je reçois des emails du système (depuis Watchdog Plesk) :

Et sur le forum PLesk, on ma conseillé de rechercher le fichier qui appelle l'extension ssh2 par cette commande "/usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so ...vu que sur ce serveur, il n'y a pas de dossier "extension" dans usr/lib64. Il faudrait donc que je trouve cette ligne et que je la modifie pour mettre le bon chemin vers les extensions de PHP.
Enfin je crois...

Oui ça semble cohérent

Envoyé par renaud26

Parce que ce sont vraiment mes tous premiers pas dans le monde de Linux...

Where no man has gone before...

[renaud26]

Merci pour ta patience et ta gentillesse.
Je reviendrai ici pour donner les résultats de ma requête et mettre ce post en résolu.
Bonne journée !

[chardclo]

Bonjour,

Envoyé par Sve@r

Pour moi c'est normal. chardclo a oublié que sa commande allait scanner tous les fichiers de l'arborescence, y compris les pipes. Or, tout processus qui lit un pipe reste bloqué tant qu'un autre processus ne vient pas y écrire dedans...
A moins que grep -R sache éviter les pipes et dans ce cas mon hypothèse n'est pas bonne (je ne connais pas les détails de l'option "-R"). Mais tu devrais essayer la syntaxe de becket pour voir car avec la sienne, en ne demandant que les fichiers de type f, tu es sûr de ne pas choper les fichiers de type p...

Tu dis dans le vrai... j'ai complétement zapé ce comportement !!
honte à moi

[zipe31]

Salut,

Envoyé par chardclo

Bonjour,

Tu dis dans le vrai... j'ai complétement zapé ce comportement !!
honte à moi

A ce moment là voir du côté des options "-D" et "-d" de grep :

-D ACTION, --devices=ACTION
If an input file is a device, FIFO or socket, use ACTION to process it. By default, ACTION is read, which means that devices are read just as if they were
ordinary files. If ACTION is skip, devices are silently skipped.

-d ACTION, --directories=ACTION
If an input file is a directory, use ACTION to process it. By default, ACTION is read, which means that directories are read just as if they were ordinary
files. If ACTION is skip, directories are silently skipped. If ACTION is recurse, grep reads all files under each directory, recursively; this is
equivalent to the -r option.

[Sve@r]

Envoyé par zipe31

Salut,



A ce moment là voir du côté des options "-D" et "-d" de grep :

Bien vu - J'ai appris quelque chose

Envoyé par Sve@r

Comme quoi parfois, les principes de nos sages ancêtres Unixiens avaient du bon et essayer de vouloir "gonfler" artificiellement certaines commandes en oubliant certains détails amène plus de malheurs qu'autre chose...

Comme quoi j'aurais dû aussi me rappeler aussi que les développeurs gnu ne sont pas des branques et que quand ils font quelque chose, ils produisent quand-même un travail de qualité...

[renaud26]

Bonjour à tous,

Me voici de retour 30h00 plus tard.
Ma console est toujours au même point : sous la commande, le curseur est bloqué et rien ne se passe. Je ne sais même pas si ça "travaille"...

Sur les conseils de Sve@r, j'ai utilisé la commande de becket :

Code :

1
2
 
find /  -type f -exec grep -l /usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so  {} \; 2> /dev/null

Je ne sais plus trop quoi faire... Il n'existerait pas une option qui affiche les fichiers scannés pour que, au moins, je puisse voir que ce n'est pas bloqué ?

Merci de votre aide.

[zipe31]

Salut,

Envoyé par renaud26

Je ne sais plus trop quoi faire... Il n'existerait pas une option qui affiche les fichiers scannés pour que, au moins, je puisse voir que ce n'est pas bloqué ?

Merci de votre aide.

Retire le 2> /dev/null à la fin, tu verras déjà les messages d'erreurs signe que la commande mouline un tant soit peu

Tu peux aussi t'intéresser à l'option "-prune" de find afin d'éluder certains répertoires de l'arborescence...

Exemple "-prune"

Voir aussi les exemples dans le man find

[Sve@r]

Envoyé par renaud26

Bonjour à tous,

Me voici de retour 30h00 plus tard.

Comme je te l'ai dit, tu aurais dû arrêter au bout de 10mn...

Envoyé par renaud26

Sur les conseils de Sve@r, j'ai utilisé la commande de becket :

Code :

find /  -type f -exec grep -l /usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so  {} \; 2> /dev/null

Je ne sais plus trop quoi faire... Il n'existerait pas une option qui affiche les fichiers scannés pour que, au moins, je puisse voir que ce n'est pas bloqué ?

Oui, bien sûr
Tu vas taper les instructions suivantes, ligne par ligne

Code bash :

1
2
3
4
5
find / -type f -print 2>/dev/null |while read f
do
echo "scanning $f"
grep -l "/usr/lib64/extensions/no-debug-non-zts-20060613/ssh2.so" "$f" && echo "trouvé dans $f"
done

T'inquiète pas si le prompt qui apparait à chaque ligne prend la forme ">", ça veut dire que le shell attend la suite des instructions. Donc là, tu verras la liste des fichiers scannés défiler...

[chardclo]

Bonjour,

Juste pour le "fun" :

Code :

find / -type f  \( -exec /usr/bin/printf "%s : " {} \; -exec grep -q '/usr/lib64/extensions/no-debug-non-zts-20060613/ssh2\.so' {} \; -exec /usr/bin/printf "ok\n" \; -o -exec /usr/bin/printf "ko\n" \; \)