Bonjour à tous,

Pour les besoins d'un projet, il me faut écrire un programme de contrôle qui doit se lancer automatiquement après le chargement de l'O.S., NanoBSD en l'occurence .

Mes questions:

1 - Est-ce cela que l'on appele un script ?
2 - Est-il possible d'automatiser l'exécution de ce programme avant le login ou pas ?
3 - Ce programme doit exécuter une commande (dmidecode) qui va écrire dans un fichier texte.
Quelle est l'expression dans un fichier source C qui permet d'exécuter une commande (dmidecode dans ce cas) ?
Merci ! ;)

Quote:

1 - Est-ce cela que l'on appele un script ?

Non, un script est un langage interprété, et qui ne nécessite pas de compilation
-perl,ruby,python,sh,bash sont des langages de script
- c,C++,java n'en sont pas


Quote:

2 - Est-il possible d'automatiser l'exécution de ce programme avant le login ou pas ?

Oui, tu appelles ton programme dans /etc/rc.local, comme le monsieur te l'explique là  


Quote:

3 - Ce programme doit exécuter une commande (dmidecode) qui va écrire dans un fichier texte.

Il n'y a la aucun problème, fais tout de même attention à donner le chemin absolut du fichier, ainsi que le chemin complet de l'exécutable.

Voila, c'était tout ?  ;)


Quote:

Quelle est l'expression dans un fichier source C qui permet d'exécuter une commande (dmidecode dans ce cas) ?

exec(3), mais attention elle est recouvrante.

Je prends de l'avance sur ta prochaine question : http://www.ai.univ-paris8.fr/~jk/C/Sys/td_6/node1.html

Merci ros pour tous ces éclaircissements ;)
Je vais regarder tout ça de près avant de poser de nouveau une question... ;D
Et même trouver la question que j'étais censé poser au moment de poster ce post-ci ! :D

Salut à tous,

Bon ros, j'ai réfléchi toute la nuit à la question que je pourrais te poser ! :)

En fait, j'en ai deux ! ;D


1 - Qu'est-ce qu'une expression recouvrante ? Y a-t-il un risque à l'employer ? (Ok, là ça fait deux questions en une, je triche un peu...)

2 - Au niveau sécurité, le fait de faire exécuter de façon automatique un programme en le placant dans  /etc/rc.local, est-ce facilement contournable ? Je veux dire, par exemple, une personne mal attentionnée (non non je ne suis pas parano...) pourrait-elle démarrer en mode single-user ou afficher le prompt du chargeur (ou toute autre processus visant à contourner l'exécution du programme) et aller modifier le  /etc/rc.local ?
Merci ! ;)

Ecureuil wrote on 27. Nov 2008 at 08:25:

1 - Qu'est-ce qu'une expression recouvrante ? Y a-t-il un risque à l'employer ? (Ok, là ça fait deux questions en une, je triche un peu...)

La formule est étrange, mais bon… ros veut simplement attirer ton attention sur le fait qu'exec(2) remplace le processus courant (il faut donc forker avant).

Ecureuil wrote on 27. Nov 2008 at 08:25:

