I have had to relocate my business and its network to another state. As a result, I had to change my internet connection. The new arrangement required that I use l2tp tunnelling, so I had to upgrade the fireware to redhat 9 to accomodate this (it was RH 6.1!). The upgrade seemed like a good idea, so I upgraded *ALL* the machines to rh9. This caused some grief with my web server (formerly RH 7.x), as it caused apache to upgrade from 1.3x to 2.0.x, which meant all my config files were history. :-(
Now that I have a workable apache config setup, I discover that some of my cgi scripts written in perl no longer work because rh9 also upgraded my perl from 5.6.x to 5.8.0, and 5.8.0 no longer has the dbmopen call working the same way. Apache also now runs under username apache, instead of nobody like it used to. I changed the ownership of the db file, but alas, still no joy. Here is an excerpt of the code that fails: # open the username/password database or create it dbmopen(%passwd, $passwd_db, 0600) || die "cannot open $passwd_db: $!"; And here is what gets logged in /var/log/httpd/error_log: [Fri Nov 21 12:12:59 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 Obviously, from the viewpoint of perl 5.6.x programs, perl 5.8.0 has a very broken dbmopen. Of course the file exists! Its a passwoed database; you can't go creating that new every time you want to use it! So why can't it open it? I have a number of other places where dbmopen is used to implement a hash as a disk file, and I really do not want to have to go and redesign the logic of all those programs to make them work. Surely I am not the first person to hit this problem. Surely there is some simple compatibility fix for this. Can somebody suggest a fix? I *HATE* upgrades! -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
