I posted this question once before, a couple of days ago, but never really got an answer...
Not attempting a flame war or anything, and I don't necessarily have a 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...
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. :-(
As the dbmopen seems to rely very heavily on the underlying dbm 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.
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: http://www.elilabs.com/~rj/chat/rj_chat_login.html
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.
Again, your post doesn't indicate you have done the required amount of homework to nail down where the actual incompatiblity exists.
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?
Being annoyed about this probably isn't going to help much, and maybe if 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......
http://danconia.org
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
