drieux writes: > > On Friday, Nov 21, 2003, at 10:40 US/Pacific, Robert Brown wrote: > [..] > > > > # 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 guess the first question I would ask is which > DB_FILE format were you using under 5.6.x that > seems not to have arrived in 5.8.0.
Whatever DB_FILE format was the default under perl 5.6.x and Linux 7.x was it, as I did nothing to specify any particular format, so I guess I got the default. In particular, it would be *VERY* inconvenient, to say the least, to have to change formats when I cannot read the old file, as I do not know what usernames and passwords other users might have stored in it; all I know is my own. Since passwords are stored MD5 encrypted, there is no easy way for me to recreate this database in a new format, unless I can read the old format. And if I can read the old format, why would I want to change formats anyway? I suspect this file -- and the other files used by other scripts as well -- was either Berkeley or Gnu format DB, but I really don't know. I used to "just work", and now its yet another componet broken by the latest "improvement". :-( > the dbmopen() > > I remember hoving some issue with dbm/ndbm... > > perl the 'perldoc DB_File' it notes that if you > are going to use the newer versions of Berkley DB 2.x or 3.X > you will want to use BerkleyDB. > > cf: > <http://search.cpan.org/~pmqs/BerkeleyDB-0.25/BerkeleyDB.pod> > > It is possible that this has happened 'under the sheets' > for you with the shift from 6.x to 9.x so you will need > to essentially dump the old format into a new format, > assuing that is the real issue here. > > the alternative of course is the simpler problem of > permissions, and that the web-server can not actually > read the file. Do you have a piece of test code that > merely opens and reads it? The perms problem was actually an ownership problem. The fine folks at Red Hat changed the username that Apache runs ynder from "nobody" to "apache". While this sounds like a good idea at first glance, it means I have a lot of files to change from nobody to apache, and some of them probably still want to be owned by nobody, as they are probably not being used by Apache anyway, but some other precess that still does run under nobody. I originally could not open the file because of perms, but I fixed that by chown-ing it to apache. Now the problem is that it refuses to open it because "file already exists", which tells me that the description of dbmopen() that says "open the db file or create it if it does not exist" is no longer accurate. Is theree some conversion utility that I can use to read the old file and write a new one in a more desirable format? > ciao > drieux > > --- > > > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