2 - Au niveau sécurité, le fait de faire exécuter de façon automatique un programme en le placant dans  /etc/rc.local, est-ce facilement contournable ? Je veux dire, par exemple, une personne mal attentionnée (non non je ne suis pas parano...) pourrait-elle démarrer en mode single-user ou afficher le prompt du chargeur (ou toute autre processus visant à contourner l'exécution du programme) et aller modifier le  /etc/rc.local ? Merci ! ;)

D'une façon générale, la sécurité «tout court» inclut la sécurité physique… donc empêcher l'accès à la machine. Après, tu peux quand même «blinder» un peu (flagger la console en «insecure» dans ttys(8), chiffrer le disque, etc.)

fgudin wrote on 27. Nov 2008 at 08:55:

Ecureuil wrote on 27. Nov 2008 at 08:25: 1 - Qu'est-ce qu'une expression recouvrante ? Y a-t-il un risque à l'employer ? (Ok, là ça fait deux questions en une, je triche un peu...) La formule est étrange, mais bon… ros veut simplement attirer ton attention sur le fait qu'exec(2) remplace le processus courant (il faut donc forker avant).

Bonjour francis, que veux-tu dire par remplacer le processus courant ?
En quoi cela consiste-t-il, comme cela se manifeste-t-il ?
J'ai bien regardé ici http://jargonf.org/wiki/fork mais n'ai pas tout saisi...


fgudin wrote on 27. Nov 2008 at 08:55:

Ecureuil wrote on 27. Nov 2008 at 08:25: 2 - Au niveau sécurité, le fait de faire exécuter de façon automatique un programme en le placant dans  /etc/rc.local, est-ce facilement contournable ? Je veux dire, par exemple, une personne mal attentionnée (non non je ne suis pas parano...) pourrait-elle démarrer en mode single-user ou afficher le prompt du chargeur (ou toute autre processus visant à contourner l'exécution du programme) et aller modifier le  /etc/rc.local ? Merci ! ;) D'une façon générale, la sécurité «tout court» inclut la sécurité physique… donc empêcher l'accès à la machine. Après, tu peux quand même «blinder» un peu (flagger la console en «insecure» dans ttys(8), chiffrer le disque, etc.)

Ok, merci francis pour toutes ces infos, je vais m'atteler à tout cela...

Pour finir, dans /etc/rc.local, est-il possible de faire exécuter un programme en C en indiquant le plus simplement du monde le nom du dit programme ou bien doit-on le faire exécuter en l'appelant dans un script ?

Je crois que les journées à venir vont êtres longues, mais longues... :-?

Merci. ;)

Salut,
Je t'avoues que ça risque d'être difficile si on doit repasser les bases de la programmation UNIX.
Je te renvoies don sur ce site qui à pas l'air trop mal.

http://drocourt.iut-amiens.fr/cours/Unix/C-Programmation_Systeme/prog_sys.xhtml

Euh... Ros tu veux me plomber le moral là où quoi ?!? :o
Je sais bien qu'il va falloir que j'en passe par là, j'ai d'ailleurs acheté un bouquin à cet effet (Programmation système en C sous Linux) mais là il me faut parer au plus pressé...

Je "n'ai besoin que de quelques infos pertinantes" pour dégrossir et me mettre sur les rails pour pondre ce que l'on me demande.

Ma question: dans /etc/rc.local, est-il possible de faire exécuter un programme en C en indiquant le plus simplement du monde le nom du dit programme ou bien doit-on le faire exécuter en l'appelant dans un script ?
Merci. ;)

La réponse est oui, on peut. Un script n'est finalement qu'un appel implicite à un binaire (p.ex /bin/sh) avec comme paramètre le fichier de script à éxecuter.

par exemple l'appel à

Code (]/usr/scripts/do_somephing.sh[/code):

est équivalent à [code]/bin/sh /usr/scripts/do_somephing.sh

Merci à toi Ros.
Si j'ai bien compris, je peux donc tout aussi bien dans mon /etc/rc.local faire  un...:
[code]/usr/script/mon_programme[/code]
...là où mon_programme est un exécutable généré à partir d'un fichier source C ?

Non tu dois la compiler avant avec la commande suivante

[code]cc monprograme.c -o monprogramme[/code]

puis le copier la ou ça va bien et l'appeler depuis rc.local

ros wrote on 27. Nov 2008 at 16:45:

Non tu dois la compiler avant avec la commande suivante Code (]cc monprograme.c -o monprogramme[/code): puis le copier la ou ça va bien et l'appeler depuis rc.local Ok, compiler, ça, je savais qu'il fallait le faire ! ;D Merci Ros. J'essaie d'avancer un peu, j'ai fait plusieurs choses: 1  - J'ai crée dans /etc le fichier rc.local et mis dedans la commande suivante: [code]/usr/sbin/dmidecode > /usr/home/admin/info_sys.txt

J'ai rebooté et j'ai bien obtenu le résultat attendu, à savoir un joli petit fichier texte avec plein d'infos hardware sur ma machine.

2 - Comme je souhaite par la suite lire le fichier ainsi généré, je me suis dit que j'allais faire ça au travers d'un petit programme de rien du tout en C, sauf que de bien entendu, y a comme une couille dans le potage (non, vraiment...?!?).
En voici le code:
[code]#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

