Re: Question about permissions used on onconfig and sqlhosts files

Colin Bull wrote: > > Having just gone through the routine of installing 9.4 without > overwriting 7.31, I just wish this advice had been followed > earlier. We live and learn. There is only so much you can do > with symbolic links. Very true; I'm keen to try a bit of chrooting too. My latest fashion for production installs is to put each product in /SOMEWHERE/informix.731 (for example) and THEN setup a symlink from /SOMEWHERE/informix pointing to the current production install. This way, a fall-back is as simple as re-pointing the symlink (oh, and the engine upgrade rollback). This approach also means that precicely zero scripts need editing to change the value of $INFORMIXDIR. If you need more than one engine in production, then it's still reasonable to have a few symlinks such as /SOMEWHERE/informix.prod, /SOMEWHERE/informix.web, /SOMEWHERE/informix.dw, and make them point to the appropriate install directory; once again, saving the need to edit any scripts or config files. I find this plan is less effective for development machines, because we often want multiple engines running simultaneously for either testing or pragmatic reasons. However, we've got shell functions which flip shell variables all over the place, even automatically just by performing a cd, so that different style in development works well.

On Tue, 28 Oct 2003 17:46:33 -0500, Andrew Hamm wrote: Andrew, I also have promoted and used this approach for many years. It saves a s*&^load of trouble anytime we have to upgrade or downgrade. I'm with you. Art S. Kagel > Colin Bull wrote: >> >> Having just gone through the routine of installing 9.4 without overwriting >> 7.31, I just wish this advice had been followed earlier. We live and learn. >> There is only so much you can do with symbolic links. > > Very true; I'm keen to try a bit of chrooting too. > > My latest fashion for production installs is to put each product in > /SOMEWHERE/informix.731 (for example) and THEN setup a symlink from > /SOMEWHERE/informix pointing to the current production install. This way, a > fall-back is as simple as re-pointing the symlink (oh, and the engine upgrade > rollback). This approach also means that precicely zero scripts need editing > to change the value of $INFORMIXDIR. > > If you need more than one engine in production, then it's still reasonable to > have a few symlinks such as /SOMEWHERE/informix.prod, /SOMEWHERE/informix.web, > /SOMEWHERE/informix.dw, and make them point to the appropriate install > directory; once again, saving the need to edit any scripts or config files. > > I find this plan is less effective for development machines, because we often > want multiple engines running simultaneously for either testing or pragmatic > reasons. However, we've got shell functions which flip shell variables all > over the place, even automatically just by performing a cd, so that different > style in development works well.

Andrew Hamm wrote: > > Colin Bull wrote: > > > > Having just gone through the routine of installing 9.4 without > > overwriting 7.31, I just wish this advice had been followed > > earlier. We live and learn. There is only so much you can do > > with symbolic links. > > Very true; I'm keen to try a bit of chrooting too. > > My latest fashion for production installs is to put each product in > /SOMEWHERE/informix.731 (for example) and THEN setup a symlink from > /SOMEWHERE/informix pointing to the current production install. This way, a > fall-back is as simple as re-pointing the symlink (oh, and the engine > upgrade rollback). This approach also means that precicely zero scripts need > editing to change the value of $INFORMIXDIR. Being doing this for years, makes life so easy. re: scripts, all our scripts source a single environment file so if you do need to change INFORMIXDIR, edit one file and every body knows On dev boxes, we just run things like on920, on931, se726 etc and these scripts flick the environment over > > If you need more than one engine in production, then it's still reasonable > to have a few symlinks such as /SOMEWHERE/informix.prod, > /SOMEWHERE/informix.web, /SOMEWHERE/informix.dw, and make them point to the > appropriate install directory; once again, saving the need to edit any > scripts or config files. > > I find this plan is less effective for development machines, because we > often want multiple engines running simultaneously for either testing or > pragmatic reasons. However, we've got shell functions which flip shell > variables all over the place, even automatically just by performing a cd, so > that different style in development works well. -- Paul Watson # Oninit Ltd # Growing old is mandatory Tel: +44 1436 672201 # Growing up is optional Fax: +44 1436 678693 # Mob: +44 7818 003457 # www.oninit.com #