Different users on different instances?

Hi all, I have multiple IDS instances on the same server. Is it possible to install each instance using a different user (ifxinst1 or ifxinst2, instead of informix)? If so, what procedure should i follow to make it?

No. The server has to be owned by user informix. But you do not have to have a separate installation for each server instance. They can all share the same INFORMIXDIR, you just need a different ONCONFIG file for each instance with a different SERVERNUM and DBSERVERNAME/DBSERVERALIASES settings. Art S. Kagel ----- Original Message ----- From: Jose De Jesus Obregon Rizo <ids@iiug.org> At: 5/04 13:52:10 Hi all, I have multiple IDS instances on the same server. Is it possible to install each instance using a different user (ifxinst1 or ifxinst2, instead of informix)? If so, what procedure should i follow to make it? ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

As Art said, use informix as owner. Keep seperate ONCONFIG and ofcourse chunks etc. and then initialiase instances. We run a number of instances on same server. No issue. --- "ART KAGEL, BLOOMBERG/ 731 LEXIN" <kagel@bloomberg.net> wrote: > No. The server has to be owned by user informix. But you do not have to have a > separate installation for each server instance. They can all share the same > INFORMIXDIR, you just need a different ONCONFIG file for each instance with a > different SERVERNUM and DBSERVERNAME/DBSERVERALIASES settings. > > Art S. Kagel > ----- Original Message ----- > From: Jose De Jesus Obregon Rizo <ids@iiug.org> > At: 5/04 13:52:10 > > Hi all, > I have multiple IDS instances on the same server. Is it possible to install > each instance using a different user (ifxinst1 or ifxinst2, instead of > informix)? If so, what procedure should i follow to make it? > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Jose De Jesus Obregon Rizo <ids@iiug.org> asked: > I have multiple IDS instances on the same server. Is it possible to install > each instance using a different user (ifxinst1 or ifxinst2, instead of > informix)? If so, what procedure should i follow to make it? ART KAGEL <kagel@bloomberg.net> responded: > No. The server has to be owned by user informix. But you do not have to have a > separate installation for each server instance. They can all share the same > INFORMIXDIR, you just need a different ONCONFIG file for each instance with a > different SERVERNUM and DBSERVERNAME/DBSERVERALIASES settings. What Art says is accurate, but may not address the fundamental problem that I suspect Jose faces - having multiple instances on a single machine administered by different people. If the requirement is to have different people managing different instances on the same machine, you can achieve the effect, but everything still has to be installed by user informix. That means you have to as careful of user informix (and group informix) as you are with root. (If you aren't careful with root, you are hosed, regardless of what you do.) FWIW: I'm assuming a Unix environment - I'm not sure whether you can achieve this on Windows. OK - how do we go about this. First of all, ensure that no-one who must be constrained to a single instance of IDS has access to user informix or group informix privileges. Second, recognize that you will need multiple INFORMIXDIRs - one for each distinct set of administrators. If you are careful, you do not need separate copies of the basic software, but it is easiest if the INFORMIXDIRs are in fact completely separate. Third, note that if you enable role separation for the DBSA in each INFORMIXDIR, as long as your sets of admins are disjoint, you will have achieved the desired effect. How do you enable role separation for the DBSA? You change the group that owns $INFORMIXDIR/etc. That group is the DBSA group; as such they can administer the system via onmode, onstat, oncheck, onspaces, onparams, and so on. With one small change, they can start the server too; that change is to make the oninit executable 6755 (or 6711 or 6511 or 6111 mode - add public execute permission. (This is the only time I'm likely to tell you to relax the standard permissions - the default mode is 6754, no public execute permission. The change is safe; if you are not a DBSA, you will not be permitted to start IDS. So, if you want user ifxinst1 to administer instance1 and user ifxinst2 to administer instance2, then you will do: 1. Install software for instance1 in a suitable INFORMIXDIR (/usr/instance1, which might be a symlink to somewhere else). 2. Install software for instance2 in a second suitable INFORMIXDIR (/usr/instance2). 3. Create your administrator for instance1 - user name ifxinst1, group name ifxinst1 (for convenience). 4. Create your administrator for instance2 - user name ifxinst2, group name ifxinst2. 5. Change the group ownership of /usr/instance1/etc to (group) ifxinst1. 6. Change the group ownership of /usr/instance2/etc to (group) ifxinst2. 7. Consider setting the SGID bit on the two directories: 2775. This ensures that files created in the directory belong to the group that owns the directory (and hence, any files created in $INFORMIXDIR/etc will belong to the administrative group). 8. Prevent anyone su-ing to user informix (or sudo-ing, or logging in directl) and ensure no-one except user informix belongs to group informix. Anyone given access to those has control over all the instances. 9. Have root create the chunk files for the two teams; the files will be owned by user informix and group informix with 660 permissions. 10. The administrator ifxinst1 can now bring up their server(s) in their INFORMIXDIR (/usr/instance1); similarly, ifxinst2 can bring up the server(s) in /usr/instance2. Neither is able to control the other at all. Things to watch out for: 1. The sqlhosts files must be coordinated - and server numbers (server names also, but that is part of sqlhosts), etc. 2. If you don't want two lots of disk space for the software (it isn't that big; it is usually trivial by comparison with the disk being managed for the data in the databases), then check out the ixcreate script that is part of utils_jl from the IIUG Software Archive (http://www.iiug.org/software). * Install the IDS software once, in /opt/informix/10.00.UC5 (or somewhere else similarly appropriate) * Use "ixcreate -R /opt/informix/10.00.UC5 -L /usr/instance1 -lvd" to create /usr/instance2 with symlinks for all files but real directories under /usr/instance1. * Remove the symlink to sqlhosts; replace it with the appropriate alternative. * Set the permissions on /usr/instance1/etc as before. * Repeat (mutatis mutandis) for instance2. This gives you a reference copy of the software in /opt/informix/10.00.UC5, and two parallel setups which point to the reference software. Any configuration files that you might alter on a per-instance basis (which would be primarily sqlhosts - but you might need to worry about aaodir/adtcfg and dbssodir/seccfg, and maybe a few others) should also be created as separate files - break the symlink and copy the original from under /opt/informix/10.00.UC5 to the specific $INFORMIXDIR. Thereafter, the admins can work on their own instances and not on each others. Users root and informix are still largely unfettered - but they should not be administering the individual servers anyway. One of them has to be involved each time new storage is needed - but that was likely true anyway. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2007.0226 -- http://dbi.perl.org/ NB: Please do not use this email for correspondence. I don't necessarily read it every week, even.