Hello,
Here is my original posting:
Has anyone succesfully manage text files with NIS such as motd?
I am running into several problems:
1. There seems to be an upper limit to the number of lines that
the text file can be.
2. The line order of the text file gets all screwed up. For
example, the 5th line may come before the 1st line and so on.
Here are the responses:
Peter.Samuel@nms.otc.com.au (Peter Samuel):
NIS stores its information in ndbm(3) files. There are two major points
of note when using ndbm files:
The order in which information is stored bares absolutely NO
resemblance to the raw data input. This is a result of the hashing
algorithm used by ndbm.
The size of key/data pairs cannot exceed the internal block size which
is 1024 bytes.
This explains your problems described above.
Now, ways around them. Whenever I need to retain the order of an NIS
map is use numerically increasing keys and then match on them. So in
your case line one will have a key of 1, line two will have a key of
2, etc. Then whenever you need to extract the information you start at
key 1 and then repeatedly ypmatch the next numeric key until you
fall off the end of the map. IE you see the following error:
Can't match key 120 in map xxx. Reason: no such key in map.
As for an upper limit on the number of lines allowable, ndbm files can
store *LOTS* of data. All the answerbook indexes are ndbm files so I
doubt very much that your are making an /etc/motd *that* big. What
could be happening is that you are trying to store lines with
duplicate keys. Within an ndbm file the keys MUST be unique. If you
use duplicate keys only one of the duplicate data fields will be
stored - and there's no guarantee as to which one it will be either.
If you adopt the numerically increasing key scheme as described above
then you won't have duplicate keys which may solve your size
problems.
The other possibility is that you're trying to store paragraphs,
rather than lines. In this case you may be overstepping the key/data
size limit of 1024 bytes (your mileage may vary - check the ndbm man
page). If this is the case, try storing on a line by line basis
instead.
stern@sunrise.East.Sun.COM (Hal Stern - NE Area Systems Engineer):
this is hard to do, because the keys are inserted into a database,
which is then read back in random order. the best hope i can offer
you is to take your motd file, number the lines, t hen pump
them into an NIS file. when you read them back out on machine X,
sort the lines (and strip off the numbers) to get your original text
in order.
lines can't be longer than 1024 bytes, including the key. this
is a limitation of the DBM database used for NIS maps.
"Daniel E. Zegarac" <zegarac@gdls.com>:
Correct on both. NIS does have a line length limit and it manages
single line databases like the password file, but does not maintain the order.
If you want to do what you are trying, you will have to substitute some
character or character string for the end-of-line character when you do a make
on motd and another when you extract. O'Reilly & Associates, Inc has a good
book called "Managing NFS and NIS" by Hal Stern (of Sun Microsystems) which has
a chapter on doing something like this.
paulo@jaguari.dcc.unicamp.br (Paulo Licio de Geus):
ndbm will change the lines of its keys so that access is faster, so
your approach is not sound.
To propagate text files accross machines, we use makefiles (we also
change specific parts of specific copies, according to the name of the
host). You could also use rdist, and there are other ways to achieve
the same...
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:13 CDT