ant à lui dans 100% des cas. Il faut
>> juste ne pas être dans les 2%.
>
> Et tu peux vivre avec ce risque sur des machines de production ? Tes
> nuits doivent être mouvementées :)
Merci, mes nuits sont généralement calmes.
>>>>>> La
nctionne
dans 98% des cas. SysV fonctionne quant à lui dans 100% des cas. Il faut
juste ne pas être dans les 2%.
Et tu peux vivre avec ce risque sur des machines de production ? Tes
nuits doivent être mouvementées :)
La seule chose qui peut à la rigueur être faite, c'est de v
> Le 30-01-2018, à 14:15:30 +0100, Ph. Gras a écrit :
>
> > Qu'en sera-t-il de la commande service machin (start | restant | stop |
> > reload ) ?
Le Tue, Jan 30, 2018 at 02:37:08PM +0100, steve a écrit :
>
> C'est remplacé par
>
> systemctl (start|restart|stop|reload) le_nom_du_service
D'ail
ui fonctionne
dans 98% des cas. SysV fonctionne quant à lui dans 100% des cas. Il faut
juste ne pas être dans les 2%.
>>>> La seule chose qui peut à la rigueur être faite, c'est de virer de
>>>> /etc/init.d ce qui est explicitement transcrit dans /lib/systemd
>>&g
Le 30-01-2018, à 15:07:03 +0100, G2PC a écrit :
Salut Steve,
la commande suivante t'indiquera quels fichiers ne sont pas installés
par un paquet.
dpkg -S /etc/init.d/* | grep "no path"
Les autres peuvent rester: le responsable du paquet s'occupe (à son
rythme) de la mi
'ancien système ?
La seule chose qui peut à la rigueur être faite, c'est de virer de
/etc/init.d ce qui est explicitement transcrit dans /lib/systemd pour le
fonctionnement de l'usine à gaz avec des fuites.
Mais ces fichiers seront réinstallés à la prochaine maj. Donc assez
inutil
> Salut Steve,
>
> la commande suivante t'indiquera quels fichiers ne sont pas installés
> par un paquet.
>
> dpkg -S /etc/init.d/* | grep "no path"
>
> Les autres peuvent rester: le responsable du paquet s'occupe (à son
> rythme) de la migratio
steve a écrit :
> Le 29-01-2018, à 19:12:17 +0100, BERTRAND Joël a écrit :
>
>> steve a écrit :
>>>
>>> Salut,
>>
>> 'soir
>>
>>>
>>> M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
>>> principal
Le 30-01-2018, à 14:15:30 +0100, Ph. Gras a écrit :
Je ne sais pas si ça sert encore. Mais il semble être trop tôt pour l'enlever:
Ainsi, le répertoire init.d et tout ce qui s'y trouve devraient disparaître à
terme ?
Si le système tourne à 100% avec SystemD, oui.
Qu'en sera-t-il de la co
Hello there!
>> Je ne sais pas si ça sert encore. Mais il semble être trop tôt pour
>> l'enlever:
Ainsi, le répertoire init.d et tout ce qui s'y trouve devraient disparaître à
terme ?
Qu'en sera-t-il de la commande service machin (start | restant | stop | reload
) ?
Au plaisir,
Ph. Gras
Le 30-01-2018, à 20:13:16 +0900, Charles Plessy a écrit :
Le 30-01-2018, à 11:00:44 +0900, Charles Plessy a écrit :
>
> dpkg -S /etc/init.d/* | grep "no path"
Le Tue, Jan 30, 2018 at 09:05:02AM +0100, steve a écrit :
dpkg-query: aucun chemin ne correspond à /etc/init.d/.
> Le 30-01-2018, à 11:00:44 +0900, Charles Plessy a écrit :
> >
> > dpkg -S /etc/init.d/* | grep "no path"
Le Tue, Jan 30, 2018 at 09:05:02AM +0100, steve a écrit :
>
> dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.boot
> dpkg-query: aucun
Le 30-01-2018, à 11:00:44 +0900, Charles Plessy a écrit :
Le Mon, Jan 29, 2018 at 05:16:32PM +0100, steve a écrit :
M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
principale), je me demandais si les fichiers placés dans /etc/init.d/
sont encore utilisés ou s'ils
Le 29-01-2018, à 19:12:17 +0100, BERTRAND Joël a écrit :
steve a écrit :
Salut,
'soir
M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
principale), je me demandais si les fichiers placés dans /etc/init.d/
sont encore utilisés ou s'ils ne sont là que pour
Le Mon, Jan 29, 2018 at 05:16:32PM +0100, steve a écrit :
>
> M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
> principale), je me demandais si les fichiers placés dans /etc/init.d/
> sont encore utilisés ou s'ils ne sont là que pour une éventuelle
&g
Le 29/01/2018 à 17:16, steve a écrit :
>
> Salut,
>
>
> M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
> principale), je me demandais si les fichiers placés dans /etc/init.d/
> sont encore utilisés ou s'ils ne sont là que pour une éventuelle
&g
steve a écrit :
>
> Salut,
'soir
>
> M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
> principale), je me demandais si les fichiers placés dans /etc/init.d/
> sont encore utilisés ou s'ils ne sont là que pour une éventuelle
> compatibilité
Salut,
M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
principale), je me demandais si les fichiers placés dans /etc/init.d/
sont encore utilisés ou s'ils ne sont là que pour une éventuelle
compatibilité avec les systèmes utilisant SysVInit plutôt que systemd
On 15/11/2015 15:17, Dominique Dumont wrote:
>> Ah, donc si on veut se créer un service hors package, on doit
>> mettre son fichier unité dans /etc/systemd/ pas dans /lib/systemd,
>> c'est bien ça ?
>
> En local, oui.
>
> Tu peux aussi créer des services user dans ~/.config/systemd/user/
> cf. s
Le dimanche 8 novembre 2015, 12:29:24 12:29:24 Francois Lafont a écrit :
> Ah, donc si on veut se créer un service hors package, on doit
> mettre son fichier unité dans /etc/systemd/ pas dans /lib/systemd,
> c'est bien ça ?
En local, oui.
Tu peux aussi créer des services user dans ~/.config/syste
On 2015-11-08 20:04:45 +0100, Migrec wrote:
> Encore une chose : Quel est le service qui parcourt /etc/init.d/ à la
> recherche de scripts éventuellement non lancés via systemd "pur" ??
Je pense que ça ne peut pas être un service puisque cela risquerait
d'aboutir à des
u /usr/lib.
Merci pour vos réponses. J'ai bien compris qu'on était encore dans un double
système mais que c'est bien systemd qui lance les services...
Encore une chose : Quel est le service qui parcourt /etc/init.d/ à la
recherche de scripts éventuellement non lancés via systemd "pur" ??
On 2015-11-08 12:29:24 +0100, Francois Lafont wrote:
> Ah, donc si on veut se créer un service hors package, on doit
> mettre son fichier unité dans /etc/systemd/ pas dans /lib/systemd,
> c'est bien ça ?
Ce n'est pas propre à systemd. Ce qui est dans /lib est réservé aux
paquets Debian.
Concernan
Le dimanche 8 novembre 2015, 12:29:24 Francois Lafont a écrit :
>[…]
> > /lib/systemd contient la version par défaut, qui est
> > fournie par le paquet et qui devrait rester immuable.
> >
> > /etc/systemd contient ce qui est local.
>
> Ah, donc si on veut se créer un service hors package, o
On 08/11/2015 10:53, Sylvain L. Sauvage wrote:
>> ou dans /lib/systemd...
>
> Plutôt dans /etc/systemd.
>
> /lib/systemd contient la version par défaut, qui est fournie
> par le paquet et qui devrait rester immuable.
> /etc/systemd contient ce qui est local.
Ah, donc si on veut se créer
On 11/08/2015 03:42 AM, Francois Lafont wrote:
Pour moi, c'est au cas par cas, en fonction du paquet. Ce que j'ai compris,
c'est que de toute façon c'est toujours systemd qui lance le service sous
Jessie, que le package propose ou non un script init.d (c'est le côté un
peu facho de systemd ;)).
Le samedi 7 novembre 2015, 22:01:30 Migrec a écrit :
>[…]
> Ce qui m'embête avec cette histoire de systemd, c'est que on
> ne sait plus vraiment si la config doit être dans
> /etc/init.d/
Seulement si on ne veut utiliser que la compatibilité sysV.
> ou dans /lib/syste
est que on ne sait plus
> vraiment si la config doit être dans /etc/init.d/ ou dans /lib/systemd...
Pour moi, c'est au cas par cas, en fonction du paquet. Ce que j'ai compris,
c'est que de toute façon c'est toujours systemd qui lance le service sous
Jessie, que le package pro
On 2015-11-07 22:01:30 +0100, Migrec wrote:
> Ce qui m'embête avec cette histoire de systemd, c'est que on ne sait plus
> vraiment si la config doit être dans /etc/init.d/ ou dans /lib/systemd...
Normalement, les paquets devraient fournir les deux, car toutes
les machines
-
>
> Puis :
>
> systemctl enable myservice # activation du démarrage automatique du
> service à chaque boot systemctl start myservice # démarrage du service
Ce qui m'embête avec cette histoire de systemd, c'est que on ne sait plus
vraiment si la config doit être
Re,
On 06/11/2015 17:06, Francois Lafont wrote:
> Bref, tout ça pour dire que si tu es sous systemd tu devrais laisser
> tomber ton script init.d et utiliser systemd directement via une
> une unité. Pour le coup (et c'est un des gros intérêts de systemd)
> c'est vraiment très simple à écrire. Et
un script "perso" qui est dans
> /etc/init.d/fwbuilder
>
> Pourquoi est-il exécuté ? Il me semble que ce n'est pas l'emplacement des
> "unités" ?
Mais systemd est capable (en théorie) de gérer le démarrage etc. des scripts
sysvinit (ie des scripts
ratiques...
>
> Sur mon serveur mis à jour depuis peu en version stable, le nouveau systemd a
> remplacé l'ancien système. J'ai un soucis avec un script "perso" qui est dans
> /etc/init.d/fwbuilder
>
> Pourquoi est-il exécuté ? Il me semble que ce n'e
Bonjour,
Je me suis documenté sur le systemd mais j'ai encore quelques question
pratiques...
Sur mon serveur mis à jour depuis peu en version stable, le nouveau systemd a
remplacé l'ancien système. J'ai un soucis avec un script "perso" qui est dans
/etc/init.d/f
Gaëtan PERRIER a écrit :
> Le Sun, 01 Sep 2013 13:48:51 +0200
> daniel huhardeaux a écrit:
>> Saulf que en pre-up et dhcp, si les règles sont basées sur l IP
>> publique, celle ci n'est pas encore connue, il faut donc le faire en
>> 2 temps: pre-up protège l'interface, post-up pour les règles lié
Le Sun, 01 Sep 2013 13:48:51 +0200
daniel huhardeaux a écrit:
> Bonjour,*
>
> *Le 01/09/2013 10:00, François TOURDE a écrit :
> > Le 15949ième jour après Epoch,
> > Gaëtan PERRIER écrivait:
> >
> >> Bonsoir,
> >>
> >> C'est possible quand on est sur un réseau statique mais avec une
> >> réseau e
Bonjour,*
*Le 01/09/2013 10:00, François TOURDE a écrit :
Le 15949ième jour après Epoch,
Gaëtan PERRIER écrivait:
Bonsoir,
C'est possible quand on est sur un réseau statique mais avec une réseau
en dhcp ça ne me semble pas possible, non ?
Idem qu'en statique, sauf que la ligne de l'interface
François TOURDE wrote on Sun, Sep 01, 2013 at 10:00:55AM +0200
> Le 15949ième jour après Epoch,
> Gaëtan PERRIER écrivait:
>
> > Bonsoir,
> >
> > C'est possible quand on est sur un réseau statique mais avec une réseau
> > en dhcp ça ne me semble pas possible, non ?
>
> Idem qu'en statique, sauf q
Bonjour,
Là encore, je pense que if-pre-up.d serait plus indiqué.
De cette manière, le firewall est appliqué avant l'activation de
l'interface :)
Cordialement,
JB
Le 01/09/2013 10:00, François TOURDE a écrit :
> Le 15949ième jour après Epoch, Gaëtan PERRIER écrivait:
>
>> Bonsoir,
>>
>> C'est
Le 15949ième jour après Epoch,
Gaëtan PERRIER écrivait:
> Bonsoir,
>
> C'est possible quand on est sur un réseau statique mais avec une réseau
> en dhcp ça ne me semble pas possible, non ?
Idem qu'en statique, sauf que la ligne de l'interface est du style
>> auto eth0
>> iface eth0 inet dhcp
>>
zz.1
> > pre-up "/usr/local/sbin/firewall.sh"
> >
> > De cette manière, le firewall est chargé avant que l'interface ne soit
> > activée et configurée.
> >
> > Cordialement,
> > JB
> >
> > Le 31/08/2013 22:21, Dominique Asselineau a écrit :
&g
ière, le firewall est chargé avant que l'interface ne soit
> activée et configurée.
>
> Cordialement,
> JB
>
> Le 31/08/2013 22:21, Dominique Asselineau a écrit :
> > Bonjour,
> >
> > J'ai adapté un firewall à partir de la doc de Debian security, que
> > j
firewall est chargé avant que l'interface ne soit
activée et configurée.
Cordialement,
JB
Le 31/08/2013 22:21, Dominique Asselineau a écrit :
> Bonjour,
>
> J'ai adapté un firewall à partir de la doc de Debian security, que
> j'ai placé dans /etc/init.d/ et j'aurai
Bonjour,
J'ai adapté un firewall à partir de la doc de Debian security, que
j'ai placé dans /etc/init.d/ et j'aurais souhaité le faire exécuter au
bon moment lors du démarrage.
Au début du script il faut donc placer des lignes d'en-tête pour que
insserv l'insère au bon
. Mais j'ai des warning à chaque upgrade de paquets ayant un
>> fichier dans init.d.
>>
>> En particulier j'ai ce warning ci :
>> insserv: warning: script 'S22xserver-xorg' missing LSB tags and overrides
>> insserv: warning: script 'xserver-xorg&#x
aquets ayant un
> fichier dans init.d.
>
> En particulier j'ai ce warning ci :
> insserv: warning: script 'S22xserver-xorg' missing LSB tags and overrides
> insserv: warning: script 'xserver-xorg' missing LSB tags and overrides
>
> j'ai bien un fich
i :
insserv: warning: script 'S22xserver-xorg' missing LSB tags and overrides
insserv: warning: script 'xserver-xorg' missing LSB tags and overrides
j'ai bien un fichier /etc/init.d/xserver-xorg. mais la date de celui ci
me laisse à penser qu'il n'est plus tr
e l'ai donc installé avec
> aptitude mais il n'a pas crée de script de démarrage dans /etc/init.d/
>
> quelqu'un aurai une idée ou une copie de script à me passer?
>
> si non comment puis-je démarrer stunnel? /usr/sbin/stunnel?
/usr/bin/stunnel plus précisément. Tu
mais j'ai juste une petite question.
stunnel n'était pas installé sur ma machine, je l'ai donc installé
avec aptitude mais il n'a pas crée de script de démarrage dans
/etc/init.d/
quelqu'un aurai une idée ou une copie de script à me passer?
si non comment puis-je démarrer
Bonjour à tous ou plutôt rebonjour.
Je suis toujours en train de configurer mon Postfix en trichant avec
stunnel mais j'ai juste une petite question.
stunnel n'était pas installé sur ma machine, je l'ai donc installé avec
aptitude mais il n'a pas crée de script de démarr
giggz wrote:
Slt,
Je suis en sid (installé depuis woody...ça fait un bail). En regardant
ds /etc/init.d/ j'ai vu que xfree86-common était tjs présent. Peut on
l'enlever ss risque ?
Merci d'avance
GiGGz
Je me suis aussi posé la question et
Je l&
Slt,
Je suis en sid (installé depuis woody...ça fait un bail). En regardant
ds /etc/init.d/ j'ai vu que xfree86-common était tjs présent. Peut on
l'enlever ss risque ?
Merci d'avance
GiGGz
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?Debia
Le Mercredi 1 Février 2006 14:32, Florentin Duneau a écrit :
> Bonjour
>
> Comme l'explique le sujet, le script /etc/init.d/alsa-utils ne charge pas
> la config au démarrage. Les scripts /etc/rcS.d/S50alsa-utils
> et /etc/rc0.d/K50alsa-utils sont à priori bien exécutés. La s
Thierry B wrote:
Vincent Danjean a écrit :
Florentin Duneau wrote:
[...]
Je ne comprends pas pourquoi la config n'est pas chargée lors de
l'exécution de /etc/rcS.d/S50alsa-utils. Une idée ?
Dans ces cas là, je boote avec le paramètre supplémentaire
"init=/bin/sh", puis je lance tous les s
Vincent Danjean a écrit :
> Florentin Duneau wrote:
>> Bonjour
>>
>> Comme l'explique le sujet, le script /etc/init.d/alsa-utils ne charge
>> pas la config au démarrage. Les scripts /etc/rcS.d/S50alsa-utils et
>> /etc/rc0.d/K50alsa-utils sont à priori bi
Florentin Duneau wrote:
Bonjour
Comme l'explique le sujet, le script /etc/init.d/alsa-utils ne charge pas la
config au démarrage. Les scripts /etc/rcS.d/S50alsa-utils
et /etc/rc0.d/K50alsa-utils sont à priori bien exécutés. La seule solution
pour récupérer le son est de faire /etc/i
Le Mercredi 1 Février 2006 17:33, Frédéric Bothamy a écrit :
> * Florentin Duneau <[EMAIL PROTECTED]> [2006-02-01 17:14] :
> > Le Mercredi 1 Février 2006 16:16, Jean-Luc Coulon (f5ibh) a écrit :
> > > Le 01.02.2006 16:07:29, Florentin Duneau a écrit :
> > >
> > >
> > >
> > > > DHCPREQUEST on
Florentin Duneau a écrit :
Bonjour
Comme l'explique le sujet, le script /etc/init.d/alsa-utils ne charge pas la
config au démarrage. Les scripts /etc/rcS.d/S50alsa-utils
et /etc/rc0.d/K50alsa-utils sont à priori bien exécutés. La seule solution
pour récupérer le son est de faire /etc/i
* Florentin Duneau <[EMAIL PROTECTED]> [2006-02-01 17:14] :
> Le Mercredi 1 Février 2006 16:16, Jean-Luc Coulon (f5ibh) a écrit :
> > Le 01.02.2006 16:07:29, Florentin Duneau a écrit :
> >
> >
> >
> > > DHCPREQUEST on eth0 to 255.255.255.255 port 67
> > > DHCPACK from 192.168.0.1
> > > boun
es and remove the snd-cs46xx module
# "all" Stop sound processes and remove all ALSA modules
force_unload_modules_before_suspend=""
> Quels sont les modules chargés avant de relancer le tout à la main ?
>
lsmod avant /etc/init.d/alsa-utils restart :
Module Size Used by
Le 01.02.2006 16:07:29, Florentin Duneau a écrit :
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.4 -- renewal in 43200 seconds.
done.
^[]RSetting up general console font... done.
Setting up per-VC ACM's
^[[9;30]^[[14;30]Setting up ALSA..
Voici le bootlog
.
null symbol found
Setting parameters of disc
Will now activate swap.
swapon on /dev/hda2
Done activating swap.
Will now check root file system.
fsck 1.39-WIP (31-Dec-2005)
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -C0 /dev/hda3
/ has been mounted 30 times without being c
Le Mercredi 1 Février 2006 14:35, Jean-Luc Coulon (f5ibh) a écrit :
>
> Sans doute y a-t-il un message (voir dmesg, bootlog ou syslog) qui
> contient une amorce d'explicaiton.
>
> Jean-Luc
Non, rien de rien dans syslog, dmesg et bootlog. Je n'ai pas la ligne "Setting
Up Alsa... " dans bootlog, j'
Le 01.02.2006 14:32:07, Florentin Duneau a écrit :
Bonjour
Comme l'explique le sujet, le script /etc/init.d/alsa-utils ne charge
pas la
config au démarrage. Les scripts /etc/rcS.d/S50alsa-utils
et /etc/rc0.d/K50alsa-utils sont à priori bien exécutés. La seule
solution
pour récupérer le so
Bonjour
Comme l'explique le sujet, le script /etc/init.d/alsa-utils ne charge pas la
config au démarrage. Les scripts /etc/rcS.d/S50alsa-utils
et /etc/rc0.d/K50alsa-utils sont à priori bien exécutés. La seule solution
pour récupérer le son est de faire /etc/init.d/alsa-utils start dan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
dédé le homard wrote:
| bonjour,
|
| peut on lancer un script par /etc/init.d/... ,mais en utilisateur
normal, et
| non en root ?
|
| et surtout, je voudrais lancer le démon giftd sur un terminal , en
plus de la
| session x( par exemple sur le
dédé le homard <[EMAIL PROTECTED]> writes:
> bonjour,
>
> peut on lancer un script par /etc/init.d/... ,mais en utilisateur normal, et
> non en root ?
Ta question est-elle « Peut-on lancer un daemon au démarrage en temps
qu'utilisateur normal ? ».
Dans ce cas, il y a un
Si c'est pas les droits d'accès à /dev/tty4, ça doit être les droits d'accès
au binaire
Là comme ça je vois que ça !
--
Laurent
---
Mon site : http://www.monptilinux.fr.st
Designed only with free softwares.
Le Jeudi 11 Septembre 2003 14:22, Laurent a écrit :
> Le Jeudi 11 Septembre 2003 21:53, dédé le homard a écrit :
> > bonjour,
> >
> >
>
> T'as les droits d'écriture sur /dev/tty4 ?
oui, j'ai fait adduser christo tty ( utilisateur christo) et j'ai donné les
droits d'acces à tty4 à christo, pourtant
Le jeu 11/09/2003 à 21:53, dédé le homard a écrit :
Tu vis dans le futur!
> bonjour,
>
> peut on lancer un script par /etc/init.d/... ,mais en utilisateur normal, et
> non en root ?
Oui si tu l'utilisateur a les droits nécessaires pour accéder aux
ressources.
>
>
On Thu, Sep 11, 2003 at 05:53:48PM -0200, dédé le homard wrote:
> bonjour,
>
> peut on lancer un script par /etc/init.d/... ,mais en utilisateur normal, et
> non en root ?
>
Il y a eu à ce sujet un thread que je n'ai pas lu, sur -devel.
http://lists.debian.org/debian-dev
Le Jeudi 11 Septembre 2003 21:53, dédé le homard a écrit :
> bonjour,
>
> peut on lancer un script par /etc/init.d/... ,mais en utilisateur normal,
> et non en root ?
>
Je ne pense qu'il y ait d'impossibilité de ce coté là.
> et surtout, je voudrais lancer le démo
bonjour,
peut on lancer un script par /etc/init.d/... ,mais en utilisateur normal, et
non en root ?
et surtout, je voudrais lancer le démon giftd sur un terminal , en plus de la
session x( par exemple sur le terminal 4, ctrl-alt-f4 ) automatiquement au
démarage du système, est ce possible
er
la probabilité de récupérer un service sans intervention humaine (des
fois, on ne s'aperçoit même pas que le service est tombé, mais quand on
le remarque c'est quand y'a personne pour le relancer, loi de Murphy).
Donc, voilà, première expérience :
30 * * * * root /etc/init.
> > Pratiquement toutes les permissions des fichiers de /etc/init.d/ sont
à
> > 755. C'est bon ça au niveau sécurité ?
> >
> > Et si on les met à 744 est-ce que cela risque de causer des Pbs ?
Je ne vois pas ce que cela changerait, il est toujours possible de cop
* Philippe Monroux <[EMAIL PROTECTED]> [2002-12-13 10:58] :
> Bonjour,
>
> tite question comme ça...:)
>
> Pratiquement toutes les permissions des fichiers de /etc/init.d/ sont à
> 755. C'est bon ça au niveau sécurité ?
>
> Et si on les met à 744 est-ce que
Salut,
Il ne semble pas qu'il y ai de problème.
Pour eviter le lancement de demon, la doc securing-debian-howto, ils disent que
certain empêchent le lancement des demons avec "chmod 644 /etc/init.d/demon".
Mais, cette méthode n'est pas recommandée. De plus, tu auras un
Bonjour,
tite question comme ça...:)
Pratiquement toutes les permissions des fichiers de /etc/init.d/ sont à
755. C'est bon ça au niveau sécurité ?
Et si on les met à 744 est-ce que cela risque de causer des Pbs ?
Phil
--
Le savant n'est pas l'homme qui fournit les vraies
On Saturday 23 November 2002 09:14, [EMAIL PROTECTED] wrote:
> Tout ce qu'il y a de plus normal !
Ah bin non ! Tu récupères du 'stable' et du 'woody', c'est bien la même chose
(pour l'instant...) mais aussi du 'testing', et là, c'est plus pareil ! C'est
du 'sarge' !
Il serait peut-être bon
La version de sendmail est : (8.12.6-7).
Mon sources.list :
deb http://http.us.debian.org/debian stable main contrib non-free
deb http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free
deb http://security.debian.org stable/updates main contrib non-free
deb http://security.deb
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2002-11-22 17:23] :
> Bonjour,
>
> après un apt-get install sendmail et la configuration qui s'en suit, woody
> essaye de démarrer le MTA et j'ai un message d'erreur :
>
> Starting Mail Transport Agent: sendmail/usr/sbin/sendmail: /lib/libc.so.6:
> ver
Bonjour,
après un apt-get install sendmail et la configuration qui s'en suit, woody
essaye de démarrer le MTA et j'ai un message d'erreur :
Starting Mail Transport Agent: sendmail/usr/sbin/sendmail: /lib/libc.so.6:
version `GLIBC_2.3' not found (required by /usr/sbin/sendmail)
/usr/sbin/sendm
Christian Marillat <[EMAIL PROTECTED]> writes:
[...]
>> Cependant, imaginons que l'on souhaite temporairement suspendre un
>> service ; je dis bien : imaginons. Le fait de supprimer le script de
>> /etc/init.d/ va rendre impossible la réactivation de ce derni
/etc/rcS.d/ montent tous les systèmes
de fichiers et le réseau est disponible (cf. /etc/rcS.d/README)
> Si tu supprime le service avec update-rc.d, tu perds l'ordre (à moins > de
> le noter, mais on oublie toujours), c'est pourquoi il est
> préférable de
> renommer le
> /etc/rc2.d/ (si tu es au level 2)
> mv S20exim _S20exim
Bonjour (enfin Bonne nuit plutôt),
Mon humble contribution :
Plutôt que de renommer le lien (ou de le déplacer dans un
répertoire d'archive ce qui revient au même...), je suis plutôt
d'avis qu'il faut créer un lien pour terminer le proces
ce avec update-rc.d, tu perds l'ordre (à moins de
le noter, mais on oublie toujours), c'est pourquoi il est préférable de
renommer le script de /etc/init.d/, ou de coller un "exit 0" au début,
ou de faire par exemple un faux script :
# cd /etc/init.d/
# mv service service.orig
# ec
is bien : imaginons. Le fait de supprimer le script de
> /etc/init.d/ va rendre impossible la réactivation de ce dernier (par
> update-rc.d), sauf réinstallation du paquetage correspondant, non ? Je
> me gourre complètement ? Il existe une autre commande pour le
> réinstaller ce script ?
renommer
les liens dans le rc du level correspondant le lien fera appel à rien.
> -Message d'origine-
> De : Nicolas Kowalski [mailto:[EMAIL PROTECTED]
> Envoyé : jeudi 10 octobre 2002 22:26
> À : debian-user-french@lists.debian.org
> Objet : /etc/init.d [was: Re: RE : Question
oves
any links in the /etc/rcrunlevel.d directories to the
script /etc/init.d/name. The script must have been
deleted already - update-rc.d checks for this.
Diable ! Je ne l'avais pas vu ce paragraphe là...
Cependant, imaginons que l'on souhaite tempo
Edi STOJICEVIC <[EMAIL PROTECTED]> writes:
[...]
> extrait du man :
> REMOVING SCRIPTS
>When invoked with the remove option, update-rc.d removes
>any links in the /etc/rcrunlevel.d directories to the
> script /etc/init.d/name. The scri
Le 30/03/02, axel a ecrit:
> Bonjour à tous,
>
> J'ai un script de reconnection Adsl (eci) qui fait référence
> à un fichier functions que je ne parviens pas à localiser:
>
> extrait du fichier :
>
> # Source function library.
> . /etc/init.d/functions
> EC
Bonjour à tous,
J'ai un script de reconnection Adsl (eci) qui fait référence
à un fichier functions que je ne parviens pas à localiser:
extrait du fichier :
# Source function library.
. /etc/init.d/functions
ECI_SRCRIPT=/usr/local/bin/startmodem
LOG_DIR=/var/log
ECI_LOG=$LOG_DIR/eci.log
Laurent Pichard wrote:
>
> Bonjour,
Salut,
>[...]
> Je crois qu'il faut faire:
>ln -s /usr/share/keymaps/i386/azerty/fr-latin0.kmap.gz
>/etc/console/boottime.kmap.gz
>
> A mon avis, cela revient au même que de faire:
> #dpkg-reconfigure console-data
> Puis sélectionner:
> Select ke
Laurent Pichard wrote:
>
> Bonjour,
>
> Je viens de lire: Utiliser et configurer Debian pour le français de
> [...]
> Mais le Chapitre 3 Configurer l'entrée et la sortie en français n'est pas
> conforme à ma configuration Woody.
Effectivement, il a été rectifié à la va-vite juste avant mon dépa
Le Samedi 29 Septembre 2001 20:18, Laurent Pichard a écrit :
> Bonjour,
Bonsoir,
> Donc, au lieu de faire:
> ln -s /usr/share/keymaps/i386/azerty/fr-latin0.kmap.gz
> /etc/console-tools/default.kmap.gz
> Je crois qu'il faut faire:
> ln -s /usr/share/keymaps/i386/azerty/fr-latin0.kmap.gz
>
iguration Woody.
D'après ce que j'ai compris, Il est expliqué que sous Debian Woody:
/etc/init.d/keymaps.sh appelle le fichier
/etc/console-tools/default.kmap.gz
Chez moi, Le fichier s'appelle en réalité keymap.sh (sans s) et il appelle
/etc/console/boottime.kmap.gz (pas /etc/console
96 matches
Mail list logo
