Thread View: dnet.comp.pcs
2 messages
2 total messages
Started by Rudi Wildgruber
Thu, 21 Feb 1991 13:47
Produktinfo CADMUS TCP/IP (BSD) V2.0
Author: Rudi Wildgruber
Date: Thu, 21 Feb 1991 13:47
Date: Thu, 21 Feb 1991 13:47
169 lines
9274 bytes
9274 bytes
1. Einfuehrung ============== TCP/IP (BSD) V.2.0 ist die Nachfolgeversion von TCP/IP (BSD) V.1.2 fuer CADMUS/M und CADMUS/R Systeme. Mit dieser Version wurden einige neue Dienste eingefuehrt. Weiterhin wurde der "Virtual Information Service (VIS)" implementiert. Optional kann eine Zugangskontrolle fuer TCP basierende Dienste installiert werden. 2. VIS Virtual Information Service ================================== 2.1. Konfiguration Mittels VIS besteht die Moeglichkeit vorhandene Informationsdienste global, bzw. benutzerspezifisch zu nutzen. Folgende Dienste werden zur Zeit unterstuetzt: nis SUN's Network Information Service (YP) dns DARPA Domain Name Service files Standard UNIX Konfigurationsdateien Die Festlegung, welche Informationsdienste wann und wo verwendet werden sollen, wird in der Datei /etc/vis.conf definiert. Die Informationsdienste stehen fuer folgende Bereiche zur Verfuegung: host Hostnamen bzw. IP-Adressen passwd Loginnamen, UID, Passwoerter, ... group Gruppennamen, GID net Netzwerknamen netgroup NFS Netzwerkgruppen services Servicenamen, Portnummern proto Protokollnamen, IP-Protokollnummern Neben der globalen Verwaltung ( /etc/vis.conf ), kann sich jeder Benutzer ueber die Shellvariable VIS_SERVICES seine eigene Konfigurationsdatei erstellen. Bei der Erstellung der Datei (VIS_SERVICES) ist zu beachten, dass die Dateistruktur identisch mit der von /etc/vis.conf sein muss. Falls /etc/vis.conf nicht vorhanden bzw. VIS_SERVICES nicht belegt ist, wird standardmaessig auf die lokalen Datenbestaende zugegriffen. Dies trifft bei der Aufloesung von rechnerspezifischen Daten (host) nicht zu. Hier wird zuerst versucht, die Adresse bzw. den Namen des entsprechenden Rechners ueber DNS zu erhalten. Falls dies nicht moeglich ist wird auch hier auf die lokalen UNIX Dateien zugegriffen. 2.2. Nutzung mit eigenen Applikationen Zur Erstellung benutzerspezifischer Applikationen, welche VIS benutzen sollen, steht die Bibliothek /usr/lib/lib_vis.a zur Verfuegung. Beim Binden des Programms muessen dazu die Bibliotheken -l_vis -lrpc -lbsd angegeben werden. 3. BIND (Berkeley Internet Name Domain Server) ============================================== 3.1 Einfuehrung In einem weitverzweigten Netzwerk, bestehend aus einer Vielzahl lokaler Netze, die ueber Wide Area Networks (WANs) gekoppelt sind, ist die Verwaltung der IP-Adressen ueber die Datei /etc/hosts bzw. Yellow Pages nicht mehr zweckmaessig. Damit die Verwaltung der IP-Adressen nicht einer einzigen Institution obliegt, werden die Aufgaben an Unterorganisationen delegiert. Hierzu wird der Namensraum des Netzes in Bereiche (Domains) aufgeteilt. Die Anordnung der Bereiche ist baumartig strukturiert. Es gibt eine Wurzel von der aus sog. Top Level Domains ausgehen, die wiederum in weitere Unterbereiche aufgeteilt sind. Rechnernamen bestehen nun nicht mehr aus einer einfachen Zeichenfolge sondern werden aus mehreren Zeichenfolgen zu einem hierarchischen Namen zusammengesetzt. Ein Bestandteil (Domain) eines hierarchischen Namens kann z.B. die Bezeichnung einer Unterorganisation sein, ein weiterer eine Laenderkennung. Der Name pluto.bst.pcs.com bezeichnet den Rechner pluto der Abteilung BST in der Firma PCS Computer Systeme in der top level domain com (com bedeutet kommerziell). Um die IP-Adresse eines Rechners zu bekommen, wird ein Rechner (Nameserver), der sich in jeder Unterorganisation befindet, befragt. Kann der Rechner die Anfrage beantworten, schickt er die IP-Adresse zurueck. Kann der Name nicht aufgeloest werden, wird eine Anfrage an den Nameserver der naechsthoeheren Hierarchie gesendet usw. 3.2. DNS Der in TCP/IP (BSD) V.2.0 gelieferte Berkeley Internet Name Domain Server (BIND) ist eine vollstaendige Implementierung des Domain Name Services (DNS). Er ist unter dem Programmnamen named verfuegbar und wird ueber eine Reihe von Dateien konfiguriert. DNS Name Server verwalten sogenannnte Domains. In jeder Domain sollten aus Sicherheitsgruenden mindestens zwei aktive Name Server (primary und secondary) vorhanden sein. Der named fuehrt Caching sowie rekursive Queries durch und kann in drei verschiedenen Modi konfiguriert werden: als primaerer, sekundaerer Server oder rein zum Caching. 3.3. Resolver Der Resolver uebernimmt fuer die Applikationsprogramme und damit fuer den Benutzer die Anfrage beim Name Server. Der Resolver ist angehalten, die so ermittelte Information - soweit moeglich - lokal zu speichern (Caching), um sie bei weiteren gleichartigen Anfragen ohne weitere Kommunikation mit dem Name Server liefern zu koennen. Fuer Anfragen kann der Resolver sowohl UDP als auch TCP verwenden. UDP stellt das Standardprotokoll dar. Eine eigene Fehlersicherung (Anfragewiederholung) wurde hier implementiert. Soll ein Rechner mit den Resolver Funktionen betrieben werden so muessen der dazugehoerige Domainname und Nameserver bekannt sein. Diese Daten werden in der Datei /etc/resolv.conf gehalten. Die Resolver Funktionen befinden sich in der Bibliothek /usr/lib/lib_vis.a. 4. Neue Dienste =============== Mit TCP/IP Version 2.0 werden die Dienste talk und talkd , finger und fingerd , sowie fuer die RCU Systeme timedc und timed , eine Implementierung des Network Time Protocol (NTP) , ausgeliefert. Talk und talkd dienen der Kommunikation zweier Benutzer auch auf entfernten Systemen. Dabei erscheinen auf dem Bildschirm bzw. Fenster zwei durch einen Strich getrennte Bereiche. Im oberen Bereich schreibt der Benutzer seine Nachricht, im unteren Teil wird die Nachricht des entfernten Benutzers empfangen. Finger und fingerd sind Dienste, die Informationen ueber Benutzer auch auf entfernten Systemen erlangen. Timed wird zur Synchronisation der Zeit zwischen Rechnern auf einem Netzwerk eingesetzt. Dies ist vor allem bei NFS und MUNIX/Net wichtig. Zur Kontrolle der Zeit ist das Programm timedc noetig. 5. Zugangskontrolle =================== 5.1. Funktionen Fuer alle TCP basierenden Dienste, die durch den Internet Daemon inetd gestartet werden (rlogind, telnetd, ftpd, rshd, rexecd und fingerd) kann eine Zugangskontrolle installiert werden. Dabei besteht die Moeglichkeit bestimmte Dienste bestimmten Rechnern bzw. Rechnergruppen zu verweigern bzw. zur Verfuegung zu stellen. Nach erfolgter Installation werden bei Verbindungswunsch die gewuenschten Serverprogramme nicht sofort gestartet sondern durch einen vorgeschalteten Serverprozess ausgefuehrt. Dieser Serverprozess prueft die Zugangsberechtigung des rufenden Rechners mittels der Dateien /etc/hosts.allow und /etc/hosts.deny ab. Weiterhin koennen alle erlaubten bzw. zurueckgewiesenen Verbindungen auf unterschiedliche Weise angezeigt und gespeichert werden. Die Konfiguration des vorgeschalteten Serverprozesses erfolgt durch die Datei /usr/lib/inet/secure/tcpd.conf . Mit dieser Datei wird die Ausgabe der Logging Informationen gesteuert. 5.2. Installation der Zugriffskontrolle Die Installation der Zugriffskontrolle erfolgt durch Aufruf des Programmes /usr/lib/inet/secure/inst_secure . Das Installations-Script erzeugt alle notwendigen Eintraege in der Datei /usr/lib/inet/inetd.conf . Die urspruengliche Datei wird in /usr/lib/inet/inetd.conf.org gesichert. Danach wird der Prozess inetd durch ein Signal HANGUP dazu gebracht, die Datei /usr/lib/inet/inetd.conf erneut zu lesen. Soll keine Zugangskontrolle mehr stattfinden, muessen nur die Dateien /etc/hosts.allow und /etc/hosts.deny umbenannt bzw. geloescht werden. Die zweite Moeglichkeit besteht darin, die urspruengliche Datei /usr/lib/inet/inetd.conf.org nach /usr/lib/inet/inetd.conf zu kopieren und dem inetd ein Signal HANGUP zu senden. Dazu benoetigt man die Prozess ID (PID) von inetd (ps -ef|grep inetd) und sendet das Signal an den Prozess (kill -1 PID). Ein nochmaliger Aufruf von inst_secure bewirkt dann wieder den Zugangsschutz. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rudi Wildgruber PCS-Mail: rw PCS Computer Systeme GmbH DOMAIN: rw@pcsbst.pcs.com D-8000 Muenchen 90 UUCP: ...unido!pcsbst!rw
Re: Produktinfo CADMUS TCP/IP (BSD) V2.0
Author: Bernhard Schneck
Date: Sun, 10 Mar 1991 01:47
Date: Sun, 10 Mar 1991 01:47
36 lines
2255 bytes
2255 bytes
wild@rks32.pcs.com (Rudi Wildgruber) writes:
>[...] viele nette Dinge ...
>Timed wird zur Synchronisation der Zeit zwischen Rechnern auf einem
>Netzwerk eingesetzt. Dies ist vor allem bei NFS und MUNIX/Net wichtig.
>Zur Kontrolle der Zeit ist das Programm timedc noetig.
Hmmm ... der timed den *ich* kenne benutzt kein ntp, sondern das
aeltere Berkeley Protokoll, das die Uhren zwar einigermassen synchron
haelt, aber eben ziemlich synchron falsch. Ueblicherweise heissen die
NTP Time Daemons 'ntpd' (bzw. der bessere 'xntpd'), allerdings
rentiert sich *das* erst wirklich wenn man irgendwo einen guten Wecker
in der Naehe hat (sprich DFC77 Empfaenger, der mit wenigen msec delay
benutzt werden kann ... uebliche PC-Empfaenger verwirren das NTP zu
sehr durch Schwankungen!)
Kann latuernich sein dass PCS einen NTPigen timed hat ... aber
vielleicht sollten sie dann einen anderen Namen nehmen der keine
falschen Assoziationen weckt ...
>[...]
>Rudi Wildgruber PCS-Mail: rw
\Bernhard.
--
Bernhard Schneck Internet: B.Schneck@Marvin.E17.Physik.TU-Muenchen.DE
TU Muenchen Physik E17 Postmaster@Physik.TU-Muenchen.DE
8046 Garching BitNET : schneck@dgablg5p
West Germany
--
"There is no problem so big that it cannot be run away from"
Illusions, Richard Bach
Bernhard Schneck Internet: B.Schneck@Marvin.E17.Physik.TU-Muenchen.DE
TU Muenchen Physik E17 Postmaster@Physik.TU-Muenchen.DE
8046 Garching BitNET : schneck@dgablg5p
West Germany
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads