Re: onaudit problems after upgrading from11.10.FC2

Message started sometime ago (like maybe 2009-09-17?) - then continued - then finished...Sorry... On Sun, Sep 13, 2009 at 14:37, KARL OLIVER <karl.oliver@maf.govt.nz> wrote: > Hoping some one out there can help with on audit problems. > Since upgrading from 11.10.FC2 to 11.10.FC3 onaudit is not working correctly > on one server and not working at all on others. So we now have 9 instances > without functioning audit. That is not good. Have you contacted IBM Informix Technical Support? > The problem where onaudit is not working correctly is as follows > I have set onaudit level to 1 with no audit masks > So in theory nothing should be audited > onaudit -o shows nothing audited as you would expect:> > Do you wish to continue? [y/N]: y > paqis > > The sysaudit table in sysmaster shows nothing either: > username paqis > succ1 0 > succ2 0 > succ3 0 > succ4 0 > succ5 0 > fail1 0 > fail2 0 > fail3 0 > fail4 0 > fail5 0 > > 1 row(s) retrieved. > Yet when I set audit level to 1 hundreds of OPDB are logged see below. > The informix support team is unable to reproduce the problem Answer: yes - you have... > so I am hoping > that someone else has struck the issue and can shed some light on the problem > > NLN|2009-09-14 > 09:13:16.000|auwsp123.dmz.maf.govt.nz |10855|asp132_ecms_live_rep|ecert|0:OPDB:ec_live:0:- > ONLN|2009-09-14 > 09:13:19.000|wuasp132|2923|asp132_ecms_live_rep|informix|0:OPDB:sysmaster:0:- > ONLN|2009-09-14 > 09:13:21.000|wuwsp133.dmz.maf.govt.nz |29342|asp132_ecms_live_rep|ecert|0:OPDB:ec_live:0:- > [...] > ONLN|2009-09-14 > 09:13:43.000|auwsp123.dmz.maf.govt.nz |10855|asp132_ecms_live_rep|ecert|0:OPDB:ec_live:0:- > ONLN|2009-09-14 Later, you added the information: > More information - I think I know why all opdb were logged - I had a user ecert > accessing system that did not have specific mask. Removed opdb from _require > and recording stopped. > Why when you do onaudit -o is not _require mask shown? It should be shown if it exists and you don't specify which mask to show: onaudit -o -y On one server, this yields (amongst a collection of very long lines that won't format sensibly in email): _audit - CRAM,DRAM,LSAM,UPAM _crud - DLRW,INRW,RDRW,UPRW _dba - CRDB,DRDB,RNDB,STRS [...] _require - ACTB,OPDB,STSN jleffler - ACTB,ALTB,BGTX,CLDB,CMTX,CRIX,DLRW,EXSP,INRW,LKTB,ONCH,ONST,OPDB,RDRW,RLTX,SCSP, STEX,STIL,STLM,STSN,ULTB,UPRW,ALFR,STDS,STDP,CRDM,DRDM,STSC,RNDS I added the _require mask with: onaudit -a -u _require -e +STSN,OPDB,ACTB > Where does this information reside? It is in the sysmaster database, and in the sysaudit table specifically. This table is unusual in sysmaster because it is a real table and not a pseudo-table. AFAIK, it is the only such table. And that means that the process that rebuilds the sysmaster database has to take extra steps to ensure that the data in sysaudit is preserved (UNLOAD and then LOAD, in other words). > Why is dir /opt/informix/dbssodir not mentioned as being new under IDS 11? > Was not there under version 9. $INFORMIXDIR/dbssodir was present in IDS 7 and 9 and 10 and continues to be present in 11; it was not mentioned as being new because it is not new. Why does onaudit not report when adding/deleting mask - always seems to > work in silent mode? Legacy...it appears to have been a requirement in the OnLine/Secure product that worked with multi-level secure operating systems. It is very hostile, and was once necessary to prevent information leakage via covert channels - well, that was the theory. It should be fixed, eventually. > When I delete all audit masks with onaudit -d and set audit level to 0 > all auditing stops fine. It should be sufficient to set the audit level to 0, leaving masks available for (re)use when auditing is next activated. > But when I try to set it all up again with exactly the same script I used > to set up under version 9 it does not work, something must have changed to > cause auditing to stop but I can find it in the documentation anywhere. Since I can't see your script, it is hard to know what might be going wrong. However, there are multiple ways in which things can go awry - most notably if the person doing the setup is not privileged. You did say in another message that you were simply using user informix with no role separation; that should not cause any problems as long as user informix runs the audit setup script. There were no deliberate changes made to break things. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/ "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." NB: Please do not use this email for correspondence. I don't necessarily read it every week, even. Ted Turner - "Sports is like a war without the killing." - http://www.brainyquote.com/quotes/authors/t/ted_turner.html --00c09f9b0763d02aba04745e6cae