rebooter serveur ssh en mode console ?
ctobini
J'ai besoin d'un petit renseignement sur le serveur ssh de Mac OS X: je
me connecte à distance sur mon Mac et je voudrais savoir comment
redémarrer sshd en mode console.
En effet, si je modifie sshd_config, je voudrais pouvoir redémarrer le
serveur ssh sans forcément rebooter le Mac :-)
En vous remerciant,
C. Tobini
patpro ~ Patrick Proniewski
"ctobini" <cte...@free.fr> wrote:
> Bonjour,
>
> J'ai besoin d'un petit renseignement sur le serveur ssh de Mac OS X: je
> me connecte à distance sur mon Mac et je voudrais savoir comment
> redémarrer sshd en mode console.
>
> En effet, si je modifie sshd config, je voudrais pouvoir redémarrer le
> serveur ssh sans forcément rebooter le Mac :-)
sur MacOS X c'est inutile. sshd est lancé "on demand" par launchd, donc
si tu attends que le sshd quitte tout seul (en te déconnectant et en
attendant un peu), le sshd_config sera lu à la prochaine connexion.
D'ailleurs je me demande même si c'est utile d'attendre avant de se
reconnecter, mais dans le doute...
patpro
Nicolas MICHEL
en plus de ce qu'a dit patpro :
~> sudo launchctl list |grep sshd
com.openssh.sshd
~> man launchctl |grep -A1 -B1 restart
stop joblabels ...
Stop the specified jobs by label. Jobs may restart automatically
if demand driven.
Donc un truc de ce genre devrait relancer le service (et non le daemon,
lequel se lance sur demande)
~> sudo launchctl stop com.openssh.sshd
(a tester)
--
Nicolas
Vincent Lefevre
patpro ~ Patrick Proniewski <pat...@boleskine.patpro.net> écrit:
> In article <1165912782....@j72g2000cwa.googlegroups.com>,
> "ctobini" <cte...@free.fr> wrote:
[...]
> > En effet, si je modifie sshd config, je voudrais pouvoir redémarrer le
> > serveur ssh sans forcément rebooter le Mac :-)
> sur MacOS X c'est inutile. sshd est lancé "on demand" par launchd, donc
> si tu attends que le sshd quitte tout seul (en te déconnectant et en
> attendant un peu), le sshd_config sera lu à la prochaine connexion.
Au cas où l'utilisateur aurait installé un autre sshd qui n'est pas
lancé "on demand" (c'est mon cas, pour avoir un OpenSSH plus récent),
"man sshd" dit:
sshd rereads its configuration file when it receives a hangup
signal, SIGHUP, by executing itself with the name and options
it was started with, e.g., /usr/sbin/sshd.
Note: cette fonctionnalité de relire son fichier de config quand
on reçoit tel signal n'est pas propre à sshd, d'autres serveurs,
comme Apache (httpd) et Exim, ont une fonctionnalité similaire
(mais ce n'est pas toujours le signal HUP, j'ai aussi vu USR1).
--
Vincent Lefèvre <vin...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
JPaul
> Au cas où l'utilisateur aurait installé un autre sshd qui n'est pas
> lancé "on demand" (c'est mon cas, pour avoir un OpenSSH plus récent),
> "man sshd" dit:
>
> sshd rereads its configuration file when it receives a hangup
> signal, SIGHUP, by executing itself with the name and options
> it was started with, e.g., /usr/sbin/sshd.
Et pour envoyer un tel signal au processus sshd, déterminer son n° (de
process=PID) et faire la commande kill -HUP n°deprocess
JPaul.
--
/==/==\\-\ Jean-Paul BLANC
/ /--/--//\\ quelque-part (somewhere)
|/| L |\\\ en (in)
\/|| = |||\\\ FRANCE
Laurent Pertois
> Et pour envoyer un tel signal au processus sshd, déterminer son n° (de
> process=PID) et faire la commande kill -HUP n°deprocess
sudo killall -HUP nom_de_process
doit faire l'affaire, il me semble.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
JPaul
> sudo killall -HUP nom_de_process
>
> doit faire l'affaire, il me semble.
Oui, également.
Mais je n'ai pas l'habitude de mentionner killall que je considčre plus
dangereux.
ctobini
Bonjour et merci de ta réponse,
Ca a l'air pratique dans l'absolu mais c'est un peu frustrant de ne pas
commander le service directement (genre /etc/init.d) ce que je reproche
un peu à Mac OS X.
C. Tobini
patpro ~ Patrick Proniewski a écrit :
Nicolas MICHEL
> Bonjour et merci de ta réponse,
>
> Ca a l'air pratique dans l'absolu mais c'est un peu frustrant de ne pas
> commander le service directement (genre /etc/init.d) ce que je reproche
> un peu à Mac OS X.
Il y a à peut près l'équivalent :
C'est soit des StartupItems soit des LaunchDeamon.
Ceci dit on est bien d'accord sur la clarté de /etc/init.d
J'aurais perso préféré que Apple utilise ce système en créant un système
de gestion de ces init.d, du genre "services et chkconfig" de redhat
mais en mieux.
--
Nicolas
Erwan David
> Ceci dit on est bien d'accord sur la clarté de /etc/init.d
> J'aurais perso préféré que Apple utilise ce système en créant un système
> de gestion de ces init.d, du genre "services et chkconfig" de redhat
> mais en mieux.
Idem, mais la séparation totale de la mécanique et de la carosserie
qu'implique ce système d'un GUI pilotant un stystème non graphique
ne semble pas être complètemenet entré dans la culture Apple.
--
Erwan
Laurent Pertois
> Ca a l'air pratique dans l'absolu mais c'est un peu frustrant de ne pas
> commander le service directement (genre /etc/init.d) ce que je reproche
> un peu à Mac OS X.
Cela dit, le ssh est lancé par launchd 'on demand', on doit pouvoir
l'avoir en permanence et après le relancer au besoin après changements.
Laurent Pertois
> Cela dit, le ssh est lancé par launchd 'on demand', on doit pouvoir
> l'avoir en permanence et après le relancer au besoin après changements.
Je corrige, il est lancé en mode compatibilité inetd et en wait.
D'ailleurs, en 10.3 sshd était géré par xinetd qui faisait de même, il
me semble.
Patrick Stadelmann
laurent...@alussinan.org (Laurent Pertois) wrote:
> Laurent Pertois <laurent...@alussinan.org> wrote:
>
> > Cela dit, le ssh est lancé par launchd 'on demand', on doit pouvoir
> > l'avoir en permanence et après le relancer au besoin après changements.
>
> Je corrige, il est lancé en mode compatibilité inetd et en wait.
>
> D'ailleurs, en 10.3 sshd était géré par xinetd qui faisait de même, il
> me semble.
Il est lancé à la demande en tout cas : deux process "sshd" apparaissent
à l'ouverture d'une connexion ssh et disparaissent lorsque que le client
se déconnecte.
Patrick
--
Patrick Stadelmann <Patrick.S...@unine.ch>
patpro ~ Patrick Proniewski
Erwan David <er...@rail.eu.org> wrote:
man launchd
patpro
Laurent Pertois
> Il est lancé à la demande en tout cas : deux process "sshd" apparaissent
> à l'ouverture d'une connexion ssh et disparaissent lorsque que le client
> se déconnecte.
Oui, comme xinetd le faisait, launchd écoute le port 22, quand il
détecte une connexion sur ce port il lance sshd (enfin, il lance
sshd-keygen-wrapper avec comme option sshd -i) et l'arrête quand la
connexion est terminée. En 10.3, xinetd écoutait le port 22 et lançait
sshd à chaque connexion également.
patpro ~ patrick proniewski
Matt <hfr...@syrius.org.invalid> wrote:
> On Wed, 13 Dec 2006 15:10:15 +0100,
> patpro ~ Patrick Proniewski <pat...@boleskine.patpro.net> wrote:
>
> > man launchd
>
> Mon Dieu, tu révolutionnes de vieilles habitudes.
> Mais arrête donc !
si faire `man` est une révolution, c'est probablement que je parle au
type qui a inventé la carte perforée :)
Pour launchd par contre, c'est effectivement l'effet que ça me fait. Je
ne peux pas tenir rigueur aux gens de s'accrocher à des vieux trucs
qu'ils sortent de linusque/BSD/Solaris/... et qui n'ont pour eux que le
fait d'être connus. J'ai moi même eu mes périodes de rage contre mac os
x, façon "où sont mes flatfiles @$#?". Mais ça m'a passé. J'ai accepté
que mac os x n'est pas FreeBSD, j'ai accepté qu'il y a d'autres manières
de faire, parfois plus évoluées et finalement plus puissantes quand on
se sort les doigts du cul.
Je peux concevoir que c'est pas encore le cas de tout le monde, je ne
jette pas la pierre. (mais j'étais à deux doigts d'm'agasser)
patpro
Laurent Pertois
> si faire `man` est une révolution, c'est probablement que je parle au
> type qui a inventé la carte perforée :)
> Pour launchd par contre, c'est effectivement l'effet que ça me fait. Je
> ne peux pas tenir rigueur aux gens de s'accrocher à des vieux trucs
> qu'ils sortent de linusque/BSD/Solaris/... et qui n'ont pour eux que le
> fait d'être connus. J'ai moi même eu mes périodes de rage contre mac os
> x, façon "où sont mes flatfiles @$#?". Mais ça m'a passé. J'ai accepté
> que mac os x n'est pas FreeBSD, j'ai accepté qu'il y a d'autres manières
> de faire, parfois plus évoluées et finalement plus puissantes quand on
> se sort les doigts du cul.
> Je peux concevoir que c'est pas encore le cas de tout le monde, je ne
> jette pas la pierre. (mais j'étais à deux doigts d'm'agasser)
:-)
clap clap...
Mais chut, ça reste entre nous ;-)
Vincent Lefevre
Erwan David <er...@rail.eu.org> écrit:
> bl...@empty.org (JPaul) écrivait :
> > Laurent Pertois <laurent...@alussinan.org> wrote:
> >
> >> sudo killall -HUP nom_de_process
> >>
> >> doit faire l'affaire, il me semble.
Pas essayé, mais à chaque connexion ssh, le sshd crée deux fils (dans
mon cas, avec OpenSSH_4.5p1). Le signal HUP risque aussi de perturber
les fils. Je ne sais pas comment ceux-ci sont censés se comporter.
> > Oui, également.
> > Mais je n'ai pas l'habitude de mentionner killall que je considère plus
> > dangereux.
Ce qui risque d'être le cas ici (cf ci-dessus).
> Sur mon tiger sshd est lancé par launchproxy, donc il est relancé à
> chaque connexion. Dans ce cas pas besoin de "rebooter" le serveur,
> pusiqu'il ne tourne pas en permanence...
Tu n'as pas suivi la discussion complètement...
Vincent Lefevre
Nicolas MICHEL <Nicolas...@bonbon.net> écrit:
> Il y a à peut près l'équivalent :
> C'est soit des StartupItems soit des LaunchDeamon.
> Ceci dit on est bien d'accord sur la clarté de /etc/init.d
> J'aurais perso préféré que Apple utilise ce système en créant un système
> de gestion de ces init.d, du genre "services et chkconfig" de redhat
> mais en mieux.
Mais le /etc/init.d ne permet pas qu'un démon soit automatiquement
relancé s'il est tué. Je trouve cette fonctionnalité des LaunchDaemons
bien pratique. Et les LaunchDaemons ont permis de tout uniformiser: on
n'a pas des bouts éparpillés dans le /etc/init.d, dans les /etc/cron*,
etc.
Laurent Pertois
> On Wed, 13 Dec 2006 23:29:14 +0100,
> Laurent Pertois <laurent...@alussinan.org> wrote:
>
> > Mais chut, ça reste entre nous ;-)
>
> Trop tard Laurent, tu t'es trompé de bouton, le monde te lit !
> Honte sur toi !!!
Damned, je suis pris !
Laurent Pertois
> Ne t'inquiète pas, à 23h29 on a le droit de se tromper (philosophie
> hybride Klingon/Shaddock).
Ouf, merci à eux :)
Nicolas MICHEL
> Mais le /etc/init.d ne permet pas qu'un démon soit automatiquement
> relancé s'il est tué. Je trouve cette fonctionnalité des LaunchDaemons
> bien pratique. Et les LaunchDaemons ont permis de tout uniformiser: on
> n'a pas des bouts éparpillés dans le /etc/init.d, dans les /etc/cron*,
> etc.
Je te réponds à toi mais en fait je m'adresse aussi à patpro, Matt et
Laurent ...
Voyons comparativement les avantages et les inconveignants de darwin
contre fedora côté gestion des services :
Essayer une fausse commande du genre :
# chkconfig --help
et :
# launchctl --help
launchctl est naze de ce côté.
Puis comparons les synopsis de ces 2 commandes ...
SYNOPSIS
chkconfig --list [name]
chkconfig --add name
chkconfig --del name
chkconfig [--level levels] name <on|off|reset>
chkconfig [--level levels] name
SYNOPSIS
launchctl [subcommand [arguments ...]]
Ici aussi, launchctl est moins clair.
Enfin le plus important :
# service smb
Usage: /etc/init.d/smb {start|stop|restart|reload|status|condrestart}
avec launchctl, pas de reload à l'horizon, ni de status. Quand au
restart, il faut savoir que c'est en fait "stop" et que "stop" ne stoppe
pas le service puisqu'il sera relancé automatiquement :-(
3 points pour fedora donc.
Bref, d'une façon générale je ne critique pas le fait que ce soit
nouveau ou différent, je trouve juste plus compliqué et mal fait.
Ajouter à ça qu'ils n'ont pas "tout uniformisé" du tout, bien au
contraire :
- cron est toujours là
- et il y a les startup items, toujours présent.
Faut-il croire que même pour Apple, c'est trop compliqué de pondre 5 ou
6 launchd ?
( et bien sûr pas de "reload" ou de "status" dans les SystemStarter)
- Enfin il y a les launchd, dont vous savez tout le bien que je penses.
Bien entendu, ça change d'une version à l'autre. xinetd en 10.3, launchd
en 10.4 pour sshd. Comme on ne peut pas avoir un par homogène sur mac,
c'est pratique.
Et ici je ne parlerai pas des préférences
(flatfiles + netinfo + .plist non commentés)
Ni de la façon dont on accède à ces prefs (defaults, j'adore)
Bref, ça sera peut-être bien dans 10 ans mais pour l'instant c'est le
bordel. Je passes 10x plus de temps au bas mot sur mac que sur fedora,
mais je m'y retrouve moins bien.
amha, Mac OS X client n'est pas conçu pour être administré en cli.
--
Nicolas
patpro ~ Patrick Proniewski
Nicolas...@BonBon.net (Nicolas MICHEL) wrote:
> Je te réponds à toi mais en fait je m'adresse aussi à patpro, Matt et
> Laurent ...
>
> Voyons comparativement les avantages et les inconveignants de darwin
> contre fedora côté gestion des services :
>
> Essayer une fausse commande du genre :
> # chkconfig --help
> et :
> # launchctl --help
>
> launchctl est naze de ce côté.
Zéro partout, les sources d'info varient énormément selon les vendeurs,
entre man, help, info, la doc html, ... chaque vendeur a sa préférence.
Le svn a une page man de 20 lignes qui renvoie vers help et vers le
svnbook. cvs a une longue page man et un help ridicule, ...
> Enfin le plus important :
> # service smb
> Usage: /etc/init.d/smb {start|stop|restart|reload|status|condrestart}
>
> avec launchctl, pas de reload à l'horizon, ni de status. Quand au
> restart, il faut savoir que c'est en fait "stop" et que "stop" ne stoppe
> pas le service puisqu'il sera relancé automatiquement :-(
Stop, ça stoppe le service. Si ton service est configuré pour se
relancer et bien il se relance, mais ce n'est pas systématique, c'est à
la discrétion de l'administrateur. Ça assume très bien le rôle du
watchdog de la 10.3.
Si tu veux vraiment stopper un service définitivement alors qu'il est
configuré pour se relancer, tu as un flag qui va bien à ajouter à ta
commande.
> Bref, d'une façon générale je ne critique pas le fait que ce soit
> nouveau ou différent, je trouve juste plus compliqué et mal fait.
Et ta fedora, elle a un cron dans un coin, un xinetd dans un autre, peut
être même un watchdog applicatif si elle a de la chance (j'en doute), et
elle est incapable de surveiller le contenu d'un dossier ou d'un fichier
pour lancer des actions en fonction, de manière transparente pour
l'utilisateur.
> Ajouter à ça qu'ils n'ont pas "tout uniformisé" du tout, bien au
> contraire :
> - cron est toujours là
il est la pour la compatibilité, tu peux tout faire sans cron.
> - et il y a les startup items, toujours présent.
idem.
> Faut-il croire que même pour Apple, c'est trop compliqué de pondre 5 ou
> 6 launchd ?
> ( et bien sûr pas de "reload" ou de "status" dans les SystemStarter)
Ça dépend les quels, ce sont des scripts shell, tu fais ce que tu veux
avec.
> - Enfin il y a les launchd, dont vous savez tout le bien que je penses.
>
> Bien entendu, ça change d'une version à l'autre. xinetd en 10.3, launchd
> en 10.4 pour sshd. Comme on ne peut pas avoir un par homogène sur mac,
> c'est pratique.
sincèrement, ça change quoi pour l'admin que sshd soit lancé par xinetd
ou launchd ?
> Et ici je ne parlerai pas des préférences
> (flatfiles + netinfo + .plist non commentés)
> Ni de la façon dont on accède à ces prefs (defaults, j'adore)
Apple a des API pour ce genre de choses, si tu les utilises c'est
transparent pour toi. Mais c'est sûr qu'il faut coder un peu, et c'est
pas nécessairement à la portée de l'admin (pas de la mienne en tout cas).
> Bref, ça sera peut-être bien dans 10 ans mais pour l'instant c'est le
> bordel. Je passes 10x plus de temps au bas mot sur mac que sur fedora,
> mais je m'y retrouve moins bien.
> amha, Mac OS X client n'est pas conçu pour être administré en cli.
Ne t'inquiète pas, dans 10 ans ce sera pas plus administrable par CLI.
Ce n'est simplement pas l'objectif.
patpro
Nicolas MICHEL
> Si tu veux vraiment stopper un service définitivement alors qu'il est
> configuré pour se relancer, tu as un flag qui va bien à ajouter à ta
> commande.
Aurais-tu un exemple de commande stp ?
Et comment sait-on si le job est relancé ou pas ?
En lisant le .plist ?
> Et ta fedora, elle a un cron dans un coin, un xinetd dans un autre, peut
> être même un watchdog applicatif si elle a de la chance (j'en doute), et
> elle est incapable de surveiller le contenu d'un dossier ou d'un fichier
> pour lancer des actions en fonction, de manière transparente pour
> l'utilisateur.
Oui, c'est vrais que launchd, en théorie, est puissant et bien pensé.
Simplement je ne le trouves pas aboutit ... Il manque plein de petits
détails qui pour moi autaient dû être implémentés dés le début :
Si c'est pour faire moin bien, autant ne pas changer.
> > Ajouter à ça qu'ils n'ont pas "tout uniformisé" du tout, bien au
> > contraire :
> > - cron est toujours là
>
> il est la pour la compatibilité, tu peux tout faire sans cron.
C'est vrais. A la rigueure je peux comprendre.
Dureste s'ils ne l'avaient pas laissé qu'est-ce que j'aurais geulé :)
> > - et il y a les startup items, toujours présent.
>
> idem.
Non, pas idem :
ls /System/Library/StartupItems
Apache FibreChannel NetworkTime
AppServices IFCStart PrintingServices
AppleShare IPServices RemoteDesktopAgent
AuthServer Metadata SNMP
CrashReporter NFS
Disks NIS
Les StartupItems sont encore bien présents en 10.4.8
C'est pas là juste pour la compatibilité, c'est là pour faire tourner le
système.
> > Faut-il croire que même pour Apple, c'est trop compliqué de pondre 5 ou
> > 6 launchd ?
> > ( et bien sûr pas de "reload" ou de "status" dans les SystemStarter)
>
> Ça dépend les quels, ce sont des scripts shell, tu fais ce que tu veux
> avec.
On peut l'ajouter dans un script mais c'est pas prévu de base, le manuel
d'en parles du reste pas. Or si je me logue sur un serveur, la première
chose est bien d'aller voir le status des services... Pour un admin
c'est une fonction aussi nécessaire que start ou stop. Mais chez Apple,
ils n'ont pas l'air d'avoir de pratique.
> sincèrement, ça change quoi pour l'admin que sshd soit lancé par xinetd
> ou launchd ?
Si tu dois scripter des éléments d'administration, et parce que on a
forcément pas un parc homogène, impossible sur mac, ça veux dire que tu
dois analyser pour chaque version comment chaque élément est lancé puis
tester selon la config quelle commande lancer, quoi modifier ...
D'une distrib linux à une autre je comprends que ça puisse changer, et
encore je crois que ça change plus de la 10.3 à la 10.4 que de fedora à
debian à ce niveau.
> Apple a des API pour ce genre de choses, si tu les utilises c'est
> transparent pour toi. Mais c'est sûr qu'il faut coder un peu, et c'est
> pas nécessairement à la portée de l'admin (pas de la mienne en tout cas).
L'administration d'un mac devrait pouvoir se faire sans avoir à touiller
dans les API, non ?
> Ne t'inquiète pas, dans 10 ans ce sera pas plus administrable par CLI.
> Ce n'est simplement pas l'objectif.
On verra, mais ce serait dommage, on a pas encore trouvé mieux à ma
connaissance pour bien des choses.
--
Nicolas
Nicolas MICHEL
> T'es flemmard à ce point là ? Se cantonner au synopsis c'est léger.
Non, c'est une question d'efficacité.
Le man n'est pas là que pour étudier en profondeur une commande.
Le synopsis est aussi là pour rappeler la syntaxe et il devrait être
suffisant pour un léger rafraichissement de mémoire.
> Personnellement, je pense que la sémantique de launchd(8) t'échappe encore
> (je fus dans le même cas lorsque je suis passé à Mac OS X 10.4)
Possible. Je vais prier pour recevoir l'illumination, on verra si ça
marche :-P
> Parce que changer les habitudes est généralement délicat.
> Entre nous, je préfère encore utiliser ma crontab que de faire un job pour
> launchd même si ce n'est pas sorcier.
Moi aussi, pour un résultat identique je préfère écrire une ligne de
texte plutôt que tout un fichier + launchctl load ...
cron a encore de beaux jours devant lui :)
> > - et il y a les startup items, toujours présent.
>
> Même chose que pour crond.
La crontab de base est vide, pas les startupItems.
Un peu comme netinfo local qui est resté malgré l'arrivée de
OpenDirectory et de son ldap ...
> Bien que Mac OS X soit si sexy, il n'en est pas moins tout jeune.
En 10.0 et même en 10.1, je comprenais très bien ça.
A présent il est en phase de rénovation avant même d'avoir été finit et
ces rénovations sont bâclées. C'est différent :->
> Le sachant, prend les décisions qui te permettent de t'épanouir
> pleinement.
Mac OS X client reste selon moi le seul unix utilisable par un
utilisateur lambda. Par contre j'ai toujours pas de Mac OS X serveur
alors que j'ai 5 ou 6 serveurs linux ... Mais ça ne m'épanouis pas pour
autant :)
--
Nicolas
patpro ~ Patrick Proniewski
Nicolas...@BonBon.net (Nicolas MICHEL) wrote:
> > Si tu veux vraiment stopper un service définitivement alors qu'il est
> > configuré pour se relancer, tu as un flag qui va bien à ajouter à ta
> > commande.
>
> Aurais-tu un exemple de commande stp ?
J'ai gouré, pour virer un job sans qu'il se relance, c'est juste unload.
Si tu veux qu'il ne se relance pas au boot suivant, c'est :
launchctl unload -w /chemin/du/plist
> Et comment sait-on si le job est relancé ou pas ?
au sens de `ps` ou au sens de `launchctl list` ?
> En lisant le .plist ?
par exemple, si c'est pour savoir si il peux se relancer tout seul.
> > Ça dépend les quels, ce sont des scripts shell, tu fais ce que tu veux
> > avec.
>
> On peut l'ajouter dans un script mais c'est pas prévu de base, le manuel
> d'en parles du reste pas. Or si je me logue sur un serveur, la première
> chose est bien d'aller voir le status des services... Pour un admin
> c'est une fonction aussi nécessaire que start ou stop. Mais chez Apple,
> ils n'ont pas l'air d'avoir de pratique.
un truc genre :
# serveradmin status web
web:state = "RUNNING"
# serveradmin list
afp
appserver
dhcp
dirserv
...
# serveradmin
Usage: serveradmin [-dhvx] [list | start | stop | status | fullstatus |
settings | command] [<service_key> [ = <value> ]]
-h, --help display this message
-v, --version display version info
-d, --debug print command
-x, --xml print output as XML plist
Examples:
serveradmin list
--Lists all services
serveradmin start afp
--Starts afp server
serveradmin stop ftp
--Stops ftp server
serveradmin status web
--Returns current status of the web server
serveradmin fullstatus web
--Returns more complete status of the web server
serveradmin settings afp
--Returns all afp configuration parameters
serveradmin settings afp:guestAccess
--Returns afp guestAccess attribute
serveradmin settings afp:guestAccess = yes
--Sets afp guestAccess to true
serveradmin settings
--Takes settings commands like above from stdin
serveradmin command afp:command = getConnectedUsers
--Used to perform service specific commands
serveradmin command
--Takes stdin to define generic command that requires other
parameters
Achète donc une licence Mac OS X Server, au lieu de râler que le client
est pas mûr pour être administré comme un serveur :)
> > sincèrement, ça change quoi pour l'admin que sshd soit lancé par xinetd
> > ou launchd ?
>
> Si tu dois scripter des éléments d'administration, et parce que on a
> forcément pas un parc homogène, impossible sur mac, ça veux dire que tu
> dois analyser pour chaque version comment chaque élément est lancé puis
> tester selon la config quelle commande lancer, quoi modifier ...
j'ai l'impression que c'est très artisanal et empirique ta méthode
d'administration là.
> > Apple a des API pour ce genre de choses, si tu les utilises c'est
> > transparent pour toi. Mais c'est sûr qu'il faut coder un peu, et c'est
> > pas nécessairement à la portée de l'admin (pas de la mienne en tout cas).
>
> L'administration d'un mac devrait pouvoir se faire sans avoir à touiller
> dans les API, non ?
oui, mais ces API permettent de créer des outils de manipulation des
préférences système, et de tout un tas de choses, si vraiment tu as un
besoin exotique qui n'est pas couvert par les outils apple.
patpro
Nicolas MICHEL
> launchctl unload -w /chemin/du/plist
Ok, ça c'est clair en lisant le man.
> > Et comment sait-on si le job est relancé ou pas ?
> un truc genre :
> serveradmin status web
> --Returns current status of the web server
Oui, c'est un truc comme ça que je voudrais sur les Mac OS X client.
C'est très bien ce truc.
> Achète donc une licence Mac OS X Server, au lieu de râler que le client
> est pas mûr pour être administré comme un serveur :)
Mais non, je ne veux pas de Mac OS X serveur sur des workstations.
Je veux un système "client" fait pour des entreprises, pas pour madame
Michoud et sa connexion adsl.
> > Si tu dois scripter des éléments d'administration, et parce que on a
> > forcément pas un parc homogène, impossible sur mac, ça veux dire que tu
> > dois analyser pour chaque version comment chaque élément est lancé puis
> > tester selon la config quelle commande lancer, quoi modifier ...
>
> j'ai l'impression que c'est très artisanal et empirique ta méthode
> d'administration là.
J'administre mon parc notament avec un loginhook qui me sert, entre
autres choses, à corriger les bugs du système.
Certes c'est artisanal mais ça marche.
Reste que même en interactif, ça change à tout bout de champ pour ne pas
faire mieux, euh, ça agace.
> oui, mais ces API permettent de créer des outils de manipulation des
> préférences système, et de tout un tas de choses, si vraiment tu as un
> besoin exotique qui n'est pas couvert par les outils apple.
Tu veux dire que ces API permettent de créer des outils dépourvus des
bugs contennus dans ceux que Apple nous livre ? Super :->
J'ai notament remonté un bug pour l'abominable defauts, Apple m'a
répondu "oui, on sait, on y travaille". Ce serait tellement plus simple
de réfléchir un peu avant de coder.
Bon, note, il y a pire :)
--
Nicolas
Laurent Pertois
> A présent il est en phase de rénovation avant même d'avoir été finit et
> ces rénovations sont bâclées. C'est différent :->
Launchd est en version 1. Comme le disait le regretté Michael Bartosh,
Apple a mis un orteil dans l'eau avec cette version pour voir, la suite
viendra naturellement dans les prochaines versions et les éléments comme
les Startup Items sont appelés à disparaître dans les prochaines
versions.
Rome ne s'est pas faite en 1 jour, avant xinetd on avait inetd, regarde
la syntaxe du fichier et réjouis-toi...
Laurent Pertois
> Je veux un système "client" fait pour des entreprises, pas pour madame
> Michoud et sa connexion adsl.
Sauf qu'en entreprise je ne vois aucune raison d'activer des services
sur un poste utilisateur, au contraire même, si ce n'est des services de
prise en main à distance (ssh, Remote Desktop ou autres de
tierce-partie). Donc avoir un serveradmin sur le client, je n'en vois
pas l'intérêt.
Nicolas MICHEL
> Sauf qu'en entreprise je ne vois aucune raison d'activer des services
> sur un poste utilisateur, au contraire même, si ce n'est des services de
> prise en main à distance (ssh, Remote Desktop ou autres de
> tierce-partie). Donc avoir un serveradmin sur le client, je n'en vois
> pas l'intérêt.
C'est que tu as une vue trop rigide d'une entreprise ...
Ici on a plein de petites cellules de travail qui gèrent eux-même leur
données et qui n'ont pas un volume suffisant pour justifier un serveur,
un vrais. Du coup on se retrouve souvent avec des partages locaux sur
des sortes de mini-serveurs-workstations. C'est tordu d'un point de vue
technique, mais c'est comme ça. Et si le meilleur OS du monde ne peux
pas le faire alors on vas finir avec un OS M$ qui lui le permet.
--
Nicolas
patpro ~ Patrick Proniewski
Nicolas...@BonBon.net (Nicolas MICHEL) wrote:
Et un (gros ?) serveur pour héberger tous les fichiers de chaque petite
cellule ?
Ça permet de garder le contrôle sur la politique de sécurité, tant en
terme de sécurité des données (backup, ...) que de sécurité des accès.
Ça évite par exemple que quelqu'un monte dans ton dos un relais smtp,
une passerelle vers l'extérieur qui permettrait des accès non contrôlés
au réseau de l'entreprise, ... Bref tous ces trucs qu'on voit fleurir
dès que les utilisateurs commencent à gérer leur propre petit serveur
dans leur coin.
patpro
Nicolas MICHEL
> Et un (gros ?) serveur pour héberger tous les fichiers de chaque petite
> cellule ?
Pour centraliser, il faut une volonté commune.
C'est pas toujours le cas.
On a bien sûr un serveur de fichier central, mais il ne fait que 2To, ce
qui ne permet pas de gérer tous les cas de figures.
> Bref tous ces trucs qu'on voit fleurir
> dès que les utilisateurs commencent à gérer leur propre petit serveur
> dans leur coin.
Bon, tout de même, il y a des limites.
Je ne vais pas filer le mot de passe admin sur de telles machines.
Parce qu'après, je retrouve non pas ce dont tu parles, mais du yahoo
messenger, p2p et autre crétinneries.
Ah si, on a quelqu'un qui a effectivement activé le serveur mail local.
(Parce qu'installer un client pop c'est trop compliqué :)
Mais c'est différent, c'est un adepte de Solaris ...
--
Nicolas
Vincent Lefevre
Nicolas MICHEL <Nicolas...@bonbon.net> écrit:
> Ah si, on a quelqu'un qui a effectivement activé le serveur mail local.
> (Parce qu'installer un client pop c'est trop compliqué :)
Ben justement, certains clients POP (comme fetchmail) se servent d'un
serveur local pour délivrer le courrier rapatrié. Bref, un serveur de
mail local sert à plein de choses, notamment pour gérer l'envoi de
mail en local (pas forcément obligatoire de passer par le port 25,
mais ça peut être plus pratique).
Laurent Pertois
> C'est que tu as une vue trop rigide d'une entreprise ...
Différente, on va dire.
> Ici on a plein de petites cellules de travail qui gèrent eux-même leur
> données et qui n'ont pas un volume suffisant pour justifier un serveur,
> un vrais. Du coup on se retrouve souvent avec des partages locaux sur
> des sortes de mini-serveurs-workstations. C'est tordu d'un point de vue
> technique, mais c'est comme ça. Et si le meilleur OS du monde ne peux
> pas le faire alors on vas finir avec un OS M$ qui lui le permet.
Euh, franchement ? c'est de la bricole, pour moi, plein de machines à
gérer quand je peux créer des partages que chaque cellule verra sans
voir celles des autres sur un ou deux serveurs uniques, faciles à gérer
et maîtrisés.
De plus, tu me parles de serveur pour une petite cellule, je te réponds
Mac OS X Server 10 licences.
patpro ~ patrick proniewski
Vincent Lefevre <vincen...@vinc17.org> wrote:
> Dans l'article <1hqdt6g.1g6it0u1gdvf14N%Nicolas...@BonBon.net>,
> Nicolas MICHEL <Nicolas...@bonbon.net> écrit:
>
> > Ah si, on a quelqu'un qui a effectivement activé le serveur mail local.
> > (Parce qu'installer un client pop c'est trop compliqué :)
>
> Ben justement, certains clients POP (comme fetchmail) se servent d'un
> serveur local pour délivrer le courrier rapatrié.
le serveur est pas forcément local.
patpro
Vincent Lefevre
patpro ~ patrick proniewski <pat...@boleskine.patpro.net> écrit:
C'est vrai, mais si on veut récupérer le mail sur sa machine perso
avec fetchmail, par défaut, on doit avoir un serveur local.
patpro ~ patrick proniewski
Vincent Lefevre <vincen...@vinc17.org> wrote:
> > le serveur est pas forcément local.
>
> C'est vrai, mais si on veut récupérer le mail sur sa machine perso
> avec fetchmail, par défaut, on doit avoir un serveur local.
yep.
patpro
FiLH
> Dans l'article <1hqafts.1psgsf2sqr9c0N%Nicolas...@BonBon.net>,
> Nicolas MICHEL <Nicolas...@bonbon.net> écrit:
>
> > Il y a à peut près l'équivalent :
> > C'est soit des StartupItems soit des LaunchDeamon.
>
> > Ceci dit on est bien d'accord sur la clarté de /etc/init.d
> > J'aurais perso préféré que Apple utilise ce système en créant un système
> > de gestion de ces init.d, du genre "services et chkconfig" de redhat
> > mais en mieux.
>
> Mais le /etc/init.d ne permet pas qu'un démon soit automatiquement
> relancé s'il est tué. Je trouve cette fonctionnalité des LaunchDaemons
> bien pratique. Et les LaunchDaemons ont permis de tout uniformiser: on
> n'a pas des bouts éparpillés dans le /etc/init.d, dans les /etc/cron*,
> etc.
Sauf que c'est incompatible avec amd par exemple !
J'ai été obligé de passer par les StartupItems
Là sur le coup Solaris10 enfonce carrément Apple (et bien profond gnarg
gnarg)
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
FiLH
> patpro ~ Patrick Proniewski <pat...@boleskine.patpro.net> wrote:
>
> > Et un (gros ?) serveur pour héberger tous les fichiers de chaque petite
> > cellule ?
>
> Pour centraliser, il faut une volonté commune.
> C'est pas toujours le cas.
>
En voilà qui n'ont jamais perdu de données :)
Attend qu'ils paument deux mois de boulot et ils vont réclamer leur
sauvegarde centralisée sur robotique !
FiLH (Qui a perdu des données enfin pas les siennes, et qui a un super
robot)
Vincent Lefevre
FiLH <fi...@filh.orgie> écrit:
> Sauf que c'est incompatible avec amd par exemple !
amd?
FiLH
> Dans l'article <1hqhq7i.owlgt21t3gdcqN%fi...@filh.orgie>,
> FiLH <fi...@filh.orgie> écrit:
>
> > Sauf que c'est incompatible avec amd par exemple !
>
> amd?
Le daemon am-utils un automonteur qui a la facheuse manie (Pour Mac Os
X) de passer en mode daemon, et Launchd ne le voit plus (d'ailleur c'est
dans la doc de Launchd faut pas passer en mode daemon)
Nicolas MICHEL
> Le daemon am-utils un automonteur qui a la facheuse manie (Pour Mac Os
> X) de passer en mode daemon, et Launchd ne le voit plus (d'ailleur c'est
> dans la doc de Launchd faut pas passer en mode daemon)
Whoao, une autre supperbe tarre de Launchd que je ne connaissait pas !
--
Nicolas
Laurent Pertois
> Whoao, une autre supperbe tarre de Launchd que je ne connaissait pas !
Faut vraiment que tu lises le man et quelques docs un jour Nicolas ;-)
Nicolas MICHEL
> Nicolas MICHEL <Nicolas...@BonBon.net> wrote:
>
> > Whoao, une autre supperbe tarre de Launchd que je ne connaissait pas !
>
> Faut vraiment que tu lises le man et quelques docs un jour Nicolas ;-)
La clause du besoins seule m'y obligera :)
--
Nicolas, qui ne sait pas lire.
Laurent Pertois
> > Faut vraiment que tu lises le man et quelques docs un jour Nicolas ;-)
>
> La clause du besoins seule m'y obligera :)
Arf... Il est toujours bon de commencer, àmha, quand c'est le début, ça
fait moins à rattraper par la suite...
FiLH
> Nicolas MICHEL <Nicolas...@BonBon.net> wrote:
>
> > Whoao, une autre supperbe tarre de Launchd que je ne connaissait pas !
>
> Faut vraiment que tu lises le man et quelques docs un jour Nicolas ;-)
En fait c'est plus drôle quand c'est pas documenté... d'où l'intérêt de
lire la doc pour pouvoir plus rire...
FiLH
P.S. M'en fous j'ai réussi ma config de services...
Vincent Lefevre
FiLH <fi...@filh.orgie> écrit:
> Le daemon am-utils un automonteur qui a la facheuse manie (Pour Mac Os
> X) de passer en mode daemon, et Launchd ne le voit plus (d'ailleur c'est
> dans la doc de Launchd faut pas passer en mode daemon)
C'est probablement que am-utils est mal écrit: ça risque aussi
de poser des problèmes avec des systèmes similaire, e.g.
"/etc/init.d/... stop".
François Jacquemin
> ...quand on
> se sort les doigts du cul.
> ... (mais j'étais à deux doigts d'm'agasser)
Les mêmes ?
--
F. J.
FiLH
> Dans l'article <1hqifp0.r4pdks1oyiw86N%fi...@filh.orgie>,
> FiLH <fi...@filh.orgie> écrit:
>
> > Le daemon am-utils un automonteur qui a la facheuse manie (Pour Mac Os
> > X) de passer en mode daemon, et Launchd ne le voit plus (d'ailleur c'est
> > dans la doc de Launchd faut pas passer en mode daemon)
>
> C'est probablement que am-utils est mal écrit:
Ouaiiiii.... :) Non. Il est juste en mode daemon, un truc normal et de
base : on coupe les ponts avec le tty et basta.
> ça risque aussi
> de poser des problèmes avec des systèmes similaire, e.g.
> "/etc/init.d/... stop".
Ça n'en pose pas, ça fonctionne très bien avec les svc solaris par
exemple :)
Vincent Lefevre
FiLH <fi...@filh.orgie> écrit:
> Vincent Lefevre <vincen...@vinc17.org> wrote:
> > Dans l'article <1hqifp0.r4pdks1oyiw86N%fi...@filh.orgie>,
> > FiLH <fi...@filh.orgie> écrit:
> >
> > > Le daemon am-utils un automonteur qui a la facheuse manie (Pour Mac Os
> > > X) de passer en mode daemon, et Launchd ne le voit plus (d'ailleur c'est
> > > dans la doc de Launchd faut pas passer en mode daemon)
> >
> > C'est probablement que am-utils est mal écrit:
> Ouaiiiii.... :) Non. Il est juste en mode daemon, un truc normal et de
> base : on coupe les ponts avec le tty et basta.
Launchd n'a pas de problème avec d'autres programmes qui passent
en mode daemon.
> > ça risque aussi
> > de poser des problèmes avec des systèmes similaire, e.g.
> > "/etc/init.d/... stop".
> Ça n'en pose pas, ça fonctionne très bien avec les svc solaris par
> exemple :)
Si ça se trouve, il utilise une fonctionnalité non standard de Solaris.
Mais d'après
http://lists.apple.com/archives/Macosx-interop/2006/Nov/msg00013.html
il ne semble même pas y avoir de problème avec launchd (à part
l'ordre dans lequel les démons sont lancés, pour ça, je ne sais
pas ce que launchd prévoit).
FiLH
> Dans l'article <1hqorhe.1qe50tk111uk5uN%fi...@filh.orgie>,
> FiLH <fi...@filh.orgie> écrit:
>
> > Vincent Lefevre <vincen...@vinc17.org> wrote:
>
> > > Dans l'article <1hqifp0.r4pdks1oyiw86N%fi...@filh.orgie>,
> > > FiLH <fi...@filh.orgie> écrit:
> > >
> > > > Le daemon am-utils un automonteur qui a la facheuse manie (Pour Mac Os
> > > > X) de passer en mode daemon, et Launchd ne le voit plus (d'ailleur c'est
> > > > dans la doc de Launchd faut pas passer en mode daemon)
> > >
> > > C'est probablement que am-utils est mal écrit:
>
> > Ouaiiiii.... :) Non. Il est juste en mode daemon, un truc normal et de
> > base : on coupe les ponts avec le tty et basta.
>
> Launchd n'a pas de problème avec d'autres programmes qui passent
> en mode daemon.
http://developer.apple.com/macosx/launchd.html
Creating and running a launchd job
Whether you're migrating a job to launchd from some other system job
launcher, or you're setting up a job for a new service, there are a few
basic requirements for the job.
Jobs run from launchd should not duplicate launchd functionality; for
instance, they should not use chroot(2). Furthermore, they should not do
the things normally required of daemon processes, such as detaching from
the terminal they are initially attached to. The only things that are
strictly prohibited, however, are fork()/exit() combinations (including
indirect methods, such as the daemon(3) library call). A server which
attempts to run itself as a daemon in this way will seem to have
finished running, potentially leading to launchd respawning it, or
disabling the service.
Et je confirme avec amd ça merde..
>
> > > ça risque aussi
> > > de poser des problèmes avec des systèmes similaire, e.g.
> > > "/etc/init.d/... stop".
>
> > Ça n'en pose pas, ça fonctionne très bien avec les svc solaris par
> > exemple :)
>
> Si ça se trouve, il utilise une fonctionnalité non standard de Solaris.
Non. Juste que svc.startd garde une meilleure traces des processus
générés y compris si ils passent en mode daemon. (svcs -p <service>
donne la liste de TOUS les processus
> Mais d'après
>
> http://lists.apple.com/archives/Macosx-interop/2006/Nov/msg00013.html
>
> il ne semble même pas y avoir de problème avec launchd (à part
> l'ordre dans lequel les démons sont lancés, pour ça, je ne sais
> pas ce que launchd prévoit).
Je ne vois pas de référence à amd...
Vincent Lefevre
FiLH <fi...@filh.orgie> écrit:
> http://developer.apple.com/macosx/launchd.html
> Creating and running a launchd job
> Whether you're migrating a job to launchd from some other system job
> launcher, or you're setting up a job for a new service, there are a few
> basic requirements for the job.
> Jobs run from launchd should not duplicate launchd functionality; for
> instance, they should not use chroot(2). Furthermore, they should not do
> the things normally required of daemon processes, such as detaching from
> the terminal they are initially attached to.
Tout cela ne devrait pas poser de problème: il y a juste redondance.
Bon, évidemment, si par exemple, un démon essaie de se détacher d'un
terminal éventuel et quitte parce qu'il n'y arrive pas (e.g., parce
qu'il est déjà détaché), c'est qu'il est déjà bien buggé.
> The only things that are strictly prohibited, however, are
> fork()/exit() combinations (including indirect methods, such as the
> daemon(3) library call).
C'est une évidence: si un démon fait un fork et que le père quitte,
il n'y a absolument plus moyen d'en garder une trace (sauf protocole
particulier), vu que seul le pid du fils permet de manière standard
d'avoir une information sur le fils. Certains logiciels utilisent la
sortie de ps, mais c'est une méthode intrinsèquement buggée qu'on peut
faire échouer (et par là même un trou de sécurité potentiel).
> A server which attempts to run itself as a daemon in this way will
> seem to have finished running, potentially leading to launchd
> respawning it, or disabling the service.
Oui, c'est le fonctionnement bien documenté.
> Et je confirme avec amd ça merde..
Parce que amd est écrit n'importe comment ou est prévu de fonctionner
avec un protocole particulier. De la même manière, un démon écrit
spécifiquement pour Darwin risque d'échouer sous Linux ou Solaris.
> > > > ça risque aussi
> > > > de poser des problèmes avec des systèmes similaire, e.g.
> > > > "/etc/init.d/... stop".
> >
> > > Ça n'en pose pas, ça fonctionne très bien avec les svc solaris par
> > > exemple :)
> >
> > Si ça se trouve, il utilise une fonctionnalité non standard de Solaris.
> Non. Juste que svc.startd garde une meilleure traces des processus
> générés y compris si ils passent en mode daemon. (svcs -p <service>
> donne la liste de TOUS les processus
svc.startd est un truc non standard. Tu dis simplement que amd
fonctionne avec svcs, qui semble être spécifique à Solaris. Il
est probable qu'amd utilise une fonctionnalité de Solaris ou
que Solaris ait une fonctionnalité pour suivre les processus
après un fork. Mais dans le second cas, Solaris pourrait se
retrouver avec de "faux" démons si ceux-ci sont écrits pour
un autre OS.
Rappelons qu'il y a deux grandes classes d'Unix: BSD (dont fait
partie Darwin / Mac OS X) et System V (dont font partie Solaris
et Linux). Même s'il y a des similarités et des tentatives
d'unification et de standardisation (POSIX / Single Unix), il y
a beaucoup d'incompatibilités (notamment tout ce qui concerne le
boot), et même à l'intérieur d'une classe, il y a des différences
(par exemple, Mac OS X a introduit launchd, qui introduit des
fonctionnalités intéressantes). La seule méthode universelle ici,
ce sont les signaux (SIGCHLD en particulier), et justement, launchd
se base dessus et amd semble casser cette méthode (s'il fait un
fork/exit... sinon je ne vois pas).
Note: certains démons ont une ou plusieurs options pour faire telle
ou telle chose suivant le système ou la méthode de lancement; il
faut penser à les utiliser. Malheureusement, ce n'est apparemment
pas le cas d'amd.
> > Mais d'après
> >
> > http://lists.apple.com/archives/Macosx-interop/2006/Nov/msg00013.html
> >
> > il ne semble même pas y avoir de problème avec launchd (à part
> > l'ordre dans lequel les démons sont lancés, pour ça, je ne sais
> > pas ce que launchd prévoit).
> Je ne vois pas de référence à amd...
Il est fait mention d'am-utils.
FiLH
> Dans l'article <1hqusvz.11pqcz81rs401zN%fi...@filh.orgie>,
> FiLH <fi...@filh.orgie> écrit:
>
> > http://developer.apple.com/macosx/launchd.html
>
> > Creating and running a launchd job
> > Whether you're migrating a job to launchd from some other system job
> > launcher, or you're setting up a job for a new service, there are a few
> > basic requirements for the job.
> > Jobs run from launchd should not duplicate launchd functionality; for
> > instance, they should not use chroot(2). Furthermore, they should not do
> > the things normally required of daemon processes, such as detaching from
> > the terminal they are initially attached to.
>
> Tout cela ne devrait pas poser de problème: il y a juste redondance.
Si : launchd relance amd sans arrêt... je crois que tu n'as pas pigé le
pb.
> Bon, évidemment, si par exemple, un démon essaie de se détacher d'un
> terminal éventuel et quitte parce qu'il n'y arrive pas (e.g., parce
> qu'il est déjà détaché), c'est qu'il est déjà bien buggé.
Ce n'est pas ce qu'il se produit....
> C'est une évidence: si un démon fait un fork et que le père quitte,
> il n'y a absolument plus moyen d'en garder une trace (sauf protocole
> particulier), vu que seul le pid du fils permet de manière standard
> d'avoir une information sur le fils. Certains logiciels utilisent la
> sortie de ps, mais c'est une méthode intrinsèquement buggée qu'on peut
> faire échouer (et par là même un trou de sécurité potentiel).
Sauv que svc sous solaris le fait mais bon hein...
> Parce que amd est écrit n'importe comment
Non c'est juste un démon.
>ou est prévu de fonctionner
> avec un protocole particulier.
Non. Ça marche normalement.
De la même manière, un démon écrit
> spécifiquement pour Darwin risque d'échouer sous Linux ou Solaris.
>
> svc.startd est un truc non standard. Tu dis simplement que amd
> fonctionne avec svcs, qui semble être spécifique à Solaris. Il
> est probable qu'amd utilise une fonctionnalité de Solaris ou
> que Solaris ait une fonctionnalité pour suivre les processus
> après un fork. Mais dans le second cas, Solaris pourrait se
> retrouver avec de "faux" démons si ceux-ci sont écrits pour
> un autre OS.
En fait t'en sais rien et tu brodes grave là, vu comment tu cause d'amd
qui serait spécifique à Solaris.
Sais tu qu'amd est l'automonteur BSD ?
Allez stop pour le délire là... l
Vincent Lefevre
FiLH <fi...@filh.orgie> écrit:
> Vincent Lefevre <vincen...@vinc17.org> wrote:
> > Dans l'article <1hqusvz.11pqcz81rs401zN%fi...@filh.orgie>,
> > FiLH <fi...@filh.orgie> écrit:
> >
> > > http://developer.apple.com/macosx/launchd.html
> >
> > > Creating and running a launchd job
> > > Whether you're migrating a job to launchd from some other system job
> > > launcher, or you're setting up a job for a new service, there are a few
> > > basic requirements for the job.
> > > Jobs run from launchd should not duplicate launchd functionality; for
> > > instance, they should not use chroot(2). Furthermore, they should not do
> > > the things normally required of daemon processes, such as detaching from
> > > the terminal they are initially attached to.
> >
> > Tout cela ne devrait pas poser de problème: il y a juste redondance.
> Si : launchd relance amd sans arrêt... je crois que tu n'as pas pigé le
> pb.
Ben non c'est toi qui n'as rien compris. Le fait que launchd relance
amd sans arrêt ne peut pas être dû aux problèmes ci-dessus (sauf si
le problème est qu'amd quitte/plante, mais dans ce cas, le problème
n'est pas que amd soit relancé par launched, mais qu'il quitte).
> > C'est une évidence: si un démon fait un fork et que le père quitte,
> > il n'y a absolument plus moyen d'en garder une trace (sauf protocole
> > particulier), vu que seul le pid du fils permet de manière standard
> > d'avoir une information sur le fils. Certains logiciels utilisent la
> > sortie de ps, mais c'est une méthode intrinsèquement buggée qu'on peut
> > faire échouer (et par là même un trou de sécurité potentiel).
> Sauv que svc sous solaris le fait mais bon hein...
Voilà, tu utilises un truc buggé (en lançant un programme qui a le même
nom que le démon, un utilisateur lambda peut tromper le système) et tu
critiques launchd, qui n'a pas ce genre de problème.
> > Parce que amd est écrit n'importe comment
> Non c'est juste un démon.
Et alors? Quasiment tous les démons fonctionnent avec launchd. Il n'y
a pas besoin de faire un fork + exit pour être un démon. La preuve est
que les autres démons ne le font pas.
> >ou est prévu de fonctionner
> > avec un protocole particulier.
> Non. Ça marche normalement.
Si tu râles, c'est que visiblement, ça ne marche pas normalement.
> > De la même manière, un démon écrit spécifiquement pour Darwin
> > risque d'échouer sous Linux ou Solaris. svc.startd est un truc non
> > standard. Tu dis simplement que amd fonctionne avec svcs, qui
> > semble être spécifique à Solaris. Il est probable qu'amd utilise
> > une fonctionnalité de Solaris ou que Solaris ait une
> > fonctionnalité pour suivre les processus après un fork. Mais dans
> > le second cas, Solaris pourrait se retrouver avec de "faux" démons
> > si ceux-ci sont écrits pour un autre OS.
> En fait t'en sais rien et tu brodes grave là, vu comment tu cause d'amd
> qui serait spécifique à Solaris.
Je ne dis pas qu'amd est spécifique à Solaris, mais que *svcs*
semble être spécifique à Solaris (une recherche sur Google parle
systématiquement de Solaris). Je dis aussi qu'amd peut utiliser
une fonctionnalité de Solaris (cela ne veut pas dire qu'amd est
spécifique à Solaris). Relis bien le paragraphe ci-dessus.
Maintenant, si svcs utilise la sortie de ps, ça peut fonctionner
ailleurs, mais comme je l'ai dit, une tierce personne peut tromper
le système. D'autre part, comme avec launchd, il y a probablement
des restrictions sur l'utilisation de svcs (par exemple, un démon
ne doit pas changer son nom avec ce système).
> Sais tu qu'amd est l'automonteur BSD ?
Oui, et alors?
Si tu as des arguments techniques pour résoudre le problème (par
exemple dans launchd), tu peux les donner[*]. Attention! S'il y a
un trou de sécurité potentiel, ça ne va pas. En attendant, je n'ai
rien vu.
[*] Il y a toujours la possibilité de demander à Apple d'ajouter une
option à launchd pour ne pas relancer les démons qui quittent, tout
du moins ceux avec un exit(0). Mais pour ces démons, s'ils plantent,
il sera impossible de les relancer automatiquement de façon fiable.
FiLH
> > Si : launchd relance amd sans arrêt... je crois que tu n'as pas pigé le
> > pb.
>
> Ben non c'est toi qui n'as rien compris. Le fait que launchd relance
Ouarfff donc toi qui ne voit rien n'a pas vu tu comprends mieux que moi,
t'invent la moitié des choses, mais bon...
> amd sans arrêt ne peut pas être dû aux problèmes ci-dessus (sauf si
> le problème est qu'amd quitte/plante, mais dans ce cas, le problème
> n'est pas que amd soit relancé par launched, mais qu'il quitte).
AMD NE QUITTE PAS ! launcd relance de multiples occurences car étant en
mode daemon launchd perd sa trace.
Ce comportement est tout à fait conforme à la doc de launchd face à un
prog qui passe en mode daemon.
Point barre....
> > Sauv que svc sous solaris le fait mais bon hein...
>
> Voilà, tu utilises un truc buggé (en lançant un programme qui a le même
> nom que le démon, un utilisateur lambda peut tromper le système) et tu
> critiques launchd, qui n'a pas ce genre de problème.
??? T'as fumé ou quoi ? tu connais pas amd, tu racontes n'importe quoi
tu te fais des films catastrophe sur un trou de sécu..
C'est de plus en plus le délire par chez toi...
> Et alors? Quasiment tous les démons fonctionnent avec launchd. Il n'y
> a pas besoin de faire un fork + exit pour être un démon. La preuve est
> que les autres démons ne le font pas.
Tu confond daemon et mode daemon, relis la doc de Launchd...
> [*] Il y a toujours la possibilité de demander à Apple d'ajouter une
> option à launchd pour ne pas relancer les démons qui quittent,
AMD NE QUITTE PAS !
AMD et Launchd se comportent mutiellement tout à fait correctement
suivant la doc.
Juste que Launchd ne sait pas gérer le mode daemon (et c'est DOCUMENTÉ),
contrairement à svc.startd de chez Solaris.
Point barre.
Voilà... le reste est un délire total de ta part...
Vincent Lefevre
FiLH <fi...@filh.orgie> écrit:
> > Et alors? Quasiment tous les démons fonctionnent avec launchd. Il n'y
> > a pas besoin de faire un fork + exit pour être un démon. La preuve est
> > que les autres démons ne le font pas.
> Tu confond daemon et mode daemon, relis la doc de Launchd...
"mode daemon" ne veut rien dire. N'importe quel programme peut dire
qu'il a un mode daemon. Mais ça peut être juste "se détacher du
terminal".
> > [*] Il y a toujours la possibilité de demander à Apple d'ajouter une
> > option à launchd pour ne pas relancer les démons qui quittent,
> AMD NE QUITTE PAS !
> AMD et Launchd se comportent mutiellement tout à fait correctement
> suivant la doc.
> Juste que Launchd ne sait pas gérer le mode daemon (et c'est DOCUMENTÉ),
Launchd gère bien tous les processus qui se comportent correctement.
Faire un fork + exit est complètement inutile pour pouvoir
fonctionner, même pour les démons.
> contrairement à svc.startd de chez Solaris.
que n'importe quel utilisateur peut tromper facilement. Libre à toi
d'utiliser des programmes troués. Mais merci de ne pas les imposer
aux autres.
FiLH
> Dans l'article <1hqz6e0.1yhdphhej5ekiN%fi...@filh.orgie>,
> FiLH <fi...@filh.orgie> écrit:
>
> > > Et alors? Quasiment tous les démons fonctionnent avec launchd. Il n'y
> > > a pas besoin de faire un fork + exit pour être un démon. La preuve est
> > > que les autres démons ne le font pas.
>
> > Tu confond daemon et mode daemon, relis la doc de Launchd...
>
> "mode daemon" ne veut rien dire. N'importe quel programme peut dire
> qu'il a un mode daemon. Mais ça peut être juste "se détacher du
> terminal".
Doc Apple (encore...
Jobs run from launchd should not duplicate launchd functionality; for
instance, they should not use chroot(2). Furthermore, they should not do
the things normally required of daemon processes, such as detaching from
the terminal they are initially attached to. The only things that are
strictly prohibited, however, are fork()/exit() combinations (including
indirect methods, such as the daemon(3) library call). A server which
>>
> Launchd gère bien tous les processus qui se comportent correctement.
Je te remets un petit coup de doc Apple hein...
Jobs run from launchd should not duplicate launchd functionality; for
instance, they should not use chroot(2). Furthermore, they should not do
the things normally required of daemon processes, such as detaching from
the terminal they are initially attached to. The only things that are
strictly prohibited, however, are fork()/exit() combinations (including
indirect methods, such as the daemon(3) library call). A server which
> Faire un fork + exit est complètement inutile pour pouvoir
> fonctionner, même pour les démons.
Et je te remets la doc, elle répond là encore à ce que tu dis... (the
things normally requiered as daemon)...
Jobs run from launchd should not duplicate launchd functionality; for
instance, they should not use chroot(2). Furthermore, they should not do
the things normally required of daemon processes, such as detaching from
the terminal they are initially attached to. The only things that are
strictly prohibited, however, are fork()/exit() combinations (including
indirect methods, such as the daemon(3) library call). A server which
> que n'importe quel utilisateur peut tromper facilement. Libre à toi
Je ne suis pas un utilisateur,
> d'utiliser des programmes troués.
N'importe quoi... quel programme est troué ?
>Mais merci de ne pas les imposer
> aux autres.
Tu fais tourner ? Elle est bonne ?
Juste une question t'administre combien de machines sous combien d'os
depuis combien d'année ?
FiLH J'avoue que je continue parce que tu me fais trop rire...
Vincent Lefevre
FiLH <fi...@filh.orgie> écrit:
> Vincent Lefevre <vincen...@vinc17.org> wrote:
> > "mode daemon" ne veut rien dire. N'importe quel programme peut dire
> > qu'il a un mode daemon. Mais ça peut être juste "se détacher du
> > terminal".
> Doc Apple (encore...
> Jobs run from launchd should not duplicate launchd functionality; for
> instance, they should not use chroot(2). Furthermore, they should not do
> the things normally required of daemon processes, such as detaching from
> the terminal they are initially attached to. The only things that are
> strictly prohibited, however, are fork()/exit() combinations (including
> indirect methods, such as the daemon(3) library call). A server which
C'est peut-être ce que *tu* appelles mode daemon. Mais tous les démons
ne font pas ce genre de choses. Souvent ils n'en font qu'une partie. Et
la combinaison fork()/exit() est très rare (pour le moment, amd vs tous
les démons qui fonctionnent avec launchd).
> > Launchd gère bien tous les processus qui se comportent correctement.
> Je te remets un petit coup de doc Apple hein...
> Jobs run from launchd should not duplicate launchd functionality; for
> instance, they should not use chroot(2). Furthermore, they should not do
> the things normally required of daemon processes, such as detaching from
> the terminal they are initially attached to. The only things that are
> strictly prohibited, however, are fork()/exit() combinations (including
> indirect methods, such as the daemon(3) library call). A server which
Et alors?
> > Faire un fork + exit est complètement inutile pour pouvoir
> > fonctionner, même pour les démons.
> Et je te remets la doc, elle répond là encore à ce que tu dis... (the
> things normally requiered as daemon)...
> Jobs run from launchd should not duplicate launchd functionality; for
> instance, they should not use chroot(2). Furthermore, they should not do
> the things normally required of daemon processes, such as detaching from
> the terminal they are initially attached to. The only things that are
> strictly prohibited, however, are fork()/exit() combinations (including
> indirect methods, such as the daemon(3) library call). A server which
Et alors?
Au passage, note que daemon() n'est pas POSIX. Donc son utilisation
pas un démon portable ne peut être qu'optionnelle.
> > que n'importe quel utilisateur peut tromper facilement. Libre à toi
> Je ne suis pas un utilisateur,
Et alors?
> > d'utiliser des programmes troués.
> N'importe quoi... quel programme est troué ?
Celui qui utilise la sortie de ps pour déterminer si un démon tourne
encore.
> Juste une question t'administre combien de machines sous combien d'os
> depuis combien d'année ?
Cette question est hors-sujet. Ce n'est pas parce qu'on est
administrateur de quelques milliers de machines qu'on est
forcément bon. Je peux te dire qu'en tant que simple utilisateur
de quelques centaines de machines sous divers OS, j'en ai vue
des choses mal écrites... Et j'ai déjà rapporté plusieurs trous
de sécurité.
Nicolas MICHEL
> C'est peut-être ce que *tu* appelles mode daemon. Mais tous les démons
> ne font pas ce genre de choses. Souvent ils n'en font qu'une partie. Et
> la combinaison fork()/exit() est très rare (pour le moment, amd vs tous
> les démons qui fonctionnent avec launchd).
"Très rare" ?
Si launchd supportait le mode daemon, contrairement à ce que dit la doc
d'Apple laquelle recommande de "migrer" les services en utilisant
l'option "RunAtLoad", pourquoi subsisterait-il des services lancés via
des StartupItems ?
%> ls -1 /System/Library/StartupItems
Apache
AppServices
AppleShare
AuthServer
CrashReporter
Disks
FibreChannel
IFCStart
IPServices
Metadata
NFS
NIS
NetworkTime
PrintingServices
RemoteDesktopAgent
SNMP
M'enfin moi ce que j'en dis...
--
Nicolas
Nicolas MICHEL
> pourquoi subsisterait-il des services lancés via
> des StartupItems ?
Bon, la réponse semble être dans la doc. Je cite :
> Some, however, are run this way (StartupItems, donc) because they [snip]
> need an explicit shutdown procedure, which is handled by the StopService()
> function in a StartupItem script.
D'après ce que FiLH dit, amd "ne quite pas", je suppose donc qu'il "need
an explicit shutdown procedure" et que donc il doit bel et bien être
lancé par un StartupItems.
En fait, j'ai pas compris une chose : Pourquoi ne pas lancer amd avec
l'option "RunAtLoad" ?
Bon, je crois que je mélange tout.
--
Nicolas
FiLH
> D'après ce que FiLH dit, amd "ne quite pas", je suppose donc qu'il "need
> an explicit shutdown procedure" et que donc il doit bel et bien être
> lancé par un StartupItems.
>
> En fait, j'ai pas compris une chose : Pourquoi ne pas lancer amd avec
> l'option "RunAtLoad" ?
> Bon, je crois que je mélange tout.
Parce que launchd le relance sans arrêt !
Comme amd se détache, launchd perd sa trace, croit qu'il a planté et le
relance... Maintenant le seul truc est que amd pourrait voir quil tourne
déjà et quitter de suite, mais ça ne résoudrait pas le pb de launchd qui
le relancerait.
Et ce comportement est 100% conforme à la doc Apple...
Juste que launchd n'est pas aussi universel qu'Apple l'annonce.
Sinon arrêter amd ça n'a pas trop de sens hein.. même si c'est prévu en
standard, en général on le lance après le réseau et le client nfs et on
le quitte quand on arrête la machine.
Après sur les comparaisons, svc semble pouvoir faire beaucoup plus de
choses : trois types de services, gestion de dépendances dans deux sens,
gestion de runlevels, suivi des processus, relance des processus en cas
de reconfiguration ou de redémarrage d'autres processus...
FiLH
Nicolas MICHEL
> Comme amd se détache, launchd perd sa trace, croit qu'il a planté et le
> relance...
Pourtant, dans la doc, ils disent :
> > There are two common cases for commands run from /etc/rc (or rc.local).
> > In one, a command is simply run once at system startup. This corresponds
> > to the RunAtLoad key in a launchd job file
D'où je comprenais, moi, que launchd lance les services ayant la clef
"RunAtLoad" qu'une seule fois au boot.
Mais visiblement c'est pas le cas.
> Et ce comportement est 100% conforme à la doc Apple...
Oui, ils disent bien que dans certains cas il faut faire un StartupItem.
> Juste que launchd n'est pas aussi universel qu'Apple l'annonce.
Et du coup, on perds un peu l'intérêt de launchd qui prétends pourtant
être "le moyen unique et standard de lancer les services":
> > The launchd daemon offers a single, standardized, interface to any and
> > all programs started automatically by the system
Bon, ce système est encore perfectible, mais ça on l'avait remarqué :)
--
Nicolas
FiLH
> FiLH <fi...@filh.orgie> wrote:
>
> > Comme amd se détache, launchd perd sa trace, croit qu'il a planté et le
> > relance...
>
> Pourtant, dans la doc, ils disent :
> > > There are two common cases for commands run from /etc/rc (or rc.local).
> > > In one, a command is simply run once at system startup. This corresponds
> > > to the RunAtLoad key in a launchd job file
>
> D'où je comprenais, moi, que launchd lance les services ayant la clef
> "RunAtLoad" qu'une seule fois au boot.
> Mais visiblement c'est pas le cas.
Hum non...
There are two common cases for commands run from /etc/rc (or rc.local).
In one, a command is simply run once at system startup. This corresponds
to the RunAtLoad key in a launchd job file. The other case is a daemon
which waits for connections.
RunAtLoad lance une fois et tente de le maintenir en vie. Dans l'autre
cas c'est un fonctionnement à la inetd : il attend sur un port et lance
le daemon.
Si tu lance un prog qui se détache en RunAtLoad alors il va le relancer
indéfiniment car pour lui le détachement est vu comme un plantage.
Chez Sun, on a trois mode : le mode inetd: on écoute sur un socket et on
relance à chaque connection, le monde contract : on lance un process et
on surveille qu'il tourne et dans certains cas on le relance ou on le
passe en maintenance ou autre, le mode transient : on lance le truc une
fois au démarrage, le process tourne puis s'arrête (par exemple un
nettoyage de répertoire) et le service est considéré comme réalisé.
> > Juste que launchd n'est pas aussi universel qu'Apple l'annonce.
>
> Et du coup, on perds un peu l'intérêt de launchd qui prétends pourtant
> être "le moyen unique et standard de lancer les services":
:) Ben ils auraient intérêt à piquer les idées de Sun. D'autant que
launchd ne gère pas de dépendances.
Par contre le plus Apple c'est apparament une version améliorée de cron
qui lance les jobs quand il peut, et plus adapté à une machine qui
peut-être endormie. Ça c'est bien.
Enfin dans les deux cas (Sun et Apple) on note que les bonnes vieilles
méthodes continuent de tourner (script init.d chez sun, startupItems
chez Apple)... comme quoi :)
> > > The launchd daemon offers a single, standardized, interface to any and
> > > all programs started automatically by the system
>
> Bon, ce système est encore perfectible, mais ça on l'avait remarqué :)
Après avoir pesté comme un rat mort, je commence à m'y faire.
Mais bon, même chez Sun il y a quelques défauts notamment sur
l'ordonnancement (certaines tâches sont vues comme achevées mais ne sont
vraiment finies qu'un peu plus tard ce qui peut foutre un bronx pas
possible).
Vincent Lefevre
Nicolas MICHEL <Nicolas...@bonbon.net> écrit:
> Nicolas MICHEL <Nicolas...@BonBon.net> wrote:
> > pourquoi subsisterait-il des services lancés via
> > des StartupItems ?
Parce qu'ils n'ont pas encore tout migré.
> Bon, la réponse semble être dans la doc. Je cite :
> > Some, however, are run this way (StartupItems, donc) because they [snip]
> > need an explicit shutdown procedure, which is handled by the StopService()
> > function in a StartupItem script.
Je pense que NetworkTime n'a pas besoin de "shutdown procedure", par
exemple. Normalement, un service ne devrait pas avoir besoin d'une
telle procédure (le signal TERM envoyé au shutdown devrait être
suffisant si le service est bien écrit).
Vincent Lefevre
FiLH <fi...@filh.orgie> écrit:
> :) Ben ils auraient intérêt à piquer les idées de Sun.
Oh non!
> D'autant que launchd ne gère pas de dépendances.
Cela peut être vu aussi comme un problème des services en question.
Apple recommande que les démons sachent attendre ce dont ils ont
besoin, i.e. les démons doivent gérer eux-mêmes les dépendances de
manière dynamique.
Les dépendances introduisent certaines contraintes et ne résolvent
pas tout. Par exemple, lorsqu'un service est lancé, cela ne veut pas
forcément dire qu'il fonctionne (e.g., problème de configuration).
Aussi, que faire quand il y a des dépendances optionnelles?
> Par contre le plus Apple c'est apparament une version améliorée de cron
> qui lance les jobs quand il peut, et plus adapté à une machine qui
> peut-être endormie. Ça c'est bien.
Il existe déjà anacron qui fait ça. Ce n'est donc pas nouveau. En
revanche, avec un seul système, on y gagne en clarté (parce que
pour supporter à la fois cron et anacron sans conflit, c'est un
peu le flou et il est plus facile de faire une erreur).
> Enfin dans les deux cas (Sun et Apple) on note que les bonnes vieilles
> méthodes continuent de tourner (script init.d chez sun, startupItems
> chez Apple)... comme quoi :)
Sauf que c'est plus limité. Sous Linux, le init.d n'est pas très
fiable: quand un démon plante, il laisse traîne un /var/run/*.pid
derrière et le système croit qu'il tourne toujours. Et c'est
inévitable avec ce système. La méthode de launchd est infaillible:
si le fils quitte ou plante, il reçoit toujours un SIGCHLD.
Vincent Lefevre
Nicolas MICHEL <Nicolas...@bonbon.net> écrit:
> FiLH <fi...@filh.orgie> wrote:
> > Juste que launchd n'est pas aussi universel qu'Apple l'annonce.
Il n'y a rien d'universel. En revanche, launchd ne nécessite aucune
fonctionnalité non POSIX.
> Et du coup, on perds un peu l'intérêt de launchd qui prétends pourtant
> être "le moyen unique et standard de lancer les services":
Il suffit que le service soit suffisamment bien écrit.
> Bon, ce système est encore perfectible, mais ça on l'avait remarqué :)
Si tu as une suggestion pour améliorer launchd, n'hésite pas à la donner.
Nicolas MICHEL
> Dans l'article <1hrd2k2.1negfyh1d4jugtN%Nicolas...@BonBon.net>,
> Nicolas MICHEL <Nicolas...@bonbon.net> écrit:
>
> > Nicolas MICHEL <Nicolas...@BonBon.net> wrote:
>
> > > pourquoi subsisterait-il des services lancés via
> > > des StartupItems ?
>
> Parce qu'ils n'ont pas encore tout migré.
Ah, c'est comme M$ et Adobe, ils leur faut 2 ans pour une mise à jour et
quand finalement elle sort ils te la font payer en tant que nouvelle
version ? Cool !
amha s'il suffisait d'écrire un .plist dans LaunchDaemon ils l'auraient
déjà fait. Et je penses qu'ils ne l'ont pas fait parce que
- Launchd ne sais pas gérer certains truc nécessaires pour ces services
- En l'absence d'un "meilleur" Launchd, il faudrait réécrire
partiellement ces services
- Et ce serait du travail pour rien parce que le résultat, possiblement
buggé, ne ferait rien de plus que ce qu'on a déjà.
Mais si tu penses être en mesure de me prouver que j'ai tord, fais nous
un .plist pour NetworkTime (ou pour NFS, ou ce que tu veux d'autre),
je l'installerai bien volontier :>
> Je pense que NetworkTime n'a pas besoin de "shutdown procedure", par
> exemple. Normalement, un service ne devrait pas avoir besoin d'une
> telle procédure (le signal TERM envoyé au shutdown devrait être
> suffisant si le service est bien écrit).
Je n'ai pas les compétances pour juger du comment devrait être écrit tel
ou tel service. A présent si tu penses que NetworkTime, Apache, NFS,
automount, AppleFileServer, RemoteDesktopAgent et consort sont mal
écrits parce que launchd ne sait pas les gérer, quand bien même ils
existaient avant launchd, à ta guise.
Moi je préfère penser que Apple n'a pas voulu créer un launchd capable
de prendre en charge les services existants, que c'est une décision
"politique" à la Apple et que ce genre de changement non aboutit et à
l'emporte pièce est un des charmes de la firme de Cupertino.
--
Nicolas
FiLH
> Si tu as une suggestion pour améliorer launchd, n'hésite pas à la donner.
Ben va voir svc :)....
Vincent Lefevre
FiLH <fi...@filh.orgie> écrit:
> Vincent Lefevre <vincen...@vinc17.org> wrote:
> > Si tu as une suggestion pour améliorer launchd, n'hésite pas à la donner.
> Ben va voir svc :)....
J'ai demandé une amélioration, pas un truc buggé par design.
FiLH
> Dans l'article <1hrozbs.1j0wtsjp4vb1fN%fi...@filh.orgie>,
> FiLH <fi...@filh.orgie> écrit:
>
> > Vincent Lefevre <vincen...@vinc17.org> wrote:
>
> > > Si tu as une suggestion pour améliorer launchd, n'hésite pas à la donner.
>
> > Ben va voir svc :)....
>
> J'ai demandé une amélioration, pas un truc buggé par design.
J'ai un peu de mal à voir comment tu trouves des bugs sur un truc que tu
ne connais manifestement pas.
Vincent Lefevre
FiLH <fi...@filh.orgie> écrit:
> Vincent Lefevre <vincen...@vinc17.org> wrote:
> > Dans l'article <1hrozbs.1j0wtsjp4vb1fN%fi...@filh.orgie>,
> > FiLH <fi...@filh.orgie> écrit:
> >
> > > Vincent Lefevre <vincen...@vinc17.org> wrote:
> >
> > > > Si tu as une suggestion pour améliorer launchd, n'hésite pas à
> > > > la donner.
> >
> > > Ben va voir svc :)....
> >
> > J'ai demandé une amélioration, pas un truc buggé par design.
> J'ai un peu de mal à voir comment tu trouves des bugs sur un truc
> que tu ne connais manifestement pas.
Tu avais dit qu'il utilisait la sortie de ps. Or le ps ne donne pas
assez d'info pour identifier un processus. En fait, la seule info
véritablement fiable est le PID (éventuellement le PPID), mais comme
le démon fait un fork, il se retrouve avec un PID différent, sur
lequel on ne peut plus rien dire.
FiLH
> Dans l'article <1hrrnao.14n9coey4jy53N%fi...@filh.orgie>,
> FiLH <fi...@filh.orgie> écrit:
>
> > Vincent Lefevre <vincen...@vinc17.org> wrote:
>
> > > Dans l'article <1hrozbs.1j0wtsjp4vb1fN%fi...@filh.orgie>,
> > > FiLH <fi...@filh.orgie> écrit:
> > >
> > > > Vincent Lefevre <vincen...@vinc17.org> wrote:
> > >
> > > > > Si tu as une suggestion pour améliorer launchd, n'hésite pas à
> > > > > la donner.
> > >
> > > > Ben va voir svc :)....
> > >
> > > J'ai demandé une amélioration, pas un truc buggé par design.
>
> > J'ai un peu de mal à voir comment tu trouves des bugs sur un truc
> > que tu ne connais manifestement pas.
>
> Tu avais dit qu'il utilisait la sortie de ps.
Non. Je n'ai JAMAIS dit ça.
> Or le ps ne donne pas
> assez d'info pour identifier un processus. En fait, la seule info
> véritablement fiable est le PID (éventuellement le PPID), mais comme
> le démon fait un fork, il se retrouve avec un PID différent, sur
> lequel on ne peut plus rien dire.
Attend tu parles de quoi là ?
Moi j'attend les bugs de conception de svc par le grand guru
Levebvre...
Et je lis une fiction complètment délirante dans lequel tu
m'inventes des propos que je n'ai pas tenu et on ne sait même pas
de quoi tu causes :)
Je plains tes ingés sys...
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail fi...@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Vincent Lefevre
FiLH <fi...@filh.org> écrit:
> Vincent Lefevre <vincen...@vinc17.org> writes:
> > Tu avais dit qu'il utilisait la sortie de ps.
> Non. Je n'ai JAMAIS dit ça.
http://groups.google.fr/group/fr.comp.os.mac-os.x/msg/6d93de5594f06ce7
| > C'est une évidence: si un démon fait un fork et que le père quitte,
| > il n'y a absolument plus moyen d'en garder une trace (sauf protocole
| > particulier), vu que seul le pid du fils permet de manière standard
| > d'avoir une information sur le fils. Certains logiciels utilisent la
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| > sortie de ps, mais c'est une méthode intrinsèquement buggée qu'on peut
^^^^^^^^^^^^
| > faire échouer (et par là même un trou de sécurité potentiel).
|
| Sauv que svc sous solaris le fait mais bon hein...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(Je suppose que ton "Sauv" est une typo pour "Sauf".)
> Et je lis une fiction complètment délirante dans lequel tu
> m'inventes des propos que je n'ai pas tenu et on ne sait même pas
> de quoi tu causes :)
Heureusement qu'il y a Google...
Vu que tu ne sais plus trop ce que tu as dit, veux-tu nous expliquer
une fois pour toute comment fonctionne svc sous Solaris?