commande au démarrage

On Thu, 7 Aug 2003, perangusta wrote:

Bref, je dois faire sous root les commandes suivantes :
# adictrl -i
Et la valeur " eth1 " m'est renvoyée
Je dois alors établir ma connection avec un
# dhclient eth1
[...]

[Desktop Entry]
Exec­iclient -i
[...]

Je voudrais savoir si je peux rajouter simplement une ligne :

Exec=dhclient eth1

Je ne pense pas. À priori, KDE ne doit tolérer qu'une seule action par
raccourci.

Ou dois-je la formuler ainsi ?

Exec­iclient -i & Exec=dhclient eth1

Ou ainsi ?

Exec­iclient -i & dhclient eth1

Je ne crois pas que ça marchera (as-tu essayé ?)... Je pense que Exec doit
être suivi d'une commande executable directement (ie., comme en ligne de
commande), ce que ne sont probablement pas tes deux syntaxes.

Je vois deux solutions simples :
- soit tu crées un script (par exemple dans /usr/local/bin) qui contient
tes deux commandes, et tu mets Exec=mon_script dans ton raccourci KDE ;
- soit tu essayes de combiner ça dans ton raccourci, et la syntaxe serait
plutôt Exec="adiclient -i && dhclient eth1" (les "" ne sont peut-être pas
indispensables). Ou éventuellement Exec="adiclient -i ; dhclient eth1".

2 - J'aimerais automatiser ces deux taches au démarrage.

je n'ai aucune idée du script à faire, ni de sa syntaxe. Et surtout, où
faut-il l'insérer ? Dans un ficchier init.c ?

Je ne connais plus la structure des init.d de Mandrake, mais en gros, il
te faut mettre un script dans /etc/init.d, et un lien symbolique depuis
/etc/rcX.d sur ce script (où X est le runlevel kivabien, celui par défaut
est marqué dans /etc/inittab). Regarde comment sont faits les autres
scripts de init.d, c'est assez simple (le script doit accepter start et
stop comme arguments (au moins), et le lien doit s'appeler Sxx ou Kxx pour
que le script soit appellé avec l'argument start ou stop (kill)).
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."

Remi Moyen a dit dans fr.comp.os.linux.configuration :

Je ne connais plus la structure des init.d de Mandrake, mais en gros, il
te faut mettre un script dans /etc/init.d, et un lien symbolique depuis
/etc/rcX.d sur ce script (où X est le runlevel kivabien, celui par défaut
est marqué dans /etc/inittab). Regarde comment sont faits les autres
scripts de init.d, c'est assez simple (le script doit accepter start et
stop comme arguments (au moins), et le lien doit s'appeler Sxx ou Kxx pour
que le script soit appellé avec l'argument start ou stop (kill)).

Ou alors bêtement rajouter la (les) commande dans /etc/rc.d/rc.local

--
Fred.
Linux, {Free,Open}BSD mercenary {sys,net}admin @ N48º53.115 E02º19.31
This message is made from the freshest handpicked electrons
http://www.fredshome.org

Fred Albrecht wrote:

Remi Moyen a dit dans fr.comp.os.linux.configuration :

Je ne connais plus la structure des init.d de Mandrake, mais en gros, il
te faut mettre un script dans /etc/init.d, et un lien symbolique depuis
/etc/rcX.d sur ce script (où X est le runlevel kivabien, celui par défaut
est marqué dans /etc/inittab). Regarde comment sont faits les autres
scripts de init.d, c'est assez simple (le script doit accepter start et
stop comme arguments (au moins), et le lien doit s'appeler Sxx ou Kxx
pour que le script soit appellé avec l'argument start ou stop (kill)).

Ou alors bêtement rajouter la (les) commande dans /etc/rc.d/rc.local

Ok, je vais essayer cette méthode (la plus simple a priori).

Il s'avère (semble-t-il) que la commande adictrl -i suffit à activer la
connection...

