From owner-freebsd-hackers Thu Nov 7 14:39:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21856 for hackers-outgoing; Thu, 7 Nov 1996 14:39:21 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA21844 for ; Thu, 7 Nov 1996 14:39:18 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id LAA17843 for ; Thu, 7 Nov 1996 11:09:32 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id LAA01324; Thu, 7 Nov 1996 11:09:15 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id GAA27388; Fri, 8 Nov 1996 06:08:47 +1100 From: Julian Assange Message-Id: <199611071908.GAA27388@suburbia.net> Subject: virtual hosting with inetd To: terry@lambert.org (Terry Lambert) Date: Fri, 8 Nov 1996 06:08:46 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199611071827.LAA10376@phaeton.artisoft.com> from "Terry Lambert" at Nov 7, 96 11:27:24 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > +Lines starting with '/' in the configuration file are special directives to > > +.Nm inetd . > > +At present the following directives are supported: > > +.Bd -literal > > +/bind iface1|ANY...iface_n bind following service entries to > > + these interfaces > > +/bind+ iface1...iface_n as above, but add specified ifaces to > > + the previous bind list > > +.Ed > > +.Pp > > +If the iface name begins with "<", then the iface name is treated > > +as a file with interface addresses listed as the first word per line. > > +If the iface name is multi-homed in the DNS, then all addresses belonging > > +to that iface name will be bound. > > Some notes on the "inetd.conf" "bind" changes... > > 1) Why not add an "-i" option to inetd ans start multiple inetd's? > Clearly, the intent of the "<" syntax is to have seperate conf > files per bound interface. There is already an "-a" option. The '<' is used so one can automate the addition of particular classes of interfaces (virtual hosts), by simple having those addresses in a "hosts" type file, that can also be used for other things, such as setting up the interface alias addresses in the first place. Further, such a list could be very large and therefor not in keeping with placing in inetd.conf The general idea behind my changes this: a) many systems now run as "virtual" sites, depending on IP. Some systems have hundreds or thousands of such addresses. b) one should not need to run more than one inetd c) the majority of services with be uniform accross ifaces; therefor only the differences between ifaces should be different. The case of having multiple inetd.conf's flies in the face of all configuration file theory ;) and will in the majority of circumstances require idential changes to every inetd.conf file when a service entry needs changing. d) the accounting features of inetd should be unified. e) configuration files should be efficient and visually pleasing. > 2) Why introduce state? Since a configuration for a single > interface can span several pages of data, this is confusing. > Did you consider an "interface:service" instead of "service" > syntax instead? A single strtok() call could find the ':'. I thought about this idea, and decided against it on the basis that it would introduce possible large scale data duplication and very ugly config lines. State is good. Natural language uses it all the time. It makes things more efficient ;) > 3) Why are you binding by network number (or host name, which will > be translated to network number and may in fact fail if this is > run on a multi-homed host)? If you bound by interface name > instead, it would be unambiguous... I didn't believe I was binding by network number...? > 4) Support for virtual hosting in inetd has already been implemented > by Van Jacobsen (last I heard)... any reason to not use his code > instead? I believe it requires the ability to determine the > interface following an accept before the spawn via an ioctl() > on the socket... getsockname(). I didn't use this, as it requires checking only after the connection is made. This latter method is flawed, as you may not want a service bound to every interface, you may want it handled out side of inetd, or have no listening process on it at all. -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | +---------------------+--------------------+----------------------------------+