[ic] Upgrade procedure
emailgrant at gmail.com
Mon Jun 15 14:44:48 UTC 2009
>>>> Database variable scalar parameter VARIABLE.TXT redefined to "TAB", was "TAB".
>>> You have a duplicate Database line for your variable database. check
>>> your catalog.cfg and included files (including files in the dbconf
>>> directory and subdirectories).
>> You're right, I had variable.dbm in both dbconf/default_db and
>> dbconf/mysql. I noticed I also have identical access.dbm and
>> mv_metadata.dbm files in those locations. Does variable have special
>> handling in this case?
> Only the ones in the mysql directory should get pulled in. Check your
> catalog.cfg for an extra Database line for the variable file.
The message actually disappeared after I removed the line from
dbconf/default_db/variable.dbm. A bug maybe?
>>>> Warning while compiling UserTag 'ups_query':
>>>> "my" variable $result masks earlier declaration in same scope at
>>>> /usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm line 97, <SYSTAG>
>>>> line 154.
>>> This is an issue with Business::UPS and needs to be taken up with the
>>> author of that module. It is porobably safe to ignore the warning, though.
>> OK but should that usertag be disincluded from IC since it has a problem?
> If you're not using ups then you should be able to exclude the usertag
> without problems. I would not consider the warning you mention to be
> enough of a "problem" to merit removing the usertag from IC.
A fresh installation of IC throwing a warning upon start/restart seems
to me like it should be fixed, but it's not a big deal. I renamed
ups_query.tag to ups_query.tag.conflict and the warning disappeared.
Thanks a lot for all your advice. The upgrade went very smoothly thanks to you.
>>>> 3. I use Interchange::Link and I had to add "SocketPerms 0666" to
>>>> interchange.cfg. I get the following warning in the global error.log:
>>>> ALERT: /usr/local/interchange/etc/socket socket permissions are
>>>> insecure; are you sure you want permissions 666?
>>> If you trust everyone who has access to the server then you generally
>>> don't have to worry about that, but it's a good idea to fix it anyways.
>>> The proper way to fix it is to properly set the owner and suid
>>> permissions bit on your vlink file so that it can access the socket
>>> without requiring 666 permissions on the socket.
>> Do I need to stick with 666 permissions since I'm using
>> Interchange::Link instead of vlink?
> I missed that you're using Interchange::Link. I don't use that or know
> much about it so someone else will have to answer your question.
More information about the interchange-users