Re: Caldera installation - something Debian should learn
In message <[🔎] Pine.LNX.4.10.9904230955250.1683-100000@peace.netnation.com>, R Gar
th Wood writes:
> On Fri, 23 Apr 1999 tho@thomsen.isdn.cs.tu-berlin.de wrote:
>
> > > > > I have read it. Keeping data in a text file that needs to be parsed
> > > > > is an antiquated notion that needs to be eliminated. The information
> > > > > contructs are correct, however.
>
> Note: I have been corrected. The above solution could have an arbitrary
> back end.
So, we're keeping the text file based configuration? Than I don't have to
care further. :-)
>
> > > > no no no! keeping data in a text file may be an old notion, but is not
> > > > antiquated and *definitely* does not need to be eliminated. quite the
> > > > contrary, in fact. text files for configuration information are Very Go
> od
> > > > Things (tm) because *text files can be edited however one wants*. forci
> ng
>
> So can a database.
Right, but not with that wide spread collection of tools.
>
> > Right. This is the Unix spirit. Use a small orthogonal set of simple tools
>
> "spirit"? Well if you have some sort of religous attachment to text files
> then I can't convince you.
Please exchange 'spirit' by 'idea behind of', in contrary to 'Eierlegende-
wollmilchsaeue' (is there a translation for this term? best I can think of
is 'one-tool-does-it-all') like Netscape and StarOffice.
I'm just (very) suspicious, because I made the experience, that the tools
provided by (most) Unices are better fitted to handle server configuration
than the NT registry editor. E.g. remote administration or administrating
a whole bunch of similiar servers (like a web-server farm). On a single
host it may not matter so much and joe average might like a point and click
interface better.
IMHO text based configuration files are an inherent part of Unix. An OS
without them might prove better (easier to administer) or worse, but it
wouldn't be Unix anymore. I'm serious about that. Would there still be a
need for sed, grep, awk or vi? Does it even need a shell? Some like to get
rid of those, since they don't need them anyway and never learned to use
them (or the other way round?). For the new OS one might wish kde/gnome
based tools. I'll bet many will stay for a nother decade with traditional
Unix.
Well, I guess I have an attachment to Unix, but I wouldn't call it religious.
You must understand me, compared to CP/M (you remember?), DOS, Windoze XX
and even VMS, it's so lovely. (Now don't call it amorously ;-)
>
> I think we should make the distinction here between *data* and a config
> file. sendmail.cf is a language with variables in it(the data).
>
> > together to solve a given Problem. With text files I can grep through them
> > or change them with sed on the fly. With binary config files, like on NT, I
>
> With a database you can change the data with SQL or what have you.
Again, not with the tools I'm used to and have proven to be handy.
>
> > have to use the given tools. Either the problem is solvalble with them or
> > you're doomed.
>
> I would never say that windows * registries are the optimal solution.
> They are the right idea, though, just a bad implementation.
Is there a 'good' implementation?
Another defency of NT registry: If I have to reinstall NT (happend in the
past, will happen in future) I have to reinstall most applications even
although they are stored on a seperate (and integre) media, because not
only system configuration, but also application and even user data is stored
there.
>
> > > In fact I believe that's their most glaring weakness. Enevitably popular
> > > software has more and more parsers that read and write it's config files.
> > > Note that they are DIFFERENT parsers(not equivalent ones). For any
> > > dataset there should only be one way to access the data(one API for
> > > example). This ensures that work is not duplicated. THIS is a good thing.
> > How many freeware/shareware/commercial registry editors exist for NT ?
>
> I don't use NT too much. I'll bite: how many?
I have to confess, it was a rhetorical question; I have no idea. I just saw
several, say half a dozen (yes, much less than different parser
implementations ;-) or so. The point is, there is no single right one. The
more, the better (the more likely is, you'll find one, you like and
solves the given problem). And Unix knows dozens of tools to modify text
files.
>
> > > What about differential backups?
> > Yes, what's about them?
>
> It should be ovious.
Sorry, _that_ wasn't a rhetorical question. I don't see the difference
between text and binary files in respect to back-up.
>
> > BTW: text files fit much easier in a version control system like CVS.
>
> All good databases the same mechanism and better performance.
Right, but can I see the diffs?
> I believe cvs does binary files now as well.
CVS can handle binary files to some degree, but can't give you the (then
meaningless anyway) diffs.
> g an
> > >
> > > Who said you cannot dump the database to a text file?
> > Text files. The web-admin should be able to edit the config file(s) for th
> e
> > httpd, but not necessarily for the MTA. With many files you can exploit
> > Unix file permissions for access control, with a central DB you have to
> > invent some alternative scheme. And the past shows, that it's non-trivial
> > to get security right.
>
> Sure different databases, different permissions.
Point.
>
> > PS: Look at SuSE's yast/rc.config for a warning.
>
> Hmm. Don't have a SuSE box around here.
>
>
> To sum up:
> Databases offer:
> better speed
Is there a need to improve time efficience for reading config. files? I
do not really care, if the servers take 1 or 2 minutes to boot-up. I care,
if the sendmaild takes 1 or 2 hours to get the mailing list out, but not
if it takes 5 or 0.03 seconds to parse the configuration file.
> smaller size.
for configuration files? Your kidding. In an other mail you estimate the
total size to be less then 10MB - so what?
> other inhereted database properties
I'm not too familiar with DBs. What other properties could help system
configuration?
> text files have:
> the "advantage" that they can be edited easily
> consider: what if you're logging in remotely and they
> only have telnet or it's a slow connection?
Yes, happens all the time. I can deal with that. Sometimes, I wished to
have a line-oriented ssh. Why the parantheses? Can you imagine the fact
to easily edit config files a disadvantage?
> ppl are used to them
> this I think is the strongest point. Retraining
> is a major concern.
Right, Unix is out for about 30 years (as am I ;) And importance of the
fact, that it is still there and is quite well documented shouldn't be
underestimated.
> they are not NT
I regret to have used the word 'spirit' above. Sorry to mention M$ product
all the time, but I haven't dealed with any other binary config system
so far.
>
> Also note the difference bt _data_(uid=0) and a program(sendmail.cf).
??? I guess I understood your wish to seperate between configuration
variables ('keys' in the NT registry, right?) and the data assigned to
them in a configuration file/registry, but what is meant by uid=0? Should
the data be accessed by root (setuid process) only?
Guenther
Reply to: