Re: onconfig file

You can also change archive settings in the onconfig file...at least that has been my experience with some of the later 7 and 9 engines. I would not think that its onmonitor that makes these changes possible dynamically, rather its more likely to be a feature of the engine itself. Personally I would not recommend onmonitor as the primary means for administration of a system. Its fine for viewing info but I think its better to use the underlying commands when doing such things as building new instances, adding lots of chunks, logs and so forth. I'd agree with Johnathan about the security aspect of links, although I do use them myself since its convenient to keep a set of onconfig files tuned for different aspects of system management [load, index rebuild etc]. I guess I could always have used some form of source control system and had a different branch for each of the files... Mark ----- Original Message ----- From: "Martin, Wayne E." <WMartin@kmart.com> To: "'Jonathan Leffler'" <jleffler@earthlink.net>; <informix-list@iiug.org> Sent: Tuesday, June 10, 2003 07:28 Subject: RE: onconfig file > Onmonitor allows the Logical and archive tape to be up dated in a running > database instance. This helps us who support 24X7 database instances. > > > > Wayne Martin > Database Administrator > Kmart Corporation > > -----Original Message----- > From: Jonathan Leffler [mailto:jleffler@earthlink.net] > Sent: Tuesday, June 10, 2003 1:19 AM > To: informix-list@iiug.org > Subject: Re: onconfig file > > Malcolm Weallans wrote: > > The system administrator at my current site thought he would be very > > clever and he linked the onconfig files to different directories using > > ln -s. We have now discovered that these links are being lost when we > > use onmonitor and replaced by a local file, but not when we use vi. Is > > this yet another reason why we should not use onmonitor? Does anybody > > else think that onmonitor still has a role in teaching IDS to > > prospective admins? It is still documented in the manuals so > > presumably it should still work. > > > > regards > > > > Malcolm > > P.S. I am having to use google groups to post messages as info > > security here has to be seen to be believed. > > > I keep a central repository of onconfig files - by using symbolic > links from the repository to the actual various INFORMIXDIR locations, > precisely because of this problem. When I backup the central > repository, I use a command that is oblivious to the symlinks and > simply copies the files through the symlink (that is not tar, nor > cpio, nor pax, but good old cp). OTOH, I keep a central sqlhosts file > with symlinks from the various INFORMIXDIR locations to the central > version. > > ON-Monitor is within its rights to expect its file to be local, and to > expect to be able to rewrite it by removing the old version and > creating the new. It does so. That breaks links - hard and symbolic. > > No, it is not the only way it could be done; it is, however, the way > it always has been done. If I had my druthers, then oninit would > probably refuse to have anything to do with an onconfig file that was > not as secure as it should be. That would mean a variety of things - > such as $INFORMIXDIR being properly owned and all directories on the > path to it being sufficiently secure (owned by root, bin, or sys and > not writable by group - or only limited groups - or others). If > symlinks were to be allowed, then the symlink would have to equally > secure - which is hard to establish. I'd be happy to keep it that the > onconfig file was local to INFORMIXDIR. > > You can arrange to get a feature request entered to have ON-Monitor be > more careful about symlinks and hard links. However, I'm not > convinced it is a bug per se (hence feature request), and I'm fairly > sure it would not get a very high priority unless the security of the > onconfig file is being upgraded - whereupon it would probably be fixed > as a side-effect of the upgrade. > > As to whether ON-Monitor still has a role - the feedback we get every > time we've attempted to drop it is "Give me my ON-Monitor back". So > it does get used. Personally, I use it for one thing - to get the > NETTYPE entries right. When onconfig.std includes a prototype of a > NETTYPE entry (so I don't have to remember what the fields mean), then > I will have no use for ON-Monitor. It does list the databases - with > owner and mode - which is convenient, but the information is also > obtainable from sysmaster. So, it has very limited value to me, but > the cries from the field indicate that it is still widely used. > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/ > > > This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. > >

"Mark Denham" <mkdenham@attbi.com> wrote in message news:bc4qlv$et9$1@terabinaries.xmission.com... > > You can also change archive settings in the onconfig file...at least that > has been my experience with some of the later 7 and 9 engines. I would not > think that its onmonitor that makes these changes possible dynamically, > rather its more likely to be a feature of the engine itself. > Once transaction logging to a device (LTAPEDEV set to /dev/null) you cannot re- enable it without onmonitor. It sets a shared memory flag which says "keep logical logs for ontape to be able to collect and write to tape". Otherwise they get discarded. THIS IS WHY IT IS NEEDED. Also when creating a chunk it gives better error messages than onspaces. i.e. Whether the chunk has the wrong owner/wrong group/wrong permissions/does not exist. onspaces just gives a generic message like 'cannot access chunk'. > Personally I would not recommend onmonitor as the primary means for > administration of a system. Its fine for viewing info but I think its better > to use the underlying commands when doing such things as building new > instances, adding lots of chunks, logs and so forth. > > I'd agree with Johnathan about the security aspect of links, although I do > use them myself since its convenient to keep a set of onconfig files tuned > for different aspects of system management [load, index rebuild etc]. I > guess I could always have used some form of source control system and had a > different branch for each of the files... > > Mark > > ----- Original Message ----- > From: "Martin, Wayne E." <WMartin@kmart.com> > To: "'Jonathan Leffler'" <jleffler@earthlink.net>; <informix-list@iiug.org> > Sent: Tuesday, June 10, 2003 07:28 > Subject: RE: onconfig file > > > > Onmonitor allows the Logical and archive tape to be up dated in a running > > database instance. This helps us who support 24X7 database instances. > > > > > > > > Wayne Martin > > Database Administrator > > Kmart Corporation > > > > -----Original Message----- > > From: Jonathan Leffler [mailto:jleffler@earthlink.net] > > Sent: Tuesday, June 10, 2003 1:19 AM > > To: informix-list@iiug.org > > Subject: Re: onconfig file > > > > Malcolm Weallans wrote: > > > The system administrator at my current site thought he would be very > > > clever and he linked the onconfig files to different directories using > > > ln -s. We have now discovered that these links are being lost when we > > > use onmonitor and replaced by a local file, but not when we use vi. Is > > > this yet another reason why we should not use onmonitor? Does anybody > > > else think that onmonitor still has a role in teaching IDS to > > > prospective admins? It is still documented in the manuals so > > > presumably it should still work. > > > > > > regards > > > > > > Malcolm > > > P.S. I am having to use google groups to post messages as info > > > security here has to be seen to be believed. > > > > > > I keep a central repository of onconfig files - by using symbolic > > links from the repository to the actual various INFORMIXDIR locations, > > precisely because of this problem. When I backup the central > > repository, I use a command that is oblivious to the symlinks and > > simply copies the files through the symlink (that is not tar, nor > > cpio, nor pax, but good old cp). OTOH, I keep a central sqlhosts file > > with symlinks from the various INFORMIXDIR locations to the central > > version. > > > > ON-Monitor is within its rights to expect its file to be local, and to > > expect to be able to rewrite it by removing the old version and > > creating the new. It does so. That breaks links - hard and symbolic. > > > > No, it is not the only way it could be done; it is, however, the way > > it always has been done. If I had my druthers, then oninit would > > probably refuse to have anything to do with an onconfig file that was > > not as secure as it should be. That would mean a variety of things - > > such as $INFORMIXDIR being properly owned and all directories on the > > path to it being sufficiently secure (owned by root, bin, or sys and > > not writable by group - or only limited groups - or others). If > > symlinks were to be allowed, then the symlink would have to equally > > secure - which is hard to establish. I'd be happy to keep it that the > > onconfig file was local to INFORMIXDIR. > > > > You can arrange to get a feature request entered to have ON-Monitor be > > more careful about symlinks and hard links. However, I'm not > > convinced it is a bug per se (hence feature request), and I'm fairly > > sure it would not get a very high priority unless the security of the > > onconfig file is being upgraded - whereupon it would probably be fixed > > as a side-effect of the upgrade. > > > > As to whether ON-Monitor still has a role - the feedback we get every > > time we've attempted to drop it is "Give me my ON-Monitor back". So > > it does get used. Personally, I use it for one thing - to get the > > NETTYPE entries right. When onconfig.std includes a prototype of a > > NETTYPE entry (so I don't have to remember what the fields mean), then > > I will have no use for ON-Monitor. It does list the databases - with > > owner and mode - which is convenient, but the information is also > > obtainable from sysmaster. So, it has very limited value to me, but > > the cries from the field indicate that it is still widely used. > > > > -- > > Jonathan Leffler #include <disclaimer.h> > > Email: jleffler@earthlink.net, jleffler@us.ibm.com > > Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/ > > > > > > This message and its contents (to include attachments) are the property of > Kmart Corporation (Kmart) and may contain confidential and proprietary > information. You are hereby notified that any disclosure, copying, or > distribution of this message, or the taking of any action based on > information contained herein is strictly prohibited. Unauthorized use of > information contained herein may subject you to civil and criminal > prosecution and penalties. If you are not the intended recipient, you should > delete this message immediately. > > > > >