int
main(void)
{
     execl("/usr/local/sbin/dmidecode", ">", "/usr/home/admin/info_sys.txt", NULL);
     return EXIT_SUCCESS;
}[/code]

Pas d'erreur à la compilation, j'exécute mon programme dans mon interpréteur et au lieu de générer mon fichier texte info_sys.txt, cela me lance directement dmidecode dans l'interpréteur... ::)

(pressé, désolé…)
fork() puis exec(), ou encore system()

fgudin wrote on 27. Nov 2008 at 17:22:

(pressé, désolé…)

Ne sois surtout pas désolé d'être pressé, c'est déjà bien sympa à vous tous de donner un coup de pouce à un newbie like me, même si c'est le but d'un forum je vous l'accorde, mais cela n'empêche pas...
Donc merci encore. ;)


fgudin wrote on 27. Nov 2008 at 17:22:

fork() puis exec(), ou encore system()

J'ai donc rajouté un fork() avant ma ligne execl(...), même combat, pas de fichier info_sys.txt généré et dmidecode qui se lance dans l'interpréteur quand j'exécute mon programme.

Code (]execl("/usr/local/sbin/dmidecode", ">", "/usr/home/admin/info_sys.txt", NULL);[/code):

Ah non tu ne peux pas faire ça comme ça ! Explication : > est une redirection du shell, dmidecode ne sais pas gérer l'option ">" pas plus que "/usr/home/admin/info_sys.txt" Alors comment faire ? Les pipes ! dmidecode ecrit sur la sortie standard, qui est un descripteur de fichier (1 ) il te faut donc faire une redirection de ta sortie standard vers un pipe ou un fichier (ça marche mais c'est moins beau. Voici un exemple illustré de ls, c'est tout simple, on ne verifie même pas que ça marche et on ne contrôle pas les erreurs, mais c'est une bonne base. [code]#include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <sys/stat.h> #include <fcntl.h> int main(void) {   /* On ouvre un fichier */   int pfd = open("CON",O_WRONLY|O_CREAT|O_TRUNC,S_IRWXU);   /* On substitue STDOUT au descripteur de fichier */   dup2(pfd, STDOUT_FILENO);   /* On ferme FD dont on n'a plus besoin */   close(pfd);   /* On execute la commande */   execl("/bin/ls","ls",NULL);   /* On n'arrive là qu'en cas d'erreur */   return EXIT_SUCCESS; }

Merci beaucoup Ros, surtout pour l'explication.
Effectivement, je pouvais toujours essayer, ça risquait pas de fonctionner.
J'ai appris un truc de plus et dormirai "moins bête" ce soir ! ;D
Je vais regarder ton exemple avec ls de près et quand serai arrivé à le faire fonctionner avec dmidecode, je ferai ça avec pipe, j'aime bien quand c'est beau moua... :)

Encore merci. ;)

non, non, c'est pas obligé, les pipes ne sont pas utiles, tu peux faire comme ça
il faut juste rajouter les contrôles des retour erreur.

Merci ros, je suis à bosser sur ce bout de code et au passage gloire à ceux qui ont crée les man pages !

Par contre, quelqu'un pourrait-il m'expliquer la subtilité qu'il y a à placer un script et/ou une commande à exécuter au démarrage du système soit dans /etc/rc.local ou dans /etc/rc.d comme s'est expliqué ici: http://www.freebsd.org/doc/fr_FR.ISO8859-1/books/handbook/
Merci. ;)

man est omniscient et te donne la réponse :

Quote:

The rc.local script contains commands which are pertinent only to a specific site.  Typically, the /usr/local/etc/rc.d/ mechanism is used instead of rc.local these days but if you want to use rc.local, it is still supported.  In this case, it should source /etc/rc.conf and contain additional custom startup code for your system.  The best way to handle rc.local, however, is to separate it out into rc.d/ style scripts and place them under /usr/local/etc/rc.d/. The rc.conf file contains the global system configuration information referenced by the startup scripts, while rc.conf.local contains the local system configuration.

sources : rc(8)
aka man 8 rc
aka man rc.local

ros wrote on 28. Nov 2008 at 13:34:

