Je viens d'installer Libranet et je voudrais savoir quel est
l'équivalent du rc.firewall de Slackware dans Debian.
GP
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
A l'usage, je préfère quand même avoir les paramètres réseau stockés dans un fichier à part (genre debian /etc/network/interfaces) plutot que mélangés avec les commandes ifconfig et autres routes (genre slackware /etc/rc.d/rc.inet1)
Ça n'est plus le cas pour la Slackware 9.1 (script dans rc.inet1 et paramètres dans rc.inet1.conf).
JFB
-- All syllogisms have three parts, therefore this is not a syllogism.
scripsit Michel BILLAUD :
A l'usage, je préfère quand même avoir les paramètres réseau stockés
dans un fichier à part (genre debian /etc/network/interfaces) plutot
que mélangés avec les commandes ifconfig et autres routes (genre
slackware /etc/rc.d/rc.inet1)
Ça n'est plus le cas pour la Slackware 9.1 (script dans rc.inet1
et paramètres dans rc.inet1.conf).
JFB
--
All syllogisms have three parts, therefore this is not a syllogism.
A l'usage, je préfère quand même avoir les paramètres réseau stockés dans un fichier à part (genre debian /etc/network/interfaces) plutot que mélangés avec les commandes ifconfig et autres routes (genre slackware /etc/rc.d/rc.inet1)
Ça n'est plus le cas pour la Slackware 9.1 (script dans rc.inet1 et paramètres dans rc.inet1.conf).
JFB
-- All syllogisms have three parts, therefore this is not a syllogism.
Michel BILLAUD
Jean-Francois Billaud writes:
scripsit Michel BILLAUD :
A l'usage, je préfère quand même avoir les paramètres réseau stockés dans un fichier à part (genre debian /etc/network/interfaces) plutot que mélangés avec les commandes ifconfig et autres routes (genre slackware /etc/rc.d/rc.inet1)
Ça n'est plus le cas pour la Slackware 9.1 (script dans rc.inet1 et paramètres dans rc.inet1.conf).
Et la présence du script /etc/rc.sysvinit dans les distributions Slackware remonte à la plus haute antiquité.
Le Pere Noel mettra une organisation Sys5 dans les distributions de tous ceux qui n'ont pas été sages.
# rc.sysvinit This file provides basic compatibility with SystemV style # startup scripts. The SystemV style init system places # start/stop scripts for each runlevel into directories such as # /etc/rc.d/rc3.d/ (for runlevel 3) instead of starting them # from /etc/rc.d/rc.M. This makes for a lot more init scripts, # and a more complicated execution path to follow through if # something goes wrong. For this reason, Slackware has always # used the traditional BSD style init script layout. # # However, many binary packages exist that install SystemV # init scripts. With rc.sysvinit in place, most well-written # startup scripts will work. This is primarily intended to # support commercial software, though, and probably shouldn't # be considered bug free. # # Written by Patrick Volkerding , 1999 # from an example by Miquel van Smoorenburg .
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
A l'usage, je préfère quand même avoir les paramètres réseau stockés
dans un fichier à part (genre debian /etc/network/interfaces) plutot
que mélangés avec les commandes ifconfig et autres routes (genre
slackware /etc/rc.d/rc.inet1)
Ça n'est plus le cas pour la Slackware 9.1 (script dans rc.inet1
et paramètres dans rc.inet1.conf).
Et la présence du script /etc/rc.sysvinit dans les distributions
Slackware remonte à la plus haute antiquité.
Le Pere Noel mettra une organisation Sys5 dans les distributions de
tous ceux qui n'ont pas été sages.
# rc.sysvinit This file provides basic compatibility with SystemV style
# startup scripts. The SystemV style init system places
# start/stop scripts for each runlevel into directories such as
# /etc/rc.d/rc3.d/ (for runlevel 3) instead of starting them
# from /etc/rc.d/rc.M. This makes for a lot more init scripts,
# and a more complicated execution path to follow through if
# something goes wrong. For this reason, Slackware has always
# used the traditional BSD style init script layout.
#
# However, many binary packages exist that install SystemV
# init scripts. With rc.sysvinit in place, most well-written
# startup scripts will work. This is primarily intended to
# support commercial software, though, and probably shouldn't
# be considered bug free.
#
# Written by Patrick Volkerding <volkerdi@slackware.com>, 1999
# from an example by Miquel van Smoorenburg <miquels@cistron.nl>.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
A l'usage, je préfère quand même avoir les paramètres réseau stockés dans un fichier à part (genre debian /etc/network/interfaces) plutot que mélangés avec les commandes ifconfig et autres routes (genre slackware /etc/rc.d/rc.inet1)
Ça n'est plus le cas pour la Slackware 9.1 (script dans rc.inet1 et paramètres dans rc.inet1.conf).
Et la présence du script /etc/rc.sysvinit dans les distributions Slackware remonte à la plus haute antiquité.
Le Pere Noel mettra une organisation Sys5 dans les distributions de tous ceux qui n'ont pas été sages.
# rc.sysvinit This file provides basic compatibility with SystemV style # startup scripts. The SystemV style init system places # start/stop scripts for each runlevel into directories such as # /etc/rc.d/rc3.d/ (for runlevel 3) instead of starting them # from /etc/rc.d/rc.M. This makes for a lot more init scripts, # and a more complicated execution path to follow through if # something goes wrong. For this reason, Slackware has always # used the traditional BSD style init script layout. # # However, many binary packages exist that install SystemV # init scripts. With rc.sysvinit in place, most well-written # startup scripts will work. This is primarily intended to # support commercial software, though, and probably shouldn't # be considered bug free. # # Written by Patrick Volkerding , 1999 # from an example by Miquel van Smoorenburg .
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Emmanuel Florac
Dans article , disait...
Alors, si tous les services peut s'arrêter ainsi, quel est l'avantage du SysV ??
Les runlevels. Ca permet de démarrer (ou redémarrer) en mode X, ou en mode monoutilisateur, etc, sans modifier de fichier de config. Bon il est vrai que dans la pratique ça sert peu.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3FD29FD5.5000200@altermmm.org>, gil@altermmm.org disait...
Alors, si tous les services peut s'arrêter ainsi, quel est l'avantage du
SysV ??
Les runlevels. Ca permet de démarrer (ou redémarrer) en mode X, ou en
mode monoutilisateur, etc, sans modifier de fichier de config. Bon il est
vrai que dans la pratique ça sert peu.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Alors, si tous les services peut s'arrêter ainsi, quel est l'avantage du SysV ??
Les runlevels. Ca permet de démarrer (ou redémarrer) en mode X, ou en mode monoutilisateur, etc, sans modifier de fichier de config. Bon il est vrai que dans la pratique ça sert peu.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Vincent Bernat
OoO Lors de la soirée naissante du samedi 06 décembre 2003, vers 17:05, GP disait:
Exemple ? Parce que moi, je démarre ou éteins rarement des services. Tu es bien sôr que tu ne peux arrêter des services individuellement avec Slackware?
Si, mais avec une procédure adhoc pour chaque service. ctlinnd shutdown "maintenance" pour INN, apachectl stop pour Apache, etc. L'intérêt du SysV, c'est que tu ne réfléchis pas. Tu veux stopper tel service : /etc/init.d/apache stop. Il doit relire son fichier de config ? /etc/init.d/apache reload.
et de pouvoir démarrer les services dans un ordre spécifique, en fonction des dépendances requises, sans avoir à touiller les shell scripts.
Là encore, je ne suis pas. Dernièrement, je me suis installé un firewall que j'ai concocté à partir des instructions de Daniel Robbins (chez IBM). Puis, j'ai décidé d'ajouter quelques tweakings de fichiers proc/... que j'ai mis dans un fichier séparé qui est appelé par rc.init2 après le fichier firewall. En quoi est-ce qu'un boot SysV ,e dirait ce qui doit aller avant ou après le firewall dans les procs ?
En rien, c'est toi qui décide où il démarre. Tu devrais surtout aller te documenter un peu sur cette procédure de boot car tu ne sembles pas du tout savoir comment elle fonctionne et elle est pourtant très simple quand on se limite à un runlevel.
Étant donné la complexité apparente du SysV, comme aurais-je pu écrire mon firewall à partir des petites des petites commandes simplettes qui m'ont été fournies et qui font tout de même que je me retrouve avec TOUS mes ports "BLOCKED" à tous les tests chez scan,sygatetech.com ?
Cela n'a absolument rien à voir avec SysV. Tu peux utiliser absolument le même script que tu as utilisé sur ta Slack. Tu le colles dans /etc/init.d et un lien symbolique depuis /etc/rcx.d sous la forme Sxxmachin et c'est fini. Évidemment, il ne pourra pas s'arrêter individuellement sans quelques petits modifications, mais comme cette fonctionnalité ne t'intéresse pas.
Apparemment cet argument a séduit les BSDistes les plus convaincus, puisque NetBSD et FreeBSD sont passés à ce mécanisme.
Ah! Mais pas OpenBSD, réputé le plus sécure.
Pas Gentoo, pas Slackware. À qui faut-il se fier, particulièrement pour un système Desktop? Et Gentoo et Slackware prétendent à plus que ça!
Gentoo utilise une init SysV un peu plus compliquée pour gérer automatiquement les dépendances. -- Follow each decision as closely as possible with its associated action. - The Elements of Programming Style (Kernighan & Plaugher)
OoO Lors de la soirée naissante du samedi 06 décembre 2003, vers
17:05, GP <gilpel@inverse.nretla.org> disait:
Exemple ? Parce que moi, je démarre ou éteins rarement des
services. Tu es bien sôr que tu ne peux arrêter des services
individuellement avec Slackware?
Si, mais avec une procédure adhoc pour chaque service. ctlinnd
shutdown "maintenance" pour INN, apachectl stop pour Apache,
etc. L'intérêt du SysV, c'est que tu ne réfléchis pas. Tu veux stopper
tel service : /etc/init.d/apache stop. Il doit relire son fichier de
config ? /etc/init.d/apache reload.
et de
pouvoir démarrer les services dans un ordre spécifique, en fonction des
dépendances requises, sans avoir à touiller les shell scripts.
Là encore, je ne suis pas. Dernièrement, je me suis installé un
firewall que j'ai concocté à partir des instructions de Daniel Robbins
(chez IBM). Puis, j'ai décidé d'ajouter quelques tweakings de fichiers
proc/... que j'ai mis dans un fichier séparé qui est appelé par
rc.init2 après le fichier firewall. En quoi est-ce qu'un boot SysV ,e
dirait ce qui doit aller avant ou après le firewall dans les procs ?
En rien, c'est toi qui décide où il démarre. Tu devrais surtout aller
te documenter un peu sur cette procédure de boot car tu ne sembles pas
du tout savoir comment elle fonctionne et elle est pourtant très
simple quand on se limite à un runlevel.
Étant donné la complexité apparente du SysV, comme aurais-je pu écrire
mon firewall à partir des petites des petites commandes simplettes qui
m'ont été fournies et qui font tout de même que je me retrouve avec
TOUS mes ports "BLOCKED" à tous les tests chez scan,sygatetech.com ?
Cela n'a absolument rien à voir avec SysV. Tu peux utiliser absolument
le même script que tu as utilisé sur ta Slack. Tu le colles dans
/etc/init.d et un lien symbolique depuis /etc/rcx.d sous la forme
Sxxmachin et c'est fini. Évidemment, il ne pourra pas s'arrêter
individuellement sans quelques petits modifications, mais comme cette
fonctionnalité ne t'intéresse pas.
Apparemment cet argument a séduit les BSDistes les plus convaincus,
puisque NetBSD et FreeBSD sont passés à ce mécanisme.
Ah! Mais pas OpenBSD, réputé le plus sécure.
Pas Gentoo, pas Slackware. À qui faut-il se fier, particulièrement
pour un système Desktop? Et Gentoo et Slackware prétendent à plus que
ça!
Gentoo utilise une init SysV un peu plus compliquée pour gérer
automatiquement les dépendances.
--
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plaugher)
OoO Lors de la soirée naissante du samedi 06 décembre 2003, vers 17:05, GP disait:
Exemple ? Parce que moi, je démarre ou éteins rarement des services. Tu es bien sôr que tu ne peux arrêter des services individuellement avec Slackware?
Si, mais avec une procédure adhoc pour chaque service. ctlinnd shutdown "maintenance" pour INN, apachectl stop pour Apache, etc. L'intérêt du SysV, c'est que tu ne réfléchis pas. Tu veux stopper tel service : /etc/init.d/apache stop. Il doit relire son fichier de config ? /etc/init.d/apache reload.
et de pouvoir démarrer les services dans un ordre spécifique, en fonction des dépendances requises, sans avoir à touiller les shell scripts.
Là encore, je ne suis pas. Dernièrement, je me suis installé un firewall que j'ai concocté à partir des instructions de Daniel Robbins (chez IBM). Puis, j'ai décidé d'ajouter quelques tweakings de fichiers proc/... que j'ai mis dans un fichier séparé qui est appelé par rc.init2 après le fichier firewall. En quoi est-ce qu'un boot SysV ,e dirait ce qui doit aller avant ou après le firewall dans les procs ?
En rien, c'est toi qui décide où il démarre. Tu devrais surtout aller te documenter un peu sur cette procédure de boot car tu ne sembles pas du tout savoir comment elle fonctionne et elle est pourtant très simple quand on se limite à un runlevel.
Étant donné la complexité apparente du SysV, comme aurais-je pu écrire mon firewall à partir des petites des petites commandes simplettes qui m'ont été fournies et qui font tout de même que je me retrouve avec TOUS mes ports "BLOCKED" à tous les tests chez scan,sygatetech.com ?
Cela n'a absolument rien à voir avec SysV. Tu peux utiliser absolument le même script que tu as utilisé sur ta Slack. Tu le colles dans /etc/init.d et un lien symbolique depuis /etc/rcx.d sous la forme Sxxmachin et c'est fini. Évidemment, il ne pourra pas s'arrêter individuellement sans quelques petits modifications, mais comme cette fonctionnalité ne t'intéresse pas.
Apparemment cet argument a séduit les BSDistes les plus convaincus, puisque NetBSD et FreeBSD sont passés à ce mécanisme.
Ah! Mais pas OpenBSD, réputé le plus sécure.
Pas Gentoo, pas Slackware. À qui faut-il se fier, particulièrement pour un système Desktop? Et Gentoo et Slackware prétendent à plus que ça!
Gentoo utilise une init SysV un peu plus compliquée pour gérer automatiquement les dépendances. -- Follow each decision as closely as possible with its associated action. - The Elements of Programming Style (Kernighan & Plaugher)
Vincent Bernat
OoO En ce milieu de nuit étoilée du dimanche 07 décembre 2003, vers 04:07, Michel BILLAUD disait:
Le lancement des scripts d'un niveau (par exemple le 2) se fait par une boucle du type for script in /etc/rc2.d/S* do if [ -x $script ] ; then $script start ; fi done dont le surcoût est très certainement négligable.
Dans une init BSD, certains programmes sont lancés en tâche de fond et non séquentiellement. -- J'a -+- PM in GGE - Je vous ai tous grillés sur cette réponse -+-
OoO En ce milieu de nuit étoilée du dimanche 07 décembre 2003, vers
04:07, Michel BILLAUD <billaud@labri.u-bordeaux.fr> disait:
Le lancement des scripts d'un niveau (par exemple le 2) se fait par
une boucle du type
for script in /etc/rc2.d/S*
do
if [ -x $script ] ; then $script start ; fi
done
dont le surcoût est très certainement négligable.
Dans une init BSD, certains programmes sont lancés en tâche de fond et
non séquentiellement.
--
J'a
-+- PM in GGE - Je vous ai tous grillés sur cette réponse -+-
OoO En ce milieu de nuit étoilée du dimanche 07 décembre 2003, vers 04:07, Michel BILLAUD disait:
Le lancement des scripts d'un niveau (par exemple le 2) se fait par une boucle du type for script in /etc/rc2.d/S* do if [ -x $script ] ; then $script start ; fi done dont le surcoût est très certainement négligable.
Dans une init BSD, certains programmes sont lancés en tâche de fond et non séquentiellement. -- J'a -+- PM in GGE - Je vous ai tous grillés sur cette réponse -+-
Thomas Nemeth
Le dim 07 déc 2003 à 18:56, Vincent Bernat a tapoté : | OoO En ce milieu de nuit étoilée du dimanche 07 décembre 2003, vers | 04:07, Michel BILLAUD disait: | | > Le lancement des scripts d'un niveau (par exemple le 2) se fait par | > une boucle du type | > for script in /etc/rc2.d/S* | > do | > if [ -x $script ] ; then $script start ; fi | > done | > dont le surcoût est très certainement négligable. | | Dans une init BSD, certains programmes sont lancés en tâche de fond et | non séquentiellement.
Rien n'empêche de les lancer en tâche de fond...
Ceci dit, il me semble que les BSD vont utiliser des makefiles pour gérer les dépendances entre services au boot.
Thomas -- "Tu l'as vu le mari à la Juliette, tu sais, celui qu'est ouèbemaster ? Ce garçon, il est pâle comme la craie de la Sainte-Foi, malade je te dis : il boit trop de café, il est trop nerveux : je suis sûr qu'il a la thyroïde fatiguée. Il va nous péter le boulon avant le premier petiot." -+- Brèves de comptoir -+-
Le dim 07 déc 2003 à 18:56, Vincent Bernat a tapoté :
| OoO En ce milieu de nuit étoilée du dimanche 07 décembre 2003, vers
| 04:07, Michel BILLAUD <billaud@labri.u-bordeaux.fr> disait:
|
| > Le lancement des scripts d'un niveau (par exemple le 2) se fait par
| > une boucle du type
| > for script in /etc/rc2.d/S*
| > do
| > if [ -x $script ] ; then $script start ; fi
| > done
| > dont le surcoût est très certainement négligable.
|
| Dans une init BSD, certains programmes sont lancés en tâche de fond et
| non séquentiellement.
Rien n'empêche de les lancer en tâche de fond...
Ceci dit, il me semble que les BSD vont utiliser des makefiles
pour gérer les dépendances entre services au boot.
Thomas
--
"Tu l'as vu le mari à la Juliette, tu sais, celui qu'est ouèbemaster ? Ce
garçon, il est pâle comme la craie de la Sainte-Foi, malade je te dis : il boit
trop de café, il est trop nerveux : je suis sûr qu'il a la thyroïde fatiguée.
Il va nous péter le boulon avant le premier petiot." -+- Brèves de comptoir -+-
Le dim 07 déc 2003 à 18:56, Vincent Bernat a tapoté : | OoO En ce milieu de nuit étoilée du dimanche 07 décembre 2003, vers | 04:07, Michel BILLAUD disait: | | > Le lancement des scripts d'un niveau (par exemple le 2) se fait par | > une boucle du type | > for script in /etc/rc2.d/S* | > do | > if [ -x $script ] ; then $script start ; fi | > done | > dont le surcoût est très certainement négligable. | | Dans une init BSD, certains programmes sont lancés en tâche de fond et | non séquentiellement.
Rien n'empêche de les lancer en tâche de fond...
Ceci dit, il me semble que les BSD vont utiliser des makefiles pour gérer les dépendances entre services au boot.
Thomas -- "Tu l'as vu le mari à la Juliette, tu sais, celui qu'est ouèbemaster ? Ce garçon, il est pâle comme la craie de la Sainte-Foi, malade je te dis : il boit trop de café, il est trop nerveux : je suis sûr qu'il a la thyroïde fatiguée. Il va nous péter le boulon avant le premier petiot." -+- Brèves de comptoir -+-
Gerald Niel
Le dimanche 07 décembre 2003 à 16:10 GMT, Emmanuel Florac écrivait sur fr.comp.os.linux.debats :
Alors, si tous les services peut s'arrêter ainsi, quel est l'avantage du SysV ??
Les runlevels. Ca permet de démarrer (ou redémarrer) en mode X, ou en mode monoutilisateur, etc, sans modifier de fichier de config. Bon il est vrai que dans la pratique ça sert peu.
Heuh, veuillez m'excuser pour mon ignorance si tel est le cas, mais avec ma slack 9.0, j'ai aussi ça, les runlevel. Donc j'ai du mal à saisir...
En tout cas je trouve bien plus claire l'organisation de la slackware.
@+ -- Lu sur linux.wine.users :
I have a bottle of Haut Medoc from 1971 and wondered if anyone on this BB could advise as to possible value and drinkability. -+- PB in Guide du linuxien pervers - "Important ça, la drinkability !" -+-
Le dimanche 07 décembre 2003 à 16:10 GMT, Emmanuel Florac écrivait sur
fr.comp.os.linux.debats :
Alors, si tous les services peut s'arrêter ainsi, quel est l'avantage du
SysV ??
Les runlevels. Ca permet de démarrer (ou redémarrer) en mode X, ou en
mode monoutilisateur, etc, sans modifier de fichier de config. Bon il est
vrai que dans la pratique ça sert peu.
Heuh, veuillez m'excuser pour mon ignorance si tel est le cas, mais
avec ma slack 9.0, j'ai aussi ça, les runlevel. Donc j'ai du mal à
saisir...
En tout cas je trouve bien plus claire l'organisation de la slackware.
@+
--
Lu sur linux.wine.users :
I have a bottle of Haut Medoc from 1971 and wondered if anyone on this BB
could advise as to possible value and drinkability.
-+- PB in Guide du linuxien pervers - "Important ça, la drinkability !" -+-
Le dimanche 07 décembre 2003 à 16:10 GMT, Emmanuel Florac écrivait sur fr.comp.os.linux.debats :
Alors, si tous les services peut s'arrêter ainsi, quel est l'avantage du SysV ??
Les runlevels. Ca permet de démarrer (ou redémarrer) en mode X, ou en mode monoutilisateur, etc, sans modifier de fichier de config. Bon il est vrai que dans la pratique ça sert peu.
Heuh, veuillez m'excuser pour mon ignorance si tel est le cas, mais avec ma slack 9.0, j'ai aussi ça, les runlevel. Donc j'ai du mal à saisir...
En tout cas je trouve bien plus claire l'organisation de la slackware.
@+ -- Lu sur linux.wine.users :
I have a bottle of Haut Medoc from 1971 and wondered if anyone on this BB could advise as to possible value and drinkability. -+- PB in Guide du linuxien pervers - "Important ça, la drinkability !" -+-
Vincent Bernat
OoO En cette fin de matinée radieuse du dimanche 07 décembre 2003, vers 11:54, Gerald Niel disait:
Heuh, veuillez m'excuser pour mon ignorance si tel est le cas, mais avec ma slack 9.0, j'ai aussi ça, les runlevel. Donc j'ai du mal à saisir...
<URL:http://www.linux-france.org/article/sys/init-jaco/init-jaco.html> -- Watch out for off-by-one errors. - The Elements of Programming Style (Kernighan & Plaugher)
OoO En cette fin de matinée radieuse du dimanche 07 décembre 2003,
vers 11:54, Gerald Niel <gegeweb@invalid.gegeweb.net> disait:
Heuh, veuillez m'excuser pour mon ignorance si tel est le cas, mais
avec ma slack 9.0, j'ai aussi ça, les runlevel. Donc j'ai du mal à
saisir...
<URL:http://www.linux-france.org/article/sys/init-jaco/init-jaco.html>
--
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan & Plaugher)
OoO En cette fin de matinée radieuse du dimanche 07 décembre 2003, vers 11:54, Gerald Niel disait:
Heuh, veuillez m'excuser pour mon ignorance si tel est le cas, mais avec ma slack 9.0, j'ai aussi ça, les runlevel. Donc j'ai du mal à saisir...
<URL:http://www.linux-france.org/article/sys/init-jaco/init-jaco.html> -- Watch out for off-by-one errors. - The Elements of Programming Style (Kernighan & Plaugher)
Emmanuel Florac
Dans article , disait...
Heuh, veuillez m'excuser pour mon ignorance si tel est le cas, mais avec ma slack 9.0, j'ai aussi ça, les runlevel. Donc j'ai du mal à saisir...
Oui mais dans la slack c'est un package optionnel (sysvinit). On est pas obligé de l'installer, ni de l'utiliser.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <slrnbt71bq.14j.gegeweb@tux.gn.homeunix.org>,
gegeweb@invalid.gegeweb.net disait...
Heuh, veuillez m'excuser pour mon ignorance si tel est le cas, mais
avec ma slack 9.0, j'ai aussi ça, les runlevel. Donc j'ai du mal à
saisir...
Oui mais dans la slack c'est un package optionnel (sysvinit). On est pas
obligé de l'installer, ni de l'utiliser.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Heuh, veuillez m'excuser pour mon ignorance si tel est le cas, mais avec ma slack 9.0, j'ai aussi ça, les runlevel. Donc j'ai du mal à saisir...
Oui mais dans la slack c'est un package optionnel (sysvinit). On est pas obligé de l'installer, ni de l'utiliser.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
GP
Gerald Niel wrote:
Le dimanche 07 décembre 2003 à 16:10 GMT, Emmanuel Florac écrivait sur fr.comp.os.linux.debats :
Alors, si tous les services peut s'arrêter ainsi, quel est l'avantage du SysV ??
Les runlevels. Ca permet de démarrer (ou redémarrer) en mode X, ou en mode monoutilisateur, etc, sans modifier de fichier de config. Bon il est vrai que dans la pratique ça sert peu.
Heuh, veuillez m'excuser pour mon ignorance si tel est le cas, mais avec ma slack 9.0, j'ai aussi ça, les runlevel. Donc j'ai du mal à saisir...
Pareil ici. Mais n'est pas la question, je suppose. Tous les OS, les Unix en tout cas, ont des runlevels.
En tout cas je trouve bien plus claire l'organisation de la slackware.
Idem ici.
GP
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Gerald Niel wrote:
Le dimanche 07 décembre 2003 à 16:10 GMT, Emmanuel Florac écrivait sur
fr.comp.os.linux.debats :
Alors, si tous les services peut s'arrêter ainsi, quel est l'avantage du
SysV ??
Les runlevels. Ca permet de démarrer (ou redémarrer) en mode X, ou en
mode monoutilisateur, etc, sans modifier de fichier de config. Bon il est
vrai que dans la pratique ça sert peu.
Heuh, veuillez m'excuser pour mon ignorance si tel est le cas, mais
avec ma slack 9.0, j'ai aussi ça, les runlevel. Donc j'ai du mal à
saisir...
Pareil ici. Mais n'est pas la question, je suppose. Tous les OS, les
Unix en tout cas, ont des runlevels.
En tout cas je trouve bien plus claire l'organisation de la slackware.
Idem ici.
GP
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Le dimanche 07 décembre 2003 à 16:10 GMT, Emmanuel Florac écrivait sur fr.comp.os.linux.debats :
Alors, si tous les services peut s'arrêter ainsi, quel est l'avantage du SysV ??
Les runlevels. Ca permet de démarrer (ou redémarrer) en mode X, ou en mode monoutilisateur, etc, sans modifier de fichier de config. Bon il est vrai que dans la pratique ça sert peu.
Heuh, veuillez m'excuser pour mon ignorance si tel est le cas, mais avec ma slack 9.0, j'ai aussi ça, les runlevel. Donc j'ai du mal à saisir...
Pareil ici. Mais n'est pas la question, je suppose. Tous les OS, les Unix en tout cas, ont des runlevels.
En tout cas je trouve bien plus claire l'organisation de la slackware.
Idem ici.
GP
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 100,000 Newsgroups - 19 Different Servers! =-----