Mais elle doit être faite sous root.

Je suppose néanmoins que l'insertion dans rc.local n'exige pas de privilèges
n'est-ce pas ?

Autre question : a priori ce n'est pas le cas, mais on ne siat jamais
pourplus tard : imaginons que je souhaite lancer deux commandes au
démarrage mais que la seconde dépend de la première (c'était mon cas),
dois-je adopter une synthaxe particulière dans rc.local ?

genre
adictrl -i && dhclient eth1

ou suffit-il de mettre deux lignes, et le système les interprète comme
devant résulter l'une de l'autre.

ex :
adictrl -i
dhclient eth1

Et le système retient l'ordre pour lancer dhclient une fois qu'adictrl -i a
été exécuté ? (je ne sai pas pourquoi, mais j'ai l'impresseion que ce n'est
pas cohérent : les fichiers rc lencent une série de commande, mais ne
doivent pas logiquement être bloqués par la défaillance de l'une des
commandes)

Enfin (toujours pour information)...

la commande dhclient eth1 suppose que adictrl -i ait renvoyé la variable
eth1, mais on peut imaginer que ce ne soit pas eth1 mais eth2 (si j'ai 2
cartes réseau par exemple).

Quelle serait alors la synthaxe pour

#adictrl -i
qui me renvoit la valeur "valeur1"
puis
#dhclient "valeur1"

?

On Thu, 7 Aug 2003, perangusta wrote:

Ou alors bêtement rajouter la (les) commande dans /etc/rc.d/rc.local

Voui, c'est vrai. J'oublie souvent... Peut-être parce que ce répertoire
n'existe pas sous Debian !

Autre question : a priori ce n'est pas le cas, mais on ne siat jamais
pourplus tard : imaginons que je souhaite lancer deux commandes au
démarrage mais que la seconde dépend de la première (c'était mon cas),
dois-je adopter une synthaxe particulière dans rc.local ?

genre
adictrl -i && dhclient eth1

ou suffit-il de mettre deux lignes, et le système les interprète comme
devant résulter l'une de l'autre.

ex :
adictrl -i
dhclient eth1

Si je ne m'abuse, dans les deux cas ici, le système attend que adictrl -i
soit fini avant de lancer la commande suivante. Donc si ton adictrl bloque
et ne rend jamais la main, ton système bloquera. Je ne sais pas comment
éviter facilement ce genre de problèmes (mais bon, si les commandes sont
bien faites, elles ont des timeout qui évitent qu'elles bloquent le
système eternellement).

Par contre, dans le premier cas, la deuxième commande (dhclient) ne sera
executée que si la première a reussi. Si donc adictrl finit, mais avec une
erreur, dhclient ne sera jamais lancé. Dans le deuxième cas, dhclient est
toujours lancé.

Globalement, les scripts dans rc.d sont des... scripts ! Donc pas besoin
de faire des choses particulières (en dehors de prévoir l'invocation par
start/stop).

Quelle serait alors la synthaxe pour

#adictrl -i
qui me renvoit la valeur "valeur1"
puis
#dhclient "valeur1"

VAR=`adictrl -i`
dhclient $VAR

Voire même peut-être dhclient `adictrl -i`, avec un peu de chance. Enfin,
sauf si adictrl renvoie d'autres infos que simplement le nom de
l'interface, dans ce cas faudrait filtrer un peu.
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."

Tout d'abord, merci à vous deux : une simple commande dans
/etc/rc.d/rc.local suffit désormais à lancer ma connection.

Merci encore pour les suggestion et précisions, car ça me permet d'apprendre
beaucoup plus vite.

Si je ne m'abuse, dans les deux cas ici, le système attend que adictrl -i
soit fini avant de lancer la commande suivante. Donc si ton adictrl bloque
et ne rend jamais la main, ton système bloquera. Je ne sais pas comment
éviter facilement ce genre de problèmes (mais bon, si les commandes sont
bien faites, elles ont des timeout qui évitent qu'elles bloquent le
système eternellement).

Ok, j'ai expérimenté des timeout lors de commandes infructueuses. Ceux-ci
ont-ils une efficacité générale, du genre (si une commande n'est pas
efficace au bout de n secondes, passer à autre chose), ou sont-ils
paramètrés par fichier et application ? Si c'ets le cas, il vaudrait mieux
que j'en prévoit une pour ma commande adictrl -i dans rc.local, non ?

Globalement, les scripts dans rc.d sont des... scripts ! Donc pas besoin
de faire des choses particulières (en dehors de prévoir l'invocation par
start/stop).

C'est quoi l'invocation start/stop ? Je ne la trouve pas dans les script :
s'agit-il du !#/ etc... en début de script ?

Quelle serait alors la synthaxe pour
/ect/rc.d/rc.local
#adictrl -i
qui me renvoit la valeur "valeur1"
puis
#dhclient "valeur1"

VAR=`adictrl -i`
dhclient $VAR

Voire même peut-être dhclient `adictrl -i`, avec un peu de chance. Enfin,
sauf si adictrl renvoie d'autres infos que simplement le nom de
l'interface, dans ce cas faudrait filtrer un peu.

Non, non, c'est la seule valeur renvoyée. Ok, je vois comment ça peut
fonctionner.

Une dernière question : mon /etc/rc.d/rc.local est ainsi fait :

#!/bin/sh
#

----------------------------
Il s'agit donc d'un script shell, c'est cela ?
----------------------------

# This script will be executed after all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

[ -f /etc/sysconfig/msec ] && source /etc/sysconfig/msec
[ -z "$SECURE_LEVEL" ] && SECURE_LEVEL=3

# Source functions
. /etc/init.d/functions

-------------------------
Je ne comprends pas cette ligne : s'agit-il de l'appel d'un autre fichier
(un lien symbolique ?). Je l'ai ouvert et n'y comprends guère.
----------------------------


if [ -f /etc/mandrake-release -a $SECURE_LEVEL -lt 4 ]; then
R=$(cat /etc/mandrake-release)

arch=$(uname -m)
a="a"
case "_$arch" in
_a*) a="an";;
_i*) a="an";;
esac