man est omniscient et te donne la réponse : Quote: The rc.local script contains commands which are pertinent only to a specific site.  Typically, the /usr/local/etc/rc.d/ mechanism is used instead of rc.local these days but if you want to use rc.local, it is still supported.  In this case, it should source /etc/rc.conf and contain additional custom startup code for your system.  The best way to handle rc.local, however, is to separate it out into rc.d/ style scripts and place them under /usr/local/etc/rc.d/. The rc.conf file contains the global system configuration information referenced by the startup scripts, while rc.conf.local contains the local system configuration. sources : rc(8) aka man 8 rc aka man rc.local

Merci ros, il faut vraiment que j'adopte ce réflexe sur man... ::)

Par contre, aka, cela signifie...? :-?
J'ai pas trouvé dans man ! ;D

Ecureuil wrote on 28. Nov 2008 at 15:07:

Merci ros, il faut vraiment que j'adopte ce réflexe sur man... ::) Par contre, aka, cela signifie...? :-? J'ai pas trouvé dans man ! ;D

'man -k mot' (aka 'apropos') est bien aussi :-)
Sinon «aka» -> «Also Known As»

fgudin wrote on 28. Nov 2008 at 15:12:

Ecureuil wrote on 28. Nov 2008 at 15:07: Merci ros, il faut vraiment que j'adopte ce réflexe sur man... ::) Par contre, aka, cela signifie...? :-? J'ai pas trouvé dans man ! ;D 'man -k mot' (aka 'apropos') est bien aussi :-) Sinon «aka» -> «Also Known As»

ppfioouuuuuuuu...
Merci francis. ;)
C'est fou ce que l'on peut apprendre comme trucs ici ! ;D
Entre le Forum FUG-FR, mes trois bouquins et les cachets qui vont bien pour rester éveillé les nuits, dans quelques semaines je suis un pro de FreeBSD et de la programmation système ! :D

Pardon de m'akamiscer dans ce fil, il y a aussi une page man dmidecode (Ou il est aussi précisé que les infos fournies ne sont pas toujours à prendre au pied de la lettre), et un site, ou l'on pourra trouver des explications et liens vers des scripts, etc...
Pour aider...


   

Ecureuil wrote on 27. Nov 2008 at 17:06:

En voici le code: [code]#include <stdlib.h> #include <stdio.h> #include <unistd.h> int main(void) {      execl("/usr/local/sbin/dmidecode", ">", "/usr/home/admin/info_sys.txt", NULL);      return EXIT_SUCCESS; }[/code] Pas d'erreur à la compilation, j'exécute mon programme dans mon interpréteur et au lieu de générer mon fichier texte info_sys.txt, cela me lance directement dmidecode dans l'interpréteur... ::)

Oui, normal. Que fait ton code : il execute dmidecode avec les *arguments* ">" et ""/usr/home/admin/info_sys.txt""

C'est pas du tout la même chose que dmidecode > info_sys.txt. Où là dmidecode est appelé avec aucun argument, mais avec sa sortie standard (stdout) redirigée vers un fichier.

Je t'invite à lire un bouquin sur la programmation et les concepts Unix au plus vite...

Bon courage, mais tu verras que ça n'a rien de bien compliqué.

Ecureuil wrote on 27. Nov 2008 at 09:27:

En quoi cela consiste-t-il, comme cela se manifeste-t-il ? J'ai bien regardé ici http://jargonf.org/wiki/fork mais n'ai pas tout saisi...

Sous unix tu n'as jamais de création de processus, il n'y a que des duplications. Pour exécuter un nouveau programme il faut que tu dupliques le processus courant -fork()- et que tu le recouvres (exec).

C'est vraiment la base ! Tu vas galérer inutilement si tu ne prends pas le temps de te documenter un minimum.

Dumpy wrote on 28. Nov 2008 at 17:22:

Pardon de m'akamiscer dans ce fil, il y a aussi une page man dmidecode (Ou il est aussi précisé que les infos fournies ne sont pas toujours à prendre au pied de la lettre), et un site, ou l'on pourra trouver des explications et liens vers des scripts, etc... Pour aider...

Merci Dumpy, je vais regarder cela de près. ;)

patrick wrote on 29. Nov 2008 at 00:06:

Ecureuil wrote on 27. Nov 2008 at 17:06: En voici le code: [code]#include <stdlib.h> #include <stdio.h> #include <unistd.h> int main(void) {      execl("/usr/local/sbin/dmidecode", ">", "/usr/home/admin/info_sys.txt", NULL);      return EXIT_SUCCESS; }[/code] Pas d'erreur à la compilation, j'exécute mon programme dans mon interpréteur et au lieu de générer mon fichier texte info_sys.txt, cela me lance directement dmidecode dans l'interpréteur... ::) Oui, normal. Que fait ton code : il execute dmidecode avec les *arguments* ">" et ""/usr/home/admin/info_sys.txt"" C'est pas du tout la même chose que dmidecode > info_sys.txt. Où là dmidecode est appelé avec aucun argument, mais avec sa sortie standard (stdout) redirigée vers un fichier. Je t'invite à lire un bouquin sur la programmation et les concepts Unix au plus vite... Bon courage, mais tu verras que ça n'a rien de bien compliqué.

patrick wrote on 29. Nov 2008 at 00:17:

Ecureuil wrote on 27. Nov 2008 at 09:27: En quoi cela consiste-t-il, comme cela se manifeste-t-il ? J'ai bien regardé ici http://jargonf.org/wiki/fork mais n'ai pas tout saisi... Sous unix tu n'as jamais de création de processus, il n'y a que des duplications. Pour exécuter un nouveau programme il faut que tu dupliques le processus courant -fork()- et que tu le recouvres (exec). C'est vraiment la base ! Tu vas galérer inutilement si tu ne prends pas le temps de te documenter un minimum.

Merci pour tes encouragements patrick, je "galère" déjà en fait !  ;D
Je sais que je vais en chier pendant quelques temps mais j'ai de l'énergie et de la volonté à revendre...
Le travail finissant toujours par payer et en plus avec vos conseils avisés, je devrai pouvoir, à terme, m'en sortir comme un grand ! :)

Bonjour à tous,

J'ai donc un script (lui-même faisant appel à un binaire) "chmodé +x" qui se trouve dans /etc/rc.d

J'ai ajouté dans mon rc.conf :
[code]mon_script_enable="YES"[/code]
Je reboote, tout fonctionne à merveille.

Sauf que, lorsque je modifie mon rc.conf et que je mets cette dernière ligne en commentaire ou que je la supprime ben au reboot mon script s'exécute quand même...?!?  :o

Il ressemble à quoi ton script ?

ros wrote on 29. Dec 2008 at 18:02:

Il ressemble à quoi ton script ?

Mon script ressemble à cela :
[code]#!/bin/sh
#PROVIDE: mon_script

name="mon_script"

/usr/sbin/mon_script[/code]
A la dernière ligne, j'appele un binaire qui porte le même nom que le script lui-même.

Ben oui mais le script il doit assurer la gestion du "YES". Exemple avec hald
[code]
...
hald_enable=${hald_enable-${gnome_enable}}
...
...
   if ! checkyesno hald_enable ; then
       return 0
   fi
   echo "Starting ${name}."
....
[/code]

C'est le script lui-même qui teste la variable qui porte le nom que tu as choisi. Et si checkyesno est false il sort tout de suite.

Bonjour Michel,

Je n'ai pas repris de café ce matin, mes neurones ne sont pas encore toutes en place, j'ai bien peur de ne pas avoir tout saisi...  :-[

En quoi la gestion du "YES" au niveau du script lui-même fait que celui-ci va s'exécuter quand même alors que je n'ai rien renseigné dans le rc.conf à son sujet...?

Merci.

Facile : tous les scripts qui sont dans /usr/local/erc/rc.d/ sont exécutés au startup ainsi qu'au shutdown, tous.
Donc si ton script ne teste pas la présence de la ligne mon_script_enable="YES"   personne ne le fera a ta place.
Ces variables portent généralement le nom du script ou de la fonction qu'ils activent mais ce n'est pas une obligation.
Bref si dans rc.conf tu mets coucou_toto="Yes" ,dans ton script via la ligne  load_rc_config coucou_toto tu récupères ta variable définie dans rc.conf. Donc tu tests cette variable pour décider de continuer l'exécution de ton script ou non.

Merci Michel pour ces explications, c'est on ne peut plus clair.  ;)