An Alternative to Reinstalling Informix SE 7.2....

A system administrator, while copying load-ready files from tape to our unix machine, inadvertently deleted the entire /usr/informix directory structure. Prior to this catastrophe, he had copied the directory structure (as root) under another directory location. He tried recovering from this mistake by restoring the /usr/informix directory structure from the backup, as I soon discovered, everything was owned by root now and then belonged to the system group. I changed the ownership and group attributes of all the informix files back to informix, but could not connect to the databse. I discovered that the permission flags on the database directories and the files inside weren't set right either. After creating a test database with a test table, I was able to use the permission attributes of the test database as a model restore the other database file permissions. After these shennanigans, I was able to connect to the database, but later, discovered that the users were still having problems running ISQL reports and forms.Are there any specific file permissions that the ISQL report and form components have to have? Other information: public has connect permission. Update,Delete,Select and Insert permission is granted at the table level for all users. The sys admin, temporarily added the users to the informix group (!) to allow the users continued access to the data, reports and forms. Is a reinstallation of informix (and then the subsequent recreation of the database and re-loading of data) the most effective solution to this problem? (And perhaps the revoking of the sys admin's root privileges!) Thanks --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---

mabin001@tc.umn.edu wrote: > > A system administrator, while copying load-ready files from tape to our > unix machine, inadvertently deleted the entire /usr/informix directory > structure. Prior to this catastrophe, he had copied the directory > structure (as root) under another directory location. He tried > recovering from this mistake by restoring the /usr/informix directory > structure from the backup, as I soon discovered, everything was owned > by root now and then belonged to the system group. I changed the > ownership and group attributes of all the informix files back to > informix, but could not connect to the databse. I discovered that the > permission flags on the database directories and the files inside > weren't set right either. After creating a test database with a test > table, I was able to use the permission attributes of the test database > as a model restore the other database file permissions. > > After these shennanigans, I was able to connect to the database, but > later, discovered that the users were still having problems running > ISQL reports and forms.Are there any specific file permissions that the > ISQL report and form components have to have? > > Other information: public has connect permission. > Update,Delete,Select and Insert permission is granted at the table > level for all users. > > The sys admin, temporarily added the users to the informix group (!) to > allow the users continued access to the data, reports and forms. > > Is a reinstallation of informix (and then the subsequent recreation of > the database and re-loading of data) the most effective solution to > this problem? (And perhaps the revoking of the sys admin's root > privileges!) Hmmm. What was wrong with the previous weeks backup of the system? It would be quicker to reinstall than to wait for this answer, too. However, the utils_jl package at the IIUG web site (http://www.iiug.org) has utilities for both checking and setting the file permissions under $INFORMIXDIR using the same files lists that the install process uses to install Informix software. This would probably work for you. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>