NUMPROC=`egrep -c "^cpu[0-9]+" /proc/stat`
if [ "$NUMPROC" -gt "1" ]; then
SMP="$NUMPROC-processor "
[ "$NUMPROC" = "2" ] &&
SMP="Dual-processor "
if [ "$NUMPROC" = "8" -o "$NUMPROC" = "11" ]; then
a="an"
else
a="a"
fi
fi

# This will overwrite /etc/issue at every boot. So, make any changes
you
# want to make to /etc/issue here or you will lose them when you reboot.

if [ -x /usr/bin/linux_logo ];then
/usr/bin/linux_logo -c -n -f | sed -e 's|\|\\|g' > /etc/issue
echo "" >> /etc/issue
else

/etc/issue
fi

echo "$R" >> /etc/issue
echo "Kernel $(uname -r) on $a $SMP$(uname -m) / l" >> /etc/issue

if [ "$SECURE_LEVEL" -le 3 ];then
echo "Welcome to ${HOST}" > /etc/issue.net
echo "$R" >> /etc/issue.net
echo "Kernel $(uname -r) on $a $SMP$(uname -m)" >> /etc/issue.net
else
echo "Welcome to Mandrake Linux" > /etc/issue.net
echo "-------------------------" >> /etc/issue.net
fi
elif [ $SECURE_LEVEL -ge 4 ]; then
rm -f /etc/issue /etc/issue.net
fi

touch /var/lock/subsys/local

#lancement connection
adictrl -i

