Je ne suis pas trop sûr de savoir ce que tu veux faire en fait.
Si tu écrits un daemon, le mieux me semble de t'assurer que ton daemon se méfie de l'OS comme de la peste (en fait, l'OS et tous les processus externes doivent être considérés comme des utilisateurs, et donc pouvant dire de la merde, pour une sécurité maximale), et vérifie tous les pré-requis au minimum à l'initialisation. Dans le cas d'un outils de sécurité, tu devras aussi t'arranger pour chiffrer la RAM, mais, honnêtement, je n'ai jamais creusé. Sûrement un truc bien pénible à faire, et certainement pas la 1ère cause de problèmes.
Tout ça est souvent plus simple à faire dans le code exécutable plutôt que par le système d'init: il suffit de vérifier chaque retour de chaque fonction d'I/O pour être sûr que l'I/O s'est bien passée. C'est chiant, mais bon... Sinon, il y a les exceptions, mais c'est à éviter comme la peste si tu ne codes pas un binaire unique (édition des liens statique): il se pourrait que l'API ou l'ABI varie avec le temps, amenant des bugs particulièrement mesquins. La contrepartie d'une édition de liens statique, c'est un binaire potentiellement plus gros. Dans les faits, j'ai plus constaté un binaire plus petit... L'autre problème, c'est la difficulté de mise à jour. Elle ne se pose que peu pour un logiciel libre, surtout que de nos jours les CPU sont des monstres, mais pour un logiciel fermé, c'est différent.
Si tu ne peux pas, ou ne veux pas, vérifier tous les pré-requis correctement, alors tu te dois au minimum de les indiquer dans la doc... enfin, si tu prétends être fier de ton œuvre. Pour moi, soit le code vérifie de manière explicite les pré-requis, soit la doc les spécifie. Et l'idéal, c'est quand les deux sont réunis (mais, c'est rare, parce que c'est déjà chiant d'en faire un, alors les deux... argh!).
Si tu écris un système d'init, alors... hum, bon courage, mais dans ce cas tu sais probablement déjà ce que tu fais, ou alors tu cherches à apprendre pour le fun, donc pas de soucis.
[^] # Re: SystemV RC est obsolète
Posté par freem . En réponse au message système d'init. Évalué à 2.
Je ne suis pas trop sûr de savoir ce que tu veux faire en fait.
Si tu écrits un daemon, le mieux me semble de t'assurer que ton daemon se méfie de l'OS comme de la peste (en fait, l'OS et tous les processus externes doivent être considérés comme des utilisateurs, et donc pouvant dire de la merde, pour une sécurité maximale), et vérifie tous les pré-requis au minimum à l'initialisation. Dans le cas d'un outils de sécurité, tu devras aussi t'arranger pour chiffrer la RAM, mais, honnêtement, je n'ai jamais creusé. Sûrement un truc bien pénible à faire, et certainement pas la 1ère cause de problèmes.
Tout ça est souvent plus simple à faire dans le code exécutable plutôt que par le système d'init: il suffit de vérifier chaque retour de chaque fonction d'I/O pour être sûr que l'I/O s'est bien passée. C'est chiant, mais bon... Sinon, il y a les exceptions, mais c'est à éviter comme la peste si tu ne codes pas un binaire unique (édition des liens statique): il se pourrait que l'API ou l'ABI varie avec le temps, amenant des bugs particulièrement mesquins. La contrepartie d'une édition de liens statique, c'est un binaire potentiellement plus gros. Dans les faits, j'ai plus constaté un binaire plus petit... L'autre problème, c'est la difficulté de mise à jour. Elle ne se pose que peu pour un logiciel libre, surtout que de nos jours les CPU sont des monstres, mais pour un logiciel fermé, c'est différent.
Si tu ne peux pas, ou ne veux pas, vérifier tous les pré-requis correctement, alors tu te dois au minimum de les indiquer dans la doc... enfin, si tu prétends être fier de ton œuvre. Pour moi, soit le code vérifie de manière explicite les pré-requis, soit la doc les spécifie. Et l'idéal, c'est quand les deux sont réunis (mais, c'est rare, parce que c'est déjà chiant d'en faire un, alors les deux... argh!).
Si tu écris un système d'init, alors... hum, bon courage, mais dans ce cas tu sais probablement déjà ce que tu fais, ou alors tu cherches à apprendre pour le fun, donc pas de soucis.