(Michel Talon) writes:Bin, j'aime mieux le init BSD, c'est certain. Quel est l'avantage de ce
foutoir SysV ?
De pouvoir démarrer ou éteindre chaque service individuellement, et de
pouvoir démarrer les services dans un ordre spécifique, en fonction des
dépendances requises, sans avoir à touiller les shell scripts.
Et de pouvoir ajouter enjouter/enlever des services en
ajoutant/enlevant des scripts dans des répertoires, plutôt qu'en
allant bidouiller un fichier ou une "base de registres" contenant la
liste des services à lancer pour chaque niveau (à la /etc/inittab).
talon@lpthe.jussieu.fr (Michel Talon) writes:
Bin, j'aime mieux le init BSD, c'est certain. Quel est l'avantage de ce
foutoir SysV ?
De pouvoir démarrer ou éteindre chaque service individuellement, et de
pouvoir démarrer les services dans un ordre spécifique, en fonction des
dépendances requises, sans avoir à touiller les shell scripts.
Et de pouvoir ajouter enjouter/enlever des services en
ajoutant/enlevant des scripts dans des répertoires, plutôt qu'en
allant bidouiller un fichier ou une "base de registres" contenant la
liste des services à lancer pour chaque niveau (à la /etc/inittab).
(Michel Talon) writes:Bin, j'aime mieux le init BSD, c'est certain. Quel est l'avantage de ce
foutoir SysV ?
De pouvoir démarrer ou éteindre chaque service individuellement, et de
pouvoir démarrer les services dans un ordre spécifique, en fonction des
dépendances requises, sans avoir à touiller les shell scripts.
Et de pouvoir ajouter enjouter/enlever des services en
ajoutant/enlevant des scripts dans des répertoires, plutôt qu'en
allant bidouiller un fichier ou une "base de registres" contenant la
liste des services à lancer pour chaque niveau (à la /etc/inittab).
Et la présence du script /etc/rc.sysvinit dans les distributions
Slackware remonte à la plus haute antiquité.
Et la présence du script /etc/rc.sysvinit dans les distributions
Slackware remonte à la plus haute antiquité.
Et la présence du script /etc/rc.sysvinit dans les distributions
Slackware remonte à la plus haute antiquité.
Et puis, pour quelqu'un qui veut arrêter et repartir des services à
toutes les 5 minutes, est-ce que webmin ne peut pas faire ça?
Écoute, je veux bien croire que tu te débrouilles avec SysV. Et il se
peut qu'il y en ait peut-être un ou deux à part toi mais, à moins que
je tombe sur une doc vraiment illuminante, je pense que je vais
laisser ça à d'autres.
Et puis, pour quelqu'un qui veut arrêter et repartir des services à
toutes les 5 minutes, est-ce que webmin ne peut pas faire ça?
Écoute, je veux bien croire que tu te débrouilles avec SysV. Et il se
peut qu'il y en ait peut-être un ou deux à part toi mais, à moins que
je tombe sur une doc vraiment illuminante, je pense que je vais
laisser ça à d'autres.
Et puis, pour quelqu'un qui veut arrêter et repartir des services à
toutes les 5 minutes, est-ce que webmin ne peut pas faire ça?
Écoute, je veux bien croire que tu te débrouilles avec SysV. Et il se
peut qu'il y en ait peut-être un ou deux à part toi mais, à moins que
je tombe sur une doc vraiment illuminante, je pense que je vais
laisser ça à d'autres.
OoO En ce début d'après-midi ensoleillé du dimanche 07 décembre 2003,
vers 15:52, GP disait:Et puis, pour quelqu'un qui veut arrêter et repartir des services à
toutes les 5 minutes, est-ce que webmin ne peut pas faire ça?
Comment remplacer un système incroyablement simple par une usine à
gaz.
Écoute, je veux bien croire que tu te débrouilles avec SysV. Et il se
peut qu'il y en ait peut-être un ou deux à part toi mais, à moins que
je tombe sur une doc vraiment illuminante, je pense que je vais
laisser ça à d'autres.
SysV est d'une simplicité déconcertante, il est beaucoup plus simple
de s'y retrouver qu'avec un script type BSD que l'on doit lire d'un
bout à l'autre.
OoO En ce début d'après-midi ensoleillé du dimanche 07 décembre 2003,
vers 15:52, GP <gilpel@inverse.nretla.org> disait:
Et puis, pour quelqu'un qui veut arrêter et repartir des services à
toutes les 5 minutes, est-ce que webmin ne peut pas faire ça?
Comment remplacer un système incroyablement simple par une usine à
gaz.
Écoute, je veux bien croire que tu te débrouilles avec SysV. Et il se
peut qu'il y en ait peut-être un ou deux à part toi mais, à moins que
je tombe sur une doc vraiment illuminante, je pense que je vais
laisser ça à d'autres.
SysV est d'une simplicité déconcertante, il est beaucoup plus simple
de s'y retrouver qu'avec un script type BSD que l'on doit lire d'un
bout à l'autre.
OoO En ce début d'après-midi ensoleillé du dimanche 07 décembre 2003,
vers 15:52, GP disait:Et puis, pour quelqu'un qui veut arrêter et repartir des services à
toutes les 5 minutes, est-ce que webmin ne peut pas faire ça?
Comment remplacer un système incroyablement simple par une usine à
gaz.
Écoute, je veux bien croire que tu te débrouilles avec SysV. Et il se
peut qu'il y en ait peut-être un ou deux à part toi mais, à moins que
je tombe sur une doc vraiment illuminante, je pense que je vais
laisser ça à d'autres.
SysV est d'une simplicité déconcertante, il est beaucoup plus simple
de s'y retrouver qu'avec un script type BSD que l'on doit lire d'un
bout à l'autre.
Vincent Bernat wrote:SysV est d'une simplicité déconcertante, il est beaucoup plus simple
de s'y retrouver qu'avec un script type BSD que l'on doit lire d'un
bout à l'autre.
Peut-être, lorsqu'on en comprend le principe. Ce qui n'est pas encore
mon cas.
Vincent Bernat wrote:
SysV est d'une simplicité déconcertante, il est beaucoup plus simple
de s'y retrouver qu'avec un script type BSD que l'on doit lire d'un
bout à l'autre.
Peut-être, lorsqu'on en comprend le principe. Ce qui n'est pas encore
mon cas.
Vincent Bernat wrote:SysV est d'une simplicité déconcertante, il est beaucoup plus simple
de s'y retrouver qu'avec un script type BSD que l'on doit lire d'un
bout à l'autre.
Peut-être, lorsqu'on en comprend le principe. Ce qui n'est pas encore
mon cas.
Je remplace donc ca par un script firewall avec ses start/stop/reload,
et la bordée de règles iptables (ou ipchains) kivonbien, avec les
commentaires qui expliquent pourquoi on a ajouté un jour tel ou tel
truc pour une situation particulière.
MB
Je remplace donc ca par un script firewall avec ses start/stop/reload,
et la bordée de règles iptables (ou ipchains) kivonbien, avec les
commentaires qui expliquent pourquoi on a ajouté un jour tel ou tel
truc pour une situation particulière.
MB
Je remplace donc ca par un script firewall avec ses start/stop/reload,
et la bordée de règles iptables (ou ipchains) kivonbien, avec les
commentaires qui expliquent pourquoi on a ajouté un jour tel ou tel
truc pour une situation particulière.
MB
Michel BILLAUD wrote:
Je remplace donc ca par un script firewall avec ses start/stop/reload,
et la bordée de règles iptables (ou ipchains) kivonbien, avec les
commentaires qui expliquent pourquoi on a ajouté un jour tel ou tel
truc pour une situation particulière.
iptables -L
ça ne fait pas l'affaire pour voir ce que tu as dans tes règles?
Michel BILLAUD <billaud@labri.u-bordeaux.fr> wrote:
Je remplace donc ca par un script firewall avec ses start/stop/reload,
et la bordée de règles iptables (ou ipchains) kivonbien, avec les
commentaires qui expliquent pourquoi on a ajouté un jour tel ou tel
truc pour une situation particulière.
iptables -L
ça ne fait pas l'affaire pour voir ce que tu as dans tes règles?
Michel BILLAUD wrote:
Je remplace donc ca par un script firewall avec ses start/stop/reload,
et la bordée de règles iptables (ou ipchains) kivonbien, avec les
commentaires qui expliquent pourquoi on a ajouté un jour tel ou tel
truc pour une situation particulière.
iptables -L
ça ne fait pas l'affaire pour voir ce que tu as dans tes règles?
Ca me parait assez casse-gueule, parce que non "auditable".
Personnellement j'aime bien pouvoir imprimer et relire calmement les
règles de filtrage, et être sur que les règles utilisées sont celles
qui sont écrites, et inversement. Et non pas les restes d'un petit
bricolage temporaire qui perdure sans que je m'en rende compte.
/etc/init.d/iptable => poubelle
Ca me parait assez casse-gueule, parce que non "auditable".
Personnellement j'aime bien pouvoir imprimer et relire calmement les
règles de filtrage, et être sur que les règles utilisées sont celles
qui sont écrites, et inversement. Et non pas les restes d'un petit
bricolage temporaire qui perdure sans que je m'en rende compte.
/etc/init.d/iptable => poubelle
Ca me parait assez casse-gueule, parce que non "auditable".
Personnellement j'aime bien pouvoir imprimer et relire calmement les
règles de filtrage, et être sur que les règles utilisées sont celles
qui sont écrites, et inversement. Et non pas les restes d'un petit
bricolage temporaire qui perdure sans que je m'en rende compte.
/etc/init.d/iptable => poubelle
GP writes:Vincent Bernat wrote:SysV est d'une simplicité déconcertante, il est beaucoup plus simple
de s'y retrouver qu'avec un script type BSD que l'on doit lire d'un
bout à l'autre.
Peut-être, lorsqu'on en comprend le principe. Ce qui n'est pas encore
mon cas.
Nous voilà rassurés. Un instant on a pu croire que le principe y était
quelque chose.
Pour en revenir au sujet, le script /etc/init.d/iptable de la debian
me parait assez criticable, parce qu'il est basé sur la remise en place,
au démarrage, de la "machine de filtrage" dans l'état où on l'a laissé au
dernier arrêt.
Ca me parait assez casse-gueule, parce que non "auditable".
Personnellement j'aime bien pouvoir imprimer et relire calmement les
règles de filtrage, et être sur que les règles utilisées sont celles
qui sont écrites, et inversement. Et non pas les restes d'un petit
bricolage temporaire qui perdure sans que je m'en rende compte.
/etc/init.d/iptable => poubelle
Je remplace donc ca par un script firewall avec ses start/stop/reload,
et la bordée de règles iptables (ou ipchains) kivonbien
GP <gilpel@inverse.nretla.org> writes:
Vincent Bernat wrote:
SysV est d'une simplicité déconcertante, il est beaucoup plus simple
de s'y retrouver qu'avec un script type BSD que l'on doit lire d'un
bout à l'autre.
Peut-être, lorsqu'on en comprend le principe. Ce qui n'est pas encore
mon cas.
Nous voilà rassurés. Un instant on a pu croire que le principe y était
quelque chose.
Pour en revenir au sujet, le script /etc/init.d/iptable de la debian
me parait assez criticable, parce qu'il est basé sur la remise en place,
au démarrage, de la "machine de filtrage" dans l'état où on l'a laissé au
dernier arrêt.
Ca me parait assez casse-gueule, parce que non "auditable".
Personnellement j'aime bien pouvoir imprimer et relire calmement les
règles de filtrage, et être sur que les règles utilisées sont celles
qui sont écrites, et inversement. Et non pas les restes d'un petit
bricolage temporaire qui perdure sans que je m'en rende compte.
/etc/init.d/iptable => poubelle
Je remplace donc ca par un script firewall avec ses start/stop/reload,
et la bordée de règles iptables (ou ipchains) kivonbien
GP writes:Vincent Bernat wrote:SysV est d'une simplicité déconcertante, il est beaucoup plus simple
de s'y retrouver qu'avec un script type BSD que l'on doit lire d'un
bout à l'autre.
Peut-être, lorsqu'on en comprend le principe. Ce qui n'est pas encore
mon cas.
Nous voilà rassurés. Un instant on a pu croire que le principe y était
quelque chose.
Pour en revenir au sujet, le script /etc/init.d/iptable de la debian
me parait assez criticable, parce qu'il est basé sur la remise en place,
au démarrage, de la "machine de filtrage" dans l'état où on l'a laissé au
dernier arrêt.
Ca me parait assez casse-gueule, parce que non "auditable".
Personnellement j'aime bien pouvoir imprimer et relire calmement les
règles de filtrage, et être sur que les règles utilisées sont celles
qui sont écrites, et inversement. Et non pas les restes d'un petit
bricolage temporaire qui perdure sans que je m'en rende compte.
/etc/init.d/iptable => poubelle
Je remplace donc ca par un script firewall avec ses start/stop/reload,
et la bordée de règles iptables (ou ipchains) kivonbien
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.
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.
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.
