Origine des noms des dossiers systèmes

Origine des noms des dossiers systèmes - Débats - Linux et OS Alternatifs

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.
Reply

Marsh Posté le 08-01-2003 à 17:18:45   

Reply

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 ...  :??:

Reply

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


Message édité par Mjules le 08-01-2003 à 17:32:54

---------------
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.
Reply

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à ?
 
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


 
peut etre pour daemon  :??:  comme httpd, sshd, dhcpd etc...


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 08-01-2003 à 19:35:40    

.d pour directory
 
rc = resource ?

Reply

Marsh Posté le 08-01-2003 à 19:49:45    

le s de sbin, c'est peut-être le s de super-utilisateur non ?

Reply

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

Reply

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
 
FHS = file hierarchy standart , ca va avec la lsb  

Euh, t'as vu que c'est le lien que je donne à la 5° ligne du premier topic ?


---------------
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.
Reply

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).

Reply

Marsh Posté le 09-01-2003 à 10:38:44    

minusplus a écrit :

.d pour directory
 
rc = resource ?

.d c pas daemon ?  :??:

Reply

Marsh Posté le 09-01-2003 à 10:38:44   

Reply

Marsh 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 ?

Reply

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).
pkoi daemon ? vois pas le rapport ?

heu ché pas suis nul, xinit.d ya des daemon dedans enfin voila [:rougit] patapai ! [:tapai]

Reply

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 [:rougit] patapai ! [:tapai]

:??: dans xinit.d ? c'est où ça ? dans /etc/ ? ça m'étonnerai qu'il y ait des démons là dedans mais bon.. :D

Reply

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.. :D

oups, xinetd.d  :lol:


Message édité par Bitman13 le 09-01-2003 à 10:58:29
Reply

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.

Reply

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.
C'est unix system resource, en gros tous les logiciels.


 
et /etc ?

Reply

Marsh Posté le 09-01-2003 à 11:15:17    

je vote +1 pour le et-caetera ;)

Reply

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.
C'est unix system resource, en gros tous les logiciels.


 
Encore une fois, /home n'existait pas a l'origine je pense.

Reply

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.
C'est unix system resource, en gros tous les logiciels.

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)

Reply

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.
 
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)


 
Le dernier Linux pratique en parle. Tu peux faire une recherche "unix system resource" sur google et tu trouveras /usr

Reply

Marsh Posté le 09-01-2003 à 22:20:42    

zeb_ a écrit :


 
Le dernier Linux pratique en parle. Tu peux faire une recherche "unix system resource" sur google et tu trouveras /usr


 
 [:tracker]  
 
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

Reply

Marsh Posté le 09-01-2003 à 22:38:06    

sartene a écrit :


 
 [:tracker]  
 
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


 
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.

Reply

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)

Reply

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é :p
 
Si je me souviens bien ,les repertoires des utilisateurs sont dans /users/home ou qqchose comme ça :)

Reply

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...  :sweat:

Reply

Marsh Posté le 10-01-2003 à 14:32:50    

zeb_ a écrit :


 
Le dernier Linux pratique en parle. Tu peux faire une recherche "unix system resource" sur google et tu trouveras /usr

ah ben oué tiens, désolé, je savais pas ! :D

Reply

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+  :hello:


---------------
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.
Reply

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 :p
 
sinon, rc c'est pas resource control ou qqchose dans le genre ?

Reply

Marsh Posté le 13-01-2003 à 11:49:53    

sbin
 
g tjrs compris ça comme "binaire secondaires" > pas indispensables au fonctionnement du système.
 
:??:

Reply

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

Reply

Marsh Posté le 13-01-2003 à 11:59:51    

e_esprit a écrit :

et /sbin/mount ? c'est pas indispensable a ton système ???
 
Pour moi : sbin => binaires du sysadmin


 
fo croire ke non puiske chez moi il est pas dans ce dossier :D (g une mandrake)
 
mount est dans le /bin.
 
Dans sbin g rien de vital.


Message édité par mober le 13-01-2003 à 12:00:54
Reply

Marsh Posté le 13-01-2003 à 12:03:44    

mober a écrit :


Dans sbin g rien de vital.


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


---------------
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.
Reply

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 :D

Reply

Marsh Posté le 13-01-2003 à 12:16:19    

Mjules 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


 
 
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.
 

Reply

Marsh Posté le 17-01-2003 à 10:21:19    

mober 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.
 
 


 
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.

Reply

Marsh Posté le 17-01-2003 à 11:08:34    

sartene 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.


 
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 [:wam]
 
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 :heink: (à 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
 
[:alph-one]
 
 

Reply

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...

Reply

Marsh Posté le 17-01-2003 à 12:32:37    

Sous debian, je ne crois pas que les utilisateurs lambda aient accès à sbin.

Reply

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.


---------------
A Plus Donc...  [:jls]
Reply

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

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed