Professional Web Applications Themes

dbmopen compatibility from perl 5.6 to 5.8 - PERL Beginners

I posted this question once before, a couple of days ago, but never really got an answer... 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. :-( 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) ...

  1. #1

    Default dbmopen compatibility from perl 5.6 to 5.8

    I posted this question once before, a couple of days ago, but never
    really got an answer...

    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. :-(

    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.

    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?

    Thans to all the helpful people on this list!
    Robert Brown Guest

  2. #2

    Default Re: dbmopen compatibility from perl 5.6 to 5.8

    Robert Brown wrote:
    > 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: [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.
    >
    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......

    [url]http://danconia.org[/url]

    Wiggins D'Anconia Guest

  3. #3

    Default Re: dbmopen compatibility from perl 5.6 to 5.8

    Wiggins d'Anconia writes:
    > Robert Brown wrote:
    > > 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...
    Please excuse my frustration. I am updating a bank of servers from
    various versions of RedHat, Mandrake, openBSD, and netBSD, so that
    they all run the same current version of RedHat 9. This is occurring
    concurrently with moving over 400 miles to a different state, changing
    the network topology, and having to get a new internet connection that
    involved 2 isp's, one of which is the phone company, who could not
    give me a cidr block of static ip addresses, and the other isp I have
    to tunnel to to get my cidr block and routing. It has been very
    painful. The perl thing is just a small part of the ulative
    frustration. I did not mean to sound ungrateful to the perl
    developer's community.

    And no! M$ is not an option. I have been running emacs since 1986,
    Unix since 1989, and Linux since 1993. There is no way that I would
    switch to anything that was not open sourced and unix based now.

    It did suprise me that the doentation I was able to find indicated
    that dbmopen should be replaced with "tie", and that the construct was
    not a line for line change, but a methodology change. This is what I
    meant by breaking legacy code. And while one machine was running RH
    6.1, the web server that the perl scripts in question run on was
    actually running RH 7.3.

    I guess what I am looking for is a dbmopen that will behave the same
    way the old one did, even if I have to unload and reload the old files
    into new ones using the technique you described -- unloading under the
    old version of Redhat, and reloading under the new version.

    My understanding was that dbmopen is no longer recommended, and that a
    single call to dbmopen now needs to be replaced with multiple lines of
    logic to determine if the file exists so it can be created if not, and
    then opened either way, and the whole thing was totally confusing to
    me.

    Does dbmopen still work, and it is the underlying database support
    tools that are called by default that have been changed, or is dbmopen
    out the window and tie is in in its place, or what? If it is only the
    default database implementation that has been changed, how can I
    determine what the old default was, and how can I force the new perl
    to use than mechanisim instead of whatever its new default is? Or is
    this even possible? It could at least save me downgrading a machine
    to dump the old database files.

    And yes, you are right about md5 hashes. They should port to the new
    implementaion even if they do look like alphabet soup. The md5 hash
    of a password is still the same, whatever it is implemented with and
    running under.
    Robert Brown Guest

Similar Threads

  1. Off Topic: Active Perl Native Windows / cygwin perl
    By Paul Kraus in forum PERL Beginners
    Replies: 1
    Last Post: January 5th, 07:56 PM
  2. dbmopen problem
    By Joel Newkirk in forum PERL Beginners
    Replies: 9
    Last Post: December 11th, 11:03 PM
  3. dbmopen replacement in perl 5.8.0
    By Robert Brown in forum PERL Beginners
    Replies: 3
    Last Post: November 22nd, 01:00 AM
  4. Inline-CPP and 64-bit perl compatibility?
    By Jeff in forum PERL Modules
    Replies: 1
    Last Post: October 11th, 04:58 AM
  5. File type compatibility issue with Perl
    By \Dandy\ Randy in forum PERL Miscellaneous
    Replies: 4
    Last Post: July 28th, 12:27 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139