Administration Systeme Unix
Administration Systeme Unix
Administration Systeme Unix
c 1992, 1993, 1994, 1995, 1996 by Thierry Besancon, Pierre David and
This paper is Copyright
Joel Marchand.
Permission is hereby granted to give away free copies electronically. You may distribute, transfer,
or spread this paper electronically. You may not pretend that you wrote it. This copyright notice
must be maintained in any copy made. If you wish to reprint the whole or any part of this paper
in any other medium excluding electronic medium, please ask the authors for permission.
Special thanks to all my partners in crime. . .
Please recycle.
A propos de ce manuel.
A propos de ce manuel.
Introduction.
Ce document est un recueil de savoir-faire de plusieurs personnes en matiere d'administration
systeme de stations de travail sous UNIX. Ce document se veut relativement pratique, donnant
quand cela est possible des reponses a des problemes concrets ou a defaut des pointeurs sur des
solutions possibles, des ouvrages a consulter, des personnes a contacter. . . Les exemples que nous
donnerons sont tous tires de notre pratique et pour la plupart sont encore en service.
Le public vise est celui des personnes ayant un minimum de connaissances en administration
systeme UNIX. Nous ne reviendrons pas sur les commandes UNIX du niveau de l'utilisateur moyen,
nous n'expliquerons pas comment realiser une sauvegarde de disque ou comment calculer la place
disque occupee par un utilisateur ; tout cela est suppose connu. Nous ne nous adressons pas non
plus a des administrateurs de grands sites qui ont des besoins dierents et egalement des moyens
nanciers, materiels autres que les n^otres.
Nos methodes tiennent un peu de l'artisanat. Actuellement, on distingue deux methodes pour
faire de l'administration systeme :
, utiliser le logiciel d'administration systeme du constructeur (sam sur HP-UX, smit sur AIX. . .) ;
, faire les choses a la main.
Ce que nous allons vous decrire tient plus de la seconde methode ; m^eme si la progression fulgurante d'UNIX ces dernieres annees a conduit les constructeurs a faciliter la vie de l'administrateur
systeme en mettant a sa disposition des outils d'administration conviviaux, ces outils ne doivent
pas masquer la realite : l'administration d'un systeme UNIX n'est pas comparable a l'administration (la non-administration ?) d'un simple micro-ordinateur. En eet, les problemes poses par un
systeme complexe d'une part, et par le partage des ressources entre tous les utilisateurs d'autre
part, font qu'une certaine part d'expertise a toujours ete necessaire, m^eme si le bon sens reste le
principal atout du bon administrateur systeme. Acquerir ce bon sens et cette expertise ne peut se
faire a notre go^ut en utilisant ces outils conviviaux : ils sont trop speciques, trop partiels, trop
luxueux (interface graphique, sous{menus a rallonge etc.), trop bo^te noire, pire trop bugges. . . pour
que l'on puisse les utiliser dans la vie de tous les jours de l'administrateur. De plus, les techniques
evoluant, les systemes changeant, seules les bases et l'experience vous eviteront d'^etre demode trop
rapidement.
Comme il est stipule dans de nombreux logiciels du domaine public, ce document vous est fourni
l'etat". Nous ne serions ^etre tenus responsables des deg^ats qu'occasionnerait son utilisation. . .
Prenez toujours la peine de verier votre documentation, de vous renseigner et de faire des sauvegardes convenables avant de commencer une manipulation. Pour certaines choses, nous n'avons
donne que les informations trouvees dans la documentation mais qui nous ont paru justes et logiques. Un vieil adage conseille egalement de ne jamais proceder a des modications du systeme
une veille de week{end ou de conges. . .
"en
Un dernier mot : il n'y a rien de magique dans ce que vous trouverez dans ce manuel. Tout n'est
que le resultat d'heures passees a lire de la documentation, a tester des congurations, a compiler
des logiciels. . .
Conventions utilisees.
Nous essayerons de suivre les conventions suivantes dans les exemples donnes au cours de ce
document :
, La syntaxe utilisee pour les references a des logiciels ou a des documentations disponibles est
la syntaxe de la RFC 1738 (cf [Request For Comments (RFC)], page 7).
, Lorsque l'on ne donne qu'une partie d'un chier, on ache la partie utile precedee et suivie de
[...] comme dans :
[...]
gnu:x:1001:1000:GNU software:/usr/local/gnu:/bin/noshell
tex:x:1011:1000:TeX software:/usr/local/lib/tex:/bin/noshell
[...]
, Il sera donne plusieurs fois des commandes UNIX a executer pour accomplir telle ou telle
action. Ces commandes seront presentees sous plusieurs formes possibles :
1. soit la commande est precedee du signe % ou de # ; il s'agit la du prompt par defaut du
shell par defaut. . .
2. soit la commande est precedee d'un prompt du genre :
excalibur:[281]:</excalibur/homes/besancon>
hfooi.hdomainei
Les signes h et i ne sont la que pour determiner une information a remplacer. Ainsi, hdomainei
indique qu'il vous faut entrer le nom de votre domaine. En aucun cas, il ne faudra considerer
les chevrons comme faisant partie de la commande.
, Nous donnerons plusieurs fois des extraits de chiers /etc/passwd. Il est inutile de vouloir
dechirer les cha^nes chirees des mots de passe qui s'y trouveraient car j'ai pris la precaution
de les modier.
A propos de ce manuel.
Copyright.
c 1992, 1993, 1994, 1995, 1996 by Thierry Besancon, Pierre David and
This paper is Copyright
Joel Marchand.
Permission is hereby granted to give away free copies electronically. You may distribute, transfer,
or spread this paper electronically. You may not pretend that you wrote it. This copyright notice
must be maintained in any copy made. If you wish to reprint the whole or any part of this paper
in any other medium excluding electronic medium, please ask the authors for permission.
Disclaimer.
The information within this paper may change without notice. Use of this information constitutes
acceptance for use in an AS IS condition. There are NO warranties with regard to this information.
In no event shall the authors be liable for any damages whatsoever arising out of or in connection
with the use or spread of this information. Any use of this information is at the user's own risk.
Remerciements.
Nous remercions les personnes et les organismes suivants pour leur aide materielle et leurs
facilites a la realisation de ce document:
,
,
,
,
,
,
,
,
,
,
,
,
Nous remercions aussi tous ceux qui ont notablement contribue a l'amelioration de ce document ou
a lui donner matiere a traiter :
, Babafou et Manu, babafous promotion 1994 (the last ones ?) de l'Ecole Nationale Superieure
,
,
,
,
,
,
,
,
,
,
,
,
,
,
de Techniques Avancees ;
Jannick TAILLANDIER et Joel NICOLAS de la RATP ;
Rene COUGNENC ;
Pierre BEYSSAC ;
Laurent GHYS de l'IRCAM ;
Laurent AMON de la Caisse des Dep^ots et Consignations ;
Alain DURAND de l'IMAG ;
Marc BAUDOIN, Ollivier ROBERT et Herve SCHAUER de Herve Schauer Consultants.
Pascale RICH{HENNION du Centre de Mathematiques Appliquees de l'Ecole Polytechnique ;
Jean-Philippe GIRARD ;
Bernard GAULLE, Marie{Noelle DAUPHIN, Elisabeth DEQUAIRE et Florence HAMET de
l'Institut du Developpement et des Ressources en Informatique Scientique ;
Jean CHASSAING de la SERIAT ;
Michel BEHEREGARAY du Centre Informatique de l'Universite de Pau et des Pays de l'Adou
([email protected]) ;
Thomas NETTER ;
Ariane GERMA.
A propos de ce manuel.
Les presents le 31 mars 1996 a 2h30 du m^atin se reconna^tront sur la photographie qui fut prise
a ce moment la :
Dernier mot :
Newsgroup: news.software.readers
From: Tom Christiansen <[email protected]>
Subject: ENOBRAIN: Driving out the Visigoths
Date: 14 Jun 1995 11:55:35 GMT
It's still 5 in the morning, and I haven't had coee { perhaps I haven't even awoken yet { and the
following eureka just occurred to me:
You guys are all committing a grave error in trying to make Usenet software easier to use by idiots. If
even idiots can post, idiots will. We should return to that mythic world in which intelligence, education,
and technical expertise were a sucient impediment to participation in the net that we didn't have
to put up with terabytes of bumbling drivel by the computationally challenged. Under the the current
situation, every drooling peeeceee cretin and their dog can (and sadly do) post, but they think USENET
is merely some big BBS system for their toy computers with operating systems from Hell. The Romans
screwed up: send the barbarians back until they can learn to wash themselves.
ftp://ds.internic.net/rfc/
ftp://ftp.ibp.fr/pub/rfc/rfc
ftp://ftp.univ-lyon1.fr/pub/rfc/
ftp://ftp.inria.fr/rfc/
,
,
,
http://pubweb.nexor.co.uk/public/rfc/index/rfc.html
wais://wais.cnam.fr/RFC
http://www.cis.ohio-state.edu/hypertext/information/rfc.html
http://web.cnam.fr/Network/TCP-IP
On peut recevoir par courrier electronique les annonces de parution de nouvelles RFCs : envoyer
un mail a [email protected]
ftp://rtfm.mit.edu/pub/usenet-by-group
ftp://ftp.univ-lyon1.fr/pub/faq
ftp://ftp.uu.net/usenet/news.answer
ftp://lth.se/archive2/netnews/news.answer
ftp://unix.hensa.ac.uk/pub/uunet/usenet/news.answer
http://www.pasteur.fr/other/computer/FAQ/
Systemes abordes.
Au l de l'ouvrage, nous decrirons plusieurs systemes. Ce sont ceux a notre disposition, sur nos
machines ou sur des machines auxquelles on nous pr^ete acces. Les systemes faisant l'objet de mises
a jour incessantes, il se peut que certaines versions ne fassent plus l'objet d'exemples au fur et
a mesure de l'existence de ce document (par exemple, le systeme HP-UX 8.07 n'est plus detaille
depuis janvier 1995).
AIX versions 3.2.x et 4.1.x
Les machines sur lesquelles sont utilises ces versions de systemes sont exclusivement
des IBM RS6000 (a base de processeurs POWER et POWER2).
Newsgroups USENET consacres
FAQ
comp.unix.aix
ftp://ftp.univ-lyon1.fr/pub/faq/by-newsgroup/comp/comp.unix.aix/*
Mailing-lists consacres
Se reporter a la FAQ.
Disponibilite de patches constructeur
Se reporter a la FAQ.
Egalement :
ftp://ibminet.awdpa.ibm.com/pub/ptf
ftp://aix.boulder.ibm.com/ship.ptfs/*
ftp://aix.boulder.ibm.com/fixdist_client_code/fd.tar.Z
FAQ
ftp://ftp.univ-lyon1.fr/pub/faq/by-newsgroup/comp/comp.unix.osf.osf1/*
Mailing-lists consacres
Se reporter a la FAQ.
Disponibilite de patches constructeur
Se reporter a la FAQ.
Egalement :
ftp://gatekeeper.dec.coms/pub/DEC/
http://www.digital.com
ftp://gatekeeper.dec.coms/pub/DEC/
FAQ
Se reporter a la m^eme section sous DEC OSF1.
Mailing-lists consacres
Se reporter a la m^eme section sous DEC OSF1.
Disponibilite de patches constructeur
Se reporter a la m^eme section sous DEC OSF1.
Disponibilite de documentations constructeur
Se reporter a la m^eme section sous DEC OSF1.
FreeBSD versions 2.0.5 et 2.1
La machine sur laquelle ce systeme est installe est de type Pentium 133 Mhz, 128 Mo
de ram, 1 Go de disque SCSI.
A noter que les sources de ce systeme sont disponibles de facon publique. Des informations sur ce systeme sont disponibles via l'URL http://www.freebsd.org/. On trouve
ainsi que les sources sont recuperables via ftp://ftp.FreeBSD.org/pub/FreeBSD mais
on preferera l'URL ftp://ftp.ibp.fr/FreeBSD.
Newsgroups USENET consacres
comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc
FAQ
ftp://ftp.ibp.fr/pub/FreeBSD/docs/freebsd-faq.ascii
10
Mailing-lists consacres
A noter que les newsgroups USENET consacres a FreeBSD ne sont pas tres
actifs au contraire des mailing-lists.
Se reporter a la FAQ.
Disponibilite de patches constructeur
Se reporter aux sources disponibles.
Disponibilite de documentations constructeur
http://www.freebsd.org/
FAQ
ftp://ftp.univ-lyon1.fr/pub/faq/by-newsgroup/comp/comp.sys.hp.
hpux/hp-hpux-faq
Mailing-lists consacres
Se reporter a la FAQ.
Disponibilite de patches constructeur
Se reporter a la FAQ.
Egalement :
http://support.mayfield.hp.com
ftp://ftp.hpl.hp.com//pub/wilkes
FAQ
11
ftp://ftp.univlyon1.fr/pub/faq/by-newsgroup/comp/comp.sys.sgi.admin/sgi-faqpointer
Mailing-lists consacres
Se reporter a la FAQ.
Disponibilite de patches constructeur
ftp.sgi.com:"ftp/sgi/
exxilon.xx.rmit.EDU.AU:/pub/
Princeton.EDU:/pub/sgi.fixes/patches/
ftp://ftp.sgi.com/support
La machine sur laquelle ce systeme est installe est de type Pentium 133 Mhz, 128 Mo
de ram, 1 Go de disque IDE.
A noter que les sources de ce systeme sont disponibles. On trouve les sources de la
facon la plus simple a l'URL ftp://ftp.ibp.fr/ (parce qu'autant dire que c'est
la jungle entre les sites d'origine ftp.funet.fi, tsx-11.mit.edu, sunsite.unc.edu,
ftp.cdrom.com. . . ; le lecteur est pri
e d'envoyer ses remerciements a [email protected]
qui assure la gestion de ftp.ibp.fr).
Newsgroups USENET consacres
comp.os.linux
comp.os.linux.admin
comp.os.linux.advocacy
comp.os.linux.announce
comp.os.linux.answers
comp.os.linux.development
comp.os.linux.development.apps
comp.os.linux.development.system
FAQ
NetBSD 1.0
ftp://ftp.univ-lyon1.fr/pub/faq/by-newsgroup/comp/comp.os.linux.
announce/linux-meta-faq
Mailing-lists consacres
Se reporter a la FAQ.
Disponibilite de patches constructeur
Se reporter aux sources du systeme.
Disponibilite de documentations constructeur
En fait, pour Linux, nous ne dirons quasiment rien puisqu'un ouvrage
couvre deja pas mal de points. Il s'agit du Guide du ROOTard, dont l'URL
de reference est http://www.emi.u-bordeaux.fr/"dumas/linux/Guide
(version PostScript ftp://ftp.ibp.fr/linux/french/Guide.ps.gz).
La machine sur laquelle ce systeme est installe est un SAGER NP9600, de type Pentium
90 Mhz, 24 Mo de ram, 1.3 Go de disque IDE.
A noter que les sources de ce systeme sont disponibles. Des informations sur ce systeme
sont disponibles via l'URL http://www.netbsd.org/. On trouve ainsi que les sources
sont recuperables via ftp://ftp.NetBSD.org/pub/NetBSD mais on preferera l'URL
ftp://ftp.ibp.fr/NetBSD.
Newsgroups USENET consacres
comp.unix.bsd.netbsd.announce
comp.unix.bsd.netbsd.misc
12
FAQ
http://www.netbsd.org
Mailing-lists consacres
Se reporter a la FAQ.
Disponibilite de patches constructeur
Se reporter aux sources du systeme.
Disponibilite de documentations constructeur
http://www.netbsd.org
SunOS 4.1.x
Les machines sur lesquelles sont utilisees ces versions de systemes sont de type Sparc
(gamme sun4c et sun4m principalement). La derniere version du systeme sous lequel
les modeles de type sun3 peuvent fonctionner est le systeme SunOS 4.1.1.
Newsgroups USENET consacres
comp.sys.sun
comp.sys.sun.admin
comp.sys.sun.announce
comp.sys.sun.apps
comp.sys.sun.hardware
comp.sys.sun.managers
comp.sys.sun.misc
comp.sys.sun.wanted
FAQ
ftp://ftp.univ-lyon1.fr/pub/faq/by-newsgroup/comp/comp.sys.sun.admin/*
Mailing-lists consacres
Se reporter a la FAQ.
Disponibilite de patches constructeur
Se reporter a la FAQ.
Egalement :
ftp://thor.ece.uc.edu/pub/sun-faq/
ftp://ugle.unit.no/pub/unix/sun-fixes/
http://www.sun.com
ftp.uwtc.washington.edu:/pub/FAQs/Sun/WhitePapers/
sunsite.unc.edu:/pub/sun-info/white-papers/
ftp.prz.tu-berlin.de:/pub/docs/SunPapers/
Solaris 2.x La machine sur laquelle ce systeme est installe est de type sun4c.
On passera sous silence l'incarnation de Solaris 2.x sur processeur INTEL.
Newsgroups USENET consacres
comp.unix.solaris
FAQ
Cf la m^eme rubrique sous SunOS 4.1.x.
Mailing-lists consacres
Cf la m^eme rubrique sous SunOS 4.1.x.
Disponibilite de patches constructeur
Cf la m^eme rubrique sous SunOS 4.1.x.
Disponibilite de documentations constructeur
Cf la m^eme rubrique sous SunOS 4.1.x.
13
IBM (10.3%)
Hewlett-Packard (19.5%)
Hewlett-Packard (16.3%)
IBM (11.8%)
Autres (39.4%)
Autres (45.7%)
1992
1993
Sun Microsystems (36.2%)
Hewlett-Packard (19.8%)
Autres (14.5%)
IBM (12.9%)
Silicon Graphics (5.9%)
Digital Equipment (10.7%)
1994
14
15
On y trouvera des indications sur ce qui est active au demarrage d'une station.
Dans la pratique, on utilisera ce chapitre une fois que la station aura boote pour le
premiere fois et que l'on aura congure les disques etc.
chapitre 3, page 39 : Conguration bas niveau de disques durs.
chapitre 4, page 59 : Conguration de lesystems classiques.
chapitre 7, page 89 : Conguration de la memoire virtuelle.
C'est lorsque la station vient d'arriver qu'il est le moins genant de congurer ses disques
car personne ne les utilise encore si bien qu'on peut s'essayer a toutes sortes de tests.
La conguration des disques comporte trois aspects :
1. formattage physique et partitionnement ;
2. installation de lesystems ;
3. conguration de la memoire virtuelle.
chapitre 8, page 101 : Reseau Ethernet.
Ce chapitre decrit le minimum de theorie a conna^tre pour connecter physiquement une
station a un reseau Ethernet.
Des aspects logiciels lies a Ethernet sont abordes.
chapitre 10, page 121 : Conguration d'Internet Protocol (IP).
Ce chapitre aborde les aspects logiciels de la mise en reseau d'une station de travail.
chapitre 11, page 145 : Conguration du Domain Name Service (DNS).
Ce chapitre continue le precedent en y decrivant le mecanisme logiciel permettant a
une station de rentrer en connexion avec n'importe quelle autre station du monde.
chapitre 12, page 175 : Gestion du temps et des horloges.
Ce chapitre decrit comment on peut synchroniser l'horloge d'une station sur l'heure
universelle, garantissant ainsi le bon fonctionnement des services qui auront besoin
d'une horloge.
chapitre 13, page 187 : Conguration du Network Information Service (NIS).
Ce chapitre decrit le mecanisme permettant d'assurer une redistribution de certains
contenus de chiers, comme les mots de passe.
chapitre 14, page 205 : Conguration du Network File System (NFS).
Ce chapitre decrit le mecanisme permettant d'utiliser le contenu d'un disque dur depuis
une station autre que celle sur laquelle il est physiquement connecte.
chapitre 15, page 229 : Aspects de securite UNIX.
Une fois les principaux services d'une station congures, quelques aspects de securite
seront abordes.
chapitre 16, page 271 : Librairies dynamiques.
Ce chapitre aborde divers points (notamment de securite) concernant les librairies
dynamiques que de plus en plus de systemes utilisent.
16
La suite du manuel decrit des services a ajouter pour rendre la station conviviale pour les
utilisateurs :
17
18
19
20
SAGE, as the professional organization for systems administrators, formed the `sage-jobs' working group to address these problems. Its goals include the creation of a set of appropriate job
descriptions for systems administrators and promotion of their adoption by organizations that
employ systems administrators.
Below are the current job description templates that the working group has produced. We
have created an additional list of check-o items. The templates are intended to describe the core
attributes of systems administrators at various levels of job performance, while the check-o list is
intended to augment the core descriptions. In particular the check-o list is intended to address sitespecic needs, or special areas of expertise that a systems administrator may have. Job descriptions
for more experienced systems administrators or more senior positions will typically include more
items from the check-o list.
As a SAGE member, we'd like to encourage your comments on the work to date. Please send
your input to the sage-jobs working group, [email protected], or to the Chair, Tina Darmohray, [email protected]. Feel free to join the working group as well by sending email to
[email protected], with the body of the message subscribe sage-jobs.
Tina Darmohray SAGE Jobs Working Group Chair [email protected]
Denitions
A "small site" has 1-10 computers, all running the same operating system, and 20 or fewer users.
(A computer used by only the administrator does not qualify as a site.)
A "midsized site" has up to 100 systems, running no more than 3 dierent operating systems,
and up to 100 users.
A "large site" has 100 or more computers, potentially running more than one operating system,
and 100 or more users.
The following are the core templates:
Novice
Required skills:
Has strong inter-personal and communication skills; is capable of explaining
simple procedures in writing or verbally, has good phone skills.
Is familiar with UNIX and its commands/utilities at a user level; can edit
les, use a a shell, nd users' home directories, navigate through the le
system, and use i/o redirection.
Is able to follow instructions well.
Required background:
2 years of college or equivalent post-high-school education or experience.
Desirable: A degree or certicate in computer science or a related eld.
Previous experience in customer support, computer operations, system administration or another related area. Motivated to advance in the profession.
Junior
21
Appropriate responsibilities:
Performs routine tasks under the direct supervision of a more experienced
system administrator.
Acts as a front-line interface to users, accepting trouble reports and dispatching them to appropriate system administrators.
Required skills:
Strong inter-personal and communication skills; capable of training users
in applications and UNIX fundamentals, and writing basic documentation.
High skill with of most UNIX commands/utilities. Familiarity with
most basic system administration tools and processes; for example, can
boot/shutdown a machine, add and remove user accounts, use backup
programs and fsck, maintain system database les (groups, hosts, aliases).
Fundamental understanding of a UNIX-based operating system; for
example, understands job control, soft and hard links, distinctions between the kernel and the shell.
Required background:
One to three years of system administration experience.
Desirable: A degree in computer science or a related eld.
Familiarity with networked/distributed computing environment concepts;
for example, can use the route command, add a workstation to a network,
and mount remote lesystems.
Ability to write scripts in some administrative language (Tk, Perl, a shell).
Programming experience in any applicable language.
Appropriate responsibilities:
Administers a small site alone or assists in the administration of a larger
system. Works under the general supervision of a system administrator or
computer systems manager.
Intermediate/Advanced:
Required skills:
Strong inter-personal and communication skills; capable of writing purchase justications, training users in complex topics, making presentations
to an internal audience, and interacting positively with upper management.
Independent problem solving; self-direction.
Is comfortable with most aspects of UNIX systems administration; for
example, conguration of mail systems, system installation and conguration, printing systems, fundamentals of security, installing third-party
software.
A solid understanding of a UNIX-based operating system; understands paging and swapping, inter-process communication, devices and what device
drivers do, le system concepts ("inode", "superblock").
Familiarity with fundamental networking/distributed computing environment concepts; can congure NFS and NIS, can use nslookup or dig to
check information in the DNS, understands basic routing concepts.
Ability to write scripts in some administrative language (Tk, Perl, a shell).
Ability to do minimal debugging and modication of C programs.
Required background:
Three to ve years systems administration experience.
22
Senior:
These are things you might want to add to the base job descriptions as either required or
desirable.
Local Environment Experience
Experience with the specic operating systems, applications, or programming languages
in use at the site (for example SunOS, AIX, CAE/CAD software, FrameMaker, Mathematica, Fortran, Ada). Experience with the work done by the users at the site.
23
Heterogeneity Experience
Experience with more than one UNIX-based operating system. Experience with sites
running more than one UNIX-based operating system. Familiarity with both System
V and BSD-based UNIX operating systems. Experience with non-UNIX operating systems (for example, MS-DOS, Macintosh OS, or VMS). Experience with internetworking
UNIX and other operating systems (MS-DOS, Macintosh OS, VMS).
Programming Skills
Extensive programming experience in an administrative language (Tk, Perl, a shell).
Extensive programming experience in any applicable language.
Networking Skills
Experience conguring network le systems (for example, NFS, RFS, or AFS). Experience with network le synchronization schemes (for example, rdist and track). Experience conguring automounters. Experience conguring license managers. Experience
conguring NIS/NIS+. Experience with TCP/IP networking protocols (ability to debug
and program at the network level). Experience with non-TCP/IP networking protocols (for example, OSI, Chaosnet, DECnet, Appletalk, Novell Netware, Banyan Vines).
Experience with high-speed networking (for example, FDDI, ATM, or SONET). Experience with complex TCP/IP networks (networks that contain routers). Experience
with highly complex TCP/IP networks (networks that contain multiple routers and
multiple media). Experience conguring and maintaining routers. Experience maintaining a site-wide modem pool/terminal servers. Experience with X/X terminals. Experience with dial-up networking (for example, SLIP, PPP, or UUCP). Experience at a
site that is connected to the Internet. Experience installing/conguring DNS/BIND.
Experience installing/administering Usenet news. Experience as postmaster of a site
with external connections.
Security Experience with network security (for example, building rewalls, deploying authentication systems, or applying cryptography to network applications). Experience with
classied computing. Experience with multi-level classied environments. Experience
with host security (for example, passwords, uids/gids, le permissions, le system integrity, use of security packages).
Site Specialities
Experience at sites with over 1,000 computers, over 1,000 users, or over a terabyte
of disk space. Experience with supercomputers. Experience coordinating multiple independent computer facilities (for example, working for the central group at a large
company or university). Experience with a site with 100% uptime requirement. Experience developing/implementing a site disaster recovery plan. Experience with a site
requiring charge-back accounting.
Documentation
Background in technical publications, documentation, or desktop publishing.
Databases Experience using relational databases. Experience using a database query language. Experience programming in a database query language. Previous experience as a database
administrator.
Hardware Experience installing and maintaining the network cabling in use at the site. Experience installing boards and memory into systems. Experience with SCSI device setup
and installation. Experience installing/conguring peripherals (for example, disks, modems, printers, or data acquisition devices). Experience with board-level diagnosis and
repair of computer systems. Experience with component-level diagnosis and repair of
computer system.
Management
Budget responsibility. Experience in writing personnel reviews, and ranking processes.
Experience in interviewing/hiring.
24
25
,
,
,
,
26
Systeme
AIX 3.2.x et 4.1.x
DEC ULTRIX 4.x
HP-UX 8.07, 9.0x et 10.0x
SunOS 4.1.x
Solaris 2.x
Methode de Protection
Principe de cle de verrouillage du mode de boot
Protection par mot de passe possible
Mode secure activable apres ^etre passe en boot administration
mode
protection par mot de passe dans une EEPROM (cf. man 8 eeprom
et les champs secure, password)
protection par mot de passe dans une EEPROM (cf. man 8 eeprom
et les champs secure, password)
Le mieux pouvant ^etre l'ennemi du bien, ces protections sont a utiliser avec precaution, notamment les methodes de protection avec mots de passe. Sur Sun, perdriez-vous le mot de passe de
l'acces au moniteur que vous ne pourriez plus booter du tout, ce qui vous obligerait a un retour
usine de la station !
Voici comment booter en mono-utilisateur selon le systeme :
Systeme
AIX 3.2.x
AIX 4.1.x
DEC OSF1 1.x, 2.0 et 3.0
FreeBSD 2.0.5 et 2.1
HP-UX 8.07, 9.0x et 10.0x
SGI Indigo
Linux
NetBSD 1.0
SunOS 4.1.x
Solaris 2.x
27
Si le dispositif est un disque, le chargeur secondaire reside dans les secteurs de boot qui sont
donc tres importants. En cas d'eacement de ces secteurs, il faut les reconstruire. Selon le systeme,
cette operation est executable sans autres modications au disque.
Le chargeur secondaire ne constitue en aucune facon le systeme qui tournera ensuite. Il en
a cependant certaines connaissances, surtout la connaissance de la structure d'organisation du
disque UNIX, ce qui lui permet de trouver sur le disque l'emplacement de certains chiers et plus
particulierement du noyau UNIX. Ce noyau a divers noms selon les constructeurs (/vmunix pour la
plupart des UNIX de la famille BSD, /unix pour ceux de la famille System-V mais avec quelques
exceptions comme /hp-ux pour HP-UX 9.0x, /stand/vmunix pour HP-UX 10.01 par exemple).
On distingue deux philosophies concernant la construction du noyau :
l'approche minimaliste de System V
Un noyau tournant sur un systeme V ne conna^t que les peripheriques presents sur les
bus au moment ou le noyau a ete genere. L'ajout d'un peripherique necessite donc la
reconstruction d'un noyau pour voir le nouveau peripherique.
l'approche BSD
Le noyau par defaut est congure pour des peripheriques qui ne sont peut-^etre pas
disponibles sur la station ou le systeme tournera. L'ajout d'un peripherique a de bonnes
chances de se faire sans necessiter de reconstruire le noyau.
La reconstruction d'un noyau est dierente selon le systeme. Cf son manuel constructeur pour
ce point.
Arborescence ou chier
de conguration du noyau
Systeme
AIX 3.2.x
AIX 4.1.x
DEC OSF1 3.0
DEC ULTRIX 4.x
FreeBSD 2.0.5 et 2.1
HP-UX 9.0x
HP-UX 10.0x
IRIX 4.0.5
IRIX 5.2
Linux
NetBSD 1.0
SunOS 4.1.x
Solaris 2.x
Nom du noyau
???
/unix
/usr/lib/boot/
/unix
???
/usr/sys/conf/hsystemnamei
/usr/sys/conf/harchi/hsystemnamei
/sys/i386/conf/hsystemnamei
/etc/conf/dfile + /etc/master
/vmunix
/vmunix
/kernel
/hp-ux
/stand/build
/stand/vmunix
/usr/sysgen/system
/unix
/usr/var/sysgen
/unix
/usr/src/linux
/vmlinuz
/usr/src/sys/arch/
/usr/sys/
harchi/conf
harchi/conf
???
/netbsd
/vmunix
/kernel/genunix
28
la mise a feu du systeme UNIX en creant le procesus de numero 0 qui porte en general le nom de
swapper. Ce processus en engendre alors un deuxieme qui est init quel que soit l'UNIX (pour une
fois, ils sont d'accord sur cela), de numero 1.
Sur les systemes d'origine BSD, le processus 2 est special ; sa mission est d'assurer la gestion
des pages memoire du mecanisme de memoire virtuelle.
Le processus init a un r^ole tres important : c'est lui qui va faire passer le systeme de l'etat de
programme mono-utilisateur et mono-t^ache a l'etat multi-utilisateurs et multi-t^aches. Il determine
aussi la duree de vie du systeme : si init se termine, il entra^ne UNIX avec lui dans sa chute.
Suivant la famille d'UNIX a laquelle appartient votre UNIX, le systeme peut presenter dierents
niveaux de fonctionnement :
famille BSD
On a deux niveaux, le niveau single-user et le niveau multi-user (sans compter le niveau
ou le materiel est eteint).
famille System-V
De nombreux niveaux existent, en general numerotes de 0 a 6, avec deux valeurs en
plus (s et S) pour signaler le mode single-user. Par exemple, sous Solaris 2.x, on a :
SVR4 Run States
S Single-user (leaves lesystems mounted)
0
Power o
1
Single-user/System-admin (leaves only / mounted)
2
Multi-user, network disabled
3
Multi-user, network enabled
4
(not used)
5
PROM Monitor level
6
Halt & reboot to default state
Ces niveaux ont en general une signication qui est de la responsabilite de l'administrateur systeme bien que les signications des niveaux 0, 1, 2 6 et s sont souvent codees
en dur dans le systeme.
C'est le processus init qui fait passer d'un niveau a un autre, la plupart du temps automatiquement.
Dans le cas des UNIX System-V, le passage d'un run-level a un autre est contr^ole par le chier
/etc/inittab au format suivant :
label : niveaux : action : commande
C'est une simple simple cha^ne de caracteres servant en interne a init et qui permet
de designer facilement la ligne.
Ce champ designe les etats dans lesquels doit se trouver le systeme pour lancer la
commande donnee par le champ 4, de la facon designee par le champ 3. Si le champ
est vide, tous les niveaux possibles sont concernes par la commande.
C'est une commande UNIX a executer, aussi bien un shell-script qu'un binaire.
action
29
respawn
wait
once
boot
bootwait
off
initdefault
sysinit
Voici un exemple de chier inittab ; c'est celui d'un systeme HP-UX 9.0x :
thorgal:[43]:</etc>cat /etc/inittab
init:4:initdefault:
stty::sysinit:stty 9600 clocal icanon echo opost onlcr ienqak ixon icrnl ignpary
brc1::bootwait:/etc/bcheckrc </dev/console >/dev/console 2>&1
slib::bootwait:/etc/recoversl </dev/console >/dev/console 2>&1
brc2::bootwait:/etc/brc >/dev/console 2>&1
link::wait:/bin/sh -c "rm -f /dev/syscon; ln /dev/systty /dev/syscon" >/dev/console 2>&1
rc ::wait:/etc/rc </dev/console >/dev/console 2>&1
powf::powerwait:/etc/powerfail >/dev/console 2>&1
lp ::off:nohup sleep 999999999 </dev/lp & stty 9600 </dev/lp
halt:6:wait:/usr/lib/X11/ignition/shutdown.ksh
cons:012456:respawn:/etc/getty -h console console
vue :34:respawn:/etc/vuerc
# start VUE
parce que l'on peut entrer dans l'etat 4 puisque c'est le run-level par defaut comme precise par la
ligne :
init:4:initdefault:
Par defaut, l'installation HP ne lance pas le systeme de multifen^etrage ; il sut pour cela de
faire du run-level 3 ou 4 le run-level par defaut. Quand on installera une station HP, on prendra
donc soin de passer de init:2:initdefault: a init:4:initdefault: (si bien s^ur, on souhaite
disposer de leur chu systeme proprietaire de multi-fen^etrage).
30
Dans l'environnement System V, tout au moins sur les System V purs et durs, lorsque le systeme
entre dans le run-level hni, un shell-script de nom rchni (situe dans /etc ou /sbin selon les
systemes) est execute :
% cat /etc/inittab
[...]
is:3:initdefault:
ss:Ss:wait:/sbin/rc0 shutdown < /dev/console > /dev/console 2>&1
s0:0:wait:/sbin/rc0 off < /dev/console > /dev/console 2>&1
fs:23:wait:/sbin/bcheckrc < /dev/console > /dev/console 2>&1
update:23:wait:/sbin/update > /dev/console 2>&1
s2:23:wait:/sbin/rc2 < /dev/console > /dev/console 2>&1
s3:3:wait:/sbin/rc3 < /dev/console > /dev/console 2>&1
[...]
31
Pour simplier les choses, les scripts Shnnifoo et Khnnifoo sont en general des liens symboliques
vers un m^eme chier qui regroupe alors le lancement et l'arr^et du sous systeme de demons concerne.
Le squelette d'un tel script est le suivant :
#!/sbin/sh
# OSF/1 Release 1.0
# Start the cron deamon
PATH=/sbin:/usr/sbin:/usr/bin
export PATH
case "$1" in
'start')
set `who -r`
if [ $9 = "S" ]; then
rm -f /var/adm/cron/FIFO
if /usr/sbin/cron; then
echo "Cron service started"
else
echo "Unable to start cron service"
fi
fi
;;
'stop')
pid=`/bin/ps -e | grep cron | sed -e 's/^ *//' -e 's/ .*//' | head -1`
if [ "X$pid" != "X" ]
then
/bin/kill $pid
fi
;;
*)
echo "usage: $0 start|stop"
;;
esac
Non seulement, Shnnifoo et Khnnifoo sont-ils des liens symboliques sur un m^eme script en
pratique, mais ces scripts sont identiques quel que soit l'etat et on trouve donc dans les directo-
32
ries rc0.d, rc1.d,rc2.d. . . des liens symboliques vers un directory regroupant les divers scripts.
Traditionnellement ce directory s'appelle init.d. Sous DEC OSF/1 version 2.0, on a ainsi :
ensapb:[52]:</sbin>ls -l /sbin/rc0.d/*cron*
lrwxr-xr-x
1 root
10
14 May
ensapb:[53]:</sbin>ls -l /sbin/rc2.d/*cron*
lrwxr-xr-x
1 root
10
14 May
ensapb:[54]:</sbin>ls -l /sbin/rc3.d/*cron*
lrwxr-xr-x
1 root
10
14 May
33
faut savoir que, si l'on choisit l'initialisation a la BSD, il faut entrer a nouveau ces
renseignements dans /etc/rc.bsdnet, pour la raison simple que les renseignements
donnes via smit sont entres dans la base ODM, propre au systeme AIX et que cette
base n'a aucune raison d'^etre consulte par les trucs BSD. Si vous ne modiez pas
/etc/rc.bsdnet, votre station s'appelerait ainsi aoot.austin.ibm.com, hostname par
defaut dans /etc/rc.bsdnet.
La methode propre a AIX consulte le chier /etc/rc.net.
DEC OSF versions 1.x, 2.0 et 3.x.
Il s'agit d'une initialisation dans le plus pur style System-V.
Les chiers et directories impliques sont /etc/inittab, /sbin/rc[023], /sbin/rc[023].d
et /sbin/init.d.
On retrouve le classique /etc/inittab qui active des scripts de nom /sbin/rchnni
lancant des demons dans /sbin/rchnni.d.
DEC ULTRIX 4.x.
Il s'agit d'une initialisation classique a la BSD.
On ajoutera ses extensions dans /etc/rc.local.
FreeBSD versions 2.0.5 et 2.1
Il s'agit d'une initialisation classique a la BSD.
Le programme init consulte /etc/rc.
On ajoutera ses extensions dans le chier /etc/rc.local.
HP-UX versions 8.07 et 9.0x.
Il s'agit d'une initialisation hybride comme celle d'AIX ou init se sert du chier
/etc/inittab :
% cat /etc/inittab
init:4:initdefault:
stty::sysinit:stty 9600 clocal icanon echo opost onlcr ienqak ixon icrnl ignpary
brc1::bootwait:/etc/bcheckrc </dev/console >/dev/console 2>&1
slib::bootwait:/etc/recoversl </dev/console >/dev/console 2>&1
brc2::bootwait:/etc/brc >/dev/console 2>&1
rc ::wait:/etc/rc </dev/console >/dev/console 2>&1
powf::powerwait:/etc/powerfail >/dev/console 2>&1
lp ::off:nohup sleep 999999999 </dev/lp & stty 9600 </dev/lp
halt:6:wait:/usr/lib/X11/ignition/shutdown.ksh
cons:012456:respawn:/etc/getty -h console console
vue :34:respawn:/etc/vuerc
##
## Automount.
##
[Thierry Besancon, le 16 mars 1993]
##
if [ -x /etc/amd/amd-run ] ; then
echo "automounter:\c"
/etc/amd/amd-run
echo " amd started (sleeping for 10 seconds)"
sleep 10
fi
34
Une autre tactique permettant de ne plus editer /etc/rc et d'y faire une possible erreur
est d'inserer quelque chose comme :
if [ -f /etc.local/rc ]; then
sh /etc.local/rc
fi
1 root
1 root
root
root
/etc/rc
[...]
initialize()
{
# The following parameters may be modified for the specific
# needs of your local system.
##
## Sur les conseils de beig et de pda, je change le umask.
##
[[email protected], le 9 mars 1994]
##----umask 022
[...]
resservira dans
35
if [ "$SYSTEM_NAME" = "" ]
then
SHORT_SYSTEM_NAME=caferoya
SHORT_SYSTEM_NAME
SYSTEM_NAME=caferoyal.ens.fr
export SYSTEM_NAME
[...]
}
[...]
if [ ! -f /etc/rcflag ]
# Boot time invocation only
then
[...]
uname -S $SHORT_SYSTEM_NAME
uname -S $SYSTEM_NAME
hostname $SYSTEM_NAME
[...]
Avant on avait
Le nom sur 8 caracteres sert au niveau de la commande uname. Si l'on avait fait
uname -S $SYSTEM_NAME avec SYSTEM_NAME contenant un nom de plus de 8 caracteres, on aurait obtenu :
HP-UX unknown A.09.01 E 9000/735 2001083524 8-user license
Il faut egalement modier le chier /usr/adm/inetd.sec qui contient le nom tronque a 8 caracteres suite a l'installation.
HP-UX 10.01.
Il s'agit d'une initialisation dans un style tres System V.
Les chiers et directories impliques sont /etc/inittab, /sbin/rc, /sbin/rc[01234].d
et /sbin/init.d.
On retrouve le classique /etc/inittab qui active le script de nom /sbin/rc lancant
des demons dans /sbin/rchnni.d.
On ajoutera ses extensions en creant des scripts qui seront places dans /sbin/rchni.d,
avec un nom du type Shnnnifoo ou alors en n de chier /etc/inittab comme mentionne pour AIX.
IRIX 4.0.5 et 5.2.
Il s'agit d'un boot dans le plus pur style System-V.
Les chiers et directories impliques sont : /etc/inittab, /etc/rc[023] et /etc/rc[023].d/.
Pour ajouter ses propres extensions, on creera donc, dans le bon directory
/etc/rchni.d, un script aubl
e d'un numero hNNi le lancant au bon moment dans la
phase de boot.
Linux 1.2.x
Il s'agit d'une initialisation hybride comme celle d'AIX ou init consulte le chier
/etc/inittab :
% cat /etc/inittab
# System initialization (runs when system boots).
si:S:sysinit:/etc/rc.d/rc.S
# Script to run when going single user.
su:S:wait:/etc/rc.d/rc.K
36
NetBSD 1.0
Les scripts systeme d'initialisation impliques sont donc principalement dans /etc/rc.d.
On ajoutera ses extensions dans le chier /etc/rc.d/rc.local lance depuis
/etc/rc.d/rc.M.
2.3 Bibliographie.
Le lecteur pourra se reporter aux newsgroups consacres aux dierents systemes (cf [Generalites
sur les systemes abordes], page 7).
Le lecteur pourra se reporter aux articles suivants :
[AF93] leen Frisch. In the Beginning. RS/Magazine, 1993.
37
38
39
40
HP-UX 10.01
La commande bas niveau est /usr/bin/mediainit.
Attention : sur le modele K200, le bus SCSI interne est de type SCSI 2 alors que le bus
SCSI externe est de type SCSI Fast Wide.
IRIX version 4.0.5 et 5.2
La commande a utiliser est /usr/bin/fx -x. Elle procede par interrogation de la carte
contr^oleur du disque pour determiner le modele du disque et en deduire la methode
pour le formatter.
SunOS 4.1.x
La commande a utiliser est /usr/etc/format. Elle utilise le chier /etc/format.dat
qui contient les descriptions des modeles de disques.
Un chier format.dat plus complet est poste regulierement dans les news ; un URL
en est ftp://ra.mcs.anl.gov/sun-managers/format.dat.
L'utilisation intercative de format ne permet pas d'entrer des vitesses de rotation de
7200 RPM. Il faut ^etre en mode batch pour y arriver.
Solaris 2.x La commande est /usr/sbin/format.
En ce qui concerne les UNIX domaine public sur hardware PC (en l'occurence ici, FreeBSD
versions 2.0.5 et 2.1, Linux 1.2.x, NetBSD 1.0) , voici quelques renseignements (de la part de Rene
Cougnenc, [email protected]) :
Le formattage du disque est une operation bas niveau (les disques SCSI serieux sont
fournis tout formates et certies). En general, il faut envoyer une commande de formattage au contr^oleur SCSI, qui s'occupe de tout. C'est ce qui se passe sur SunOS, la
preuve en est que si l'on ne reconstruit pas un noyau ca se termine en time-out sur les
gros disques, puisque SunOS n'avait pas prevu que ca puisse durer aussi longtemps (cf
section 3.6.2 [Formattage de disques SCSI 9 Go sur SunOS], page 54).
Dans le monde du hardware PC, si dans le principe c'est la m^eme chose, je ne connais
pas d'OS capables d'envoyer cet ordre au contr^oleur (mais c'est s^urement faisable ou
ca existe peut-^etre), car ca se passe dieremment. . .
Le contr^oleur SCSI contient tout un "moniteur" en ROM, qui permet sa conguration
ainsi que toutes sortes d'operations sur les disques : formattage, verication, tests, relocation des bad blocs, etc. Pour acceder a ce programme, bienvenue dans le monde du
PC : selon le constructeur la methode est dierente. En general cela consiste a appuyer
sur une combinaison de touches magique, juste au moment du boot. Le systeme d'exploitation n'est donc pas concerne, le moniteur du contr^oleur prend la main directement
et ore en general un joli programme convivial.
Sur les cartes ADAPTEC recentes, il faut taper CTRL-A par exemple. Et sur les tres
recentes ils ont prevu le cas des claviers AZERTY qui ne sont pas encore pris en compte
en tant que tels par le PC a ce moment, si bien que le clavier AZERTY est vu comme
un clavier QWERTY ; c'est pourquoi CTRL-Q marche aussi. Sur les plus anciennes, il
faut lancer le programme "a la main", depuis le debogueur DOS. . . Si si. A condition
de retrouver l'adresse magique pour faire le JUMP. En general c'est dans la doc que
l'on vient juste de perdre :-)
Sur d'autres marques, ce moniteur en ROM n'existe pas forcement et il faut utiliser
un programme externe fourni par le constructeur, la plupart du temps uniquement en
binaire MS-DOS.
41
Ca parait complique, mais bon : on ne reformate jamais un disque SCSI quand on est
utilisateur de PC. D'ailleurs ils croient que c'est ce qu'ils font quand ils mettent un
le-system, la comande DOS equivalente a mkfs s'appelle. . . format :-))
Moralite : le formattage bas niveau de disques durs SCSI sur du hardware PC, passe rarement
par une commande UNIX mais est specique a la carte contr^oleur SCSI.
Bien s^ur, ce qui est valable pour le SCSI est aussi valable pour l'IDE. On passera par la carte
contr^oleur IDE pour (re)formatter un disque.
On notera l'aspect non pratique de la chose, puisque conduisant a un passage ou on ne tourne
aucun OS, rendant donc la machine indisponible pendant ce temps la.
42
The tidiest way to handle this problem is to divide the total block capacity of the drive by the number
of heads times the number of cylinders. Round o to a whole number of sectors/track, and thats what
you use. The only thing that matters is that the product of cylinders*heads*sectors/track must be less
than or equal to the total block capacity.
Fichier de description
/etc/disktab
/etc/disktab
/etc/disktab
/etc/disktab
mais obsolete
/etc/disktab
/etc/format.dat
/etc/format.dat
M^eme si le chier ne correspond pas a votre version de systeme, les informations qu'on y trouve
peuvent vous ^etre utiles. Le probleme ici est que l'on ne trouve dans ces chiers que les disques
supportes par les constructeurs.
3. Le chier constructeur de description de disques est rarement a jour. On trouve par contre sur
le reseau plusieurs tables de description a jour.
Systeme
DEC OSF1 3.x
DEC ULTRIX 4.x
HP-UX 9.0x
SunOS 4.1.x
Fichier de description
ftp://gatekeeper.dec.com/pub/DEC/ultrix-disktabs
ftp://gatekeeper.dec.com/pub/DEC/ultrix-disktabs
http://siihp.epfl.ch/HPUX/tools/disktab.html
ftp://ra.mcs.anl.gov/sun-managers/format.dat
M^eme si le chier ne correspond pas a votre version de systeme, les informations qu'on y
trouve peuvent vous ^etre utiles. Contrairement au cas precedent, ces chiers contiennent des
informations sur des disques non necessairement supportes par les constructeurs.
4. On peut demander la geometrie du disque a la personne qui la conna^t le mieux, a savoir le
disque lui-m^eme !
Pour cela, il faut pouvoir parler SCSI dans le texte, la manuvre consistant a envoyer la
commande SCSI de demande de description du disque (MODE SENSE de code 0x1a).
Parfois, certains utilitaires systeme font deja cela. Parfois il faut faire appel a un programme
tierce.
DEC OSF1 3.x
Utiliser la commande /sbin/scu.
43
# /sbin/scu
scu> set nexus bus 0 target 2 lun 0
scu> show capacity
Disk Capacity Information:
Maximum Capacity: 8410200
Block Length: 512
scu> show edt bus 0 target 2 lun 0 full
CAM Equipment Device Table (EDT) Information:
Inquiry Information:
SCSI Bus ID:
SCSI Target ID:
SCSI Target LUN:
Peripheral Device Type:
Peripheral Qualifier:
Device Type Qualifier:
Removable Media:
ANSI Version:
ECMA Version:
ISO Version:
Response Data Format:
Terminate I/O Process:
Asynchronous Notification:
Additional Length:
Soft Reset Support:
Command Queuing Support:
Linked Command Support:
Synchronous Data Transfers:
Support for 16 Bit Transfers:
Support for 32 Bit Transfers:
Relative Addressing Support:
Vendor Identification:
Product Identification:
Firmware Revision Level:
0
2
0
Direct Access
Peripheral Device Connected
0
No
SCSI-2 Compliant
0
0
ANSI SCSI-2
0
0
129
0
1
0
1
0
0
0
QUANTUM
XP34301
1051
HP-UX 9.0x
La commande /etc/diskinfo permet de conna^tre des informations sur la geometrie du disque :
# /etc/diskinfo -v /dev/rdsk/c201d1s0
SCSI describe of /dev/rdsk/c201d1s0:
vendor: HP
product id: C3725S
type: direct access
size: 2119418 Kbytes
bytes per sector: 512
rev level: 4299
blocks per disk: 4238836
ISO version: 0
ECMA version: 0
ANSI version: 2
removable media: no
response format: 2
HP-UX 10.01
La commande /etc/diskinfo permet de conna^tre des informations sur la geometrie du disque :
# /etc/diskinfo -v /dev/rdsk/c0t6d0
44
URL ftp://ftp.cdf.toronto.edu/pub/scsiping/scsiping-2.0.shar
45
2. Ayant cree des partitions, on peut exporter des partitions a d'autres machines sans avoir a
exporter la totalite du disque.
3. On peut declarer une partition comme etant consultable en lecture uniquement alors qu'une
autre partition peut ^etre declaree en lecture/ecriture.
Bien s^ur, on pestera toujours lorsqu'une partition dont on a besoin est pleine alors que les autres
partitions sont partiellement vides. . .
La creation de partitions est en general assez simple et ne comporte qu'un piege a eviter : faire
se recouvrir des partitions. Une partition est en eet determinee par un bloc de depart et un bloc
d'arrivee, la partition etant alors l'ensemble des blocs que cela determine. Certains constructeurs
permettent de creer des partitions qui se chevauchent sans demander conrmation a l'utilisateur.
Il faut donc se meer avec ces utilitaires la ; heureusement ils tendent a dispara^tre au prot de
logiciels ne demandant que la taille des partitions et non plus aussi les adresses bloc de debut de
la partition. En cas de recouvrement de deux partitions, de graves erreurs systeme surviennent t^ot
ou tard et obligent a la reinstallation des partitions avec vraisemblablement perte des informations
qui y auraient ete stockees (de toute maniere, un certain nombre d'informations sont detruites des
l'instant ou les erreurs apparaissent).
Le partitionnement de disques etant tout ce qu'il y a de plus non standard, chaque constructeur
a sa maniere d'operer. Tous, par contre, passent par une etape de marquage du disque dite "dep^ot
d'un label".
AIX versions 3.2.x et 4.1.x
Ces versions d'AIX utilisent LVM (Logical Volume Manager). On utilisera ce systeme
tres souple pour creer des partitions.
DEC OSF1 3.0
On depose un label et on decoupe le disque en partitions avec l'utilitaire /sbin/disklabel.
Il utilise le chier /etc/disktab qui contient les descriptions des modeles de disques
ainsi que la facon de les partitionner.
D'apres de nombreuses sources :
Digital UNIX and ULTRIX V4.0 and later can get the geometry information directly from the disk, without the need for a disktab entry. The driver
supplies a default partition table. For ULTRIX and disks larger than 2 GB,
the partition table will need to be customized.
On Digital UNIX to take advantage of the feature:
disklabel -wr /dev/rrz#c some-name
46
type
label
M2654Su1x1-2
u1_news
partition 1
size 1450000K
partition 2
size
max
Ajout d'un type puisque le type par defaut (calcule visiblement d'apres le product id) est trop
long (16 caracteres maximum).
label
lmd1_lmd2
partition 1
size 862725K
47
Ajout des param^etres du disque. On notera le nom de l'entree, une fois de plus calculee en fonction
du product id du disque.
[...]
et
# tail /etc/disktab
[...]
HP_MICROP-2217x1-2|HP_MICROP-2217x1-2_noreserve|HP_MICROP-2217x1-2_noswap:\
sdsadmin
newfs
:ns#95:nt#15:nc#2372:\
:s1#863232:b1#8192:f1#1024:\
:s2#861184:b2#8192:f2#1024:\
:se#512:rm#5400:
kbytes
300672
852879
850831
used
262956
9
9
# /etc/sdsadmin -d /dev/dsk/c201d4s0
sdsadmin: /dev/dsk/c201d4s0 is disk 1 of "lmd1_lmd2"
Destroy SDS configuration data for /dev/dsk/c201d4s0 (y/n)? y
HP-UX 10.01
Cette version d'HP-UX utilise LVM (Logical Volume Manager).
IRIX versions 4.0.5 et 5.2
La commande
/usr/bin/fx
repartition menu.
48
Fs
yes
yes
Start: sec
3864
35742
116886
3864
0
0
(cyl)
(
4)
( 37)
( 121)
(
4)
(
0)
(
0)
Size: sec
31878
81144
1193010
1306032
3864
1309896
(cyl)
( 33)
( 84)
(1235)
(1352)
(
4)
(1356)
Mount Directory
/
/usr
SunOS 4.1.x
La commande /usr/etc/format permet de partitionner un disque, entre autres choses.
Solaris 2.x La commande
choses.
/usr/sbin/format
Nous n'avons pas donne les informations a propos des systemes FreeBSD, Linux, NetBSD pour
la raison que ces systemes sourent de l'heritage du PC, si bien que la situation est compliquee.
Voici quelques renseignements (de la part de Rene Cougnenc, [email protected]) :
Sur les disques "Winchester", il a ete prevu par convention que les tous premiers 512
octets du disque etaient reserves a :
, Une table de partitions, qui contient 4 structures identiques permettant d'allouer
4 partitions dierentes, pour partager le disque entre plusieurs systemes d'exploitation, ou pour orir 4 zones de travail dierentes a un m^eme OS, au choix. De nos
jours, l'une de ces entrees peut en fait contenir un pointeur vers une autre table de
partitions, c'est ce qu'ils appellent "partition etendue". Mais bon, n'entrons pas
dans le detail.
, Un bout de code machine, situe juste avant cette table de partitions. La ROM
BIOS, au boot de la machine, lit ce code et lui passe le contr^ole : c'est le chargeur primaire de tout systeme d'exploitation. C'est la que chaque OS se bat pour
installer son bout de code a lui en ecrasant celui du copain :-)
Ceux fournis avec les versions d'UNIX (m^eme SCO !) sont assez gentils pour proposer le choix du systeme a lancer. MS-DOS, non. Il ne conna^t que lui :-)
/sbin/fdisk
FDISK
49
Begin
1
232
443
Start
1
232
443
End
231
442
1029
Blocks
236528
216064
601088
Id
83
83
83
System
Linux extfs
Linux extfs
Linux extfs
Les OS comme DOS, Windaube, OS/2, ont absolument besoin qu'un disque soit partitionne et qu'il y ait leur nombre magique dans une des tables de partition pour
fonctionner.
Linux, c'est un UNIX, hein. Il est parfaitement legal de coller un gros disque sur le bus
SCSI et de le considerer comme un tres gros chier et de mettre un tar dessus, hein :-)
La commande fdisk de Linux (certaines versions en tout cas) emet ce type d'avertissement parfois :
[root] renux:/ # /sbin/fdisk /dev/sdb
The number of cylinders for this disk is set to 1042.
This is larger than 1024, and may cause problems with some software.
Alors :
1. On s'en che.
2. Sauf dans un cas.
Les t^etes, les cylindres, tout ca, c'est bidon : un disque SCSI, il adresses des blocs, et
il se debrouille. C'est beau, propre et moderne. Mais il fut un temps ou le PC, c'est lui
qui faisait presque bouger les t^etes en avancant le moteur pas-a-pas et en comptant les
plateaux :-)
En souvenir de cette epoque, les programmes PC (a commencer par la ROM BIOS)
ne connaissent que des t^etes et des cylindres. Alors il faut leur en donner en p^ature, et
le contr^oleur leur en donne des bidons, pour que ces programmes sachent acceder au
disque.
Or, pour amorcer un systeme d'exploitation, il faut aller chercher le programme (chargeur secondaire ou OS complet, peu importe), le code machine correspondant. Qui se
trouve quelque part sur le disque, a partir en general du tout premier secteur de la
partition concernee, dite "active" (un octet ayant 0xFF comme nombre magique dans
la table de partitions).
50
Si cela correspond a un cylindre superieur a 1024 : c'est trop loin pour les dures limitations prehistoriques de l'IBM-PC, y'a pas assez de bits pour indiquer plus a ce
moment-la de l'etape de boot :-)
Il s'en suit que si cette partition doit ^etre "bootable", il est imperatif que le noyau se
trouve dans une partition dont le debut est sur un cylindre < 1024. Sinon ca ne bootera
pas, et il faudra se resigner a demarrer sur disquette.
C'est tout !
Pour tout le reste, on s'en tape, Linux est beaucoup plus intellignt que MS-DOS, on lui
donne un disque, il tape dans le contr^oleur disque et il l'exploite le plus naturellement
du monde. Il ne demande pas ce service au code prehistorique existant dans la ROMBIOS de l'IBM PC.
En pratique :
FreeBSD 2.1
La commande /sbin/fdisk sert a partitionner un disque dur en partitions FreeBSD,
DOS ou pour d'autres systemes.
La decoupe de la partition FreeBSD en partitions au sens UNIX, se fait par la commande /sbin/disklabel.
Linux 1.2.x
La commande /sbin/fdisk sert a partitionner un disque dur en partitions FreeBSD,
DOS ou pour d'autres systemes.
# /sbin/fdisk -l
Disk /dev/hda: 64 heads, 63 sectors, 528 cylinders
Units = cylinders of 4032 * 512 bytes
Device Boot
/dev/hda1
*
/dev/hda2
/dev/hda3
/dev/hda4
NetBSD 1.0
Begin
1
209
338
274
Start
1
209
338
274
End
208
273
528
337
Blocks
419296+
131040
385056
129024
Id
6
82
83
82
System
DOS 16-bit >=32M
Linux swap
Linux native
Linux swap
51
ne sera pas utilise au mieux ; par exemple, SunOS 4.1.x ne permet pas de creer des partitions de
plus de 2 Go. Le tableau suivant donne la taille maximale d'une partition residant sur un disque
dur, taille maximale obtenue sans utiliser d'artice logiciel comme un Logical Volume Manager ou
d'artice hardware comme un contr^oleur RAID. Cela veut donc dire que l'on ne considere que le
probleme de creer une partition aussi grande que possible sur un disque de 9 Go (capacite actuelle
pas encore tres courante mais deja disponible malgre tout).
Systeme
AIX 3.2.x
AIX 4.1.x
DEC OSF1 3.0
DEC ULTRIX 4.x
FreeBSD 2.0.5 et 2.1
HP-UX 9.01
HP-UX 9.0x (x > 1)
HP-UX 10.01
HP-UX 10.10
IRIX 4.0.5 et 5.2
Linux
NetBSD 1.0
SunOS 4.1.x
Solaris 2.x
52
Dans le m^eme genre de blague materielle que la precedente, les chires donnes ici sont valables
pour des disques de donnees. Il se peut en eet que cela ne soit pas valable pour des disques systeme
de boot, pour diverses raisons, comme les suivantes pour HP-UX :
>> I installed a Seagate ST15230N (4GigB) Hard disk in our 715/50 running HP-UX
9.05. It will not boot o of the disk. It gives an error: IPL not found.
Short answer:
You can't use S700 whole disk layout for a boot device that is > 2Gb (plus
a wee bit).
Longer answer:
The S700 PDC (boot rom) looks for a LIF header on the disk. This is
usually put there by mkboot(1m). The boot rom looks for the disk address
of the Initial Program Load (IPL) which is usually the ISL utility. The
boot rom performs a number of sanity checks to make sure that a device is
actually a boot volume{ this is why it generally won't show your data disks
as potential boot devices. One of the sanity checks that it performs is that
the disk address of the IPL must be "positive" when tested as a signed
int. Hence, no whole disk layouts larger than 2Gb. (HP does support some
devices that are up to 2Gb + a tad on 9.05, but on those devices the LIF
area and IPL end up below the 2Gb threshhold).
SCSI target id #3
SCSI target id #1
regular shoebox
SCSI target id #0
(tape at target id #4)
SCSI target id #2
expansion shoebox
53
3. The minor device byte for disks, after partition bits (3), left 5 bits, or 32 total disks allowed.
4. In order to allow for overlap with the old [34]/260 internal drive arrangement (SCSI target 0,
luns 0 and 1), a unit numbering scheme was used such that even numbers mapped to lun 0,
odd numbers mapped to lun 1. For example, the cong le lines here are:
disk
disk
disk
disk
disk
disk
sd0
sd1
sd2
sd3
sd4
sd6
at
at
at
at
at
at
si0
si0
si0
si0
si0
si0
drive
drive
drive
drive
drive
drive
000
001
010
011
020
030
flags
flags
flags
flags
flags
flags
0
0
0
0
0
0
(in other words, don't overload the slave eld; ask for what you want by name!)
This was all well and ne, but it then left open the question of what the various values of N
should be (for sdN, etc..).
Chapter 4 { What's in a name, anyway?
Should unix device names be logical or contain some physical address information to infer? This
quickly became a very heated topic of discussion within the SS1 team.
Mitch Bradley (the author of the OpenBoot prom), held out for the notion that the true name
of a device should be *completely* physical, and that you would use simple aliases for convenience.
In OpenBoot, version 2 and later, you can see this philosophy in the prom pathnames of devices.
For example, the default disk to boot from on an SS2 is:
/sbus/esp@0,800000/sd@3,0:a
This has even made it into the OS for Solaris 2.0 (aka 'SunOS 5.0') as 'devfs'.
Clearly this naming scheme can get incredibly awkward for more complicated machines. The
above example is about as simple as it can get. For this reason we all had the notion that, ultimately,
your boot device would be called "Fred", and that when you booted the machine, you typed "boot
Fred", which would be an alias for the above.
This was all well and ne, but at the time (and a short amount of time it was! we did all
the major OS/Prom design *and* implementation work between about March and October), we
still had traditional unix device names sitting in /etc/fstab, e.g., sd0a, sd0g, etc, so the above
54
philosophy and discussion was a "future", and not directly pertinent to what we released at rst.
This left us back at the discussion as to whether a sd unit number should be completely logical
(and convenient), or contain enough information to derive a physical address from.
My (poor) contribution at this point was the following argument:
1. There aren't enough minor device bits to do full SCSI address encoding. This is because there
are 64 possible target/lun combinations per SCSI bus.
2. Users want something simple, not complicated. The rst disk you use should be sd0. The
second should be sd1, etc. If I had kept the old SCSI numbering scheme, I thought that the
notion that the primary drive would be 'sd6' was unbearably stupid and awkward.
3. Therefore, the sd unit numbers should be completely logical. The rst disk (at target id #3)
should be sd0, and so on.
4. If this arrangement turned out to be a problem for someone, I insisted on and got *mostly*
implemented a mechanism to change such a logical mapping. The cong le you could always
cha
In retrospect, I found #1 was false for two reasons:
1. I confused the *name* of the device with its minor device number in /dev. There was no reason
why a *name* like sd030a couldn't have been using (sd bus 0 target 3 lun 0 partition a), but
with a completely arbitrary minor device number. After all, /dev/MAKEDEV would do all
the dirty work.
2. It simply didn't occur to me to use more than one major number in order to extend the width
of the 'minor' device byte. I just plain forgot that System V had been doing this for some time,
and I also just didn't pay attention to what Joe Eykholt was doing with IPI at the same time
(solving a similar problem).
In retrospect, I found #2 was false, mainly for the reason that I guessed that users would want
that which *I* found simple, and this is most certainly not the case. At SUG panels I got ripped
totally by pissed o users (and rightly, I suppose). I also violated the principle of "least surprise",
where something was dierent from what customers expected. As a minor sidebar, Sun Field service
also ripped me up side the face because, in their opinion, customers changed addresses of shoeboxes
all the time, and that we (engineering) should have made the internal drives SCSI id 0 and 1 (resp),
thus obviating any change to numbering schemes whatsoever.
All in all, though, given the constraints of hardware, time, and a desire to make things easier,
the major mistake here was #b above. If I had thought of this, and made the unix names encode
full physical information, I *think* everyone would have been happier.
[email protected],
August 1992.
55
Le logiciel est disponible pour AIX, IRIX 4 et 5, SunOS 4.1.x, Solaris 2.x.
URL ftp://ftp.fnal.gov/pub/juke/v4_1.
If the two rst parameters (ARWE and I keep forgetting the second) are
both 0, then it is OFF. Turn them ON by issuing the following command,
edit the two elds and save.
/sbin/scsi -f /dev/rsdNc -m 1 -P 3
If both are set to 1, then automatic remapping is already ON and the disk
has no more available sectors to remap bad blocks into. Return it to your
vendor to get another one.
HP-UX 9.0x
Voici un extrait d'une news :
Marc Jourdeuil <[email protected]> provided a very nice summary, which I'll quote in
conclusion. . .
I had a bad block problem on a HP 715, with a SEAGATE ST11200N 1
Gb disk. Here are some of the things I tried:
fsck -y /dev/rdsk/c201d5s0
Let fsck run a while to try to bypass the bad block, no luck,
got stuck there!
try to specify an
for specic disk
dd.ignore-errors if=/dev/rdsk/c201d5s0
of=/dev/rdsk/c201d4s0 bs=4096
dd.ignore-errors if=/dev/rdsk/c201d5s0
of=/dev/rdsk/c201d4s0 bs=4096 skip=16
Try to skip the 1st 16 512-byte blocks (skip the trouble area.
56
You can try some or all of these things. Depending on state of the disk/bad
block, you may be ok. In the case I describe, I even sent the disk for data
recovery with OnTrack, but only ~20 Mb of 350 Mb could be recovered.
In another case, the forced mount worked. Typically, when you hit a bad
block, say "asta lavista" to the disk. It will have to be mediainit, newfs'ed.
It won't hurt to try these things rst.
On notera la mention au chier /etc/sbtab qui contient eectivement le resultat des
commandes newfs ou mkfs, a savoir les numeros de super blocks de secours, ce qui
peut ^etre pratique en cas de perte du super block par defaut.
SunOS 4.1.x
La commande /usr/etc/format permet de reaecter des bad blocks via repair.
Solarix 2.x
La commande /usr/etc/format permet de reaecter des bad blocks via repair.
D'apres [email protected] :
This doesn't work on all disks though.
The bad block is added to the list and if it's in use by a le the le will get
a zeroed block. (You'll know it is in use by a le if dump complains)
If the block is in use by lesystem metadata, you'll need to re-run fsck after
xing the block.
3.7 Bibliographie.
Le lecteur pourra se reporter aux newsgroups consacres aux dierents systemes (cf [Generalites
sur les systemes abordes], page 7) ainsi qu'a comp.periphs.scsi.
Le lecteur peut se reporter aux articles suivants :
[Miq93] Robert Miquel. L'environnement SCSI { Principes du bus et application aux peripheriques.
Dunod Tech, 1993.
57
58
59
Commande
/bin/smit
/usr/sbin/newfs
/etc/newfs
/sbin/newfs
/etc/newfs
/sbin/newfs
/etc/mkfs
???
/sbin/newfs
/etc/newfs
/usr/sbin/newfs
La commande newfs est en fait une interface pour une autre commande plus bas niveau : mkfs.
Par defaut, la commande newfs cree un lesystem ayant les caracteristiques suivantes (c'est a
peu pres la m^eme chose sur tous les systemes) :
,
,
,
,
,
60
A suivre
On notera l'existence du chier /etc/sbtab sur HP-UX 9.0x qui contient le resultat des commandes newfs ou mkfs, a savoir les numeros de super blocks de secours, ce qui peut ^etre pratique
en cas de perte du super block par defaut.
D'une facon plus generale, pour les autres systemes, il est interessant de conserver une trace
ecrite (par exemple scotchee sur le disque) de ces adresses de blocks de facon a les avoir sous la
main en cas de besoin pour un fsck.
A suivre
4.3 Montage des lesystems locaux.
Les chiers ou l'on indique les disques locaux a monter sont les suivants selon le systeme :
Systeme
AIX versions 3.2.3 et 4.1.x
DEC OSF1 1.x, 2.0 et 3.0
DEC ULTRIX-4.x
FreeBSD version 2.0.5 et 2.1
HP-UX 8.07 et 9.0x
HP-UX 10.01
IRIX 4.0.5 et 5.2
Linux 1.2.x
NetBSD 1.0
SunOS 4.1.x
Solaris 2.x
Fichier
/etc/filesystems
/etc/fstab
/etc/fstab
/etc/fstab
/etc/checklist
/etc/fstab
/etc/fstab
/etc/fstab
/etc/fstab
/etc/fstab
/etc/vfstab
Quant a la syntaxe, il vaut mieux se reporter aux pages de manuel de chaque systeme.
Pour AIX, il vaut mieux passer par l'utilitaire SMIT.
61
AIX 3.2.x
AIX 4.1.x
DEC OSF1 3.0
DEC ULTRIX 4.x
FreeBSD 2.0.5 et 2.1
HP-UX 9.0x
HP-UX 10.0x
IRIX 4.0.5 et 5.2
Linux
NetBSD 1.0
Architecture sun3 + SunOS 4.1.1
Architecture sun4 + SunOS 4.1.1
Architecture sun4c ou mieux + SunOS 4.1.x
SunOS 4.1.x avec x > 1
Solaris 2.x
Systeme de chiers
2 Go
64 Go
4 Go
???
4 Go
4 Go
4 Go
8 Go
4 Go
4 Go
2 Go
2 Go
4 Go
chier
2 Go
2 Go
???
???
???
2 Go
2 Go
???
???
???
2 Go
1 Go
2 Go
2 Go
???
Commande
Utiliser /bin/smit
/usr/sbin/tunefs
/sbin/tunefs
/etc/tunefs
indisponible
/sbin/tune2fs
/sbin/tunefs
/usr/etc/tunefs
/usr/sbin/tunefs
62
63
64
the disk are utilized regardless of parameters such as number of tracks passed to mkfs, but blocks
may be oriented dierently.
hdevicei
If you are accustomed to a version of HP-UX earlier than 10.0, you may note that the -O option
used above to specify the disk type is new. This is because the disk type is no longer a required
parameter as of HP-UX 10.0.
The size of the new le system is specied to be 40000 "logical sectors" (DEV_BSIZE blocks)
simply because that is the amount of space available on the system where the information in this
paper was tested (40MB). This is done explicitly for this example, but the default for mkfs is also
to use the entire space available on the device.
65
This newfs command will, in turn, execute the following mkfs command, inserting many of the
defaults on the command line:
mkfs
hdevicei
To save you from continually referring to the manual page, the parameters are transposed from
this command line to the following list so that you can see each one with its description:
File system size, DEV_BSIZE blocks
Number of logical sectors per track
Number of tracks per cylinder
Data Block size, bytes
Fragment size, bytes
Number of cylinders per group
Minimum free space, percent
Revolutions per second
Number of bytes per inode
40000
38
13
8192
1024
16
10
90
6144
Notice that the number of cylinders per group can be entered on the command line. As you will
see, this parameter plays an important role in maximizing the number of inodes { its value can
range from 1 to 32.
Also note that the number of bytes per inode is 6144. On systems before HP-UX 10.0 the default
value for this parameter was 2048 bytes per inode.
Notice that this computation is in sectors (DEV_BSIZE blocks of 1024 bytes), not data blocks or
fragments of data blocks. The units will not be the same in all computations, so it is worthwhile
taking notice of the units through- out this paper.
The number of cylinders in the le system can be found by rst dividing the size of the le
system by the number of sectors per cylinder. For example:
40000 / 494 = 80.97 cylinders in the file system
If the number of sectors in the le system is not an even multiple of the cylinder size, the number
of cylinders will be rounded up, and you will see a message warning you that the end of the last
cylinder will be padded with unusable sectors to ll out the cylinder. For example:
40000 - ( 80 * 494 ) = 480 sectors [14 short of a full cylinder]
Because there are 480 sectors left over, the number of cylinders will be increased to 81 and the
following message will be printed:
66
Note that the total number of DEV_BSIZE blocks/sectors requested by the user have been allocated,
and the message is merely warning the user that the last cylinder is "incomplete" (i.e. not enough
data blocks to make an even cylinder).
Cylinder Groups
The number of cylinder groups can be determined by rst dividing the number of cylinders by
the number of cylinders per cylinder group. If the number of cylinders is not an even multiple of
the number of cylinders per group, the number of cylinder groups will be rounded up. For example:
81 / 16 = 5.06 cylinder groups
Since 81 is not evenly divisible by 16 there will be 6 cylinder groups in our example.
This number of (DEV_BSIZE) sectors in a cylinder group can be converted to the number of data
blocks by dividing this number by the number of sectors per block. In the example we are using
there are 8192 bytes per data block, and since there are always 1024 bytes per sector, the number
of logical sectors per data block is 8. Thus, the number of data blocks per cylinder group is:
7904 / 8 = 988 data blocks per cylinder group
67
of the above "overhead" calculation. If you reach a cylinders per group limit you will receive the
following message:
mkfs (hfs): Cylinder group is too large (xx cylinders).
mkfs (hfs): The maximum is yy cylinders per group.
To resolve this particular problem, you need to reduce the number of cylinders per cylinder group.
The message shows you the number of cylinders per cylinder group that was used, and the maximum
value that will work given the other parameters that were used.
The maximum number of data blocks per cylinder group varies depending upon the size of the
blocks in the le system. The reason for this is because there is some information that must be stored
in a single cylinder group information block at the front of the cylinder group. The information
block consists of a xed part that is always 988 bytes, and a variable part that uses the rest of
the space in the block. The variable part of the information is a bitmap that requires one bit for
every fragment in the cylinder group. Thus, the size of a cylinder group is limited to the number
of fragments for which there are bits in the cylinder group information block.
For example, if the block size is 8192 bytes, then there are 8192 - 988, or 7204 bytes available
for the bitmap. Since there are 8 bits in a byte, the maximum number of fragments in the cylinder
group is 7204 * 8, or 57632 fragments. To get the maximum number of blocks in the cylinder group,
you then divide this maximum number of fragments by the number of fragments in a regular data
block. A formula would be:
(blocksize , 988) 8 = maximum data blocks per cylinder group
fragments per block
The following table shows the maximum cylinder group size for each combination block size and
fragment size that is currently allowed:
Block Size
4096
8192
16384
32768
Fragment Size
4096
2048
1024
8192
4096
2048
1024
16384
8192
4096
2048
32768
16384
8192
4096
Maximum Blocks
24864
12432
6216
57632
28826
14408
7204
123168
61584
30792
15396
254240
127120
63560
31780
68
Block Size
65536
Fragment Size
65536
32768
16384
8192
Maximum Blocks
516384
258192
129096
64548
The mkfs command uses the following formula to determine the number of blocks in the inode
area:
cgsize , overhead
= data blocks of inodes
bpi iopb
1 + blocksize
where:
cgsize
overhead
bpi
iopb
blocksize
In our example,
Please note that in our example, the cgsize of 988 was derived earlier as the total
number of data blocks in our example cylinder group. The fact that this number is the
same as the constant number of bytes used to store cylinder group information is a
coincidence, from which no connection should be inferred.
69
The derivation of this formula is somewhat dicult to explain, historically, and we have not been
able to reason exactly why "1" was added to the denominator in the formula. Our assumption is
that it was intended to prevent the possibility of division by zero without signicantly aecting the
result. If you disregard the +1 in the denominator of the formula, then the formula is algebraically
equivalent to the following formula which is more intuitive:
(cgsize , overhead) blocksize
bpi
iopb
In this formula, the cylinder group size (less the overhead) in blocks is converted to bytes, which is
then divided by the number of bytes per inode to give the number of inodes in the cylinder group.
This is then divided by the number of inodes that can be stored in a block to determine the number
of blocks that are needed for the inode area.
The math here is very important because the result is truncated (rounded down). This can have
a very signicant eect on the number of inodes with large data-block sizes such as 64K. Thus,
to get the actual number of inodes per cylinder group you need to multiply the number of inode
blocks by the number of inodes that can be stored in a block. In our example:
20 * 64 = 1280 inodes per cylinder group
There is one other rule that gures into this inode allocation: THE NUMBER OF INODES
THAT CAN BE ALLOCATED IN A SINGLE CYLINDER GROUP IS LIMITED TO 2048 INODES. See the fs(4) man pages for a discussion of MAXIPG and other limits.
Since le systems are getting larger all the time, this limit is being reached quite frequently. If you
reach this limit, the number of inodes will be set to 2048 per cylinder group and the mkfs command
will print a message indicating that it cannot allocate as many inodes as you have requested. For
example:
mkfs (hfs): The maximum number of inodes (2048) is being used due to
mkfs (hfs): fundamental file system restrictions.
This may not be the exact message that the user sees because the mkfs command prints slightly
dierent messages depending upon which parameters were used on the command line.
The limit of 2048 inodes in a cylinder group is emphasized because this is the single biggest
factor to check when trying to determine why the user did not get the number of inodes requested.
Be sure you examine the information printed by the mkfs command to see if the user reached this
limit. This will be the value labeled "i/g", meaning inodes per group. If you hit this limit, it will
say "2048 i/g"; otherwise there will be some smaller number.
70
Now its time to check the results. The following information was printed by the mkfs command
that was used for the example in this paper and we see that our calculation is correct:
Warning: 14 sector(s) in last cylinder unallocated
<device>: 40000 sectors in 81 cylinders of 13 tracks, 38 sectors
41.0Mb in 6 cyl groups (16 c/g, 8.09Mb/g, 1280 i/g)
^^^^^^^^^^^^
^^^^^^^^
super-block backups (for fsck -b#) at:
16, 7960, 15904, 23848, 31792, 39736,
You can also use the bdf(1M) command to check the total number of inodes in a mounted le
system. The bdf command printed the following information for the le system created in the
example in this paper:
hdevicei
$ bdf -i
Filesystem
hdevicei
kbytes
38919
used
9
avail
35018
%used
0%
iused
4
^^^^^
ifree
7676
^^^^^
%iuse
0%
Mounted on
/
If you decrease the number of bytes per inode, you will get more inodes in the le system. At
least until you reach the limit of 2048 inodes per cylinder group and receive a warning message.
Once you reach this limit and still want more inodes, then you must increase the number of cylinder
groups by decreasing the size of each cylinder group. If you specify only bytes per inode and you
do NOT specify the number of cylinders per cylinder group, the newfs command will make a
cylinders per group adjustment for you, provided the desired inode adjustment causes the number
of cylinder groups to change from the default by at least 10%. Implicit in this is that if only bytes
per inode is specied, and that allowing the desired number of inodes would require a less than 10of
cylinder groups in the le system, then mkfs will not make the adjustment. Without the necessary
cylinders_per_group adjustment, mkfs will allocate 2048 (MAXIPG) inodes per cylinder group.
If you specify both the number of bytes per inode AND the number of cylinders per group, the
command will not adjust the number of cylinders per group. Instead, it will rst give you
the number of cylinders per group that you requested. Then it will allocate inodes based on the
value of the bytes per inode option, up to the limit of 2048 inodes per cylinder group.
newfs
The smaller the value for the number of bytes per inode, the more inodes will be allocated until,
at some point, you have the both the maximum number of inodes in each cylinder group and the
maximum number of cylinder groups. This is the point where the maximum number of inodes have
been allocated in the le system!
So, let's go back to our original example to see if we can increase the number of inodes in the
le system. We add the -i option, which species the number of bytes per inode. Since it is set to
6144 in this rst example, the default value, the results are the same as discussed before.
71
1280
16
6
7680
If we reduce the number of bytes per inode, we should see the number of inodes increase. This
example shows what happens:
newfs -i 4096 -O HP_C2247M1 -s 40000 <device>
1856
16
6
11136
As we expected, the number of inodes increased. Let's see what happens when the value is reduced
still further:
newfs -i 2048 -O HP_C2247M1 -s 40000 <device>
1792
8
10
17920
The total number of inodes increased, but note that the number of inodes per cylinder group
actually decreased and the number of cylinders per group also decreased (to allow the total number
of cylinder groups to increase by more than 10%).
In this case, the mkfs command also reports:
Warning: inode blocks/cyl group (82) >= data blocks (60) in last
cylinder group. This implies 480 sector(s) cannot be allocated.
This is because the number of data blocks in the last cylinder group was so small that the inodes
alone could not t in the amount of space available. This last cylinder group is therefore abandoned
as unallocatable space.
By reducing the number of bytes per inode to around 800, which is smaller than a fragment,
the command will allocate an excessive number of inodes for an HFS le system:
newfs -i 800 -O HP_C2247M1 -s 40000 <device>
2048
4
21
43008
72
Checking the rough approximation shows that 43008 inodes point to 40000 * 1024 bytes of space
which is one inode per 952 bytes of space which is smaller than a fragment; that is undesirable
because more inodes are being created than can possibly be associated with regular les. Here, we
have also run into the maximum number of inodes per group, as indicated by a warning from mkfs.
To check the layout of an existing le system, run tunefs -v hdevicei using the fs(4) man pages
for an explanation of terms.
Conclusion
A couple of wrap-up notes before we nish. Most likely you have read in both the newfs(1M) and
man pages, as well as in this document, that the default number of data bytes per inode
is 6144 on HP-UX 10.0 and 2048 on earlier versions. Yet when you try a simple newfs command
with just a device le and a device, you don't get either 6144 or 2048. That is because there is both
a cylinders per group default and a bytes per inode default; the cylinders per group default has a
higher precedence than the data bytes per inode default. You will only get 6144 or 2048 bytes per
inode if it happens to work out without changing the 16 cylinders per group default.
mkfs(1M)
For the sake of completeness we should brie
y discuss the inverse case. Consider a large le
system with very few les for which a minimal number of inodes is desired. This frequently is done
using customized disktab entries or with the user specifying many le system parameters. The
temptation is to generate very few cylinder groups, perhaps just one large one with many tracks
per cylinder, etc. HFS was designed to have many cylinder groups; it will not work properly with
just a few. Avoid the temptation. Have many.
We have shown how to get a large number of inodes simply by adjusting the bytes per inode
option. We have also stated that the number of inodes is maximized by reducing the number of
cylinders per cylinder group, directly increasing the number of cylinder groups. It will be dicult,
however, to get just 1 or 2 cylinders per group using only the bytes per inode option. Other options
not discussed here, such as number of cylinders per group, can be used if ner granularity is needed.
The methodology is to make all of the terms a power of 2 and wholly divisible so that no rounding
occurs. In any event, though, judicious use of the bytes per inode option should produce an adequate
number of inodes for most le system uses.
File System Lab
HP OSSD/COSL
73
minfree of 10and the le system lls up, the slower search algorithms are used, reducing performance.
More importantly for read performance the blocks of a poorly allocated le will scrattered all over
the disk.
The 10available disks were around 512 MB on VAX 11/750. Given the geometries of disks at
the time and typical cylinder group arrangement, 1/2 MB to 1 MB was reserved per cylinder group
(averaging across the disk). Unfortunately, the 10enshrined as a fundemental law of the universe,
without much work to ensure that is the right value for modern disks.
File sizes
There is no such thing as an average le system. Some le systems have lots of little les. Others have
a few big les. However as a mental model the notion of an average le system is invaluable.
The following table gives a break down of le sizes and the amount of space they consume.
le size
(max. bytes)
0
1
2
4
8
16
32
64
128
256
512
1024
2048
#les
87995
2071
3051
6194
12878
39037
173553
193599
167152
321016
695853
774911
999024
%les
cumm.
1.4
0.0
0.0
0.1
0.2
0.6
2.8
3.1
2.7
5.2
11.3
12.6
16.2
%les
cumm.
1.4
1.5
1.5
1.6
1.8
2.5
5.3
8.4
11.1
16.4
27.7
40.2
56.5
disk space
(Mb)
0.0
0.0
0.0
0.0
0.1
0.5
4.4
9.7
15.6
58.5
307.7
616.6
1496.6
%space
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.2
0.4
1.1
%space
cumm.
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.1
0.3
0.7
1.8
74
le size
(max. bytes)
4096
8192
16384
32768
65536
131072
262144
524288
1048576
2097152
4194304
8388608
16777216
33554432
67108864
134217728
268435456
536870912
#les
831283
607046
474483
321283
196954
114489
64842
34655
18493
9329
4002
1323
558
274
126
27
9
7
%les
cumm.
13.5
9.9
7.7
5.2
3.2
1.9
1.1
0.6
0.3
0.2
0.1
0.0
0.0
0.0
0.0
0.0
0.0
0.0
%les
cumm.
70.0
79.8
87.5
92.8
96.0
97.8
98.9
99.4
99.7
99.9
100.0
100.0
100.0
100.0
100.0
100.0
100.0
100.0
disk space
(Mb)
2415.3
3540.7
5549.4
7519.0
9118.5
10607.5
11906.2
12707.5
13515.1
13429.1
11602.7
7616.6
6389.5
6470.9
6255.9
2490.5
1819.7
2495.7
%space
1.8
2.6
4.0
5.5
6.6
7.7
8.6
9.2
9.8
9.7
8.4
5.5
4.6
4.7
4.5
1.8
1.3
1.8
%space
cumm.
3.6
6.1
10.2
15.6
22.2
29.9
38.5
47.7
57.5
67.3
75.7
81.2
85.8
90.5
95.1
96.9
98.2
100.0
,
,
,
,
,
,
,
Such a heavily skewed distribution of le sizes suggests that if one was to design a le system from
scratch it might make sense to employ radically dierent strategies for small and large les.
The seductive power of mathematics allows us treat a 200 byte and a 2M le in the same way. But do
we really want to? Are there any problems in engineering where the same techniques would be used in
handling physical objects that span 6 orders of magnitude.
A quote from sci.physics that has stuck with me: "When things change by 2 orders of magnitude you
are actually dealing with fundamentally dierent problems".
75
1e+06
Number of files
900000
800000
700000
# files
600000
500000
400000
300000
200000
100000
0
1
10
100
1000
10000
100000
File size
1e+06
1e+07
1e+08
1e+09
14000
Disk space used (in Mb)
12000
10000
8000
6000
4000
2000
0
1
10
100
1000
10000
100000
File size
1e+06
1e+07
1e+08
1e+09
People I trust say they would have expected the tail of the above distribution to have been even longer.
They expect at least some les in the 1-2G range. They point out that DBMS shops with really large
les might have been less inclined to respond to a survey like this than some other sites. This would
bias the disk space gures, but it would have no appreciable eect on le counts. The results gathered
would still be valuable because many static disk layout issues are determined by the distribution of
small les and are largely independent of the potential existence of massive les.
Block sizes
The last block of a le is only be partially occupied, and so as block sizes are increased so too will the
the amount of wasted disk space.
76
The following historical values for the design of the BSD FFS are given in "the Demon book":
fragment size (bytes)
512
1024
2048
4096
overhead (%)
4.2
9.1
19.7
42.9
Files have clearly got larger since then; I obtained the following results:
fragment size (bytes)
128
256
512
1024
2048
4096
8192
16384
overhead (%)
0.3
0.5
1.1
2.4
5.3
11.8
26.3
57.6
By default the BSD FFS typically uses a 1k fragment size. Perhaps this size is no longer optimal and
should be increased.
[The FFS block size is constrained to be no more than 8 times the fragment size. Clustering is a good
way to improve throughput for FFS based le systems but it doesn't do very much to reduce the not
insignicant FFS computational overhead.]
It is interesting to note that even though most les are less than 2k, having a 2k block size wastes very
little space, because disk space consumption is so totally dominated by large les.
Inode ratio
The BSD FFS statically allocates inodes. By default one inode is allocated for every 2k of disk space.
Since an inode consumes 128 bytes this means that by default 6.25% of disk space is consumed by
inodes.
It is important not to run out of inodes since any remaining disk space is then eectively wasted.
Despite this allocating 1 inode for every 2k is excessive.
For each le system studied I worked out the minimum sized disk it could be placed on. Most disks
needed to be only marginally larger than the size of their les, but a few disks, having much smaller
les than average, needed a much larger disk - a small disk had insucient inodes.
77
overhead (%)
12.5
6.3
4.2
3.5
3.1
3.1
3.2
3.5
4.0
4.7
6.5
7.8
9.4
11.0
12.9
14.9
17.3
19.9
22.6
Clearly the current default of one inode for every 2k of data is too small.
Misc.
I am keen to gather additional le size data from anybody who might not have taken part in the original
le size survey. If you can nd time to run the script that follows it would be much appreciated.
It is not possible to condense all the potentially useful information I gathered down to a few tables.
Every le system is unique. The full data comprising this survey can be obtained by anonymous ftp as
cs.dartmouth.edu:pub/file-sizes/ufs93.tar.gz.
4.7 Bibliographie
Le lecteur pourra se reporter aux newsgroups consacres aux dierents systemes (cf [Generalites
sur les systemes abordes], page 7).
Le lecteur peut se reporter aux articles suivants :
[KNJS84] Marshall K.MCKUSICK, William N.JOY, Samuel J.Leer, and Robert S.FABRY. A
Fast File System for UNIX. ACM Transactions on Computer Systems, 2(1):181{197,
ao^ut 1984.
78
79
gravure personnelle cd CDROM et donc problemes associes concernant les graveurs et les
logiciels de gravure.
80
,
[...]
81
These add a modication to the cdfs code which can translate all mounted
CDROMs (not selectively) to accomplish the same task. This patch adds no additional lesystem support such as POSIX or the RockRidge Extensions. This patch
can only be activated by modifying the kernel with adb. An example of how to
modify the 9.xx kernel is shown in the patch. Note that this patch aects every
mounted CDROM in the system at the same time.
3. Through an agreement with Young Minds, Inc, the Portable File System (PFS) code
has been made available to 700 and 800 series systems running 9.xx and 10.xx.
This code accomplishes not only the lowercase translation and version removal
(both are separate options and can be specied on or o for each CDROM), but
also provides RockRidge Extensions (long lenames, ownerships, permissions). This
code is available on the Nov-Dec 1995 application CDROM and tapes for the 700's,
and on the Jan-Feb 1996 Application CDROM/tapes. The media can be purchased
at any time for a nominal fee.
PFS handles exporting of CDROM lenames as well as importing these names
from other HP-UX systems, and is the most versatile solution to the CDROM
compatibility problems in HP-UX.
ou
sr0: Unrecongized Vendor 'TOSHIBA ', product 'CD--ROM XM-3301TA'sr0 at esp0 target 6 lun 0
mais cela n'est qu'un warning (en general) et le drive marche parfaitement sinon.
Certains lecteurs ne fonctionnent pas sur Sun parce qu'ils travaillent par blocs de 2048 bytes
alors que le driver SunOS s'attend a des blocs de 512 bytes. On peut cependant congurer certains
lecteurs via software pour leur dire de travailler en mode 512 bytes. Pour cela, il faut utiliser le
programme sun_cd que l'on trouve sur ftp.cdrom.com sous le nom /pub/cdrom/cd_sun.c.
Autres renseignements obtenus par les news :
Newsgroup: comp.sys.sun.hardware
From: [email protected] (Buck Fowler)
Subject: 3'rd party CD-ROM summary
Date: 25 Sep 1993 22:45:11 -0500
A little while ago I posted asking for information about attaching a third party CD-ROM to a Sparc.
I received many helpful responses; below is a summary.
Thanks again to those who helped!
82
Cette news mentionne deux programmes permettant de jouer des CDs audio sur un lecteur. Il
en existe d'autres ; les voici :
xcd_player
workman
xmcd
83
ftp.cdrom.com.
5.3 Bibliographie
Le lecteur pourra se reporter aux newsgroups consacres aux dierents systemes (cf [Generalites
sur les systemes abordes], page 7) ainsi qu'a comp.periphs.scsi. Il existe aussi d'autres newsgroups
abordant le theme des CDROM :
,
,
,
,
comp.publish.cdrom.hardware
comp.publish.cdrom.multimedia
comp.publish.cdrom.software
comp.periphs.scsi
84
85
Commande de formattage
/bin/dosformat
/usr/bin/fddisk
/usr/sbin/fdformat
/usr/bin/mediainit
Fonctionnalite absente
Il faut formatter sous DOS.
/bin/fdformat
/bin/fdformat
86
FreeBSD 2.1
Il existe un package logiciel appele hfs qui permet, entre autre, d'utiliser des disquettes
Mac :
hfs provides a command line interface to suite of functions for accessing
Macintosh HFS
oppy disks, hard drives and CD-ROMS. The following
functions are available:
, display a directory listing (ls, dir)
, change directories (cd)
, display the name of the current directory (pwd)
, copy an HFS le into a local le (read)
, display the contents of an HFS le (cat)
, display the partition table on a Macintosh volume.
IRIX 5.2 La commande /bin/mkfp permet de formatter des disquettes au format Mac.
Linux
Le package hfs, mentionne pour FreeBSD, fonctionne aussi sous Linux.
A noter l'utilitaire suntar sur Macintosh qui permet de lire une disquette formattee sous
UNIX et sur laquelle on a ecrit en raw device un chier au format TAR. Un URL en est
ftp://phoenix.doc.ic.ac.uk/computing/systems/mac/sumex/cmp/suntar-205.hqx
6.3 Bibliographie
87
88
89
When OSF/1 is in "immediate" swap mode, it allocates on-disk swap space before satisfying
each request for virtual memory. In other words, if your program requests 64 KB of virtual memory,
OSF/1 will nd space on disk to which it can swap that VM. The disk space may never be used,
but it is there if you ever need it.
When OSF/1 is in "deferred" swap mode, it allocates VM without bothering to allocate on-disk
swap space. In the event that OSF/1 needs to page or swap, it then tries to nd the disk space
required.
The advantage to deferred mode is that you can keep lling up physical memory even if you
don't have enough swap space. I.e., you could have 256 MB of memory but only 128 MB of swap
space. This would give you (very roughly) 384 MB of useable virtual memory.
The danger in using deferred mode is that OSF/1 may need to abruptly kill a running process
if the operating system desperately needs physical memory and there is no swap space available.
The advantage to immediate mode is that processes never get killed due to lack of swap space.
If they request VM and get it, then they are safe. The worst that can happen is that they request
VM and the operating system denies the request.
The disadvantage to immediate mode is that you need lots of swap space, typically 2-3 times
the amount of physical memory. Any less and you may run out of swap space before you run out
of physical memory.
A propos de Linux.
Linux peut se passer de swap. Tout depend de la memoire installee dans la machine et des
applications qui seront utilisees ; il est neanmoins fortement conseille d'employer une zone de swap
an de ne pas g^acher la precieuse memoire vive par des programmes inactifs dont les pages memoire
seraient mieux a leur place, tranquilement en attente sur un disque dur.
90
Size
136MB
128MB
%Used
17
29
Active [...]
yes
[...]
yes
[...]
Il existe une commande pstat sur AIX mais elle n'a rien a voir avec son homologue
SunOS qui donne la taille du swap.
DEC OSF1 versions 2.0 et 3.x
Utiliser la commande /sbin/swapon -s :
# /sbin/swapon -s
Total swap allocation:
Allocated space:
Reserved space:
Available space:
Size
---------131072k
16384p
In Use
---------35552k
4444p
Free
---------95520k
11940p
/dev/rz2b
131072k
16384p
35520k
4440p
95552k
11944p
/dev/rz3b
131072k
16384p
---------393216k
49152p
35280k
4410p
---------106352k
13294p
95792k
11974p
---------286864k
35858p
Dumpdev
91
dmi:[127]:</users/absint/besancon>/etc/pstat -T
473/1992
files
418/1404
gnodes
165/1056
processes
0/1056
vector processes
49/ 123/ 172 active/reclaimable/total texts
239/ 635
00k swap
Used
25936
Avail Capacity
6550
80%
HP-UX 9.0x
Utiliser la commande /etc/swapinfo :
Type
Interleaved
thorgal:[127]:</thorgal/homes/besancon> /etc/swapinfo
Kb
Kb
Kb
PCT START/
Kb
TYPE
AVAIL
USED
FREE USED
LIMIT RESERVE PRI
dev
97824
12636
85188
13% 318060
0
hold
0
30288 -30288
NAME
/dev/dsk/c201d6s0
HP-UX 10.01
Utiliser la commande /usr/sbin/swapinfo :
# /usr/sbin/swapinfo
Kb
Kb
TYPE
AVAIL
USED
dev
49152
3272
dev
475136
3388
reserve
44436
memory
203220 103992
Kb
FREE
45880
471748
-44436
99228
PCT
USED
7%
1%
START/
Kb
LIMIT RESERVE
0
0
-
PRI
1
1
NAME
/dev/vg00/lvol2
/dev/vg00/lvol8
51%
Linux
mafalda:[63]:</mafalda/homes/besancon>/etc/swap -l
path
dev swaplo blocks
free
/dev/dsk/dks0d1s1 22,33
0 81144 77904
# /sbin/swap -l
lswap path
dev
pri swaplo
blocks
free maxswap
vswap
2 /mafalda/swap/extra-swap
128,22
2
0
196608
196608
196608
0
1 /dev/swap
128,17
0
0
81144
68784
81144
0
# /sbin/swap -s
total: 6.04m allocated + 14.81m add'l reserved = 20.84m bytes used, 144.40m bytes available
NetBSD 1.0
total
Mem:
129488
-/+ buffers:
Swap:
259768
used
121716
16892
0
free
7772
112596
259768
shared
4136
buffers
104824
92
% /usr/sbin/pstat -T
117/1772 files
644 vnodes
5M/31M swap space
SunOS 4.1.x
Utiliser la commande /etc/pstat -T :
excalibur:[127]:</excalibur/homes/besancon>/etc/pstat -T
181/582 files
177/322 inodes
55/138 processes
14160/32756 swap
dev = /dev/hd6
On peut a tout moment ajouter une entree dans la table puis lancer la commande
swapon /dev/paging03 par exemple.
93
swap2
ufs
sw
/dev/wd1b
none
swap
sw
On peut a tout moment ajouter une entree dans la table /etc/fstab puis lancer une
commande du type swapon /dev/rz0b par exemple.
DEC ULTRIX 4.3
La commande est /etc/swapon. Elle ne permet que d'ajouter des block devices comme
zone de swap. Au boot (cf /etc/rc), tous les chiers de swap precises dans /etc/fstab
sont ajoutes par un swapon -a ; on peut a tout moment ajouter une entree dans
/etc/fstab puis lancer la commande swapon /dev/rz0b par exemple.
FreeBSD 2.1
La commande a utiliser est /sbin/swapon. Elle ne permet que d'ajouter des block
devices comme zone de swap. Au boot (cf /etc/rc) tous les chiers de swap precises
dans /etc/fstab sont ajoutes par un swapon -a ; les partitions doivent ^etre declarees
de la facon suivante :
On peut a tout moment ajouter une entree dans la table /etc/fstab puis lancer une
commande du type swapon /dev/rw1b par exemple.
HP-UX versions 8.07 et 9.0x
La commande est /etc/swapon. Elle permet d'ajouter des zones de swap sous la forme
de partition disque entiere ou sous la forme de chiers UNIX. Pour ajouter une partition
de swap, il faut mettre dans le chier /etc/checklist une ligne du genre :
/dev/dsk/c201d5s0 / swap default 0 0
En fait le second directory de la ligne (ici /) doit exister et ^etre non vide. On fait
ensuite /etc/swapon -a. Regarder la page de manuel de swapon pour savoir les options
possibles a la place de default.
Voici un exemple avec une partition disque que l'on va ecraser (option -f) :
# bdf /lmd1
Filesystem
kbytes
used
avail capacity Mounted on
/dev/dsk/c201d4s1
50367
9
49350
0%
/lmd1
# /etc/swapon -f -p 0 /dev/dsk/c201d4s1
# swapinfo
Kb
Kb
Kb
PCT START/
Kb
TYPE
AVAIL
USED
FREE USED
LIMIT RESERVE PRI NAME
dev
95394
11114
84280
12% 320490
0 /dev/dsk/c201d6s0
dev
51200
8
51192
0%
0
0 /dev/dsk/c201d4s1
hold
0
36052 -36052
HP-UX 10.01
La commande est /usr/sbin/swapon. Elle permet d'ajouter des zones de swap sous la
forme de partition disque entiere ou sous la forme de chiers UNIX. Pour ajouter une
partition de swap, il faut modier le chier /etc/fstab. Regarder la page de manuel
de swapon pour les options necessaires.
Linux
Voila ce qu'en dit Rene Cougnec :
A noter que les distributions toutes pr^etes s'occupent en general de toutes
les etapes qui vont suivre lors de la procedure d'installation.
Il faut dedier une partition du disque dur au swap, par la classique commande /sbin/fdisk. On peut lui donner l'identication "Linux Swap",
valeur 82 par la commande "t" de /sbin/fdisk ; c'est plus propre mais ce
n'est pas indispensable pour le fonctionnement.
94
Device Boot
/dev/sda1
/dev/sda2
Begin
1
17
Start
1
17
End
16
80
Blocks
16368
65536
Id
82
83
System
Linux swap
Linux native
shared:
2800
buffers:
2216
shared:
2828
buffers:
2168
Apres :
minux# /bin/free
total:
used:
Mem:
6912
6732
Swap:
16364
0
free:
180
16364
Comme on peut le voir, Linux n'a pas encore eu besoin de l'utiliser, cette
machine se sut a elle-m^eme avec ses 8 Mo de memoire vive. Ca ne durera
pas, tous les processus "idle" vont bient^ot ^etre swappes, et on peut l'aider
en lancant X11 :
minux# /bin/sfree
total:
used:
Mem:
6912
6784
Swap:
16364
1964
free:
128
14400
shared:
5836
buffers:
2152
NetBSD 1.0
directory
swap
type
swap
options
defaults
freq pass
0
0
Les deux derniers champs doivent exister et ^etre a zero. Ils sont utilises
par fsck et dump sur les systemes de chiers normaux ; malheureusement
beaucoup de distributions Linux toutes pr^etes les omettent, ou y placent
des valeurs fantaisistes, ce qui ne manquera pas de provoquer des ennuis
un jour.
La commande a utiliser est /sbin/swapon. Elle ne permet que d'ajouter des block
devices comme zone de swap. Au boot (cf /etc/rc) tous les chiers de swap precises
dans /etc/fstab sont ajoutes par un swapon -a ; les partitions doivent ^etre declarees
de la facon suivante :
/dev/wd1b
none
swap
sw
On peut a tout moment ajouter une entree dans la table /etc/fstab puis lancer une
commande du type swapon /dev/rw1b par exemple.
SunOS 4.1.x
La commande est /usr/etc/swapon. Pour ajouter une partition, il faut :
95
Fonctionnalite absente.
Fonctionnalite absente.
Fonctionnalite absente.
FreeBSD 2.1
Fonctionnalite absente.
HP-UX 9.0x
Pour ajouter du swap dans un lesystem existant deja, mettre dans /etc/checklist
une ligne du genre :
/dev/dsk/c201d6s0
default
/
/akira/swap
hfs
defaults
0 1
swapfs min=10,lim=2560,res=1000,pri=2 0 0
ou /akira/swap est un directory dans le lesystem sur lequel on peut vampiriser de la
place pour le swap additionnel. On fait ensuite /etc/swapon -a.
Regarder la page de manuel de swapon pour les options min=. . .
Dans le cas precedent, on a :
# swapinfo
TYPE
dev
fs
hold
Kb
AVAIL
54624
20480
0
Kb
USED
8328
0
37564
Kb
FREE
46296
20480
-37564
PCT
USED
15%
0%
START/
Kb
LIMIT RESERVE
361260
20480
1000
PRI
0
2
NAME
/dev/dsk/c201d6s0
/akira/swap
Voici un autre exemple d'ajout de swap via un lesystem. Le chier de swap est
/lmd2/swap et r
eside sur le lesystem /lmd2.
96
# bdf /lmd2
Filesystem
kbytes
used
avail capacity Mounted on
/dev/dsk/c201d4s2
1653070
10 1619998
0%
/lmd2
# /etc/swapon -m 10 -l 4500 -r 100 -p 0 /lmd2/swap
Kb
AVAIL
95394
36864
0
Kb
USED
10638
0
36536
# bdf /lmd2
Filesystem
/dev/dsk/c201d4s2
Kb
FREE
84756
36864
-36536
kbytes
1653070
PCT
USED
11%
0%
START/
Kb
LIMIT RESERVE
320490
36864
100
PRI
0
0
NAME
/dev/dsk/c201d6s0
/lmd2/swap
used
avail capacity Mounted on
2066 1617942
0%
/lmd2
Peu de place a disparu pour le moment puisque l'espace de swap supplementaire n'est pas encore utilise.
HP-UX 10.01
Comme avec HP-UX 9.0x, on peut utiliser le systeme de chiers comme espace de swap.
Il sut de declarer un repertoire existant dans /etc/fstab (dans lequel le systeme cree
un sous-repertoire nomme paging), puis de faire /usr/sbin/swapon -a de maniere
analogue a precedemment.
Voici un exemple ou le swap est ajoute \au vol" :
sweet# df
Filesystem
kbytes
used
avail %used Mounted on
/dev/dsk/c0t6d0
429781 327452
59350
85% /
/dev/dsk/c0t2d0
309670 207872
70831
75% /users
sweet# ls -l /users/paging
/users/paging not found
sweet# swapon /users
sweet# swapinfo
Kb
Kb
Kb
PCT START/
Kb
TYPE
AVAIL
USED
FREE USED
LIMIT RESERVE PRI NAME
dev
69707
1272
68360
2% 441344
1 /dev/dsk/c0t6d0
localfs
69632
0
69632
0%
none
0
1 /users/paging
reserve
23308 -23308
memory
19708
9480
10228
48%
sweet# ls -l /users/paging
total 0
sweet#
IRIX 4.0.5
IRIX 5.2
Fonctionnalite absente.
On peut ajouter des chiers de swap sur un lesystem existant deja. Pour cela, mettre
dans /etc/fstab, une ligne du genre :
/mafalda/swap/extra-swap /mafalda/swap swap rw 0 0
blocks
free
maxswap
vswap
81144
76112
81144
97
Linux
4096000 Dec
4 23:04 fichier.swap
Puis, il sut de proceder comme pour une partition, pour valider ce chier
en tant que zone de swap :
minux:/ # /sbin/mkswap /fichier.swap
Setting up swapspace, size = 4091904 bytes
Voila. Le chier est pr^et a servir, comme s'il s'agissait d'une partition de
swap :
minux:/ # /sbin/swapon fichier.swap
minux:/ # /bin/free
total:
used:
free:
shared:
Mem:
6912
6736
176
5744
Swap:
20360
2460
17900
buffers:
2560
98
# device
directory
/dev/sda1
swap
/fichier.swap swap
NetBSD 1.0
type
swap
swap
options
defaults
defaults
freq pass
0
0
0
0
Fonctionnalite absente.
SunOS 4.1.x
Pour creer un chier de swap, utiliser la commande mkfile. Par exemple, on ajoute 50
Mo de swap par :
% mkfile 50m /share/dea/swap/extra_swap
On donne ces 50 Mo au systeme par swapon <file>. Une fois des chiers donnes au
systeme, on ne peut recuperer l'espace qu'ils occupent qu'en rebootant.
Si l'on veut que le chier de swap soit automatiquement ajoute au moment du boot, il
faut mettre une commande swapon <filename> dans /etc/rc.local. Par exemple :
if [ -f /share/dea/swap/extra_swap -a -f /usr/etc/swapon ]; then
/usr/etc/swapon /share/dea/swap/extra_swap
echo ' Ajout de 50M de swap'
>/dev/console
fi
Solaris 2.x
Pour creer un chier de swap, utiliser la commande mkfile. Par exemple, on ajoute 50
Mo de swap par :
% mkfile 50m /share/dea/swap/extra_swap
On donne ces 50 Mo au systeme par swap -a <file>. A priori (et sous reserve que
cela marche), on peut retirer cet ajout de swap par /usr/sbin/swap -d <file>.
Pour ajouter automatiquement des chiers de swap, il faudra ajouter des appels a
/usr/sbin/swap -a. . . dans les scripts de boot (cf section 2.2 [Initialisation
a la System V], page 32).
/usr/sbin/swap -d.
Voila ce que dit Rene Cougnec a propos de la diminution de la taille du swap sur Linux :
Ce n'est pas conseille : le systeme s'en sert et se sent a l'aise. Supprimer une zone de
swap le force a "avaler" en memoire vive tout ce qu'il y avait pose pour se debarrasser.
Cette operation peut fort bien se passer, ou fort mal :-) En regle generale, laisser le
"shutdown" s'en occuper, il tue susamment de processus au pr
ealable.
La commande opposee de /sbin/swapon s'appelle /sbin/swapoff :
minux# /sbin/swapoff /fichier.swap
minux# /bin/free
total:
used:
free:
shared:
buffers:
Mem:
Swap:
6912
16364
6748
2532
164
13832
5700
99
2656
Hop, nos 4 Mo de swap dans un chier ne sont plus la. Eviter swapoff -a sauf si vous
savez exactement ce que vous faites, en fonction de l'avertissement ci-dessus.
7.6 Divers.
Setting the maxslp kernel variable to 0x80 will stop unnecessary swapping (by default, idle
processes are swapped out after 20 seconds { you can check this by setting swapdebug to 1). This
should decrease activity on the swap device.
The Xkernel package, available from ftp.ctr.columbia.edu contains a device driver that allows
to build a swapless kernel (I think it is in /pub/Xkernel/Xkernel-2.0-beta/Xpert.tar). It works
ne for a minimal kernel running only an X server. I never tried it on a generic workstation though.
7.7 Bibliographie.
Le lecteur peut se reporter aux articles suivants :
100
101
8 Reseau Ethernet.
Nous ne parlerons ici que d'Ethernet qui est le standard de-facto pour les stations de travail
sous UNIX.
,
,
,
,
,
topologie bus ;
principe de CSMA/CD (Carrier Sense Multiple Access, Collision Detect ) ;
heart beat (CPT), Signal Quality Error (SQE) ;
tailles des trames Ethernet ;
...
La norme propose aussi dierentes implantations materielles possibles ayant chacune certaines
contraintes :
,
,
,
,
Ethernet gros
Le support physique est du c^able coaxial de 50 ohms, jaune, marque tous les 2.5 m
et de rayon de courbure 50 cm. Sa
Thick Coax Segment
longueur maximale est de 500 m. On
(500 meter maximum)
peut y installer un maximum de 100
AMP
stations dont les prises sur le c^able
Thick
MAU
Coaxial
doivent ^etre separees au moins de
Tap
15-pin
2.5 m entre elles d'ou la marque re(MDI)
AUI Connector
guliere sur le c^able. On met un bouAUI Cable
(50 meter max)
chon 50 ohms a chaque extremite.
Ethernet
Une machine s'installe en posant un DTE
Interface
transceiver vampire, simple ou mulMale N Connector
tiple et en raccordant avec un drop
50 Ohm Terminator
cable de 45m maximum. L'installation peut ^etre transparente. On appelle aussi ce support 10 Base 5 (le 10 signiant
qu'il s'agit de la version Ethernet a 10 Mbps, le Base signiant que l'on transporte
des signaux de base, le 5 signiant que la longueur maximale autorisee est de 5 x 100
metres).
102
AUI
Ethernet n
Le support physique est du c^able coaxial de longueur 185 m maximum. On peut y
installer un maximum de 30 stations
qui doivent ^etre au moins separees de
Thin Ethernet Coax
0.5 m. On installe un bouchon de 50
(185 meter maximum
ohms a chaque extremite. Une machine
0.5 meter minimum)
s'installe en interrompant a l'aide d'un
Male BNC Connector
te le c^able. Une installation introduit
donc une br^eve coupure. On ne doit
Ethernet
BNC Tee
MAU
DTE Interface
pas poser de c^able entre le te et l'adapWith Internal MAU
Male BNC 50 Ohm
Terminator
tateur sur la machine. On appelle aussi
Female BNC MDI
ce support 10 Base 2 (le 10 signiant
qu'il s'agit de la version Ethernet a 10
Mbps, le Base signiant que l'on transporte des signaux de base, le 2 ne semble pas
s'interpr^eter comme le 5 de 10 base 5 puisque l'on a le droit a 185 m au plus et non a
2 x 100 m).
AUI
MAU
MAU
MAU
MAU
MAU
RJ-45 Jack
(MDI) Pin 1 =
Pin 2 =
Pin 3 =
Pin 6 =
FOMAU
FOMAU
TX RX
TX RX TX RX TX RX
DTE
Ethernet
Interface
AUI Cable
Ces dierents types de c^ablage ne permettent que de se constituer un segment. Pour constituer
son reseau local, il va vraisemblablement ^etre necessaire d'interconnecter dierents segments. Cela
se fait gr^ace a des repeteurs ou a des ponts. Dans tous les cas, cela est normalise ; entre deux
stations A et B, on ne peut avoir :
103
Adresse
Destination
Adresse
Source
Type de
paquet
Donnees
CRC
64 bits
48 bits
48 bits
16 bits
368 a 12000
bits
32 bits
d'ou il ressort que l'on peut transmettre au plus 1500 bytes de donnees. Cette limite est connue
sous le nom de MTU, Maximum Transfer Unit que l'on peut voir precisee dans des commandes
UNIX de conguration de l'interface Ethernet (ifconfig. . .).
Il peut ^etre parfois interessant de savoir dechirer des adresses Ethernet. Ainsi, sous SunOS
4.1.x, on peut recevoir des messages du type suivant (via syslog) :
Dec 15 20:18:35 excalibur vmunix: le0: Receive: giant packet from 0:0:a7:a7:a7:40
Dec 15 20:18:35 excalibur vmunix: le0: Receive: STP in rmd cleared
Pour identier le peripherique Ethernet en cause via son adresse, on utilisera des tables donnant
les prexes constructeurs et le nom du constructeur ayant ce prexe. Ces tables ont pour URLs
ftp://ftp.ieee.org/info/stds/info.stds.oui et ftp://ftp.lcs.mit.edu/pub/map/EtherNetcodes. Ainsi, dans notre exemple, on trouve que l'identicateur 0:0:a7 est celui de Network Computing Devices (NCD) ; donc un terminal X NCD branche sur le c^able Ethernet a fait des siennes
ce soir la. . .
104
A noter que l'utilisation conjointe de ping et de arp permet de se constituer la liste des adresses
Ethernet des stations (en fonctionnement) ; pour cela :
1. faire un ping sur l'adresse de broadcast (cf section 10.4 [Broadcast], page 127);
2. faire un arp -a apres.
3. Le systeme peut fournir certaines commandes permettant de decouvrir l'adresse :
Systeme
AIX 3.2.3
AIX 4.1.x
DEC OSF1 1.x, 2.0 et 3.0
DEC ULTRIX 4.x
FreeBSD 2.1
HP-UX 8.07 et 9.0x
HP-UX 10.01
IRIX 4.0.5 et 5.2
Linux
NetBSD 1.0
SunOS 4.1.x
Solaris 2.x
Commande
/etc/lscfg -v | grep "Network Address"
/usr/sbin/lscfg -v | grep "Network Address"
/usr/sbin/uerf -R -r 300 | grep "_hardware address"
???
/usr/bin/netstat -i
/etc/lanscan
/etc/lanscan
/usr/etc/netstat -ia
/sbin/ifconfig -i
/usr/bin/netstat -i
/etc/ifconfig -a
/sbin/ifconfig -a
4. On dispose en general d'un moyen de programmation de recherche de l'adresse. En general, cela se ramene a un bon appel ioctl(). Par exemple, sous SunOS 4.1.x, le chier
d'URL ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/geteaddr.c donne un
exemple de ce que l'on doit faire.
Dans le cas d'une station disposant de plusieurs interfaces Ethernet, la probleme reste entier car
on ne trouve en general qu'une seule adresse par des moyens logiciels.
105
us
decim
dec
mo
08:00:69:06:1d:d5
Unsegmented
08:00:69:07:6e:e4
33.97 %
yan
vig
:02
00
galileo
tutte
sodom
abe
yan
:74
:74
a1:
8a
1:8a
:9b:a
91:
:c5
:87
c0:
vig
:1d
:a6
:61
go
m
0:
f7
:8
17.07 %
6:61
sh
fla
0:1d:a
:2
08:00
81
f7:
3c:
c0:
00:
:
0
0
:c3:74
:c0:78
00:00
00:00:c0:87:c5:74
sodo
m
slo
th
:5c
:43
:02
:69
:00
08
ent
vinc
e2
08:00:69:07:6e:
:c3
:c0
:20
:81
:5
:78
:00
00:
:00
:f7
c0
:c0
00
00:
:fa:81
:7a:86
:c0:a8
0:c0
00:0
00:00
deedee
00:00:c0:e0
Sortie de etherman
erdo
s
rabbit
:3c
0:
:00
00
or
ra
:0
pr
id
e
ma
rsh
00:00:c
0:50:f7
:81
08
:0c
:c0
08:00:6
9:06:c
e:79
lus
t
sto
rm
:45
d5
:07
w
sno
:e4
:6e
:69
:00
t
us
:07
:00
ard
00
Sortie de analyser
:7b
08
pic
er
g
an
:69
ny
tto
glu
:00
08
:05
rose
stor
08:00:69:06:1d:
amb
h
slot
:69
marvin
envy
bik
:00
08
00:00:c0:e0:fa:81
08
:a1:8a
rvi
ma
zen
00:00:c0:94
b
rra
08:00:69:07:6e:31
08:00:69:02:43:5c
2:05:7
:00:69:0
us
go
zen
im
berne
:5d
le
:60
hy
cauc
drizz
:07
:0
00
:69
:00
lille
:e2
:6e
:07
:69
00
08:
goat
lillee
00:0
0:c0
:91:a
de
1:8a
ed
ee
08:00:69:07:6e:bc
rsh
ma
bit
rab
cen
y
env
anger
el
ab
ne
ber
cain
:79
vin
os
br
am
08
erd
:ce
23.37 %
covet
urly
mrc
a
1:8
4:a
0:9
c
:
0
os
kr
yte
n
tutte
:06
00:00
:c0:9b
:a1:8a
csgw
de
pri
cai
drizzle
mrc
bike
kryte
urly
ve
ve
:69
co
re
:00
:a8:7a:8
ow
sn
08
ve
tton
00:00:c0
cauchy
:5d
glu
o
galile
ard
pic
31
goat
08:00:69:07:6e:
re
:0c
:45
:07
:60
flas
:07
:69
cs-gw
:69
:00
08
:00
08
08:00:69:07:6e:bc
URL ftp://ftp.cs.curtin.edu.au//pub/netman/harchitecturei/etherman-1.1a.tar.gz
URL ftp://ftp.cs.curtin.edu.au//pub/netman/harchitecturei/analyser-1.0.tar.gz
Ces programmes ne sont disponibles qu'en versions binaires pour un certain nombre
d'architectures (DEC OSF1 et ULTRIX, IRIX, SunOS 4.1.x, Solaris 2.x) :
Le programme etherman est un utilitaire sous X achant en temps reel les communications Ethernet entre les stations. On peut sauvegarder une image instantanee du
trac sous forme postcript ce qui donne une copie assez similaire a l'achage temps
reel (cf. ci-apres).
L'utilitaire analyser vient en complement de etherman ; il tente de trouver une repartition au mieux de machines en sous reseaux Ethernet, les echanges entres reseaux
etan limites au minimum (cf. la repartition ci-apres) :
106
ethertop
URL ftp://ftp.inria.fr/network/tools/ethertop.shar.Z
C'est un programme moins sophistique que etherman, fonctionnant en mode texte et
achant les machines provoquant le plus de trac Ethernet. Voici un exemple de sortie
de ethertop :
Network load as seen from excalibur
bytes
pkts
bcst
tcp
udp
icmp
arp
nd
oth
6.95K
66.05
0.00
26.52
21.25
0.00
0.00
0.00
18.28
packet sizes:
64-154 155-245
246-336
337-427
428-518
519-609
610-699
700-790
48.10
13.84
4.12
0.00
0.00
0.00
0.00
0.00
791-881 882-972
973-1063 1064-1154 1155-1245 1246-1336 1337-1427 1428-1518
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
-------------------------------------------------------------------------------HOSTNAME
SENT | HOSTNAME
RECV
peterpan.ens.fr
7.43 | peterpan.ens.fr
7.43
ensapb.ens.fr
6.93 | clochette.ens.fr
5.61
clochette.ens.fr
5.61 | ensapb.ens.fr
4.79
falbala.ens.fr
4.79 | corto.ens.fr
3.96
corto.ens.fr
3.96 | excalibur.ens.fr
3.96
calvin.ens.fr
2.97 | ensapd.ens.fr
3.14
tournesol.ens.fr
2.97 | ensape.ens.fr
3.14
ensape.ens.fr
2.15 | calvin.ens.fr
2.97
ensapd.ens.fr
1.98 | tournesol.ens.fr
2.97
donald.ens.fr
0.99 | naomi.lpt.ens.fr
0.99
marguerite.ens.fr
0.99 | fantasio.ens.fr
0.99
pollux.ens.fr
0.99 | marguerite.ens.fr
0.99
castor.ens.fr
0.99 | pollux.ens.fr
0.99
fantasio.ens.fr
0.99 | castor.ens.fr
0.99
celeste.lpt.ens.fr
0.99 | donald.ens.fr
0.99
naomi.lpt.ens.fr
0.99 | celeste.lpt.ens.fr
0.99
alix.lpt.ens.fr
0.99 | alix.lpt.ens.fr
0.99
joyeux.ens.fr
0.33 | falbala.ens.fr
0.83
droopy.ens.fr
0.17 | joyeux.ens.fr
0.33
thorgal.ens.fr
0.17 | SGI-DOG.MCAST.NET
0.17
dmi.ens.fr
0.17 | thorgal.ens.fr
0.17
mafalda.ens.fr
0.17 | dmi.ens.fr
0.17
papoon.ens.fr
0.17 | droopy.ens.fr
0.17
| papoon.ens.fr
0.17
etherload
URL ftp://ftp.navya.com/pub/vikas/nocol-4.01.tar.gz
Ce programme fait parti d'un ensemble d'autres programmes, appele nocol :
% etherload -s 30
etherload: searching for all devices
Scan-interval= 15, sleeptime= 30
Thu May
Thu May
Thu May
Date
4 23:47:11 1995
4 23:47:57 1995
4 23:48:42 1995
PPS
79
74
85
BW%
0
0
0
% etherload -e -i 5 -s 15
etherload: searching for all devices
Scan-interval= 5, sleeptime= 15
Thu May
Thu May
Thu May
Date
4 23:49:33 1995
4 23:49:53 1995
4 23:50:14 1995
107
etherprobe
URL ftp://ftp.utexas.edu/pub/netinfo/src/etherprobe.tar.Z
Il s'agit d'un utilitaire permettant de decouvrir les adresses Ethernet via des requ^etes
ARP (le logiciel ne necessite pas d'^etre root).
excalibur:[1794]:</excalibur/homes/besancon> etherhostprobe 129.199.115.40 129.1
99.115.49
08:00:20:0d:8b:db 129.199.115.41 percevan.ens.fr
00:00:0f:00:d4:f2 129.199.115.42 castafiore.ens.fr
08:00:69:06:ff:73 129.199.115.43 filochard.ens.fr
08:00:09:48:88:01 129.199.115.44 caferoyal.ens.fr
08:00:20:18:00:de 129.199.115.45 clochette.ens.fr
08:00:20:18:7f:75 129.199.115.46 corto.ens.fr
08:00:09:70:01:5e 129.199.115.47 prunelle.ens.fr
08:00:20:03:75:e8 129.199.115.48 garfield.ens.fr
08:00:20:03:98:13 129.199.115.49 betty-boop.ens.fr
8.5 Bibliographie.
Le lecteur pourra se reporter aux articles suivants :
[Bar93] Doug Barr. Ethernet Network Questions and Answers. Technical report, University of
Colorado, Boulder, 1993,
URL ftp://thor.ece.uc.edu/pub/sun-faq/FAQs/ethernet.faq
[Iri93] Wes Irish. Performance problems on high utilization Ethernets. Technical report, Xeros
PARC, 1993,
URL ftp://ftp.utexas/edu/pub/netinfo/ethernet/misc/ethernet-bugs/irishenet-bug-posting
[Med93] Mark Medici. Ethernet Network Questions and Answers. Technical report, 1993,
URL ftp://ftp.utexas.edu/pub/netinfo/ethernet/ethernet-faq/ethernet-faq
[Met93] Bob Metcalfe. Ethernet chip bugs? Technical report, InfoWorld, 1993,
URL
ftp://ftp.utexas.edu/pub/netinfo/ethernet/misc/ethernetbugs/metcalfe-enet-bug-columns
[MJ92] Steven McCanne and Van Jacobson. The BSD Packet Filter: A New Architecture for
User-level Packet Capture. Technical report, Lawrence Berkeley Laboratory, 1992,
URL ftp://ee.lbl.gov/papers/bpf-usenix93.ps.Z
[Pat93] Michael A. Patton. List of codes used on 802.3 and EtherNet networks. Technical report,
Laboratory for Computer Science, Massachusetts Institute of Technology, 1993,
URL
ftp://ftp.utexas.edu/pub/netinfo/ethernet/ethernet-numbers/mitethernet-numbers.txt
[Rol91] Pierre Rolin. Reseaux locaux, normes et protocoles, 4e edition revue et augmentee. Editions HERMES, 1991.
[Spu93] Charles Spurgeon. Network Reading List: TCP/IP, UNIX, and Ethernet. Technical
report, UTnet Network Information Center, University of Texas at Austin, 1993,
URL ftp://ftp.utexas.edu/pub/netinfo/ethernet/net-read-ethernet.ps
108
[Spu94a] Charles Spurgeon. Guide to Ethernet. Technical report, Networking Services, University
of Texa at Austin, 1994,
URL ftp://ftp.utexas.edu/pub/netinfo/ethernet/ethernet-guide-A4.p
[Spu94b] Charles Spurgeon. Guide to Ethernet Conguration. Technical report, Networking Services, University of Texas at Austin, 1994,
URL ftp://ftp.utexas.edu/pub/netinfo/ethernet/ethernet-config-A4.ps
[Spu94c] Charles Spurgeon. SQE test (AKA Heartbeat and CPT). Technical report, Networking
Services, University of Texa at Austin, 1994,
URL
ftp://ftp.utexas.edu/pub/netinfo/ethernet/misc/ethernet-sqe/sqe-test.ps
[Tha93] Pat Thaler. Re: Performance problems on high utilization Ethernets. Technical report,
Roseville Networks Division, 1993,
URL ftp://ftp.utexas.edu/pub/netinfo/ethernet/misc/ethernet-bugs/thalerenet-bug-posting
109
110
111
PACKETFILTER
112
PACKETFILTER
packetfilter
bpfilter 4
113
AA ssuuiivvrree
A suivre
NetBSD
A suivre
SunOS 4.1.x
On peut utiliser le mode promiscuous a condition de le congurer au niveau du chier
de conguration du noyau /usr/sys/kvm/harchitecturei/conf/hlenamei de la facon
suivante :
#
# The following are for streams NIT support. NIT is used by
# etherfind, traffic, rarpd, and ndbootd. As a rule of thumb,
# NIT is almost always needed on a server and almost never
# needed on a diskless client.
#
pseudo-device
snit
# streams NIT
pseudo-device
pf
# packet filter
pseudo-device
nbuf
# NIT buffering module
Solaris 2.x On peut utiliser le mode promiscuous sous Solaris (une commande est d'ailleurs fournie
utilisant le mode promiscuous : /usr/sbin/snoop) ; se reporter a la page de manuel
de pfmod.
SIG
0
PROC(PID)
0(26359)
114
Filters:
#
COUNT
0
20
QueueElts:
LOC
LINK-QUEUE
COUNT
TIME
% /usr/bin/pfstat
[...]
Desq(95ba4030): 0/256 open files [95ba4030,95ba4030]:
AllDescriptors:
#
LOC
LINK-QUEUE STATE WAIT-QUEUE NQ'D
TOUT MODE
Filters:
#
COUNT
QueueElts:
LOC
SIG
PROC(PID)
LINK-QUEUE
COUNT
TIME
% ifconfig -au
ed0: flags=c943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK2,MULTICAST> mtu 1500
inet 193.56.58.65 netmask 0xffffff00 broadcast 193.56.58.255
ether 00:00:e8:cf:70:f4
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
La valeur numerique de flags (en hexadecimal) indique si l'interface est mode promiscuous :
% grep 'define.*PROMISC' /usr/include/net/if.h
#define IFF_PROMISC
0x100
/* receive all packets */
Dans le deuxieme cas, le troisieme chire (a partir de la droite) indique que l'interface
est donc en mode promiscuous. On le voit aussi bien s^ur au mot PROMISC.
HP-UX 10.01
Utiliser la commande /usr/sbin/ifconfig. Toutefois, le resultat n'est pas ache clairement comme avec SunOS, mais oblige a faire un peu d'arithmetique (tres simple)
hexadecimale. Lorsque l'interface fonctionne normalement, ifconfig renvoit :
sweet# ifconfig lan0
lan0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING>
inet 193.51.25.64 netmask ffffff00 broadcast 193.51.25.255
115
La valeur numerique de flags (en hexadecimal) indique si l'interface est mode promiscuous :
sweet# grep 'define.*PROMISC' /usr/include/net/if.h
#define IFF_PROMISC
0x100
/* receive all packets */
Linux
Dans le deuxieme cas, le troisieme chire (a partir de la droite) etant pair, l'interface
est donc en mode promiscuous.
(les adresses IP sont fantaisistes).
Utiliser la commande /sbin/ifconfig. Lorsque l'interface fonctionne normalement,
ifconfig renvoit :
minux# /sbin/ifconfig eth0
eth0
Link encap:10Mbps Ethernet HWaddr 02:60:8C:4A:38:15
inet addr:193.56.58.88 Bcast:193.56.58.255 Mask:255.255.255.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:810055 errors:44 dropped:44 overruns:43
TX packets:933784 errors:0 dropped:0 overruns:0
Interrupt:5 Base address:0x310 Memory:c8000-ca000
NetBSD 1.0
A suivre
A suivre
SunOS 4.1.x
Quand une station Sun travaille en mode promiscuous, la commande /etc/ifconfig
indique l'etat de l'interface reseau :
# ifconfig -a
le0: flags=163<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC>
inet 129.199.115.40 netmask fffff800 broadcast 129.199.119.255
ether 8:0:20:4:b:a
lo0: flags=49<UP,LOOPBACK,RUNNING>
inet 127.0.0.1 netmask ff000000
On dispose aussi d'une commande specialisee dans la detection de de mode de fonctionnement : ftp://ftp.urec.fr/pub/securite/Unix/Logiciels/cpm.1.0.tar.Z
Solaris 2.x Il n'est pas possible jusqu'a la version 2.4 (comprise) de solaris de determiner si une
interface a ete placee en mode promiscuous.
From: [email protected] ( Mark Graff )
Subject: promiscuous mode on solaris 2.x
Date: Thu, 4 May 1995 17:38:58 -0700
This has been discussed several times here, but it's been a while. Here is my current
understanding of the situation.
First, this problem is completely solved for SunOS 4.1.x. I am aware of two main approaches. Let me know privately if you want details.
The situation is much more complicated for Solaris 2.x.
1. The PROMISC feature in the Solaris 2.x ifcong is broken. The ifcong program
will not report the controller to be in promiscuous mode, even if it is. (This feature
works ne in 4.1.x.)
116
2. No generally available public domain software does the job either. I have seen some
promising starts toward a promiscuous-mode detection scheme for Solaris 2.x, and
I believe it is possible, and even feasible. But nothing is available today so far as I
know.
3. Since the problem was pointed out last year Sun has taken a careful look at the
problem. The technical diculty{and now we approach the edge of my expertise{is
that the DLPI interface between the kernel and the device drivers does not provide
for transport of the needed data. That is, the protocol does not provide for a general
(device-independent) way for the kernel to nd out from the ethernet controller the
state of the "promiscuous mode"
ag.
4. I have seen some code{not from Sun{which comes very close to solving the problem
by checking the status
ags on each interface card. Unfortunately the only way to
do this seems to be to read directly through the kvm interface. This means (as I
understand it) that a program that ran on all congurations would require specic
code for each supported ethernet interface card. That might seem like a small set;
but when you consider that Solaris 2.4 now runs on x86 as a coequal platform, this
is a real complication.
5. The code I refer to above will not run successfully on at least of our major hardware
platforms. I am not sure why but know that that is being looked at now, today.
It may be a bug on our side; and I can't think of any reason we wouldn't x it, if
it is. My understanding is that Sun has no current plans to either (1) develop our
own general solution or (2) release and/or support a public domain program to do
the job. If, however, I personally become aware of a solution to the problem which
is reliable and generally useful, I will make that information known here.
This is the situation as I understand it today. Please contact me personally for any
followup. I am not trying to give an ocial position statement here{just ll some folks
in on what I know of the issues.
Mark Gra
Sun Security Coordinator
[email protected]
[email protected]
117
On le trouvera sous formes de sources dans le logiciel tcpdump 2.2.1 (mais cela ne
peut ^etre utile que si vous beneciez des sources de votre kernel).
URL : ftp://ftp.ee.lbl.gov/old/tcpdump-2.2.1.tar.Z.
L'article d'URL ftp://ee.lbl.gov/papers/bpf-usenix93.ps.Z decrit le fonctionnement de BPF.
tcpdump URL : ftp://ftp.ee.lbl.gov/tcpdump-3.0.2.tar.Z
URL : ftp://ftp.ee.lbl.gov/libpcap-0.0.6.tar.Z
C'est l'utilitaire le plus polyvalent.
On en trouvera des versions ameliorees sur ftp.inria.fr :
URL : ftp://ftp.inria.fr/network/tools/tcpdump-3.0.2+.tar.gz
URL : ftp://ftp.inria.fr/network/tools/libpcap-0.0.6+.tar.gz
Bien s^ur, cet utilitaire ne peut fonctionner correctement que si le systeme ore le
passage en mode promiscuous.
packetman
Suite etherman, interman, loadman
URL ftp://ftp.cs.curtin.edu.au//pub/netman/harchitecturei/packetman-1.2.tar.gz
URL ftp://ftp.cs.curtin.edu.au//pub/netman/harchitecturei/etherman-1.1a.tar.gz
URL ftp://ftp.cs.curtin.edu.au//pub/netman/harchitecturei/analyser-1.0.tar.gz
URL ftp://ftp.cs.curtin.edu.au//pub/netman/harchitecturei/loadman-1.1.tar.gz
URL ftp://ftp.cs.curtin.edu.au//pub/netman/harchitecturei/interman-1.1.tar.gz
Packetman is a retrospective Ethernet packet analyser. This tool allows the capture
and analysis of an Ethernet packet trace.
Ces programmes ne sont disponibles qu'en versions binaires pour un certain nombre
d'architectures (DEC OSF1 et ULTRIX, IRIX, SunOS 4.1.x, Solaris 2.x).
,
,
ftp://ftp.germany.eu.net/pub/networking/inet/ethernet/ethdp103.zip
ftp://ftp.germany.eu.net/pub/networking/monitoring/ethload/ethld104.zip
9.5 Bibliographie.
Le lecteur pourra se reporter aux newsgroups consacres aux dierents systemes (cf [Generalites
sur les systemes abordes], page 7).
Il existe aussi le newsgroup comp.dcom.lans.ethernet.
Il existe une FAQ sur Ethernet, d'URL ftp://steph.admin.umass.edu/pub/faqs/ethernet.faq.
118
119
120
121
, La designation d'une station necessitant une adresse ou un equivalent dans tout protocole,
l'adresse IP est assignee de maniere tout a fait independante des adresses materielles des
interfaces reseaux. Par exemple, les adresses physiques Ethernet sont sur 48 bits alors que les
adresses IP sont actuellement sur 32 bits. Il n'y a, a priori, strictement aucun lien entre une
adresse physique et une adresse IP.
, Le protocole IP se veut independant de tout support physique. Cela se repercute au niveau des
tailles des paquets IP. La taille minimale de paquet que supporte IP est 576 octets ; la taille
maximale est imposee par le support physique (extrait de la RFC 1191) :
Support physique
MTU IP
Ocial maximum MTU
65535
Hyperchannel
65535
16Mb IBM Token Ring
17914
IEEE 802.4
8166
IEEE 802.5 (4Mb max)
4464
FDDI (Revised)
4352
Wideband Network
2048
IEEE 802.5 (4Mb recommended)
2002
Exp. Ethernet Nets
1536
Ethernet Networks
1500
Point-to-Point (default)
1500
IEEE 802.3
1492
SLIP
1006
ARPANET
1006
X.25 Networks
576
DEC IP Portal
544
NETBIOS
512
IEEE 802/Source-Rt Bridge
508
ARCNET
508
Point-to-Point (low delay)
296
Ocial minimum MTU
68
Comme un paquet IP est susceptible de transiter par n'importe quel type de support physique
possible, il peut arriver qu'un paquet ait une taille trop grande a un moment de son voyage. Il
sera alors fragmente en autant de paquets IP plus petits assimilables par la couche physique a
traverser. Seule la machine destination reassemble des fragments d'un paquet.
122
Au dessus d'IP existent d'autres protocoles : ICMP, UDP, TCP. Chacun de ces protocoles,
denit une structure de donnees qu'un paquet IP encapsule, le paquet IP etant lui m^eme encapsule
dans une trame du support physique ; pour le cas d'Ethernet, cela donne :
Trame Ethernet
header
Ethernet
trailer
Ethernet
data
Trame Ethernet
Trame Ethernet
Trame Ethernet
Trame IP
header
Ethernet
Trame ARP
header
Ethernet
trailer
Ethernet
trailer
Ethernet
header
IP
Trame Ethernet
trailer
Ethernet
Trame Ethernet
Trame IP
Trame IP
header
Ethernet
trailer
Ethernet
header
IP
Trame IP
header
Ethernet
Trame ICMP
header
Ethernet
Trame UDP
trailer
Ethernet
header
IP
Trame TCP
Un autre point fondamental dans le fonctionnement d'IP, est son mecanisme d'adressage. La
procedure a suivre pour obtenir des adresses IP est decrite au chapitre suivant (cf section 11.2
[Aspect administratif du DNS : enregistrement d'un domaine.], page 150) car l'attribution de numeros IP est par nature etroitement liee a la notion de domaine et donc liee au DNS. La version
actuelle d'IP (version 4) utilise des adresses sur 32 bits, chaque machine se voyant donc attribuer
une adresse que l'on ecrit sous la forme numerique a.b.c.d ou a, b, c, d prennent des valeurs entre
0 et 255 (sachant que les valeurs 0 et 255 ont des signications particulieres). Cette adresse IP est
censee ^etre unique au monde sinon des con
its apparaissent ; en fait, les con
its surgissent vraiment
si l'on a la m^eme adresse plusieurs fois sur le m^eme reseau local : des messages du type duplicate
IP address apparaissent alors. Chaque paquet IP transporte les adresses IP de la machine source
et de la machine destination selon le format :
0
Version
IHL
16
TTL
Longueur totale
Type de service
Identification
31
Flags
Protocole
Offset du fragment
Checksum
Adresse source
Adresse destination
Options
Padding
123
Les numeros IP ne s'attribuent pas au petit bonheur la chance. Ils sont attribues dans des
tranches que l'on appelle des numeros de reseau. On peut decomposer une adresse en deux parties,
une partie xe a partir de laquelle on peut incrementer une partie variable ; on appelera hostid la
partie modiable a volonte et netid la partie xe. Suivant le nombre de bits de la partie xe, on
distingue cinq1 types dits classes de numeros IP :
Classe A
Un site possede un adressage IP de classe A s'il est libre de choisir les champs b, c et
d pour identier ses machines. Un tel r
eseau peut donc supporter 16777214 machines.
7 bits
Classe B
24 bits
netid
hostid
Un site possede un adressage IP de classe B s'il est libre de choisir les champs c et d
pour identier ses machines. Un tel reseau peut donc supporter 65534 machines.
14 bits
Classe C
16 bits
netid
hostid
Un site possede un adressage IP de classe C s'il est libre de choisir le champ d pour
identier ses machines. Un tel reseau peut donc supporter 254 machines.
21 bits
Classe D
8 bits
netid
hostid
C'est une plage d'adressse Internet reservees a des utilisations bien particulieres.
28 bits
Classe E
multicast groupid
C'est une plage d'adressse Internet reservees pour des extensions non encore denies a
ce jour.
27 bits
Plage
0.0.0.0 a 127.255.255.255
128.0.0.0 a 191.255.255.255
192.0.0.0 a 223.255.255.255
224.0.0.0 a 239.255.255.255
240.0.0.0 a 247.255.255.255
La RFC 1375 proposa d'autres types de classe mais ceux-ci ne furent jamais adoptes.
124
et 0.b.c.d
Ces adresses sont utilisees temporairement pendant des phases d'initialisation et ne
doivent pas ^etre utilisees en pratique.
127.X.Y.Z
localhost
10.0.0.0
a 10.255.255.255 (un reseau complet de classe A)
172.16.0.0
a 172.31.255.255 (16 reseaux complets contigus de classe B)
192.168.0.0
a 192.168.255.255 (256 reseaux complets contigus de classe
C)
Ces plages d'adresses correspondent a des tranches reservees servant a constituer des
reseaux qui ne seront jamais interconnectes directement a Internet. Typiquement une
entreprise sachant qu'elle ne se raccordera jamais a l'Internet, peut utiliser ces tranches
pour numeroter ses machines et n'a pas besoin de faire la demande ocielle de numeros
de reseaux. Ces tranches de numeros ainsi que leur utilisation sont decrites dans le RFC
1597 (Address Allocation for Private Internets).
L'utilisation de ces tranches d'adresses n'est cependant pas recommandee.
D'autres valeurs ne sont pas non plus disponibles (cf section 10.4 [Broadcast], page 127).
Une derniere precision sur l'ecriture de l'adresse IP : utiliser toujours des valeurs numeriques
decimales. La page de manuel a propos des adresses IP (inet (3)) dit, en eet, que :
All numbers supplied as parts in dot notation can be decimal, octal, or hexadecimal,
as specied in the C language (i.e., a leading 0x or 0X implies hexadecimal; a leading
0 implies octal; otherwise, the number is interpreted as decimal).
ce qui veut dire que l'adresse 129.199.115.040 est en fait 129.199.115.32. . .
, un reseau de classe B a beau orir 65534 adresses, il n'existe pas de support physique pouvant
supporter autant de peripheriques sur un seul segment ;
, la situation est quasiment identique pour un reseau de classe C ;
, on ne peut presque plus obtenir de reseaux de classe B de nos jours.
125
Bref, le real world conduit assez souvent a pratiquer une repartition en dierents lots des adresses
IP disponibles de facon a ce qu'un lot re
ete la situation physique en place. Cette pratique porte
le nom de subnetting, de decoupage en sous reseaux.
Un sous-reseau sera donc le reseau logique constitue des stations sur un certain segment physique,
delimite par un ou des routeurs.
La determination de l'appartenance d'une station A a un sous-reseau se fait a partir de l'adresse
IP de A et d'une quantite qu'on appelle le subnet mask ou netmask. C'est une valeur numerique
qui, appliquee selon un ET logique avec l'adresse IP de A, va donner le numero du sous-reseau sur
lequel reside A.
Par exemple, si dans un laboratoire, on doit considerer que les stations d'adresses dans la plage
a 129.199.127.255 font partie du m^eme reseau logique, le netmask a utiliser est
qui conduit au numero de sous reseau 129.199.112.0 :
129.199.112.0
255.255.240.0
...
&
10000001.11000111.01110000.XXXXXXXX
10000001.11000111.01110001.XXXXXXXX
10000001.11000111.01110010.XXXXXXXX
(129.199.112.X)
(129.199.113.X)
(129.199.114.X)
10000001.11000111.01111101.XXXXXXXX
10000001.11000111.01111110.XXXXXXXX
10000001.11000111.01111111.XXXXXXXX
(129.199.125.X)
(129.199.126.X)
(129.199.127.X)
11111111.11111111.11110000.00000000
<--------------------><----------->
10000001.11000111.01110000.00000000
(255.255.240.0)
(129.199.112.0)
126
/usr/sbin/netsetup.
FreeBSD 2.0.5
Le netmask se regle dans le chier /etc/sysconfig :
[...]
#
# Set to the list of network devices on this host. You must have an
# ifconfig_$network_interface line for each interface listed here.
# for example:
#
#
network_interfaces="ed0 sl0 lo0"
#
ifconfig_ed0="inet 10.0.0.1 netmask 0xffffff00"
#
ifconfig_sl0="inet 10.0.1.0 netmask 0xffffff00"
#
network_interfaces="ze0 lo0"
ifconfig_lo0="inet localhost"
ifconfig_ze0="inet 192.25.85.24 netmask 255.255.255.0"
[...]
127
esac
[...]
HP-UX 10.01
On peut regler le netmask via sam. On peut aussi le faire manuellement de
la facon suivante : dans la partie Internet conguration parameters du chier
/etc/rc.config.d/netconf, mettre la bonne valeur de netmask :
[...]
INTERFACE_NAME[0]=lan0
IP_ADDRESS[0]="129.104.10.50"
SUBNET_MASK[0]="255.255.255.0"
BROADCAST_ADDRESS[0]=""
LANCONFIG_ARGS[0]="ether"
[...]
Linux 1.2.1
NetBSD 1.0
hinterfacei qui
/etc/hostname.
Ces chiers sont consultes par /etc/netstart lui m^eme appele par /etc/rc.
SunOS 4.1.x
Le reglage se fait dans /etc/rc.local par une ligne du type :
[...]
ifconfig le0 `hostname` netmask 255.255.240.0 broadcast 129.199.112.0 up > /dev/null 2>&1
[...]
Nous rappelons que sur SunOS-4.1.x, l'adresse de broadcast est calculee de maniere
fausse (cf section 10.4 [Broadcast], page 127).
Solaris 2.x Les shell{scripts /etc/init.d/inetsvc et /etc/init.d/rootusr s'occupent de congurer les interfaces. La valeur du netmask est recuperee a partir de NIS+ ou du chier
/etc/netmasks. Ainsi, pour la station d'adresse IP 129.199.99.26, on trouve dans le
chier /etc/netmasks :
129.199.0.0
255.255.240.0
10.4 Broadcast.
Faire un broadcast IP consiste a envoyer un ou plusieurs paquets IP a destination de toutes les
stations du reseau logique. C'est une pratique courante quand il s'agit de rechercher sur le reseau
128
une station possedant une certaine ressource mais dont on ne conna^t pas l'adresse (recherche d'un
serveur NIS, diusion d'informations pour actualiser la table de routage. . .).
Etant donne qu'une station ne peut pas conna^tre a tout instant toutes les autres stations
fonctionnant sur le reseau, le mecanisme de broadcast doit s'appuyer sur un mecanisme de diusion
au niveau du support physique. Par exemple, un broadcast de nature IP se traduira, si le support
est Ethernet, par l'envoi de trames Ethernet a l'adresse physique ff:ff:ff:ff:ff:ff.
Du point de vue IP, comment specie-t-on une intention de broadcast ? Tout simplement en
envoyant un paquet avec pour adresse de destination une adresse speciale dite adresse de broadcast.
Cette adresse de broadcast se determine a partir du netmask : l'adresse de broadcast est calculee
en fonction de l'adresse de reseau en mettant tous les bits de la partie variable propre a chaque
adresse de station a 1. Par exemple :
La station excalibur.ens.fr (129.199.115.40) a pour netmask 255.255.240.0 (ce
qui signie que les 16 reseaux 129.199.112.x a 129.199.127.x sont consideres comme
appartenant a un m^eme reseau logique). Elle broadcaste donc en :
&
7!
10000001.11000111.01110011.00100100
11111111.11111111.11110000.00000000
<--------------------><----------->
identificateur
identificateur
de reseau
de machine
(129.199.115.40)
(255.255.240.0)
10000001.11000111.0111XXXX.XXXXXXXX
| ~
hnetmaski
129
c 1989. Permission to copy without fee all or part of this material is granted provided
Copyright
that the copies are not made or distributed for direct commercial advantage. Copies must show the
University of Texas at Austin as the source, and include this notice.
July 3, 1989
The broadcast storm and the packet avalanche are phenomena that occur on campus internets
or any LAN of sucient complexity and population density. Campus internets are perhaps more
vulnerable to these events due to the less structured environment in which they operate.
Campus network users typically have a high degree of autonomy and are free to buy any kind of
equipment they like and attach it to the network system. Very often the rst indication the network
manager has that there's a new device on the system is that it's causing a broadcast storm.
A packet avalanche is a situation where a single packet triggers an avalanche of responses. A
broadcast storm is a set of packets sent to the Ethernet broadcast address at suciently high volume
to cause problems for many hosts on the network. Packet avalanches composed of broadcast packets
form the worst case of the broadcast storm.
There appear to be three basic causes of these phenomena:
, Broken protocols.
, Broken congurations.
, Broken implementations.
130
bridges to construct a "wide area" LAN, then every host in the wide area network gets to hear
the game broadcasts as well. If the incorrect IP broadcast address is used a rapid sequence of
broadcast storms based on packet avalanches can be generated by this game. See below.
It's also the case that even when the correct IP broadcast address is used, sending streams of
UDP datagrams wrapped in IP broadcast packets that are destined for unknown UDP ports
developed for game software causes problems. While hosts are not supposed to respond to
broadcast packets, many do, and in this case the simultaneous transmission of ICMP packets
complaining about an unknown UDP port on the part of hundreds of workstations that saw
these broadcast packets causes a local collision burst that also aects the throughput of the
Ethernet.
3. Another example of a dependence on the Ethernet broadcast address is seen in the ICMP
netmask discovery mechanism. A host wishing to discover the netmask for a network may send
a request to the IP broadcast address. Many (most) hosts are currently programmed to answer
that request, leading to bursts of netmask replies. These replies are even sent to the broadcast
address at times, depending on how broken the netmask implementation on the host is.
131
simultaneously sees the packet with the ones IP broadcast address. Not knowing that this is a
legitimate broadcast address and not having an entry in their routing tables for this address,
the hosts consult their gateway code for instructions.
The gateway code says "attempt to forward the packet to its proper destination." (Fundamental
Flaw #2) In order to do this, the host tries to nd an Ethernet address associated with the
IP address of 128.83.255.255. So now every such host simultaneously sends an ARP request to
the Ethernet broadcast address to resolve the 128.83.255.255 address. This is the heart of the
avalanche eect that ensures a maximum sized broadcast storm. It's also known as an ARP
storm, for obvious reasons.
Since most of these hosts are the same machine type running the same kernel in the same CPU
architecture, they all hit the Ethernet wire pretty much simultaneously, causing a large local
collision burst along with the large burst of successful packets sent to the Ethernet broadcast
address.
Finally, the gateway software on these hosts sends an Internet Control Message Protocol packet
back to the original sender of the IP broadcast stating "Destination Unreachable". Since these
are directed packets, only the poor sending host sees them all, although it is likely that there's
another collision burst on the local wire due to the simultaneous transmission of all these
packets. The collision eect is local to the wire that is attached to the sending hosts. In this
case the ICMP avalanche is causing a LAN collision saturation that is roughly simultaneous
with the broadcast storm.
If the sending host is sending a lot of packets to the "incorrect" IP broadcast address, the
havoc raised by this behavior can reach truly colossal proportions. The network eectively quits
working for hosts with anything less than high MIP CPUs, and high performance Ethernet
interfaces.
Luckily, many new UNIX systems are based on BSD 4.3 UNIX. That release of UNIX does
not have gateway code enabled by default, so it will NOT automatically perform ipforwarding.
Nor will it make a response to any possible form of the zeros or ones IP broadcast. As hosts
migrate to the newer UNIX releases the IP broadcast storms and packet avalanches should
begin to abate. Nonetheless, many implementations of TCP/IP were based on the older BSD
4.2 UNIX and examples of these machines are likely to persist on campus for some time.
2. Severe Avalanche Storms
Severe avalanche storms can produce so many broadcasts that the hosts on an Ethernet system
cannot deal with them and the network appears to \freeze up." Miscongured or malfunctioning
UNIX systems used as gateways have been observed to forward packets out the interface they
were heard on over and over again until the Time To Live eld expires. This leads to 255 packets
being sent out for every one received. If the packet being forwarded is a netmask request sent
to the \wrong" IP broadcast address, for instance, than every time the packet is forwarded, it
can cause an ARP storm on the part of all other hosts on a bridged network that are trying
to forward packets as well. This can lead to enormous ARP storms with packets being sent to
the Ethernet broadcast address at rates of 2-3,000/sec. Broadcast packets at this rate cause
nearly all hosts to run out of resources for dealing with them.
132
generation of name lookup requests. These requests were sent to the Ethernet broadcast address
at a rate of over 400 packets per second and the resultant storm was seen on the entire network
due to the bridged architecture.
2. At Stanford University ULTRIX V2.? generated enough response packets to freeze up the
external gateway connection to the outside networks. A broken TCP/IP retransmission timer
allowed the ULTRIX system to instantly respond to a gateway ICMP Dest. Unreach. packet
with a retransmission of the packet that generated the error. The result was a VAX 8800
throwing packets at the MC68000-based gateway as fast as it could, endlessly. Needless to
say the gateway became unavailable to other users and outside network access to Stanford
ceased. Interestingly enough, this failure mode was propagated through two other intervening
IP gateways in a demonstration of the fact that IP gateways are not perfect "rewalls" for all
possible network protocol failures.
3. At Stanford, early releases of AIX for PC/RTs contained a netmask bug that resulted in
incorrect netmask broadcasts. These incorrect netmasks were propagated to the network via
Ethernet broadcast. Any host that heard this netmask would proceed to stop sending any and
all packets due to having a totally incorrect mask for routing. This was xed by adding sanity
checking to netmask sends and receives. Luckily the Stanford campus internet was entirely
subnetted with gateways, so that this bug was limited to the departments with PC/RTs and
did not propagate over the entire campus as it would have through a bridged system.
Even normal netmask replies can cause problems when a newly booted host sending a broadcasted netmask request gets back scores of netmask replies sent to broadcast as well. These
\normal" events cause mini broadcast storms and as more hosts are given the ability to reply
to netmask requests, the problem worsens.
Recently a major workstation vendor's software changed with the result that their hosts would
accept any broadcasted netmask value they saw as their new netmask value. On a large bridged
network it is not dicult for a miscongured host to send out an incorrect netmask reply. This
causes all of these workstations to adopt the incorrect value and aects their ability to route
packets.
Most broken implementations that manage to aect an entire network are based on the use of
Ethernet broadcasts. In large bridged networks these problems propagate widely and cause major
trac bursts due to the MAC level interaction of all stations that bridged network architectures
enforce. In the case of the retransmission bug described above, it took the combination of the fact
that a very fast host was broken and that it was interacting with a critical network resource to
bring the bug to the attention of the entire campus community.
10.6 Multicast.
Le multicast correspond a une diusion IP bien particuliere et peu utilisee en dehors d'applications bien speciales comme la video-conference et autres aspects du multimedia. On peut toutefois
predire que l'utilisation du multicast va se developper considerablement dans un futur pas si lointain.
Les systemes recents (IRIX 5.x, Solaris 2.x, DEC OSF1 3.x, HP-UX 10.01, AIX 4.1.x) sont
capables d'utiliser le multicast ; pour les autres systemes, on aura a recongurer le noyau en y
integrant des patches.
Pour plus de details, se reporter aux URL
http://www.univ-rennes1.fr/CRU/Multicast.
http://www.lbl.gov/ctl/vconf-faq.html
et
133
134
hIFi:hNi hip-addressi
ifconfig
hIFi:hNi
up
ou hIFi est un nom d'interface (par exemple le0), ou hNi est un nombre entre 1 et 255.
On retire une adresse virtuelle par :
0.0.0.0 down
,
,
http://www.your.net/multi-homed/
http://www.thesphere.com/~dlp/TwoServers/
10.8 Routage.
Maintenant que votre station est physiquement raccordee a un reseau et qu'elle sait entrer en
contact avec les stations du m^eme segment physique, attaquons{nous au probleme consistant a
rentrer en contact avec les stations en dehors du segment.
C'est ce que l'on appelle le probleme du routage. En pratique, il s'agit de trouver un chemin
indiquant a chaque etape le relais suivant en fonction de la destination nale.
Pour arriver a cela, chaque machine dispose d'une table de routage indiquant l'interface physique
reliee a un segment et le next{hop a utiliser en fonction de la destination des datagrammes.
Apres consultation de cette table, un paquet IP est envoye sur une certaine interface (qui determine donc le type d'encapsulation realisee) a destination du next-hop qui le desencapsulera et
le fera suivre selon ses propres tables de routage. Le processus se repete jusqu'a ne pas trouver de
chemin ou jusqu'a ce que le segment de la machine nale soit atteint.
Nous n'entrerons pas dans les problemes de conguration de bo^tiers routeurs (comme les routeurs Cisco), ni dans les problemes de conguration de stations utilisees en routeurs. Ces problemes
sont en eet trop speciques en general des congurations des reseaux sur lesquels se trouvent ces
appareils ; des regles de conguration du routage peuvent exister sur votre site ; nous ne connaissons
pas les materiels a votre disposition.
Bref, nous ne parlerons donc ici que d'une chose : congurer un routage par defaut sur votre
machine ce qui permet de rentrer en contact avec les stations directement sur votre reseau (ou
sous{reseau) et sinon de rentrer en contact avec un routeur qui est suppose avoir ete bien congure.
, routage statique ;
, routage dynamique (demons routed, gated. . .) c'est{a{dire mise a jour des informations de
routage par echange de messages entre les routeurs.
135
Nous utiliserons le routage statique. Cela presente plusieurs avantages mais aussi quelques inconvenients :
, C'est le choix le plus simple et le plus ecace quand la situation est simple et qu'en fait il n'y
a pas de choix possible (cas d'une machine ordinaire sur un site avec un seul routeur) ;
, Comme les routes ne sont pas calculees par un protocole, on peut s'aranchir des limitations
des protocoles existants et realiser n'importe quelle strategie ou politique ;
, Les tables de routage ne sont pas diusees par un protocole, ce qui rend la gestion plus dicile,
en particulier pour installer un nouveau routeur ;
, Le routage statique ne s'adapte pas aux changements (conguration, topologie, trac. . .).
Autrement dit, il faut utiliser le routage statique seulement pour une topologie simple comme
c'est le cas pour un sous-reseau relie au monde exterieur via un seul lien.
devrait pas chercher a joindre C ou parce que l'interface de B vers C est hors{service) ;
, un datagramme pour C est injecte entre A et B ;
, A envoie le datagramme a B d'apres sa route ;
, B n'ayant pas de route vers C, le routage par defaut de B s'applique et le datagramme est
envoye vers A et on boucle. . .
machine
C
machine
A
Destination
Router par
Destination
C
default
Datagramme a
destination de C
Router par
""
A
machine
quelconque
machine
B
136
La boucle est heureusement detectee gr^ace a un champ du paquet IP (le champ TTL) qui est
decremente a chaque passage dans un routeur et provoque, lorsqu'il atteint la valeur 0, l'emession
d'un paquet ICMP de type TTL exceeded.
>>$LOGFILE 2>&1
>>$LOGFILE 2>&1
FreeBSD 2.05
C'est le chier /etc/sysconfig qui initialise le routage.
[...]
# Set to the host you'd like set as your default router, or NO for none.
defaultrouter=gateway.lps.ens.fr
[...]
esac
[...]
HP-UX 10.01
Le routage se congure au niveau du chier /etc/rc.config.d/netconfig :
[...]
# Internet routing configuration.
[...]
ROUTE_DESTINATION[0]="default"
ROUTE_MASK[0]=""
ROUTE_GATEWAY[0]="129.104.10.13"
ROUTE_COUNT[0]="1"
ROUTE_ARGS[0]=""
[...]
esac
Linux 1.2.1
137
138
NetBSD 1.0
C'est le chier /etc/netstart (appele par /etc/rc) qui lance le routage en consultant
le chier /etc/mygate. qui contient l'adresse IP ou le nom du routeur par defaut.
[...]
# /etc/mygate, if it exists, contains the name of my gateway host
# that name must be in /etc/hosts.
if [ -f /etc/mygate ]; then
route add default `cat /etc/mygate`
fi
SunOS 4.1.x
C'est le chier
/etc/rc.local
/etc/defaultrouter qui contient
[...]
#
# Try to add a default route again, now that "/usr" is mounted
# and NIS is running.
#
if [ ! -f /sbin/route -a -f /etc/defaultrouter ]; then
route -f add default `cat /etc/defaultrouter` 1
fi
[...]
139
de stockage d'une classe B se revele assez souvent en pratique trop grande (qui peut justier d'un
besoin de 65536 adresses actuellement pour son organisme ?).
La gure suivante montre le nombre d'adresses deja allouees ainsi que la tendance depuis
quelques annees :
Total address space allocated
1.6e+09
1.4e+09
Addresses allocated
1.2e+09
1e+09
8e+08
6e+08
4e+08
2e+08
83
84
85
86
87
88
Year
89
90
91
92
93
Si la tendance actuelle se poursuit, on aura epuise l'espace d'adressage actuel en l'an 2004 comme
le montre la gure suivante :
Total address space allocated
5e+09
4.5e+09
4e+09
Addresses allocated
3.5e+09
3e+09
2.5e+09
2e+09
1.5e+09
1e+09
5e+08
83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09
Year
140
Devant ce probleme auquel nous risquons de nous heurter de plein fouet a court terme, deux
mesures ont ete prises :
La RFC 1466 (Guideline for Management of IP Adress Space) decrit la facon dont les reseaux
C sont attribues selon l'importance de la demande.
141
struct routing_entry
{
u_int network ;
u_int aggregate_mask;
u_int router_addr;
};
L'emploi d'un masque d'agregat montre que les blocs d'adresses C doivent toujours ^etre attribues
selon une puissance de 2.
Bien s^ur, l'emploi de CIDR sous-entend l'adoption de protocoles de routage permettant la diffusion des masques d'agregat.
On notera que le masque d'agregat de CIDR permet de decrire aussi les reseaux de classe A, B,
C pour lesquels les masques d'agregat sont simplement :
classe A
classe B
classe C
255.0.0.0
255.255.0.0
255.255.255.0
L'emploi de CIDR depuis quelques mois a permis aux routeurs de ne pas voir leurs tables de
routage continuer a evoluer de facon exponentielle ; la croissance est desormais sensiblement lineaire.
142
http://playground.sun.com/pub/ipng/html.
,
,
,
http://playground.sun.com/pub/ipng/html/ipng-implementations.html
ftp://ftp.inria.fr/network/ipv6/
(merci Francis).
Documents
IPng commence a faire l'objet de certains RFC (parus vers decembre 1995). Cf
http://playground.sun.com/pub/ipng/html/specs/specifications.html
pour
plus de renseignements.
Mailing lists sur IPng
Plusieurs listes son disponibles :
ipv6
Pour s'y abonner, envoyer un mail a [email protected] avec subscribe
ipv6 comme corps de message ou bien consulter http://www.univrennes1.fr/LISTES/[email protected].
ipng
Pour s'y abonner, envoyer un mail a [email protected]
avec subscribe ipng comme corps de message.
Serveurs WWW
,
,
,
,
,
,
http://www.urec.fr/IPng
http://www.univ-rennes1.fr/LISTES/[email protected]
http://playground.sun.com/pub/ipng/html
http://www.cnam.fr/Network/IPng/
http://www.ietf.cnri.reston.va.us/ipng/ipng.html
http://www.ietf.cnri.reston.va.us/ids.by.wg/sipp.html
>
>
143
This is a humorously large address space. Taking a SWAG at the size of the Earth, about 201,062,400
square miles, this comes to around 1,692,421,690,584,308,470,720,406,239,216 addresses per
square mile of Earth's surface, or about 421,578,297,421,497,485,189 addresses per square inch.
Even if we chop o three bytes to indicate galaxy, solar system and planet, we'd still have 25,128,024
addresses per square *mil* here on Earth. Pathology will never be the same after every microbe has
its own address. . .
10.10 Bibliographie.
Le lecteur pourra se reporter aux newsgroups consacres aux dierents systemes (cf [Generalites
sur les systemes abordes], page 7) ainsi qu'a comp.protocols.tcp-ip.
Le lecteur pourra se reporter aux articles suivants :
[FLYV93] V. Fullner, T. Li, J. Yu, and K. Varadhan. Classless Inter-Domain Routing (CIDR):
an Address Assignment and Aggregation Strategy. Technical report, BARRnet, Cisco,
MERIT, OARnet, 1993,
URL ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1519.txt
[Ger93]
E. Gerich. Guidelines for Management of IP Adress Space. Technical report, Merit,
1993,
URL ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1466.txt
[RMKdG94] Y. Rekhtex, B. Miskowitz, D. Karrenberg, and G. de Groot. Address Allocation
for Private Internets. Technical report, T.J. Watson Research Center, IBM Corp.,
Chrysler Corp., RIPE NCC, RIPE NCC, 1994,
URL ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1597.txt
[Rob92]
P. Robinson. Suggestion for New Classes of IP Addresses. Technical report, Tansin
A. Darcos & Co., 1992,
URL ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1375.txt
144
145
fr
pasteur
ens
organisme
ensta
La machine toto est dite dans le domaine division.organisme.fr. En fait, tout nud non
terminal de l'arbre permet de construire un nom de domaine. On distingue quelques domaines
particuliers :
146
, les domaines juste en dessous de la racine dits toplevel domains ; ce sont les toplevel domains
des dierents pays du monde, des prestataires de connectivite, des universites americaines etc.;
cf la norme ISO 3166 dont un URL est ftp://sh.cs.net/country_codes.txt.
Cet arbre se pr^ete tres bien a un modele hierarchise distribue. Le principe du DNS est de resoudre
une requ^ete de type nom de machine en adresse IP, en interrogeant un serveur (dit serveur de noms
ou nameserver) qui possede des informations dans sa base de donnees sur cette machine ainsi que
sur certaines autres. Les machines decrites dans cette base de donnees constituent en general au
moins une sous-arborescence de l'arbre ci{dessus, parfois profonde. Cette arborescence, dont un
nameserver possede les renseignements et pour lesquelles il fait autorite en la matiere, est appelee
une zone et les zones decomposent donc l'espace des noms de machines. Lorsqu'une nouvelle zone
est creee, le nameserver qui la servait avant, perd le contr^ole qu'il exercait sur cette partie de
l'arborescence et en delegue l'autorite au nouveau nameserver. C'est une delegation de zone. Une
consequence importante en est qu'aucun nameserver n'a une vision globale de tout l'arbre. Voici
une vue de l'arbre et de quelques unes de ses zones et des nameservers de ces zones :
zone "."
% nslookup
> set q=ns
> .
Server: falbala.ens.fr
Address: 129.199.115.50
(root) nameserver
(root) nameserver
(root) nameserver
(root) nameserver
(root) nameserver
(root) nameserver
(root) nameserver
(root) nameserver
(root) nameserver
AOS.ARL.ARMY.MIL
AOS.ARL.ARMY.MIL
=
=
=
=
=
=
=
=
=
NS.ISC.ORG
NS.NIC.DDN.MIL
NS.INTERNIC.NET
AOS.ARL.ARMY.MIL
NS1.ISI.EDU
C.PSI.NET
TERP.UMD.EDU
NS.NASA.GOV
NIC.NORDU.NET
inet address = 128.63.4.82
inet address = 192.5.25.82
zone "edu."
zone "fr."
% nslookup
> set q=ns
> fr.
Server: falbala.ens.fr
Address: 129.199.115.50
edu
Nonauthoritative answer:
fr
nameserver = MIRSA.INRIA.FR
fr
nameserver = NS.EU.NET
fr
nameserver = PRINCETON.EDU
fr
nameserver = DNS.CS.WISC.EDU
fr
nameserver = INRIA.INRIA.FR
fr
nameserver = layon.inria.fr
Authoritative answers can be found from:
MIRSA.INRIA.FR inet address = 138.96.32.15
NS.EU.NET
inet address = 192.16.202.11
PRINCETON.EDU
inet address = 128.112.128.1
DNS.CS.WISC.EDU inet address = 128.105.2.10
INRIA.INRIA.FR inet address = 192.93.2.1
layon.inria.fr inet address = 192.93.2.4
fr
zone "jussieu.fr."
zone "ens.fr."
ens
jussieu
excalibur
% nslookup
> set q=ns
> ens.fr.
Server: falbala.ens.fr
Address: 129.199.115.50
% nslookup
> set q=ns
> jussieu.fr.
Server: falbala.ens.fr
Address: 129.199.115.50
Nonauthoritative answer:
jussieu.fr
nameserver =
jussieu.fr
nameserver =
jussieu.fr
nameserver =
Authoritative answers can be
cendrillon.lptl.jussieu.fr
soleil.uvsq.fr inet address
shiva.jussieu.fr
inet
cendrillon.lptl.jussieu.fr
soleil.uvsq.fr
shiva.jussieu.fr
found from:
inet address = 134.157.8.24
= 193.51.24.1
address = 134.157.0.129
ens.fr nameserver =
ens.fr nameserver =
ens.fr nameserver =
ens.fr nameserver =
ens.fr nameserver =
oseille.ens.fr inet
layon.inria.fr inet
lri.lri.fr
inet
dmi.ens.fr
inet
clipper.ens.fr inet
oseille.ens.fr
layon.inria.fr
lri.lri.fr
dmi.ens.fr
clipper.ens.fr
address = 129.199.98.16
address = 192.93.2.4
address = 129.175.15.1
address = 129.199.96.11
address = 129.199.129.1
On retrouve les informations sur les nameservers des toplevel domains dans le chier root.zone
(dont un URL est ftp://ftp.rs.internic.net/domain/root.zone) :
[...]
CN.
NS.CNC.AC.CN.
518400
518400
NS
A
NS.CNC.AC.CN.
159.226.1.1
CN.
IRAUN1.IRA.UKA.DE.
CN.
[...]
518400
518400
518400
518400
518400
NS
NS
NS
A
NS
147
NS.SESQUI.NET.
NS.EU.NET.
IRAUN1.IRA.UKA.DE.
129.13.10.90
NS.UU.NET.
Dans la pratique, comment fait-on pour resoudre un nom de machine en adresse IP ? Imaginons
que l'on souhaite resoudre l'adresse de toto.division1.organisme.fr.
1. On interroge un nameserver par defaut, le nameserver attitre du systeme.
2. Ce nameserver, s'il ne conna^t pas les informations sur la machine cherchee, transmettra la
requ^ete aux nameservers de la racine (tout nameserver conna^t obligatoirement les nameservers
de la racine de l'arbre pour pouvoir faire cela).
3. Un des nameservers de ".", a la vue du contenu de la requ^ete, determine le toplevel domain
concerne et renvoit les adresses des nameservers de ce toplevel, donc ici la liste des nameservers
de la zone .fr.
4. Le nameserver attitre du systeme contacte alors ces dierents nameservers du toplevel domain
.fr. Ceux-ci, soit poss
edent la reponse, soit ne la possedent pas. Dans ce dernier cas, on
analyse davantage le domaine precise dans la requ^ete et on determine une nouvelle liste de
nameservers a contacter connaissant mieux le domaine recherche. Ici, on recevrait donc la liste
des nameservers de la zone organisme.fr.
5. Ainsi de suite jusqu'a tomber sur un nameserver connaissant la machine dont on recherche
l'adresse IP.
Cela donne le schema suivant de communications :
nameserver A
nameserver
utilisateur
resolver
nameserver B
attitre
nameserver C
C'est une resolution de type iterative ou un nameserver consulte soit repond par l'information
cherchee, soit repond par une liste de nameservers plus susceptibles de posseder l'information.
En general, un nameserver consulte ne va pas consulter lui m^eme les autres nameservers plus
susceptibles de conna^tre la reponse car cela provoque un travail plus important ; ce mecanisme est
cependant quelques fois utilise et porte le nom de resolution de type recursive ; elle est cependant
fortement deconseillee, principalement pour la charge supplemenatire induite. Il existe enn un
dernier type de resolution, la resolution transitive ou le dernier nameserver consulte, detenteur
de l'information, repond directement au premier nameserver ; ce mecanisme n'est cependant pas
applicable systematiquement puisqu'un chemin direct du dernier nameserver au premier peut ne
pas exister (il n'y a pas forcement de transitivite dans le routage Internet).
148
Une autre caracteristique du DNS est le type d'informations de sa base de donnees. On a parle
jusqu'ici de convertir un nom de machine en adresse IP mais en fait la base de donnees peut contenir
d'autres enregistrements (un enregistrement est appele un RR pour Resource Record). Le DNS est
en fait concu pour ^etre independant des familles de protocole. Cela se traduit au niveau des RRs,
par une classe pour designer un protocole et par un type pour designer certaines informations de
ce protocole. Ainsi la classe du protocole TCP/IP est IN (pour Internet) et comporte les types
suivants :
SOA
NS
Ce sont des RRs donnant des informations sur la gestion de la zone desservie par le
nameserver ; le type SOA (Start Of Authority) indique ainsi l'adresse electronique du
gestionnaire du nameserver, la duree de vie des informations dans la base, etc. le type
NS permet de d
esigner les nameservers de la zone.
C'est un RR precisant l'adresse IP d'une machine.
excalibur.ens.fr.
IN
129.199.115.40
MX
excalibur.ens.fr.
CNAME
100
nef.ens.fr.
IN
CNAME
mafalda.ens.fr.
PTR
MX
HINFO
IN
IN
HINFO
"PENTIUM" "WINDOWS95.0000003401"
IN
PTR
excalibur.ens.fr.
Gr^ace a cela, on voit donc qu'un site doit avoir deux delegations de zones :
1. une delegation de zone sur une partie de la hierarchie des noms symboliques ;
2. une delegation sur une zone de la hierarchie in-addr.arpa.
La partie qui suit, explique comment obtenir ces delegations.
Montrons un exemple concret1 d'une requ^ete iterative. Imaginons que nous nous interessions a
des machines situees en Chine. On va chercher successivement le nom de nameservers servant une
zone chinoise puis le nom du gestionnaire de cette m^eme zone :
1
Realiser un exemple ou l'on verrait des appels aux root nameservers puis aux nameservers des
toplevel domains et ainsi de suite, est infaisable en pratique pour la bonne raison qu'il faudrait
que tous ces nameservers viennent d'^etre reinitialises et ne disposent d'aucune connaissance des
uns des autres.
149
Gestionnaire de la zone :
on continue en fait la requ^ete precedente :
> set type=soa
> ac.cn.
Server: papoon.ens.fr
Address: 129.199.115.27
ac.cn
>
origin = ns.cnc.ac.cn
mail addr = hostmaster.ns.cnc.ac.cn
serial = 95031502
refresh = 10800 (3 hours)
retry
= 900 (15 mins)
expire = 604800 (7 days)
minimum ttl = 86400 (1 day)
datagram from [129.199.115.27].1204, fd 5, len 23; now Thu Mar 16 19:52:51 1995
req: nlookup(ac.cn) id 3 type=2
req: missed 'ac.cn' as '' (cname=0)
forw: forw -> [128.8.10.90].53 ds=7 nsid=5 id=3 0ms retry 4sec
datagram from [128.8.10.90].53, fd 5, len 60; now Thu Mar 16 19:52:51 1995
send_msg -> [129.199.115.27].1204 (UDP 5) id=3
datagram from [129.199.115.27].1205, fd 5, len 23; now Thu Mar 16 19:52:59 1995
req: nlookup(ac.cn) id 4 type=6
req: found 'ac.cn' as 'ac.cn' (cname=0)
forw: forw -> [159.226.1.1].53 ds=7 nsid=6 id=4 0ms retry 4sec
datagram from [159.226.1.1].53, fd 5, len 77; now Thu Mar 16 19:53:00 1995
send_msg -> [129.199.115.27].1205 (UDP 5) id=4
19:52:53.258528 papoon.ens.fr.domain > terp.umd.edu.domain: 5 NS? ac.cn. (23)
19:52:53.512328 terp.umd.edu.domain > papoon.ens.fr.domain: 5- 1/0/1 NS ns.cnc.ac.cn. (60)
19:53:01.057855 papoon.ens.fr.domain > ns.cnc.ac.cn.domain: 6 SOA? ac.cn. (23)
19:53:01.862179 ns.cnc.ac.cn.domain > papoon.ens.fr.domain: 6* 1/0/0 SOA (77)
150
Cet exemple montre la quantite d'echanges pour une seule requ^ete. Pour diminuer le co^ut de
futures requ^etes, votre nameserver attitre va stocker les resultats intermediaires de la requ^ete, a
savoir qu'un nameserver pour ac.cn. est ns.cnc.ac.cn. Ces donnees sont conservees dans un
cache memoire et possedent une date de peremption au bout de laquelle elles ne sont plus valables
et qui est precisee dans le RR de type SOA a savoir ici expire = 604800 (7 days).
A titre d'informations, les nameservers de la racine recoivent en moyenne 6 requ^etes par seconde
soit 20000 requ^etes par heure.
Fax: (1) 39 63 55 34
C'est donc a FR-NIC que revient la charge d'attribution des numeros IP de reseaux en France.
La demande d'attribution de numeros de reseaux IP, en general, est a faire aupres de l'operateur
fournisseur de connectivite pour l'organisme. Dans le cas ou celui-ci serait dans l'incapacite de le
faire, on s'adresse alors directement a FR-NIC qui joue alors le r^ole de last resort registry.
Le passeport d'entree dans le monde Internet est alors le suivant :
151
Il faut au moins un serveur secondaire au sein de l'organisme ; le serveur secondaire est a choisir
justicieusement (eviter de le prendre sur le m^eme brin Ethernet, sur la m^eme alimentation
electrique etc. ; cf RFC 1032{1035). Ces serveurs doivent ^etre disponibles 24h/24 et 7jours/7.
L'ideal est d'avoir un autre serveur secondaire ne residant pas sur votre site mais sur un autre
site qui pourrait alors servir de roue de secours. Ce service peut ^etre assure par votre operateur.
La mise en route de serveurs DNS doit s'accompagner de la mise en route du service de resolution inverse, c'est-a-dire de resolution a partir de l'adresse IP du nom de la machine. Il faut
savoir que de plus en plus de services Internet necessite de pouvoir acceder aux enregistrements
de type PTR.
, Apres avoir teste votre service DNS, l'operateur annonce a FR-NIC votre domaine et FR-NIC
l'enregistre dans ses tables.
Un certain nombre de formulaires reprenant ces point sont disponibles :
,
,
ftp://ftp.oleane.net/pub/netinfo/Oleane/obtenir-un-domaine-fr
ftp://corton.inria.fr/NIC-FR/formulaire-domaine-court et ftp://corton.inria.fr/NICFR/formulaire-domaine-documente
152
The latest version of host checks for illegal characters in A/MX record names
and the NS/MX target names.
On distingue deux categories de noms de bapt^eme :
, les noms dits completement qualies ou FQDNs (Fully Qualied Domain Name) ; c'est un nom
De preference, on baptisera les stations avec des noms de type FQDN, principalement pour ne
pas se placer hors des conditions par defaut de certains logiciels delicats a congurer du genre
sendmail etc. L'auteur d'une des implantations du DNS donne comme raisons :
Date: Sun Nov 27 23:32:41 EST 1994
Subject: Q4.9 - Why are fully qualied domain names recommended ?
Q: Why are fully qualied domain names recommended ?
A: The documentation for BIND 4.9.2 says that the hostname should be set to the full
domain style name (i.e host.our.domain rather than host). What advantages are there
in this, and are there any adverse consequences if we don't?
A: Paul Vixie likes to do it :-) He lists a few reasons :
, Sendmail can be congured to just use
gethostbyname(gethostname) == gethostbyaddr(primary_interface_address)
If you take an address and go "backwards" through the PTR's with it, you'll get a
FQDN, and if you push that back through the A RR's, you get the same address.
Or you should. Many multi-homed hosts violate this uncaringly.
If you take a non-FQDN hostname and push it "forwards" through the A RR's, you
get an address which, if you push it through the PTR's, comes back as a FQDN
which is not the same as the hostname you started with.
Consider the fact that, absent NIS/YP, there is no domainname command analogous to
the hostname command. (NIS/YP's doesn't count, of course, since it's sometimes-butonly-rarely the same as the Internet domain or subdomain above a given host's name.)
The domain keyword in resolv.conf doesn't specify the parent domain of the current
host; it species the default domain of queries initiated on the current host, which can
be a very dierent thing. (As of RFC 1535 and BIND 4.9.2's compliance with it, most
people use search in resolv.conf, which overrides domain, anyway.)
What this means is that there is NO authoritative way to programmatically discover
your host's FQDN unless it is set in the hostname, or unless every application is willing
to grovel the netstat -in tables, nd what it hopes is the primary address, and do a
PTR query on it.
153
Commande
/etc/rc.net
/etc/rc.config
/etc/rc.local
/etc/sysconfig
/etc/src.sh
/etc/rc.config.d/netconfig
/etc/sys id
/etc/HOSTNAME
et /etc/hostname.hinterfacei
/etc/hostname.hinterfacei
/etc/nodename ???
/etc/myname
servira dans
154
#
#
#
#
#
#
if [ "$SYSTEM_NAME" = "" ]
then
SHORT_SYSTEM_NAME=caferoya
SHORT_SYSTEM_NAME
SYSTEM_NAME=caferoyal.ens.fr
export SYSTEM_NAME
[...]
}
[...]
if [ ! -f /etc/rcflag ]
# Boot time invocation only
then
[...]
uname -S $SHORT_SYSTEM_NAME
uname -S $SYSTEM_NAME
hostname $SYSTEM_NAME
[...]
Avant on avait
Le nom sur 8 caracteres sert au niveau de la commande uname. Si l'on avait fait uname -S
avec SYSTEM_NAME contenant un nom de plus de 8 caracteres, on aurait obtenu :
$SYSTEM_NAME
Il faut egalement modier le chier /usr/adm/inetd.sec qui contient le nom tronque a 8 caracteres suite a l'installation.
ftp://ftp.jussieu.fr/pub/networking/bind-4.9.2.tar.gz.
La prochaine version 4.9.3 est sur le point de sortir et est d'ores et deja disponible en version de
test nal sous l'URL ftp://ftp.vix.com/pri/vixie/bind-4.9.3-BETA26.tar.gz. En pratique,
155
c'est cette version que l'on adoptera. Le manuel de reference de cette version est disponible ; un
URL en est ftp://ftp.ripe.net/tools/dns/bind-4.9.3-docs/bog.ps.Z.
IN
SOA
dmi.ens.fr.
2001030
3600
3600
3600000
7200 )
beig.dmi.ens.fr. (
; Serial
; Refresh 6 hours
; Retry
1 hour
; Expire 1000 hours
; Minimum 48 hours
La nouvelle base de donnees est alors transmise aux nameservers secondaires ; ils verient que le champ serial du SOA est superieur a celui qu'ils ont, ce qui signie que
leur base n'est pas a jour et ils chargent alors la nouvelle base.
Les serveurs de noms peuvent ^etre parametres ensuite selon plusieurs congurations. Le reste
de cette section passe en revue certaines de ces congurations. Dans tous les cas, ces congurations
sont selectionnees au niveau du chier habituellement appele named.boot et dont l'emplacement
est determine a la compilation de bind (nous passons sous silence les versions fournies par les
constructeurs parce que trop vieilles).
ccr.jussieu.fr
1.157.134.in-addr.arpa
ccr
1
156
134.157.0.129
134.157.0.129
ccr
1
,
,
,
,
Les chiers mentionnes en quatrieme champ ne sont consultes que lorsque le serveur secondaire
demarre et que le primaire ne repond pas, ou lorsqu'il y a un probleme au niveau des serials
des zones. Ces chiers sont initialises et actualises automatiquement, sans intervention manuelle et
peuvent ne pas exister au moment ou le serveur secondaire est lance. On prendra soin de nommer
ces chiers d'une facon qui fasse bien penser que ce ne sont que des chiers de secours consultes si
le serveur primaire ne repond pas.
157
named.boot
cache
root.cache
Ces adresses sont ocielles. Lorsque les adresses des nameservers de la racine sont modiees,
cela implique qu'il faut modier le chier associe de vos nameservers. Le chier a jour contenant les
adresses des serveurs de la racine a pour URL ftp://ftp.rs.internic.net/domain/named.root
;
This file holds the information on root name servers needed to
;
initialize cache of Internet domain name servers
;
(e.g. reference this file in the "cache . <file>"
;
configuration file of BIND domain name servers).
;
;
This file is made available by InterNIC registration services
;
under anonymous FTP as
;
file
/domain/named.root
;
on server
FTP.RS.INTERNIC.NET
;
-OR- under Gopher at
RS.INTERNIC.NET
;
under menu
InterNIC Registration Services (NSI)
;
submenu
InterNIC Registration Archives
;
file
named.root
;
;
last update:
Nov 8, 1995
;
related version of root zone:
1995110800
;
;
; formerly NS.INTERNIC.NET
;
.
3600000 IN NS
A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.
3600000
A
198.41.0.4
;
; formerly NS1.ISI.EDU
;
.
3600000
NS
B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
3600000
A
128.9.0.107
;
; formerly C.PSI.NET
;
.
3600000
NS
C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
3600000
A
192.33.4.12
;
; formerly TERP.UMD.EDU
;
.
3600000
NS
D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
3600000
A
128.8.10.90
;
; formerly NS.NASA.GOV
;
.
3600000
NS
E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
3600000
A
192.203.230.10
;
; formerly NS.ISC.ORG
;
.
3600000
NS
F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
3600000
A
192.5.5.241
;
; formerly NS.NIC.DDN.MIL
158
;
.
3600000
G.ROOT-SERVERS.NET.
3600000
;
; formerly AOS.ARL.ARMY.MIL
;
.
3600000
H.ROOT-SERVERS.NET.
3600000
;
; formerly NIC.NORDU.NET
;
.
3600000
I.ROOT-SERVERS.NET.
3600000
; End of File
NS
A
G.ROOT-SERVERS.NET.
192.112.36.4
NS
A
H.ROOT-SERVERS.NET.
128.63.2.53
NS
A
I.ROOT-SERVERS.NET.
192.36.148.17
Au demarrage, le serveur de noms charge le chier designe par la directive "cache" dans une zone A
PART de son espace de travail normal apellee HINTs. Des que possible (apres avoir charge toutes les
zones de son chier named.boot) le serveur de noms va envoyer une requ^ete pour avoir les enregistrements NS de la racine a un des serveurs de la table HINTs (si ce serveur ne repond pas, on essaie un
autre serveur, etc.). Des que la reponse est recue, la liste des serveur de noms de la racine fournie dans
la reponse est installee dans la zone de travail du DNS avec les TTLs recus dans la reponse.
Nb: Tant que le serveur de noms qui vient juste d'^etre lance n'a pas obtenu les enregistrements NS de
la racine, il repond "server failure" a toutes les requ^etes pour lesquelles il n'est pas autoritaire. Cela
dure en general quelques secondes sauf en cas de congestion des liaisons internationales...
Le serveur de noms va ensuite faire vieillir les enregistrements NS de la racine comme les autres et
quand ils auront disparu il va a nouveau utiliser les HINTs pour obtenir les nouveaux. Le TTL des
hints n'est jamais pris en compte.
Il est utile d'avoir un chier root.cache a jour an que les adresses des serveurs de la racine soient
correctes (elles changent de temps en temps). Mais ce chier n'est jamais utilise comme tel dans les
versions recentes de BIND.
Aujourd'hui ns.internic.net donne les enregistrements NS de '.' avec un TTL de 5 jours. Donc votre
serveur de noms va rafraichir la liste des serveurs de la racine au moins tous les 5 jours.
Benoit Grange ([email protected])
159
de noms. On n'y trouvera rien sur, par exemple, ftp.prep.mit.edu puisque la bonne designation
de cette machine est "DNSement" parlant "prep.ai.mit.edu.".
On distingue donc trois categories de noms en pratique :
absolute rooted FQDN
C'est un nom de machine se terminant par "." qui est donc complet depuis la racine.
Par exemple "prep.ai.mit.edu.".
FQDN
C'est un nom de machine ne se terminant pas par "." mais qui deviendrait absolute
rooted par le seul ajout de ce point nal. Par exemple "prep.ai.mit.edu".
non FQDN
C'est un nom de machine n'etant m^eme pas complet. Cela correspond d'ordinaire
aux synonymes raccourcis de machines que l'on utilise au sein d'un site pour ne pas
avoir a taper un trop long nom. Par exemple "marie" (alors que le FQDN est en fait
"marie.polytechnique.fr").
La partie logicielle transformant un nom en sa designation depuis la racine de l'arbre est connue
sous le nom de resolver.
Pour des raisons decrites dans le RFC 1535, A Security Problem and Proposed Correction With
Widely Deployed DNS Software (dont un URL est ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1535.txt),
l'algorithme de mise en forme d'un absolute rooted FQDN est le suivant :
Dans le absolute rooted FQDN, il y a une partie du nom dont le site est libre et
une autre partie dont il n'est pas libre, cette derniere partie etant tout simplement le
nom sous lequel le site s'est fait enregistre aupres de l'IANA (cf section 11.2 [Aspect
administratif du DNS : enregistrement d'un domaine], page 150) ou de ses delegations.
Par exemple, pour la machine cezanne.prism.uvsq.fr, le petit nom de la machine est
cezanne, la partie libre correspond a
prism et la partie imposee correspond a uvsq.fr.
Si depuis cezanne, on cherche a se connecter a une machine designee dans la commande
sous un nom non absolute rooted, par exemple a.b.c.d, alors on va essayer les absolute
rooted FQDNs suivants :
"a.b.c.d.prism.uvsq.fr."
"a.b.c.d.uvsq.fr."
"a.b.c.d."
Si la station destination avait ete designee par x (un seul mot), on aurait procede aux
m^emes complements du nom.
Bref, l'algorithme consiste a completer par toutes les cha^nes decroissantes de la partie
libre suxees de la partie xe ou alors a completer par ".'.
160
Par exemple :
domain
nameserver
nameserver
ens.fr
129.199.115.50
129.199.96.11
Le chier contient une ligne domain. . . permettant au resolver de convertir toute requ^ete pour
un non absolute rooted FQDN en un absolute rooted FQDN, puisque le DNS ne permet que de
resoudre des FQDNs.
On notera bien que, dans l'implantation standard, il n'y a pas de directives permettant de
preciser une quelconque autre methode de resolution de noms. Si une telle methode existe, c'est
propre au systeme de la station et peut donc ne pas marcher sur un autre systeme. On se reportera
a Cf section 11.7 [Mecanismes de resolution adoptes par les constructeurs], page 163, pour plus de
details.
L'emplacement du chier resolv.conf peut varier selon le systeme. C'est en general
sauf sous IRIX 4.0.5 ou c'est /usr/etc/resolv.conf.
/etc/resolv.conf
permet de pouvoir balayer tout l'espace de noms du domaine sans avoir a specier un nom completement qualie :
% cat /etc/resolv.conf
161
domain ens.fr
nameserver 129.199.115.50
nameserver 129.199.96.11
% nslookup excalibur
Server: falbala.ens.fr
Address: 129.199.115.50
Name:
excalibur.ens.fr
Address: 129.199.115.40
Mais que mettre comme ligne domain dans le cas de FQDNs sur quatre champs ? Une solution
est de mettre le domaine sur trois champs de la division. Cela permettra de faire des requ^etes
de noms non qualies de la division. Par contre, pour des machines d'une autre division, il faudra preciser le FQDN. Exemple avce le cas de deux machines de noms mandrake.lps.ens.fr et
becassine.lpt.ens.fr :
% cat /etc/resolv.conf
domain
lps.ens.fr
nameserver 129.199.115.50
nameserver 129.199.96.11
% nslookup mandrake
Server: falbala.ens.fr
Address: 129.199.115.50
Name:
mandrake.lps.ens.fr
Address: 129.199.115.202
% nlookup becassine
Server: falbala.ens.fr
Address: 129.199.115.50
*** falbala.ens.fr can't find becassine: Non-existent domain
% nslookup becassine.lpt.ens.fr
Server: falbala.ens.fr
Address: 129.199.115.50
Name:
becassine.lpt.ens.fr
Address: 129.199.115.201
Une solution plus conviviale existe. Elle consiste en la directive search de resolv.conf qui
permet de donner une liste de domaines par lesquels completer un nom non qualie.
La primitive search trouve sa justication dans le RFC 1535.
Si l'on veut se connecter depuis la machine foo.division1.organisation.pays vers
on aimerait bien avoir a n'entrer que foobar. Or, les
regles de composition implicite d'absolute rooted FQDNs ne vont pas permettre de faire une
requ^ete qui aboutira puisque les FQDNs des requ^etes seront :
foobar.division2.organisation.pays,
foobar.division1.organisation.pays.
foobar.organisation.pays.
foobar.
162
Pour remedier a cela, on va etendre la liste implicite des domaines a suxer gr^ace a search qui
denit une liste explicite de domaines. En mettant :
search division1.organisation.pays division2.organisation.pays organisation.pays
% nlookup becassine
Server: falbala.ens.fr
Address: 129.199.115.50
Non-authoritative answer:
Name:
becassine.lpt.ens.fr
Address: 129.199.115.201
La primitive search est supportee sur les systemes suivants (sans y ^etre necessairement documentee) :
Systeme
Primitive search
AIX 3.2.5
supporte
AIX 4.1.1
supporte
DEC OSF1 3.0
supporte
DEC ULTRIX 4.x
non supporte
FreeBSD 2.0.5 et 2.1
supporte
HP-UX 8.07
supporte
HP-UX 9.0x
supporte
HP-UX 10.01
supporte
IRIX 4.0.5
supporte
IRIX 5.2
supporte
Linux
non supporte ?
Systeme
NetBSD 1.0
SunOS 4.1.x
Solaris 2.4
163
Primitive search
supporte
non supporte
supporte
Il sut donc de decider de l'ordre voulu dans la ligne hosts=. . . pour congurer la resolution
de noms.
164
/etc/host.conf
ou
source
status
action
% cat /etc/newconfig/nsswitch/nssw.dnsfiles
hosts: dns [NOTFOUND=continue] files
% cat /etc/newconfig/nsswitch/nssw.filesdns
hosts: files [NOTFOUND=continue] dns
165
% cat /etc/newconfig/nsswitch/nssw.nisfiles
hosts: nis [NOTFOUND=continue] files
On peut verier la syntaxe du chier /etc/nsswitch.conf par l'utilitaire nslookup qui vient
avec le patch PHNE_4563 ; on fait nslookup -swdebug :
% cat /etc/nsswitch.conf
hosts: files [NOTFOUND=continue] dns
% nslookup -swdebug
__nsw[/etc/nsswitch.conf] 1->hosts: files [NOTFOUND=continue] dns
__nsw[/etc/nsswitch.conf]LS->L<hosts>L<:>L<files>L<[>L<notfound>L<=>L<continue>L<]>L<dns>
__nsw_getconfig: PARSE SUCCESSFUL
Using /etc/hosts on: caferoyal.ens.fr
On peut savoir l'ordre de resolution par l'ordre policy de cette commande nslookup. On peut
egalement voir le mecanisme suivi de resolution en utilisant l'ordre set swtrace. Dans les exemples
qui suivent, la machine mandrake.lps.ens.fr n'est enregistre que dans le chier /etc/hosts et
pas dans les tables du DNS et c'est le contraire pour la station absinthe.ens.fr :
% cat /etc/nsswitch.conf
hosts: files [NOTFOUND=continue] dns
% nslookup
Using /etc/hosts on: caferoyal.ens.fr
> policy
#Lookups = 2
files [RCCR]
dns [RRRR]
> set swtrace
> mandrake.lps.ens.fr
Using /etc/hosts on: caferoyal.ens.fr
lookup source is FILES
Using /etc/hosts on: caferoyal.ens.fr
Name:
mandrake.lps.ens.fr
Address: 129.199.122.30
> absinthe.ens.fr
Using /etc/hosts on:
thorgal.ens.fr
166
> policy
#Lookups = 2
dns [RCCR]
files [RRRR]
> set swtrace
> mandrake.lps.ens.fr
Name Server: falbala.ens.fr
Address: 129.199.115.50
lookup source is DNS
Name Server: falbala.ens.fr
Address: 129.199.115.50
*** falbala.ens.fr can't find mandrake.lps.ens.fr: Non-existent domain
Switching to next source in the policy
lookup source is FILES
Using /etc/hosts on: caferoyal.ens.fr
Name:
mandrake.lps.ens.fr
Address: 129.199.122.30
Si vous rencontrez des problemes pour imprimer ce chier sur une imprimante n'utilisant que
du papier A4, appliquez le patch suivant :
1877c1877
< 1 1 0 0 612 792 0 1 15 FMDOCUMENT
--> .97 .97 0 0 595 842 0 1 15 FMDOCUMENT
167
Le systeme de la resolution de noms est completee par le chier /etc/resolv.conf (qui supporte
le mot-cle search).
ens.fr
local bind
129.199.115.50
129.199.96.11
# falbala.ens.fr
# dmi.ens.fr
/etc/resolv.conf
168
presume que l'on resoud par le DNS puis par le chier local /etc/hosts. Sinon on retrouve le
classique chier /etc/resolv.conf, le mecanisme de resolution de noms supportant la primitive
search dans ce chier.
Une consequence de ce mecanisms est qu'il n'est pas necessaire d'avoir un chier resolv.conf
sur les clients NIS puisque ceux-ci transmettent toutes les requ^etes de resolution de noms via NIS.
Cependant, on remarquera que l'absence de ce chier emp^echera des programmes comme nslookup
de fonctionner.
Pour utiliser le DNS, independemment de NIS, il faut modier la librairie dynamique
pour y incorporer des routines modiees (gethostbyname(). . .) faisant
appel au DNS comme celles de /usr/lib/libresolv.a mais on preferera celles du package logiciel
resolv+ (d'URL ftp://ftp.uu.net/networking/ip/dns/resolv+2.1.1.tar.Z) qui ore la possibilite de choisir quels mecanismes de resolution de noms prendre ainsi que leur ordre d'application.
/usr/lib/libc.so.x.y
M^eme si vous recompilez la librairie C dynamique. certains utilitaires systeme ne pourront pas
utiliser le DNS car, soit ces utilitaires sont compiles en statique et ne font pas acces aux librairies
dynamiques, soit ces utilitaires ne sont pas prevus pour fonctionner avec le DNS pour des questions de securite. Ces utilitaires sont : /usr/etc/mount, /usr/etc/rpc.mountd, /usr/lib/lpd,
/usr/ucb/rcp.
Si vous souhaitez, malgre tout, disposer de ces utilitaires en version dynamique donc pouvant
utiliser une librairie C dynamique patchee pour le DNS, vous devrez vous procurer leurs sources
dans des distributions du genre de BSD 4.4 lite.
169
Le chier README du package resolv+ indique la maniere a suivre pour compiler une nouvelle
librairie dynamique, la tester et l'installer si elle convient. La conguration de la resolution de noms
se fait gr^ace a un chier host.config.
Au m^eme titre, on peut se procurer la FAQ comp-sys-sun-faq postee regulierement dans le
newsgroup news.answers et qui reprend notamment les points de details de l'installation a faire.
Elle est disponible sur le site thor.ece.uc.edu sous le nom /pub/sun-faq/sun-faq.general.
On consultera aussi le chier /pub/sun-faq/sun-managers.faq sur la m^eme machine.
cation de /etc/hosts ne peut pas ^etre plus recente que la date de ce chier estampille (31
Decembre 1999) si bien que la map hosts n'est jamais reactualisee.
, Remettre un chier /etc/hosts normal sur le serveur NIS.
Si un client NIS cherche a resoudre un nom. ce nom peut ne pas ^etre trouve dans la map hosts
du serveur si bien que ce dernier se trouvera force d'emettre une requ^ete DNS pour resoudre la
requ^ete et la reponse sera transmise malgre tout au client comme si elle avait ete trouvee dans la
map hosts.
cat /etc/nsswitch.conf
/etc/nsswitch.nis:
An example file that could be copied over to /etc/nsswitch.conf; it
uses NIS (YP) in conjunction with files.
"hosts:" and "services:" in this file are used only if the /etc/netconfig
file contains "switch.so" as a nametoaddr library for "inet" transports.
[...]
# consult /etc "files" only if nis is down.
hosts:
nis [NOTFOUND=return] files dns
[...]
170
...
Claude Scarpelli,
I try to congure MacTCP 2.0.4 with BOOTP. BootP server is running on
SunOS4.1.3, and MacTCP is running on a Quadra 650 (System 7.1 french).
The Mac record its IP address, the gateway address and the subnet mask
correctly. But it does not get neither the domain name nor the name
> server adress.
>
>
171
I'n not shure about version 2.0.4 of MacTCP, but by experimenting I've arrived att the following
conclusions for earlier versions:
It will not get the domain name address. There is really no reason. It should get this from the domain
name server. In the bootp table it's only used as an identier.
It will however get one domain name server. If you give several in the bootp table it will only use one
(the last one if I remember correctly). Also, it will not enter the domain name server into the MacTCP
control panel, but it will use it. Having only one domain name server congured is of course not very
nice. Not much will work when it's down.
There are also some other stupid bugs in MacTCP. E.g., it will only get one MX record from a domain
name server (the last one ?).
The user interface for entering domain name servers manually is not very good (I'm working hard here
to refrain from using bad language). If you want to congure MacTCP for using two domain name
servers, one of which is used normally and the other is used if the rst is down, you should do it in the
following way. Don't ask me why! It's to complicated to explain :-)
default.domain
.
.
xxx.xxx.xxx.xxx
xxx.xxx.xxx.xxx
yyy.yyy.yyy.yyy
x
o
o
where "default.domain" is the domain you mostly connect to, "xxx.xxx.xxx.xxx" is the IP address for
the rst hand choice for domain name server, and "yyy.yyy.yyy.yyy" is the IP address for the other
domain name server.
All this (and more) has been reported to Apple many times. Why they haven't xed it long since is
beyond me.
Newsgroup: comp.protocols.appletalk
From: [email protected] (Paul Henderson)
Subject: Re: MacTCP 2.0.6 and bootp
Date: Mon, 6 Mar 1995 13:51:20 GMT
In article <[email protected]>,
(Paul Henderson) wrote:
>
>
>
Hi, everyone,
I'm having a problem getting my Ethernet Macs w/ MacTCP 2.0.6
> > to bootp from a bootp server. I have all the Mac settings correct, and I
> > can watch the correct data being sent from the bootp server to the Mac
> > via my handy Snier. However, the Mac seems to only "grab" the IP address.
> > The gateway address and the subnet mask do not update.
>>
>>
> >
Tony,
I (and dozens of others on this campus) have used bootp since MacTCP
> 1.? (several years) and except for MacTCP 2.0.2, bootp has always worked.
> We are now at MacTCP 2.0.6. MacTCP does not seem to update the gateway
> address and subnet mask displays, but it apparently works correctly.
>
>
172
It would seem that in an eort to reduce network trac, my brevity was not as clear as I thought I
was. The bootp server (I have no idea what version it is) here at University of Waterloo supplies IP
address, gateway address, subnet mask, and even rudimentary Domain Name Server information. In
addition, it provides the security of knowing that if bootp fails, there is probably a network problem. It
is a 'feature' of MacTCP that many of the items supplied by bootp are not displayed in the MacTCP
control panel display. The fact that they are not displayed does not inhibit the essentially correct
operation of MacTCP. The only area we do not use the data supplied by the bootp server is DNS. I
have experimented with this and have discovered that I must always supply a fully-qualied address.
e.g. Using the bootp-supplied DNS values, MacTCP did not resolve telnet dcs1, but was able to
resolve telnet dcs1.uwaterloo.ca. Since the DNS portion of MacTCP is not displayed for bootp, we
have elected to manually set DNS. This also allows us to use secondary DNS entries, as bootp DNS
setting only supplies a primary DNS.
I hope this clears up any questions that my earlier brief posting may have left unanswered.
host
dnswalk
lamers
URL : ftp://ftp.vix.com/pri/vixie/bind-4.9.3-BETA26.tar.gz
L'utilitaire nslookup permet d'interroger un nameserver (celui mentionne dans
resolv.conf) et de lui faire des requ^
etes de classe IN et de tout type (A, SOA, NS,
MX. . .).
C'est l'outil de base dans l'environnement DNS, si bien qu'on le trouve sur tous
les systemes en standard. Cependant, on notera bien que le bon fonctionnement de
nslookup est ind
ependant de l'utilisation par le systeme du DNS. Ainsi, sur SunOS
4.1.x, nslookup fonctionne sans que SunOS reconnaisse le DNS pour autant. L'utilitaire nslookup fait reposer son bon fonctionnement uniquement sur l'existence du
chier resolv.conf.
La version la plus a jour de nslookup fait partie du package de bind. Cette version permet notamment de pouvoir traiter directement des requ^etes de type PTR
sans avoir a utiliser la notation d.c.b.a.in-addr.arpa pour conna^tre le nom
de l'adresse IP a.b.c.d ; si l'on ne dispose que d'un vieux nslookup, on utilisera, pour resoudre ce genre de requ^ete, le shell script revnslookup.sh d'URL
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/revnslookup.sh.
URL : ftp://ftp.nikhef.nl/pub/network/host_YYMMDD.tar.Z
Host is a program used to retrieve DNS information from name servers. This information may be used simply to get simple things like address-to-name mapping, or some
more advanced purposes, e.g., performing sanity checks on the data.
URL : ftp://ftp.pop.psu.edu/pub/src/dnswalk
Dnswalk is a DNS debugger written in Perl.
URL : ftp://terminator.cc.umich.edu/dns/lame-delegations
A lame delegation is a serious error in DNS congurations, yet a (too) common one.
It happens when a name server is listed in the NS records for some domain and in
fact it is not a server for that domain. Queries are thus sent to the wrong servers, who
173
don't know nothing (at least not as expected) about the queried domain. Furthermore,
sometimes these hosts (if they exist!) don't even run name servers. As a result, queries
are timed out and resent, only to fail, thus creating (more) unnecessary trac.
doc
ddt
nslook
URL : ftp://ftp.uu.net/networking/ip/dns/doc.2.0.tar.Z
It is a C-shell script called DOC (Domain Obscenity Control), an automated domain
testing tool that uses dig to query the appropriate name servers about authority for a
domain and analyzes the responses.
URL : ftp://ns.dns.pt/pub/dns/ddt-2.0.1.tar.gz
DDT (Domain Debug Tools) is a package of programs to scan DNS information for
error detection, developed originally by Jorge Frazao from PUUG - Portuguese UNIX
Users Group and later rewritten by the author, at the time at the Faculty of Sciences of
University of Lisbon. Each program is specialized in a given set of anomalies: you have
a checker for authority information, another for glue data, mail exchangers, reversemappings and miscellaneous errors found in all kinds of resource records. As a whole,
they do a rather extensive checking on DNS congurations.
URL : ftp://ftp.inria.fr/network/dns/nslook-1.4.shar.Z
C'est un utilitaire de la famille de nslookup.
11.9 Bibliographie.
Le lecteur pourra se reporter aux newsgroups consacres aux dierents systemes (cf [Generalites
sur les systemes abordes], page 7) ainsi qu'a comp.protocols.tcp-ip.domains.
Le lecteur pourra se reporter aux articles suivants :
FAQs disponibles sur le site thor.ece.uc.edu sous
/pub/sun-faq/sun-managers.faq.
le nom /pub/sun-faq/sun-faq.general et
[AL92] Paul Albitz and Cricket Liu. DNS and BIND. O'Reilly & Associates, Inc., 1992.
[Bor93] Stephane Bortzmeyer. Le systeme de service de noms de l'Internet : DNS. Technical
report, Laboratoire d'Informatique du CNAM, 1993,
URL ftp://ftp.cnam.fr/pub/Network/DNS/DNS_in_french.ps.Z
[DT93] Pierre David and Jacky Thibault. Domain Name Service { Fonctionnement et installation,
Messagerie { Architecture et installation. Technical report, Laboratoire MASI, Universite
de Versailles - St Quentin en Yvelines, Centre de Calcul Recherche, Universite Pierre et
Marie Curie, 1993,
URL ftp://ftp.jussieu.fr/jussieu/doc/local/dnsmail.ps.Z
[Rom94] Artur Rom ao. Tools for DNS debugging. Technical report, Faculdade de Ci^ensas e
Tecnologia, Universidade Nova de Lisboa, 1994,
URL ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1713.txt
174
175
, consultation du temps ;
, activites liees au temps ;
Pour que les activites liees au temps s'executent normalement, il faut cependant que le temps
soit bon sur la station.
where:
176
offset
Three or more bytes that designate the standard time zone (STD) and
summer (or daylight-savings) time zone (DST) STD is required. If DST
is not specied, summer time does not apply in this locale. Any characters other than digits, comma (,), minus (-), plus (+), or ASCII NUL are
allowed.
offset is the value that must be added to local time to arrive at Coordinated Universal Time (UTC). Oset is of the form :
hh[:mm[:ss]]
rule
Hour (hh) is any value from 0 through 23. The optional minutes (mm) and
seconds (ss) elds are a value from 0 through 59. The hour eld is required.
If oset is preceded by a -, the time zone is east of the Prime Meridian. A +
preceding oset indicates that the time zone is west of the Prime Meridian.
The default case is west of the Prime Meridian.
rule indicates when to change to and from summer (daylight-savings) time.
The rule has the form :
date/time,date/time
where the rst date/time species when to change from standard to summer time, and the second date/time species when to change back. The
time eld is expressed in current local time.
The form of date should be one of the following :
Jn
Julian day n (1 through 365). Leap days are not counted. February 29 cannot be referenced.
n
The zero-based Julian day (0 through 365). Leap days are counted. February 29 can be referenced.
Mm.n.d
The d day (0 through 6) of week n (1 through 5) of month
m (1 through 12) of the year. Week 5 refers to the last day d
of month m. Week 1 is the week in which the rst day of the
month falls. Day 0 is Sunday.
time
Time has the same format as oset except that no leading sign
("-" or "+") is allowed. The default, if time is not given, is
02:00:00.
While the STD eld and the oset eld for STD must be specied, if the
DST eld is also provided, the system will supply default values for other
elds not specied. These default values come from le /usr/lib/tztab
(see tztab(4)), and, in general, re
ect the various historical dates for start
and end of summer time.
Ainsi, la valeur NFT-1DST,M3.4.0/2:00:00,M9.4.0/2:00:00 signie : on se trouve dans la zone
mais avec une heure de decalage en plus par rapport a l'heure de Greenwhich (le temps UTC
(Coordinated Universal Time) est equivalent au temps GMT (Greenwich Mean Time)) ; on applique
en plus le systeme d'heure d'ete et d'heure d'hiver le dimanche de la quatrieme semaine de mars
et septembre, a deux heures du matin.
NFT
L'exemple ci-dessus provient de ce qu'on est oblige de faire sur certains systemes pour le cas de
la France avec son systeme d'heure d'ete et d'heure d'hiver. Rappelons en deja le fonctionnement :
Dernier dimanche de mars
On perd une heure de sommeil puisque l'on passe de 2h du matin a 3h du matin.
177
clock summer-time MET-DST recurring last Sun Mar 2:00 last Sun Sep 3:00
MET-1METDST
MET
MET
MET
MET
ftp://elsie.nci.nih.gov/pub
Bien s^ur, si la variable TZ ne contient pas la bonne valeur, les valeurs renvoyees pas les fonctions
C d'achage du temps sont incorrectes :
mendel:[46]:</home3/Guests/besancon>echo $TZ
MET-1EDT
mendel:[47]:</home3/Guests/besancon>date
Sun Oct 16 23:58:01 EDT 1994
mendel:[49]:</home3/Guests/besancon>export TZ=MET
mendel:[50]:</home3/Guests/besancon>date
Sun Oct 16 22:58:41 MET 1994
Une valeur pour TZ est aectee par defaut au systeme, en des endroits tres dierents suivant le
systeme :
Systeme
Niveau de l'aectation par defaut
AIX versions 3.2.3 et 4.1.x
/etc/environment
DEC OSF1 versions 1.x, 2.0 et 3.0
/etc/zoneinfo/localtime est un lien soft vers le bon chier de
description /etc/zoneinfo/XXX de l'heure
DEC ULTRIX 4.x
/usr/sys/conf/<architecture>/<config-file>, chercher une
ligne du type :
FreeBSD 2.1.0
1
timezone -1 dst 4
178
Systeme
HP-UX versions 8.07, 9.0x
HP-UX 10.01
IRIX versions 4.0.5 et 5.2
Linux
NetBSD 1.0
SunOS 4.1.x
Solaris 2.x
lu par init
bon -
l'heure
/etc/TIMEZONE
Tous les champs, sauf commande, peuvent faire l'objet de caracteres jokers, permettant ainsi de
designer de facon globale certains intervalles. En pratique, on peut mettre *, une enumeration
(suite de nombres separes par des virgules) ou un intervalle (nombres separees par -). Voici un
exemple de ce chier de commandes :
#
# Un exemple de crontab
#
# Historique : 14/07/89 : pda : redaction
#
# Tous les dimanches,
a 4h du matin, sauvegarder le fichier des messages.
0 4 * * 0 /usr/local/etc/sauver-log
# Supprimer les fichiers "core" non utilis
es depuis plus de 2 jours
a 2h35 du matin.
35 2 * * * find / -name core -atime +2 -exec rm -f \;
# Toutes les 10 minutes, entre 8h et 19h, surveiller le nombre d'utilisateurs.
05,15,25,35,45,55 8-19 * * * (date ; who | wc -l) >> /usr/local/etc/compta
Comment fonctionne plus en details cron ? Le mecanisme repose en fait sur deux utilitaires :
crontab
cron
179
cron
5 * * * *
10 4 * * *
15 5 * * 0
5 * * * *
10 4 * * *
15 5 * * 0
uucp
uucp
uucp
/usr/lib/uucp/uudemon.hr
/usr/lib/uucp/uudemon.day
/usr/lib/uucp/uudemon.wk
Il existe une version domaine public de cron corrigeant quelques bugs et trous de securite des differentes versions constructeur de cron. Un URL en est ftp://ftp.inria.fr/system/admin/cron3.0pl11.tar.gz.
2
Je n'ai jamais eu acces a des machines ayant une version BSD de cron ; les informations donnees
proviennent de la lecture de quelques documentations.
180
On notera que cet utilitaire ne permet pas de tenir compte de la derive d'horloge. On le lancera
donc periodiquement sur la station a synchroniser de facon a ne pas avoir une trop grosse derive.
La commande rdate est disponible en standard sur les machines suivantes :
Systeme
AIX 3.2.x et 4.1.x
DEC OSF1 1.x, 2.0 et 3.0
DEC ULTRIX 4.x
FreeBSD 2.0.5 et 2.1
HP-UX 8.07, 9.0x et 10.0x
IRIX 4.0.5 et 5.2
Linux
NetBSD 1.0
SunOS 4.1.x
Solaris 2.x
Commande rdate
non disponible
/etc/rdate
/etc/rdate
non disponible
non disponible
non disponible
non disponible
/usr/sbin/rdate
/usr/ucb/rdate
/usr/ucb/rdate
Pour les systemes ou la commande est absente, on la compilera a partir dont un URL est
ftp://ftp.inria.fr/network/time/rdate.shar.Z.
181
x
2
La ou ce mecanisme est interessant, est que cet arbre est dynamique suivant les problemes reseau
rencontres. Une machine peut changer de niveau de strate au cours du temps : ainsi, si la liaison x
dans le dessin ci-dessus est rompue, il y a reorganisation des strates pour donner ce que l'on trouve
dans la gure de droite. Une machine a change de niveau de strate.
Les machines sur lesquelles on se synchronise sont a preciser dans un chier de conguration :
Voici un exemple d'un tel chier pour une machine conguree en serveur de niveau de
strate 2 (il y a peut-^etre trop de serveurs sur lesquels se synchroniser) :
ntp.conf.
monitor yes
precision -7
server 192.93.2.20
## canon.inria.fr
server 129.132.1.160
## swisstime.ethz.ch
server 128.96.60.5
## pi.bellcore.com
server 128.118.46.3
version 2 ## otc1.psu.edu
peer 128.118.25.3
version 2 ## clock.psu.edu
peer 129.132.1.170
## bernina.ethz.ch
peer 192.93.2.39
version 1 ## concorde.inria.fr
peer 134.214.100.6
## ntp.univ-lyon1.fr
driftfile /usr/local/ntp/etc/ntp.drift
stratum
stratum
stratum
stratum
stratum
stratum
stratum
stratum
1
1
1
1
2
2
2
2
182
On y voit des references a des serveurs de dierents niveaux de strate. Pour plus de renseignements sur ces serveurs, on se reportera au chier clock.txt disponible sur ftp.univ-lyon1.fr sous
le nom /pub/unix/network/tcpip/xntp/clock.txt.gz) : Ce chier donne une liste certaine de
sites sur lesquels on peut se synchroniser. Voici juste les renseignements sur les machines francaises
y etant mentionnees :
canon.inria.fr (192.93.2.20)
Location
Synchronization
Service area
Access policy
Contact
Note
ntp.pasteur.fr
Location
Synchronization
Service area
Access policy
Contact
Note
ntp.univ-lyon1.fr (134.214.100.25)
Location
Synchronization
Service area
Access policy
Contact
Note
Note
chronos.univ-rennes1.fr (129.20.128.2)
Location
Synchronization
Service area
Access policy
Contact
183
D'une facon plus generale, il est tres conseille de demander l'autorisation de se synchroniser sur
tout serveur d'heure. Le choix des sites sur lesquels se synchroniser est delicat et doit faire entrer
en compte des considerations reseau (nombre de hops, vitesse des liaisons. . .). Un consensus semble
se degager preconisant l'emploi de serveurs francais, hollandais, suisses ; a la limite, on peut utiliser
des sites americains mais de la c^ote est.
Se reporter a http://www.univ-rennes1.fr/CRU/NTP/anonce-ntp.html.
Le package apporte quelques commandes dont les plus utiles sont les suivantes :
xntpd
ntpdate
Il s'agit du demon a lancer pour activer la mise en synchronisation sur les serveurs de
temps. Il doit ^etre lance au boot (cf chapitre 2 [Demarrage d'UNIX (son bootstrap)],
page 25).
C'est l'utilitaire permettant de realiser une mise en synchronisation avec un serveur
d'heure. La methode la plus simple pour cela est d'utiliser cron qui lancera alors la
commande ntpdate -s serveur. On peut egalement demander une synchronisation au
moment du boot par la commande ntpdate -b -s serveur &. Le programme ntpdate
se comporte comme une sorte de rdate.
# hostname
mafalda.ens.fr
# date
Tue Jul 18 13:36:17 MET 1995
# /etc/ntp/bin/ntpdate excalibur.ens.fr
/etc/ntp/bin/ntpdate: step time server 129.199.115.40 offset -31452982.9810429
# date
Tue Jul 19 12:40:36 MET 1994
# hostname
filochard.ens.fr
# date
Tue Jul 19 13:40:00 MET 1994
# /etc/ntp/bin/ntpdate excalibur.ens.fr
/etc/ntp/bin/ntpdate: step time server 129.199.115.40 offset -3432.4853048
# date
Tue Jul 19 12:42:55 MET 1994
xntpdc
Le package apporte aussi la commande xntpdc qui permet d'interroger les dierentes
sources de temps :
# ./xntpdc -p
remote
local
st poll reach delay
offset
disp
======================================================================
=129.132.1.160
129.199.115.40
3 1024 377 0.0719 -0.000302 0.0167
+cismsun.univ-ly 129.199.115.40
2 256 377 0.0209 -0.002617 0.0229
+abymes.inria.fr 129.199.115.40
2 256 377 0.0162 0.002556 0.0166
+concorde.inria. 129.199.115.40
2 256 377 -0.0012 -0.002201 0.0239
+chenas.inria.fr 129.199.115.40
2
64 177 0.0077 0.010022 0.1372
+oldber.ethz.ch 0.0.0.0
16 1024
0 0.0000 0.000000 16.000
=otc1.psu.edu
129.199.115.40
1 1024 126 0.1773 -0.031409 0.0379
+nhelene.inria.f 129.199.115.40
3 1024 376 0.0137 -0.011359 0.0281
*canon.inria.fr 129.199.115.40
1 256 377 0.0161 0.006774 0.0139
=pi.bellcore.com 0.0.0.0
16 1024
0 0.0000 0.000000 16.000
+otc2.psu.edu
129.199.115.40
2 1024 367 0.1639 -0.025311 0.0483
184
Concernant l'utilisation de NTP sur des PCs sous Unix, je peux dire d'experience que les derives
de l'horloge sur la carte mere sont pratiquement toujours telles (probablement dues a l'utilisation de
quartz non etalonnes) que le serveur NTP n'arrive pas a se synchroniser, il faut alors ajuster a la main
la variable tickadj du kernel... (utilitaire tickadj sous FreeBSD).
, Une methode consiste a faire appel a des packages logiciels specialises du genre CAP ou netatalk
(cf hundenedi [Serveur d'heure], page hundenedi) ;
, L'autre methode consiste tout simplement a utiliser le m^eme protocole que sur les stations de
travail, a savoir NTP. Un logiciel de type shareware propose cela sur Macintosh ; il s'agit
de NTP for Macintosh, disponible par exemple sur le site ftp.pasteur.fr sous le nom
/pub/Mac/Networking/ntpclient1.0.sit.hqx.
12.5 Bibliographie
Le lecteur pourra se reporter aux ouvrages suivants:
[Bis90] Mark Bishop. A Security Analysis of the NTP Protocol. Technical report, Department
of Mathematics and Computer Science, Darthmouth College, 1990,
URL ftp://louie.udel.edu/pub/ntp/doc/security.ps.Z
[Mil] David L. Mills. Internet Time Synchronization: the Internet Time Protocol. Technical
report, University of Delaware,
URL ftp://louie.udel.edu/pub/ntp/doc/ntp.ps.Z
[Mil89a] David L. Mills. Internet Time Synchronization: the Network Time Protocol. Technical
report, University of Delaware, 1989,
URL ftp://louie.udel.edu/pub/ntp/doc/rfc1129.ps.Z
[Mil89b] David L. Mills. Measured Performance of the Network Time Protocol in the Internet
System. Technical report, University of Delaware, 1989,
URL ftp://louie.udel.edu/pub/ntp/doc/rfc1128.ps.Z
[Mil89c] David L. Mills. Network Time Protocol (version 2), Speciations and implementation.
Technical report, University of Delaware, 1989,
URL ftp://louie.udel.edu/pub/ntp/doc/rfc1119.ps.Z
[Mil90] David L. Mills. On the Accuracy and Stability of Clocks Synchronization by the Network
Time Protocol in the Internet System. ACM Computer Communication review, 1990.
[Mil91] David L. Mills. A Comparison of Certain Timekeeping Systems and the Network Time
Protocol. Technical report, University of Delaware, 1991,
URL ftp://louie.udel.edu/pub/ntp/doc/dts3.ps.Z
[Mil92] David L. Mills. the Network Time Protocol (Version 3), Specication, Implementation
and Analysis. Technical report, University of Delaware, 1992,
URL ftp://ftp.inria.fr/rfc/rfc13xx/rfc1305.tar.Z
185
[Mil94] David L. Mills. Improved Algorithms for Synchronizing Computer Network Clocks. Technical report, University of Delaware, 1994,
URL ftp://louie.udel.edu/pub/ntp/doc/algorithm.ps.Z
186
187
188
Dans ce domaine NIS, on distingue un serveur principal d'informations, des serveurs secondaires
dont la presence ne s'explique que pour equilibrer la charge occasionnee sur le serveur principal s'il
etait seul, par des clients NIS interrogeant les serveurs.
Que sont ces informations redistribuees via NIS ? Tout d'abord, ces informations redistribuees
sont appelees des maps NIS. Elles sont a un format bien particulier que l'on appelle le format DBM
qui permet de faire des recherches tres rapides dans de tres grandes bases de donnees (du genre
localiser un certain element en un ou deux acces disque). Ce format rend les maps diciles a modier
a la main (on peut utiliser le package de manipulation DBM present sur le site ftp.inria.fr
sous le nom /prog/libraries/dbm-toolkit-1.1.1.shar.Z ). Chaque map est construite a partir
d'informations contenues dans un certain chier systeme (au format ASCII) (en gros, le chier est
lu par un utilitaire appele makedbm qui cree la map dans le directory en general appele /var/yp
(cf section 13.3 [Installation de NIS], page 190)). Ainsi, la map passwd est, en general, construite
a partir du chier /etc/passwd.
Quand un systeme fonctionne sous NIS, les maps NIS sont consultees de maniere quasi-exclusive
par le systeme au detriment des chiers ASCII. Pour ^etre plus precis, disons que certaines maps NIS
remplacent des chiers systeme locaux (c'est le cas des maps ethers, hosts, netmasks, netgroups,
networks, protocols, rpc, services) et que d'autres maps NIS peuvent s'ajouter
a des chiers
systeme locaux pour en completer le contenu (c'est le cas des maps passwd, group, bootparams,
aliases).
Soyons bien clairs : le r^ole des serveurs secondaires NIS n'est que de distribuer les maps ; en
aucun cas, ils ne peuvent enregistrer des modications de ces maps. Les modications des maps ne
peuvent ^etre realisees que sur le serveur principal qui les retransmet alors aux serveurs secondaires.
Sur les machines clientes du service NIS (le serveur principal ainsi que les serveurs secondaires
en font partie en general), tourne un process de nom ypbind. A son lancement, ypbind a lance,
via un broadcast reseau, une requ^ete pour obtenir le nom d'un serveur NIS ; en temps normal, il
obtient une reponse d'un serveur NIS (en general le moins occupe a l'instant de la requ^ete).
Soit ensuite un programme ayant besoin des fonctionnalites de NIS. Beaucoup de programmes
sont dans ce cas ; c'est par exemple le cas de /bin/ls qui a besoin d'acher le nom de l'utilisateur a
partir de son UID. Analysons ce qui se passe dans /bin/ls. Le programme lit le directory et recupere
les UIDs des proprietaires des chiers ; il fait alors une serie de getpwuid(). En environnement
NIS, cette routine fait les choses suivantes :
1. elle recupere le nom de domaine NIS ;
2. elle interroge le process ypbind pour avoir le nom d'un serveur NIS ;
3. elle emet alors une requ^ete au serveur NIS indique, lui demandant quel est le nom de l'utilisateur
associe a tel UID ;
4. le serveur consulte ses tables et renvoie le resultat ;
5. la routine reprend son cours normal comme si elle avait lu le resultat dans le chier /etc/passwd
local.
Le serveur est capable de repondre aux requ^etes RPC des clients NIS parce qu'il fait tourner un
process particulier ypserv, capable de repondre aux requ^etes RPC de NIS. Ce process tourne sur
le serveur principal et sur les serveurs secondaires.
Comment sont maintenues a jour les informations NIS ? Il y a deux methodes :
189
1. Le serveur master expedie ses maps aux serveurs secondaires. Cela est fait en general manuellement via le chier Makefile residant dans le directory ou sont stockees les maps. La commande
de base pour realiser cela est yppush.
C'est une mise a jour inconditionnelle des maps.
2. Les serveurs secondaires demandent au serveur master si leurs maps sont a jour et si cela n'est
pas le cas, ils recuperent la derniere version de la map. La commande de base pour realiser
cela est ypxfr.
C'est une mise a jour des maps au libre arbitre des serveurs secondaires.
Important : les serveurs secondaires conservant une copie des maps NIS du serveur principal, ils
doivent imperativement toujours posseder la derniere version a jour. Pour cela, on utilise des shell{
scripts (traditionnellement appeles ypxfr_1perday, ypxfr_1perhour et ypxfr_2perday) qui font
periodiquement, via la crontab, des mises a jour a partir du serveur NIS principal. L'utilisation de
la crontab permet ainsi de pouvoir louper une mise a jour explicite faite par le serveur principal (par
exemple parce que le serveur secondaire etait en train de rebooter). Si le chier /var/yp/ypxfr.log
existe, le systeme y stockera des informations sur ce qui est realise par ypxfr. Par xemple :
Tue Feb 22 00:15:00:
Tue Feb 22 00:15:00:
ypxfr_1perhour
Tue Feb 22 01:15:00:
Tue Feb 22 01:15:01:
ypxfr_1perhour
Tue Feb 22 01:30:00:
Tue Feb 22 01:30:01:
Tue Feb 22 01:30:01:
Tue Feb 22 01:30:01:
Tue Feb 22 01:30:01:
Tue Feb 22 01:30:01:
Tue Feb 22 01:30:01:
Tue Feb 22 01:30:01:
ypxfr_1perday
Tue Feb 22 02:15:00:
Tue Feb 22 02:15:00:
ypxfr_1perhour
Tue Feb 22 03:15:01:
Tue Feb 22 03:15:01:
ypxfr_1perhour
00:15 )
01:15 )
01:30 )
02:15 )
03:15 )
En pratique, il n'existe guere qu'une seule map que l'on modie souvent : celle des mots de
passe. Alors comment cela se passe-t-il lors d'un changement de mot de passe par la commande
yppasswd ?
Dans le protocole NIS, on ne peut pas modier une entree dans une map. Il faut obligatoirement
modier le chier source de la map et a partir du source modie, reconstruire la map. Donc, quand
on fait yppasswd, on contacte un programme particulier qui tourne sur le serveur NIS principal et
dont le r^ole va ^etre d'enregistrer le changement de mot de passe dans le chier source de la map
passwd et de reconstruire la map ensuite via un genre de make passwd que l'on eectuerait dans le
directory ou sont stockees les maps. Sur SunOS 4.1.x, cela se traduit par un process du type :
/usr/etc/rpc.yppasswdd /etc/passwd -m passwd DIR=/var/yp
qui indique que les modications sont a stocker dans le chier /etc/passwd et doivent ^etre repercutees sur les serveurs secondaires via un make <passwd> dans le directory /var/yp.
190
191
[...]
IRIX 4.0.5
IRIX 5.2
Linux
NetBSD 1.0
192
Commande
d'installation
Directory de
stockage
Emplacement
des sources
/usr/sbin/ypinit
/var/yp
DIR=/etc
/var/yp/Makefile
DIR=/var/yp/src
/var/yp/Makefile
DIR=/var/yp/src
/var/yp/Makefile
/usr/etc/yp/ypinit
y
/usr/etc/yp
DIR=/etc
/usr/etc/yp/Makefile
/usr/sbin/ypinit
/var/yp
DIR=/etc
/var/yp/ypmake
/usr/etc/yp/ypinit
/usr/etc/yp
DIR=/etc
/usr/etc/yp/make/script
/var/yp/ypinit
/var/yp
DIR=/etc
/var/yp/ypmake
/usr/etc/yp/ypinit
/var/yp
DIR=/etc
/var/yp/Makefile
/usr/sbin/ypinit
/var/yp
DIR=/etc
???
/usr/sbin/ypsetup
/usr/etc/ypinit
y
/var/yp
y
/var/yp
Activation de NIS.
Finalement, reste a activer NIS. Si la station est un serveur NIS, il faudra lancer
Si la station est un client NIS, il faudra lancer uniquement ypbind.
ypbind.
ypbind
[...]
#if [ -x /usr/etc/ypserv -a -d /etc/yp/`domainname` ]; then
#
startsrc -s ypserv
#fi
ypserv
et
193
if [ -x /usr/etc/ypbind ]; then
startsrc -s ypbind
fi
[...]
La variable
et SLAVE.
Ces valeurs sont ensuite recuperees par le script /sbin/init.d/nis lances au demarrage de la station. On peut y mettre des valeurs par defaut pour certains parametres mais la bonne maniere de proceder reste de mettre ces parametres dans
/etc/rc.config :
[...]
#defaults
NIS_CONF="NO"
NIS_TYPE=""
NIS_ARGS=""
NIS_PASSWDD="NO"
NIS_DOMAIN=""
#pre-sets
NIS_CONF=`$RCMGR get NIS_CONF`
NIS_TYPE=`$RCMGR get NIS_TYPE`
NIS_ARGS=`$RCMGR get NIS_ARGS`
NIS_PASSWDD=`$RCMGR get NIS_PASSWDD`
NIS_DOMAIN=`$RCMGR get NIS_DOMAIN`
[...]
ypbind
[...]
# %YPSTART% - Yellow Pages daemons added by "ypsetup"
/bin/domainname liens
echo -n 'YP daemons:' >/dev/console
194
FreeBSD 2.1.0
On lance le service NIS via dierentes variables du chier /etc/sysconfig :
# Set to appropriate flags if you want to start NIS for a client
nis_clientflags="NO"
# Set to host to ypset to if you need to do that
nis_ypsetflags="NO"
# Set to appropriate flags if you want to start NIS for a server
nis_serverflags="NO"
# Set to appropriate flags for yppasswdd, if you wish to run it.
# Typical flags might be "-m /var/yp/master.passwd -s -f"
yppasswddflags="NO"
Les variables positionnees dans ce chier sont automatiquement recuperees par le script
/etc/netstart.
195
Linux
NetBSD 1.0
/etc/config/yp
on
/etc/config/ypbind.option
129.199.115.32
/etc/config/ypmaster
off
/etc/config/ypserv
off
Ici, on congure une machine en client NIS du serveur dont l'adresse IP est
129.199.115.32. Le syst
eme IRIX permet en eet de preciser en option a ypbind
le nom ou l'adresse IP d'un serveur NIS a utiliser ; j'ai d^u utiliser cette option pour
cette station SGI cliente NIS d'un serveur sous HP-UX-9.01. Pourquoi ???
Le demon ypbind est demarre depuis /etc/rc.d/rc.inet2.
Cette ligne active l'utilisation de NIS. Le systeme est concu de facon a ne pas considerer cette ligne
comme la declaration de l'utilisateur + sans mot de passe et d'UID et GID 0 0. Pour plus de renseignements (et notamment une legere modication de la ligne au titre de la securite informatique),
cf section 13.5 [A propos de /etc/passwd], page 197.
Un champ vide indique un wild card. Un caractere - indique que le champ est rendu inutilisable.
Melanger des entrees du type (, hutilisateuri,) et (hmachinei,-,) est dangereux. Si l'on creait le
netgroup suivant :
1 Je n'ai jamais vu le troisieme champ avoir une quelconque utilite en pratique.
196
buggy-netgroup
(,besancon,),
alors on ne creerait pas un netgroup restreignant les acces a deux machines mais un netgroup ouvert
a toutes les machines connues par NIS puisque les champs <machine> des entrees (,besancon,)
et (,jma,) sont vides, donc des cases joker. La bonne facon de proceder est la suivante :
hosts-netgroup
users-netgroup
(excalibur,,), (ariana,,)
(,besancon,),
(,jma,)
-access=droopy,root=droopy
-access=droopy,root=droopy
-root=merlin,access=physique
-root=merlin,access=physique
-root=merlin,access=physique
C'est la syntaxe de SunOS 4.1.x ; se reporter au manuel du systeme pour les autres OS.
L'utilisation d'un netgroup dans le champ -root= n'a pas d'eet. En eet, le netgroup est
diuse a partir d'un serveur NIS. Il faudrait donc avoir conance en cette machine pour accepter
ces netgroups ; ici, il a ete choisi de ne pas faire conance aux netgroups diuses si bien qu'il faut
donner explicitement les noms de toutes les stations autorisees a acceder avec les equivalences root
par NFS a des lesystems.
Par contre, la derniere ligne indique que toutes les autres personnes denies dans le chier passwd
diuse par NIS sont autorisees a se connecter.
Cette methode qui fonctionne bien, a cependant un defaut : a cause de la ligne -@u_students:,
il n'existe aucun utilisateur du netgroup u_students sur cette machine. Or parfois, il peut ^etre
interessant d'interdire de se connecter a certaines personnes mais de conserver leurs logins ; typiquement sur un serveur NFS, on peut souhaiter interdire les logins de tous les utilisateurs sauf ceux
197
des ingenieurs systeme et avoir encore la possibilite de faire cd ~dupont. Developpons cet exemple.
Supposons qu'il existe deux netgroups net_administrateurs et net_utilisateurs ; on mettra
donc dans le chier /etc/passwd du serveur NFS :
+@net_administrateurs::0:0:::
+@net_utilisateurs::0:0:::/bin/noshell
De cette facon, les utilisateurs normaux sont denis sur le serveur NFS mais ils ont un shell de login
(/bin/noshell) qui n'existe pas et les emp^eche donc de se connecter. Les ingenieurs systeme eux,
ont les m^emes informations passwd que celles propagees par NIS et peuvent donc se connecter.
REMARQUE : les methodes ci{dessus ne peuvent marcher que si le chier /etc/passwd permet
d'y mettre des noms de netgroups. Pour cela, il faut donc que ce chier /etc/passwd ne soit
pas celui a partir duquel on a construit la map passwd diusee par NIS. S'il se trouvait que ce
serveur NFS etait aussi le serveur primaire NIS, il faudrait absolument dissocier les entrees passwd
a diuser par NIS du chier /etc/passwd. Pour cela, on peut creer des chiers particuliers qui
vont servir a NIS, par exemple /etc/passwd.nis ou /var/yp/src/passwd. La methode la plus
simple est certainement de creer un directory dans lequel on stockera tous les chiers contenant les
informations a redistribuer par NIS, donc quelque chose comme /var/yp/src. On modie alors le
chier /var/yp/Makefile (qui est charge de distribuer manuellement les maps NIS) de la facon
suivante : on positionne la variable DIR a la valeur du nom du directory ou tous les chiers a diuser
resident :
DIR = /var/yp/src
198
+::0:0:::
On a vu que l'on pouvait restreindre l'acces a une station via l'emploi d'un netgroup dans le
chier /etc/passwd :
+@net_utilisateurs::0:0:::/bin/noshell
La restriction d'acces vient du shell impose aux utilisateurs, /bin/noshell, qui n'existe pas biens^ur.
En fait les deux formes citees ci{dessus rentrent dans le m^eme cas de gure. Il faut savoir que
les divers champs de la ligne peuvent ^etre modies. Dans ce cas, la valeur du champ se substitue
au champ correspondant de l'utilisateur. C'est ainsi que l'on peut imposer un certain shell aux
utilisateurs sur une certaine machine. . .
Les champs UID et GID ont cependant un fonctionnement particulier. Ce sont les valeurs que
prendront l'UID et le GID de l'utilisateur si le systeme ne les trouve pas dans les informations
transmises par NIS. L'absence de ces informations peut arriver tres facilement : il sut d'une
erreur dans le chier source des passwords sur le serveur NIS principal pour que NIS propage une
map passwd incorrecte. C'est pour cette raison qu'il vaut mieux ne pas mettre les valeurs 0 et 0
mais plut^ot :
+::65534:65534:::
De cette facon, en cas d'accident, aucun utilisateur ne pourra gagner les privileges de root et se
retrouvera commy ayant l'UID ou le GID de nobody (UID et GID valant -2 donc 65534 puisque les
UIDs et les GIDs sont codes sur 16 bits signes).
A noter le bug suivant sous DEC OSF1 2.0 :
Newsgroup: comp.unix.osf.osf1
From: [email protected] (Marcel Bernards)
Subject: Re: Any problems upgrading from OSF/1 v1.3 to v2.0??
Date: 20 May 1994 12:27:23 +0200
We ran into a nasty NIS passwd map bug.
Normally a NIS slave has an entry +: in /etc/passwd for including the NIS entries from the server.
We have users who want a local directory on the machine logging into for several good reasons.
For that purpose we us a well known feature in the NIS lookup switching the homedir entry in the NIS
map to a local directory in /etc/passwd.
+usera::::://local/home/dir/usera:
We have a Sun 4/280 NIS server and used this trick on many 3rd party clients in that NIS domain.
When running 1.2 and 1.3 OSF this also works as espected
When installing this in OSF/1 2.0 machines, this feature does not work any more.
199
We called DEC and they admit that this is a bug. It is xed in OSF/1 3.0 coming this summer(?)
but maybe there will be a patch released in the mean time. I'm not sure if this will arrive in time.
That's my story about OSF/1 2.0
Il est egalement conseille egalement d'installer tous les shells des utilisateurs dans le directory
de facon a ce qu'ils soient toujours disponibles localement (un probleme pourrait se poser si
un utilisateur utilisait un shell residant sur une partition d'un serveur NFS hors service momentanement ; en pratique, soit il se trouverait delogge du systeme a toute tentative de connexion, soit
son login se bloquerait en attente de la disponibilite du shell).
/bin
Une certaine commande est bien pratique pour verier la validite du chier /etc/passwd : il
s'agit de pwck. Elle permet de trouver un certain nombre d'erreurs pouvant se trouver dans le chier
/etc/passwd; par exemple :
nobody:x:65534:65534::/:/noshell
Optional shell file not found
audit:*:9:9::/etc/security/audit:/bin/csh
Login directory not found
La commande existe sur certains OS (par exemple SunOS). Ses sources peuvent ^etre trouvees dans
n'importe quelle distribution BSD. On l'utilisera pour verier periodiquement la consistance du
chier et de la map passwd aussi.
# 7 days in seconds
# (BSD | UPGRADE | ENHANCED)
200
A noter que DEC est l'un des rares constructeurs a fournir d'origine un mecanisme permettant
de choisir l'ordre de la methode de resolution des noms de machines.
NIS Client
NIS Server
Fake RPC Reply
RPC Reply
Intruder
Plusieurs programmes publies dans les news ont montre ce probleme (ypfake, ypx. . .).
Un article resume bien les problemes de securite poses par NIS. Il s'agit de l'article intitule A
Unix Network Protocol Security Hole: Network Information Service de David K. Hess, David R.
Saord et Udo W. Pooch, dont un URL est ftp://sc.tamu.edu/pub/security/NIS_Paper.ps.
Les constructeurs proposent quelques patches pour corriger ce probleme :
Systeme
AIX 3.2.3
DEC OSF1 1.x et 2.0
DEC ULTRIX 4.x
HP-UX 9.01
IRIX 4.0.5 et 5.2
SunOS 4.1.x
Solaris 2.x
Patch(es)
IX32328
???
???
PHNE_3390
???
100482-04
???
201
Patch(es)
???
???
???
???
???
100342-03
???
100564-06
File permissions on numerous les were set incorrectly in the build tape of 4.1.x FCS.
This script changes them back to what they should be.
yppasswd will not allow
ver. rpc.pwdauthd logs
user to change passwd from client, the daemon dies on sercleartext passwords via auditd. rpc.pwdauthd's core image
contains plaintext passwords and passwd.adjunct le. rpc.yppasswdd sometimes corrupt passwd dbm les.
D'une facon plus generale, on jettera un il aux patches constructeurs an de voir si d'autres
problemes ne seraient pas corriges.
202
>>
There are some problems with NIS+ that I consider almost fatal aws:
, the DNS domainname must equal the Secure RPC domainname. (or admintool won't work)
Perhaps this is a
aw in admintool, but this sure makes stu almost unusable for us.
, Servers must be in a domain one up from the clients This doesn't t the traditional NIS/YP
,
,
,
,
,
model making transition extremely hard. (There is really only one way: make all your NIS+ server
independent and root servers, those can be in the same domain)
no database recovery and backup tools that I know of. I don't use a database when I can't be
sure I can back it up and/or repair it.
.rootkey distribution problem. (now, there is talk about anonymous clients)
shadow passwords don't really work (or cumbersome, to say the least, or is this xed now)
some info must be accesable to the entire world
no password daemon (though one is being produced)
I nd that NIS to NIS+ transition in a situation with multiple NIS domain, but one DNS domain,
all servers in the same domain and use by users in the same domain as compute servers is next to
impossible.
13.8 Bibliographie.
Le lecteur pourra se reporter aux newsgroups consacres aux dierents systemes (cf [Generalites
sur les systemes abordes], page 7).
Le lecteur pourra se reporter aux ouvrages suivants:
[HSP] David K. Hess, David R. Saord, and Udo W. Pooch. A Unix Network Protocol Security
Hole: Ntwork Information Service. Technical report,
URL ftp://cs.tamu.edu/pub/security/NIS_Paper.ps
[Ste91] Hal Stern. Managing NFS and NIS. O'Reilly & Associates, Inc., 1991.
203
204
205
, Unicite des UIDs (la maniere la plus simple d'arriver a cela etant de travailler en utilisant NIS)
(cf chapitre 13 [Conguration du Network Information Service (NIS)], page 187).
, Tous les appels de procedures RPC sont auto-susants, contenant donc en parametres tout ce
Cet aspect sans etats se revele tres pratique en cas de crash du serveur NFS. Ainsi il redemarre
sans avoir a se soucier de ce qui se passait avant le crash (cela simplie aussi la conception du
serveur).
A l'URL ftp.uu.net:/networking/ip/nfs/NFS3.spec.ps.Z, on trouvera les specications de
NFS version 3. On jettera aussi un il a ftp://netapp.com/pub/netapp/docs/usenix94v3.ps.Z.
Les systemes actuels implantent tous
version 3 :
Systeme
AIX
DEC OSF1
DEC ULTRIX
FreeBSD
HP-UX
IRIX
Linux
NetBSD 1.0
SunOS 4.1.x
Solaris 2.x
206
foo()
{
...
return(*p);
...
}
station A
station B
Pour tenir compte des dierences dans les formats de representation interne des mots memoires
(machines big-endian, little-endian et egalement big-endian ou little-endian au niveau des bits),
les RPCs utilisent le mecanisme eXternal Data Representation (XDR) permettant de codier les
representations internes des mots memoire utilises dans les echanges reseau lors de RPC (marshalling).
Les RPC reposent bien s^ur sur IP. A priori, on aurait pu choisir UDP ou TCP pour realiser
les echanges. UDP a ete retenu pour la rapidite de traitement de ses paquets plus petits. Bien
s^ur, l'aspect de abilite de la transmission des paquets (permis par la retransmission des paquets
perdus) est perdu.
Moyennant cela, un programme peut realiser un RPC sur une autre machine. S'appuyant sur IP
et par consequent sur le mecanisme des sockets, l'execution d'un RPC necessite donc l'etablissement
d'un socket entre les deux machines donc entre deux ports des machines. Il faut donc au client
obtenir le numero de port de la procedure RPC. Cela se realise de la maniere suivante :
1. Le demon implantant la procedure est lance sur la machine B. A ce moment la, il s'enregistre
par registerrpc() aupres du demon portmapper (appele aussi rpcbind sur les UNIX de la
famille System V) qui lui assigne un numero de port sur lequel il peut ecouter. Le portmapper
ajoute le nouveau couple (port, procedure) dans ses tables internes.
2. Le demon de la procedure RPC se met en attente de connexion, via svc_run().
3. Une machine A desirant faire un RPC par call_rpc(), contacte le portmapper de B qui est
a l'ecoute sur un port bien precis ociel (well known port), le port 111 que cela soit en mode
UDP ou TCP. Le portmapper analyse la requ^ete speciant la procedure voulue et repond a A
par le port sur lequel ecoute la procedure indiquee.
4. La machine A peut alors etablir le socket entre les deux ports reseau et le RPC peut s'executer.
Il faut bien noter que, si la procedure RPC n'implante pas elle m^eme de mecanisme de securite,
il n'y a aucune securite non plus au niveau du fonctionnement du portmapper (cf section 14.5.8
[Probleme du vol de lehandle], page 224).
207
En pratique, un serveur NFS fait donc tourner deux demons RPC bien precis :
portmap
rpc.mountd
L'adoption de NFS par quasiment tous les constructeurs a ete rendue possible parce que
SUN, a l'origine du mecanisme des RPC et de XDR, en a rendu les sources publiques. Cf
ftp://playground.sun.com/pub/rpc/tirpcsrc2.3.tar.Z.
User Land
Kernel interface
File System
VNODE
MSDOS
file
VFS
Remote
file
VFS
UNIX
file
VFS
UNIX
device
VFS
RPC
XDR
UDP
IP
EThernet
network
On a donc procede a une generalisation abstraite de la notion de lesystem local, passant ainsi de
l'interface a base d'inode a une interface a base de virtual node (vnode). En pratique, un lesystem,
quel que soit son type (UFS, NFS, DOS, ISO9660. . .) est associe a une structure de type VFS au
208
moment de son montage, si bien qu'en cas de consultation NFS, le deroulement des choses est le
suivant :
System Calls
System Calls
(SERVER)
(CLIENT)
VNODE / VFS
VNODE / VFS
Client Routines
RPC / XDR
Server Routines
RPC / XDR
Ethernet Network
mount()
{
...
vfs_mount();
...
}
vfs_mount()
{
...
switch(type of the filesystem)
{
...
case NFS: nfs_mount();
break;
...
}
...
}
nfs_mount()
{
...
call_rpc();
allocate(VFS);
allocate(VNODE);
allocate(RNODE);
RNODE->filehandle = new filehandle;
...
}
Que se passe-t-il apres que la requ^ete de montage est acceptee par le serveur NFS ? On a beau
avoir reussi a monter le lesystem, il reste maintenant a y acceder et donc a pouvoir designer
les chiers qui s'y trouvent. Si l'utilisateur travaille sur les chiers en les designant par des noms
symboliques, il en va autrement du systeme. Dans le cas de chiers locaux, on utilise les inodes.
Dans le cas de NFS, la notion d'inode est generalisee et le lehandle en est l'incarnation.
209
Le lehandle est une quantite numerique permettant de designer un chier sur un serveur NFS
depuis un client NFS (sous une forme plus pratique pour le systeme que par le path du chier qui
necessiterait un traitement de resolution a chaque requ^ete). Une consequence de cela est que le
lehandle n'a un sens que pour le serveur ; on le qualie de quantite opaque pour le client NFS. En
pratique, on se doute qu'un lehandle contient un identicateur de disque, l'inode du chier mais
tout cela peut ^etre code dans le byte order du serveur NFS peut-^etre dierent de celui du client
NFS, tout cela peut ^etre padde dieremment selon les systemes. Bref le decodage d'un lehandle
ne concerne que le serveur NFS qui l'a emis. Dans NFS version 2, un lehandle est un tableau de
taille 32 bytes et dans NFS version 3, la taille du tableau peut varier de 32 a 64 bytes.
En pratique, quasimment toutes les procedures RPC du protocole NFS necessitent que soit
precise au moins un lehandle, soit le lehandle du chier que l'on est en train de manipuler, soit
le lehandle du directory dans lequel on fait des manipulations, plusieurs lehandles dans le cas de
procedures du genre RENAME(). . .
La recuperation de nouveaux lehandles se fait par la procedure LOOKUP (ainsi que READDIRPLUS
dans NFS version 3), sur le principe que pour en obtenir de nouveaux il faut deja en avoir au
prealable. Le systeme peut fonctionner parce que lors de la procedure de montage NFS, le client
NFS recupere le lehandle de la racine de l'arborescence montee. Ce lehandle permet donc ensuite
toute operation sur l'arborescence montee (cf section 14.5.8 [Vol de lehandle], page 224).
Cette analyse a aborde un point interessant de NFS, le fait qu'un certain nombre d'operations
se passe au niveau du noyau (pour des raisons de rapidite de traitement et des possibilites de
multithreading du noyau) :
Sur le client NFS
La principale activite va consister a demander des portions de chiers au serveur NFS
(quand ces portions seront modiees, le serveur recevra les parties modiees). Pour
anticiper de futures requ^etes de blocs NFS, le client lit plus de blocs que necessaire.
Cette lecture anticipee est realisee par des processus appeles en general biod ou nfsiod
mais qui se contentent de faire l'appel systeme async_daemon(), plongeant ainsi dans
la partie NFS du noyau.
Sur le serveur NFS
Les activites sont bien s^ur tournees autour du traitement de requ^etes NFS. Il faut
distinguer les requ^etes de montage NFS, des requ^etes d'acces aux chiers via NFS ;
les premieres sont traitees par un demon, rpc.mountd ; les secondes sont traitees par
les processus appeles en general nfsd mais qui se contentent de faire l'appel systeme
nfssvc() plongeant ainsi dans le noyau.
De par l'utilisation des RPC, de par le synchronisme des operations realisees, de par l'execution
de tout cela dans le noyau, on comprend bien pourquoi une station est souvent dans un etat piteux
en cas de problemes de nature NFS.
210
qu'au niveau de la machine : seules des machines sont autorisees, les autorisations ne sont pas
associees a des utilisateurs (les autorisations au niveau utilisateurs sont en cours de developpement).
Le contr^ole d'acces se fait par l'intermediaire d'un chier d'autorisations, le chier exports qui
est consulte par le demon rpc.mountd :
Systeme
Fichier de contr^ole
Commande de mise a jour
AIX versions 3.2.x et 4.1.x
/etc/exports
/usr/sbin/exportfs
DEC OSF1 versions 1.x, 2.0 et 3.0
/etc/exports
mise a jour automatique
DEC ULTRIX 4.x
/etc/exports
mise a jour automatique
FreeBSD 2.1.0
/etc/exports
kill -HUP `cat /var/run/mountd.pid`
HP-UX 8.07
/etc/exports
mise a jour automatique
HP-UX 9.0x
/etc/exports
/usr/etc/exportfs
HP-UX 10.0x
/etc/exports
/usr/sbin/exportfs
IRIX 4.0.5 et 5.2
/etc/exports
/usr/etc/exportfs
Linux 1.2.x
/etc/exports
???
NetBSD 1.0
/etc/exports
kill -HUP `cat /var/run/mountd.pid`
SunOS 4.1.x
/etc/exports
/usr/etc/exportfs
Solaris 2.x
/etc/dfs/sharetab
???
La syntaxe de ce chier est la suivante :
directory
-option[,option ]...
Parmi les options, on notera les suivantes : access, root directement liees aux noms des stations
autorisees a importer les disques. L'option -root sert a preciser la liste des stations qui verront
leurs requ^etes de lecture ecriture de chiers avec l'UID 0 realisees avec l'UID de root ou de nobody.
Certains systemes ne permettent pas cela, par exemple HP-UX 8.07 ; voici ce que suggere HP pour
realiser l'equivalence root via NFS :
Pour activer l'equivalence root via NFS, lancer le script
suivant :
#! /bin/sh
adb -w /hp-ux /dev/mem <<EOF
nobody/X
nobody/W0
nobody/X
EOF
L'option access sert a preciser quelles machines ont acces en lecture ecriture aux arborescences
exportees. On peut donner une liste composee de noms explicites de stations ou bien de netgroups
(cf section 13.4 [Les netgroups], page 195).
211
On ne peut pas donner de netgroups avec l'option root vraisemblablement pour des raisons de
securite informatique : si l'on est client NIS, on n'a aucun contr^ole sur le contenu des netgroups que
l'on utilise, si bien que l'on ne peut pas exercer de veritable contr^ole sur qui accede en root-NFS a
ses partitions.
Pour les autres options, voir son manuel prefere.
On notera que dans la version actuelle de NFS, on ne peut exporter un disque qu'a une machine
ou a un ensemble de machines ; il n'y a aucune possibilite d'exporter un disque a un individu.
On notera aussi que l'on peut exporter un disque de deux facons dierentes, par exemple en
read/write pour certaines machines et en read-only pour d'autres. Pour y arriver, il sut d'utiliser
les options -rw et -access comme dans l'exemple suivant ou l'on ne donne l'acces en ecriture qu'a la
machine excalibur.ens.fr, les stations thorgal.ens.fr et falbala.ens.fr devant se contenter
d'un acces en lecture uniquement :
/ensapb/homes
-rw=excalibur.ens.fr,access=thorgal.ens.fr:falbala.ens.fr
falbala.ens.fr
thorgal.ens.fr
et
Un client ne fait tourner que des demons biod (nfsiod si l'UNIX est de la famille
System V), rpc.lockd et rpc.statd.
Serveur NFS
Un serveur NFS fait tourner les demons portmap (ou rpcbind), mountd (ou
rpc.mountd), nfsd, rpc.statd et rpc.lockd.
212
HP-UX 10.01
Le chier /etc/rc.config.d/nfsconf permet de congurer les aspects que l'on veut
de NFS.
[...]
NFS_CLIENT=1
NFS_SERVER=1
NUM_NFSD=4
NUM_NFSIOD=4
[...]
NetBSD 1.0
213
Les valeurs de ces variables et l'existence deu chier /etc/exports decident du lancement de NFS au niveau du script de demarrage /etc/rc.
SunOS 4.1.x
C'est l'existence d'un chier /etc/exports qui decide du lancement de NFS en mode
serveur par /etc/rc.local.
Solaris 2.x ???
214
lesystem et de le demonter des qu'il n'existe plus de le-descriptor ouvert le referencant au bout
d'un certain temps. De cette facon un client NFS n'a pas a interroger un serveur s'il n'utilise aucun
de ses lesystems et peut donc ne pas se rendre compte qu'un serveur a ete indisponible suite a un
probleme.
Cependant, l'automounter ne resoud pas tous les problemes de nature NFS : si on lance une
application qui accede a des chiers d'une partition distante et si en plein accces a des chiers
distants le serveur NFS tombe en panne, l'application restera bloquee tant que le serveur NFS ne
refonctionnera pas normalement. L'automounter ne debloquera pas cette situation car le blocage
est au niveau du kernel ; la ou l'emploi d'un automounter peut jouer un peu dans cette situation,
est sur la facon dont le montage qu'il fait est realise (parametre soft ou hard).
En resume, l'automounter permet de ne pas avoir de problemes lors de l'acces a des chiers
NFS mais si des chiers NFS en cours d'utilisation deviennent inaccessibles, les process y accedant
bloqueront et alors l'automounter n'apporte rien de plus que des montages permanents (via fstab
ou mount -t nfs. . .).
A noter un automounter dans le domaine public, AMD. Cf ftp://usc.edu/pub/amd pour la
version ocielle de amd, ftp://ftp.cs.columbia.edu/pub/amd pour une version plus debuggee
mais non ocielle.
"
"
Table de montage
/etc/mnttab
/etc/mtab
/etc/mtab
/etc/mnttab
215
[mount-options]
remote-location
mount-options
-ro,nosuid,soft
-rw,nosuid,soft
-rw,nosuid,soft
location
marie:/home/glouton
marie:/usr2
marie:/usr3
Il s'agit de tmp_mnt sur tous les systemes avec la version constructeur de l'automounter pour la
raison que tous ces automounters ont la m^eme origine, a savoir la version de Sun.
216
[mount-options]
remote-location
-rw,hard,intr
-rw,hard,intr
tournesol:/tournesol/homes
tournesol:/tournesol/local
217
FreeBSD 2.1.0
On congure le demarrage de l'automounter via le chier /etc/sysconfig :
[...]
# Set to appropriate flags if you want to use AMD
amdflags="NO"
[...]
Linux 1.2.x
NetBSD 1.0
SunOS-4.1.x
On peut lancer l'automounter depuis /etc/rc.local.
Solaris 2.x C'est le script /etc/init.d/nfs.client qui lance l'automounter :
Il peut arriver que l'on ait besoin d'ajouter des lesystems a gerer par l'automounter alors que
l'automounter tourne deja. On peut dire a l'automounter de relire ses chiers de conguration si
l'on a ajoute ou modie une entree ; pour cela, il sut d'envoyer le signal SIGHUP (le signal -1 pour
la commande kill) au process.
218
Pour arr^eter l'automounter, il faut envoyer le signal SIGTERM (le signal -15 pour la commande
mais surtout pas SIGKILL (le signal -9 pour la commande kill) . Un SIGKILL laisse en
general la station de travail dans un etat precaire conduisant plus ou moins rapidement a un
reboot. Le SIGTERM termine l'automounter, proprement, lui faisant demonter autant de lesystems
que possible, laissant montes les lesystems pour lesquels il y a encore des le descriptors ouverts.
Si on relance l'automounter apres l'avoir termine proprement, il reprend contr^ole des directories
qu'il gerait et qui auraient ete laisses montes.
kill)
Commande
Solaris 2.x
219
Voici cependant un extrait du APAR IX48289 IBM expliquant comment peauner le comportement d'un serveur NFS sur AIX 3.2.x. Les informations qu'on y trouve peuvent ^etre reutilises,
tout au moins en ce qui concerne la reconnaissance des problemes de la machine.
1. Do netstat -m
See if there are any requests for mbufs denied or delayed. If so, you need to increase the number
of mbufs available to the network. I can provide information on how to do this, but since this
is not usually a problem I do not append the information here.
2. Do netstat -in
See if there are any Oerrs reported. If there are any Oerrs you should increase the transmit
queues for the network device. This can be done with the machine running, but the interface
must be detached before it is changed. (rmdev -l the interface). Clearly you can not shut down
the interface on a diskless machine, and you may not be at liberty to shut down the interface
if other work is going on. In this case you can use the chdev command to put the changes in
odm so they will be activated on the next boot. The syntax is:
chdev -P -l ent0 -a xmt_que_size=120
Start by doubling the current value for the queue length, and repeat the process (adding an
additional 30 each time) until there are no Oerrs reported. Smit can be used to do the same
thing, entering through the Devices menus to do Change/Show on the appropriate network
adapter.
Ierrs are much more rare, and Ierrs are often reported for events that do not result in
dropped packets. If you think Ierrs are related to a performance problem The input queue
can be increased using methods similar to the above.
3. Do netstat -v before and after a test indicating the slow performance. Look for No Resources
Counts or no Mbuf Errors in particular. But any counts that are very large except byte count,
frame count and interrupt count may indicate problems.
4. If an NFS client is slow reading and/or writing you may be overrunning the server. Try running
with just one biod on the aected client. If performance increases, then something is being
overrun either in the network or on the server.
Execute
stopsrc -s biod
Stop all the src biod's with the above command. That will leave one kproc biod with which
you can still run. See if it runs faster with just the one biod. If your test runs faster, work on
the server rst. If it has no eect, restart the biod's with
startsrc -s biod
5. (This one only applies to server machines) On 3.2.5 and later machines, check for NFS UDP
buer overruns by executing
netstat -s
Look in the udp statistics for the socket buffer overflows statistic. If it is anything other
than 0 you are probably overrunning the NFS UDP buer.
On machines before 3.2.5 some versions of netstat do not report the socket buer over
ows
statistic. But you can get the same information from crash.
As root, invoke crash. When you get the > prompt, issue the crash sub-command:
knlist udpstat
The socket buer over
ows statistic indicates the count of packets thrown away due to the
NFS socket buer being full on the server. This can happen on heavily stressed servers or on
220
servers that are slow in relation to the client(s). eg: 520 server and 370 client. 1 or 2 or 5 or 10
is probably not a problem. Hundreds are. If this number continually goes up while you watch
it. It needs some kind of xing.
There are two things that can x NFS socket buer overruns. First try just increasing the
number of nfsd's that are being run on the server. If that does not cure the problem, then you
must adjust two kernel variables, sb_max (socket buer max) and nfs_chars (the size of the
NFS server socket buer). Use the no command to increase sb_max. Its default value is 65536.
Use the nfso command to increase the nfs_chars variable. Its default value is 60000. (If your
machine is earlier than 3.2.5, You must have PTF U418274 on the machine in order to have
the ability to query and set nfs_chars.) sb_max MUST be set LARGER than nfs_chars. It
is hard to suggest new values. The best values are the smallest ones that also make the udpstat
report 0 (or just a few) socket buer overruns.
Important notes on tuning sb_max and nfs_chars:
You must restart the nfsd daemons after adjusting the sb_max and nfs_chars
variables in order for them to take eect. Do
stopsrc -s nfsd; startsrc -s nfsd
If the nfsd's do not start, you have made a mistake in setting one of the two
variables and sb_max is probably not greater than nfs_chars.
These commands to change these variables must be run every time the machine
is booted. Put them in the rc.nfs le right before the nfsd daemons are started
and after the biod daemons are started. The position is important.
6. Some routers have been known to relay packets with the bare minimum inter-packet delays.
There have been where this has caused problems with some AIX machines. If there is a router
or other hardware between the server and client, you should check its tech manual to see if the
inter-packet delays can be congured to longer delays and see if that helps.
7. Check MTU matchup between server and client. (do netstat -i and check the MTU) If they
are dierent, try making them the same and see if the problem is eliminated. Also be aware
that if there are slow or wide area networks between the machines, routers, bridges, etc may
further fragment the packets to traverse these network segments. Attempt to determine the
smallest MTU between source and destination and change the rsize/wsize on the NFS mount
to some number lower than that "lowest-common-denominator" MTU.
221
Cette relative independance du client NFS vis-a-vis des tailles limites systeme de lesystems
et de chier, fait que, sur un systeme A qui par exemple aurait une taille limite de chier a 1
Go, on peut utiliser quand m^eme des chiers de plus d'1 Go du moment que le serveur B NFS le
supporte. Cela dit, les autres utilitaires du systeme A peuvent ne pas fonctionner parfaitement avec
ce lesystem monte par NFS depuis B ; cela est souvent le cas de df avec des lesystems de plus
de 2 Go (la version SunOS est dans ce cas). En voici un exemple ou l'on voit que la commande df
de SunOS renvoit n'importe quoi.
Machine SunOS 4.1.1 voyant deux disques NFS de 4 Go :
% df
Filesystem
kbytes
used
avail capacity
thorgal:/thorgal/homes3
-164229-1545138 1260006
68%
sambre:/sambre/homes -59444 1813345-1955487
45%
Mounted on
/network/thorgal/homes3
/network/sambre/homes
Les capacites achees sont en partie fausses. Par contre les pourcentages d'utilisation
sont corrects.
Machine SunOS 4.1.3 ou 4.1.4 voyant deux disques NFS de 4 Go :
% df
Filesystem
kbytes
thorgal:/thorgal/homes3
2097151
sambre:/sambre/homes 2097151
used
avail capacity
716242 1260006
0 2097151
36%
0%
Mounted on
/network/thorgal/homes3
/network/sambre/homes
Rien ici n'est correct, ni les capacites, ni les pourcentages d'utilisation. C'est le cas,
que cela soit avec le df SunOS ou le df GNU.
Les df de ces disques 4 Go sont en fait :
% df
Filesystem
/dev/dsk/c201d2s0
kbytes
used
avail capacity Mounted on
4030075 2649166 1260006
68%
/thorgal/homes3
% df
Filesystem
/dev/dsk/c201d5s0
kbytes
used
avail capacity Mounted on
4134860 1814056 2238106
45%
/sambre/homes
222
Il semble qu'il existe des problemes au niveau de l'interpretation de ces informations sur quelques
systemes. Plus exactement, certains systemes considerent que certains champs sont exprimes dans
une certaine unite alors que le serveur NFS les a exprimes dans une autre unite :
Certain vendors are a little confused about how UNIX is supposed to work. The st_
information returned by stat(2) is supposed to be in 512-byte blocks. Some
vendors botch this. AIX, for example, properly reports local lesystems in 512-byte
blocks, but across the network reports in 1024-byte blocks. HP-UX does the exact opposite.
Voila deux exemples de ce probleme :
blocks
n=
223
Now I even get this message for commands like `df'. The permissions on the partition I'm mounting
is rwxr-xr-x, so it's not something as simple as not having le permission to list the directory. What's
going on? How do I x this problem?
>>
Check if the users on your Suns are members of 8 or more groups. HP-UX 8.0x will only tolerate users
who are members of up to 7 groups. Raised quite a bit in 9.0 (either 16 or 20 groups; I've heard both
numbers mentioned).
, Realiser l'operation sur le serveur NFS plut^ot que sur un client NFS. Cela presente aussi
224
mountd
From a distant host, you can make a pmap_rmtcall call formatted as a mount request,
and the portmapper will forward it to the port you request. When the mount daemon
gets it, it will appear to originate from the local host. The mount daemon will verify
that the lesystem is exported to the local host, and return a valid lehandle.
One likely solution is to to enable port checking :
echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem
225
Now the mount daemon (modulo any bugs) will only accept requests from a privileged port. The rpc requests forwarded by the portmapper will (modulo any bugs) not
originate from a privileged port.
Cela dit, cette solution peut poser des problemes si on l'applique systematiquement :
Subject: Why can't Ultrix automount SGI lesystems?
DEC Ultrix's automount uses an "untrusted" port for mount requests. Add an -n to
the mountd lines in /usr/etc/inetd.conf (/etc/inetd.conf in IRIX 5.x), like so:
mountd/1
mountd/1
stream
dgram
rpc/tcp wait
rpc/udp wait
root
root
/usr/etc/rpc.mountd
/usr/etc/rpc.mountd
mountd -n
mountd -n
URL ftp://harbor.ecn.purdue.edu/pub/davy/nfswatch4.0.tar.Z.
Ce logiciel est capable d'analyser les requ^etes NFS a destination d'une station ce qui
peut se reveler bien utile en cas de probleme. Voici un exemple de ce que cela ache :
all hosts
Interval packets:
Total packets:
ND Read
ND Write
NFS Read
NFS Write
NFS Mount
YP/NIS/NIS+
RPC Authorization
Other RPC Packets
Client host
caferoyal
droopy
idefix
nfswatch>
On peut aussi acher des informations sur les lesystems auxquels on accede ou sur
les taux d'utilisation de chaque procedure NFS.
packetman
tcpdump
URL ftp://ftp.cs.curtin.edu.au//pub/netman/harchitecturei/packetman-1.2.tar.gz
Ce programmes n'est disponible qu'en version binaire pour un certain nombre d'architectures (DEC OSF1 et ULTRIX, IRIX, SunOS 4.1.x, Solaris 2.x).
URL : ftp://ftp.ee.lbl.gov/tcpdump-3.0.2.tar.Z
URL : ftp://ftp.ee.lbl.gov/libpcap-0.0.6.tar.Z
Parce qu'etant le plus polyvalent de tous les sniers UNIX, il est aussi capable d'analyser du trac NFS.
226
nfstrace
nfsbug
portmap3
rpcbind
securelib
URL ftp://ftp.win.tue.nl/pub/security/securelib.tar.Z
Cf section 15.4.4 [Outils de contr^ole dynamique d'un systeme], page 259.
14.7 Bibliographie.
Le lecteur pourra se reporter aux newsgroups consacres aux dierents systemes (cf [Generalites
sur les systemes abordes], page 7) ainsi qu'a comp.protocols.nfs.
Le lecteur peut se reporter aux articles suivants :
[Cal]
Brent Callaghan. The automounter. Technical report,
URL
ftp://ftp.uwtc.washington.edu/pub/Docs/SunWhitePapers/automounter.ps.Z
[Cor94a] John Corbin. The NFS implementation for Solaris 2.1. Technical report, 1994,
URL ftp://sunsite.unc.edu/pub/sun-info/white-papers/NFS_sol21.tar
[Cor94b] John Corbin. NFS performance for system administrators. Technical report, 1994,
URL ftp://sunsite.unc.edu/pub/sun-info/white-papers/NFS_perf.tar
[Mic93] Sun Microsystems. NFS: Network File System, Version 3 Protocol Specication. Technical
report, Sun Microsystems, 1993,
URL ftp://ftp.uu.net/networking/ip/nfs/NFS3.spec.ps.Z
[MK94] Varun Mehta and Rajiv Khemani. Tuning the SPARCserver 490 for Optimal NFS Performance. Technical report, 1994,
URL ftp://excalibur.ens.fr/pub/besancon/adm-cookbook/src/nfs-enhancementsun4-490.ps.gz
[per94] Networks and File Servers: A Performance Tuning Guide. Technical report, Sun Microsystems, 1994,
URL ftp://ftp.uwtc.washington.edu/pub/Docs/SunWhitePapers/networks_and_
servers_tuning_guide.ps.Z
[Ste91] Hal Stern. Managing NFS and NIS. O'Reilly & Associates, Inc., 1991.
227
ftp://ftp.uwtc.washington.edu/pub/Docs/SunWhitePapers/TheArtofAutomounting1.4.ps.Z
228
229
230
-- TCP/IP LOG -- TM: Thu Jul 21 20:29:26 -PATH: mafalda.ens.fr(1591) => tournesol.ens.fr(telnet)
STAT: Thu Jul 21 20:29:42, 50 pkts, 65 bytes [TH_FIN]
DATA: (255)(253)^C(255)(251)^X(255)(251)^_(255)(251) (255)(251)!(255)(251)"(255)
(253)^E(255)(251)$(255)(250)^X
: VT100(255)(240)(255)(253)^A(255)(252)^Abesancon
: XXXXXXXX
Apres
-- TCP/IP LOG -- TM: Thu Jul 21 20:29:51 -PATH: mafalda.ens.fr(1593) => tournesol.ens.fr(ftp)
STAT: Thu Jul 21 20:30:04, 16 pkts, 74 bytes [TH_FIN]
DATA: USER besancon
:
: PASS XXXXXXXX
PASS
:
: SYST
:
: PORT 129,199,115,30,6,58
:
: LIST
:
: QUIT
:
-- TCP/IP LOG -- TM: Thu Jul 21 20:30:16 -PATH: mafalda.ens.fr(1023) => tournesol.ens.fr(rlogin)
STAT: Thu Jul 21 20:30:27, 32 pkts, 55 bytes [TH_FIN]
DATA: besancon
: besancon
: vt100/9600
: (255)(255)ss
: 7
: P
: XXXXXXXX
231
Le programme ayant permis la capture et l'analyse de ces trames Ethernet fait moins de 1000 lignes
de C sur un Sun. . .
Un autre probleme d'UNIX est sa reutilisation de sources C ou sommeillent certains trous de
securite. Recemment un trou de securite a ete decouvert dans les demons de connexion par rlogin
qui permettait a quiconque ayant une connectivite INTERNET de se connecter en tant que root
sur une machine fonctionnant sous AIX 3.2.x ; il susait pour cela de lancer la commande :
% rlogin -l -froot <machine-AIX>
Ce trou est passe inapercu pendant des lustres. Moralite : un systeme peut toujours ^etre penetrable
sans qu'on le sache.
On pourrait multiplier les exemples.
D'autres points jouent en defaveur d'UNIX mais, par contre, ne lui sont pas imputables. Par
exemple de nombreuses aaires de piratage ont defraye la chronique de par le passe :
, Aaire du Lawrence Berkeley Laboratory en ao^ut 1986 (cf. The cuckoo's Egg : Tracking a Spy
Through the Maze of a Computer Espionage de Cli Stoll) ;
, Aaire du Internet Worm en novembre 1988 (cf. The Internet Worm Program: An Analysis
de Eugene H. Spaord, The Internet Worm Incident de Eugene H. Spaord, With Microscope
and Tweezers: An Analysis of the Internet Virus of November 1988 de Mark W.Eichin et Jon
A. Rochlis) ;
, Aaire du Wily Hacker en janvier 1991 (cf. An evening with Berferd, in which a cracker is
lured, endured, and studied de William R. Cheswick) ;
Ces aaires constituent des pages croustillantes de l'^age d'or de l'informatique reseau. On y voit
le reseau controverse en fait de deux facons :
1. le reseau est l'outil de l'attaque ;
2. le reseau a servi a informer les spheres informatiques des aaires en cours. Le but etait honorable
car en mettant les foules au courant, on esperait de l'aide et montrer le bon exemple a suivre.
Certains n'en auront retenu cependant que l'aspect negatif : UNIX a des faiblesses mais combien
de systemes IBM MVS auront ete pirates sans que cela soit revele au public ? Obscurantisme. . .
232
de ce chier est devenu strategique au fur et a mesure des annees, m^eme si les mots de passe y sont
stockes de maniere chiree.
Le probleme est donc d'eviter que des gens mal intentionnes puissent s'accaparer ce chier an
d'en dechirer le contenu. Or dans la conguration par defaut des systemes, rien n'est plus facile :
1. Si la station fonctionne sous NIS, il est possible de recuperer toutes les entrees password. Pour
cela, il sut de brancher une station sur le reseau a espionner puis d'utiliser certains logiciels
et on recupere ce que l'on veut.
2. Si la station fonctionne sans NIS, il sut de recopier le chier /etc/passwd. Pour pouvoir faire
cela, il faut, cependant, avoir deja un compte sur la station a cracker.
Alors comment changer cela ? La solution est d'autant plus compliquee qu'il faut assurer la
compatibilite avec un certain nombre d'applications qui consultent le chier /etc/passwd pour
en extraire des informations non sensibles comme le nom du home-directory d'un utilisateur par
exemple.
La solution adoptee par tous les constructeurs, est ce que l'on appelle les shadow passwords.
Il s'agit de retirer du chier /etc/passwd les informations condentielles que sont les mots de
passe chires et de les stocker dans un autre chier a l'acces reserve a root uniquement. Le champ
password d'une ligne de /etc/passwd contient alors une information ininteressante mais permet
aux autres programmes de continuer a acceder de m^eme qu'avant a /etc/passwd.
Voici ce qu'il en est des shadow passwords chez les principaux constructeurs :
AIX 3.2.3 C'est le fonctionnement par defaut sur AIX-3.2.3. Voici un extrait de /etc/passwd :
root:!:0:0:Le super utilisateur:/:/bin/csh
daemon:!:1:1::/etc:
bin:!:2:2::/bin:
Les mots de passe sont stockes dans le chier /etc/security/passwd, (non accessible
par tout le monde puisque le directory /etc/security, appartenant a root.security,
a pour droits d'acces 750) :
root:
daemon:
bin:
password = BScErWZr8RLb2
lastupdate = 727443298
flags =
password = *
password = *
On notera que des dates de derniere modication sont conservees ce qui permet d'invalider un compte dont on jugera le mot de passe trop vieux.
DEC Ultrix 4.x
Un systeme des shadow passwords est activable sur ULTRIX 4.x2 . Pour l'activer, il
faut dire au systeme qu'il fonctionne sous shadow password ; pour cela, il faut preciser
ce mode de fonctionnement dans /etc/svc.conf :
2
Les informations donnees ici le sont sans que le mode ait jamais ete active, uniquement sur
lecture des pages de manuel.
SECLEVEL=ENHANCED
233
plus facile a modier que la forme sous laquelle elle est stockee. On notera la longueur
de la cha^ne chiree du mot de passe qui laisse penser que l'algorithme utilise n'est pas
celui usuel.
Seuls root et les membres du group authread peuvent consulter la base ; seul root
peut modier la base.
DEC OSF1 2.0
Un systeme des shadow passwords est activable sur OSF13 . Pour l'activer, il faut dire
au systeme qu'il fonctionne sous shadow password ; pour cela, il faut preciser ce mode
de fonctionnement dans /etc/svc.conf :
SECLEVEL=ENHANCED
Trois modes sont activables ; l'interpretation est la m^eme que pour DEC ULTRIX 4.x.
Une fois le mode de securite active, le systeme va aller consulter les mots de passe
dans la base securisee. L'acces a la base de donnees est analogue a celui des chiers
de description terminfo : ainsi, les renseignements relatifs a l'utilisateur besancon
seront-ils cherches dans le chier /tcb/files/auth/b/besancon.
Le contenu de chaque chier est decrit dans prpwd(4) et authcap(4) et prend la forme
suivante :
perry:u_name=perry:u_id#101:\
:u_pwd=aZXtu1kmSpEzm:\
:u_minchg#0:u_succhg#653793862:u_unsucchg#622581606:u_nullpw:\
:u_suclog#671996425:u_suctty=tty1:\
:u_unsuclog#660768767:u_unsuctty=tty1:\
:u_maxtries#3:chkent:
Les informations donnees ici le sont sans que le mode ait jamais ete active, uniquement sur
lecture des pages de manuel.
234
SunOS 4.x
On notera qu'une ligne ce chier contient le m^eme nombre de champs que le chier
/etc/passwd, tout simplement pour pouvoir r
eutiliser les fonctions de parsing d'une
ligne de passwd. Bien s^ur, l'acces au directory /etc/security est restreint.
La particularite de ce package est de pouvoir fonctionner sous NIS (bien s^ur a la condition que toutes les stations aient installe le package C2). On prendra soin d'appliquer
tous les patches SunOS relatifs au kit C2, par exemple les patches 100564-07 et 10171801. Suite a l'application de ces patches, deux utilisateurs sont ajoutes : AUpwdauthd et
AUyppasswdd et leurs entr
ees dans les chiers ad-hoc ajoutees :
/etc/passwd
AUpwdauthd:##AUpwdauthd:10:10:::/bin/false
AUyppasswdd:##AUyppasswdd:11:10:::/bin/false
/etc/security/passwd.adjunct
AUpwdauthd:*:::::
AUyppasswdd:*:::::
Solaris 2.x C'est le fonctionnement par defaut sur Solaris-2.x. Voici un extrait de /etc/passwd:
235
root:x:0:1:0000-Admin(0000):/:/sbin/sh
daemon:x:1:1:0000-Admin(0000):/:
besancon:*:10141:201:Thierry Besancon:/home1/Guests/besancon:
Les mots de passe sont stockes dans le chier /etc/shadow, (non accessible par tout le
monde puisque le chier, appartenant a root.sys, a pour droits d'acces 400) :
root:Oja/8gQ79SUQI:::::
daemon:*:::::
besancon:Ix7WNLnWzdQ4s:::::
Si ce chier existe, detruisez le. Quand il existe et qu'il contient des noms de station,
alors les connexions depuis les stations mentionnees se font sans exiger de mot de passe
du moment qu'un utilisateur porte le m^eme nom sur votre station.
Par defaut, la procedure d'installation d'une nouvelle station Sun fonctionnant sous
SunOS 4.1.x, installe un chier /etc/hosts.equiv contenant la ligne + ce qui autorise
toutes les stations a se connecter sans demande de mot de passe du moment que l'on
aura devine un nom de login (ce qui est faisable par l'emploi des commandes finger,
rwho etc.).
$HOME/.rhosts
Il n'est prevu aucun procede de protection vis-a-vis de ces chiers. Pire : le contenu
de ces chiers etant relativement condentiel ; on s'attendrait donc a ce que les droits
d'acces de ce chier soient assez restreints, du genre 0400 ; or lors de l'acces NFS a ce
chier, les demons rlogind ont besoin de lire ce chier et suivant les systemes, cela
necessite que le chier soit en lecture publique.
Dans le cas general, on se contentera de verier periodiquement le contenu de ce chier.
Pour cela, on pourra utiliser un shell-script ecrit en perl. Voici le genre de choses qu'il
signale :
ERROR: line 1, /users/stat3/jma/.rhosts user 'besancon' != 'jma'
ERROR: line 2, /users/stat3/jma/.rhosts user 'besancon' != 'jma'
ERROR: line 4, /users/stat3/jma/.rhosts IP name 'ariana' couldn't be resolved
236
Cela verie donc la coherence des noms presents ainsi que la validite des noms de
machines mentionnees. Ce script est disponible sur le site excalibur.ens.fr sous le
nom /pub/besancon/adm-cookbook/src/cron-check-.rhosts.pl.
La procedure C responsable de l'analyse de ces chiers est sur tous les UNIX la procedure
Le package logdaemon-4.4 (decrit en Cf section 15.4.4 [Outils de contr^ole dynamique
d'un systeme], page 259) contient une version modiee de ruserok() permettant de refuser l'utilisation du + dans /etc/hosts.equiv et $HOME/.rhosts. Sur les systemes ou l'on est capable de
recompiler la librairie C dynamique, on envisagera donc d'integrer cette version securisee de la
routine.
ruserok().
A propos
Le contenu du chier /etc/hosts.equiv ne concerne pas root. Pour root, seul compte son
chier /.rhosts. Un autre chier joue cependant un r^ole dans l'authentication de l'utilisateur
root : le chier /etc/ttytab. Ce chier contient la liste des terminaux et pseudo terminaux de
votre systeme ; a chaque terminal est associe, par exemple, sa vitesse de transmission des caracteres
(cf section 20.3.2.2 [Conguration de init], page 354). Il contient aussi un champ indiquant si root
peut se logger directement sur ce terminal :
#
# name
#
console
ttya
ttyb
tty00
[...]
getty
"/usr/etc/getty
"/usr/etc/getty
"/usr/etc/getty
"/usr/etc/getty
std.9600"
std.9600"
std.9600"
std.9600"
type
status
sun
unknown
unknown
unknown
on
off
off
off
comments
local
local
local
local
secure
secure
secure
secure
La cha^ne secure indique que root est autorise a se connecter directement. La sagesse conseille
de n'autoriser les logins root que sur la console et sur les terminaux connectes par voie serie que
l'on sait s^urs (du genre : des terminaux dans une salle informatique ou peu de gens ont acces). La
raison pour cela est bien simple : quand quelqu'un se logge root, on ne peut pas savoir qui utilise
le compte root ; la seule trace est, en eet, gardee par la station d'ou vient la personne et vous n'y
avez pas forcement acces. Par contre, si root ne peut pas se logger directement, l'utilisateur doit
passer par l'etape du su root qui, lui, laisse une trace sur votre systeme. Dans le cas ou la ligne
n'est pas secure, une connexion au nom de root donnera :
excalibur:[44]:</excalibur/homes/besancon>rlogin papoon -l root
Login incorrect
237
Option de contr^ole
des chiers speciaux
Option de contr^ole
des chiers suid
nodev
nosuid
nodev
nosuid
nodev
nodev
{
{
nosuid
nosuid
nosuid
nosuid
nosuid
Dans le cas ou la partition serait montee en interdiction d'utilisation de tels chiers, l'execution
de chiers suid se traduirait par un message du type :
% ./suid-program
./suid-program: Setuid execution not allowed
[...]
Execution du programme.
On notera bien que le programme cherche a s'executer mais sans eectuer le changement d'UID,
ce qui peut compromettre le deroulement normal de l'application.
Si l'on est oblige de monter une partition avec permission d'executer des chiers suid, on prendra
soin de verier periodiquement ces chiers suid pour voir si leur nombre n'augmente pas sans raison,
s'ils n'ont pas ete modies sans raison. . .
On notera bien que l'on ne peut contr^oler que l'utilisation de tels chiers et non leur creation. En
fait, on ne se protege pas de leur creation au niveau du lesystem mais au niveau des appels systeme
permettant leur creation. Ainsi la commande mknod ou l'appel systeme mknod() necessitent-ils d'^etre
l'utilisateur root pour permettre la creation de peripheriques de types block ou caractere. Quant a
chmod permettant de positionner le bit s, le cas le plus dangereux se trouve quand le propri
etaire
du chier est root ce dont on se protege en ne permettant pas a l'utilisateur lambda de faire un
chown root. Les m^
emes principes s'appliquent au cas de NFS, qui suit.
238
NFS (cf chapitre 14 [Conguration du Network File System (NFS)], page 205) est de loin la
methode de partage de chiers la plus sophistiquee. Divers points de NFS sont securisables :
1. A qui exporte-t-on une partie de l'arborescence ?
2. Comment lui exporte-t-on l'arborescence ?
3. Comment doit-on importer cette arborescence ?
Le point 1 fait l'objet du chier /etc/exports (cf section 14.2 [Contr^ole de l'exportation des
disques sur un serveur NFS], page 209) ; une liste de machines auxquelles on exporte une arborescence peut y ^etre precisee soit explicitement soit en utilisant le raccourci qu'orent les netgroups
de NIS (cf section 13.4.2 [Netgroups et exportations de disques], page 196).
NFS ne donne pas beaucoup de libertes pour le point 2. On ne peut guere contr^oler que l'acces
en lecture{ecriture de l'arborescence exportee et la facon dont les chiers crees par un root distant
seront eectivement crees (probleme de l'equivalence de root via NFS ; cf section 14.2 [Contr^ole
de l'exportation des disques sur un serveur NFS], page 209).
En fait, de par la nature stateless du protocole NFS, les methodes d'acces aux chiers sont plus
du ressort du client NFS que du serveur NFS, d'ou le point 3. Il en est ainsi pour les chiers suid et
les chiers speciaux : le serveur NFS peut proposer ces chiers dans l'arborescence exportee (voir
auparavant) mais ce n'est pas parce qu'il les propose que leur utilisation est autorisee sur le serveur
(revoir precedemment). C'est donc au client de contr^oler leut utilisation (le kernel du client sait
bien a quel type de chiers il a aaire et s'ils sont importes par NFS). Le contr^ole de ces chiers
est determine par les options donnees lors du montage NFS de l'arborescence. Certains systemes
permettent ainsi d'invalider l'utilisation des chiers suid et des chiers peripheriques ; d'autres non
; sur tous ces systemes, on re
echira donc si l'utilisation de ces options s'imposent et on pesera le
danger presente en cas d'absence de ces options ou de leur non utilisation. Voila ce qu'il en est des
options sur les dierents systemes :
Option de contr^ole
Option de contr^ole
Systeme
des chiers speciaux
des chiers suid
AIX 3.2.3
nodev
nosuid
DEC OSF1 2.0
nodev
nosuid
DEC ULTRIX 4.x
{
nosuid
4
HP-UX 8.07 et 9.01
nodevs
nosuid
IRIX 4.0.5 et 5.2
nodev
nosuid
SunOS 4.1.x
{
nosuid
Solaris 2.x
{
nosuid
Pour une fois, les systemes developpes sur bas BSD ont le desavantage sur les systemes d'origine
System-V, en ne proposant pas d'option de montage en nodev.
239
Le probleme est que si le demon tftpd est mal congure, il permet de recuperer TOUT chier.
Voici les ponts a consulter pour rendre demon securise :
Systeme
Demon
Methode de contr^ole d'acces
AIX 3.2.3
/usr/sbin/tftpd
chier /etc/tftpaccess.ctl
DEC OSF1 1.x, 2.0, 3.0
/usr/sbin/tftpd
chier /etc/tftptab
DEC ULTRIX 4.x
/usr/etc/tftpd
option -r pathname a preciser dans
la ligne de lancement de tftpd dans
HP-UX 8.07 et 9.01
IRIX 4.0.5 et 5.2
/etc/inetd.conf
/etc/tftpd
/usr/etc/tftpd
SunOS 4.1.x
/usr/etc/in.tftpd
Solaris 2.x
/usr/sbin/in.tftpd
Ce chier contient les noms des personnes non autorisees a utiliser le programme ftp
pour se connecter au systeme. Une sage precaution est de mettre l'utilisateur root dans
ce chier.
/etc/shells
Ce chier contient les noms des shells de login des utilisateurs autorises a utiliser ftp.
L'ajout d'un shell dans le systeme doit s'accompagner de l'ajout de son nom dans
ce chier sinon toutes les personnes l'utilisant comme shell de login ne seront plus
autorisees a faire ftp ce qui provoquera un message du type :
240
% ftp corto
Connected to corto.ens.fr.
220 corto.ens.fr FTP server (SunOS 4.1) ready.
Name (corto:besancon):
530 User besancon access denied.
Login failed.
ftp>
Ici, mon shell n'etait pas present dans le chier /etc/shells de cette station nouvellement arrivee.
Quel est l'inter^et de ce chier ? Sur certains OS, il existe des comptes publics sans
mot de passe dont le r^ole est de lancer un programme particulier. C'est le cas du
compte sync sur SunOS qui lance /bin/sync. En ne mettant pas ces programmes dans
/etc/shells, on interdit donc d'utiliser ces comptes publics sans mot de passe via ftp.
La plupart du temps, le demon ftpd va consulter le chier /etc/shells, sauf sur AIX
ou il s'agit du chier /etc/security/login.cfg, qui prend la forme suivante :
[...]
usw:
shells = /bin/sh,/bin/bsh,/bin/csh,/bin/ksh,/bin/tsh,/usr/bin/sh,
/usr/bin/bsh,/usr/bin/csh,/usr/bin/ksh,/usr/bin/tsh,
/usr/mbin/sh,/usr/mbin/bsh,/usr/mbin/csh,/usr/mbin/ksh,
/usr/mbin/tsh,/bin/tcsh,/bin/bash,/bin/lstcsh
maxlogins = 64
, le systeme est ralenti par tous les evenements d'audit a generer et a enregistrer ;
, l'audit genere des chiers tres vite tres gros et impossibles a exploiter ;
, le systeme ne peut rien contre un piratage de la machine : il a beau ^etre imposant en theorie,
si un trou beant de securite (comme c'est la plupart du temps) existe, il sura au cracker
d'exploiter ce trou puis de supprimer les chiers de log de l'audit ou d'arr^eter l'audit tout
simplement.
Le systeme de l'audit est disponible sur la quasi-totalite des systemes mais n'en est pas pour autant
standard, au contraire. . .
Le peu d'utilite pratique de l'audit pour la securite est un peu compense par les enregistrements
des connexions et deconnexions eectues systematiquement par le systeme. Ces enregistrements
sont ranges dans deux chiers :
utmp
wtmp
241
Les enregistrements sont au format utmp deni dans <utmp.h>. Comme generalement, on a
plus besoin de savoir qui s'est connecte, on a plus besoin d'examiner le chier wtmp, ce que fait la
commande last :
ftp
ftp
ftp
ftp
ftp
ftp
besancon
besancon
besancon
besancon
ftp
ftp
ftp
ftp
ftp
ftp
ttyp4
ttyp3
ttyp0
ttyp1
verne.cnam.fr
grasp.insa-lyon.
iijmp.laas.fr
iijmp.laas.fr
opt13.emse.fr
frbdx12.cribx1.u
:0.0
:0.0
:0.0
:0.0
Mon
Mon
Mon
Mon
Mon
Mon
Sun
Sun
Sun
Sun
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
19
19
19
19
19
19
18
18
18
18
16:25
16:11
10:32
10:14
09:51
09:25
23:26
21:49
21:36
21:36
16:27
16:11
10:56
10:30
09:57
09:25
still
still
still
still
(00:01)
(00:00)
(00:24)
(00:15)
(00:06)
(00:00)
logged in
logged in
logged in
logged in
La commande last (et donc les chiers d'enregistrement des connexions et deconnexions) est
disponible sur les systemes suivants :
Systeme
AIX 3.2.3
DEC OSF1 2.0
DEC ULTRIX 4.3
HP-UX 8.07 et 9.01
IRIX 4.0.5
IRIX 5.2
SunOS 4.1.x
Solaris 2.x
Fichier utmp
Fichier wtmp
Commande last
/etc/utmp
/var/adm/wtmp
/bin/last
/var/adm/utmp
/var/adm/wtmp
/bin/last
/etc/utmp
/var/adm/wtmp
/usr/ucb/last
/etc/utmp
/etc/wtmp
/etc/last
/etc/utmp
/etc/wtmp
/usr/bsd/last
/var/adm/utmp
/var/adm/wtmp
/usr/bsd/last
/etc/utmp
/var/adm/wtmp
/usr/ucb/last
/var/adm/utmp
/var/adm/wtmp
/bin/last
Si le systeme d'analyse de l'utilisation des ressources de la station (ce que l'on appelle l'accounting) est installe, on peut disposer alors du nom des commandes lancees par les utilisateurs.
Malheureusement, l'accounting etant oriente facturation du temps CPU utilise, il ne donne pas les
informations dont on pourrait avoir besoin en securite :
F
F
F
root
4332
besancon
besancon
besancon
X besancon
root
__
ttyq4
ttyq4
ttyq4
ttyq4
ttyq4
__
0.14
0.00
0.05
0.00
0.36
14.88
0.30
secs
secs
secs
secs
secs
secs
secs
Fri
Fri
Fri
Fri
Fri
Fri
Fri
Oct
Oct
Oct
Oct
Oct
Oct
Oct
7
7
7
7
7
7
7
11:04
11:04
11:04
11:04
11:03
11:03
11:03
242
tracerou
X
tracerou
ls
papstatu
users
bash
F
date
mesg
stty
tty
bash
F
hostname
bash
F
papstatu
Mail-101
amd
SF
xmail
DX
[...]
besancon
besancon
besancon
root
besancon
besancon
besancon
besancon
besancon
besancon
besancon
besancon
besancon
root
tcheou
root
tcheou
ttyq4
ttyq4
ttyq4
__
ttyq4
ttyq4
ttyq4
ttyq4
ttyq4
ttyq4
ttyq4
ttyq4
ttyq4
__
__
__
__
0.09
0.12
0.17
0.17
0.06
0.06
0.08
0.05
0.06
0.06
0.08
0.02
0.03
0.11
3.42
0.06
3.33
secs
secs
secs
secs
secs
secs
secs
secs
secs
secs
secs
secs
secs
secs
secs
secs
secs
Fri
Fri
Fri
Fri
Fri
Fri
Fri
Fri
Fri
Fri
Fri
Fri
Fri
Fri
Fri
Fri
Fri
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
11:03
11:02
11:02
11:02
11:02
11:02
11:02
11:02
11:02
11:02
11:02
11:02
11:02
11:02
10:35
11:02
10:35
Le resultat de latscomm est assez peu clair ; on ne dispose notamment que des 8 premiers caracteres
du nom de la commande. . . En fait, le format d'une ligne renvoyee est :
nom-commande
flags
username
tty
CPU-time
date-debut
et une commande n'est enregistree qu'une fois son execution terminee, ce qui complique l'analyse
chronologique du chier.
La commande lastcomm est disponible sur les systemes suivants :
Systeme
AIX 3.2.3
DEC OSF1 2.0 et 3.0
DEC ULTRIX 4.3
HP-UX 8.07 et 9.01
IRIX 4.0.5 et 5.2
SunOS 4.1.x
Solaris 2.x
Commande lastcomm
/bin/lastcomm
/bin/lastcomm
/usr/ucb/lastcomm
/usr/bin/lastcomm
non disponible
/usr/ucb/lastcomm
/bin/lastcomm
Le probleme de l'accounting provenant de l'impossibilite a determiner ce que l'utilisateur a reellement accompli, il a ete mis au point un systeme restreignant ce qu'un utilisateur peut accomplir.
Il s'agit du principe du restrictd shell qui est un environnement utilisateur dans lequel le path rendu
non modiable ne contient que des commandes soigneusement selectionnees et dans lequel l'utilisateur est conne a une partie d'arborescence. En pratique, le bon fonctionnement des restricted
shells reste a prouver et leur constitution est tres delicate a realiser, comme on peut le voir ci apres
(l'exemple a ete realise sur une station en SunOS 4.1.x) :
excalibur:[1455]:</excalibur/homes/besancon>cat buggy.sh
#!/bin/sh
PATH=/usr/bin; export PATH
ls
excalibur:[1457]:</excalibur/homes/besancon>export SHELL=/usr/lib/rsh
excalibur:[1458]:</excalibur/homes/besancon>/usr/lib/rsh
243
$ ./buggy.sh
./buggy.sh: restricted
M^eme chose.
PATH: restricted
$ echo abc > foo
foo: restricted
stdout
$ cd ..
cd: restricted
etc.
Tous ces exemples ci-dessus sont la pour montrer que bon nombre de shell-scripts tres repandus
dans les systemes ne marcheront pas sans ^etre profondement revus.
On se reportera aux pages de manuel ad-hoc pour congurer un restricted shell :
Systeme
AIX 3.2.3
DEC OSF1 2.0
DEC ULTRIX 4.x
HP-UX 8.07 et 9.01
IRIX 4.0.5
IRIX 5.2
SunOS 4.1.x
Solaris 2.x
Restricted shell
/bin/Rsh voir man sh
/bin/Rsh voir man sh
???
voir man sh
/bin/rsh voir man sh
/usr/lib/rsh voir man sh
/usr/lib/rsh (non document
e)
/usr/lib/rsh voir man sh
/bin/rsh
, leur diusion publique leur permet d'^etre testes sur de nombreuses plateformes ;
, leur diusion publique permet la diusion rapide des nouvelles versions corrigeant des bugs ou
apportant de nouvelles fonctionnalites.
244
Unique probleme de ces outils : leur detournement de leur objectif principal par des personnes
mal intentionnees.
1 root
1 root
root
root
[...]
#
# Set the device file(s) used by /etc/rbootd
# If no device is specified, /etc/rbootd will
# use the device corresponding to the ethernet
# address of the machine.
#
RBOOTD_DEVICES=""
Autre probleme : des droits trop l^aches, par exemple les directories /tmp et /usr/tmp
ont 777 pour mode et non pas 1777. . .
IRIX 4.0.5 La commande find / -perm -2 -print signale un certain nombre de directories et
chiers en ecriture publique.
SunOS 4.1.x
Sun continue de livrer un chier /etc/hosts.equiv.
Finalement, des mecanismes de securite constructeurs peuvent se reveler incompatibles les uns
avec les autres en environnement heterogene.
Corriger des droits d'acces est facile a faire ; il sut d'une simple commande comme la suivante
pour trouver tous les chiers suid :
find /
\( -type d -fstype nfs -prune \) -o -type f \( -perm -4001 -o -perm
-4010 -o -perm -4100 -o -perm -2100 -o -perm -2010 -o -perm -2001 \) -print
Le probleme est plus de savoir quoi corriger sur quel systeme, quels points presentent un danger
? Plusieurs outils de securite se sont specialises dans le diagnostic des systemes. Faciles a mettre
245
en uvre, aptes a passer en revue un certain nombre de failles de securite archi connues, rapproblemes trouves excellent, ne peuvent que pousser a l'utilisation de ces logiciels.
port nombre de
temps passe
D'autres pallient a ces problemes d^us a l'heterogeneite des systemes. Voici quelques uns de ces
programmes.
Logiciel COPS.
Le logiciel COPS (Computer Oracle Password and Security system) permet de faire des verications sur divers aspects de securite UNIX mais pas, entre autres, sur les aspects reseau.
Il part du principe que beaucoup de problemes de securite ont leur source dans de petits details
de conguration systeme, simples a corriger et aussi simples a decouvrir. Cela se re
ete dans son
implantation :
, le logiciel est compose d'une douzaine de petits modules simples, chacun charge de veiller a
un point de securite simple ; la plupart des modules sont des shell-scripts, donc sont portables
d'un systeme a un autre ; le lancement de ces shell-scripts est parametrable ;
, aucune reparation n'est eectuee par COPS, pour que celui-ci ne necessite pas de droits particuliers, pour ^etre s^ur que ce logiciel ne compromette pas davantage le systeme ;
, aucune explication n'est donnee dans le rapport d'intervention de COPS ; les problemes rencontres y sont mentionnes d'une facon telle que l'administrateur sait comment les corriger sans
pour autant se voir precise la methode d'exploitation du trou de securite.
Un article resume bien tout cela. Je vous y renvoie : il est disponible sur le site
sous le nom pub/usenix/summer90/cops.ps.Z
ftp.sage.usenix.org
Point 1 7!
Point 2 7!
Point 3 7!
Point 4 7!
Point 5 7!
Point 6 7!
246
Point 7 7!
Point 8 7!
Point 9 7!
Point 10 7!
Point 11 7!
Point 12 7!
Point 13 7!
Point 2
Point 3
Point 4
Pourquoi est-il dangereux que root ne soit pas le proprietaire des directories cites ?
Tout simplement parce qu'il est plus facile de cracker le compte de bin que de root
et donc l'ayant cracke, on pourrait mettre dans ces directories des chevaux de Troie
que root pourrait ^etre amene a utiliser plus tard, compromettant ainsi davantage le
systeme.
D'autre part, en cas d'exportation NFS de ces partitions, on ne rencontre pas le probleme d'equivalence de root a travers NFS. Donc, il sut d'^etre root sur une station
important les partitions, puis de faire su bin pour pouvoir modier ces partitions, y
mettre par exemple un chier .rhosts autorisant une connexion au nom de bin.
Pourquoi est-il dangereux d'avoir "." dans son PATH ?
Tout simplement parce qu'une commande a executer sera cherchee dans le directory
courant et non dans les directories systeme, si bien que si root s'est place dans un
directory utilisateur, il pourrait executer des commandes piegees.
Pourquoi est-il dangereux que root ait /usr/local/bin dans son PATH alors que celuici est en ecriture publique ?
Tout simplement parce que quiconque peut mettre dans /usr/local/bin une commande piegee que root pourrait ^etre amene a utiliser.
Pourquoi est-il dangereux que des partitions soient exportees sans contr^ole ?
Point 5
Point 6
Point 7
Point 8
Point 9
Point 10
Point 11
Point 12
Point 13
247
Tout simplement parce que si un cracker monte la partition a votre insu, il lui sut
d'^etre root sur sa station pour passer sous n'importe quel UID et exploiter ou pieger
les chiers de cet UID qui resideraient sur la partition.
Pourquoi est-il dangereux que ces devices soient en ecritures publiques ?
Tout simplement parce qu'ayant l'autorisation d'acceder au block device ou au raw
device, on peut ecrire ce que l'on veut sur le peripherique et donc creer des chevaux de
Troie ou des programmes permettant de pirater des privileges.
Pourquoi est-il dangereux que /usr/adm soit en ecriture publique ?
Tout simplement parce que quiconque peut donc ecraser les chiers qui s'y trouvent.
Ici c'est particulierement dangereux dans la mesure ou ce directory contient pas mal
de chiers d'accounting, d'audit. . .
Pourquoi est-il dangereux d'avoir un utilisateur autre que root avec l'UID 0 ?
Tout simplement parce que cela augemente le nombre de comptes strategiques a cracker
et plus il y a de ces comptes, plus grande est la chance d'en trouver le mot de passe.
Pourquoi est-il dangereux d'avoir un compte sans mot de passe ?
Tout simplement parce que l'on n'est jamais assez prudent et que m^eme des comptes
apparemment inoensifs comme celui de sync sur SunOS peuvent ^etre des trous de
securite (et d'ailleurs sync en est un ; cf hundenedi [Chemin de recherche de librairies
partagees], page hundenedi).
Pourquoi les modes mentionnes sont-ils dangereux ?
Tout simplement parce que si le chier .rhosts est en ecriture publique alors quiconque
peut s'y ajouter et donc prendre l'identite de la personne piratee.
Quant au chier .netrc, il peut contenir un mot de passe en clair si son proprietaire est
assez stupide pout utiliser ce chier ; il ne faut donc pas que ce chier soit publiquement
lisible (d'ailleurs s'il l'est, ftp ne l'utilise pas).
Pourquoi est-il dangereux que uudecode cree des chiers suid ?
Tout simplement parce que l'on peut ainsi creer a votre insu des chiers executables
qui s'executeraient avec votre UID, pouvant ainsi compromettre votre compte puis le
systeme.
Pourquoi est-il dangereux de ne pas avoir de chier /etc/ftpusers ?
Tout simplement parce que l'on accepte ainsi les connexions ftp avec pour nom d'utilisateur des noms comme root, sync donc des noms non associes a une personne physique,
incriminable en cas de probleme.
Le point 12 met en evidence que COPS ne sait pas marcher sur une machine utilisant
NIS.
Le point 13 se contente d'avertir l'administrateur que certains points du systeme de sa
machine ont fait l'objet dans le passe de problemes de securite. En aucun cas, le programme ne se prononce sur l'existence de ces trous sur CE systeme. A l'administrateur
de verier si c'est le cas en se procurant les annonces de ces problemes puis les patches
contructeurs associes.
Logiciel ISS.
248
Le logiciel ISS (Internet Security Scanner) est, comme son nom l'indique, specialise dans les
diagnostics de problemes reseau de securite. Il complete donc bien COPS et tout comme COPS, il
ne fait que signaler les problemes sans en donner le moyen d'exploitation, ni de correction.
Voici un exemple de trace d'execution de iss :
-->
Point A 7!
Point B 7!
Point C 7!
Point D 7!
[...]
129.199.115.29 tournesol.ens.fr
>
SMTP:220-tournesol.ens.fr Sendmail 8.6.8/8.6.6 ready at Tue, 6 Sep 1994 22:52:03
220 ESMTP spoken here
550 guest... User unknown
250 <[email protected]>
550 bbs... User unknown
250 <[email protected]>
550 uudecode... User unknown
500 Command unrecognized
500 Command unrecognized
221 tournesol.ens.fr closing connection
FTP:220- tttttttttt220- tttttttttt220- tttttttttt220- tttttttttt220- tttttttttt
220- This system is for the use of authorized users only. Individuals using
220- this computer system without authority, or in excess of their authority,
220- are subject to having all of their activities on this system monitored
220- and recorded by system personnel.
220220- In the course of monitoring individuals improperly using this system, or
220- in the course of system maintenance, the activities of authorized users
220- may also be monitored.
220220- Anyone using this system expressly consents to such monitoring and is
220- advised that if such monitoring reveals possible evidence of criminal
220- activity, system personnel may provide the evidence of such monitoring
220- to law enforcement officials.
220220 tournesol.ens.fr FTP server (Version wu-2.4 -- 15 Apr 1994) ready.
331 Guest login ok, send your complete e-mail address as password.
230 Guest login ok, access restrictions apply.
257 "/" is current directory.
550 test: Permission denied.
553 test: Permission denied. (Delete)
221 Goodbye.
YPSERV MOUNT BOOT RUSERS
export list for 129.199.115.29:
/
/usr
/tournesol/homes
/tournesol/data
/tournesol/local
/tournesol/export/root/droopy
/tournesol/export/swap/droopy
/tournesol/export/root/Xkernel-2.0-sun4
/tournesol/export/root/Xkernel-2.0-sun3
dan
tournesol.en:ttyp2
matthias tournesol.en:ttyp4
Sep
Sep
excalibur.ens.fr
physique
physique
physique
physique
droopy.ens.fr
droopy.ens.fr
aristote.lps.ens.fr
cubitus.lps.ens.fr,goofy.lps.ens.fr
1 23:15
6 09:07
119:36 (SEGOVIA.MIT.EDU)
2:40 (achille.ens.fr:0)
evans
evans
besancon
krauth
krauth
[...]
tournesol.en:ttyp5
tournesol.en:ttyp7
tournesol.en:ttyp9
tournesol.en:ttype
tournesol.en:ttyq0
Sep
Sep
Sep
Sep
Sep
6
6
6
2
2
10:14
10:14
19:36
11:04
11:04
249
12:38
11:27
3:15
7:08
107:48
(spirou.ens.fr:0.0)
(spirou.ens.fr:0.0)
(satie.ens.fr)
(donald.ens.fr:0.0)
(donald.ens.fr:0.0)
teste ici des noms d'utilisateurs dans le programme sendmail qui ont, par le passe,
permis d'activer des trous de sendmail ;
iss cherche ici des trous de s
ecurite dans ftp ;
iss donne ici la liste des services TCP/IP que l'on peut consid
erer comme sensibles ;
iss donne ici la liste des partitions disques export
ees ainsi que les noms des machines
pouvant les importer.
iss
Logiciel Crack.
Le logiciel crack s'attaque a un probleme que n'aborde que partiellement COPS : le degre de
securite des mots de passe.
Le principe de crack est de partir de dictionnaires sur plusieurs th^emes (prenoms feminins,
etats des USA, legendes grecques. . . ) puis de tester le resultat du chirement de ces mots avec les
mots de passe chires de vos utilisateurs ; quand deux mots de passe ont la m^eme representation
chiree alors les deux mots de passe sont identiques6. La ou crack est intelligent, c'est qu'il ne
se contente pas de tester les mots de passe des dictionnaires tels quels : il peut leur appliquer des
modications avant leur chirement comme par exemple les passer en majuscules, leur ajouter des
chires en n de mot, les inverser. . . Crack dispose d'ailleurs pour cela d'un langage de description
de transformations.
Une autre particularite de crack est de pouvoir importer une methode de chirement. Ainsi la
procedure de chirement standard sous UNIX est concue de facon a ^etre tres lente de facon a ce
que cela decourage les crackers. On peut par contre dire a crack d'en utiliser une autre beaucoup
plus rapide : ufc-crypt. Le gain de vitesse est de l'ordre 30{60 (30 pour un SUN ELC, 60 pour
un HP 9000-720) ; pour gagner en vitesse sur certaines machines, les routines de chirement sont
parfois ecrites en assembleur (cas des sun3, sun4 et HP 9000/425e).
On trouve l'integralite du package crack sur le site ftp.inria.fr ; cela comporte crack :
des dictionnaires : /system/secure/dictionaries.tar.Z et
la routine de chirement acceleree : /system/secur/ufc-3.tar.Z.
/system/secur/Crack-4.1.tar.Z,
En pratique, crack determine tres vite beaucoup de mots de passe simples. Ensuite il en decouvre
de moins en moins (cf la gure suivante) mais un seul mot de passe sut a compromettre le
systeme. . .
5
6
250
5 Juillet 1993
120
HP735
SS10/40
110
100
90
80
70
60
50
40
30
20
10
0
0 1h 3h 5h 7h 9h 11h 13h 15h 17h 19h 21h 23h 25h 27h 29h 31h 33h 35h 37h 39h
Temps coul en heures
Resultats de Crack-4.1 sur un chier de 403 mots de passe ; 100 mots furent
trouves (en 15 h sur une hp-735 et en 40 h sur un Sun Sparc10/40).
On n'oubliera pas un petit detail : ce n'est pas parce qu'un mot de passe n'est pas dechire, que
ce dernier est excellent ; il peut tres bien ne pas faire partie des dictionnaires thematiques utilises
par crack mais gurer dans un autre ou la bonne substitution de lettres peut avoir ete oubliee dans
celles testees.
En cas d'utilisation des shadow passwords, ce package est en principe inutilisable par un utilisateur lambda ; seul l'administrateur est en mesure de le faire tourner pour juger la s^urete des mots
de passe de ses utilisateurs.
251
, password aging c'est-a-dire expiration des mots de passe apres un certain delai ;
, mots de passe sur plus de huit caracteres, seize en l'occurence .
Les deux derniers points sont delicats a mettre en uvre car ils apportent des incompatibilites
avec le systeme concu par le constructeur :
, les procedures C de saisie et de traitement du mot de passe sur seize caracteres sont dierentes
des procedures standard si bien qu'il faut modier les sources de certains programmes non
fournis avec le package ; c'est le cas par exemple des programmes xdm et ftp.
, le password aging n'apporte pas, a proprement parler, d'incompatibilite avec le fonctionnement
du systeme ; c'est juste que sa mise en fonctionnement doit s'accompagner de la mise en
fonctionnement de programmes permettant a l'utilisateur de changer son mot de passe si celuici etait arrive a expiration ; le programme login fourni avec le package permet cela mais le
programme xdm ne le permet pas du tout ; il faudra donc revoir cet utilitaire et le modier.
Une fois de plus, avant d'installer ce logiciel, on re
echira donc bien a tous les aspects du systeme
qui vont ^etre bouleverses.
Ce package est disponible sous le nom /system/secur/shadow-3.3.1.tar.Z
ftp.inria.fr. Les nouvelles versions sont post
ees d'abord dans les news dans le
comp.sources.misc archiv
e par exemple sur ftp.uu.net.
sur le site
newsgroup
Complements utiles.
D'autres logiciels existent aussi mais ils sont beaucoup plus speciques, ils ne contr^olent qu'un
certain aspect du systeme. A chacun de juger de leur utilite :
252
cracklib
Comme son nom l'indique, il s'agit d'une librairie C. Elle fournit une fonction
FascistCheck() permettant de v
erier la trivialite d'un mot de passe que vient de
rentrer un utilisateur. Il sut donc d'incorporer un appel a cette fonction dans son
code C, pour donner quelque chose comme :
for (buf[0] = '\0', tries = 0;;)
{
p = getpass("New password:");
if (!*p)
{
printf("Password unchanged.\n");
pw_error(NULL, 0, 0);
}
#ifndef CRACKLIB_DICTPATH
if (strlen(p) <= 5 && (uid != 0 || ++tries < 2))
{
printf("Please enter a longer password.\n");
continue;
}
for (t = p; *t && islower(*t); ++t);
if (!*t && (uid != 0 || ++tries < 2))
{
printf("Please don't use an all-lower case password.\n");
printf("Unusual capitalization, control characters or digits are suggested.\n");
continue;
}
#else
{
char *msg;
if (msg = (char *) FascistCheck(pwbuf, CRACKLIB_DICTPATH))
{
printf("Please use a different password.\n");
printf("The one you have chosen is unsuitable because %s.\n", msg);
continue; /* go round and round until they get it right */
}
}
#endif /* CRACKLIB_DICTPATH */
strcpy(buf, p);
if (!strcmp(buf, getpass("Retype new password:")))
printf("Mismatch; try again, EOF to quit.\n");
A signaler qu'un patch est fourni avec la librairie permettant de l'incorporer dans le
package Shadow Passwds.
La librairie est disponible sous le nom /pub/security/securelib.tar.Z sur le site
ftp.win.tue.nl.
yappaswd C'est un ensemble logiciel comprenant les utilitaires passwd, chfn, chsh en version
locale et en version NIS. La version NIS des utilitaires permet de mettre a jour plus
d'un domaine NIS. Lors d'un changement de mot de passe, des verications sur sa
trivialite sont eectuees.
Le package est disponible sous le nom /pub/unix/yapasswd.tar.Z sur le site
ftp.info.win.tue.nl.
anlpasswd C'est un utilitaire permettant de faire un certain nombre de verication sur la trivialite
d'un mot de passe, lors de son changemen local. Cet utilitaire est implante en langage
PERL.
Le package est disponible sous le nom /pub/systems/anlpasswd-2.2.tar.Z sur le site
info.mcs.anl.gov.
npasswd Du m^eme genre que anlpasswd mais plus vieux.
passwd+
253
Enn, dernier point imporant : s'il arrive aux constructeurs de faire de mauvais programmes,
il leur arrive de fournir des patches corrigeant lesdits problemes. A defaut d'installer des logiciels
publics de securite, on installera au moins les patches de securite des constructeurs. La creation d'un
patch etant souvent liee a la decouverte d'un bug ayant fait l'objet d'une annonce de la part d'un
organisme type CERT (cf section 15.5 [Quelques sources d'informations], page 267), la procedure
a suivre pour se procurer le patch est tres souvent decrite dans le message de la m^eme annonce.
Sinon on pourra se reporter aux dierents sites d'informations des constructeurs (cf hundenedi
[Patches constructeurs], page hundenedi).
1
14177
15022
3
1
0
0
0
7
12
5
0
0
0
0
0
8
2
0
0
0
0
0
0
>
1
0
0
0
0
0
0
Total
24375
25059
5
2
0
0
0
254
Parce que le but de tripwire est de decouvrir des portions du systeme qui auraient ete modiees,
tripwire ne peut pas faire conance au moindre outil du systeme. Par consequent, les methodes des
signatures sont compilees dans tripwire. Dans le m^eme ordre d'idee, un preprocesseur est compile
dans tripwire, lui permettant ainsi de n'utiliser qu'un seul chier de conguration mais pour de
multiples machines (sont disponibles les macros @@ifdef, @@else, @@endif, @@ifhost, @@define,
@@undef) ; un chier de conguration peut alors ressembler
a quelque chose comme cela :
# file/dir
selection mask
/etc
R
# all files under /etc
@@ifhosts solaria.cs.purdue.edu
!/etc/lp
#except for SVR4 printer logs
@@endif
/etc/passwd
R+12
# you can't be too careful
/etc/mtab
L
# dynamic files
/etc/motd
L
/etc/utmp
L
=/var/tmp
R
# only the directory, not its content
Une fois le chier de conguration etabli pour la ou les machines voulues, une base de donnees de
signature peut ^etre etablie par tripwire -initialize puis consultee par tripwire qui decouvrira
alors les dierences et les rapportera a root :
On genere d'abord la base :
bash# cd /usr/local/tripwire
bash# bin/tripwire -initialize
### Phase 1:
Reading configuration file
### Phase 2:
Generating file list
bin/tripwire: /.exrc: No such file or directory
bin/tripwire: /.logout: No such file or directory
bin/tripwire: /.emacs: No such file or directory
bin/tripwire: /.forward: No such file or directory
bin/tripwire: /.netrc: No such file or directory
### Phase 3:
Creating file information database
###
### Warning:
Database file placed in ./databases/tw.db_excalibur.ens.fr.
###
###
Make sure to move this file file and the configuration
###
to secure media!
###
###
(Tripwire expects to find it in '/users/stat7/tripwire/databases'.)
###
### Total files scanned: 5211
###
Files added: 0
###
Files deleted: 1
###
Files changed: 4609
###
### After applying rules:
###
Changes discarded: 4603
###
Changes remaining: 8
###
deleted: lrwxrwxrwx root
255
/etc/mtab
st_ino: 119
117
/usr/lib
st_mtime: Wed Sep 21 14:19:31 1994
st_ctime: Wed Sep 21 14:19:31 1994
Les modications signalees en n de rapport sont normales et s'expliquent par l'emploi d'un automounter qui modie donc le chier /etc/mtab et donc /etc.
Bien s^ur, tripwire permet de faire des mises a niveau de sa base (ce qui peut se reveler utile
apres installation de nouveaux logiciels ou de patches systeme).
En resume, le principe de tripwire est donc :
generate
newly
generated
database
compare
tw.config
file
old
database
apply
ignoremasks
Tripwire report
256
Le principe reposant sur des comparaisons astucieuses par rapport a des elements de reference,
fait que l'emploi de ce logiciel est un peu delicat : dans l'absolu, il faudrait garantir la non modication des elements de reference, le mieux en ce domaine etant de stocker ces elements sur des
supports non modiables ; le probleme est que peu de disques durs permettent maintenant de les
passer materiellement en mode read-only ; la solution la plus acceptable est donc actuellement de
conserver les elements de reference sur support magneto-optique amovible, ce qui est relativement
co^uteux si le drive magneto-optique est reserve a cette utilisation.
[...]
*.emerg;
*.alert;
*.crit;
*.err;
*.warning;
*.notice;
cron,mail.none;
cron,mail.none;
cron,mail.none;
cron,mail.none;
cron,mail.none;
cron,mail.none;
/var/adm/logs/syslog-level-0-emerg
/var/adm/logs/syslog-level-1-alert
/var/adm/logs/syslog-level-2-crit
/var/adm/logs/syslog-level-3-err
/var/adm/logs/syslog-level-4-warning
/var/adm/logs/syslog-level-5-notice
*.emerg;
*.alert;
*.crit;
cron,mail.none;
cron,mail.none;
cron,mail.none;
besancon
besancon
besancon
*.emerg;
*.alert;
*.crit;
*.err;
*.warning;
cron,mail.none;
cron,mail.none;
cron,mail.none;
cron,mail.none;
cron,mail.none;
@excalibur.ens.fr
@excalibur.ens.fr
@excalibur.ens.fr
@excalibur.ens.fr
@excalibur.ens.fr
Il est a noter que la syntaxe de ce chier varie sur certains systemes : c'est le cas pour DEC
ULTRIX 4.x, IRIX 4.0.5 et 5.2.
*.notice;
*.info;
[...]
cron,mail.none;
cron,mail.none;
257
@excalibur.ens.fr
@excalibur.ens.fr
La version DEC OSF1 de syslog contient une fonctionnalite interessante : le changement quotidien du directory de stockage des chiers de log ce qui permet de limiter la taille des chiers de
log. Si, par exemple, le chier /etc/syslog.conf contient :
kern.debug
user.debug
mail.debug
daemon.debug
auth.debug
syslog.debug
lpr.debug
/var/adm/syslog.dated/kern.log
/var/adm/syslog.dated/user.log
/var/adm/syslog.dated/mail.log
/var/adm/syslog.dated/daemon.log
/var/adm/syslog.dated/auth.log
/var/adm/syslog.dated/syslog.log
/var/adm/syslog.dated/lpr.log
alors les logs seront ainsi stockes dans des chiers aux noms :
/var/adm/syslog.dated/13-Sep-11:57/*.log
/var/adm/syslog.dated/14-Sep-11:57/*.log
/var/adm/syslog.dated/15-Sep-11:58/*.log
...
# following line for compatibility with old sendmails. they will send
# messages with no facility code, which will be turned into "user" messages
# by the local syslog daemon. only the "loghost" machine needs the following
# line, to cause these old sendmail log messages to be logged in the
# mail syslog file.
#
ifdef(`LOGHOST',
user.alert
/var/log/syslog
)
#
# non-loghost machines will use the following lines to cause "user"
# log messages to be logged locally.
#
ifdef(`LOGHOST', ,
user.err
/dev/console
user.err
/var/adm/messages
user.alert
`root, operator'
user.emerg
*
)
258
[...]
Logiciel swatch.
L'utilitaire syslog n'ore que des possibilites de conguration sommaires (mais c'est cependant
mieux que rien) : on ne peut guere que selectionner une classe de messages et agir sur son achage.
Or on trouve des messages qui vont d'une simple information futile a une indication de panne
grave, au sein d'une m^eme classe ; on aimerait pouvoir trier les messages d'une m^eme classe. De
m^eme, on peut supposer que l'arrivee d'un certain message indique qu'un systeme est entre dans
une condition critique d'utilisation ; si l'administrateur loupe ce message ou ne le voit que quelques
heures plus tard, cela pourrait ^etre catastrophique ; on aimerait donc avoir la possibilite de lancer
une certaine action en cas d'arrivee d'un certain message de log. Bien s^ur, il en est de m^eme pour
les chiers de log propres a certains autres demons.
L'utilitaire swatch (System Watcher) repond a ces besoins en permettant de selectionner des
messages gr^ace a des expressions regulieres et de leur appliquer dierents traitements comme l'achage en mode normal, gras, souligne, clignotant, video inverse, le lancement de commandes, l'envoi
de mail. . . swatch peut fonctionner en direct sur un chier dans lequel les demons ecrivent au fur
et a mesure (swatch -t <logfile>) ou apres coup sur un chier complet (swatch -f <logfile>).
Voici un exemple de chier de conguration de swatch :
[...]
# Test the pager every once in a while
/test pager/
exec="/usr/local/etc/call_pager 5551212 123"
# These may not be so harmless
/su: .* failed/
echo,bell=3
/[dD]enied/||/DENIED/
echo=bold,bell
# Alert me of bad login attempts and find out who is on that system
/INVALID|REPEATED|INCOMPLETE/
echo=underline,bell=3
# Ignore this stuff
/sendmail/,/nntp/,/xntp|ntpd/
# Kernel problems
/reboot/
/(panic|halt|SunOS Release)/
/file system full/
[...]
ignore
mail=action
echo=blink,bell
echo=bold,bell=3
sous le nom
3:00
5:00
0:16
0:16
/pub/sources/swatch-2.1.tar.gz
sur le site
Logiciel trimlog.
L'utilitaire trimlog essaye de resoudre un probleme commun a tous les chiers de log : leur
augmentation de taille. Il peut ainsi s'appliquer au cas de syslog.
Le logiciel trimlog a ete concu pour ^etre lance periodiquement et gr^ace a son chier de conguration trimlog.conf, il permet de manipuler les chiers de log des facons suivantes :
truncate file N
259
trimbylines file N
trimbybytes file N
Troncature du chier a N bytes maximum, avec recopie des N derniers bytes en debut
de chiers ;
/pub/davy/trimlog.tar.Z.
trimlog
1
750
1
sur le site
harbor.ecn.purdue.edu
sous le nom
, des possibilites d'analyse de l'origine de la requ^ete reseau puis son ltrage selon des regles
choisies par l'administrateur ; la requ^ete est alors autorisee ou refusee ;
260
, des informations sur ce qui est en train de se passer ; les traces laissees utilisent en general
le systeme syslog et utilisent assez bien les dierents niveaux d'importance de l'evenement
qu'ore syslog.
C^ote serveur
telnet
in.telnetd
finger
in.fingerd
rlogin
in.rlogind
talk
in.talkd
:::
:::
Le lancement du c^ote serveur peut ^etre assure par le demon inetd. Une requ^ete arrivant sur un
des ports donnes dans /etc/services sur lequel inetd est en ecoute, inetd determine alors selon
son chier /etc/inetd.conf quel demon lancer. La securisation est ici facile a integrer : il sut de
placer un demon intermediaire de plus, entre inetd et le lancement du demon requeri.
machine A
machine B
machine A
machine B
fork()
client
inetd
client
reseau
inetd
reseau
machine A
machine B
fork()
client
inetd
serveur
reseau
serveur
261
machine B
machine A
machine B
fork()
client
inetd
client
inetd
reseau
machine A
tcpd
reseau
machine A
machine B
machine B
fork()
fork()
client
inetd
client
tcpd
inetd
tcpd
serveur
reseau
reseau
machine A
machine B
fork()
client
inetd
tcpd
serveur
reseau
[...]
telnet
shell
login
exec
talk
[...]
stream
stream
stream
stream
dgram
tcp
tcp
tcp
tcp
udp
nowait
nowait
nowait
nowait
wait
root
root
root
root
root
/usr/etc/in.telnetd
/usr/etc/in.rshd
/usr/etc/in.rlogind
/usr/etc/in.rexecd
/usr/etc/in.talkd
in.telnetd
in.rshd
in.rlogind
in.rexecd
in.talkd
stream
stream
stream
stream
dgram
tcp
tcp
tcp
tcp
udp
nowait
nowait
nowait
nowait
wait
root
root
root
root
root
/usr/etc/tcpd
/usr/etc/tcpd
/usr/etc/tcpd
/usr/etc/tcpd
/usr/etc/tcpd
in.telnetd
in.rshd
in.rlogind
in.rexecd
in.talkd
Moyennant cela, on obtient par syslog davantage de renseignements que sans le package :
Sep 12 11:12:18 droopy in.rlogind[4296]: connect from merlin.ens.fr
Sep 12 11:17:13 tournesol in.fingerd[10565]: connect from dmi.ens.fr
Sep 12 11:30:51 tournesol in.telnetd[10630]: connect from surete.roma1.infn.it
262
On recupere ainsi des indications sur l'origine de le requ^ete de lancement du demon. C'est le
mode de fonctionnement par defaut. Il existe un mode avance de fonctionnement dans lequel on
peut donner des regles de ltrage sur l'origine des requ^etes reseau et ainsi les invalider ou les
autoriser. Pour cela, il sut de congurer deux chiers /etc/hosts.allow et /etc/hosts.deny
(paths modiables a la compilation du package) ; par exemple :
% cat /etc/hosts.allow
ALL : 129.199. 129.104.3.
% cat
ALL :
ALL :
ALL :
/etc/hosts.deny
UNKNOWN
.epita.fr
163.5.
Le demon tcpd verie d'abord si la requ^ete provient d'une machine citee dans /etc/hosts.allow
auquel cas elle est autorisee, sinon tcpd passe en revue /etc/hosts.deny pour refuser la requ^ete
si elle provient d'une machine qui y est citee ; nalement la requ^ete est acceptee si elle passe a
travers ces deux chiers. On peut distinguer les dierents demons (en les enumerant) ou les designer
globalement (par ALL comme ci-dessus). Pour plus de details, se rapporter aux pages de manuel
venant avec le package.
Il existe un package complementaire des TCP wrappers qui permet d'aner les renseignements
sur l'origine de la requ^ete en donnant le nom de l'utilisateur a l'origine de la requ^ete. Le logiciel
utilise pour cela le protocole IDENT decrit dans le RFC 931 mais n'importe quel cracker arrivera
a contourner ce protocole. Son fonctionnement est en eet le suivant : sur reception d'une requ^ete
emanant de la machine A, le demon tcpd de la machine B envoit une requ^ete d'identication sur
le port TCP 113 (associe au protocole IDENT) sur la machine A. Si un demon implantant le RFC
931 y est installe, celui-ci repond par le nom de l'utilisateur emetteur de la requ^ete sur B ; s'il n'y a
pas de demon, l'information n'est pas disponible ; si un faux demon tourne, l'information renvoyee
peut ^etre fausse. Le probleme est donc qu'il faut faire conance a l'information retournee que l'on
ne ma^trise pas. Si un demon RFC 931 tourne sur une machine, les demandes de connexion issues
de cette machine seront loggees ainsi par tcpd :
Sep 12 12:54:00 tournesol in.fingerd[11111]: connect from [email protected]
Sep 12 13:32:53 falbala rlogind[26863]: connect from [email protected]
Le package pident-2.3 implante le protocole RFC 931 sur un certain nombre de plateformes UNIX. Il est disponible sous le nom /pub/ident/servers/pident-2.3.tar.gz sur le site
ftp.lysator.liu.se.
Le package daemon-1.00 implante, entre autres, le protocole RFC 931 pour un Macintosh mais,
de par la nature ouverte du Macintosh ou l'on ne peut pas faire de dierence entre l'utilisateur et un
quelconque administrateur, cela presentera moins d'inter^et
puisque le nom de l'utilisateur renvoye peut ^etre change a
volonte : ainsi, si l'on change le champ Possesseur de l'accessoire de tableau de bord Reglage partage de fichiers
(comme il est montre dans la fen^etre ci a c^ote), les traces
de log deviennent :
Sep 13 00:14:51 excalibur in.telnetd[6125]: connect from [email protected]
mac.archive.umich.edu.
263
Le package TCP Wrappers a permis de montrer comment on peut contr^oler certains services
UNIX sans modier profondement le systeme. Il faut signaler que des mecanismes semblables a
celui des TCP Wrappers peuvent exister dans le systeme ; c'est ainsi le cas avec HP-UX et son
chier /usr/adm/inetd.sec donc voici un exemple :
# @(#)$Header: inetd.sec,v 1.8.109.2 92/03/09 10:24:37 thchen Exp $
#
# The lines in the file contain a service name, permission field and
# the Internet addresses or names of the hosts and/or networks
# allowed to use that service in the local machine.
# The form for each entry in this file is:
#
# <service name>
<allow/deny> <host/network addresses, host/network names>
#
# For example:
#
# login
allow
10.3-5 192.34.56.5 ahost anetwork
#
# The above entry allows the following hosts to attempt to access your system
# using rlogin:
#
hosts in subnets 3 through 5 in network 10,
#
the host with Internet Address of 192.34.56.5,
#
the host by the name of "ahost",
#
all the hosts in the network "anetwork"
#
# mountd
deny
192.23.4.3
#
# The mountd entry denies host 192.23.4.3 access to the NFS rpc.mountd
# server.
#
# Hosts and network names must be official names, not aliases.
# See the inetd.sec(4) manual page for more information.
spc
allow
127.0.0.1 unknown thorgal
mserve allow
127.0.0.1 unknown thorgal
On regardera donc qui, des TCP Wrappers et du systeme constructeur, fournit le meilleur contr^ole.
Des regles de ltrage peuvent exister egalement au niveau des demons a activer. Dans ce cas,
il est inutile de mettre le lancement de ces demons sous le sontr^ole des TCP Wrappers. C'est le
cas, par exemple, pour une implantation du demon ftp, dit demon wuftpd (parce que developpe
a l'Universite de Washington). Ce demon est congurable via le chier ftpaccess (dont l'emplacement est precisable a la compilation) et permet de limiter le nombre de connexions simultanees
ainsi que d'enregistrer et de ltrer les connexions sur les criteres suivants :
[<enforce|warn>]
264
deny
deny
deny
deny
*.epita.fr
163.5.*.*
192.48.98.*
!nameserved
limit
limit
[...]
remote
anon
8
8
/usr/local/ftpd/etc/msg.deny@epita
/usr/local/ftpd/etc/msg.deny@epita
/usr/local/ftpd/etc/msg.deny@X
/usr/local/ftpd/etc/msg.deny-dns
Any /usr/local/ftpd/etc/msg.toomany
Any /usr/local/ftpd/etc/msg.toomany
ftp.inria.fr.
/network/ftp/wu-ftpd-2.4.tar.Z
sur le site
Enn, pour terminer, signalons l'existence d'une autre implantation de inetd. Cetta implantation realise la m^eme t^ache que inetd (lancer les demons c^ote serveur) tout en fournissant les
fonctionnalites des TCP Wrappers. On peut ainsi faire du contr^ole d'acces a certains services.
Contrairement aux TCP Wrappers, on peut imposer des contraintes de plages horaires pour le
lancement des demons. Il s'agit du programme xinetd, disponible sur le site ftp.irisa.fr sous le
nom /pub/mirrors/xinetd/xinetd.2.1.4.tar.gz. Le programme fonctionne gr^ace a un chier
de conguration /etc/xinetd.conf, lui dictant le comportement a tenir ; xinetd se rend compte
tout seul des modications apportees a ce chier dont voici un exemple :
[...]
service ident
{
socket type
protocol
wait
user
server
server args
}
service telnet
{
socket type
protocol
wait
user
server
}
service talk
{
socket type
protocol
wait
user
server
}
service walld
{
type
rpc version
socket type
protocol
wait
user
server
}
[...]
=
=
=
=
=
=
stream
tcp
yes
root
/usr/etc/in.identd
-w -t300
=
=
=
=
=
stream
tcp
no
root
/usr/etc/in.telnetd
=
=
=
=
=
dgram
udp
yes
root
/usr/etc/in.talkd
=
=
=
=
=
=
=
RPC
1
dgram
udp
yes
root
/usr/etc/rpc.rwalld
265
/etc/inetd.conf
Autres demons.
Le package TCP Wrappers montre comment on peut augmenter la securite du systeme sans
modier profondement celui-ci ; on a garde les demons systeme du constructeur et on a simplement
intercale un demon de plus. Les autres packages qui vont ^etre decrits, sont par contre dierents :
ils consistent a remplacer un certain nombre de demons par d'autres fonctionnellement equivalents
mais plus s^urs et prevus pour augmenter le degre de securite. Pourquoi ne peut-on pas proceder
avec ces demons de m^eme que precedemment ? Pour deux raisons principalement :
1. Ces demons tournent en permanence sur la station et ne sont pas lances par inetd ; par
exemple, c'est le cas de portmap (ou rpcbind en System V) ;
2. Ces demons ne sont des demons a part entiere mais en fait des procedures RPC.
Pour corriger cela, on va donc proceder de deux facons :
Methode 1
Methode 2
}
[...]
adresse-de-r
eseau-autoris
ee
128.199.0.0
mask-pour-l'adresse
0.0.255.255
266
Du fait qu'il s'agit d'appels systeme, on comprend bien que pour ^etre utiles, ces nouvelles versions doivent ^etre introduites dans une librairie partagee. Par consequent,
ce package n'a d'inter^et que sur des systemes permettant la reconstruction de la librairie C dynamique ; c'est pourquoi le package ne fonctionne que sous SunOS 4.1.x
actuellement.
Dans la mesure ou l'execution de _ok_address() est assez long, on peut ne pas vouloir
appliquer ces nouveaux appels systemes a tous les demons reseau. Du coup, on n'installera pas cette nouvelle librairie dynamique a la place de celle du systeme. On passera
par un utilitaire permettant de positionner LD_LIBRARY_PATH.
Si l'on utilise xinetd, on pourra lancer un demon de la facon suivante :
service rstatd
{
type
socket_type
protocol
server
wait
user
rpc_version
env
}
=
=
=
=
=
=
=
=
RPC
dgram
udp
/usr/etc/rpc.rstatd
yes
root
2-4
LD_LIBRARY_PATH=/etc/securelib
portmap 3, rpcbind
Certains des problemes corriges par portmap_3 l'ont ete par des patches constructeurs
ou ont deja fait l'objet d'autres logiciels du domaine public :
, la version de portmap contenue dans le patch SunOS 100482-02 doit combler les
m^emes problemes concernant le vol de certaines maps ;
267
Toutes les machines dont l'adresse est dans le sous reseau 129.199.115 ont donc l'autorisation
d'interroger le demon ypserv.
,
,
,
,
,
routeurs ;
ponts ltrants ;
machines dediees ;
analyseurs de reseau ;
logiciels et systemes securises ;
268
Parmi cet ensemble de choses indispensables, il faut signaler ce que l'on appelle les machines
garde barrieres, les rewalls en anglais. Il s'agit de machines isolant un reseau de stations de
l'exterieur mais permettant malgre tout d'assurer un certain nombre de services, et cela en en
contr^olant l'execution. L'installation de rewalls est une aaire de professionnels de la securite et la
description de leur fonctionnement depasse le cadre de ce manuel. Pour plus de renseignements, on
se reportera au livre Firewalls and Internet Security de William R. Cheswick et Steven M. Bellovin,
a la mailing-list rewalls. . .
ftp.urec.fr
ftp.univ-lyon1.fr
269
15.7 Bibliographie.
Le lecteur pourra se reporter aux ouvrages suivants:
[Arc93a] Jean-Luc Archimbaud. Documents sur la securite des systemes et des reseaux disponibles
en ligne. Le Micro Bulletin, le journal des usagers de l'informatique dans la Recherche,
1993.
[Arc93b] Jean-Luc Archimbaud. Etude sur la securite des systemes d'information dans les laboratoires du CNRS. Le Micro Bulletin, le journal des usagers de l'informatique dans la
Recherche, 1993.
[Bel89] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. Technical report,
AT&T Bell Laboratories, 1989,
URL ftp://ftp.research.att.com/dist/internet_security/ipext.ps.Z
[Bel92] Steven M. Bellovin. There Be Dragons. Technical report, A&T Bell Laboratories, 1992,
URL ftp://ftp.research.att.com/dist/internet_security/dragon.ps
[Che92] Bill Cheswick. An Evening with Berferd In Which a Cracker is Lured, Endured, and
Studied. Technical report, AT&T Bell Laboratories, 1992,
URL ftp://ftp.research.att.com/dist/internet_security/berferd.ps
[MWE89] Jon A. Rochlis Mark W. Eichin. With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988. Technical report, Massachusetts Institute of Technology,
1989.
[Spa88] Eugene H. Spaord. The Internet Worm Program: An Analysis. Technical report,
Department of Computer Sciences Purdue Univerity, 1988,
URL ftp://ftp.cs.purdue.edu/pub/reports/TR823.PS.Z
[Spa91] Eugene H. Spaord. The Internet Worm Incident. Technical report, Department of
Computer Sciences Purdue Univerity, 1991,
URL ftp://ftp.cs.purdue.edu/pub/reports/TR933.PS.Z
[Sto89] Cli Stoll. THe Cuckoo's egg: Tracking A Spy Through The Maze of a Computer Espionage. DoubleDay, New York, 1989.
[WRC94] Steven M. Bellovin William R. Cheswick. Firewalls and Internet Security. AddisonWesley, 1994.
270
271
16 Librairies dynamiques.
Les librairies dynamiques sont un mecanisme qui existent maintenant depuis plusieurs annees
sur des UNIX a nature commerciale ; par exemple cela existait deja sur SunOS 4.0. Le nombre de
systemes orant cette fonctionnalite ne cesse de cro^tre : AIX versions 3.2.x et 4.1.x, DEC OSF1,
HP-UX versions 9.0x et 10.01, IRIX 5.2, Linux, NetBSD, FreeBSD, SunOS 4.1.x, Solaris 2.x . . .
, Les librairies partagees concernent surtout des fonctions systeme. Le code de ces fonctions
n'etant plus inclus dans les executables, il est facile de proceder a leurs mises a niveau sans
avoir besoin de recompiler les executables qui les utiliseraient. Pourquoi proceder a une mise
a niveau ?
Pour corriger des bugs de certaines fonctions :
Par exemple, le patch SunOS 101558-02 corrige (entre autres) le bug 1022654 en
permettant a exportent() de lire des lignes de taille maximale 4096 caracteres.
Pour apporter de nouvelles fonctionnalites :
Par exemple, en appliquant le patch PHCO_4380 a un systeme HP-UX 9.0x qui fournit une nouvelle librairie C dynamique (/lib/libc.sl), on ajoute un mecanisme
permettant de choisir l'ordre de resolution des noms de machine (cf section 11.7.5
[Mecanisme de resolution de noms sur HP-UX], page 167).
Pour modier le comportement de certains programmes :
Pour deplacer une licence xe d'une application compilee en dynamique sur SunOS (et protegee par gethostid()), il sut de reconstruire la librairie C avec le
nouveau module gethostid.c :
#include <stdlib.h>
#include <sys/syscall.h>
int
gethostid()
{
/* Pour le logiciel XXXXX qui ne peut tourner que sur 'grincheux'. */
if ( getenv("GRINCHEUX_HOSTID") != (char*)0 )
return 0x54006749;
else
return( syscall(SYS_gethostid));
}
272
hid d'URL
ftp://ftp.netcom.com/pub/he/henderso/change-sun-hostid-1.6.0.tar.gz
,
,
,
,
273
/usr/lib/ld.so | egrep LD
LD_LIBRARY_PATH
LD_TRACE_LOADED_OBJECTS
LD_PROFILE
LD_PRELOAD
LD_SYMBOLS_PUBLIC
LD_
274
On voit donc qu'il existe certaines variables d'environnement pouvant modier le fonctionnnement du linker dynamique (/usr/lib/ld.so). Voici la signication de chaque variable :
LD_LIBRARY_PATH
LD_PRELOAD
LD_TRACE_LOADED_OBJECTS
LD_PROFILE
It is used if the system is being compiled for proling (-DPROF dened | it isn't dened
in the Makefile).
LD_SYMBOLS_PUBLIC
Vous vous retrouvez alors comme etant l'utilisateur sync et faisant partie d'un groupe
(daemon) auquel vous n'apparteniez pas avant. Ce trou existe en SunOS 4.1.0 mais a ete
corrige sur les versions suivantes.
, vous obtenez quelque chose comme :
$ su sync
ld.so: open error 13 for
hpath du diri/foo
ce qui veut dire que le trou de securite est corrige sur votre version de SunOS.
Plus recemment (novembre 1995), un probleme a ete decouvert dans le demon telnetd de
Solaris 2.5 b^eta, NetBSD 1.0 et FreeBSD 2.1. Le probleme est que cette version de telnetd permet
le passage de variables d'environnement (les versions prealables ne permettaient le passage que de
la variable TERM). Voici un exemple qui montre un telnetd qui n'est pas vulnerable :
275
% telnet
telnet> env define LD_PRELOAD /no-such-file
telnet> env export LD_PRELOAD
telnet> open host
Trying A.B.C.D...
Connected to host.
Escape character is '^]'.
Voici un autre temoignage (fevrier 1994), de Wietse Venema ([email protected]), demontrant les cas ou ces variables d'environnement peuvent poser problemes :
LD_xxx variables are ignored only when the eective and real user (or group) ids dier.
Now, consider what happens when the program makes its eective and real uids (gids)
equal, and then executes another program. That other program is no longer protected
against bad LD_xxx data. Programs that fell into this hole are login, su, sendmail,
and numerous others.
SunOS 4.1.x
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.unix.internals.02662
cf :
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.sys.sun.apps.04707
Il faut noter que sur le systeme HP-UX 9.0x, il faut que les librairies partagees aient pour droits
d'acces 555 :
Newsgroup: comp.sys.hp.hpux
From: [email protected] (Ken Green)
Subject: shared library performance problems
Date: Wed, 4 Oct 1995 09:01:35 GMT
> My app makes extensive use of shared libraries. Unfortunately my app run signicantly slower using
shared libraries that when it is statically linked. Why is this happening? Is there something that I'm
overlooking?
276
Make sure that you have the permissions 555 on the shared libaries, otherwise you run
into problems with CPU protection traps.
Each area of memory you attack to gets given a protection ID, so that access to it
can be controlled. The CPU has 4 registers to hold these prot id's. Every time you
access any memory the TLB ( part of the CPU ) compares the prot id against these
4 registers. If it doesn't match then an interupt is called, this then works out whether
the prot id your after is valid for your process, if so it reloads one of the 4 registers and
returns.
This software routine takes time.
Now, if you set the perms 555, then every process attaching to the shared library would
have the same access rights so the prot id's aren't needed. So there set to 0, when the
TLB nds that the prot id on a page is 0 is doesn't check it against your 4 controll
registers.
This can also occur with shared memory segments, and shared memory mapped les.
The text region of the process uses 1 of the control registers. All the private areas
(data/stack/uarea/pmmf/ data for shared libs etc.) use another, so theres realy only 2
left to go around.
The following noddy code1 segment demos the problem.
???
???
???
???
Activation
/sbin/ldconfig
depuis /etc/rc
/sbin/ldconfig
depuis /etc/rc.d/rc.M
???
???
???
/sbin/ldconfig
/usr/etc/ldconfig
???
depuis /etc/rc.local
Le programme de demonstration est disponible dans le texte original de l'article dont l'URL est
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.sys.hp.hpux.32983
277
AIX 4.1.x
DEC OSF1 3.0
DEC ULTRIX 4.x
FreeBSD 2.1
HP-UX 9.0x
HP-UX 10.01
IRIX 4.0.5
IRIX 5.2
Linux
NetBSD 1.0
SunOS 4.0.3
Reconstruction possible ?
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.unix.aix.48333
non documente
non documente
non documente
oui a partir des sources du systeme disponibles
non documente
non documente
non documente
non documente
oui a partir des sources du systeme disponibles
oui a partir des sources du systeme disponibles
oui a partir de :
ftp://ftp.uu.net/systems/sun/sun-fixes/libc-pic.a.sun3.Z
ftp://ftp.uu.net/systems/sun/sun-fixes/libc-pic.a.sun4.Z
SunOS 4.1.x
Solaris 2.x
(0)
(1)
278
if(link(nodns[OLD],nodns[NEW]))
{
perror("link");
exit(1);
}
if(unlink(nodns[OLD]))
{
perror("unlink");
exit(1);
}
if(link(hasdns[OLD],hasdns[NEW]))
{
perror("link");
exit(1);
}
if(unlink(hasdns[OLD]))
{
perror("unlink");
exit(1);
}
exit(0);
Commande
/bin/dump -H hlenamei
/bin/odump -Dls hlenamei
/usr/bin/ldd hlenamei
/usr/bin/chatr hlenamei
/bin/elfdump -Dl hlenamei
/bin/odump -Dls hlenamei
/usr/bin/ldd hlenamei
/usr/bin/ldd hlenamei
/bin/ldd hlenamei
/usr/bin/ldd hlenamei
,
,
,
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.sys.hp.hpux.01841
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.sys.hp.hpux.06233
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.unix.internals.03678
279
I have created a libraray (of C functions) say libx.a. I then write a program and link it with
this library libx.a. After I run this program once, I can not do a cp of another library over
this libx.a. Even after the program has exited (and I tried to wait for upto 3 hrs), I get this
message:
>
16.4 Bibliographie.
Le lecteur se reportera a :
[Aus90]
M.A. Auslander. Managing programs and libraries in AIX Version3 for RISC System/6000 processors. IBM Journal of Research and Development, 34(1):98{104, janvier
1990.
[RMXM87] Robert A. Gingell, Meng Lee, Xuong T. Dang, and Mary S. Weeks. Shared Libraries
in SunOS. Technical report, Sun Microsystems, Inc., 1987,
URL
ftp://ftp.sage.usenix.org/pub/usenix/summer87/sunos-shared-libs.ps.Z
280
281
, le courrier UUCP, l'une des plus anciennes methodes d'echange de courriers electroniques entre
machines UNIX;
, le courrier BITNET du reseau BITNET (Because it's time to network), un reseau reliant des
mainframes IBM, en cours de disparition actuellement ;
, le courrier X400, qui est le courrier electronique vu selon les normes ISO ;
, le courrier SMTP qui est le protocole utilise de-facto sur la plupart des systemes modernes
connectes a l'Internet en permanence. Pour les sites n'ayant pas une pleine connectivite, UUCP
reste le must cependant.
Voici une carte montrant l'utilisation de ces services :
INTERNATIONAL CONNECTIVITY
Version 14 - 6/15/95
Internet
Bitnet but not Internet
EMail Only (UUCP, FidoNet)
No Connectivity
This map may be obtained via anonymous ftp
from ftp.cs.wisc.edu, connectivity_table directory
Copyright 1995
Larry Landweber
and the Internet Society.
Unlimited permission to
copy or use is hereby granted
subject to inclusion of
this copyright notice.
282
Reseau
Destinataire du
courrier non local
Transmission au
facteur local
Distribution personnalisee
Bo^te
aux lettres
Consultation des
courriers
MDA
Emission d'un
courrier
MUA
283
sendmail
Reseau 7! MTA
MTA 7! Reseau
La plupart des machines utilisant le protocole IP, les communications entre MTAs se
font simplement en ecoutant sur un well known port, en general le port smtp decrit
dans /etc/services :
smtp
25/tcp
Une fois connecte a ce port, les MTAs s'echangent les donnees via le protocole SMTP
(dans le cas de sendmail), protocole decrit a l'origine dans le RFC 821 et amende
souvent pour ajout d'extensions.
MTA 7! MDA
Le MDA appele par le MTA est en general precise dans le chier de conguration du
MTA.
Dans le cas de sendmail, cela donne quelque chose comme :
Mlocal, P=/bin/mail, F=MFlusr, S=10, R=12, A=mail -d $u
MUA 7! MTA
Il existe plusieurs MUAs mais, pour pouvoir communiquer avec plusieurs MTAs aussi,
ils suivent tous la m^eme methode equivalente a :
cat message | MTA
ou message est le courrier a envoyer que l'on aura compose gr^ace au MUA.
Le choix du MTA peut ^etre precise au niveau du chier de conguration du MUA. Par
exemple, pour le MUA Mail, au niveau de $HOME/.mailrc, on peut mettre la chose
suivante pour avoir un apercu (tres verbeux) de tout ce qui se passe :
set sendmail="/usr/lib/sendmail -vi -d21.2 -d1.5 -d10 -d11 -d13 -d20.1 -d30 -d28.1 -d28.4"
284
d'adresses, c'est parce que les protocoles ont evolue au cours du temps et parce que des reseaux
avec des protocoles dierents se sont retrouves connectes a l'Internet, apportant donc avec eux leurs
protocoles auxquels les MTAs ont d^u apprendre a parler.
Voici les types d'adresses que l'on risque de rencontrer en pratique :
Adresse Internet globales
Certaines adresses sont qualiees de globales parce qu'elles specient un site sans specier de chemin pour y arriver. En cela, elles sont valides en tout point de l'Internet.
jean @ jussieu.fr
C'est l'adresse la plus simple. Il peut y avoir des espaces entre les dierents
composants de l'adresse.
Cette adresse specie que le courrier doit ^etre envoye a ibp.fr qui doit faire suivre a
qui envoie nalement le courrier a [email protected].
Les adresses avec routage explicite sont fortement deconseillees. Le probleme est que
beaucoup de sites ne les reconnaissent pas correctement et, par consequent, elles ne
peuvent pas ^etre utilisees en conance. Le RFC 1123, sans les interdire, deconseille
formellement leur utilisation : on ne devrait pas les utiliser mais on doit les reconna^tre
et les accepter.
Adresse Internet litterales
C'est une adresse du type jean@[134.157.0.129]. La presence des crochets indique
une adresse numerique qui doit ^etre prise telle quelle. Le courrier doit donc ^etre envoye
a la machine d'adresse indiquee sans autre forme de traitement (en particulier sans
tenir compte des informations de type MX que le DNS indiquerait).
Il est deconseille (mais si pratique) d'utiliser ces adresses.
uvsq.fr
285
286
il doit ^etre capable d'interagir avec d'autres MTAs. . . Il existe plusieurs MTAs, chacun ayant un
degre de complexite dierent, chacun plut^ot lie a un systeme :
smail
mmdf
sendmail
URL ftp://ftp.uu.net//networking/mail/smail/smail-3.1.29.1.tar.gz
Un newsgroup lui est consacre : comp.mail.smail.
On trouvera un tutorial intitule Easy E-Mail de Felix GAEHTGENS, dans le numero
de Mars 1994 du magazine UnixWorld's Open Computing (volume 11, numero 3).
URL ftp://ftp.uu.net//networking/mail/mmdf/*
On le trouve sur le systeme SCO.
URL ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/sendmail.8.7.5.base.tar.Z
C'est le MTA que l'on trouve sur les systemes AIX, OSF1, ULTRIX, HP-UX, IRIX,
SunOS, Solaris. . .
Un newsgroup lui est consacre : comp.mail.sendmail.
, Sa disponibilite sur des systemes "grand public" en a fait un sujet qui fait couler beaucoup
d'encre et beaucoup de lignes de code ; c'est sans doute le MTA a propos duquel on discute le
plus.
, Il est disponible en version source.
, Il en existe deux grandes versions, la version 5 modiee selon IDA et la version 8, qui susent
a faire tout ce que l'on veut, la version 8 apportant notamment une tres notable simplication
(via l'utilisation du langage m4) dans ce cauchemard des ingenieurs systeme qu'etait l'ecriture
du chier de conguration de sendmail.
, Il existe un bon ouvrage du commerce sur ce MTA, ainsi que de nombreux documents techniques le decrivant.
Donner des explications sur toutes les arcanes de sendmail depasse le cadre de cet ouvrage, d'autant
plus que cela a deja ete fait (cf bibliographie). Expliquer egalement comment realiser tout type de
conguration est aussi en dehors du but de ce manuel. La seule chose que l'on peut dire en ce
domaine est que la complexite naturelle de sendmail est surfaite et que, si complexite il y a
dans sa conguration, c'est uniquement parce que la situation du site pour lequel on l'installe est
compliquee voire trop compliquee.
La section suivante s'attachera a decrire quelques points importants a conna^tre sur sendmail
et sur sa version 8.
, Initialisation de variables.
, Denition de macros.
287
, Denition de procedures que l'on appelle des ensembles de regles. Une regle prend des donnees
en entree, regarde si ces donnees sont b^aties sur un certain modele et leur applique un traitement
dans le cas positif.
, Si la partie droite de la regle commence par $:, alors apres reecriture, on passe a la regle
suivante.
, Si la partie droite de la regle commence par $@, alors apres reecriture, on quitte l'ensemble de
regles actuel. On a ni la procedure.
, Si la partie droite de la regle commence par $#, alors apres reecriture, on quitte l'ensemble de
regles actuel et l'ensemble de regles 0 se rendra compte de l'utilisation de $# et utilisera cette
information pour determiner quel mecanisme de remise du courrier prendre.
, un en-t^ete qui est une suite de champs species par les RFC 822, 1341 a 1345 ( Return-Path:,
Received:, From:, Sender:, Reply-To:, Date:, To:, Cc:, Bcc:, Message-Id:, In-Reply-To:,
References:, Keywords:, Subject:, Comments:, X-???:) ;
, un corps qui est le contenu du mail proprement dit. Il est separe de l'en-t^ete par au moins une
ligne vide. Plusieurs normes regissent le contenu de ce message, MIME etant la plus connue et
permettant l'envoi de messages multimedia (caracteres accentues, sons, images. . .).
Ce message est envoye a partir du site uvsq.fr. Si le champ To: est utilise, le message est envoye
a jussieu.fr et a urec.fr. Lorsque le message arrive a jussieu.fr, si le champ To: est utilise,
le message est remis a jean, mais est egalement transmis a urec.fr puisque le champ To: contient
deux destinataires. Le site urec.fr recoit donc maintenant deux exemplaires de ce courrier. S'il
288
utilise, lui aussi, le champ To:, il va envoyer une copie de ces deux courriers a [email protected]. On
voit donc que le systeme s'emballe et qu'une boucle de courrier est creee. Les en-t^etes ne permettent
pas a eux seuls une remise du courrier.
Il convient donc de vehiculer une nouvelle information avec un message. Cette information, par
analogie avec la poste, s'appelle l'enveloppe. Comme pour le facteur, qui n'ouvre pas une lettre
pour la remettre a son destinataire, l'enveloppe sert a router le message.
Au debut de l'envoi du courrier, l'enveloppe contient les m^emes adresses destination que les
adresses mentionnees dans les champs To: etc. Mais cela evolue par contre au fur et a mesure du
traitement du courrier. Si l'on prends l'exemple precedent, lors de la remise a jussieu.fr, l'enveloppe ne contiendra que [email protected] et lors de la remise a urec.fr, l'enveloppe ne contiendra
que [email protected]. Bien s^ur, le champ To: de l'en-t^ete du courrier contiendra toujours dans les
deux cas To: [email protected], [email protected].
L'enveloppe est immaterielle : elle n'est pas stockee dans le message lorsqu'il est dans la bo^te aux
lettres, aussi les utilisateurs n'en ont pas conscience. L'enveloppe ne sert que pendant le processus
de delivraison du courrier, les en-t^etes du courrier ne servant qu'aux destinataires du courrier a titre
d'informations sur le message. Quelle est la duree de vie d'une enveloppe ? Reprenons le processus
de composition d'un courrier :
MUA 7! MTA
Le MUA, une fois le message compose, invoque
quelques options pres sans importance ici) :
ou
sendmail
la dierence etant que, dans le premier cas, l'identite de l'expediteur est tiree de l'UID
du process alors que dans le second cas, elle est explicitee, ceci etant reserve a certains
utilisateurs privilegies (les trusted users de sendmail). Exemple du premier cas :
% hostname
mendel.sis.pasteur.fr
% mail -v [email protected]
Subject: foo
foo
.
Cc:
/usr/lib/sendmail -i -m -v [email protected]
289
Cc:
/usr/lib/sendmail -i -m -v [email protected]
Transmission du
Transmission du
de l'enveloppe.
de l'enveloppe.
Il faut bien noter que les adresses passees dans l'enveloppe a ce moment peuvent avoir
ete retraitees par sendmail et donc ^etre dierentes des adresses passees par la ligne
de commande, ce qui est le cas dans l'exemple ci-dessus ou le From: de l'enveloppe est
passe de la valeur [email protected] a [email protected].
MTA 7! MDA
La derniere etape ou appara^t l'enveloppe est la remise physique du courrier par appel
d'un MDA. Si l'on prend le cas classique du MDA /bin/mail, la remise physique se
fait par l'execution de la commande :
/bin/mail -r sender -d recipient1 recipient2 recipient3 ...
Il faut bien noter une fois de plus que sendmail peut avoir reecrit les adresses de
l'enveloppe qu'on lui aura passee, tout simplement parce que ces adresses peuvent ne
pas designer directement une bo^te aux lettres (cas des alias, cas des adresses du type
Prenom.Nom etc.) et qu'en consequence, les noms passes en argument au MDA peuvent
^etre dierents des noms dans l'enveloppe.
Ainsi, dans l'exemple, le To: de l'enveloppe a beau ^etre [email protected],
le MDA est appele avec besancon comme nom de bo^te aux lettres :
/usr/local/procmail/bin/procmail -f [email protected] -d besancon
Maintenant que le concept d'enveloppe est eclairci, reprenons le mecanisme de reecriture des
adresses.
290
S'il n'est pas faux, ce schema ne re
ete cependant pas ce qui arrive en pratique lorsqu'un courrier
est soumis. Nous allons montrer un exemple detaille d'encha^nement des regles et de leurs reecritures
apres avoir donne quelques explications sur les dierents rulesets. Attention : les encha^nements de
regles sont speciques a votre version de sendmail et a votre sendmail.cf ; dans notre cas, il s'agit
de sendmail 8.7.1 avec un sendmail.cf un peu modie.
ruleset 3
ruleset 4
ruleset 0
ruleset 1
ruleset 2
291
En entree, on presente une adresse telle qu'elle a ete entree par l'utilisateur.
En sortie, on pourra avoir, selon le cas :
, une adresse sous forme canonique, c'est-a-dire de la forme partie1<@partie2>partie3
ou :
partie1
designe la partie locale a la machine cible de l'adresse
partie2
designe l'adresse de la machine cible
partie3
est destine a la machine cible pour continuer le routage
, @ en cas d'erreur ;
, un nom d'utilisateur sans nom de machine ;
, une adresse completement baroque. . .
Pour resumer grossierement, le ruleset 3 ajoute < et > autour du nom de la machine a
contacter.
C'est le pendant du ruleset 3.
En entree, on presente une adresse sous forme canonique et en sortie, on trouve une
adresse pr^ete a ^etre lue par l'utilisateur.
Ce ruleset va analyser l'adresse qu'on lui passe an d'en deduire un protocole a utiliser
pour contacter une machine qui sera capable de remettre un message a l'utilisateur
donne dans l'adresse. C'est donc un triplet (protocole, machine, utilisateur) que le
ruleset 0 determine et renvoit.
Ces rulesets sont censes eectuer des reecritures des adresses de l'expediteur (ruleset 1)
et des destinataires (ruleset 2). Dans la mesure ou ces rulesets sont toujours appeles quel
que soit le protocole utilise, il devrait s'agir de rulesets independants des protocoles.
En pratique, ces rulesets sont souvent vides.
ruleset S
ruleset R Quand le ruleset 0 arrive a determiner un triplet (protocole, machine, utilisateur), le
protocole est un nom symbolique designant une certaine ligne de sendmail.cf. Par
exemple, le protocole local designe dans le sendmail.cf d'une machine, les lignes
suivantes :
Mlocal,
Les nombres suivants S= et R= designent des rulesets qui vont ^etre utilises comme
les rulesets 1 et 2, donc pour reecrire les adresses de l'expediteur (ruleset S) et des
destinataires (ruleset R) mais, par contre, d'une maniere dependant d'un protocole.
Les traces qui suivront ont ete obtenues en utilisant un shell-script en place du normal sendmail
an de positionner des options detaillant ce qui se passera. Ce script est :
#!/bin/sh
echo "lnvoking
cat - | sed -e
-e
-e
cat /tmp/msg |
sendmail $@"
's/besancon@excalibur/besancon2@excalibur/g' \
's/besancon@ensta/besancon3@ensta/g' \
's/besancon@pasteur/besancon4@pasteur/g' > /tmp/msg
/usr/lib/sendmail -vi -d21.2 -d1.5 -d10 -d11 -d13 -d20.1 -d30 -d28.1 -d28.4 "$@"
(la passe sed n'est utile que pour montrer un certain point lors de la discussion.)
Les etapes dans l'envoi d'un mail sont les suivantes.
292
(On voit ici que le sed du script a change les diverses adresses mentionnees dans le message. Je fais
cela pour montrer a quels moments ces adresses sont utilisees ou ne le sont pas.)
besancon
besancon
besancon
$# local $: besancon
besancon
besancon
Le resultat du ruleset 0 est memorise pour tout le reste de cette session sendmail. Trace :
293
parseaddr-->62e34=besancon:
mailer 3 (local), host `'
user `besancon', ruser `<null>'
next=0, alias 0, uid 0, gid 0
flags=6000<QPINGONFAILURE,QPINGONDELAY>
owner=(none), home="(none)", fullname="(none)"
orcpt="(none)", statmta=(none), rstatus=(none)
(ici, je ne gure pas dans la base de donnees). Du fait de cette base de donnees, il est facile de
concevoir que la determination du nom de l'expediteur peut ^etre une operation co^uteuse. Pour
eviter de realiser autant de fois que de destinataires l'etape co^uteuse de consultation de la base de
donnees, le resultat de la consultation de la base est memorise dans une variable de sendmail, la
variable $f.
En pratique, on passe l'expediteur precise dans l'enveloppe dans les rulesets 3, 1 et 4 et le resultat
est sauve dans $f. Trace :
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
3
input: besancon
3 returns: besancon
1
input: besancon
1 returns: Thierry . Besancon
4
input: Thierry . Besancon
4 returns: Thierry . Besancon
294
Les adresses sont donc extraites de la ligne de commande et non de l'en-t^ete du mail.
Chaque adresse de l'enveloppe a droit a son traitement, qui peut varier d'un cas a un autre. Le
traitement depend evidemment du mailer retenu, donc du resultat de l'application du ruleset 0 sur
l'adresse de destination. En pratique, chaque adresse de l'enveloppe passe dans les rulesets 3, 0, 2,
R et 4. Le ruleset R est celui associe au mailer determine par le ruleset 0. Trace :
--parseaddr([email protected],)
rewrite: ruleset 3
input: besancon @ ensta . fr
rewrite: ruleset 3 returns: besancon < @ ensta . fr . >
rewrite: ruleset 0
input: besancon < @ ensta . fr . >
rewrite: ruleset 0 returns: $# smtp $@ ensta . fr . $: besancon < @ ensta . fr . >
rewrite: ruleset 2
input: besancon < @ ensta . fr . >
rewrite: ruleset 2 returns: besancon < @ ensta . fr . >
rewrite: ruleset R
input: besancon < @ ensta . fr . >
rewrite: ruleset R returns: besancon < @ ensta . fr . >
rewrite: ruleset 4
input: besancon < @ ensta . fr . >
rewrite: ruleset 4 returns: besancon @ ensta . fr
parseaddr-->[email protected]:
mailer 4 (smtp), host `ensta.fr.'
user `[email protected]', ruser `<null>'
next=0, alias 0, uid 0, gid 0
flags=6000<QPINGONFAILURE,QPINGONDELAY>
owner=(none), home="(none)", fullname="(none)"
orcpt="(none)", statmta=(none), rstatus=(none)
--parseaddr()
parseaddr-->NULL
--parseaddr([email protected])
rewrite: ruleset 3
input: besancon @ pasteur . fr
rewrite: ruleset 3 returns: besancon < @ pasteur . fr
rewrite: ruleset 0
input: besancon < @ pasteur . fr
rewrite: ruleset 0 returns: $# smtp $@ pasteur . fr .
rewrite: ruleset 2
input: besancon < @ pasteur . fr
rewrite: ruleset 2 returns: besancon < @ pasteur . fr
rewrite: ruleset R
input: besancon < @ pasteur . fr
rewrite: ruleset R returns: besancon < @ pasteur . fr
rewrite: ruleset 4
input: besancon < @ pasteur . fr
rewrite: ruleset 4 returns: besancon @ pasteur . fr
parseaddr-->[email protected]:
mailer 4 (smtp), host `pasteur.fr.'
user `[email protected]', ruser `<null>'
next=0, alias 0, uid 0, gid 0
flags=6000<QPINGONFAILURE,QPINGONDELAY>
owner=(none), home="(none)", fullname="(none)"
orcpt="(none)", statmta=(none), rstatus=(none)
. >
. >
$: besancon < @ pasteur . fr . >
. >
. >
. >
. >
. >
Les parties protocole et machine du triplet (protocole, machine, utilisateur) sont memorisees
pour chaque destinataire (m^eme l'expediteur du message). On ajoute alors en gros le triplet (protocole, machine, destinataire) dans une liste en veriant que cela ne correspond pas a un quelconque
alias local ou qu'il n'y est pas deja. Trace :
From person = "besancon"
main: QDONTSEND 62e34=besancon:
mailer 3 (local), host `'
user `besancon', ruser `<null>'
next=0, alias 0, uid 4332, gid 2901
flags=6005<QDONTSEND,QGOODUID,QPINGONFAILURE,QPINGONDELAY>
owner=(none), home="/users/adm/besancon", fullname="(none)"
orcpt="(none)", statmta=(none), rstatus=(none)
295
On trouve ici l'explication d'un detail jamais explique dans les programmes de ltrage de mails.
Souvent, ces programmes sont a lancer depuis le chier $HOME/.forward. Il surait, a priori,
de mettre une ligne du type : "| /usr/local/bin/filter". Malheureusement, cela ne marche
pas si plusieurs utilisateurs, destinataires d'un m^eme mail, agissent de m^eme, parce que sendmail
voyant N fois la m^eme cha^ne de caracteres "| /usr/local/bin/filter" n'en gardera qu'un. C'est
pourquoi les manuels disent toujours de mettre quelque chose du genre :
"| /usr/local/bin/filter # hloginnamei"
Ainsi, la cha^ne de caracteres sera dierente pour chaque utilisateur et sendmail traitera chaque
cha^ne de caracteres.
Ayant selectionne un protocole de transmission pour un destinataire, il faut convertir l'adresse
de l'expediteur en une adresse valide pour ce protocole. On le fait uniquement maintenant parce
que l'on a besoin du resultat du ruleset 0. On part donc de $f pour cela et on applique dessus les
rulesets 3, 1, S et 4. Le ruleset S est celui associe au protocole de communication (determine par
le ruleset 0 applique au destinataire dans l'enveloppe). Le resultat de 3, 1, S et 4 est sauve dans
une variable sendmail, $g. Cette variable, a priori, est susceptible de changer du traitement d'un
destinataire a un autre (alors que $f ne change pas). On espere a ce moment avoir dans $g un nom
complet. De cette maniere, l'expediteur est sous une forme legale pour le mailer que l'on va utiliser.
Trace :
--deliver, id=QAA28101, mailer=smtp, host=`ensta.fr.', first user=`[email protected]'
rewrite: ruleset 3
input: besancon
rewrite: ruleset 3 returns: besancon
rewrite: ruleset 1
input: besancon
rewrite: ruleset 1 returns: Thierry . Besancon
rewrite: ruleset S
input: Thierry . Besancon
rewrite: ruleset S returns: Thierry . Besancon < @ lps . ens . fr . >
rewrite: ruleset 4
input: Thierry . Besancon < @ lps . ens . fr . >
rewrite: ruleset 4 returns: Thierry . Besancon @ lps . ens . fr
296
A ce moment la, on a donc determine tout ce qui concerne l'enveloppe : adresse valide d'expediteur, adresse(s) valide(s) de destinataire(s).
Ayant maintenant cela, il reste a appeler le programme UNIX permettant la transmission du
message. Ce programme, ainsi que les options a lancer, est precise dans le chier de conguration
sendmail.cf. Une source de confusion possible est que le programme r
ealisant une connexion
SMTP est sendmail lui m^eme et non un programme externe. Trace :
send to [email protected]:
mailer 4 (smtp), host `ensta.fr.'
user `[email protected]', ruser `<null>'
next=8bc98, alias 0, uid 0, gid 0
flags=6008<QPRIMARY,QPINGONFAILURE,QPINGONDELAY>
owner=(none), home="(none)", fullname="(none)"
orcpt="(none)", statmta=(none), rstatus=(none)
openmailer: IPC ensta.fr.
[email protected]... Connecting to ensta.ensta.fr. via smtp...
220 ensta.ensta.fr ESMTP The Internet gateway to ENSTA (8.7.2/8.7) ready at Wed, 29 Nov 1995
16:46:33 +0100 (MET)
>>> EHLO excalibur.ens.fr
250-ensta.ensta.fr Hello [email protected] [129.199.115.40], pleased to meet you
250-8BITMIME
250-SIZE
250-VERB
250-ONEX
250 HELP
openmailer: MCI@8f3ac: flags=6c, errno=0, herrno=0, exitstat=0, state=2, pid=0,
maxsize=0, phase=client EHLO, mailer=smtp,
host=ensta.ensta.fr., lastuse=Wed Nov 29 16:46:34 1995
>>>
250
>>>
250
>>>
354
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
3
3
1
1
S
S
4
4
input:
returns:
input:
returns:
input:
returns:
input:
returns:
besancon2
besancon2
besancon2
besancon2
besancon2
besancon2
besancon2
besancon2
@
<
<
<
<
<
<
@
excalibur .
@ excalibur
@ excalibur
@ excalibur
@ excalibur
@ lps . ens
@ lps . ens
lps . ens .
ens . fr
. ens . fr
. ens . fr
. ens . fr
. ens . fr
. fr . >
. fr . >
fr
.
.
.
.
>
>
>
>
297
3. Les adresses de tous les destinataires, precises par les champs To:, Cc:, Apparently-To:,
Resent-To:, Resent-Cc: de l'en-t^
ete, passent dans les rulesets 3, 2, R et 4 ou R est le ruleset
associe au mailer de l'adresse de destination dans l'enveloppe. Trace (ce sont bien les adresses
[email protected] et [email protected] de l'en-t^
ete qui sont utilisees) :
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
rewrite:
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
ruleset
3
3
2
2
R
R
4
4
3
3
2
2
R
R
4
4
input:
returns:
input:
returns:
input:
returns:
input:
returns:
input:
returns:
input:
returns:
input:
returns:
input:
returns:
besancon3
besancon3
besancon3
besancon3
besancon3
besancon3
besancon3
besancon3
besancon4
besancon4
besancon4
besancon4
besancon4
besancon4
besancon4
besancon4
@
<
<
<
<
<
<
@
@
<
<
<
<
<
<
@
ensta . fr
@ ensta . fr .
@ ensta . fr .
@ ensta . fr .
@ ensta . fr .
@ ensta . fr .
@ ensta . fr .
ensta . fr
pasteur . fr
@ pasteur . fr
@ pasteur . fr
@ pasteur . fr
@ pasteur . fr
@ pasteur . fr
@ pasteur . fr
pasteur . fr
>
>
>
>
>
>
.
.
.
.
.
.
>
>
>
>
>
>
Cette manuvre a pour but de rendre les adresses des en-t^etes du message legales par rapport
au mailer utilise pour ce destinataire dans l'enveloppe.
(de m^eme pour l'autre destinataire dans notre cas de demonstration.)
, Sur chaque station, devrait ^etre congure un MTA de facon assez complete.
, Que se passerait-il si la machine destinatrice n'est par exemple qu'un terminal X ? bref une
machine sur laquelle aucun MTA ne tourne ?
298
C'est pourquoi le systeme de courrier utilise la seconde methode : la remise du courrier a des
machines postales.
Comment conna^tre ces machine bien particulieres ? Tout simplement gr^ace au DNS qui est
capable de stocker dans sa base de donnees ce type d'informations ; il s'agit en l'occurence des RRs
de type MX (cf section 11.1 [Principe du DNS], page 145). Par exemple, pour une station :
excalibur.ens.fr.
IN
MX
100 nef.ens.fr.
220 nef.ens.fr Sendmail 8.6.8/8.6.6 ready at Tue, 28 Mar 1995 00:05:47 +0200
>>> EHLO mendel.sis.pasteur.fr
500 Command unrecognized
>>> HELO mendel.sis.pasteur.fr
250 Hello mendel.sis.pasteur.fr, pleased to meet you
>>> MAIL From:<[email protected]>
250 <[email protected]>... Sender ok
>>> RCPT To:<[email protected]>
250 <[email protected]>... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 Ok
[email protected]... Sent (Ok)
Closing connection to nef.ens.fr.
>>> QUIT
221 nef.ens.fr closing connection
IN
MX
100 nef.ens.fr.
299
4. On peut indiquer plusieurs MXs dans le DNS, avec des priorites dierentes, ce qui permet
d'assurer la continuite du service du courrier electronique en cas de panne (envoi des mails
vers les MXs secondaires) et (surtout) aussi d'eviter l'inondation du MX principal lors de sa
remise en marche puisque les mails en attente ne se presenteront pas tous successivement a lui
mais au contraire feront l'objet d'une seule connexion SMTP de la part des MXs de secours qui,
selon le principe des MXs, retransmettent les mails au MX le plus prioritaire (et donc pas a
eux m^emes).
On voit donc qu'un MX presente enormement d'inter^et vu de l'exterieur d'un site.
Vu de l'interieur, par contre, la situation peut ^etre moins interessante puisque les normes voudraient que tout envoi de courrier passe alors par le MX, ce qui peut ^etre co^uteux en termes de
performances (passages inutile par des routeurs internes) et ce qui peut surcharger peut-^etre inutilement le MX. On pourrait par exemple avoir la situation suivante ou le MX se trouve derriere
quelques routeurs :
courrier destination de user@B
Chemin rl suivi
MX de B
Les generateurs de conguration sendmail exposes au paragraphe suivant proposent de regler ces
problemes.
sendmail.cf.
sendmail
ftp://dufy.aquarel.fr/pub/network/mail/sendmail.cf/release_5.3.tar.Z
300
leurs sens.
Le
ag -d35.9 ache la liste des variables internes, ce qui peut ^etre interessant pour debugger
un nouveau chier de conguration.
sendmail
URL ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail
Cet utilitaire semble le plus robuste de ceux que l'on trouve sur la place. D'autre part,
il a ete concu avec a l'esprit les problemes connus de fonctionnement en milieu NFS,
heterogene.
URL ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/sendmail.8.7.5.base.tar.Z
Cette version de sendmail contient un utilitaire MDA.
Plut^ot que de chercher a reparer sans cesse des programmes constructeurs fondamentalement
incorrects, programmes remis en cause d'une version de systeme a une autre, programmes casses
a l'application de nouveaux patches, il vaut mieux installer un des programmes ci-dessus dont le
comportement est connu, dont on peut attendre du reseau une reponse rapide et able en cas de
problemes.
Pour une analyse des problemes et des solutions apportables, cf section 17.7 [Conguration d'un
systeme de consultation de courrier electronique], page 301.
301
MTA
MTA
Systme de
fichiers
MDA
MDA
station A
station B
Ce probleme, qui a sa source dans les dicultes de realiser un verrouillage de chiers via NFS
(cf chapitre 14 [Conguration du Network File System (NFS)], page 205), peut ^etre attenue en
changeant la conguration du systeme de courrier. En eet, il est rarement utile que chaque station
necessite un environnement sendmail completement operationnel. On peut alors se contenter de la
conguration dite null-client de sendmail 8. Dans cette conguration, la quasi totalite des machines
font tourner une version degradee de sendmail qui va se contenter de rediriger toutes les requ^etes
vers le demon sendmail d'une machine qui agira comme centre postal.
rseau
MUA
MTA
MTA
brid
Systme de
fichiers
MUA
MDA
station A
station B
302
Cette possibilite de fonctionnement attenue considerablement notre probleme car elle concentre
tous les appels aux MDAs sur une seule machine, ou tout au moins sur un nombre bien plus restreint,
sans compter qu'elle evite les problemes des dierents MDAs constructeurs qui se comportent
dieremment et souvent mal en environnement NFS ou les droits d'acces au spool deviennent alors
un casse-t^ete a gerer.
Cela dit, il reste les MUAs. M^eme si c'est moins une cause de soucis que le MDA, pour la
raison simple qu'un utilisateur a rarement N MUAs lances simultanement sur plusieurs machines
provoquant ainsi des acces concurrentiels, il n'en reste pas moins que l'on peut avoir le m^eme
probleme d'acces simultanes par un MDA qui cherche a ecrire un nouveau message et par un MUA
qui cherche a enregistrer les modications apportees par la seance de consultation du courrier.
Pour tenter de resoudre ces incompatibilites de verrouillage mais aussi parce que les ordinateurs
accedant aux bo^tes aux lettres peuvent ne pas ^etre des stations de travail sous UNIX (et donc ne
pas supporter NFS), il a ete elabore certains protocoles de consultation d'une bo^te aux lettres. Ces
protocoles sont du type client/serveur et n'implantent que la partie de consultation du courrier,
la phase d'envoi de messages reposant sur l'emploi du protocole SMTP le plus souvent. Les deux
principaux protocoles sont :
POP
IMAP
mush
Eudora (pour Macintosh)
elm
Cf ftp://ftp.ifh.de/pub/unix/mail/elm_imap.patch.tar.gz
mail-drop-11b11.hqx (pour Macintosh)
Un dicton dit "For every problem there is a solution which is simple, clean and wrong ". Il en
est de m^eme pour POP et IMAP. Si cela resoud les problemes sur le plan theorique, il n'en est pas
de m^eme sur le plan pratique. On peut distinguer deux problemes :
1. Peu de MUAs utilisent jusqu'a dernierement POP ou IMAP. Heureusement une solution de
secours existe et consiste en un petit programme ne permettant que de se connecter a un server
303
POP ou IMAP, que de lui demander les nouveaux messages et de les recopier en local apres.
On peut alors appeler son MUA favori et lui dire de consulter le chier local contenant les
nouveaux mails (ce que tout MUA sait faire).
URL ftp://ftp.mal.com/pub/pop/popclient-3.0b5.tar.gz
2. Absence de securite approfondie de ces protocoles. Un mot de passe est necessaire au bon
fonctionnement de la chose. Traditionnellement avec POP, il s'agit de mot de passe UNIX
classique. Le probleme vient de ce que le mot de passe est transmis en clair sur le reseau entre
le poste client POP/IMAP et la machine du serveur POP/IMAP.
La aussi, une solution de secours existe. Disons que la methode consiste a intercaler une
connexion chiree entre le client et le serveur, sachant que le client et le serveur ne s'en rendent
pas compte si bien qu'ils n'ont pas besoin d'^etre modies. Le schema est approximativement
le suivant :
rseau
Mcanisme de
Mcanisme de
(d)chiffrement
(d)chiffrement
Systme de
fichiers
Serveur
POP/IMAP
MUA
client POP/IMAP
station A
station B
Cf ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/bortzmeyer
17.8 Bibliographie.
Le lecteur pourra se reporter aux newsgroups consacres aux dierents systemes (cf [Generalites
sur les systemes abordes], page 7) ainsi qu'a comp.mail.sendmail.
Le lecteur peut se reporter aux articles suivants :
304
305
, liaison serie ;
, liaison parallele ;
, connexion Ethernet (physiquement, ce sont des paquets Ethernet qui seront envoyes a l'imprimante, le contenu des paquets lui m^eme pouvant faire l'objet d'autres protocoles (Ethertalk,
TCP/IP etc.).
Dans tous les cas, une fois l'imprimante designee, les chiers a imprimer sont stockes provisoirement dans un sous directory du directory /usr/spool/lp a savoir /usr/spool/lp/<printername>.
Les chiers crees sont des chiers de type donnees et de type contr^ole d'impression ; leurs noms
comprennent un numero de requ^ete incremente a chaque impression (remis a zero une fois un certain
nombre atteint).
L'action de lp se termine par l'indication a lpsched de la presence d'un job a imprimer (envoi
d'un message dans un pipe nomme (en general /usr/spool/lp/FIFO) precisant le type de requ^ete
(ici impression), le numero de la requ^ete, l'imprimante destination et l'utilisateur a l'origine de la
requ^ete d'impression). L'action de lp est alors terminee ; charge a lpsched de prendre la main
maintenant. Le cycle d'impression sous la charge de lpsched est decrit par le schema qui suit.
L'action de lpsched se ramene a l'activation d'un programme d'interface qui assure la vraie
partie de l'impression (traduction dans un format que connait l'imprimante des chiers puis envoi
de ces traductions au peripherique associe a l'imprimante). Ce programme d'interface a pour nom
/usr/spool/lp/interface/<printername>. En g
eneral, il s'agit d'un shell-script mais cela peut
^etre un vrai binaire ecrit dans n'importe quel langage de haut niveau.
306
lpsched
fork()
fd 0 == /dev/null
fd 1 == /dev/<printer device>
lpsched
fd 2 == /dev/<printer device>
fork()
exec()
fd 0 == /dev/null
wait()
interface
fd 1 == /dev/<printer device>
fd 2 == /dev/<printer device>
wait()
exit()
effacement des
fichiers data
et control
libration de
limprimante
exit()
lpsched
/usr/spool/lp/model/<squelette>.
,
,
,
,
,
,
le numero de la requ^ete ;
le nom du soumetteur du job ;
le titre optionnel du job ;
le nombre de copies demande ;
la liste d'options ;
la liste des chiers a imprimer.
Le fonctionnement decrit precedemment reposait sur l'hypothese que l'imprimante etait connectee localement a la station de travail. Cela peut ne pas ^etre le cas. Le protocole LP ne comporte pas
de protocole builtin pour imprimer a distance. Suivant les OS, les methodes suivies par LP pour
imprimer a distance seront les suivantes :
307
, emploi d'un compte utilisateur de nom lp et de remote commands (rsh, rcp) ; le programme
d'interface se ramene alors a quelque chose du genre (cas de IRIX-4.0.5) :
for f in $files
do
rcp $f lp@<remote host>:/usr/tmp/<nom de fichier unique>
rsh <remote host> -l lp lp -d<remote printername> /usr/tmp/<nom de fichier unique>
done
, appel a des programmes reseau proprietaires capables de communiquer avec le systeme d'impression de l'imprimante distante (/usr/lib/rlp sous HP-UX).
Le demon lpd forke un processus ls qui va gerer la requ^ete pendant que le processus pere se
remet a surveiller l'arrivee de nouvelles requ^etes d'impression.
Que fait le processus forke ? Son r^ole est d'appliquer des ltres eventuels puis d'envoyer le resultat
du ltrage des chiers au peripherique UNIX associe a l'imprimante. Les ltres sont precises dans
/etc/printcap par les champs if et of :
of (Output filter)
fork()
of
fd 1
/dev/<printer device>
exec()
fd 1
fd 0
pipe
if (Input Filter)
308
Le ltre if, si present, annule l'eet de of qui ne peut donc s'executer que si if n'est
pas precise.
lpd
fork
fork()
fd 1
if
/dev/<printer device>
exec()
fd 0
data file
control file
data file
lpr
lpd
lpd
fork()
machine locale
lpd
lpd
fork()
machine distante
Le lpd forke de la station d'ou la requ^ete d'impression est issue (on le designera par la suite par le
lpd
emetteur) entre en communication avec le lpd de la station gerant l'impression. Ce lpd apres
avoir verie que la requ^ete est autorisee (en inspectant si la machine d'ou elle provient est citee
dans le chier /etc/hosts.lpd) forke alors un processus ls (on le designera par le lpd serveur)
et ce sont ces deux lpd forkes qui sont alors mis en communication l'un avec l'autre. Un dialogue
s'instaure alors au terme duquel le lpd emetteur envoie ses chiers de donnees et de contr^ole du
job a imprimer, comme le montre la capture d'ecran suivante (surveillance par lpq) :
309
no entries
excalibur.ens.fr: sending to tournesol
Rank
Owner
Job Files
1st
besancon
289 /tmp/acc.ps
Total Size
70132 bytes
On notera que dans le cas d'une impression distante, ce sont les ltres du lpd distant qui sont
actives et non ceux de la station a l'origine de la requ^ete.
sam
pour ajouter
Ainsi pour congurer une imprimante distante residant sur un systeme BSD, on passera
par les etapes : Printers and plotters, Printers/plotters, Add Remote Printer/Plotter
du menu deroulant Actions. On cochera la
cache Remote Printer in on a BSD system.
Si l'on souhaite proceder manuellement, il
sut de regarder le chier log de la session
sam pr
ecedente (/usr/sam/log/samlog) pour
savoir que faire manuellement.
IRIX 4.0.5 Le systeme IRIX-4.0.5 possede un package de gestion des imprimantes a la BSD. Il
s'agit du package eoe2.sw.bsdlpr.
310
Linux 1.2.2
NetBSD 1.0
Name
Date
Description
I
I
I
eoe2
eoe2.man
eoe2.man.bsdlpr
03/12/93
03/12/93
03/12/93
I
I
eoe2.sw
eoe2.sw.bsdlpr
03/12/93
03/12/93
Le systeme d'impression est le classique systeme LPD. On ajoutera donc une imprimante via /etc/printcap.
SunOS 4.1.x
Le systeme d'impression est le classique systeme LPD. On ajoutera donc une imprimante via /etc/printcap. Le demon lpd est lance depuis /etc/rc.local.
Solaris 2.x Le systeme d'impression provient du systeme LP. On se reporter a une FAQ concernant Solaris pour savoir comment congurer le systeme d'impression, par exemple
ftp://ftp.ens.fr/pub/FAQ/FAQ.solaris.Z.
311
[...]
LAT_SETUP="1"
export LAT_SETUP
[...]
/dev/tty01
/dev/tty02
console vt100
console vt100
/dev/tty0e
/dev/tty0f
console vt100
console vt100
Les points importants sont les champs ct, lp, of et xf (parce qu'ils ne sont pas intuitifs).
Se reporter au manuel de printcap pour davantage d'explications sur les dierents champs.
312
Pour exporter cette queue d'impression VMS a des systemes UNIX, voici la marche a suivre :
1. Lancer ucx puis y faire les operations suivantes :
UCX> show service lpd /full
515
5
1
State:
Enabled
Protocol: TCP
User_name: UCX_LPD
Active:
0
Address:
Process:
Peak:
0.0.0.0
UCX$LPD
1
File:
Flags:
SYS$SPECIFIC:[UCX_LPD]UCX$LPD_RCV_STARTUP.COM
Aprox Listen
Socket Opts:
Receive:
Rcheck Scheck
0
Send:
Log Opts:
File:
Acpt Actv Dactv Conn Error Exit Logi Logo Mdfy Rjct TimO Addr
SYS$SPECIFIC:[UCX_LPD]UCX$LPD_RCV_STARTUP.LOG
Security
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0
2. Executer la commande :
@ SYS$MANAGER:UCX:LPD_STARTUP
3. Finir par :
MC UCX$LPRSETUP
Cette commande vous pose quelques questions concernant la queue d'impression a exporter.
Apres, le chier SYS$SPECIFIC:[UCX_LPD]UCX$PRINTCAP.DAT aura ete modie et contiendra
quelque chose comme :
#
# LOCAL PRINTERS
#
UCX$LPD_QUEUE:\
:lp=UCX$LPD_QUEUE:\
:sd=UCX$LPD_SPOOL:
#
# LW_QUEUE made available for remote printing
#
LWAP:\
:lp=LW_QUEUE:\
:rm=:\
:rp=:\
:lf=:\
:sd=UCX$LPD_SPOOL:
313
for f in $files
do
rcp $f lp@<remote host>:/usr/tmp/<nom de fichier unique>
rsh <remote host> -l lp lp -d<remote printername> /usr/tmp/<nom de fichier uni que>
done
On voit donc qe cela necessite la creation d'un compte utilisateur de nom lp, la mise en place
d'un .rhost ou equivalent et aussi l'emploi du systeme LP a l'autre bout !
Pour remedier a ces problemes, ainsi qu'a certains problemes de LPD, il a ete cree un nouveau
systeme d'impression : PLP (Portable LP) qui se compile sur beaucoup de systemes. En voici
quelques caracteristiques :
LPRng - An Enhanced Printer Spooler
(Beta Release)
Patrick Powell <[email protected]>
The LPRng software is an enhanced, extended, and portable version of the Berkeley
LPR software. While providing the same general functionality, the implementation is
completely new and provides support for the following features: lightweight (no databases needed) lpr, lpc, and lprm programs; dynamic redirection of print queues; automatic job holding; highly verbose diagnostics; multiple printers serving a single queue;
client programs do not need to run SUID root; greatly enhanced security checks; and
a greatly improved permission and authorization mechanism.
The source software compiles and runs on a wide variety of systems, and is compatible
with most PC and MAC based print spoolers that use the LPR interface.
The package comes with lters for PostScript and HP printers, as well as the usual
'dumb' printers. Note that the lters supplied for the HP printers do accounting, and
were developed to be used in an Educational Environment, where avoiding accounting
procedures is quite prevalent.
The software may be obtained from
,
,
ftp://dickory.sdsu.edu/pub/LPRng/
ftp://iona.ie/pub/plp/LPRng
To join the LPRng/PLP mailing list, please send mail to [email protected] with
the word 'subscribe' in the BODY
Patrick Powell
314
18.6 Bibliographie.
Le lecteur peut se reporter aux articles suivants :
[Ste] W. Richard Stevens. UNIX network programming. Addison-Wesley.
315
316
317
19 Reseaux Appletalk.
19.1 Introduction.
Ce chapitre est consacre a un probleme bien particulier : faire coexister des ordinateurs Macintosh d'Apple et des stations de travail sous UNIX.
On notera que l'on ne traitera pas du probleme equivalent avec des compatibles PC. Les raisons
en sont simples :
1. Un compatible PC ne fournit aucune conguration reseau de base, ni aucun protocole reseau
au niveau du systeme d'exploitation. Un Macintosh ore par contre tout cela de base ;
2. Quand un compatible PC est dote d'une carte d'interface reseau, il s'agit le plus souvent d'une
carte Ethernet (puisque c'est ce qu'il y a moins de cher sur le marche actuellement). On ne se
retrouve donc pas dans le cas ou le reseau a un support physique dierent de celui des stations
de travail. Le probleme revient alors a ce que le systeme du PC implante les m^emes couches
de communication reseau que l'on trouve sur une station de travail.
3. Il existe des peripheriques Apple d'impression, ayant une interface reseau Apple et parlant
le protocole reseau d'Apple alors que rien de tel n'existe dans le monde des PC. C'est donc
naturellement que l'on a souhaite utiliser les possibilites d'impression du monde Macintosh.
Partant de cette situation, les points a satisfaire sont les suivants :
, imprimer depuis une station de travail UNIX sur une imprimante du monde Macintosh ;
, acceder aux services UNIX depuis les Macintoshes (telnet, ftp, news, etc.) ;
, acceder aux services Apple entre Macintoshes (AppleShare, impression).
Pour arriver a cela, diverses choses sont necessaires :
, du materiel : il faut des bo^tiers routeurs entre les dierents reseaux physiques abritant les
peripheriques Apple ou UNIX ;
, du logiciel : au minimum on en a besoin sur le bo^tier routeur mais on se rend bien compte
qu'il faudra bien quelque chose sur les stations de travail UNIX.
Pour ce qui est des logiciels, il en existe plusieurs, des commerciaux et des logiciels du domaine
public. Au niveau du domaine public, il s'agit de :
Columbia AppleTalk Package (CAP)
Le package est disponible sur munnari.OZ.AU dans le directory /mac/ ou l'on trouvera
d'autres choses associees au package.
Voir aussi ftp://ftp.ibp.fr/pub/appletalk/cap/cap60.pl196.tar.Z.
netatalk URL ftp://terminator.cc.umich.edu/unix/netatalk/netatalk-1.3.3.tar.Z.
Le directory /unix/netatalk contient d'autres choses relatives au package.
318
ASP
PAP
Contrle de session
RTMP
Echange dinformations
entre les routeurs
ZIP
Informations sur les
zones
ATP
ADSP
Contrle de transaction
NBP
Transport en flot
DDP
Acheminementt des
paquets
ELAP
Cble Ethernet
LLAP
Cble LocalTalk
LocalTalk C'est l'ore d'Apple en matiere de couche physique de transport. Le debit est de l'ordre
de 230 kbps/s et on utilise une technologie de type CSMA/CA. Plusieurs types de
c^ablages sont possibles :
c^ablage LocalTalk
Les peripheriques sont cha^nes sur une distance d'au plus 300 metres. Le
support est de la paire torsadee blindee. Ce type de c^ablage n'autorise pas
plus de 32 peripheriques.
c^ablage PhoneNet
Le support est de la paire torsadee non blindee que l'on peut utiliser selon
diverses topologies : epine dorsale (de 20 a 40 peripheriques), etoile passive
(le nombre de peripheriques peut varier), etoile active (jusqu'a 254 peripheriques), le tout sur des distances pouvant atteindre le millier de metres
suivant le diam^etre des c^ables et leur blindage.
319
EtherTalk Le support LocalTalk ne permet que de faibles debits et limite serieusement la longueur
du reseau. C'est pourquoi Apple a decide de ne pas se limiter a son support physique
LocalTalk et permet d'utiliser, par exemple, Ethernet comme support physique (ce qui
procure un gain d'un facteur quatre).
EtherTalk correspond donc a l'utilisation d'Ethernet par Apple. Pour cela, un driver
est necessaire dans le systeme Apple.
Adresse reseau
Pour dialoguer avec un peripherique, une adresse est necessaire.
Chaque element sur un reseau AppleTalk se voit attribue un identicateur numerique
que l'on appelle un numero de nud. Contrairement a UNIX, ce numero de nud pour
un m^eme element du reseau peut varier entre deux mises sous tension ; il est attribue
de facon dynamique par le processus reseau qui gere le poste.
Ce numero de nud est compris entre 1 et 253.
Ce numero de nud est associe a un reseau qui a lui m^eme un identicateur (xe cette
fois-ci). Ce numero est compris entre 1 et 65279 et on le note souvent sous la forme
x.y ce qui se d
ecode en 256 * x + y.
AppleTalk phase 1 { AppleTalk phase 2
Parce qu'il est possible d'utiliser des supports physiques du genre Ethernet sur lesquels
de nombreux peripheriques peuvent ^etre connectes, Apple a introduit le protocole AppleTalk phase 2, permettant de ne pas ^etre limite a 253 nuds par reseau physique. Le
procede pour y arriver est simple (en resumant) : il sut de permettre a un reseau de
ne pas se limiter a une adresse mais de l'autoriser a s'etendre sur une plage d'adresses.
On parle alors de reseau etendu. De par la raison qui a pousse a la creation d'AppleTalk
phase 2, on comprend que cela ne concerne pas les reseaux a support LocalTalk sur
lesquels AppleTalk phase 2 se comportera donc de la m^eme facon qu'AppleTalk phase
1.
C'est la principale dierence entre les deux versions des protocoles. D'autres dierences
(mineures a notre niveau) existent, principalement :
, Les informations RTMP de routage sont ameliorees, reduisant la charge du routeur;
, Il y a quelques dierences au niveau des paquets EtherTalk ;
Zone AppleTalk
Une zone AppleTalk correspond a une entite logique qui n'existe que si l'on est dans le
cas de plusieurs reseaux relies par des routeurs.
Un nom de zone est aecte a chaque numero de reseau. Dans le cas d'un reseau etendu,
chaque numero de la plage est associe au m^eme nom de zone permettant ainsi de ne
voir qu'une seule entite.
Quelques remarques :
, Puisqu'un reseau LocalTalk ne peut pas ^etre etendu, un reseau LocalTalk ne peut
faire partie que d'une seule zone (attention, je n'ai pas dit "constitue une zone a
lui tout seul") ;
, Un reseau physique devant faire partie d'au moins deux zones, doit fonctionner en
AppleTalk phase 2 ;
, Si une zone doit ^etre repartie sur plusieurs reseaux physiques, les reseaux physiques
doivent fonctionner sous AppleTalk phase 2.
Le nom des zones appara^t dans le selecteur.
MacIP
Il s'agit de trames du protocole IP encapsulees dans des trames du protocole DDP.
IpTalk
Il s'agit de trames du protocole DDP encapsulees dans des trames du protocole UDP.
320
, les routeurs implantant le protocole KIP, par exemple les routeurs FastPath, GatorBox ;
, les routeurs n'implantant pas le protocole KIP.
Nous ne parlerons que de la premiere categorie.
Le protocole KIP a ses origines a l'universite de Stanford en 1985 ; c'est a cette periode que
fut cree le premier routeur AppleTalk/Ethernet appele SEAGate (Stanford Ethernet AppleTalk
Gateway). En 1986, un autre routeur vit le jour, le routeur Kinetics Fastpath. A cette occasion, le
code logiciel du SEAGate fut porte sur le Kinetics et prit le nom de KIP (Kinetics IP). Depuis, de
nombreux routeurs ont vu le jour aussi, reprenant le code source de KIP et assurant par la m^eme
l'adhesion a un standard de facto.
Apparte : KIP designe le code logiciel des routeurs ; il implante les protocoles IPTalk et MacIP.
KIP, IPTalk et MacIP sont donc des choses distinctes.
Qu'apporte KIP ? L'une des fonctionnalites des routeurs KIP est de permettre l'interconnexion
de reseaux AppleTalk via Ethernet. Il s'agit donc d'un probleme de routage. KIP implante la gestion
de ce routage.
Ce routage est de nature statique. Chaque routeur doit donc ^etre au courant de toutes les routes
vers les reseaux AppleTalk. Pour eviter d'avoir a entrer manuellement ces routes dans chaque
routeur, KIP se sert d'une machine serveuse de routes ; on designe cette machine sous le nom de
AA host (AppleTalk Administrator host).
L'utilisation du AA host par un routeur fait l'objet d'un pseudo protocole qui est le suivant :
1. Le routeur boote. Pendant son autoconguration, le routeur ne possede que quelques renseignements :
, son adresse IP ;
, l'adresse IP d'un routeur TCP/IP par defaut ;
, l'adresse IP d'un AA host.
2. Ayant decouvert l'adresse IP du AA host, le routeur envoit a ce AA host des requ^etes de type
aaCONF de demande d'informations compl
ementaires de conguration. Il recoit en retour du
321
AA host ces informations sur le port aaPort (le port 901) toujours sous la forme de paquets
:
aaCONF
aaMagic (0xFF068030)
opcode 0x01
flags
senders IP address
ipbroad
ipname
ipdebug
ipfile
ipother[0]
ipother[1]
ipother[2]
ipother[3]
ethertalk net
startddpWKS
flags
ipstatic
ipdynamic
localtalk net
UDP/DDP net
3. Le routeur demande alors les routes statiques que connait le AA host. Pour cela, il envoit au AA
host une requ^ete de type aaROUTEI (aaROUTEI comme AA Initial Route). Le AA host repond
par des paquets de type aaROUTEI contenant autant de nuplets (IP net or host, AppleTalk net
#,
ags, hops) que necessaire :
aaMagic (0xFF068030)
opcode 0x02
flags
senders IP address
IP net or host
AppleTalk net #
flags
hops
IP net or host
AppleTalk net #
flags
hops
IP net or host
AppleTalk net #
flags
hops
322
Le routeur est alors congure, tout au moins en ce qui concerne la partie geree par le AA host.
En eet, il peut y avoir d'autres routes que le AA host peut ne pas conna^tre, par exemple quelque
chose comme :
L1
AppleTalk
AppleTalk
R1
L
AppleTalk
R2
L
AppleTalk
L2
Ethernet
AA
Le routeur R peut apprendre du AA host comment router vers L' (via R') mais par contre il ne
peut pas appendre du AA host comment router vers L1 et L2. Ceci est d'autant plus vrai pour le
routeur R' qui a priori n'a pas de moyens de decouvrir les reseaux L1 et L2.
Alors comment faire en sorte que les AEG connaissent les routes pour atteindre TOUS les
reseaux AppleTalk ?
Juste avant ce probleme, se pose deja le probleme pour R d'apprendre les routes vers L1 et L2.
Cela est facilement resolu : sa phase de boot terminee, le routeur est capable d'ecouter ce qui passe
sur son interface LocalTalk ou EtherTalk. Or un routeur sur un reseau purement AppleTalk est
oblige de suivre le protocole RTMP (Routing Table Maintenance Protocol) d'AppleTalk qui specie
que les routeurs doivent s'echanger toutes les dix secondes des informations de routage. Donc R1
et R2 emettent des paquets RTMP qu'il sut a R d'ecouter pour apprendre les routes vers L1 et
L2. R, bien s^ur, emettra aussi des paquets RTMP avertissant R1 et R2 de l'apparition de nouveaux
reseaux joignables par son intermediaire.
Revenons maintenant au probleme de la connaissance de TOUS les reseaux AppleTalk. Le
protocole IPTalk n'implantant pas le transport des paquets RTMP, ces paquets restent donc connes
au brin AppleTalk et donc les AEG autres que celui directement connecte au brin ne peuvent pas
apprendre les routages complementaires. La methode de diusion des informations de routage vers
ces nouveaux reseaux est alors la suivante :
De cette facon, les routes vers TOUS les reseaux AppleTalk sont connues de tous les AEG (s'il y
a plusieurs core routers, on les utilise en acces round-robin). L'utilisation d'un core router ne sera
utile que si l'on a aaire a des reseaux de type L'.
323
Le protocole RMTP faisant des informations de routage qu'il transmet des informations perissables dans le temps (passant par les stades GOOD, SUSPECT et BAD), il faut repercuter cela
aussi au niveau des routes apprises par RTMP et transmises par aaROUTEQ. On associe donc a ces
routes des TTL (Time To Live) alors qu'aux routes apprises par le AA host (aaROUTE) ne sont pas
associes de TTL (ces routes sont eternelles).
Un protocole existe pour transmettre les noms de zones associes aux numeros de reseaux AppleTalk. Nous ne le decrirons pas ici.
Nous venons de voir un certain nombre de responsabilites incombant au AA host :
anet
Ethernet
324
IP_adress
zone
Ethernet
anet
Ethernet
IP_adress
zone
AppleTalk
Ethernet
325
IP_adress
zone
anet
IP_adress
zone
, Les laboratoires font partie d'un site ayant un numero de reseau de classe B. Chaque laboratoire
se voit attribuer un numero de classe C dans la plage autorisee par la classe B. La valeur du
broadcast pour chacun des laboratoires est 129.104.xxx.255.
, Une convention existe au niveau du site pour le numerotage des reseaux AppleTalk. Nous
supposerons qu'il n'y a qu'un seul AEG par reseau IP de classe C.
route IP de type Net
Le reseau AppleTalk destination a pour numero 2.x ou x est le troisieme octet de
l'adresse IP du reseau TCP/IP.
route IP de type Host
Il n'y a pas de convention pour le numero du reseau considere (ce type de route
est rare).
route IP de type Kbox
Si le reseau AppleTalk considere est le reseau EtherTalk, le reseau AppleTalk
destination a pour numero 3.x ou x est le troisieme octet de l'adresse IP du reseau
TCP/IP.
Si le reseau AppleTalk considere est le reseau LocalTalk, le reseau AppleTalk destination a pour numero 4.x ou x est le troisieme octet de l'adresse IP du reseau
TCP/IP.
, Les routeurs sont des FastPath 4 et 5 ; le FastPath 5 est le routeur du CPTH d'adresse
129.104.10.220.
Avant de passer au contenu du chier /etc/atalkatab, donnons le plan du reseau (une sorte de
separation physique entre les dierents reseaux IP appara^t sur le plan ; elle est purement virtuelle
et n'est la que pour permettre de distinguer les dierents laboratoires).
326
Le AA host n'est pas represente sur le plan ; il est quelque part ailleurs sur le site, sur un autre
brin Ethernet.
Chaque laboratoire possede des serveurs AppleShare inplantes sur des stations UNIX ainsi que
des peripheriques AppleTalk directement raccordes sur Ethernet (par exemple des imprimantes).
FDDI
Routeur CISCO
3.3
129.104.3.0
2.3
4.3
LocalTalk
4.10
LocalTalk
4.23
LocalTalk
129.104.10.0
CMAT
129.104.3.220
2.10
129.104.23.0
CPTH
129.104.10.220
2.23
GAGE
129.104.23.220
Ethernet
Pour des questions de simplicite, il a ete decide que les peripheriques AppleTalk seraient tous
dans la m^eme zone, qu'ils soient de nature LocalTalk ou EtherTalk (ce qui sous-entend que l'on
travaille en AppleTalk phase 2).
De quels reseaux AppleTalk dispose-t-on alors ?
1. On a des reseaux LocalTalk, au nombre de trois ; suivant la convention, ils ont pour numeros
4.3, 4.10 et 4.23. Au niveau de atalkatab, cela donnerait des lignes du type :
4.3
4.10
4.23
K
K
K
129.104.3.220
129.104.10.220
129.104.23.220
CMAT-CPTH-GAGE
CMAT-CPTH-GAGE
CMAT-CPTH-GAGE
327
2. Chaque laboratoire possedant des stations UNIX abritant des serveurs AppleShare, il est necessaire de denir des reseaux ou sera utilise de l'IPTalk. On aura donc trois reseaux de type
Net ; le broadcast correspondant a un classique broadcast de reseau de classe C, on aura donc
au niveau de atalkatab, les lignes :
2.3 N1
2.10 N1
2.23 N1
129.104.3.0
129.104.10.0
129.104.23.0
CMAT-CPTH-GAGE
CMAT-CPTH-GAGE
CMAT-CPTH-GAGE
3. Chaque laboratoire possede des peripheriques EtherTalk, donc sur le c^abe Ethernet. Il faut
donc denir un ou plusieurs reseaux EtherTalk. Il a ete choisi de n'en creer qu'un par c^able
Ethernet et par zone ; on a donc au niveau de atalkatab, l'unique ligne :
3.3
129.104.10.220 CMAT-CPTH-GAGE
Pourquoi avoir choisi le routeur 129.104.10.220 ? C'etait le seul FastPath 5 alors que les
autres AEG sont des FastPath 4. . .
On notera que l'on ne suit pas la convention pour le numero de reseau AppleTalk puisque
celui-ci est 3.3 au lieu de 3.10.
Le chier atalkatab ne servant pas uniquement a denir le routage statique entre reseaux AppleTalk, on y trouve donc aussi des informations de conguration des routeurs AppleTalk/Ethernet.
Ces informations sont donnees en m^eme temps que les routes de type Kbox, d'ou en fait les lignes
suivantes :
##
## R
eseaux LocalTalk accessibles par des routeurs.
## Informations de configuration des routeurs.
##------------------------------------------------------------------------------## CMAT ##
4.3
K 129.104.3.220 CMAT-CPTH-GAGE
## This line define a gateway to a network # 2.3,
## using a kinetics box with its IP addr, and zone name.
I129.104.3.255
## ipbroad
: broadcast address
I129.104.30.41
## ipname
: nameserver (for MacIP)
I129.104.30.60
## ipdebug
: node allowed to run ddt (not used)
I129.104.3.3
## ipfile
: a file server (not used)
L0 L0 L0 L0
## ipother
: 4 other IP addr (for MacIP) (not used)
S0
## atnetet
: 0 if don't use ethertalk
S768
## ddprangestart : 200 (nic #) or 768 (old #)
LX0
## flags
: see doc/rev0987
S10
## ipstatic
: assign 10 static MacIP addresses
S24
## ipdynamic
: assign 24 dynamic MacIP addresses
S4.3
## atneta
: atalk net # on atalk side
S2.3
## atnete
: atalk net # on ethernet side.
"CMAT-CPTH-GAGE"
## zonea
: (ignored)
## CPTH ##
4.10 K 129.104.10.220
I129.104.10.255
I129.104.30.41
I129.104.30.60
I129.104.30.60
L0 L0 L0 L0
S3.3
S768
LX0
S10
S24
S4.10
S2.10
"CMAT-CPTH-GAGE"
CMAT-CPTH-GAGE
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
328
## GAGE ##
4.23 K 129.104.23.220
CMAT-CPTH-GAGE
I129.104.23.255
I129.104.30.41
I129.104.30.60
I129.104.30.60
L0 L0 L0 L0
S0
S768
LX0
S10
S24
S4.23
S2.23
"CMAT-CPTH-GAGE"
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
startddpWKS
flags
ipstatic
ipdynamic
localtalk net
UDP/DDP net
##
##
##
##
##
##
##
##
##
##
##
##
ipbroad
ipname
ipdebug
ipfile
ipother
atnetet
ddprangestart
flags
ipstatic
ipdynamic
atneta
atnete
:
:
:
:
:
:
:
:
:
:
:
:
broadcast address
nameserver (for MacIP)
node allowed to run ddt (not used)
a file server (not used)
4 other IP addr (for MacIP) (not used)
0 if don't use ethertalk
200 (nic #) or 768 (old #)
see doc/rev0987
assign 10 static MacIP addresses
assign 24 dynamic MacIP addresses
atalk net # on atalk side
atalk net # on ethernet side.
2. Nous avons dit qu'un seul reseau EtherTalk avait ete cree, le reseau 3.3 associe au routeur
129.104.10.220. On retrouve l'existence d'un unique r
eseau au niveau des lignes atnetet des
trois routeurs :
## CMAT ##
4.3
K 129.104.3.220 CMAT-CPTH-GAGE
[...]
S0
[...]
## CPTH ##
4.10 K 129.104.10.220 CMAT-CPTH-GAGE
[...]
S3.3
[...]
## GAGE ##
4.23 K 129.104.23.220 CMAT-CPTH-GAGE
[...]
S0
[...]
Moyennant ce chier atalkatab, on accede dans la m^eme zone aussi bien aux imprimantes
LocalTalk qu'EtherTalk, aussi bien aux serveurs AppleShare Macintosh qu'UNIX.
329
330
Le choix du mode de fonctionnement se fait a la compilation. Si les deux modes sont disponibles
sur votre plateforme, choisissez alors le mode EtherTalk qui fonctionne plus rapidement. La FAQ
de CAP donne des indications sur la bonne facon de proceder.
Le mode de fonctionnement etant choisi, il reste a lancer CAP qui va alors rendre la station
UNIX visible depuis des Macintoshes comme etant une entite AppleTalk.
Traditionnellement, on utilise un script /etc/rc.atalk ou /etc/rc.etalk (suivant le mode de
fonctionnement) pour lancer CAP. La station UNIX devant devenir une entite AppleTalk, elle doit
posseder un numero de nud sur le reseau AppleTalk auquel elle appartient. Comment acquerir
ces informations ?
mode IPTalk
On utilise un chier auxilliaire, /etc/atalk.local. Par exemple, pour la zone AppleTalk 2.11, on aurait sur un serveur AppleShare UNIX :
## mynet mynode myzone
2.11 2 AT-LIX
## bridgenet bridgenode bridgeIP
2.11 220 129.104.11.220
Le numero du nud doit ^etre le dernier octet de l'adresse IP de la station UNIX. Ici
c'est 129.104.11.2 d'ou le chire 2 pour le champ mynode.
On notera la derniere ligne : on y fait reference au numero de nud de l'AEG ; cela
n'est possible que parce que l'AEG se voit toujours assigne le m^eme numero de nud.
Ici l'AEG a pour adresse IP 129.104.11.220 d'ou le numero de nud 220.
mode EtherTalk
On lance un demon de plus par rapport a la version IPTalk : aarpd. C'est un demon
charge de traiter des requ^etes AppleTalk Address Resolution Protocol. Il stocke les
couples adresse Ethernet { adresse AppleTalk. On le lance de la facon suivante :
#!/bin/sh
# Startup of atalk daemons.
BIN=/usr/local/cap/bin
ETC=/usr/local/cap/etc
if [ -x $BIN/aarpd ]; then
$BIN/aarpd le0 CMAT-CPTH-GAGE &
(echo -n "aarpd (avec tempo de 30 secondes)" > /dev/console)
sleep 30
fi
[...]
interface
netRangeStart
netRangeEnd
thisNet
thisNode
thisZone
bridgeNet
bridgeNode
bridgeIP
nisNet
nisNode
asyncNet
asyncZone
331
"le0"
3.03
3.03
3.03
2
"CMAT-CPTH-GAGE"
3.03
129
127.0.0.1
3.03
2
0.00
""
La suite du lancement de CAP est commune aux deux modes de fonctionnement et consiste a
lancer d'autres demons, plus ou moins necessaires selon les fonctionnalites que l'on souhaite orir
(atis, snitch et aufs).
332
Voici ce qu'il en est sur un exemple simple. On se place dans le cas ou le chier $HOME/afpvols
ou $HOME/.afpvols de l'utilisateur contient /users/stat/welty/MAC:welty, ce qui permet de
monter le volume welty suivant, comme le montre la copie d'ecran ci dessous :
Les chiers Macintosh etant types et ceux d'UNIX ne l'etant pas, il faut simuler sous UNIX les
deux constituantes d'un chier Macintosh. C'est CAP qui s'occupe de cela, ce qui implique qu'il
faut eviter de modier a la main les arborescences UNIX de stockage de chiers AppleShare. Pour
plus de details sur la facon dont se realise le stockage, on se reportera a la page de manuel de AUFS.
, Une imprimante physique peut avoir de multiples incarnations UNIX, tout bonnement pour
proposer dierents types de ltres a appliquer aux chiers a imprimer. Cela se traduit donc par
autant de ltres de type if que d'incarnations donc de multiples instances du nom Macintosh
a modier en cas de renommage.
, L'imprimante Macintosh est sujette a voir son nom changer. C'est dans la nature de l'environnement Macintosh. Que le nom de l'imprimante soit le moins repandu possible est donc une
bonne chose.
, L'univers Macintosh est ainsi fait que les noms des imprimantes peuvent comporter a peu pres
n'importe quels caracteres, disons des caracteres dont UNIX a horreur, par exemple l'espace
ou des caracteres accentues.
Pour ces raisons, les noms de imprimantes Macintosh sont centralises dans un unique chier,
traditionnellement /etc/cap.printers ; c'est une collection de couples dont le premier element
sera le nom appele par papif et dont le second element est le nom Macintosh. Par exemple :
lw-li=Evelyne:LaserWriter@AT-LIX
lw-lu=Catherine:LaserWriter@AT-LIX
333
Comment papif se retrouve-t-il appele ? Tout se fait via le chier /etc/printcap. Comme les
imprimantes AppleTalk ne sont pas connectees physiquement a une station de travail, on declare ces
imprimantes comme etant des imprimantes virtuelles : le peripherique d'impression sera equivalent
a /dev/null et le ltre d'impression fera en fait le veritable travail en etablissant, au moyen de
programmes CAP, une communication avec l'imprimante AppleTalk. Regardons un exemple ; tout
d'abord le chier /etc/printcap :
lix:\
:af=/usr/adm/lw-li.acct:\
:if=/usr/local/cap60/filters/lw-li:\
:lf=/usr/adm/lw-errs:\
:lp=/usr/local/cap60/dev/psli:\
:mx#0:
On y voit la declaration UNIX d'une imprimante de nom lix. Cette imprimante fera appel au ltre
a chaque impression ; ce ltre fait les choses suivantes :
/usr/local/cap60/filters/lw-li
% more /usr/local/cap60/filters/lw-li
#!/bin/sh
lw=`echo $0 | sed 's#.*/##'`
On recupere le nom sous lequel le programme est appele ; ici ce sera /usr/local/cap60/filters/lw-li
ce qui donnera lw-li.
BANNERLAST=1 CHARGEBANNER=0
PSTEXT=/usr/local/cap60/bin/pstext-A4-LW
JOBOUTPUT=/tmp/lw-output
export BANNERLAST CHARGEBANNER JOBOUTPUT PSTEXT
Il ne reste plus qu'a papif qu'a regarder dans /etc/cap.printers pour decouvrir qu'il doit
travailler avec Evelyne:LaserWriter@AT-LIX.
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/fyi-cap--IIg
334
,
,
,
,
Yes
Yes
Yes
Lancer gen.makes;
Lancer make libsmade ;
Lancer make programms ;
Lancer make install ;
4. Il faut tester le logiciel nouvellement compile :
, Lancer bin/aarpd le0 '*' ; attendre une quinzaine de secondes ;
, Lancer bin/atis ; un chier etc/etalk.local devrait ^etre cree de la forme :
#
# EtherTalk dynamic configuration data
#
# Last update: Tue Jan 18 15:34:30 1994
#
# Generated by Native EtherTalk (Phase 2)
#
interface
"le0"
netRangeStart
0.00
netRangeEnd
255.254
thisNet
255.00
thisNode
168
thisZone
"*"
bridgeNet
0.00
bridgeNode
0
bridgeIP
127.0.0.1
nisNet
255.00
nisNode
168
asyncNet
0.00
asyncZone
""
, Lancer bin/atlook pour inspecter ce que l'on voit sur la zone par defaut * ;
, Tester l'imprimante en lui soumettant un job (remplacer les noms par ceux qui
conviennent) :
1 root
nit
-rwxr-sr-x
-rwxr-sr-x
1 root
1 root
nit
nit
37,
40 Jul 30
1992 /dev/nit
Solaris 2.x.
335
Les instructions pour obtenir une version de CAP fonctionnant sous Solaris 2.2 sont disponibles sous l'URL ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/capsolaris-2.2.
ftp://terminator.rs.itd.umich.edu/unix/netatalk/netatalk-1.3.3.tar.gz
L'integration au kernel est reelle ; on peut la voir par exemple au niveau des tables de routage du
noyau. Si par exemple le reseau est celui donne par la gure suivante (les numeros en hexadecimal
correspondent aux numeros de zones AppleTalk), la commande netstat -rn renverra :
0x70
idefix:[41]:</network/excalibur/homes/besancon>netstat -rn
Routing tables
0x71
0x72
Destination
Gateway
Flags
Refcnt Use
Interface
127.0.0.1
127.0.0.1
UH
6391
lo0
default
129.199.115.4
UG
8870
le0
129.199.112.0
129.199.115.13
23
213972
le0
(16)0 0 0 0 0 0 0 (16)0 0 0 0 0 0 0 UH
0x74
0x75
0x76
0x77
13
0
lo0
4
lo0
43
le0
le0
16
le0
4854
le0
le0
le0
le0
le0
le0
0x78
0x73
Les
^eches indiquent les routes explicites vers certaines zones via les routeurs precises par leurs
numeros de nud 73 XY00 sur la zone Ethertalk 0x73. La ligne :
(16)0 73 0 0 0 0 0 (16)0 73 8b00 0 0 0 0 U
4854
le0
336
indique que l'on atteint la zone Ethertalk 0x73 via le nud 0x8b00 sur cette m^eme zone ; c'est
l'analogue de la ligne :
129.199.112.0
129.199.115.13
23
213972
le0
21
21
21
21
21
21
21
21
00:51:44
00:51:44
00:51:44
00:51:44
00:51:45
00:51:45
00:51:48
00:51:51
idefix
idefix
idefix
idefix
idefix
idefix
idefix
idefix
atalkd[175]:
atalkd[175]:
atalkd[175]:
atalkd[175]:
atalkd[175]:
atalkd[175]:
atalkd[175]:
atalkd[175]:
rtmp_packet
rtmp_packet
rtmp_packet
rtmp_packet
rtmp_packet
rtmp_packet
rtmp_packet
rtmp_packet
gateway
gateway
gateway
gateway
gateway
gateway
gateway
gateway
115.228
115.227
115.192
115.225
115.134
115.226
115.128
115.229
up
up
up
up
up
up
up
up
La connaissance du protocole AppleTalk RTMP mais aussi des protocoles NBP, ZIP et AEP
n'est pas integree au driver netatalk charge dans le noyau (soit dynamiquement sur SunOS, soit
statiquement en recompilant un noyau sur ULTRIX). La reconnaissance de ces protocoles est assuree
par un demon atalkd. Ce demon utilise un chier de conguration atalk.conf lui disant sur
quelle(s) interface(s) Ethernet ecouter ainsi que la nature de ce qu'il doit ecouter. le nom de la zone
n'appara^t pas dans le chier car il est determine en scrutant le reseau.
Traditionnellement, on lance le systeme netatalk au boot de la station (cf chapitre 2 [Demarrage
d'UNIX (son bootstrap)], page 25).
337
Regexp AppleTalk
Le nom d'un peripherique AppleTalk se decompose en 3 composantes : hnomi:htypei@hzonei.
Le caractere joker dans cette designation est le signe =. Ainsi, =:=@* permet de designer
tous les peripheriques de la zone par defaut ; =:LaserWriter@* designe toutes les
imprimantes de type LaserWriter.
, la partition privee, accessible uniquement apres avoir entre un nom de login et un mot de passe:
Dans les deux cas, il faut indiquer a afpd la correspondance entre l'arborescence UNIX concernee
et le nom du volume AppleShare. Cela se fait via un chier au format :
harborescence UNIXi hnom du volume Macintoshi
338
Les partitions publiques sont precises dans des chiers dont les noms changent avec les versions de
netatalk. Se reporter a la documentation de la version utilisee. Quant aux partitions privees, elles
sont precisees via les chiers $HOME/AppleVolumes ou $HOME/.AppleVolumes.
Les chiers Macintosh etant types et ceux d'UNIX ne l'etant pas, il faut utiliser sous UNIX
un mecanisme de stockage permettant de simuler les deux forks d'un chier Macintosh. Netatalk
realise cela en utilisant un mecanisme dierent de celui de CAP ; ce mecanisme s'appelle AppleDouble et est decrit dans une note Apple pour developpeurs intitulee AppleSingle/AppleDouble
Formats for Foreign Files (disponible aupres de l'APDA ; on pourra aussi se reporter a l'URL
ftp://phoenix.doc.ic.ac.uk/computing/systems/mac/Mac-Technical/tn/networking.nw).
Voici ce qu'il en est sur un exemple simple. On se place dans le cas ou l'utilisateur a pour chier
ou $HOME/.AppleVolumes, le suivant :
/users/adm/besancon/MAC/foo AppleShare_foo,
ce qui permet de monter le volume AppleShare_foo suivant, comme le montre la copie d'ecran ci
dessous.
$HOME/AppleVolumes
Du point de vue UNIX, cela correspond a la creation de certains directories et chiers caches de
noms .AppleDouble/ et .Parent.
Un certain nombre d'utilitaires sont fournis avec le package Netatalk, permettant de convertir
depuis et vers le format AppleDouble.
hlei
| pap -p
hprinternamei
339
En pratique, on utilisera le programme pap dans la conception de ltres if ou of (cf section 18.2
[Systeme d'impression de BSD : LPD (Line Printing Daemon)], page 307) plus sophistiques (determination du caractere postscript du document a imprimer, appel d'un ltre de conversion postscript,
accounting. . .).
Petit point a signaler : l'utilitaire pap est delicat a compiler car son bon fonctionnement repose
sur une parfaite connaissance des imprimantes qu'il va adresser. Ce probleme surgit par exemple
quand on veut faire de l'accounting. Scenario : l'imprimante adressee est une Apple LaserWriter
630 Pro ; pap a ete compile normalement, avec les
ags de compilation par defaut.
Si l'on adresse l'imprimante en interactif, on obtient le nombre de pages deja imprimees :
% pap -p 'LPS -- Mezzanine:LaserWriter@Le_grand_boulevard' < pagecount.ps
Trying 115.75:128 ...
status: idle
Connected to LPS -- Mezzanine:LaserWriter@Le_grand_boulevard.
*14721
Connection closed.
Si l'on adresse l'imprimante en mode non interactif, on n'obtient pas le nombre de pages deja
imprimees :
% pap -p 'LPS -- Mezzanine:LaserWriter@Le_grand_boulevard' < pagecount.ps &
Trying 115.75:128 ...
status: idle
Connected to LPS -- Mezzanine:LaserWriter@Le_grand_boulevard.
Connection closed.
pap
avec ou sans le ag
NOEOF
selon la version de
340
Cette fonctionnalite peut ^etre astucieusement utilisee pour rendre visibles depuis des Macintoshes des imprimantes non connectables sur LocalTalk ou sur EtherTalk, comme par exemple la
SparcPrinter de Sun. Pour cela, il sut par exemple de faire la chose suivante :
1. Il faut lancer le demon papd responsable du spooling sur UNIX. On le lance depuis le script
de lancement de netatalk :
if [ -f $ATALKDIR/etc/papd ]; then
$ATALKDIR/etc/papd -a;
fi
2. Le demon lance va alors consulter le chier ${ATALKDIR}/etc/papd.conf qui denit les caracteristiques du spooling :
# File containing list of fonts resident in printer we spool to
fontfile:/usr/local/atalk/fonts/LWPlusFonts
# Location of printcap
printcap:/etc/printcap
# Directory to store Macintosh procedure sets in.
procsetdir:/var/spool/lpd/papd-procsets
# Name to appear in the Macintosh chooser
choosername:Sparc_Printer
printer:|lpr -Psparc
operator:root
Attention a la syntaxe de ce chier qui change selon les versions de netatalk. On se reportera
a la documentation de la version utilisee.
Moyennant cela, la SparcPrinter devient visible au niveau du Selecteur :
341
Pour arriver a une pseudo synchronisation, il existe au moins une methode disponible. Elle repose
sur l'utilisation d'un serveur d'heure UNIX qu'un client logiciel sur les Macintoshes consulte. Le
serveur a pour nom TimeLord et le client Macintosh a pour nom Tardis.
Le serveur d'heure TimeLord a ete concu initialement pour le logiciel CAP ; c'est sur le site
faut donc aller chercher le chier /mac/timelord.1.4.shar.Z qui contient le
client Macintosh et le code source pour TimeLord. Malheureusement ce code est incompatible avec
la librairie de Netatalk-1.3.x. Cependant, le portage a ete fait sur Netatalk et on trouvera la version
de TimeLord pour Netatalk 1.3 sur le site citi.umich.edu sous le nom /usr/honey/timelordbundle ; on prendra aussi le chier /usr/honey/timelord-1.3-diffs qui permet de patcher le
chier pour Netatalk 1.3.1.
munnari.oz.au qu'il
Quand on appuie sur le bouton Set Time, l'heure du Macintosh est immediatement calee sur
celle du serveur d'heure que l'on aura selectionne au prealable.
On peut indiquer que le Macintosh regle son
horloge chaque jour a une heure bien precise.
On utilise pour cela le bouton Settings qui
permet de rentrer l'heure quotidienne de reglage de l'horloge.
342
Ici, dans ce laboratoire, la bo^te s'appelle AT-LIX. Son adresse IP est 129.104.11.220.
Open,
343
On choisit alors le bouton Reset et apres avoir valide son choix, on voit de nombreux messages
deler dans la fen^etre de diagnostic :
On se retrouve alors avec la fen^etre de depart ou l'on clique sur Update qui devrait faire retrouver
la bo^te.
Pause
configuration File
On peut, bien s^ur, modier la conguration chargee ou en creer une de toute piece.
Open
344
On telecharge alors dans le bo^tier du code specialise : choisir pour cela l'entree
dans le menu File :
file
Download a
On peut
Une fois le soft telecharge, on relance le bo^tier Kinetics par le bouton Go.
On peut verier que le bo^tier a bien acquis les informations de la conguration en le rebootant
proprement en appuyant sur le bouton Restart et en regardant la fen^etre de diagnostique :
345
19.7 Bibliographie.
Le lecteur pourra se reporter aux newsgroups consacres aux dierents systemes (cf [Generalites
sur les systemes abordes], page 7) ainsi qu'a comp.protocols.appletalk.
Il existe aussi un site Apple accessible via le WWW, www.france.euro.apple.com.
Voici quelques adresses de sites FTP bien fournis en logiciels MAcintosh :
,
,
,
,
Site sumex-aim.stanford.edu.
Site ftp://phoenix.doc.ic.ac.uk/computing/systems/mac/umich
Site mac.archive.umich.edu.
Site ftp.cc.utexas.edu.
Un peu de bibliographie :
[BP90] J. LittleField B. Parker. Specication of IP datagrams transported over AppleTalk Networks (MacIP). Technical report, Cayman Systems, 1990,
URL ftp://ftp.cayman.com//pub/specs/MacIP_Spec_#0.4.txt
[Bud92] Philip Budne. KIP AppleTalk/IP Gateway Functionlity. Technical report, Shiva Corporation, 1992,
URL ftp://lore.cs.columbia.edu/pub/kip.PS.Z
[foo] Technical report,
URL ftp://ftp.cayman.com/pub/User_Conference_Notes/TCPIP_MACIP.sit.hqx
[Hac92] Thomas J. Hacker. Netatalk Architecture. Technical report, Center for Information yechnology Integration, University of Michigan, 1992,
URL ftp://citi.umich.edu/public/netatalk/doc/netatalk_arch.sit.hqx
[Inc19] Apple Computer Inc. AppleTalk Network System Overview. Addison Wesley, 19??
[Lit90] Josh LittleField. AA Protocol Specication. Technical report, Cayman Systems, 1990,
URL ftp://ftp.cayman.com//pub/specs/kip/AA_Protocol.txt
[Nor91] Chris North. AppleTalk Routers and Routing Tables. Technical report, Cayman Systems,
1991,
URL
ftp://ftp.cayman.com/pub/User_Conference_Notes/AT_Routing_Tables.sit.hqx
[Sid19] Oppenheimer Sidhu, Andrews. Inside AppleTalk 2nd Edition. Addison Wesley, 19??
[TE92] Christopher Ranch Tom Evans. A Standard for the Transmission of Internet Packets Over
AppleTalk networks [MacIP]. Technical report, Webster Computer, Novell Inc., 1992,
URL ftp://terminator.rs.itd.umich.edu/pub/macip.txt.Z
[Van91] Kurt VanderSluis. Network Management Tools. Technical report, The Network gGroup,
Inc., 1991,
URL ftp://ftp.cayman.com/pub/User_Conference_Notes/VanderSluis.sit.hqx
346
347
PID
362
363
364
0.0
0.0
0.0
TT
Aug 03 04
Aug 03 05
Aug 03 06
TIME COMMAND
0:00.04 /usr/sbin/getty /dev/tty04 c
0:00.04 /usr/sbin/getty /dev/tty05 c
0:00.04 /usr/sbin/getty /dev/tty06 c
Le programme getty congure les parametres de la ligne (vitesse, parite, etc.), ache un beau
message puis attend qu'un utilisateur se manifeste. Autrement dit, il se met en veille en attendant
une entree/sortie, c'est-a-dire en ne consommant aucune ressource CPU.
Lorsqu'un utilisateur se presente et tape son nom de login, getty se reveille et saisit ce nom.
E ventuellement, si l'utilisateur avait appuye sur la touche BREAK de son terminal, getty aurait
recongure la ligne avec une autre vitesse. Le processus est donc maintenant en possession du nom.
Il passe alors la main a un autre programme, login, sans generer de nouveau processus (lancement
par exec() qui recouvre le processus courant) :
% ps -edf
USER
[...]
root
root
root
[...]
PID
362
363
364
0.0
0.0
0.0
TT
Aug 03 04
Aug 03 05
Aug 03 06
TIME COMMAND
0:00.04 /usr/sbin/getty /dev/tty04 c
0:00.09 login besancon
0:00.04 /usr/sbin/getty /dev/tty06 c
Le programme login est charge de valider l'utilisateur. Il invite donc l'utilisateur a entrer son
mot de passe, le lit, le chire et le compare a la version placee dans /etc/passwd (dans le schema
traditionnel). Si les versions chirees concordent, les etapes suivantes sont alors realisees :
348
, Sur les systemes d'origine Berkeley, login autorise l'admission si le chier /etc/nologin n'est
,
,
,
,
,
,
pas present. Si ce chier est present, le contenu est ache et la connexion est rompue ;
Sur les systemes utilisant le mecanisme d'expiration des mots de passe (password aging), si la
limite est passee, login force le changement du mot de passe ;
Le programme login enregistre le nom de l'utilisateur dans les chiers /etc/utmp (liste des
utilisateurs connectes) et /etc/wtmp (liste des dernieres connexions) ;
Le programme login change le proprietaire et le groupe du processus courant ;
Sur les systemes d'origine Berkeley, login ache, a la condition que l'utilisateur n'ait pas de
chier ou de directory $HOME/.hushlogin, le contenu du chier /etc/motd et un message si
du courrier est en attente ;
Le programme login initialise des variables d'environnement (HOME, PATH, etc.) ;
Le programme login passe alors la main au shell de l'utilisateur, sans changer le processus
(lancement par exec()) :
% ps -edf
USER
[...]
root
besancon
root
[...]
PID
362
363
364
0.0
0.0
0.0
TT
Aug 03 04
Aug 03 05
Aug 03 06
TIME COMMAND
0:00.04 /usr/sbin/getty /dev/tty04 c
0:00.78 -bash (bash)
0:00.04 /usr/sbin/getty /dev/tty06 c
Le shell demarre alors. Comme il s'agit toujours du m^eme processus, son pere direct est toujours
le processus numero 1 c'est-a-dire init.
Lorsque login lance le shell (par exemple bash), il le fait en modiant le nom de la commande
qui sera ache par la commande ps, c'est-a-dire en inserant un tiret en premiere position (en reprenant le m^eme exemple : -bash). Il s'agit d'une convention entre login et les shells qui a pour but
d'indiquer aux shells qu'il s'agit d'un debut de session. Le shell est dit alors ^etre un shell de login
interactif. Suivant les shells, certains chiers de conguration seront consultes, des chiers de conguration globaux d'abord puis des chiers d'initialisation personnels. Par exemple /etc/profile
puis $HOME/.profile pour ksh. Les chiers d'initialisation globaux sont tres interessants : ils permettent d'une part de simuler facilement ce que ne fait pas login sur les systemes d'origine AT&T,
et d'autre part d'ajouter des services supplementaires tels que la determination du type de terminal
ou l'interdiction de connexions multiples, etc. Ces chiers etant speciques a chaque shell, on se
reportera aux pages de manuel de ceux-ci pour plus de renseignements.
Lorsque l'utilisateur se deconnecte, le processus init detecte la terminaison d'un de ses ls.
Comme il a une table des processus qu'il a lances, il est a m^eme de conna^tre la ligne correspondant
a l'utilisateur qui s'est deconnecte. Il actualise les chiers /etc/utmp et /etc/wtmp, puis regenere
un nouveau processus pour getty.
Si un probleme intervient dans cette sequence (mauvais nom d'utilisateur, deconnexion du modem eventuel avant la n normale, ou toute autre raison), le processus se termine prematurement.
Pour init, rien n'est change : il detecte la terminaison d'un de ses ls et procede toujours au
nettoyage habituel.
349
AT&T
% stty -everything
#2 disc;speed 9600 baud; 66 rows; 80 columns
erase = ^?; werase = ^W; kill = ^U; intr = ^C; quit = ^ ; susp = ^Z
dsusp = ^Y; eof = ^D; eol <undef>; eol2 <undef>; stop = ^S; start = ^Q
lnext = ^V; discard = ^O; reprint = ^R; status <undef>; time = 0
min = 1
-parenb -parodd cs8 -cstopb hupcl cread -clocal
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc
ixon ixany -ixoff imaxbel
isig icanon -xcase echo echoe -echok -echonl -noflsh -mdmbuf -nohang
-tostop echoctl -echoprt echoke -altwerase iexten -nokerninfo
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tabs -onoeot
BSD
% stty -a
speed 9600 baud, 66 rows, 80 columns; line = 2
-parenb -parodd cs8 -cstopb -hupcl cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc
ixon ixany -ixoff imaxbel
isig iexten icanon -xcase echo echoe echok -echonl -noflsh -tostop
echoctl -echoprt echoke
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel
erase kill
werase rprnt flush lnext susp
intr
quit
stop
eof
^?
^U
^W
^R
^O
^V
^Z/^Y ^C
^
^S/^Q ^D
La commande stty permet aussi d'agir sur une grande quantite de parametres, decrits avec
beaucoup de details dans la page de manuel de termio sur les systemes d'origine AT&T. Ceuxci peuvent ^etre decomposes en deux categories de parametres : les parametres de liaison avec le
terminal et les parametres de comportement du pilote de terminaux.
,
,
,
,
,
,
,
Ces parametres peuvent ^etre modies dynamiquement, mais il faut faire attention : la modication est eectuee dans le pilote, mais pas dans le terminal. Si l'utilisateur se connecte a 9600 bauds,
le pilote et le terminal sont congures pour 9600 bauds. Si cet utilisateur utilise stty pour passer a
19200 bauds, le pilote dialoguera a cette vitesse, mais pas le terminal, d'ou une impossibilite totale
de communiquer. Il faut donc congurer egalement le terminal ou l'emulateur de terminal.
350
Defaut sous
System-V
Defaut sous
BSD
CTL-H
DEL
CTL-U
CTL-U
DEL
CTL-C
CTL-
CTL-
CTL-D
CTL-D
RETURN
RETURN
CTL-S
CTL-S
CTL-Q
CTL-Q
{
{
CTL-Z
CTL-Y
Signication
touche d'eacement
touche d'eacement de toute la ligne
envoi du signal SIGINT
envoi du signal SIGQUIT
n de chier sur l'entree standard
caractere de n de ligne
suspension de l'achage
reprise de l'achage
envoi du signal SIGTSTP
envoi du signal SIGTSTP
majuscules :
Certains vieux terminaux (essentiellement les teletypes) n'ont pas la possibilite de saisir
des caracteres minuscules, ce qui est tres genant sur le systeme UNIX. Les gettys de tous
les UNIX (m^eme les plus recents) pensent qu'ils ont aaire a ce genre de terminaux si le
nom de login est entierement en majucules. Dans ce cas, getty au pilote de terminaux
de :
, convertir les caracteres minuscules en majuscules lors de leur saisie et de leur
achage ;
, convertir les caracteres majuscules en \ suivi de la lettre majuscule lors de leur
saisie et de leur achage ;
traitement des caracteres de n de ligne :
Les caracteres de n de ligne, retour-chariot (CR, ou carriage return) ou avance-papier
(LF, ou line feed), peuvent ^etre traduits au vol. Par exemple, la plupart des terminaux
nissent les lignes par CR-LF, alors qu'UNIX attend simplement le caractere LF. Le
pilote eectue la traduction au fur et a mesure que les caracteres sont tapes.
delais :
Les teletypes ne fonctionnent pas a la vitesse de l'unite centrale. Lorsque le pilote
envoie des caracteres, il faut qu'il respecte certains delais lorsque la t^ete d'impression
se deplace.
canonisation et echo :
Normalement, les caracteres tapes sont immediatement aches a l'ecran et conserves
en memoire par le pilote tant qu'une n de ligne n'a pas ete tapee. Cela permet de :
, eectuer localement certaines corrections (erase ou kill par exemple) ;
, diminuer la charge du systeme dans la mesure ou le processus lecteur n'est pas
reveille a chaque fois qu'un caractere est tape par l'utilisateur.
Il arrive quelquefois que ce comportement ne soit pas le comportement desire. Par
exemple, l'editeur vi, lorsque l'utilisateur tape le caractere x, detruit immediatement
351
, il faut que le systeme UNIX le supporte : peut-on creer des chiers avec des noms accentues
par exemple ?
, il faut que les outils (shells, editeurs de texte, etc.) le supportent ;
, il faut que le terminal le supporte : on doit pouvoir saisir et visualiser les caracteres accentues
que l'on saisit.
, il faut que le driver de terminaux soit congure ad-hoc :
, caracteres sur 8 bits (en general par stty pass8 ou stty cs8) ;
, pas de parite (en general par stty -parenb) ;
, pas de troncature (strip) du huitieme bit (en general par stty -istrip).
L'etape de loin la plus dicile, par experience, est la premiere etape. Les autres sont beaucoup
plus simples.
352
[...]
##
## This entry is for high speed modems. Most of these tend to always
## communicate to the cpu at 19200, regardless of the connection speed.
##
19200
# B19200 HUPCL IGNPAR PARENB ICRNL IXON OPOST ONLCR CS7 CREAD
ISIG ICANON ECHO ECHOK PARENB ISTRIP IXANY TAB3
# B19200
SANE CS7 PARENB ISTRIP IXANY TAB3 HUPCL
#login: #19200
##
## This entry is used for the console
##
console # B9600 SANE CLOCAL CS8 ISTRIP IXANY TAB3 HUPCL
# B9600 SANE CLOCAL CS8 ISTRIP IXANY TAB3 HUPCL
#Console Login: #console
[...]
Chaque type de ligne est decrit par une entree suivant le format :
nom # modes-initiaux # modes-finaux # message # nom-suivant
champ nom
Le premier constituant est le nom de l'entree. Ce nom sert a getty pour trouver l'entree
dans correspondant au type de ligne a surveiller. Ce nom est passe en parametre dans
/etc/inittab ; pour la console pr
ecedente, cela donne :
% cat /etc/inittab
[...]
cons:012456:respawn:/etc/getty -h console console
[...]
champ modes-initiaux
Le deuxieme constituant est la conguration initiale du pilote, c'est-a-dire une suite
de mots-clefs comparables a ceux de stty, mais denis dans le mecanisme termio (cf.
/usr/include/sys/termio.h et la page de manuel de termio(7));
champ modes-finaux
Le troisieme constituant est la conguration du driver a installer lorsque getty a reconnu le nom d'utilisateur et s'appr^ete a passer la main a login ;
champ message
Le quatrieme constituant est le message d'invite a acher sur le terminal ;
champ nom-suivant
Le cinquieme constituant est le bouclage : lorsque l'utilisateur appuie sur la touche
BREAK, getty consid
ere qu'il s'agit d'une demande de changement de vitesse. Il recommence alors a l'entree indiquee, permettant ainsi a l'utilisateur de se connecter a la
nouvelle vitesse.
Lorsque les parametres du terminal sont connus (par lecture de la notice et conguration ad
hoc), l'administrateur peut passer a la modication de ce chier. Si la conguration est totalement
nouvelle1 , le plus simple est de prendre une entree existante, de la recopier et de la modier en lui
donnant un nouveau nom et les nouveaux parametres.
1
Si la conguration est identique a une conguration existante, il n'y a evidemment pas besoin
de modier ce chier.
353
An de verier que les entrees sont correctes et qu'il n'y a pas d'incoherence, on utilisera
la commande getty -c /etc/gettydefs qui verie le chier /etc/gettydefs. Une incoherence
pourrait se reveler tres grave : si un # manque a l'appel, toutes les entrees ulterieures deviennent
fausses. Si l'entree modiee est la premiere, cela signie que plus personne, m^eme pas root, ne peut
se connecter sur le systeme. Il n'y a alors plus qu'a arr^eter brutalement le systeme et redemarrer
en mode mono-utilisateur, ou se connecter par le reseau si c'est possible.
console vt100
ou /dev/tty02 est le nom du chier special correspondant a la ligne du terminal, ou console
designe l'entree dans /etc/gettydefs et vt100 correspond au type du terminal (tel que deni
dans le systeme termcap ou terminfo).
Une fois cette ligne ajoutee, il faut indiquer a init que son chier de conguration a ete modie.
Pour cela, il faut utiliser la commande telinit q. A ce moment, le message d'invite doit appara^tre
sur le terminal.
, la lecture du chier /etc/ttytype, puisqu'il n'y a pas d'argument sur la ligne de commande,
pour determiner le type de terminal attache a la ligne courante ;
L'utilisation de tset suppose que le chier /etc/ttytype est tenu a jour. Ce chier se compose de
lignes au format type ligne ou l'on a :
type
ligne
Par exemple :
vt100
vt100
console
tty02
354
/etc/gettytab
#
# The default gettytab entry, used to set defaults for all other
# entries, and in cases where getty is called with no table name
#
default:\
:ap:\
:im=\r\n\
\r\n
Big Joe's Motuary Corporation...\
\r\n
THIS NETWORK OF COMPUTERS IS PROTECTED BY A SECURITY SYSTEM.\
\r\n
THE LAW PROHIBITS UNAUTHORIZED USE.\
\r\n
VIOLATORS WILL BE PROSECUTED UNDER APPROPRIATE LOCAL OR COUNTRY LAWS.\
\r\n:\
:lm=\r\nIf authorized, please login\72 :sp#9600:
#
# This is a new entry to internationalize the console. It needs to be
# 8 bit clean so that ISO 8859 characters can be displayed without
# the window system.
#
cons8:\
:p8:lm=\r\n%h login\72 :sp#9600:
modem:\
:sp#9600:p8:crtscts
La premiere entree est l'entree par defaut. Le nom default est obligatoire. Toutes les autres
entrees, lorsqu'une valeur n'est pas speciee, prennent la valeur denie ici comme valeur par defaut.
Dans cette entree, on denit les cha^nes de caracteres qui seront achees avant2 la demande de
nom de login (im=. . .) et au moment de la demande du nom de login (lm=. . .) (certains systemes
imposent des limitations au niveau de la longueur de la cha^ne achable). On peut utiliser %h et
%t pour d
esigner dans la cha^ne a achier les noms de la machine et du terminal.
,
2
3
355
Par exemple :
console
ttya
ttyb
[...]
ttyp0
ttyp1
"/usr/etc/getty cons8"
"/usr/etc/getty modem"
"/usr/etc/getty std.9600"
sun
vt100
unknown
on local secure
off local
off local secure
none
none
network
network
off secure
off secure
Le mot-clef secure indique que root est autorise a se connecter sur ce port. Par defaut, il n'est
pas autorise a se connecter. L'exemple precedent (un extrait du chier /etc/ttytab de SunOS
uniquement modie pour la ligne ttya) n'est pas tres prudent dans la mesure ou l'on autorise
les connexions reseau pour root ; dans la pratique, on retirera toutes les entrees secure pour les
pseudo-terminaux ttypXX.
Une fois cette conguration terminee, il faut signaler a init qu'il peut relire sa conguration ;
pour cela, on utilisera kill -1 1.
20.4.1 Principe
La gestion des terminaux alphanumeriques se resume a des outils utilisant une librairie nommee
curses (libcurses.a). Cette librairie permet la creation de programme dits pleine page parce que
l'on peut adresser n'importe quel caractere de l'ecran a volonte.
Etant donne qu'UNIX est, par essence, non lie a un constructeur, cette librairie doit ^etre capable
de gerer plusieurs types de terminaux (les commandes de bas niveau de contr^ole d'un terminal
VT100 ne sont pas les m^emes que pour une console Wyse, par exemple).
Le type du terminal utilise par une personne connectee est place dans la variable TERM. Normalement, cette variable est initialisee lors de la connexion (voir les sections consacrees a l'ajout
d'un terminal). Il est tentant pour certains utilisateurs d'initialiser la variable TERM dans leur chier
.profile ou
equivalent. C'est une tres mauvaise idee car si l'utilisateur se connecte un jour sur un
autre terminal, son environnement sera completement fausse. La bonne solution est de laisser faire
le systeme lorsqu'il est bien congure.
356
Cette variable TERM sert donc aux outils comme more, vi, top, talk, etc. Si elle n'est pas
initialisee, ces outils refuseront de demarrer, ou rentreront dans un mode degenere qui les rendra
tres peu utilisables.
357
Tel que deni, l'utilisateur peut initialiser sa variable TERM avec la cha^ne m1b, minitel. Pour
dechirer la denition, se reporter au manuel du terminal et a la page de manuel de termcap(5).
L'utilisation du chier /etc/termcap est tres facile du fait que le chier est en clair, et qu'il est
presque aise d'ajouter une nouvelle denition. En revanche, la description de tous les terminaux
est gourmande, et un chier relativement complet se situe entre 100 et 200 Ko. Cette taille est
penalisante car toute operation d'edition du plus petit chier se traduit par une recherche prealable
du terminal courant dans cette base.
Commande tic
Commande captoinfo
/usr/bin/tic
Commande untic
{
{
{
{
/usr/bin/tic
/usr/bin/untic
/usr/bin/captoinfo
/bin/tic
/bin/tic
/usr/bin/tic
/usr/bin/tic
{
{
/usr/5bin/tic
/bin/tic
{
{
{
{
{
/bin/captoinfo
{
{
/usr/bin/captoinfo
/usr/bin/captoinfo
{
{
/usr/5bin/captoinfo
/bin/captoinfo
358
Notons que sur certains systemes, un outil bien pratique existe pour convertir une description
termcap en une description terminfo : il s'agit de captoinfo. Par exemple, pour l'entree minitel
precdente, la denition5 donnee par captoinfo est :
m1b|minitel,
mir, xon,
cols#80, lines#24,
bel=^G, blink=\E[5m, bold=\E[1m, clear=\E[H\E[2J\E[4l,
cr=\r, cub=\E[%p1%dD, cub1=\b, cud=\E[%p1%dB, cud1=\n,
cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH,
cuu=\E[%p1%dA, cuu1=\E[A, dch=\E[%p1%dP, dch1=\E[P,
dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K,
il=\E[%p1%dL, il1=\E[L, ind=\n, is2=\E[24;1H, kbs=\b,
kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
rev=\E[7m, rf=/usr/lib/tabset/vt100, rmir=\E[4l,
rmkx=\E[?1l\E>, rmso=\E[m, rmul=\E[m,
rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sgr0=\E[m,
smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m, smul=\E[4m,
359
360
361
Welcome to caferoyal
Login
Passwd
OK
Clear
Options
Help
excalbur.ens.fr
362
Nous nous attacherons ici a expliquer le fonctionnement et la conguration de l'utilitaire standard "xdm".
,
,
,
,
363
xdm
xdm
thread
Accept
Reset du
serveur X
Manage
fork()
XOpenDisplay()
fen^etre de login
session de travail
n de la session
XCloseDisplay()
Phase Accept
Le xdm contacte donne sa reponse a la requ^ete Request. La reponse est Accept ou
Decline suivant le cas (on peut par exemple envisager une reponse Decline dans le cas
ou le xdm gere deja un nombre susant de tX).
Phase Manage
Le tX annonce qu'il est pr^et a accepter toute demande de connexion issue du xdm.
Phase Initiate Session
Le process xdm utilise maintenant le protocole X classique. La phase de communication
utilisant le protocole XDMCP est terminee. Le xdm essaye un classique XOpenDisplay()
a destination du tX et si tout se passe bien, une fen^etre de login apparait sur l'ecran du
tX. Il est a noter que le process xdm creant cette fen^etre de login est issu d'un fork()
du process xdm tournant sur la machine contacte. De cette facon, le process principal
xdm peut continuer
a rester en attente de demande de connexion. Le process forke est
reconnaissable au nom qu'il porte; si le tX s'appelle nestor, alors le process xdm forke
a pour nom -nestor:0.
364
/usr/lib/X11/xdm/xdm-errors
/usr/lib/X11/xdm/xdm-pid
/usr/lib/X11/xdm/Xservers
true
/usr/lib/X11/xdm/Xsetup_0
/usr/lib/X11/xdm/GiveConsole
/usr/lib/X11/xdm/TakeConsole
/usr/lib/X11/xdm/Xresources
/usr/lib/X11/xdm/Xsession
false
Elle indique le chier stockant les erreurs pouvant arriver ; c'est donc un chier a
consulter en cas de probleme.
DisplayManager.pidFile
La ressource pidFile
XDMDIR=/usr/lib/X11/xdm
if [ -f $XDMDIR/xdm-pid ]; then
pid=`cat $XDMDIR/xdm-pid`
/bin/kill -TERM $pid
/bin/rm $XDMDIR/xdm-pid
fi
Une chose a conna^tre sur xdm est son comportement vis a vis des signaux :
SIGTERM
provoque la terminaison du process xdm. Toutes les sessions qu'il gere seront
tuees dans la foulee.
SIGHUP
provoque la relecture du chier de conguration de xdm.
xdm peut donc ^
etre tue a tout moment en lui envoyant un SIGTERM. Il est cependant plus
facile d'utiliser le script precedent qui vous evite d'avoir a chercher le pid du process a
tuer.
365
DisplayManager.servers
Cette ressource indique un chier qui specie les noms des DISPLAYs qu'il doit gerer
explicitement. C'est le cas pour un serveur X lance sur une station de travail, pour
des terminaux X qui ne supporteraient pas le protocole XDMCP mais ces terminaux
devraient ^etre de plus en plus rares si bien qu'il ne reste que les stations de travail de
concernees.
La syntaxe de ce chier est la suivante :
ou
display-name
display-class
est optionnel.
display-type
prend l'une des 2 valeurs local ou foreign suivant que le serveur concerne
est local ou non a la machine tournant xdm (auquel cas, il est vraisemblable
que cela soit le lancement d'un serveur X en local sur la station).
Xserver [args...]
SUN-MONO
VISUAL-V640
local
foreign
/usr/bin/X11/Xsun :0
Son r^ole est de permettre a l'utilisateur de se logger m^eme si sa conguration de travail
qui theoriquement est lancee au demarrage contient une erreur ; au lieu de se retrouver
delogge, il se retrouve alors avec une conguration peut{^etre minimale (dependante
de chaque site) mais fonctionnelle (enn, on l'espere pour lui !). Pour cela, il sut a
l'utilisateur de valider son mot de passe par la touche F1 et non RETURN.
setup
366
bring up other windows that should appear on the screen along with the
Login widget.
If DisplayManager.DISPLAY.grabServer is set, Xsetup will not be able
to connect to the display at all.
startup, reset
En fait, il faut associer a ces deux ressources la ressource session. Alors, ces trois
ressources emulent le processus shell d'un terminal ASCII. Ils sont lances successivement apres l'identication de l'utilisateur ; startup correspondrait en quelque sorte
au .login de l'utilisateur, reset au .logout et session a la session de travail sous le
shell.
Les shell{scripts designes par startup et reset sont executes au nom de root pour
permettre la realisation des t^aches d'administration systeme et session est execute
avec l'uid de l'utilisateur.
session
Cette ressource indique un shell{script dont le r^ole est primordial quand on utilise xdm.
Par defaut, le shell-script est /usr/lib/X11/xdm/Xsession.
Le but de ce chier est double :
, il permet d'enregistrer dans un chier les messages d'erreurs generes par le shell{
script ce qui permet d'avoir une trace en cas de probleme.
Par defaut, ce chier stockant les erreurs est $HOME/.xsession-errors.
, il permet de lancer une conguration de travail sous X. Cette conguration peut
^etre celle de l'utilisateur si l'on en trouve une chez lui, sinon on lance une conguration minimale indiquee dans le shell{script.
La conguration de l'utilisateur est, conventionnellement, stockee dans le chier
executable $HOME/.xsession.
Voici un exemple de script session :
#!/bin/sh
# $XConsortium: Xsession,v 1.7 92/08/06 11:08:14 gildea Exp $
# redirect errors to a file in user's home directory if we can
for errfile in "$HOME/.xsession-errors" "/tmp/xses-$USER"
do
if ( cp /dev/null "$errfile" 2> /dev/null )
then
chmod 600 "$errfile"
exec > "$errfile" 2>&1
break
fi
done
case $# in
1)
case $1 in
failsafe)
exec xterm -geometry 80x24-0-0
;;
esac
esac
startup=$HOME/.xsession
resources=$HOME/.Xresources
if [ -f $startup ]; then
exec $startup
else
fi
367
if [ -f $resources ]; then
xrdb -load $resources
fi
twm &
exec xterm -geometry 80x24+10+10 -ls
&
&
&
&
368
On voit que les premiers clients sont lances en t^ache de fonds, que quelques clients
intermediaires (xrsh, xset) sont lances en premier plan mais ces clients ont la particularite de se terminer tres vite ; il ne faudrait pas que le shell{script se termine par ces
clients, car alors il nirait tout de suite et la session de travail avec. Aussi lance-t-on
a la n un client qui ne se termine pas tout de suite ; il s'agit ici d'un simple xterm ;
quand on fera exit dans le shell de ce xterm, on nira alors la session de travail sous X.
Pour eviter une deconnexion accidentelle, ce xterm est lance sous forme d'icone (option
-iconic). Ceci oblige a
ouvrir explicitement la fen^etre a la n de session pour terminer
le shell qui y tourne. Cette methode semble plus able que selectionner une quelconque
entree Exit window manager que l'on risquerait de selectionner par hasard.
21.5 La securite et X.
21.5.1 Aspects de securite dans X.
X est un systeme de multi{fen^etrage reposant sur un serveur acceptant des connexions de la
part d'applications. Le probleme consiste donc a contr^oler les demandes de connexion.
Jusqu'en X11R3, X ne prevoyait qu'un mecanisme de contr^ole au niveau de la station de travail :
sur une station de travail B, on autorisait les connexions de tout processus tournant sur la machine
A du moment que l'on avait fait xhost A sur B. C'est ce que l'on appelle le contr^
ole d'acces par
site.
Avec X11R4 est apparu un mecanisme de contr^ole plus n ; c'est un mecanisme a base d'une
cle hexadecimale devant ^etre fournie a chaque demande de connexion ; le serveur conna^t la cle
et compare celle fournie par l'utilisateur a celle qu'il detient ; si cela concide, la connexion est
acceptee. C'est ce que l'on appelle le contr^ole d'acces par utilisateur.
X11R5 apporte deux nouvelles methodes de transmission de la cle. mais dans le principe cela
reste la m^eme chose, la seule dierence etant que la cle, au lieu d'^etre transmise en clair au serveur,
peut ^etre chiree selon diverses methodes.
Le mecanisme de X11R4 est connu sous le nom de MIT-MAGIC-COOKIE-1, les mecanismes de
X11R5 sous les noms XDM-AUTHORIZATION-1 et SUN-DES-1. On parle de magic{cookie pour
la cle hexadecimale.
369
magic{cookie
xdm
host
~/.Xauthority
Serveur X
La protection de la session X repose alors entierement sur le niveau de s^urete du lesystem. Les
droits d'acces du chier .Xauthority sont rw-------.
Lorsqu'un client X est lance, il demande une connexion au serveur via un appel a
Cette fonction va consulter le chier .Xauthority de l'utilisateur qui execute le client et recupere le magic{cookie associe au DISPLAY concerne. Si le magic{cookie est le
m^eme que celui du serveur, la connexion est acceptee ; dans le cas contraire, elle est refusee puisque
consideree comme une tentative de violation de la session (voir la gure qui suit).
XOpenDisplay().
magic{cookie A
Serveur X
reseau
magic{cookie A
client 1
/home/bob/.Xauthority
magic{cookie B
client 2
/home/joe/.Xauthority
magic{cookie A
host
magic{cookie B
370
Le probleme que l'on voit surgir avec ce mecanisme se pose lorsque l'utilisateur de la session desire lancer legitimement un client depuis une machine n'ayant pas d'acces NFS au chier contenant
le magic{cookie. Il dispose alors de deux methodes pour y arriver :
1. l'utilisateur utilise la commande xhost, autorisant alors tous les utilisateurs de la machine
depuis laquelle il va lancer son client a acceder eux aussi a son DISPLAY.
2. il transmet le magic{cookie de la session sur cette machine. Pour cela, il dispose de la commande
xauth et la manipulation se ram
ene toujours a quelque chose equivalent a :
xauth extract - $DISPLAY | rsh remotehost xauth merge -
Si problemes il y a, ceux{ci sont, une fois de plus, ramenes a des problemes classiques d'autorisation UNIX (chier .rhosts. . .).
A noter que le magic{cookie peut ^etre stocke ailleurs que dans le chier $HOME/.Xauthority.
Dans ce cas, on positionne la variable d'environnement XAUTHORITY de facon a ce qu'elle pointe
sur le chier ad-hoc. Toutes les operations decrites precedemment, notamment le fonctionnement
de XOpenDisplay(), continuent de marcher puisque la variable XAUTHORITY, si elle existe, est prioritaire sur le chier $HOME/.Xauthority.
A noter que le chier Wraphelp.c avec les routines DES non exportables est disponible, malgre
tout (pour les citoyens americains), sur export.lcs.mit.edu. Il s'agit du chier /etc/help.
371
Attention, ce chier est compresse mais son nom ne le dit pas ; il faut donc faire quelque chose
comme :
uncompress < help > mit/lib/X/Wraphelp.c
L'ajout du chier dans l'arbre des sources X11R5 ne sut pas a ajouter ce mecanisme dans les
librairies X. Il faut ajouter au chier mit/config/site.def la ligne :
#define HasXdmAuth YES
DisplayManager.randomFile
Fichier a partir duquel on genere une graine pour le generateur aleatoire par une sorte
de checksum. En principe, on prend un chier qui evolue souvent du genre /dev/mem
(auquel on peut acceder puisque xdm est lance au nom de root).
DisplayManager.DISPLAY.grabServer
Specie si xdm doit grabber
DisplayManager.DISPLAY.authorize
Indique si xdm doit utiliser les
DisplayManager.DISPLAY.authName
DisplayManager.DISPLAY.authFile
Nom d'un chier contenant des magic{cookies pour ^etre utilises avec des serveurs tournant sur des stations de travail (cf section 21.5.2.1 [Cas d'un serveur local], page 370).
DisplayManager.authDir
Directory ou seront stockes les chiers de magic{cookies pour des terminaux X.
DisplayManager.DISPLAY.userAuthDir
372
, station de travail dont l'ecran est le seul DISPLAY manage par xdm
, necessite entre 2 sessions utilisateur de pouvoir garder a l'ecran les messages d'erreurs ou autres
Application
xconsole
Fen^etre de login
Application
Passwd:
xload
excalbur.ens.fr
On conserve les pids des 2 process dans /etc/xdm/server/pids de facon a les tuer via le shell{
script DisplayManager.DISPLAY.startup suivant :
#!/bin/sh
exec 2> /dev/null
[ -f /etc/xdm/server/pids ] && kill -TERM `cat /etc/xdm/server/pids`
rm -f /etc/xdm/server/pids
373
Dernier point : pour pouvoir lancer ces applications, il faut que la valeur de la ressource
soit false.
DisplayManager.DISPLAY.grabServer
21.6.2 Terminaux X.
Nous faisons des le depart l'hypothese que ces terminaux X ont un serveur posterieur a X11R4
de sorte qu'ils supportent le protocole XDMCP.
Voici le scenario de l'exemple :
, nous disposons de terminaux X riri, fifi, loulou (que nous designerons par la suite par les
gontran
donald
riri
picsou
fifi
loulou
, nous souhaitons que les sessions de travail des utilisateurs se loggant sur les castors puissent
Pour orir un choix a l'utilisateur, nous utiliserons un chooser. Le CHOOSER est un programme
decrit par la ressource DisplayManager.DISPLAY.chooser qui doit permettre a l'utilisateur de faire
un choix parmi les xdms proposes. Le chooser standard fourni en X11R5 par le MIT, ressemble a la
chose suivante :
Liste des hosts susceptibles daccueillir une session XDM.
excalibur
hobbes
cancel accept
Willing to manage
Willing to manage
ping
374
A signaler que lorque le chooser est ache sur le tX, aucun mecanisme de protection n'est active.
On peut comprendre cela en gardant a l'esprit que cette etape ne consiste qu'a selectionner un xdm.
S'il fallait rentrer un quelconque mot de passe, des problemes pourraient surgir car on peut tres
bien espionner le serveur pendant cette phase (c'est d'ailleurs gr^ace a cela que le dump d'ecran
ci{dessus a ete realise).
Commencons par l'endroit ou il y a le moins de conguration a faire : les terminaux X. Il faut
simplement leur indiquer le process xdm a contacter et la methode pour le contacter :
gontran
on congure gontran de facon a ce qu'il contacte daisy via des requ^etes de type Query
(en general denote direct dans les congurations des constructeurs de tX)
castors juniors
arbitrairement on choisit le xdm a contacter comme etant celui de donald mais les
requ^etes seront de type IndirectQuery (en general denote indirect dans les congurations des constructeurs de tX)
En quoi consiste le type IndirectQuery ? Eh bien, c'est le type a fournir a xdm pour que celui{
ci contacte une liste de certains autres xdms qu'il connait comme etant susceptibles d'accepter
la demande de session du tX. Le premier xdm joue donc un r^ole intermediaire. Il transmettra les
reponses recueillies au tX et l'utilisateur fera son choix. Schematiquement, les echanges de messages
sont a peu pres les suivants :
daisy
donald
picsou
xdm
xdm
xdm
4 3
3 4
TCP/IP
6
daisy
donald
picsou
willing
willing
willing
5
daisy
donald
picsou
willing
willing
willing
2
daisy
donald
picsou
castor junior
Phase 1
xdm
Phase 2
Phase 3
Phase 4
Phase 5
Phase 6
375
Le process xdm contacte lance le chooser (le chooser est un petit programme qui va
permettre a l'utilisateur de choisir sur quelle machine s'executera la session de l'utilisateur ; voir un peu plus loin la gure) et l'ache sur le tX avec les noms des xdms
susceptibles d'accepter la session de travail.
Le xdm de donald lance des ForwardQuery vers les autres xdms.
Les xdms pouvant accepter la requ^ete repondent ; les autres se taisent.
Les resultats sont transmis au chooser qui les ache sur le tX.
L'utilisateur a choisi une machine (daisy). On se retrouve alors dans le cas classique
de communication XDMCP (cf section 21.3 [Le protocole "X Display Management" :
XDMCP], page 362).
Analysons maintenant les chiers de conguration de xdm permettant tout cela.
D'abors, xdm tourne sur les 3 machines. Sur les 3 machines ont ete positionnees les ressources DisplayManager.accessFile (par defaut /usr/lib/X11/xdm/Xaccess). Les chiers pointes contiennent les noms des DISPLAYs autorises a se connecter via des requ^etes Query ainsi que
pour certains DISPLAYs les noms de xdm a contacter par ForwardQuery.
Ainsi pour nos 3 machines, nous avons :
picsou
% cat Xaccess
## Direct/Broadcast query entries:
##-------------------------------donald
## Indirect query entries:
##------------------------
daisy
% cat Xaccess
## Direct/Broadcast query entries:
##-------------------------------donald
gontran
## Indirect query entries:
##------------------------
donald
% cat Xaccess
## Direct/Broadcast query entries:
##-------------------------------donald
## Indirect query entries:
##-----------------------%RELATIVES donald\
picsou\
daisy
riri
fifi
loulou
CHOOSER %RELATIVES
CHOOSER %RELATIVES
CHOOSER %RELATIVES
376
riri
CHOOSER %RELATIVES
signie que les xdms a contacter pour riri sont ceux de la macro RELATIVES et l'on proposera a
l'utilisateur d'en choisir un via l'intermediaire du CHOOSER.
Les 3 chiers accessFile autorisent toutes les requ^etes de type direct venant de donald ; il en
est ainsi car le tX fait un IndirectQuery a destination de donald qui lui doit forwarder la requ^ete
mais en mode direct (d'apres XDMCP) vers les autres xdms ; c'est donc bien donald qui doit faire
partie des entrees autorisees en mode direct sur les autres machines. A signaler que donald doit
s'autoriser lui{m^eme en mode direct.
Signalons que si l'on positionne la ressource DisplayManager.DISPLAY.terminateServer a la
valeur true, lorsque l'utilisateur se deloggera, on se retrouvera face au chooser et non face a la
fen^etre de login. Si la ressource etait mise a false, on reviendrait a la fen^etre de login et pour
revenir au chooser il faudrait alors emettre un SIGTERM via C-\ dans cette fen^etre (cf la ressource
xlogin.Login.translations du chier DisplayManager.DISPLAY.resource et plus particuli
erement le binding de abort-session()).
21.7 Bibliographie.
Le lecteur peut se reporter aux articles suivants :
[Bra91a] Mike Braca. Conguring X Display Management. Unix{World, 1991.
[Bra91b] Mike Braca. X Display Management. Unix{World, 1991.
[Gro93] Claude Gross. Les outils de securite sur X11 pour les utilisateurs. Le Micro Bulletin, le
journal des usagers de l'informatique dans la Recherche, 1993.
[Mui92] Linda Mui. Improving X Windows Security. Unix{World, 1992.
377
378
379
, La station obsolete retrouve une utilite, tout au moins pour quelques temps ;
, De l'administration d'une station de travail, on passe a l'administration d'un terminal X qui
Le logiciel xkernel-2.0 est disponible sur le site ftp.ctr.columbia.edu sous le nom /Xkernel.
Il fonctionne sur les stations Sun3 (architectures sun3 et sun3x), Sun i386, Sun4 (architectures
sun4, sun4c) et sous Linux.
(routage, broadcast. . .) puis lance un serveur X qui emet des requ^etes XDMCP cherchant donc sur
le reseau un xdm qui le gerera.
En pratique, toute station de travail supportant le protocole de boot du tX (bootparams, disponible en sources) peut servir de serveur de chiers pour le tX.
380
etc/fstab
La version 2.0 de xkernel permet de se passer d'acceder via NFS a des partitions sur
le serveur. La principale raison pour laquelle on avait besoin de cela avec les versions
anterieures etait de devoir acceder localement aux chiers stockant les fontes. Ceci est
desormais inutile en utilisant le serveur de fontes present dans X11R5 et X11R6. Il sut
de preciser un serveur de fontes et on accede a partir de ce moment la via TCP/IP aux
fontes.
Voici le bout de code de sbin/init s'occupant du serveur de fontes est le suivant :
[...]
FONTPATH=/usr/lib/X11/fonts; export FONTPATH
if [ -d $FONTPATH ]; then
# Hmm, we have a font directory, so we must be using NFS for fonts.
for i in $FONTPATH/*; do
if [ -f $i/fonts.dir ]; then
FP="${FP:+$FP/,}$i"
fi
done
else
FP="tcp/fontserver:7000/all"
fi
[...]
XSRVCMD="$Xserver -fp $FP -co /usr/lib/X11/rgb -pn $XDMCMD"
[...]
Pour que l'on ait le moins possible a modier ce chier sbin/init, on remarquera que
le serveur de fontes est connu sous le nom fontserver que l'on devra donc trouver au
niveau de etc/hosts :
##
## Les noms 'primaryxdmhost' et 'fontserver' sont utilis
es dans le fichier
## 'sbin/init' pour lancer 'xdm' et 'fs' respectivement. Ils sont donc
## importants.
##
129.199.115.16 cubitus.lps.ens.fr
cubitus
129.199.115.29 tournesol.ens.fr
tournesol fontserver primaryxdmhost
129.199.115.40 excalibur.ens.fr
excalibur
129.199.115.52 goofy.lps.ens.fr
goofy
Si, pour une raison ou une autre, le serveur de fontes cessait de fonctionner, le tX ne
booterait plus (qu'on se le dise).
etc/hosts
Pour la m^eme raison que precedemment, a savoir eviter de modier le chier sbin/init,
on trouvera dans le chier etc/hosts une reference a la machine primarysdmhost a
cause des lignes suivantes de sbin/init :
[...]
# change -indirect to -query if desired, below.
XDMCMD="-query primaryxdmhost"
[...]
381
etc/ifconfig_cmd.*
Le package xkernel tournant principalement sur des machines de type Sun3 pour
lesquelles il y eut divers modeles de cartes Ethernet, on est oblige de faire ressortir cette
dierence au niveau de certains chiers. Le chier etc/init congure les interfaces
reseau de la facon suivante :
for f in /etc/ifconfig_cmd.*
do
sh -c $f
done
Si l'on partage donc l'arborescence xkernel entre divers Sun3, on aura donc a faire
coexister dierents chiers etc/ifconfig_cmd.*, comme les suivants :
% cat ifconfig_cmd.ie0
ifconfig ie0 broadcast 129.199.119.255 netmask 0xfffff800
% cat ifconfig_cmd.le0
ifconfig le0 broadcast 129.199.119.255 netmask 0xfffff800
Leur coexistence ne pose cependant pas de probleme dans la mesure ou l'execution de
la commande ifconfig avec une interface inexistance ne produit rien si ce n'est un
message d'avertissement.
Pour nir, voici comment lancer dierents serveurs X selon le terminal X (peu importe la raison
pour laquelle on fait cela) :
# If you need to exec different Xsun depending on the host (e.g. some
# machines are color and some monochrome and you want to use the
# smaller mono-only version on the monochrome versions) you can either
# generate an extra /export/root for the color machines, or you can do
# something like:
#
case `hostname` in
cubitus*) Xserver=/Xsuns/XsunMono ; export Xserver ;;
goofy*)
Xserver=/Xsuns/Xsun
; export Xserver ;;
esac
#
-l
18:02
1994
17:22
18:00
17:27
1992
1993
18:01
Xsuns/
dev/
etc/
kernels/
sbin/
usr/
version
vmunix -> kernels/vmunix.all-suns*
tournesol:[53]:</export/root/Xkernel-2.0-sun3>ls -R
Xsuns/
dev/
etc/
kernels/ sbin/
usr/
Xsuns:
Xsun*
Xsun-cc-fswitch-pl21* XsunMono*
dev:
MAKEDEV*
audio
cgthree0
cgtwelve0
kmem
log|
nrmt9
null
rsd0a
rsd0b
version
sbus2
sbus3
tty
ttya
vmunix
382
audioctl
bwone0
bwtwo0
cgeight0
cgfour0
cgnine0
cgone0
cgsix0
cgtwo0
console
drum
dump
eeprom
fb
kbd
klog
etc:
defaultrouter
hosts
mbio
mbmem
mem
mouse
nit
nrmt0
nrmt1
nrmt8
ifconfig_cmd.ie0*
ifconfig_cmd.le0*
kernels:
version
vmunix.all-suns*
vmunix.all-suns.conf
vmunix.all-suns.desc
sbin:
clearsockets*
hostname*
ifconfig*
init*
rmt0
rmt1
rmt12
rmt13
rmt4
rmt5
rmt8
rmt9
rsd0c
rsd0d
rsd0e
rsd0f
rsd0g
rsd0h
sbus0
sbus1
protocols
services
vmunix.mono*
vmunix.mono.conf
vmunix.mono.desc
vmunix.smcolor*
intr*
message.Xterm
message.busy_loop
message.nofile
sd0a
sd0b
sd0c
sd0d
sd0e
sd0f
sd0g
sd0h
ttyb
vd
vme32
vme32d32
zero
syslog.conf
vmunix.smcolor.conf
vmunix.smcolor.desc
message.norgb
mount*
route*
sh*
shcat*
syslogd*
usr:
lib/
usr/lib:
X11/
usr/lib/X11:
rgb.dir rgb.pag
rgb.txt
On rappelle que pour qu'une station Sun (fonctionnant en tant que pure station de travail ou
en tant que terminal X sous xkernel) puisse booter en diskless, il faut avoir congurer quelques
autres chiers :
/etc/ethers
/etc/bootparams
Ce chier doit contenir les noms des partitions accessibles par la station en mode
diskless :
[...]
aristote.lps.ens.fr
cubitus.lps.ens.fr
goofy.lps.ens.fr
[...]
root=tournesol:/export/root/Xkernel-2.0-sun4
root=tournesol:/export/root/Xkernel-2.0-sun3
root=tournesol:/export/root/Xkernel-2.0-sun3
/tftpboot/*
On doit trouver dans ce directory des chiers de boot ayant pour noms les adresses IP
en hexadecimal des station associees :
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
1
1
1
1
1
1
besancon
besancon
besancon
besancon
besancon
besancon
software
software
software
software
software
software
21
21
21
21
21
21
Jan
Jan
Jan
Jan
Aug
Aug
26
26
27
27
9
9
20:43
21:20
16:01
16:02
17:11
17:11
383
384
385
Administration
ftp://ftp.umbc.edu/pub/sgi/upgrade/lisa8.ps
AppleTalk
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336, 345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
ftp://citi.umich.edu/public/netatalk/32.beta/netatalk32.beta.tar.Z
ftp://citi.umich.edu/public/netatalk/doc/netatalk arch.sit.hqx
ftp://citi.umich.edu/usr/honey/timelord-1.3-diffs
ftp://citi.umich.edu/usr/honey/timelord-bundle
ftp://ftp.cayman.com//pub/specs/kip/AA Protocol.txt
ftp://ftp.cayman.com//pub/specs/MacIP Spec #0.4.txt
ftp://ftp.cayman.com/pub/User Conference Notes/AT Routing Tables.sit.hqx
ftp://ftp.cayman.com/pub/User Conference Notes/TCPIP MACIP.sit.hqx
ftp://ftp.cayman.com/pub/User Conference Notes/VanderSluis.sit.hqx
ftp://ftp.ibp.fr/pub/appletalk/atalk/atalk-2.1/atalkad.2.1.shar.Z
ftp://ftp.ibp.fr/pub/appletalk/cap/cap60.pl196.tar.Z
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/cap-solaris-2.2
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/fyi-cap--IIg
ftp://lore.cs.columbia.edu/pub/kip.PS.Z
ftp://munnari.oz.au/mac/timelord.1.4.shar.Z
ftp://terminator.rs.itd.umich.edu/pub/macip.txt.Z
ftp://terminator.rs.itd.umich.edu/unix/netatalk/netatalk-1.3.3.tar.gz
Automount
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
. . . . . . . . . . . . . . 227
ftp://ftp.uwtc.washington.edu/pub/Docs/SunWhitePapers/automounter.ps.Z
ftp://ftp.uwtc.washington.edu/pub/Docs/SunWhitePapers/TheArtofAutomounting-1.4.ps.Z
CDROM
. ...................................................
. ........................
.............................................
..............................................
. ..........................................................
. ................................................................
ftp://ftp.hyperion.com/WorkMan/WorkMan-1.0.2.tar.gz
ftp://ftp.ibp.fr/pub/linux/sunsite/utils/disk-management/cdwrite-1.5.tar.gz
ftp://ftp.netcom.com/pub/br/bruggemn/cdrom/cdwriter.tar.Z
ftp://ftp.netcom.com/pub/br/bruggemn/cdrom/mkisofs.tar.Z
ftp://ftp.x.org/R5contrib/xcdplayer-2.2.tar.Z
ftp://ftp.x.org/R5contrib/xmcd-1.1.tar.Z
Courrier electronique
. .................................................
. ...........................................
.....................................
......................................................
ftp://ftp.ifh.de/pub/unix/mail/elm imap.patch.tar.gz
ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/bortzmeyer
ftp://ftp.mal.com/pub/pop/popclient-3.0b5.tar.gz
Disques
82
79
79
79
82
82
302
300
303
303
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40, 42
ftp://ftp.cdf.toronto.edu/pub/scsiinfo/scsiinfo-3.1.shar
ftp://ftp.cdf.toronto.edu/pub/scsiping/scsiping-2.0.shar
ftp://ftp.cdrom.com/pub/cdrom/solaris2.2 nonsuncd.tar
ftp://ftp.cdrom.com/pub/cdrom/sun cd.c
ftp://ftp.fnal.gov/pub/juke/v4 1
ftp://gatekeeper.dec.com/pub/DEC/ultrix-disktabs
ftp://ra.mcs.anl.gov/sun-managers/format.dat
386
Disquettes
. ....................................
. ..................................
..............................................................
. ...........................
ftp://ftp.freebsd.orig/pub/FreeBSD/packages-2.1/All/hfs-0.37.tgz
ftp://ftp.freebsd.orig/pub/FreeBSD/packages/emulation/hfs-0.37.tgz
ftp://ftp.inria.fr/gnu/mtools-2.0.7.tar.gz
ftp://phoenix.doc.ic.ac.uk/computing/systems/mac/sumex/cmp/suntar-205.hq
DNS
86
86
85
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
. . . . . . . . . 163
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154, 172
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169, 173
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169, 173
ftp://corton.inria.fr/NIC-FR/formulaire-domaine-court
ftp://corton.inria.fr/NIC-FR/formulaire-domaine-documente
ftp://ftp.cnam.fr/pub/Network/DNS/DNS in french.ps.Z
ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1178.txt
ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1535.txt
ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1713.txt
ftp://ftp.inria.fr/network/dns/nslook-1.4.shar.Z
ftp://ftp.jussieu.fr/jussieu/doc/local/dnsmail.ps.Z
ftp://ftp.jussieu.fr/pub/networking/bind-4.9.2.tar.gz
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/aix-and-resolvJ-comp.unix.aix.48333
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/revnslookup.sh
ftp://ftp.nikhef.nl/pub/network/host YYMMDD.tar.Z
ftp://ftp.oleane.net/pub/netinfo/Oleane/obtenir-un-domaine-fr
ftp://ftp.pop.psu.edu/pub/src/dnswalk
ftp://ftp.ripe.net/tools/dns/bind-4.9.3-docs/bog.ps.Z
ftp://ftp.rs.internic.net/domain/named.root
ftp://ftp.rs.internic.net/domain/root.zone
ftp://ftp.uu.net/networking/ip/dns/doc.2.0.tar.Z
ftp://ftp.uu.net/networking/ip/dns/resolv+2.1.1.tar.Z
ftp://ftp.uu.net/systems/sun/sun-fixes/libc pic.a.sun3.Z
ftp://ftp.uu.net/systems/sun/sun-fixes/libc pic.a.sun4.Z
ftp://ftp.vix.com/pri/vixie/bind-4.9.3-BETA26.tar.gz
ftp://ns.dns.pt/pub/dns/ddt-2.0.1.tar.gz
ftp://sh.cs.net/country codes.txt
ftp://terminator.cc.umich.edu/dns/lame-delegations
ftp://thor.ece.uc.edu/pub/sun-faq/sun-faq.general
ftp://thor.ece.uc.edu/pub/sun-faq/sun-managers.faq
Ethernet
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107, 118
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
. . . . . . . . . . . . . . 107
. . . . . . . . . . . 107
. . . . . . . . . . . . . 108
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
ftp://ee.lbl.gov/papers/bpf-usenix93.ps.Z
ftp://ftp.cs.curtin.edu.au/pub/netman/dec-alpha/etherman-1.1a.tar.gz
ftp://ftp.cs.curtin.edu.au/pub/netman/dec-mips/analyser-1.0.tar.gz
ftp://ftp.cs.curtin.edu.au/pub/netman/dec-mips/etherman-1.1a.tar.gz
ftp://ftp.cs.curtin.edu.au/pub/netman/sgi/analyser-1.0.tar.gz
ftp://ftp.cs.curtin.edu.au/pub/netman/sgi/etherman-1.1a.tar.gz
ftp://ftp.cs.curtin.edu.au/pub/netman/solaris2/analyser-1.0.tar.gz
ftp://ftp.cs.curtin.edu.au/pub/netman/solaris2/etherman-1.1a.tar.gz
ftp://ftp.cs.curtin.edu.au/pub/netman/sun4c/analyser-1.0.tar.gz
ftp://ftp.cs.curtin.edu.au/pub/netman/sun4c/etherman-1.1a.tar.gz
ftp://ftp.ieee.org/info/stds/info.stds.oui
ftp://ftp.lcs.mit.edu/pub/map/EtherNet-codes
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/geteaddr.c
ftp://ftp.navya.com/pub/vikas/nocol-4.01.tar.gz
ftp://ftp.utexas.edu/pub/netinfo/ethernet/ethernet-config-A4.ps
ftp://ftp.utexas.edu/pub/netinfo/ethernet/ethernet-faq/ethernet-faq
ftp://ftp.utexas.edu/pub/netinfo/ethernet/ethernet-guide-A4.p
ftp://ftp.utexas.edu/pub/netinfo/ethernet/ethernet-numbers/mit-ethernet-numbers.txt
ftp://ftp.utexas.edu/pub/netinfo/ethernet/misc/ethernet-bugs/metcalfe-enet-bug-columns
ftp://ftp.utexas.edu/pub/netinfo/ethernet/misc/ethernet-bugs/thaler-enet-bug-posting
ftp://ftp.utexas.edu/pub/netinfo/ethernet/misc/ethernet-sqe/sqe-test.ps
387
......................................
. ................................................
..............
. ..................................................
107
107
107
107
. ..........................................................
. ..........................................................
. ..................................................
. ........................................
. ...................................
. ........................
. .......................................................
.............................................................
. ..............................................................
. .........................................................
. .........................................................
. .........................................................
. ........................................................
180
184
179
184
182
181
185
184
184
184
184
184
184
ftp://ftp.utexas.edu/pub/netinfo/ethernet/net-read-ethernet.ps
ftp://ftp.utexas.edu/pub/netinfo/src/etherprobe.tar.Z
ftp://ftp.utexas/edu/pub/netinfo/ethernet/misc/ethernet-bugs/irish-enet-bug-posting
ftp://thor.ece.uc.edu/pub/sun-faq/FAQs/ethernet.faq
Gestion du temps
ftp://ftp.inria.fr/network/time/rdate.shar.Z
ftp://ftp.inria.fr/rfc/rfc13xx/rfc1305.tar.Z
ftp://ftp.inria.fr/system/admin/cron-3.0pl11.tar.gz
ftp://ftp.pasteur.fr/pub/Mac/Networking/ntpclient1.0.sit.hqx
ftp://ftp.univ-lyon1.fr/pub/unix/network/tcpip/xntp/clock.txt.gz
ftp://ftp.univ-lyon1.fr/pub/unix/network/tcpip/xntp/xntp3.3w.export.tar.gz
ftp://louie.udel.edu/pub/ntp/doc/algorithm.ps.Z
ftp://louie.udel.edu/pub/ntp/doc/dts3.ps.Z
ftp://louie.udel.edu/pub/ntp/doc/ntp.ps.Z
ftp://louie.udel.edu/pub/ntp/doc/rfc1119.ps.Z
ftp://louie.udel.edu/pub/ntp/doc/rfc1128.ps.Z
ftp://louie.udel.edu/pub/ntp/doc/rfc1129.ps.Z
ftp://louie.udel.edu/pub/ntp/doc/security.ps.Z
Imprimantes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
ftp://ftp.ens.fr/pub/FAQ/FAQ.solaris.Z
ftp://iona.ie/pub/plp/LPRng
IP
. ..................................
. ...............................................................
. ...............................................................
. ...............................................................
. ...............................................................
. ...............................................................
..............................
..........................................
. ..................................................
133
143
143
143
143
125
142
138
133
. ........................
. ........................
. ........................
. ..........................................................
. ....................
. ....................
. ....................
. ...................
. ........................
. .................
. .................
. ................................
...............................
.............................................
.............................................
275
275
275
273
278
278
276
275
277
275
278
272
279
277
277
ftp://ftp.ibp.fr/pub/linux/sunsite/docs/howto/mini/Virtual-Web.gz
ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1375.txt
ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1466.txt
ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1519.txt
ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1597.txt
ftp://ftp.ibp.fr/pub/rfc/rfc/rfc1860.txt
ftp://ftp.imag.fr/pub/archive/networking/ipv6/solaris2-ipv6/release-3
ftp://funet.fi/netinfo/netinfo/ip network allocations.95Jan
ftp://ugle.unit.no/pub/unix/network/vif-1.10.tar.gz
Librairies partagees
ftp://excalibur.ens.fr/pub/besancon/adm-cookbook/src/J-comp.unix.aix.44587
ftp://excalibur.ens.fr/pub/besancon/adm-cookbook/src/J-comp.unix.aix.48333
ftp://excalibur.ens.fr/pub/besancon/adm-cookbook/src/J-comp.unix.aix.49279
ftp://ftp.inria.fr/gnu/fileutils-3.12.tar.gz
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.sys.hp.hpux.01841
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.sys.hp.hpux.06233
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.sys.hp.hpux.32983
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.sys.sun.apps.04707
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.unix.aix.48333
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.unix.internals.02662
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/J-comp.unix.internals.03678
ftp://ftp.netcom.com/pub/he/henderso/change-sun-hostid-1.6.0.tar.gz
ftp://ftp.sage.usenix.org/pub/usenix/summer87/sunos-shared-libs.ps.Z
ftp://ftp.uu.net/systems/sun/sun-fixes/libc-pic.a.sun3.Z
ftp://ftp.uu.net/systems/sun/sun-fixes/libc-pic.a.sun4.Z
ftp://dufy.aquarel.fr/pub/network/mail/sendmail.cf/Instructions.ps.Z
ftp://dufy.aquarel.fr/pub/network/mail/sendmail.cf/release 5.3.tar.Z
ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/sendmail.8.7.4.base.tar.Z
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
388
...............................
..............................................
. ...............................................................
. .......................................
300
299
286
286
. .......................................
. .......................................................
.....................................................
..............
. .......................................................................
. ...............................................................
......................................................
.............................................
.....................................................
.....
....................................................
...................................................
.....................................................
. ...............................................
......................................................
. ...................................................
.........................................
........................................
. .....................................................................................
224
226
226
226
214
223
222
222
226
226
226
226
226
225
205
207
226
226
214
ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/sendmail.8.7.5.base.tar.Z
ftp://ftp.jussieu.fr/jussieu/sendmail/kit/kit-5.1.tar.Z
ftp://ftp.uu.net//networking/mail/mmdf/*
ftp://ftp.uu.net//networking/mail/smail/smail-3.1.29.1.tar.gz
NFS
ftp://coast.cs.purdue.edu/pub/tools/unix/nfsbug/nfsbug.shar.Z
ftp://coast.cs.purdue.edu/pub/tools/unix/nfsbug
ftp://coast.cs.purdue.edu/pub/tools/unix/nfstrace
ftp://excalibur.ens.fr/pub/besancon/adm-cookbook/src/nfs-enhancement-sun4-490.ps.gz
ftp://ftp.cs.columbia.edu/pub/amd
ftp://ftp.inria.fr/gnu/tar-1.11.2.tar.gz
ftp://ftp.inria.fr/system/user/enh-du-2.1.tar.gz
ftp://ftp.tu-bs.de/pub/networking/rpc.rquotad.AIX.tar.gz
ftp://ftp.uu.net/networking/ip/nfs/NFS3.spec.ps.Z
ftp://ftp.uwtc.washington.edu/pub/Docs/SunWhitePapers/networks and servers tuning guide.ps.Z
ftp://ftp.win.tue.nl/pub/security/portmap 3.shar.Z
ftp://ftp.win.tue.nl/pub/security/rpcbind 1.1.tar.Z
ftp://ftp.win.tue.nl/pub/security/securelib.tar.Z
ftp://harbor.ecn.purdue.edu/pub/davy/nfswatch4.0.tar.Z
ftp://netapp.com/pub/netapp/docs/usenix94v3.ps.Z
ftp://playground.sun.com/pub/rpc/tirpcsrc2.3.tar.Z
ftp://sunsite.unc.edu/pub/sun-info/white-papers/NFS perf.tar
ftp://sunsite.unc.edu/pub/sun-info/white-papers/NFS sol21.tar
ftp://usc.edu/pub/amd
NIS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
ftp://cs.tamu.edu/pub/security/NIS Paper.ps
ftp://ftp.inria.fr/prog/libraries/dbm-toolkit-1.1.1.shar.Z
ftp://sc.tamu.edu/pub/security/NIS Paper.ps
Securite
. ..................................................................
. ........................
..........................................................................
. .......................................
. ........................................................
. ........................................................
. ...........
.....................................................
......................................................
. .......................................................
. .......................................................
. ...................................................
. .......................................................
. ...................................................
. ...........................................................
. ...........................................
. ........................................
. ........................................
. .........................................
. ........................................
. .........................................
..............................................
. .......................................................
. ..........................................................................
. ................................................
ftp://dartmouth.edu/pub/passwd+.tar.Z
ftp://excalibur.ens.fr/pub/besancon/adm-cookbook/src/cron-check-.rhosts.pl
ftp://ftp.cert.org/pub/cert faq
ftp://ftp.cs.purdue.edu/pub/COAST/Tripwire/tripwire-1.2.tar.Z
ftp://ftp.cs.purdue.edu/pub/reports/TR823.PS.Z
ftp://ftp.cs.purdue.edu/pub/reports/TR933.PS.Z
ftp://ftp.doc.ic.ac.uk/computing/systems/mac/umich/util/network/daemon1.00.sit.hqx.gz
ftp://ftp.info.win.tue.nl/pub/unix/yapasswd.tar.Z
ftp://ftp.inria.fr/network/ftp/wu-ftpd-2.4.tar.Z
ftp://ftp.inria.fr/system/secur/cops-1.04.tar.Z
ftp://ftp.inria.fr/system/secur/Crack-4.1.tar.Z
ftp://ftp.inria.fr/system/secur/dictionaries.tar.Z
ftp://ftp.inria.fr/system/secur/iss-1.21.shar.g
ftp://ftp.inria.fr/system/secur/shadow-3.3.1.tar.Z
ftp://ftp.inria.fr/system/secur/ufc-3.tar.Z
ftp://ftp.irisa.fr/pub/mirrors/xinetd/xinetd.2.1.4.tar.gz
ftp://ftp.lysator.liu.se/pub/ident/servers/pident-2.3.tar.gz
ftp://ftp.research.att.com/dist/internet security/berferd.ps
ftp://ftp.research.att.com/dist/internet security/dragon.ps
ftp://ftp.research.att.com/dist/internet security/ipext.ps.Z
ftp://ftp.research.att.com/pub/internet security/berferd.ps
ftp://ftp.sage.usenix.org/pub/usenix/summer90/cops.ps.Z
ftp://ftp.univ-lyon1.fr/pub/doc/french/securite
ftp://ftp.urec.fr/pub/securite
ftp://ftp.win.tue.nl/pub/security/logdaemon-4.4.tar.Z
253
236
268
253
269
269
262
252
264
247
249
249
249
251
249
264
262
269
269
269
269
245
268
268
266
389
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252, 266
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
ftp://ftp.win.tue.nl/pub/security/portmap 3.shar.Z
ftp://ftp.win.tue.nl/pub/security/rpcbind 1.tar.Z
ftp://ftp.win.tue.nl/pub/security/securelib.tar.Z
ftp://ftp.win.tue.nl/pub/security/tcp wrappers 6.3.shar.
ftp://harbor.ecn.purdue.edu/pub/davy/trimlog.tar.Z
ftp://info.mcs.anl.go/pub/systems/anlpasswd-2.2.tar.Z
ftp://mac.archive.umich.edu/mac/util/network/daemon1.00.sit.hqx.gz
ftp://sierra.stanford.edu/pub/sources/swatch-2.1.tar.gz
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117, 226
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117, 226
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117, 226
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117, 226
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
ftp://ee.lbl.gov/papers/bpf-usenix93.ps.Z
ftp://ftp.ee.lbl.gov/libpcap-0.0.6.tar.Z
ftp://ftp.ee.lbl.gov/libpcap-0.0.6+.tar.gz
ftp://ftp.ee.lbl.gov/old/tcpdump-2.2.1.tar.Z
ftp://ftp.ee.lbl.gov/tcpdump-3.0.2.tar.Z
ftp://ftp.ee.lbl.gov/tcpdump-3.0.2+.tar.gz
ftp://ftp.germany.eu.net/pub/networking/inet/ethernet/ethdp103.zip
ftp://ftp.germany.eu.net/pub/networking/monitoring/ethload/ethld104.zip
ftp://ftp.iss.net/pub/faq/sniff
ftp://ftp.urec.fr/pub/securite/Unix/Logiciels/cpm.1.0.tar.Z
ftp://steph.admin.umass.edu/pub/faqs/ethernet.faq
Systemes
.................................................. 8
..................................................................... 8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
.................................................................................... 9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
..................................................... 9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
. . . . . . . . . . . 11
. . . . . . . . . . . . . . . . . . . . 10
. . . . . . . . . . . . . . 11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
. .................................... 8
............................... 9
. ....................................................................... 8
Terminaux ASCII
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
ftp://excalibur.ens.fr/pub/besancon/adm-cookbook/src/minitel.info
ftp://ftp.ens.fr/pub/unix/syst/untic.tar.Z
ftp://ftp.lps.ens.fr/pub/users/besancon/cookbook/src/minitel.cap
XDM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
ftp://export.lcs.mit.edu/etc/help
ftp://ftp.psy.uq.oz.au/pub/X11R5/Wraphelp.c.Z
390
391
/bin/dosformat
/bin/dump
/bin/smit
/etc/lscfg
/etc/lsps
/etc/swapon
/sbin/smit
/usr/etc/yp/makedbm
/usr/etc/yp/yppush
/usr/etc/yp/ypxfr
.............................
. ................................
. ................................
............................
. ........................
.............................
.............................
............................
. ................................
/usr/etc/yp/ypxfr *
/usr/etc/ypbind
/usr/etc/ypserv
/usr/lib/lpd/digest
/usr/lpp/bosperf/genld
/usr/sbin/exportfs
/usr/sbin/ifconfig
/usr/sbin/slibclean
/usr/sbin/tftpd
189
188
188
309
279
210
133
279
239
/bin/dosformat
/bin/dump
/bin/smit
/etc/lsps
/etc/swapon
/sbin/smit
/usr/etc/yp/makedbm
/usr/etc/yp/yppush
/usr/etc/yp/ypxfr
.............................
. ................................
. ................................
.............................
.............................
. ................................
............................
. ................................
/usr/etc/yp/ypxfr *
/usr/etc/ypbind
/usr/etc/ypserv
/usr/sbin/exportfs
/usr/sbin/ifconfig
/usr/sbin/lscfg
/usr/sbin/slibclean
/usr/sbin/tftpd
189
188
188
210
133
104
279
239
/etc/rdate
/etc/yp/makedbm
/etc/yp/yppush
/etc/yp/ypxfr
/etc/yp/ypxfr *
/sbin/disklabel
/sbin/scu
/sbin/swapon
/usr/bin/fddisk
/usr/bin/pfstat
/usr/lbin/lpd
/usr/sbin/ifconfig
/usr/sbin/latsetup
. . . . . . . . . . . . . . . . . . . . . . . . . 309, 311
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
. . . . . . . . . . . . . . . . . . . . . . . 234
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
/usr/sbin/lprsetup
/usr/sbin/netsetup
/usr/sbin/newfs
/usr/sbin/nfssetup
/usr/sbin/pfconfig
/usr/sbin/route
/usr/sbin/secauthmigrate
/usr/sbin/setld
/usr/sbin/tftpd
/usr/sbin/tunefs
/usr/sbin/uerf
/usr/sbin/ypserv
392
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
/bin/rzdisk
/etc/chpt
/etc/newfs
/etc/pstat
/etc/rdate
/etc/swapon
/etc/yp/makedbm
/etc/yp/yppush
/etc/yp/ypxfr
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
. . . . . . . . . . . . . . . . . . . . . . . . . . . 233
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
/etc/yp/ypxfr *
/etc/ypbind
/usr/bin/psfilt
/usr/etc/pfconfig
/usr/etc/scu
/usr/etc/sec/edauth
/usr/etc/sec/setauth
/usr/etc/ypserv
/usr/sbin/ypbind
/sbin/disklabel
/sbin/fdisk
/sbin/ifconfig
/sbin/init
/sbin/ldconfig
/sbin/newfs
/sbin/scsi
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
/sbin/swapon
/sbin/tunefs
/usr/bin/ldd
/usr/bin/netstat
/usr/sbin/fdformat
/usr/sbin/swapinfo
tickadj
/etc/lanscan
/etc/newfs
/etc/swapon
/etc/tsconvert
/etc/yp/makedbm
/etc/ypbind
....................................
. ..............................
.............................
. ..............................
.............................
. ................................
/usr/bin/sam
/usr/etc/exportfs
/usr/etc/yp/yppush
/usr/etc/yp/ypxfr
/usr/etc/yp/ypxfr *
/usr/etc/ypserv
126
210
189
189
189
188
/etc/diskinfo
/etc/lanscan
/etc/newfs
/etc/sdsadmin
/etc/swapinfo
/etc/swapon
/etc/tsconvert
/etc/tunefs
/etc/yp/makedbm
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
. . . . . . . . . . . . . . . . . . . . . . . . . . . 39, 85
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
/etc/ypbind
/usr/bin/chatr
/usr/bin/mediainit
/usr/bin/sam
/usr/etc/exportfs
/usr/etc/yp/yppush
/usr/etc/yp/ypxfr
/usr/etc/yp/ypxfr *
/usr/etc/ypserv
/etc/diskinfo
/etc/lanscan
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
/etc/tunefs
/etc/yp/makedbm
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
. . . . . . . . . . . . . . . . . . . . . . . . . . . 40, 85
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
/etc/ypbind
/sbin/newfs
/usr/bin/chatr
/usr/bin/mediainit
/usr/etc/yp/yppush
/usr/etc/yp/ypxfr
/usr/etc/yp/ypxfr *
393
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93, 96
/usr/etc/ypserv
/usr/sbin/exportfs
/usr/sbin/ifconfig
/usr/sbin/sam
/usr/sbin/swapinfo
/usr/sbin/swapon
/etc/chkconfig
/etc/mkfs
/etc/prtvtoc
/etc/swap
/usr/bin/fx
/usr/bin/lp
/usr/etc/exportfs
/usr/etc/tftpd
/usr/etc/yp/makedbm
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . 310
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
/usr/etc/yp/yppush
/usr/etc/yp/ypxfr
/usr/etc/yp/ypxfr *
/usr/etc/ypbind
/usr/etc/ypserv
/usr/lib/vadmin/printers
/usr/sbin/Add disk
/usr/sbin/vadmin
/bin/elfdump
/bin/mkfp
/bin/odump
/etc/mkfs
/sbin/swap
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
/usr/bin/fx
/usr/etc/exportfs
/usr/etc/tftpd
/usr/sbin/Add disk
/usr/sbin/prtvtoc
/bin/free
/sbin/fdisk
/sbin/ifconfig
/sbin/init
/sbin/ldconfig
/sbin/mkswap
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94, 97
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
/sbin/swapon
/sbin/tune2fs
/usr/bin/fdformat
/usr/bin/ldd
/usr/sbin/ypbind
394
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104, 115
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
. . . . . . . . . . . . . . . . . . . . . . . 40, 42, 48, 56
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
/bin/fdformat
/bin/ldd
/etc/ifconfig
/etc/newfs
/etc/pstat
/etc/pwck
/usr/etc/exportfs
/usr/etc/format
/usr/etc/in.tftpd
/usr/etc/ldconfig
/usr/etc/mkfile
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
. . . . . . . . . . . . . . . . . . . . . . . . . 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95, 98
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 188, 189
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
/usr/etc/mount
/usr/etc/rpc.mountd
/usr/etc/rpc.yppasswdd
/usr/etc/swapon
/usr/etc/tunefs
/usr/etc/yp/makedbm
/usr/etc/yp/ypxfr *
/usr/etc/ypbind
/usr/etc/ypserv
/usr/lib/lpd
/usr/ucb/rdate
/bin/fdformat
/sbin/ifconfig
/sbin/swapadd
/usr/bin/ldd
/usr/lib/netsvc/yp/ypbind
/usr/sbin/exportfs
/usr/sbin/format
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 92, 95, 98
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
/usr/sbin/makedbm
/usr/sbin/newfs
/usr/sbin/snoop
/usr/sbin/swap
/usr/sbin/tunefs
/usr/ucb/rdate
395
396
397
/etc/environment
/etc/exports
/etc/filesystems
/etc/inittab
/etc/qconfig
/etc/rc
/etc/rc.bsdnet
/etc/rc.net
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190, 212
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
. . . . . . . . . . . . . . . . . . . . . . . . 240
. . . . . . . . . . . . . . . . . . . . . . . . . . . 232
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
/etc/rc.nfs
/etc/resolv.conf
/etc/security/login.cfg
/etc/security/passwd
/etc/swapspaces
/etc/tftpaccess.ctl
/usr/bin/domainname
/etc/environment
/etc/exports
/etc/filesystems
/etc/inittab
/etc/rc
/etc/rc.bsdnet
/etc/rc.net
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190, 212
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
. . . . . . . . . . . . . . . . . . . . . . . . 240
. . . . . . . . . . . . . . . . . . . . . . . . . . . 232
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
/etc/rc.nfs
/etc/resolv.conf
/etc/security/login.cfg
/etc/security/passwd
/etc/swapspaces
/etc/tftpaccess.ctl
/usr/bin/domainname
Fichiers speciques au systeme DEC OSF1 versions 1.x, 2.x, 3.x.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60, 93
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33, 311
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309, 311
. . . . . . 126, 153, 190, 193, 212, 217, 310
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
. . . . . . . . . . . . . . . . . . . . . . . . . . 163, 199, 233
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
. . . . . . . . . . . . . . . . . . . . . . . . 178
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
/bin/domainname
/dev/pf/*
/etc/disktab
/etc/exports
/etc/fstab
/etc/inittab
/etc/printcap
/etc/rc.config
/etc/resolv.conf
/etc/routes
/etc/svc.conf
/etc/tftptab
/etc/zoneinfo/localtime
/sbin/init.d/
/sbin/init.d/inet
/sbin/init.d/lpd
/sbin/init.d/nfs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
. . . . . . . . . . . . . . . . . . . . . . . . . . . 177
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . . 112
. . . . . . . . . . 334
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
. . . . . . . . . . . . . . . . . . . . . . . 111
. . . . . . . . . . . . . . . . . . . . . . . . 79
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
/sbin/init.d/nis
/sbin/init.d/paging
/sbin/init.d/route
/sbin/init.d/settime
/sbin/rc0
/sbin/rc0.d/
/sbin/rc2
/sbin/rc2.d/
/sbin/rc3
/sbin/rc3.d/
/usr/examples/packetfilter
/usr/examples/packetfilter/pfopen.c
/usr/sbin/nissetup
/usr/sbin/ypsetup
/usr/sys/conf/<filename>
/usr/sys/data/cam data.c
<net/pfilt.h>
398
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60, 93
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
/bin/domainname
/dev/pf/*
/etc/auth.dir
/etc/disktab
/etc/exports
/etc/fstab
/etc/printcap
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . 33, 126, 136, 153, 193, 212
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
. . . . . . . . . . . . . . . . . . . . . . . . . . 163, 199, 233
. . . 178
. . . . . . . . . . . . . . . . . . . . . . . 112
/etc/rc
/etc/rc.local
/etc/resolv.conf
/etc/svc.conf
/usr/sys/conf/<architecture>/<configfile>
/usr/sys/conf/<filename>
/bin/domainname
/etc/exports
/etc/fstab
/etc/host.conf
/etc/localtime
/etc/netstart
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
. . . . . . . . . . . . . . . . . . . . . . . . . . 33, 36, 93, 212, 276
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
. . . . . . 126, 136, 153, 191, 194, 212, 217
. . . . . . . . . . . . . . . . . . . . . . . . 178
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
/etc/printcap
/etc/rc
/etc/resolv.conf
/etc/sysconfig
/usr/share/zoneinfo/MET
/var/run/mountd.pid
/.secure/etc/passwd
/bin/domainname
/etc/checklist
/etc/exports
/etc/mnttab
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126, 136
. . . . . . . . . . . . . . . . . . . . . . . . . . 191, 194, 212
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153, 178
/etc/netlinkrc
/etc/netnfsrc
/etc/resolv.conf
/etc/src.sh
/.secure/etc/passwd
/bin/domainname
/etc/checklist
/etc/exports
/etc/mnttab
/etc/netlinkrc
/etc/netnfsrc
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
. . . . . . . . . . . . . . . . . . . . . . . . . . . 160, 167
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56, 60
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153, 178
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
/etc/partitions
/etc/resolv.conf
/etc/sbtab
/etc/sdsadmin
/etc/src.sh
/usr/sam/log/samlog
/etc/checklist
/etc/exports
/etc/fstab
/etc/inittab
/etc/mnttab
/etc/rc.config.d/namesrvs
/etc/rc.config.d/namesvrs
. . . . . . . . . . . . . . . . . . . . . . . 127
. . . . . . . . . . . . . . . . 137, 153
. . . . . . . . . . . . . . . . . . 212, 217
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . 212
/etc/rc.config.d/netconf
/etc/rc.config.d/netconfig
/etc/rc.config.d/nfsconf
/etc/resolv.conf
/etc/TIMEZONE
/sbin/init.d/
/sbin/init.d/nfs.client
. . . . . . . . . . . . . . . . . . . . . . . . . . 212
. . . . . . . . . . . . . . . . . . . . . . . . 212
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
/sbin/init.d/nfs.core
/sbin/init.d/nfs.server
/sbin/rc
/sbin/rc0.d/
399
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
/sbin/rc2.d/
/sbin/rc3.d/
/usr/bin/domainname
/etc/config/automount.options
/etc/config/ifconfig-1.options
/etc/config/nfs
/etc/config/yp
/etc/config/ypbind.options
/etc/config/ypmaster
/etc/config/ypserv
/etc/exports
/etc/fstab
/etc/init.d/network
/etc/inittab
/etc/mtab
/etc/rc0
/etc/rc0.d/
/etc/rc2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
. . . . . . . . . . . . . . . . . . . . . . 160, 167
. . . . . . . . . . . . . . . . . . . . . . . . . . . 191
/etc/rc2.d/
/etc/rc3
/etc/rc3.d/
/etc/sys id
/etc/TIMEZONE
/usr/bin/domainname
/usr/etc/inetd.conf
/usr/etc/resolv.conf
/usr/etc/yp/ypdomain
/usr/people/4Dgifts/examples/network/ercv.c
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
/usr/people/4Dgifts/examples/network/esnd.c
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
<net/raw.h>
eoe2.sw.bsdlpr
/etc/config/automount.options
/etc/config/yp
/etc/config/ypbind.options
/etc/config/ypmaster
/etc/config/ypserv
/etc/exports
/etc/fstab
/etc/inetd.conf
/etc/init.d/network
/etc/init.d/network.local
/etc/inittab
/etc/mtab
/etc/rc0
/etc/rc0.d/
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . . . . . . . 160, 167
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
/etc/rc2
/etc/rc2.d/
/etc/rc3
/etc/rc3.d/
/etc/resolv.conf
/etc/sys id
/etc/TIMEZONE
/usr/people/4Dgifts/examples/network/ercv.c
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
/usr/people/4Dgifts/examples/network/esnd.c
..............................................
. ...............................
.....................................
. .................................
/var/yp/ypdomain
<net/raw.h>
bin/domainname
113
191
113
191
/bin/domainname-yp
/etc/exports
/etc/fstab
/etc/host.conf
/etc/HOSTNAME
/etc/inittab
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
. . . . . . . . . . . . . . . . . . . . . . . . . 127, 137
. . . . . . . . . . . . . . . . . . . . 191, 195, 212
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 276
/etc/printcap
/etc/rc.d
/etc/rc.d/rc.inet1
/etc/rc.d/rc.inet2
/etc/rc.d/rc.local
/etc/rc.d/rc.M
400
/etc/resolv.conf
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
/usr/lib/zoneinfo/localtime
. . . . . . . . . . . . . . . . . . . 178
/bin/domainname
/etc/defaultdomain
/etc/exports
/etc/fstab
/etc/hostname.<interface>
/etc/localtime
/etc/mygate
/etc/myname
/etc/netstart
/etc/printcap
/etc/rc
/etc/rct
/etc/resolv.conf
/usr/share/lib/zoneinfo/localtime
/usr/share/zoneinfo/MET
/var/run/mountd.pid
/bin/domainname
/etc/defaultdomain
/etc/defaultrouter
/etc/exports
/etc/format.dat
/etc/fstab
/etc/hostname.<interface>
/etc/hosts.equiv
/etc/inetd.conf
/etc/mtab
/etc/printcap
/etc/rc
/etc/rc.local
. . 36, 95, 98, 127, 138, 191, 195, 213, 217, 276, 310
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
. . . . . . . . . . . . . . . . . . 234
. . . . . . . . . . . . . . . . . . . . . . . . . . . 168
. . . . . . . . . . . . . . . . . . . . . . . . . . . 168
. . . . . . . . . . . . . . . . . . . . . . . . . 168, 277
. . . . . . . . . . . . 178
/etc/resolv.conf
/etc/security/passwd.adjunct
/usr/lib/libc.so.x.y
/usr/lib/libresolv.a
/usr/lib/shlib.etc
/usr/share/lib/zoneinfo/localtime
/usr/sys/kvm/<architecture>/conf/<filename>
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
/var/yp/hosts.time
/var/yp/securenets
/etc/default/init
/etc/defaultdomain
/etc/defaultrouter
/etc/dfs/sharetab
/etc/init.d/inetinit
/etc/init.d/inetsvc
/etc/init.d/nfs.client
/etc/init.d/rootusr
/etc/init.d/rpc
/etc/inittab
/etc/mnttab
/etc/netmasks
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60, 95
. . . . . . . . . . . . . . . . . . . . . . . . . . . 113
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
/etc/nodename
/etc/nsswitch.conf
/etc/rc[012356S]
/etc/rc[0123S].d/
/etc/resolv.conf
/etc/shadow
/etc/TIMEZONE
/etc/vfstab
/kernel/strmod/pfmod
/usr/bin/domainname
/usr/lib/pics
<sys/pfmod.h>
401
402
..........................................
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conventions utilisees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disponibilite sur Internet de ce document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remerciements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
............................
1
1
2
3
4
.........................
..........
........................
15
19
25
25
25
26
27
30
32
36
..................
39
.....................
59
59
60
60
61
61
61
62
72
73
77
ii
79
79
79
79
80
81
82
83
85
........................
89
......................
8 Reseau Ethernet.
...........................................
101
111
..............
...................
101
103
103
104
105
107
107
111
113
116
117
117
121
121
124
125
127
128
129
130
131
132
133
134
134
135
136
iii
10.9 Problemes d'IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
10.9.1 La parade actuelle : Classless Inter-Domain Routing (CIDR). . . . . . . . . 140
10.9.2 Le futur d'IP : IP new generation (IPng, IPv6). . . . . . . . . . . . . . . . . . . . . . 141
10.10 Bibliographie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
11.6
11.7
11.8
11.9
.........
145
........................
175
Principe du DNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aspect administratif du DNS : enregistrement d'un domaine. . . . . . . . . . . . . . . . . .
Baptiser une station. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Donner le nom a une station. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aspects de la conguration de nameservers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5.1 Implantation du DNS : bind. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5.2 Les dierents types de nameservers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5.2.1 Nameserver primaire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5.2.2 Nameserver secondaire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5.2.3 Nameserver cache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5.2.4 L'option forwarders. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5.2.5 L'option slave. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5.2.6 Les nameservers de la racine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appel aux nameservers : la resolution via le resolver. . . . . . . . . . . . . . . . . . . . . . . . . .
11.6.1 Emettre une requ^ete au nameserver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.6.2 Fichier resolv.conf. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.6.3 Cas des noms de domaine sur plus de deux champs. . . . . . . . . . . . . . . . . .
Mecanismes de resolution adoptes par les constructeurs. . . . . . . . . . . . . . . . . . . . . . .
11.7.1 Mecanisme de resolution de noms sur AIX versions 3.2.x et 4.1.x. . . . .
11.7.2 Mecanisme de resolution de noms sur DEC OSF1 et DEC Ultrix. . . . .
11.7.3 Mecanisme de resolution de noms sur FreeBSD 2.0.5. . . . . . . . . . . . . . . . .
11.7.4 Mecanisme de resolution de noms sur HP-UX version 8.07 et 9.0x. . . .
11.7.5 Mecanisme de resolution de noms sur HP-UX 10.01. . . . . . . . . . . . . . . . . .
11.7.6 Mecanisme de resolution de noms sur IRIX versions 4.0.5 et 5.2. . . . . .
11.7.7 Mecanisme de resolution de noms sur Linux 1.2.1. . . . . . . . . . . . . . . . . . . .
11.7.8 Mecanisme de resolution de noms sur NetBSD 1.0. . . . . . . . . . . . . . . . . . .
11.7.9 Mecanisme de resolution de noms sur SunOS 4.1.x. . . . . . . . . . . . . . . . . .
11.7.10 Mecanisme de resolution de noms sur Solaris 2.x. . . . . . . . . . . . . . . . . . .
11.7.11 Mecanisme de resolution de noms sur Macintosh. . . . . . . . . . . . . . . . . . .
11.7.11.1 MacTCP 2.0.6 et le caractere . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.7.11.2 MacTCP 2.0.x et bootp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panorama de quelques utilitaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bibliographie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
145
150
151
153
154
154
155
155
156
156
156
156
157
158
158
160
160
163
163
163
164
164
167
167
167
167
168
169
170
170
170
172
173
...
187
187
187
190
195
195
iv
13.5
13.6
13.7
13.8
196
196
197
197
199
200
200
201
201
201
202
...........
205
................................
229
15.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.2 Exemples de l'insecurite des machines UNIX { Quelques intrusions celebres. . . .
15.3 Caracteristiques standards de la securite sous UNIX. . . . . . . . . . . . . . . . . . . . . . . . . .
15.3.1 Mecanismes standards concernant l'identication,l'authentication
utilisateurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.3.2 Mecanismes standards concernant le systeme de gestion des chiers. . .
15.3.3 Mecanismes standards concernant les sessions utilisateurs. . . . . . . . . . . .
15.4 Panorama d'outils de securite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.4.1 Outils de contr^ole statique d'un systeme. . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.4.2 Outils de verication de l'integrite d'un systeme. . . . . . . . . . . . . . . . . . . . .
15.4.3 Preliminaires aux outils de contr^ole dynamique d'un systeme. . . . . . . . .
15.4.4 Outils de contr^ole dynamique d'un systeme. . . . . . . . . . . . . . . . . . . . . . . . .
15.5 Securite avancee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.6 Quelques sources d'informations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.7 Bibliographie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
229
230
231
des
231
236
240
243
244
253
256
259
267
268
269
16 Librairies dynamiques.
....................................
271
17.5
17.6
17.7
17.8
271
272
272
273
275
275
276
277
278
279
...................
281
.............................
305
........................................
317
19 Reseaux Appletalk.
19.1
19.2
19.3
19.4
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Un peu de terminologie AppleTalk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routeurs AppleTalk/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logiciel CAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4.1 Fonctionnement de CAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4.2 Utilitaires AppleTalk au niveau UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4.3 Service AppleShare sous UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4.4 Impressions AppleTalk depuis UNIX via CAP. . . . . . . . . . . . . . . . . . . . . . .
19.4.5 Exemple de conguration d'imprimantes. . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4.6 Particularites de CAP sur certaines architectures. . . . . . . . . . . . . . . . . . . .
19.5 Logiciel Netatalk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.5.1 Fonctionnement de netatalk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.5.2 Utilitaires AppleTalk au niveau UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.5.3 Service AppleShare sous UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
317
318
320
329
329
331
331
332
333
334
335
335
336
337
vi
.......................
338
339
340
342
342
342
343
345
347
............
361
.................................
379
...................................
385
21.1
21.2
21.3
21.4
vii
................................
391
.....................................
397
391
391
391
391
392
392
392
392
393
393
393
393
393
394
397
397
397
397
398
398
398
398
399
399
399
400
400
400
viii
Revision
: 1 27.
:
ix