]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/log
FreeBSD/FreeBSD.git
28 years ago(This import had better work correctly or so help me I'll move to
wpaul [Tue, 25 Jun 1996 20:26:38 +0000 (20:26 +0000)]
(This import had better work correctly or so help me I'll move to
the Himalayas and become a hermit.)

Import new mknetid program. This replaces the crufty, soon to be defunct
mknetid script packaged with ypserv.

This program parses the group, passwd, hosts and netid databases into
the netid.byname map. Duplicate checking is performed using hash tables.
Testing on my 486DX2/66 with FreeBSD 2.1.0 showed that this program can
process a 30,000-entry passwd database into a netid map (along with
assorted group and hosts information) in about 22 seconds. On my SPARC IPX
with SunOS 4.1.3, it takes about 15 seconds. This compares favorably with
the SunOS mknetid program, which parses the same database(s) in 13 seconds.
(With smaller databases, my program is actually slightly faster. Go
figure.)

28 years agoImport rpc.ypxfrd.
wpaul [Wed, 5 Jun 1996 04:36:55 +0000 (04:36 +0000)]
Import rpc.ypxfrd.

This server impliments an RPC-based file transfer protocol that allows
an NIS slave server to copy a raw map database file from an NIS master.

The goal here is to speed up the transfer of very large maps. If you
have, for example, an NIS password database with 30,000 records in it,
it can take around 8 to 10 minutes to regenerate it (four hash databases
are created). As it stands now, ypxfr(8) transfers a map by sucking all
the records from ypserv(8) on the master using yp_all() and writing them
to a new database using the db(3) library. This adds up to another 8 to 10
minutes, per slave. With as the number of slaves increases, this latency
becomes prohibitive.

With rpc.ypxfrd, all the slave has to do is copy the already-built
hash database file from the master and move it into place. Even with a
multi-megabyte file, this reduces the master to slave transfer time
to well under a minute. (This is using TCP.)

Access restrictions are applied using the same mechanism as in ypserv:
you can control access using /var/yp/securenets, and the server will
not transmit the master.passwd.* maps unless the transfer request originates
on a reserved port.

Note: this server is based on my hastily contrived protocol and is _NOT_
compatible with Sun's protocol of the same name. It can't be compatible
for a couple of reasons. For one thing, Sun's protocol has not been published
anywhere that I know of. It is not included in any of the SunRPC source
distributions that I've been able to find. Second, Sun's NIS v2 code
uses old style ndbm maps while FreeBSD uses Berkeley DB. The file formats
are incompatible, so being able to transfer maps between FreeBSD and SunOS
hosts wouldn't do any good anyway. (You could always port the FreeBSD NIS
code to SunOS if you really wanted to do it. :)

