Robert Brown wrote:Not attempting a flame war or anything, and I don't necessarily have a> I posted this question once before, a couple of days ago, but never
> really got an answer...
solution but your original post sounded very ungrateful towards the Perl
development team and maintainers and may have been the reason why it
didn't solicit any response. But that is just how I read it, maybe just
no one knows...
As the dbmopen seems to rely very heavily on the underlying dbm>
> I have numerous perl scripts, mostly cgi's, that open numerous
> password database files implemented as persistent hashes in perl
> code. I recently upgraded from an earlier version of Red Hat Linux to
> version 9. This included an upgrade from perl 5.6.x to perl 5.8.0.
> The new behavior of dbmopen has broken a lot of stuff on my
> server. :-(
libraries as someone else, maybe drieux?, mentioned your problem
probably arises from your extreme jump from RH 6 to RH 9 which also
results in what is a gigantic jump in dbm versions. Calling this a Perl
backwards compatibility problem may not be accurate here.
Again, your post doesn't indicate you have done the required amount of> Here is a snippet of perl code where such a failure is occurring:
> # open the username/password database or create it
> dbmopen(%passwd, $passwd_db, 0600)
> || die "cannot open $passwd_db: $!";
> This used to work flawlessly, but now it fails, with the following
> entry in /var/log/httpd/error_log:
> [Mon Nov 24 21:46:45 2003] [error] [client 192.168.1.3] cannot open /home/rj/chat/login.db: File exists at /var/www/cgi-bin/rj_chat_login.cgi line 109., referer: [url]http://www.elilabs.com/~rj/chat/rj_chat_login.html[/url]
> It seems to me that the legacy behavior of dbmopen has been broken by
> the new version of perl. Since this will require finding and fixing
> every line of code that used dbmopen in pre-existing perl scripts, I
> just cannot imagine that the implementors of the new version of perl
> did not provide some compatibily with the old behavior. It is one
> thing to depricate a construct and recommend against using it in new
> code, and another thing altogether to just eliminate the construct,
> thereby breaking countless pre-existing programs that used to work.
homework to nail down where the actual incompatiblity exists.
Being annoyed about this probably isn't going to help much, and maybe if> What is the workaround or fix for this? I am going to be intensely
> annoyed if I have to go edit large numbers of old perl scripts to
> change the way my persistent hashes are opened, including the logic of
> creating the file if it does not already exist. What do I need to do?
you (the royal you) spent more time maintaining your scripts and OS
software so they weren't 5 years behind you wouldn't have to make so
many changes now, but you can hardly complain about that. The amount of
time you should have spent over the last 5 years has now caught up with you.
Maybe you should also look at this as an opportunity to move into a more
open model and refactor the legacy code into an updated open cross
platform standard, etc. The work around is to fire up a RH 6 box,
install the legacy code, write a short snippet to dump the file into a
data structure or flat file that can then be read by a newer script and
reconverted into a new dbmopen functional script.
You mentioned your passwords not being readable, if they are just md5
hashes as you suggested it doesn't matter whether you can get to the
original passwords or not, the hashes will not have changed no matter
what version of dbm or Perl or any software you use that is the nature
of the md5 as a universal algorithm than some closed proprietary technology.
Remember who the gift horse is here.... Don't like it? There are people
in Redmond who will gladly take your money to make their software work
from all those lost bits from 1986......