Origine des noms des dossiers systèmes - Débats - Linux et OS Alternatifs
Marsh Posté le 08-01-2003 à 17:27:55
/usr pour user : les programmes utilisateurs (non systèmes / indispensables)
Sinon je me suis toujours demandé ce que signifiaient les lettres "rc" comme dans /etc/rc.d ...
Marsh Posté le 08-01-2003 à 17:31:38
et les .d (init.d rc.d xinit.d inet.d cron.d ...) pourquoi ils ont là ?
rc : runlevel change ? (puisqu'on éxécute ce qu'il y a dedans à chaque changement de runlevel) mais ça marche pas pour rc.firewall ou rc.local ni rc.sysinit
Marsh Posté le 08-01-2003 à 19:09:43
Mjules a écrit : et les .d (init.d rc.d xinit.d inet.d cron.d ...) pourquoi ils ont là ? |
peut etre pour daemon comme httpd, sshd, dhcpd etc...
Marsh Posté le 08-01-2003 à 19:49:45
le s de sbin, c'est peut-être le s de super-utilisateur non ?
Marsh Posté le 08-01-2003 à 22:54:35
pour ce qui est specific a linux y a bcq de choses qui expliquent la dedans http://www.pathname.com/fhs/pub/fhs-2.2.pdf
FHS = file hierarchy standart , ca va avec la lsb
Marsh Posté le 09-01-2003 à 10:02:16
houplaboom42 a écrit : pour ce qui est specific a linux y a bcq de choses qui expliquent la dedans http://www.pathname.com/fhs/pub/fhs-2.2.pdf |
Euh, t'as vu que c'est le lien que je donne à la 5° ligne du premier topic ?
Marsh Posté le 09-01-2003 à 10:31:38
Apparemment, /bin et /sbin n'existaient pas au debut de linux.
Ca a commence avec /usr /var /etc je pense (peut etre aussi /proc et quelques autres, mais pas bin ni sbin).
/usr pour mettre ce qui etait relatif aux utilisateurs (usr pour user)
/var pour mettre ce qui etait variable
/etc pour mettre le reste (etcaetera, le reste quoi)
Ensuite, ils sont du se dire que ca faisait trop de trucs a mettre dans ETC, donc ils ont fait une arborescence plus fournie, mais en gardant ce qu'il y avait avant pour compatibilite (en 1993 je crois).
Marsh Posté le 09-01-2003 à 10:38:44
ReplyMarsh Posté le 09-01-2003 à 10:43:09
bitman13 a écrit : .d c pas daemon ? |
ben non, pourquoi tu veux que ce soit daemon ? les *.d sont des directories (on met le d pour pas les confondre avec des fichiers homonymes).
pkoi daemon ? vois pas le rapport ?
Marsh Posté le 09-01-2003 à 10:53:01
minusplus a écrit : ben non, pourquoi tu veux que ce soit daemon ? les *.d sont des directories (on met le d pour pas les confondre avec des fichiers homonymes). |
heu ché pas suis nul, xinit.d ya des daemon dedans enfin voila patapai !
Marsh Posté le 09-01-2003 à 10:55:10
bitman13 a écrit : heu ché pas suis nul, xinit.d ya des daemon dedans enfin voila patapai ! |
dans xinit.d ? c'est où ça ? dans /etc/ ? ça m'étonnerai qu'il y ait des démons là dedans mais bon..
Marsh Posté le 09-01-2003 à 10:58:11
minusplus a écrit : dans xinit.d ? c'est où ça ? dans /etc/ ? ça m'étonnerai qu'il y ait des démons là dedans mais bon.. |
oups, xinetd.d
Marsh Posté le 09-01-2003 à 11:01:26
/usr ne signifie pas "user", puisque le user met son bordel dans /home.
C'est unix system resource, en gros tous les logiciels.
Marsh Posté le 09-01-2003 à 11:02:39
zeb_ a écrit : /usr ne signifie pas "user", puisque le user met son bordel dans /home. |
et /etc ?
Marsh Posté le 09-01-2003 à 11:33:23
zeb_ a écrit : /usr ne signifie pas "user", puisque le user met son bordel dans /home. |
Encore une fois, /home n'existait pas a l'origine je pense.
Marsh Posté le 09-01-2003 à 11:35:54
zeb_ a écrit : /usr ne signifie pas "user", puisque le user met son bordel dans /home. |
je ne suis pas d'accord. dans / va tout ce qui est necessaire au fonctionnement et à la maintenance essentielle du système (pour l'admin en fait), dans /usr va tout ce qui est utilisation pratique du système c'est à dire les softs utilisateur.
de plus, je suis d'accord avec sartene, le /home est quelque chose d'assez batard (qui n'est d'ailleurs pas requis dans le FHS)
Marsh Posté le 09-01-2003 à 21:40:49
minusplus a écrit : je ne suis pas d'accord. dans / va tout ce qui est necessaire au fonctionnement et à la maintenance essentielle du système (pour l'admin en fait), dans /usr va tout ce qui est utilisation pratique du système c'est à dire les softs utilisateur. |
Le dernier Linux pratique en parle. Tu peux faire une recherche "unix system resource" sur google et tu trouveras /usr
Marsh Posté le 09-01-2003 à 22:20:42
zeb_ a écrit : |
Ici :
http://www.biozentrum.unibas.ch/~b [...] course.pdf
Tu verras que /home n'existe pas a la base . Par contre il y a avait un repertoire "users" qui a disparu...
/ : Is the root directory
/dev : Contains the different special files.
/etc : Contains the system configuration files.
/sbin : Contains the system binary and executable files
/tmp : Temporary file zone
/usr : Contains the UNIX System Resource files
/var : Contains the variable files like mail, news, spool,...
/users : Contains the users directories and files
vmunix : DEC UNIX kernel located under root
Marsh Posté le 09-01-2003 à 22:38:06
sartene a écrit : |
Je comprends la confusion : les gens ont fini par assimiler /users et /usr car ça se prononce de la même façon. C'est peut-être pour ça que home a été créé, pour éviter la confusion phonétique.
C'est très "bricolage", mais c'est marrant, ça ressemble à l'évolution en biologie.
Marsh Posté le 10-01-2003 à 07:32:06
pour info le /users n'a pas entierement disparu .... il etait encore present sur solaris (en tout cas a l'ecole ou je suis l'année dernière)
Marsh Posté le 10-01-2003 à 13:44:13
Sur Solaris 8 pour x86, le /home existe mais il est vide et inutilisable : il n'est present que pour des notions de compatibilité
Si je me souviens bien ,les repertoires des utilisateurs sont dans /users/home ou qqchose comme ça
Marsh Posté le 10-01-2003 à 13:56:12
Ah oui, je me souviens vaguement d'un lien entre /home et je_sais_plus_ou, mais ca fait pertpete que j'ai plus touche de Solaris...
Marsh Posté le 10-01-2003 à 14:32:50
zeb_ a écrit : |
ah ben oué tiens, désolé, je savais pas !
Marsh Posté le 12-01-2003 à 22:03:25
Bon, et bien on a avancé quand même, on sait pourquoi /usr : unix system resource, et xxxx.d pour directory
Vos idées et connaissances sont encores bienvenues, il reste /etc (et caetera ?) et /opt ( optionnal ?) à trouver.
et aussi si on pouvait avoir une certitude sur le rc de rc.local, rcX.d ...
A+
Marsh Posté le 13-01-2003 à 11:26:12
opt je suis quasi sur que c'est effectivement optionnal
pour etc j'approuve le et caetera, mais c'est juste un avis perso
sinon, rc c'est pas resource control ou qqchose dans le genre ?
Marsh Posté le 13-01-2003 à 11:49:53
sbin
g tjrs compris ça comme "binaire secondaires" > pas indispensables au fonctionnement du système.
Marsh Posté le 13-01-2003 à 11:52:43
et /sbin/mount ? c'est pas indispensable a ton système ???
Pour moi : sbin => binaires du sysadmin
Marsh Posté le 13-01-2003 à 11:59:51
e_esprit a écrit : et /sbin/mount ? c'est pas indispensable a ton système ??? |
fo croire ke non puiske chez moi il est pas dans ce dossier (g une mandrake)
mount est dans le /bin.
Dans sbin g rien de vital.
Marsh Posté le 13-01-2003 à 12:03:44
mober a écrit : |
oh que si, tu as init dans /sbin et c'est aps la peine d'espérer démarrer normalement sans lui
tu as ifconfig (laisse tomber le réseau sans lui)
et quelques autres trucs sympa
Marsh Posté le 13-01-2003 à 12:08:30
Citation : Dans sbin g rien de vital. |
ls /sbin :
...
init
...
fsck
...
lilo
...
modprobe
...
depmod
...
shutdown
...
etc
Marsh Posté le 13-01-2003 à 12:16:19
Mjules a écrit : |
je suis d'accord avec toi sbin regorge de truc très utils.
Ceci dit mon répertoire /bin contient lui aussi pas mal de programme permettant d'administrer le système.
Par exemple g /bin/kill et /sbin/killall, c dans ce sens ke je dit ke les binaires de /sbin sont secondaires.
Marsh Posté le 17-01-2003 à 10:21:19
mober a écrit : |
Je pense plutot que les binaires de sbin sont "system binaries", vu que root est le seul a l'avoir dans son path par defaut.
Marsh Posté le 17-01-2003 à 11:08:34
sartene a écrit : |
ok, va pour les "system binaires"
Par contre je viens de regarder plus en détail les droits fixés sur les répertoires /bin et /sbin chez et ce sont exactement les mêmes
g une mandrake et g simplement spécifié un niveau de sécurité moyen sans plus me casser la tête, c déjà assez contraignante pour ce ke je fais de mon poste.
Bref je comprends de moins en moins bien la différence en tre /bin et /sbin (à moins peut-être qu'elle apparaisse à un niveau de sécurité plus élevé )
g fait qq test en lancant des executables depuis un compte normal et ça marche, heureusement les programmes les pus importants genre iptables sont sécurisés au niveau logiciel et réclame les privilèges d'administrateur.
bah g encore beaucoup de choses à apprendre
Marsh Posté le 17-01-2003 à 11:20:30
En fait c'est plus une separation logique qu'autre chose...
C'est juste que normalement, un utilisateur n'a pas a faire de traceroute, de init (de toutes facons ca marchera pas...), d'installation de lilo, etc...
Donc ca sert a rien que ca traine dans son path...
Marsh Posté le 17-01-2003 à 12:32:37
Sous debian, je ne crois pas que les utilisateurs lambda aient accès à sbin.
Marsh Posté le 17-01-2003 à 12:51:35
sartene a écrit : Sous debian, je ne crois pas que les utilisateurs lambda aient accès à sbin. |
Si l'utilisateur a acces a sbin mais celui-ci n'est pas dans son PATH donc il doit faire /sbin/lacommande.
Marsh Posté le 17-01-2003 à 12:53:12
sartene a écrit : Sous debian, je ne crois pas que les utilisateurs lambda aient accès à sbin. |
il est pas dans le path mais on peut y accéder à la main (ou le mettre dans le patch bien entendu)
par exemple, which ifconfig ne renvoit rien
mais tu peux y accéder via /sbin/ifconfig
Marsh Posté le 08-01-2003 à 17:18:45
Salut,
on sait tous ou presque ce qu'il y a dans les dossier situés à la racine (si vous ne savez pas, je vous conseille de vous reporter au FHS : http://www.pathname.com/fhs/2.2/ )
mais quel est l'origine de leur nom ?
Pour certains, l'énigme est assez simple (je propose ici mon interprétation) :
/bin : binaries (programmes binaires)
/boot : contient le noyau et les infos de boot
/dev : device files
/home : de home (chez soi) en anglais
/lib : les bibliothèques nécessaires (library en anglais)
/mnt : les points de montage par défaut (mount)
/root : le dossier du root
/tmp : les fichiers temporaires
pour d'autres c'est déjà un peu plus complexe mais encore compréhensible :
/sbin : binaires systeme (ou securisé puisque normalement uniquement pour le root ?), encore que je trouve que ls est un binaire système...
/var : les données variables + les caches des systèmes de paquetages , un peu bizarre parce que de prime abord, il semble redondant avec /tmp bien qu'en fait il traite des données différentes et donc ne l'est pas.
et alors, il y en a, on se demande d'où sortent les noms :
/etc : Editable Text Configuration mais cela semble être une signification inventé après la création pour faire sérieux et éviter de rappeler et caetera (qui serait la signification initiale)
/usr : Unix System Resource
/opt : les programmes commerciaux (optional ?)
/proc : probablement process (/proc contient les infos sur tout les process en cours) UPDATE
/sys : système (uniquement pour les noyaux 2.6) ? UPDATE
les noms de dossiers spéciaux :
le .d (de xinetd.d ; init.d etc) = directory
le rc (de rc5.d par ex) : resource configuration
Je pose donc la question :
Mais d'où viennent t'il ?
en espérant que vous saurez, A+
Message édité par Mjules le 21-04-2005 à 22:59:33
---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. | Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.