Ma commande est la dernière : je n'ai pas compris le script qui précède :
j'ai l'impression qu'iol s'agit d'un appel à d'autres fichiers... Mais je
ne suis pas sûr. est-ce que je n'ai pas intérêt à faire figurer adictrl -i
dans ces mêmes fichiers, pour bénéficier de leur configuration timeout par
exemple ?

Salut
Je vais répondre à ca que je peux, avec mes petites connaissances en
bash :

Tout d'abord, merci à vous deux : une simple commande dans
/etc/rc.d/rc.local suffit désormais à lancer ma connection.

Merci encore pour les suggestion et précisions, car ça me permet d'apprendre
beaucoup plus vite.

Si je ne m'abuse, dans les deux cas ici, le système attend que adictrl -i
soit fini avant de lancer la commande suivante. Donc si ton adictrl bloque
et ne rend jamais la main, ton système bloquera. Je ne sais pas comment
éviter facilement ce genre de problèmes (mais bon, si les commandes sont
bien faites, elles ont des timeout qui évitent qu'elles bloquent le
système eternellement).

Ok, j'ai expérimenté des timeout lors de commandes infructueuses. Ceux-ci
ont-ils une efficacité générale, du genre (si une commande n'est pas
efficace au bout de n secondes, passer à autre chose), ou sont-ils
paramètrés par fichier et application ? Si c'ets le cas, il vaudrait mieux
que j'en prévoit une pour ma commande adictrl -i dans rc.local, non ?

J'ai pas lu en détail votre échange sur les timeout.
Mais ce qu'il voulait dire c que si ton programme adictrl est bien
fait, il renvoie la main
au bout d'un certain temps, et donc l'execution du script peut
continuer.
pour eviter ca tu peux passer adictrl -i & : le prog est executé en fond

Globalement, les scripts dans rc.d sont des... scripts ! Donc pas besoin
de faire des choses particulières (en dehors de prévoir l'invocation par
start/stop).

C'est quoi l'invocation start/stop ? Je ne la trouve pas dans les script :
s'agit-il du !#/ etc... en début de script ?

l'invocation start/stop c un truc du style :

case $1 in
start) #ce qu'on fait lorsque la script est appelé avec start
;;
stop) #ce qu'on fait lorsque la script est appelé avec stop
;;
*) les autres cas

esac

et comme ca tu peux faire un script network avec "network start" qui
démarre le réseau
et "network stop" qui l'arrete

Une dernière question : mon /etc/rc.d/rc.local est ainsi fait :

#!/bin/sh
#

----------------------------
Il s'agit donc d'un script shell, c'est cela ?
----------------------------

Oui c ca

# This script will be executed after all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

[ -f /etc/sysconfig/msec ] && source /etc/sysconfig/msec
[ -z "$SECURE_LEVEL" ] && SECURE_LEVEL=3

# Source functions
. /etc/init.d/functions

-------------------------
Je ne comprends pas cette ligne : s'agit-il de l'appel d'un autre fichier
(un lien symbolique ?). Je l'ai ouvert et n'y comprends guère.
----------------------------

On charge un certain nombre de fonctions utiles pour créer des scripts
de démarrage
Par exemple daemon pour lancer un programme en daemon avec l'affichage
OK ou failed

#lancement connection
adictrl -i

Ma commande est la dernière : je n'ai pas compris le script qui précède :
j'ai l'impression qu'iol s'agit d'un appel à d'autres fichiers... Mais je
ne suis pas sûr. est-ce que je n'ai pas intérêt à faire figurer adictrl -i
dans ces mêmes fichiers, pour bénéficier de leur configuration timeout par
exemple ?

Non il s'agit des programms d'initialisation de ta mandrake, avue de nez
ca regarde si ta config est mono-processeur ou pas,etc
les références à /proc ne sont pas vraiment des fichiers : /proc
stockent pleins d'infos sur ton systeme
Par ex "cat /proc/cpuinfo"

Voila j'espere avoir éclairci qques points
Thomas