(There's also the little fact that SunOS/SPARC is big-endian and FreeBSD/i386
is little-endian. Berkeley DB can handle byte ordering differences; ndbm
probably can't.)

28 years ago(I hope I'm doing this correctly.)
wpaul [Wed, 5 Jun 1996 02:42:33 +0000 (02:42 +0000)]
(I hope I'm doing this correctly.)

Import a my own little ypxfrd protocol. Note that this protocol is
_NOT_ the same as Sun's, which is proprietary.

This basically impliments an RPC-based file transfer protocol which
lets a slave server suck over a raw map database file from the master.
This is many times faster than the normal method, which requires reading
the records from ypserv via yp_all() and then creating a new database
on the fly, particularly when you have many tens of thousands of
records in a map (e.g. a huge passwd database).

The protocol number I chose falls within the 'user-specified' range.
Maybe we should register it with Sun so we can get an official vendor
number for it. :)

28 years agoImport the new yp_mkdb. This one does what the old one does, but is
wpaul [Sun, 28 Apr 1996 04:16:06 +0000 (04:16 +0000)]
Import the new yp_mkdb. This one does what the old one does, but is
hopefully less grotty. Differences include:

- An extra flag, -c, for sending a YPPROC_CLEAR to ypserv(8) (which
  will become useful once I merge in the DB handle caching mods I've
  been working on).
- Checks for and signals duplicate keys.
- Handles line continuations.

As of now, there is no more GNU YP code in the tree.

28 years agoImport new rpc.yppasswdd. (Note: accompanying changes to passwd(1) and
wpaul [Mon, 12 Feb 1996 15:09:01 +0000 (15:09 +0000)]
Import new rpc.yppasswdd. (Note: accompanying changes to passwd(1) and
chpass(1) are on the way too.) This version supports all the features
of the old one and adds several new ones:

- Supports real multi-domain operation (optional, can be turned
  on with a command-line flag). This means you can actually have
  several different domains all served from one NIS server and
  allow users in any of the supported domains to change their passwords.
  The old yppasswdd only allowed changing passwords in the domain
  that was set as the system default domain name on the NIS master
  server. The new one can change passwords in any domain by trying
  to match the user information passed to it against all the passwd
  maps it can find. This is something of a hack, but the yppasswd.x
  protocol definiton does not allow for a domain to be passwd as an
  argument to rpc.yppasswdd, so the server has no choice but to
  grope around for a likely match. Since this method can fail if
  the same user exists in two domains, this feature is off by default.
  If the feature is turned on and the server becomes confused by
  duplicate entries, it will abort the update.

- Does not require NIS client services to be available. NIS servers do
  _NOT_ necessarily have to be configured as NIS clients in order to
  function: the ypserv, ypxfr and yppush programs I've written recently
  will operate fine even if the system domain name isn't set, ypbind isn't
  running and there are no magic '+' entries in any of the /etc files.
  Now rpc.yppasswdd is the same way. The old yppasswdd would not work
  like this because it depended on getpwent(3) and friends to look up
  users: this will obviously only work if the system where yppasswdd is
  running is configured as an NIS client. The new rpc.yppasswdd doesn't
  use getpwent(3) at all: instead it searches through the master.passwd
  map databases directly. This also makes it easier for it to handle
  multiple domains.

- Allows the superuser on the NIS master server to change any user's
  password without requiring password authentication. rpc.yppasswdd
  creates a UNIX domain socket (/var/run/ypsock) which it monitors
  using the same svc_run() loop used to handle incoming RPC requests.
  It also clears all the permission bits for /var/run/ypsock; since
  this socket is owned by root, this prevents anyone except root from
  successfully connect()ing to it. (Using a UNIX domain socket also
  prevents IP spoofing attacks.) By building code into passwd(1) and
  chpass(1) to take advantage of this 'trusted' channel, the superuser
  can use them to send private requests to rpc.yppasswdd.

- Allows the superuser on the NIS master to use chpass(1) to update _all_
  of a user's master.passwd information. The UNIX domain access point
  accepts a full master.passwd style structure (along with a domain
  name and other information), which allows the superuser to update all
  of a user's master.passwd information in the NIS master.passwd maps.
  Normal users on NIS clients are still only allowed to change their full
  name and shell information with chpass.

- Allows the superuser on the NIS master to _add_ records to the NIS
  master.passwd maps using chpass(1). This feature is also switchable
  with a command-line flag and is off by default.

28 years agoThis commit was manufactured by cvs2svn to create branch 'WPAUL'.
cvs2svn [Fri, 12 Jan 1996 07:03:35 +0000 (07:03 +0000)]
This commit was manufactured by cvs2svn to create branch 'WPAUL'.

28 years agoImport the new yppush.
wpaul [Fri, 12 Jan 1996 07:03:33 +0000 (07:03 +0000)]
Import the new yppush.

This program does what the old one did, PLUS:

- Supports parallel jobs (like the SunOS yppush)
- Does everything in one proces instead of fork()ing off
  children processes as callback listeners (this is done
  using async socket I/O).
- Can be used to transmit maps to user-specified hosts.
- Has a much more verbose verbose option.
- Reuses existing code from ypserv and ypxfr.
- Uses some rpcgen-erated code as well.
- Isn't fattening. :)

Note that this is going in /usr/sbin rather than /usr/bin like
the old one. yppush is an administrative command it it's anything.

28 years agoImport the new ypxfr, written by yours truly. Functionally equivalent
wpaul [Mon, 25 Dec 1995 03:07:13 +0000 (03:07 +0000)]
Import the new ypxfr, written by yours truly. Functionally equivalent
to the old one, except that it supports an additional option (-p path)
that lets you specify the top level path wiere your NIS maps live.
(ypserv allows you to specify a path like this, so it makes sense that
ypxfr should too. ypserv will automagically pass the -p flag to ypxfr
if you use a path other than /var/yp when you start it.)

This program uses client stub code generated by rpcgen as well as
the yp_dblookup.c module from ypserv.

28 years agoImport the new, non-GPL ypserv, written by yours truly. Functionally
wpaul [Sat, 16 Dec 1995 20:54:17 +0000 (20:54 +0000)]
Import the new, non-GPL ypserv, written by yours truly. Functionally
equivalent to the old ypserv, except that it doesn't support the
-p [port] option to force the server to use a particular port.

The server stubs and yp.h header file are auto-generated from the yp.x
protocol definition file. The auto-generated XDR routines in libc/yp
are also used. The database access code has been broken out into a
seperate module so that other NIS utilities (ypxfr in particular)
can use it.

Note that the old mknetid script is being temporarily moved here; it
will be replaced by an mknetid program which will eventually have
a home under /usr/src/libexec. (The existing script is actually
somewhat broken -- it doesn't handle hosts -- but this isn't a big
deal at this point since the netid.byname map is really only useful
fopr Secure RPC, which we don't have yet.)

28 years agoImport the first cut of my (finally finished) revnetgroup program. This
wpaul [Thu, 26 Oct 1995 16:25:29 +0000 (16:25 +0000)]
Import the first cut of my (finally finished) revnetgroup program. This
program parses the /etc/netgroup file into netgroup.byuser and netgroup.byhost
format for NIS.

I used hash tables to store the initial netgroup data in memory and to
construct the 'reverse' netgroup output. It seems just as fast as the
SunOS revnetgroup, which is surprising considering this is my first
attempt at using hash tables in a real application. :)

Note that I canibalized a large chunk of getnetgrent.c to save myself
from having to write my own netgroup parsing functions.