j'utilise Ubuntu depuis 2 jours et cette distrib a l'air attrayante... bien que
n'ayant jamais essayer auparavant Debian ; en effet je suis sous redhat depuis
4 ans !
ma question est la suivante :
dans /etc/init.d, il y a tous pleins de scripts dont j'ignore ce que
cela est et si cela est bien utile pour que le system fonction tel que
je le soiuhaite... j'aimerais savoir s'il n'existe pas un outil tel
"chkconfig" sous fedora afin de les configurer... ou encore savoir si
il n'existe pas une document traitant des services avec Ubuntu ???
merci d'avance
Eh bien tu utilises dpkg -S pour savoir à quel package ils appartiennent, puis tu utilises dpkg -s pour lire la description du package. Tu peux aussi regarder le début du script, qui contient souvent des commentaires explicatifs.
Ouh là, c'était dur.
eclipse wrote in message <pan.2004.11.23.17.14.16.736735@laposte.net>:
Eh bien tu utilises dpkg -S pour savoir à quel package ils appartiennent,
puis tu utilises dpkg -s pour lire la description du package. Tu peux aussi
regarder le début du script, qui contient souvent des commentaires
explicatifs.
Eh bien tu utilises dpkg -S pour savoir à quel package ils appartiennent, puis tu utilises dpkg -s pour lire la description du package. Tu peux aussi regarder le début du script, qui contient souvent des commentaires explicatifs.
Ouh là, c'était dur.
no_spam
On Tue, 23 Nov 2004 18:14:22 +0100, eclipse wrote:
Le Tue, 23 Nov 2004 16:33:59 +0100, TiChou a écrit :
Dans le message <news:, *eclipse* tapota sur f.c.o.l.configuration :
bonjour,
Bonjour,
j'utilise Ubuntu depuis 2 jours et cette distrib a l'air attrayante...
j'aimerais savoir s'il n'existe pas un outil tel "chkconfig" sous fedora afin de les configurer...
man update-rc.d
merci d'avance
De rien. merci pour cette info. cependant j'aimerais connaitre l'utilité de
certains services au boot du pc : dbus1 ; discover ; evms ; hwclock ; procps ; urandom
De façon générale, si tu ne sais pas, ne touche pas ;-) Sinon, google marche pas mal, entre nous...
dbus est un protocole de communication entre applications discover est un système de détection du hardware evms est un gestionnaire de volumes dynamique hwclock synchronise l'heure système sur l'heure matérielle procps, je ne vois pourquoi il a besoin de lancer quoi que ce soit au démarage.... urandom recharche le 'seed' du device urandom pour le rendre plus aléatoire.
On Tue, 23 Nov 2004 18:14:22 +0100, eclipse wrote:
Le Tue, 23 Nov 2004 16:33:59 +0100, TiChou a écrit :
Dans le message <news:pan.2004.11.23.15.26.35.363841@laposte.net>,
*eclipse* tapota sur f.c.o.l.configuration :
bonjour,
Bonjour,
j'utilise Ubuntu depuis 2 jours et cette distrib a l'air attrayante...
j'aimerais savoir s'il n'existe pas un outil tel
"chkconfig" sous fedora afin de les configurer...
man update-rc.d
merci d'avance
De rien.
merci pour cette info. cependant j'aimerais connaitre l'utilité de
certains services au boot du pc :
dbus1 ; discover ; evms ; hwclock ; procps ; urandom
De façon générale, si tu ne sais pas, ne touche pas ;-)
Sinon, google marche pas mal, entre nous...
dbus est un protocole de communication entre applications
discover est un système de détection du hardware
evms est un gestionnaire de volumes dynamique
hwclock synchronise l'heure système sur l'heure matérielle
procps, je ne vois pourquoi il a besoin de lancer quoi que ce soit au
démarage....
urandom recharche le 'seed' du device urandom pour le rendre plus
aléatoire.
On Tue, 23 Nov 2004 18:14:22 +0100, eclipse wrote:
Le Tue, 23 Nov 2004 16:33:59 +0100, TiChou a écrit :
Dans le message <news:, *eclipse* tapota sur f.c.o.l.configuration :
bonjour,
Bonjour,
j'utilise Ubuntu depuis 2 jours et cette distrib a l'air attrayante...
j'aimerais savoir s'il n'existe pas un outil tel "chkconfig" sous fedora afin de les configurer...
man update-rc.d
merci d'avance
De rien. merci pour cette info. cependant j'aimerais connaitre l'utilité de
certains services au boot du pc : dbus1 ; discover ; evms ; hwclock ; procps ; urandom
De façon générale, si tu ne sais pas, ne touche pas ;-) Sinon, google marche pas mal, entre nous...
dbus est un protocole de communication entre applications discover est un système de détection du hardware evms est un gestionnaire de volumes dynamique hwclock synchronise l'heure système sur l'heure matérielle procps, je ne vois pourquoi il a besoin de lancer quoi que ce soit au démarage.... urandom recharche le 'seed' du device urandom pour le rendre plus aléatoire.
Nicolas George
no_spam wrote in message :
procps, je ne vois pourquoi il a besoin de lancer quoi que ce soit au démarage....
Ce script fait des sysctl. Comme sysctl vient du package procps, le script s'appelle comme ça.
urandom recharche le 'seed' du device urandom pour le rendre plus aléatoire.
Plus exactement : aléatoire tout de suite, et pas seulement quand le réservoir d'entropie sera rempli.
no_spam wrote in message <pan.2004.11.23.23.31.29.696747@magic.fr>:
procps, je ne vois pourquoi il a besoin de lancer quoi que ce soit au
démarage....
Ce script fait des sysctl. Comme sysctl vient du package procps, le script
s'appelle comme ça.
urandom recharche le 'seed' du device urandom pour le rendre plus
aléatoire.
Plus exactement : aléatoire tout de suite, et pas seulement quand le
réservoir d'entropie sera rempli.
On Tue, 23 Nov 2004 23:44:55 +0000, Nicolas George wrote:
no_spam wrote in message :
procps, je ne vois pourquoi il a besoin de lancer quoi que ce soit au démarage....
Ce script fait des sysctl. Comme sysctl vient du package procps, le script s'appelle comme ça.
D'accord...
urandom recharche le 'seed' du device urandom pour le rendre plus aléatoire.
Plus exactement : aléatoire tout de suite, et pas seulement quand le réservoir d'entropie sera rempli.
Pas plus aléatoire, en fait, ni plus tôt, en fait. Ca fait juste recommencer la série au seed sauvegardé lors du dernier shutdown propre... Mais si le réservoir d'entropie est vide, la génération des nombres aléatoire sera quand même prédictible, seul le point de départ ne le sera pas (sauf pour qui peut lire le fichier qui contient la sauvegarde...). Heureusement, tout celà est bien théorique car le pool d'entropie ne reste en pratique jamais vide ;-)
On Tue, 23 Nov 2004 23:44:55 +0000, Nicolas George wrote:
no_spam wrote in message <pan.2004.11.23.23.31.29.696747@magic.fr>:
procps, je ne vois pourquoi il a besoin de lancer quoi que ce soit au
démarage....
Ce script fait des sysctl. Comme sysctl vient du package procps, le script
s'appelle comme ça.
D'accord...
urandom recharche le 'seed' du device urandom pour le rendre plus
aléatoire.
Plus exactement : aléatoire tout de suite, et pas seulement quand le
réservoir d'entropie sera rempli.
Pas plus aléatoire, en fait, ni plus tôt, en fait.
Ca fait juste recommencer la série au seed sauvegardé lors du dernier
shutdown propre...
Mais si le réservoir d'entropie est vide, la génération des nombres
aléatoire sera quand même prédictible, seul le point de départ ne le
sera pas (sauf pour qui peut lire le fichier qui contient la sauvegarde...).
Heureusement, tout celà est bien théorique car le pool d'entropie ne
reste en pratique jamais vide ;-)
On Tue, 23 Nov 2004 23:44:55 +0000, Nicolas George wrote:
no_spam wrote in message :
procps, je ne vois pourquoi il a besoin de lancer quoi que ce soit au démarage....
Ce script fait des sysctl. Comme sysctl vient du package procps, le script s'appelle comme ça.
D'accord...
urandom recharche le 'seed' du device urandom pour le rendre plus aléatoire.
Plus exactement : aléatoire tout de suite, et pas seulement quand le réservoir d'entropie sera rempli.
Pas plus aléatoire, en fait, ni plus tôt, en fait. Ca fait juste recommencer la série au seed sauvegardé lors du dernier shutdown propre... Mais si le réservoir d'entropie est vide, la génération des nombres aléatoire sera quand même prédictible, seul le point de départ ne le sera pas (sauf pour qui peut lire le fichier qui contient la sauvegarde...). Heureusement, tout celà est bien théorique car le pool d'entropie ne reste en pratique jamais vide ;-)
Nicolas George
no_spam wrote in message :
Pas plus aléatoire, en fait, ni plus tôt, en fait. Ca fait juste recommencer la série au seed sauvegardé lors du dernier shutdown propre...
Qui lui était probablement bien aléatoire (car il y a beaucoup d'activité disque au shutdown, mais les démons ont peu besoin d'aléa à ce moment-là). Donc le réservoir d'aléa est rempli immédiatement, avec du vrai aléa stocké avant le reboot, plutôt que de devoir attendre d'être rempli par des événements matériels.
C'est précisément ça que j'appelle plus tôt.
Mais si le réservoir d'entropie est vide, la génération des nombres aléatoire sera quand même prédictible, seul le point de départ ne le sera pas (sauf pour qui peut lire le fichier qui contient la sauvegarde...). Heureusement, tout celà est bien théorique car le pool d'entropie ne reste en pratique jamais vide ;-)
Euh, le réservoir d'aléa se remplit plutôt lentement. Quelques dizaines d'octets par seconde en pleine activité, ce n'est vraiment pas beaucoup. Évidemment, à ce rythme-là, on est au bout de deux secondes en dehors des possibilités pratiques de prédiction, mais on ne peut pas en faire une généralité. Une station bootant par réseau, ou depuis un support non-mécanique (mémoire flash, par exemple), aura un débit d'aléa _beaucoup_ plus lent.
no_spam wrote in message <pan.2004.11.24.09.00.10.447920@magic.fr>:
Pas plus aléatoire, en fait, ni plus tôt, en fait.
Ca fait juste recommencer la série au seed sauvegardé lors du dernier
shutdown propre...
Qui lui était probablement bien aléatoire (car il y a beaucoup d'activité
disque au shutdown, mais les démons ont peu besoin d'aléa à ce moment-là).
Donc le réservoir d'aléa est rempli immédiatement, avec du vrai aléa stocké
avant le reboot, plutôt que de devoir attendre d'être rempli par des
événements matériels.
C'est précisément ça que j'appelle plus tôt.
Mais si le réservoir d'entropie est vide, la génération des nombres
aléatoire sera quand même prédictible, seul le point de départ ne le
sera pas (sauf pour qui peut lire le fichier qui contient la sauvegarde...).
Heureusement, tout celà est bien théorique car le pool d'entropie ne
reste en pratique jamais vide ;-)
Euh, le réservoir d'aléa se remplit plutôt lentement. Quelques dizaines
d'octets par seconde en pleine activité, ce n'est vraiment pas beaucoup.
Évidemment, à ce rythme-là, on est au bout de deux secondes en dehors des
possibilités pratiques de prédiction, mais on ne peut pas en faire une
généralité. Une station bootant par réseau, ou depuis un support
non-mécanique (mémoire flash, par exemple), aura un débit d'aléa _beaucoup_
plus lent.
Pas plus aléatoire, en fait, ni plus tôt, en fait. Ca fait juste recommencer la série au seed sauvegardé lors du dernier shutdown propre...
Qui lui était probablement bien aléatoire (car il y a beaucoup d'activité disque au shutdown, mais les démons ont peu besoin d'aléa à ce moment-là). Donc le réservoir d'aléa est rempli immédiatement, avec du vrai aléa stocké avant le reboot, plutôt que de devoir attendre d'être rempli par des événements matériels.
C'est précisément ça que j'appelle plus tôt.
Mais si le réservoir d'entropie est vide, la génération des nombres aléatoire sera quand même prédictible, seul le point de départ ne le sera pas (sauf pour qui peut lire le fichier qui contient la sauvegarde...). Heureusement, tout celà est bien théorique car le pool d'entropie ne reste en pratique jamais vide ;-)
Euh, le réservoir d'aléa se remplit plutôt lentement. Quelques dizaines d'octets par seconde en pleine activité, ce n'est vraiment pas beaucoup. Évidemment, à ce rythme-là, on est au bout de deux secondes en dehors des possibilités pratiques de prédiction, mais on ne peut pas en faire une généralité. Une station bootant par réseau, ou depuis un support non-mécanique (mémoire flash, par exemple), aura un débit d'aléa _beaucoup_ plus lent.
