Re: Caldera installation - something Debian should learn
On Fri, 23 Apr 1999, R Garth Wood wrote:
> On Sat, 24 Apr 1999, Remco Blaakmeer wrote:
>
> > I use sql almost every day and I haven't yet seen regular expressions in
> > it. Also, sed is one of the most powerful search-and-replace tools I have
> > ever seen (I have never taken a good look at perl). Would you re-implement
> > that in the database?
>
> Ya you wouldn't have to do that if the database is designed correctly.
Ok, so show a database design that covers it all. And besides, why do you
think I wouldn't need to use regular expressions when searching
configuration data?
> > Storage space on backup media is not really much of an issue, if that's
> > what you mean. My /etc occupies 2843 kB disk space in total. There are
> > 1193 files in it, the largest of them being 90 kB large. If you can detect
> > if individual files have changed (and you can, in several ways), you only
> > need to make a backup of files that have changed. You could make
> > differential backups using time stamps to check if files have changed
> > since the latest backup, and using a few very simple and age-old unix
> > tools to back them up onto a 3.5" floppy disk or whatever media you use
> > for backups.
>
> I think our backups are in the GBs every night. That's with the
> traditional tools. There is the problem that what if you have
> to restore and the restore spans multiple cds(whatever). In
> this case getting a image of said host is not easy but with some
> decent software you should be happy.
We're talking configuration parameters here, not normal data, right? You
can back up /etc on floppy disks if you like, it's not that big.
> > Not important. For sendmail speed is important, but that's the only
> > example I know of. And the syntax of sendmail.cf has been optimised for
> > parsing speed, so any db will probably score worse anyway.
>
> Hmm you think so? Why?
Apache is started only once, at boot time. What does it matter if it takes
5 seconds to parse the configuration files (it doesn't)? With sendmail it
matters, since it can be started many times per second if you have a very
busy mail host. That's what I meant.
> > > high-availibility
> >
> > Text files are always available. Database servers can crash. What's your
> > point?
>
> Nono. I mean as a network service. You could have many servers
> acting as one to serve data.
Sure, serve all the data you want to serve. But I'd like to have the
system configuration files around even if the network is in a
non-functional state. You can use standard unix tools to distribute
configuration files across the network, anyway. I don't see the big
advantage here.
You might need to have several database servers acting as one. They might
create about 2BG of differential backups every day. But that's a whole
other world than storing configuration parameters.
> > > > > 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?
> > > >
> > > > ??? what problem is this? it's still easy to type "sed" or run vi.
> > >
> > > With a database either it was committed or not. With vi over a modem
> > > it's painful. Also with on;y telnet you have to think about security.
> >
> > With vi, you have either written the file to disk or you haven't. It's
>
> But you must restart the service.
And if you store the configuration data in a database you don't have to
restart it? What's different? Besides, many daemons can be signalled to
re-read the configuration files without restarting them, anyway.
> > just the same. If you think vi over a modem is a pain, it might just be
> > that you don't know vi well enough. And ssh is a very good alternative for
> > telnet.
>
> Hence the qualier "only". If you didn't have telnet you'd be screwed.
????? There is a very good alternative for telnet, yet if I didn't have it
I'd be screwed? Why can't I see the logic in that? Any if you're worried
about security you shouldn't use telnet anyway, but that's another
discussion.
> > > This is one of the major points, though. You don't need grep, sed,
> > > etc.
> >
> > Why do you think so?
>
> you have the databases' own language(ie sql).
SQL is not nearly as powerful as grep if you are searching configuration
data. What if you are searching for some regular expression in every
column of every table? And what if you also want to search table names and
column names? With text files, grep is your friend. With SQL, you'd be
screwed.
Example of this: try to change a computer's hostname and find every
occurrence of the old hostname in configuration files to replace it with
the new name. And don't say you could store it only once with a properly
designed database, because that's just not true.
> > Now, consider something else. Suppose dpkg is upgrading a certain program.
> > I have edited its configuration file before, but the default configuration
> > file that comes with the program has also changed. Maybe it now has a
> > different format than before, or the author has decided to use different
> > default values, or there is another reason for it. Dpkg then asks me about
> > this, so that I can investigate the issue (using normal tools like 'diff')
> > and tell dpkg what to do. How would you do that if the configuration data
> > was stored in a db?
>
> checksum.
Checksum of what? You can make checksums of text files, but how about data
that's stored in a database? How do you make checksums of that?
You are making all sorts of arguments to tell everyone here that using a
database can be just as good. Well, show it. I am not yet convinced.
Remco
--
rd1936: 11:15pm up 12 days, 23:11, 9 users, load average: 1.08, 1.05, 1.01
Reply to: