John D. Rowell wrote:
> I guess jdresolve could be modified to be more portable
> database-wise, but I don't use windows machines, so it would be hard
> to really test it. OTOH, I've had several reports of people using it
> on that platform (with ActiveState Perl I think) with good results
> (dunno about the database part). If the main reason to use it is to
> have access to the recursive lookups, I guess that just commenting
> the "use DB_File;" line would be enough, as the code only performs
> database operations if you tell it to (with the "--database" option).
Well, AFAIK, Berkeley DB does not run on Windows. So you'd have to
remove that line to make it work. You could change it to something less
strict, like this which would not require it unless the database option
were specified:
if( $opt{'database'} ) {
eval( 'require DB_File' ) ||
die $@;
}
> To get the performance improvement (huge) from using the database,
> we'd have to find out which database types are supported under
> windows. Is there such a thing as a ssh daemon for Win32? ;)
Well, Windows does support many of the DBI databases like MS SQL Server,
Oracle, Sybase, most ODBC, and CVS. And the whole point of DBI is to
separate the database driver from the script. So users would just need
to set a drive and datasource option to use it (and have the write
modules installed, of course).
Getting sshd to run on Windows is a pain and not something most people
are likely to do
(http://www.google.com/search?client=googlet&q=sshd%20windows). There
are several good ssh clients for windows. I'm not sure how this relates
to jdresolve though.
Another feature that might make it easier for Windows (< 2000) users
would be compiling the script into an executable (ActiveState PDK has a
tool to do this). Although at this point it seems that anyone running
jdresolve and Analog and Report Magic should really just install Perl. :-)
> BTW, the reason for not using a flat file is that most people
> resolve _huge_ logs, and the host data simply would not fit in RAM.
> Also, using Berkeley DB or other high quality dbs, you get good
> caching and the performance penalty for doing the db lookups is
> negligible.
Ok, and I assume the same thing applies to the DBD::CVS module. I did
not look to closely into the software so I didn't know if some DB
interface was required for caching or if it was just an option for
improved caching (as it appears).
--
Jeremy Wadsack
Wadsack-Allen Digital Group
+------------------------------------------------------------------------
| This is the analog-help mailing list. To unsubscribe from this
| mailing list, go to
| http://lists.isite.net/listgate/analog-help/unsubscribe.html
|
| List archives are available at
| http://www.mail-archive.com/[email protected]/
| http://lists.isite.net/listgate/analog-help/archives/
+------------------------------------------------------------------------
