openxdas-users — User discussions regarding OpenXDAS

[openxdas-users] Installing openxdas on RHEL 6.8

[Michael K. <Mic...@mi...>]

What are the required rpms to install openxdas-0.8.351-1.x86_64.rpm on Red Hat Enterprise Linux 6.8? I’m getting the following error even though the libraries it’s pointed are installed.

[root@VNXTLAPP01 UserApplication]# rpm -Uvh /tmp/openxdas-0.8.351-1.x86_64.rpm
error: Failed dependencies:
        libaudit.so.0()(64bit) is needed by openxdas-0.8.351-1.x86_64
        libodbc.so.1()(64bit) is needed by openxdas-0.8.351-1.x86_64


[root@VNXTLAPP01 UserApplication]# ll /lib/libaudit.so*
lrwxrwxrwx 1 root root     22 Nov 10 10:47 /lib/libaudit.so.0 -> /lib/libaudit.so.1.0.0
lrwxrwxrwx 1 root root     17 Sep  1  2016 /lib/libaudit.so.1 -> libaudit.so.1.0.0
-rwxr-xr-x 1 root root 136800 Aug 10  2014 /lib/libaudit.so.1.0.0

[root@VNXTLAPP01 UserApplication]# ll /lib64/libaudit.so*
lrwxrwxrwx  1 root root     24 Nov 10 10:47 /lib64/libaudit.so.0 -> /lib64/libaudit.so.1.0.0
lrwxrwxrwx. 1 root root     17 Jun 10  2016 /lib64/libaudit.so.1 -> libaudit.so.1.0.0
-rwxr-xr-x  1 root root 144208 Aug 10  2014 /lib64/libaudit.so.1.0.0

[root@VNXTLAPP01 UserApplication]# ll /lib/libodbc.so*
lrwxrwxrwx 1 root root 25 Nov 10 10:51 /lib/libodbc.so.1 -> /usr/lib/libodbc.so.2.0.0

[root@VNXTLAPP01 UserApplication]# ll /lib64/libodbc.so*
lrwxrwxrwx 1 root root 27 Nov 10 10:50 /lib64/libodbc.so.1 -> /usr/lib64/libodbc.so.2.0.0

[root@VNXTLAPP01 UserApplication]# rpm -Uvh /tmp/openxdas



Michael Kilpatrick, CISSP, ITILv3
Premium Service Engineer
Micro Focus
Office: 816.734.1747
Mobile: 816.728.3999
mic...@mi...<mailto:mki...@mi...>
________________________________
[cid:image001.png@01D35CA4.B2D371F0]

[omo]

Re: [openxdas-users] Is there service back-up? (not data)

[kadir y. <kad...@gm...>]

Thank you both for the answers.

And John, yes that is the sort of thing I'm looking for. I want to store the
data in a remote database and I don't want to lose anything when the
connection is lost to the remote system. If you say that OpenXDAS daemon
already has a local cache for this task, it is just brilliant. Thumbs up.

Kind Regards
Kadir


2011/5/16 David Corlette <dco...@no...>

> I don't believe so, I think this was left for implementation by the service
> submitting data to OpenXDAS. But I could be wrong; John Calcote may have put
> something like this in there.
>
> BTW, are you involved in the development of XDAS v2, which will replace the
> XDAS v1 standard on which OpenXDAS was based?  If not, you and anyone else
> on this list who are members of The Open Group should make sure to sign up!
>
> >>> On 16.05.2011 at 08:19, in message
> <BANLkTi=EmE...@ma...>, kadir
> yüceer<kad...@gm...> wrote:
> > Hi all,
> >
> > Imagining I have the storage in a remote system, it is possible that the
> > connection gets lost and the service can't store anything to remote
> storage.
> > Is there a service in openXDAS that can perform a service backup, like
> > storing to a local storage temporarily and adding the locally-stored data
> to
> > the remote storage whenever the connection is up?
> >
> > I couldn't see anything related in documents.
> >
> > Thanks in advance.
> >
> > Kadir
>
>

Re: [openxdas-users] Is there service back-up? (not data)

[David C. <dco...@no...>]

I don't believe so, I think this was left for implementation by the service submitting data to OpenXDAS. But I could be wrong; John Calcote may have put something like this in there.

BTW, are you involved in the development of XDAS v2, which will replace the XDAS v1 standard on which OpenXDAS was based?  If not, you and anyone else on this list who are members of The Open Group should make sure to sign up!

>>> On 16.05.2011 at 08:19, in message
<BANLkTi=EmE...@ma...>, kadir
yüceer<kad...@gm...> wrote: 
> Hi all,
> 
> Imagining I have the storage in a remote system, it is possible that the
> connection gets lost and the service can't store anything to remote storage.
> Is there a service in openXDAS that can perform a service backup, like
> storing to a local storage temporarily and adding the locally-stored data to
> the remote storage whenever the connection is up?
> 
> I couldn't see anything related in documents.
> 
> Thanks in advance.
> 
> Kadir

Re: [openxdas-users] Is there service back-up? (not data)

[John C. <joh...@gm...>]

Kadir,

I guess it depends on your definitions of "local" and "remote". OpenXDAS
currently uses a store and forward cache to ensure it doesn't lose any
data. The cache is local to the openxdas daemon on the local host. If
you use the net logger as a data sink, then the store and forward will
write cached messages to a "remote" system. If the network connection
goes down, the "local" cache will continue to grow until the network
connection is back up, at which point the cache will begin to push the
cache to the "remote" data store.

Is this the sort of thing you're thinking of?

Regards,
John

On 5/16/2011 6:19 AM, kadir yüceer wrote:
> Hi all,
>
> Imagining I have the storage in a remote system, it is possible that
> the connection gets lost and the service can't store anything to
> remote storage. Is there a service in openXDAS that can perform a
> service backup, like storing to a local storage temporarily and adding
> the locally-stored data to the remote storage whenever the connection
> is up?
>
> I couldn't see anything related in documents.
>
> Thanks in advance.
>
> Kadir
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
>
>
> _______________________________________________
> openxdas-users mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openxdas-users

[openxdas-users] Is there service back-up? (not data)

[kadir y. <kad...@gm...>]

Hi all,

Imagining I have the storage in a remote system, it is possible that the
connection gets lost and the service can't store anything to remote storage.
Is there a service in openXDAS that can perform a service backup, like
storing to a local storage temporarily and adding the locally-stored data to
the remote storage whenever the connection is up?

I couldn't see anything related in documents.

Thanks in advance.

Kadir

[openxdas-users] OpenXDAS 0.8.351 Released!

[John C. <joh...@gm...>]

I'm pleased to announce the release of version 0.8.351 of the OpenXDAS 
auditing project. Please see the SourceForge.net site to download the 
latest source and binary archives:

    http://sourceforge.net/projects/openxdas

And check the web site for information on this latest release:

    http://openxdas.sourceforge.net

This version contains the following new features:

* Implemented import API in preparation for platform import agents!

* Removed arbitrary 4k limit on store-and-forward cache message size.

* Modified the test program to understand a command line argument as a 
file containing log lines. The test program scans the file for lines 
output by xdasd during event parsing. These lines contain complete XDAS 
log-line formatted events. These are then fed back into xdasd via the 
import API, allowing defective log lines to be tested and debugged.

* Added modifications to openxdas.spec file to allow openxdas to be 
built properly on older Linux distros such as SLES 10. Removed all Java 
1.5 dependencies from code base by targeting 1.4 for both source and 
class files.

Enjoy!

[openxdas-users] OpenXDAS 0.8.345 Released!

[John C. <joh...@gm...>]

Everyone,

I'm happy to announce the release of OpenXDAS version 0.8.345.

This version contains a couple of bug fixes in the Java and C clients 
related to timezone string formatting and escaping in the XDAS record 
header.

The defect caused unescaped strings to be generated into the timezone 
field of the XDAS record header. The fixes also allow the timezone 
string to be generated more accurately now (as per the OpenGroup Single 
Unix Specification).

Additionally, we've added debug logging code, and some instrumentation 
to log inbound unparsed and parsed messages to the xdasd service. 
Additional debug log instrumentation will be added over time. For now, 
if you're interested in seeing more verbose xdasd.log information, try 
adding "-e 15" to the xdasd command line, or set the XDASD_LOG_LEVEL 
environment variable to 15. You can use any value between 0 and MAX_INT 
(zero is the default value), but currently the code is only instrumented 
to level 15, with instrumentation at levels 1, 2, 10 and 15.

(NOTE: Please don't leave debug logging on. It will fill up your 
xdasd.log file with useless garbage if you're not interested in 
collecting that information for debugging purposes.)

Check out the new version on the openxdas web site:

    http://openxdas.sourceforge.net/downloads.html

Check out the sourceforge project site at:

    http://sourceforge.net/projects/openxdas

Enjoy!
John

[openxdas-users] OpenXDAS version 0.8.333 Released!

[John C. <joh...@gm...>]

I'm happy to announce the release of version 0.8.333 of the OpenXDAS 
project.

This version has several key Java client library enhancements, plus others:

1. The Java client library has been upgraded to use Java NIO from raw 
sockets. This gives the Java client the ability to write native I/O 
buffers directly to underlying OS sockets. The result is a much faster 
Java client.

2. We've fixed a long-standing bug in the Java client wherein UTF-8 
strings were not getting processed correctly when using extended 
character set strings such as those found in languages like Chinese and 
Japanese.

3. We've added a doc package to the rpm build.

4. We've enhanced the build system in minor ways.

Please visit the OpenXDAS web site at http://openxdas.sourceforge.net 
for more information.

The files may be downloaded from the project web site on sourceforge.net 
at http://sourceforge.net/projects/openxdas.

Future enhancements include the addition of platform agents to capture 
system events and route them through the xdasd service. Watch for this 
major feature in a soon-to-be-released version of OpenXDAS.

Enjoy!
John

[openxdas-users] Announcing OpenXDAS release 0.7.320!

[John C. <joh...@gm...>]

I'm pleased to announce the release of OpenXDAS version 0.7.320.

Due to a massive upgrade to sourceforge.net that took place on July 1, 
2009, there are several U/I defects in the sf.net project page for 
OpenXDAS (and many other projects). The version that is displayed for 
download on the summary page is the 0.6.294 version, but this is NOT the 
latest. For quality download links, please visit the openxdas web site 
download page at:

    http://openxdas.sourceforge.net/downloads.html

Well, with each new release, we're that much closer to a functionally 
complete 1.0 release of the reference XDAS v1.0 specification. In this 
new release, we've done the following:

* We've finished the netstream logger's SSL/TLS functionality. You can 
now configure (on both Windows and Unix platforms) the netstream logger 
to use an SSL/TLS connection to a log server. You can optionally 
configure server and client authentication, as well as a desired cipher 
suite. For details, see the updated documentation for the netstream 
logger, which can be found in the newly released 0.7.320 version of the 
openxdas user and developer document. Detailed instructions are also 
provided for generating keys and certificates.

* We've also fixed a few defects that some of our newer users found in 
the filter trigger code. (Thanks Domenico!)

* We've added code to the C and Java client libraries to convert all 
control characters to spaces in XDAS field strings passed into the 
client interface. Control characters are not allowed in XDAS v1.0 input 
strings, as they cause wrapping issues, etc.

* We've enhanced the Unix build system a bit. The eXpat library was not 
being strictly required in configure.ac, so systems without eXpat or 
eXpat-devel installed would fail in make, rather than configure.

* Finally, we've converted the Visual Studio project and solutions files 
from VS 2008 to VS 2005 for compatibility with that older version. This 
shouldn't cause anyone problems, as VS 2008 will upgrade these older 
solution and project files automatically when they're opened in VS 2008. 
This allows our VS 2005 users to play also.

_*Still to be done:*_

Please note that the code is extremely clean, due to good integrated 
unit tests. The reason for the pre-1.0 version number is simply that 
we're still short a few features. The features we're still considering 
before 1.0 are:

* Import agents for (at least) Linux/Unix and Windows.

* The management API needs to be finished. We need to complete 
implementation for the filter management portion of the XDAS API.

As usually, please send feedback to the openxdas-devel or openxdas-users 
mailing lists.

Enjoy!
John

Re: [openxdas-users] FW: [Bandit-dev] OpenXDAS Record Filtering

[Leonardo S. <leo...@tx...>]

Hi John,

 

Thanks for your support to our problem!

Adopting the solution proposed by you the trigger works properly. Certainly
we will continue to use the OpenXDAS filters in this way until the release
of the new version.

In the next days my colleague Domenico could present you some questions
about the previous mail.

 

Best Regards.

        Leonardo.

 

From: John Calcote [mailto:joh...@gm...] 
Sent: giovedì 28 maggio 2009 20.05
To: Domenico Rotondi
Cc: jca...@no...; leonardo Straniero;
ope...@li...
Subject: Re: FW: [openxdas-users] [Bandit-dev] OpenXDAS Record Filtering

 

Domenico,

On 5/27/2009 5:47 PM, John Calcote wrote: 

Hi Domenico (adding openxdas-users to cc list),

...



The first line in your table is a trigger filter, and has no effect on
logging whatever. All events will be logged (if this is the only filter in
the filter list). Events whose EventId is 0x01000001 should cause the
trigger to take effect. I see that your trigger does not appear to be
executed. I setup my environment to be like this filter, and found that it's
true that it doesn't copy the file as it should. I spent a little time
debugging. The logic is correct in the filter. The problem appears to be
that each line passed to cmd.exe must be terminated by a CRLF or the command
will not be executed. Additionally, the XML parsing code used to parse out
the CDATA section containing the script automatically removes all leading
and trailing white space from the scriptlet. Thus, you can't just add a
blank line after the copy command in the filter file. I need to fix this so
that there is at least one trailing '\n' character following the last
command. In the mean time, you can work around the problem by using a CDATA
section that looks like this:

            <![CDATA[
COPY "C:\aa.log" "C:\AppData"
REM
             ]]>

I've committed a fix to the openxdas repository to ensure that all
scriptlets contain a trailing newline character. This should fix the problem
for you. Please continue to use the above work-around until an update of the
openxdas package for windows is released.

Thanks for your feedback.

Best regards,

John

Re: [openxdas-users] FW: [Bandit-dev] OpenXDAS Record Filtering

[John C. <joh...@gm...>]

Domenico,

On 5/27/2009 5:47 PM, John Calcote wrote:
> Hi Domenico (adding openxdas-users to cc list),
...
> The first line in your table is a trigger filter, and has no effect on 
> logging whatever. All events will be logged (if this is the only 
> filter in the filter list). Events whose EventId is 0x01000001 should 
> cause the trigger to take effect. I see that your trigger does not 
> appear to be executed. I setup my environment to be like this filter, 
> and found that it's true that it doesn't copy the file as it should. I 
> spent a little time debugging. The logic is correct in the filter. The 
> problem appears to be that each line passed to cmd.exe must be 
> terminated by a CRLF or the command will not be executed. 
> Additionally, the XML parsing code used to parse out the CDATA section 
> containing the script automatically removes all leading and trailing 
> white space from the scriptlet. Thus, you can't just add a blank line 
> after the copy command in the filter file. I need to fix this so that 
> there is at least one trailing '\n' character following the last 
> command. In the mean time, you can work around the problem by using a 
> CDATA section that looks like this:
>
> <![CDATA[
> COPY "C:\aa.log" "C:\AppData"
> REM
>              ]]>
>
I've committed a fix to the openxdas repository to ensure that all 
scriptlets contain a trailing newline character. This should fix the 
problem for you. Please continue to use the above work-around until an 
update of the openxdas package for windows is released.

Thanks for your feedback.

Best regards,

John

Re: [openxdas-users] FW: [Bandit-dev] OpenXDAS Record Filtering

[John C. <joh...@gm...>]

Hi Domenico (adding openxdas-users to cc list),

I think I understand your problem now. You are trying to find a way to 
filter out various events from the event log in some cases, and trigger 
external actions on other events. R1 (below) should NOT be added to the 
event log.

XDAS's primary function is to log events. Thus, a filter's job is not to 
define the set of events that are allowed, but rather to define a set of 
events that are disallowed. You have to create a filter that matches the 
allow AND the deny statements. This causes the matching event to be 
denied: It moves from the *default* state ("log me") to the *deny* 
state. If an event matches the allow statements, but not the deny 
statements, it then moves from the *default* state to the *allow* state 
(which states happen to be the same for log). Once a match has been made 
against one or more of the allow clauses, the deny clauses indicate 
whether or not a message is logged.

How this works with triggers is a bit different because the *default* 
state on a trigger is *deny*, and the default state on logging is 
*allow*. With triggers, once an event matches an allow clause of a match 
statement, it moves from the *default* state (*deny* - or don't 
trigger), to the *allow* state. If it then matches any of the deny 
clauses, it moves to the *deny* state (same as *default*). Thus, the way 
to get a trigger to take effect is to have an event match one or more of 
the allow clauses, but not any of the deny clauses.

I can see in retrospect that my prose in the manual is terrible. It 
would have made more sense to call these states default, allow and deny, 
rather than default, include, and exclude.

To make both R1 and R1 work as desired, you probably need two different 
filters defined in the filter list. The examples I give in the manual 
are not very well defined either. For example, the filter names really 
should be more like, "Trigger on Account Create", rather than simply 
"Account Create". Another good name for a filter would be, "Don't log 
Account Delete events".

In my own defense, at least part of the problem was that I was trying to 
decipher the effects of the logic I invented while writing the manual. ;-)

The first line in your table is a trigger filter, and has no effect on 
logging whatever. All events will be logged (if this is the only filter 
in the filter list). Events whose EventId is 0x01000001 should cause the 
trigger to take effect. I see that your trigger does not appear to be 
executed. I setup my environment to be like this filter, and found that 
it's true that it doesn't copy the file as it should. I spent a little 
time debugging. The logic is correct in the filter. The problem appears 
to be that each line passed to cmd.exe must be terminated by a CRLF or 
the command will not be executed. Additionally, the XML parsing code 
used to parse out the CDATA section containing the script automatically 
removes all leading and trailing white space from the scriptlet. Thus, 
you can't just add a blank line after the copy command in the filter 
file. I need to fix this so that there is at least one trailing '\n' 
character following the last command. In the mean time, you can work 
around the problem by using a CDATA section that looks like this:

<![CDATA[
COPY "C:\aa.log" "C:\AppData"
REM
              ]]>

Incidentally, notice that I've left justified the scriptlet lines. This 
is merely clean batch programming. cmd.exe doesn't care about leading 
white space (usually), but it never hurts to understand what's going on 
here, and write your filters accordingly. :)

Best Regards,
John

On 5/27/2009 11:59 AM, Domenico Rotondi wrote:
> Hi John,
> first of all thanks for your reply and support.
> Sorry to come in the mail exchange with my colleague Leonardo, but we 
> are still having problems with OpenXDAS filter settings.
>
> Using a simple C program (see attachment) that audits the following 2 
> events and corresponding outcomes:
> *Logged Events*
> 	
> *Event Number*
> 	
> *Event Outcome*
> R1
> 	
> 0x01000001
> 	
> 0
> R2
> 	
> 0x01000007
> 	
> 1
>
>
> we performed some checks using the last version of the OpenXDAS system 
> under Windows Server 2003 and Windows XP changing filter specs.
>
> Reading the OpenXDAS manual and your previous messages it seems to us 
> the filtering behaviour of OpenXDAS can be sumamrized as follows:
>
>     * an event can be in 3 different states: "default", "included",
>       "excluded"
>     * a transition between 2 states is governed by matching a
>       filtering "<match>" section
>     * an event initial state is "default"
>     * the "<allow>" directives have to preceed the "<deny>" ones
>     * "<allow>" directives are applied as if they were OR conditions
>       (so subsequent "<allow>"s enlarge the matching events set)
>     * "<deny>" directives are applied as if they were AND conditions
>       on the events set that was output by the "<allow>" specs.
>       Therefore the "deny" specs restrict the matching events set
>     * if an event doesn't match any of the "allow" and "deny"
>       directives of a filter its status remains "default"
>     * if an event matches at least one of the "allow"/"deny"
>       directives its status changed from the "default" one to
>       "included"/"excluded" depending if the event is in the resulting
>       filter events set or not
>     * therefore an "included" status is reached *_if and only if at
>       least one of the "allow"_* *_and none of the "deny"_* specs are met
>     * while an "excluded" status is reached *_if and only if at least
>       one of the "allow"_* *_and one or more "deny" _*specs are met
>     * if the event status after the matching against a filter <match>
>       spec is still "default" the process continues with the
>       subsequent filter spec (if any) as indicated before or, if no
>       more filters are defined, the default action is applied: i.e.
>       the event is logged
>     * if the event status after the matching against a filter match
>       spec is "included" the "<action>" spec is applied, otherwise the
>       "<action>" spec is skipped
>     * it's not clear, in case there are other filter specs, if the
>       event's status is reset to "default" or the subsequent filter
>       evaluation takes into account the outcome of the previous filter
>       evaluation
>
>
> Having in mind this schema we made the following tests with the 
> expected and actual outcomes reported in the following talble:
> *Filter Specification*
> 	
> *Expected Outcome*
> 	
> *Actual outcome (Windows Event Viewer)*
> <filter-list version='OX1'>
> <filter name='Account Created' status='On' type='Submit, Import'>
> <match>
> <allow attr='HdrEvent' op='EQ'>0x01000001</allow>
> </match>
> <action>
> <trigger>
> <![CDATA[
>    COPY "C:\swwork\Z121061A.pl" "C:\AppDev"
>    ]]>
> </trigger>
> </action>
> </filter>
> </filter-list>
> 	
> This filter spec has to:
> * log Event R2 (default action. The <match> section doesn't apply to 
> this event that, as stated in the manual, will persists in its default 
> state),
> * skip logging Event R1 (which matches the <match> directive but the 
> <action> section doesn't specify a<log /> directive),
> * trigger the copy operation on Event R1
> 	
> * Both events reported in the Windows Event Viewer.
> * It seems Event R1 doesn't match the filter and, therefore, persists 
> in its "default state" as Event R2.
> * The trigger hasn't be executed!
> <filter-list version='OX1'>
> <filter name='Account Created' status='On' type='Submit, Import'>
> <match>
> <allow attr='HdrEvent' op='EQ'>0x01000001</allow>
> <deny attr='HdrOutcome' op='NE'>0</deny>
> </match>
> <action>
> <trigger>
> <![CDATA[
>    COPY "C:\swwork\Z121061A.pl" "C:\AppDev"
>    ]]>
> </trigger>
> </action>
> </filter>
> </filter-list>
> 	
> This filter spec has to:
> * log Event R2 (default action. The <match> section doesn't apply to 
> this event that, as stated in the manual, will persists in its default 
> state),
> * skip logging Event R1 (being matched by the <match> directive and 
> due to the lack of the <log /> directive in the <action> section),
> * trigger the copy operation on Event R1
> 	
> * Event R1 reported in the Windows Event Viewer, event if it matches 
> the filter and no log directive is specified by the filter;
> * Event R2 is not reported in the Windows Event Viewer as expected. It 
> seems like if it was filtered out by the "deny" spec, even if it 
> doesn't match the "allow" part;
> * The trigger hasn't be executed!
> <filter-list version='OX1'>
> <filter name='Account Created' status='On' type='Submit, Import'>
> <match>
> <allow attr='HdrEvent' op='EQ'>0x01000001</allow>
> <deny attr='HdrOutcome' op='NE'>0</deny>
> </match>
> <action>
> <log />
> <trigger>
> <![CDATA[
>    COPY "C:\swwork\Z121061A.pl" "C:\AppDev"
>    ]]>
> </trigger>
> </action>
> </filter>
> </filter-list>
> 	
> This filter spec has to:
> * log Event R2 (default action. The <match> section doesn't apply to 
> this event that, as stated in the manual, will persists in its default 
> state),
> * log Event R1 (being matched by the <match> directive and due to the 
> presence of the <log /> directive in the <action> section),
> * trigger the copy operation on Event R1
> 	
> * Event R1 reported in the Windows Event Viewer as expected;
> * Event R2 is not reported in the Windows Event Viewer as expected. It 
> seems like if it was filtered out by the "deny" spec, even if it 
> doesn't match the "allow" part;
> * The trigger hasn't be executed!
> <filter-list version='OX1'>
> <filter name='Account Created' status='On' type='Submit, Import'>
> <match>
> <allow attr='HdrEvent' op='EQ'>0x01000001</allow>
> </match>
> <action>
> <log />
> <trigger>
> <![CDATA[
>    COPY "C:\swwork\Z121061A.pl" "C:\AppDev"
>    ]]>
> </trigger>
> </action>
> </filter>
> </filter-list>
> 	
> This filter spec has to:
> * log Event R2 (default action. The <match> section doesn't apply to 
> this event that, as stated in the manual, will persists in its default 
> state),
> * log Event R1 (being matched by the <match> directive and due to the 
> presence of the <log /> directive in the <action> section),
> * trigger the copy operation on Event R1
> 	
> * Event R1 reported in the Windows Event Viewer as expected;
> * Event R2 is reported in the Windows Event Viewer as expected. 
> Unclear if logged for its "default status" or for matching the filter;
> * The trigger hasn't be executed!
> No filter (i.e. No filter file in the Windows system folder!)
> 	
> This filter spec has to:
> * log Event R2 (default action. The <match> section doesn't apply to 
> this event that, as stated in the manual, will persists in its default 
> state),
> * log Event R1 (default action. The <match> section doesn't apply to 
> this event that, as stated in the manual, will persists in its default 
> state)
> 	
> Event R1 and R2 reported in the Windows Event Viewer as expected
>
>
>
> As you can see we didn't obtain a consistent behaviour. For sure we 
> are missinterpreting something and, for the trigger action, doing some 
> mistake.
> I know this is a long mail and we are asking you to spend precious 
> time, but, please, help us clarify the situation.
> Thanks in advance for any hints.
> Ciao
>    Domenico
>
>
> ------------------------------------------------------------------------
> On 27 May 2009 at 18:29, Leonardo Straniero wrote:
>
> *From:* John Calcote [mailto:joh...@gm...]
> *Sent:* venerdì 22 maggio 2009 21.45
> *To:* leo...@tx...
> *Cc:* ban...@co...; 
> ope...@li...
> *Subject:* Re: [openxdas-users] [Bandit-dev] OpenXDAS Record Filtering
>
>
> Dr. Straniero,
>
> I'm sorry I missed the differences before. I've spent some time 
> working through your example filters and code this morning. Here are 
> my thoughts:
>
> 1. On Windows comspec, ComSpec, and COMSPEC all represent the same 
> environment variable. This is not true on Linux or Unix systems of course.
>
> 2. Filter1 is missing the closing tag on the <action> member. It 
> should directly follow the </trigger> close tag.
>
> Consider Filter1's match clause:
>
> <match>
> <allow attr='HdrEvent' op='EQ'>0x01000007</allow>
> <deny attr='HdrOutcome' op='NE'>0</deny>
> </match>
>
> The match criteria of Filter1 state that all events with an EVENT code 
> equal to 0x01000007 are matched. Of the events that match, only those 
> with an OUTCOME code equal to 0 are remain matched. You might think 
> you could write this filter like this:
>
> <match>
> <allow attr='HdrEvent' op='EQ'>0x01000007</allow>
> <allow attr='HdrOutcome' op='EQ'>0</allow>
> </match>
>
> But what you end up with are all events whose EVENT code is 0x01000007 
> OR whose OUTCOME code is 0.
>
> I considered various ways to define Boolean logic that would be 
> useful, but an XML record format that defined Boolean logic with 
> appropriate precedence rules built into the structure was much more 
> complicated to write. Effectively, you get Boolean logic using this 
> structure by considering allow statements as OR statements, and deny 
> statements as AND statements. The precedence comes from the order of 
> these allow and deny statements. Unfortunately it's simply not as 
> powerful as a full Boolean logic engine. However, I didn't see it as 
> being much of a loss, as I don't think there are many situations where 
> very complex Boolean logic is required to accomplish most end-goals 
> here. But all of this is mentioned in the doc.
>
> Anything matching the match criteria should cause the trigger to 
> execute. I've done this before, with a very similar trigger script on 
> both Windows and Linux, and it works for me. Perhaps the missing close 
> tag on the action element is causing your problems here.
>
> 3. The problem with Filter2 is a bit more complicated to explain. The 
> error 16 you're getting back is actually 0x16 - hexadecimal. The 
> decimal value is 22, which translates to XDAS_S_NO_AUDIT. This status 
> code is returned when a defined filter causes the particular message 
> to not be audited.
>
> One use of filtering is to provide trigger actions, which occur when 
> an event matches the filter. But another primary use of filtering is 
> to discard classes of messages to keep audit logs smaller. Filter2's 
> match criteria
> <match>
> <allow attr='HdrEvent' op='NE'>0x01000007</allow>
> <deny attr='HdrEvent' op='EQ'>0x01000007</deny>
> </match>
>
> indicates that only a record whose EVENT field is not equal to 
> 0x01000007 -- AND -- whose EVENT field is not equal to 0x01000007 are 
> passed by the filter. While this is redundant, it should work to allow 
> only events whose EVENT field is 0x01000007 to match.
>
> Because of the <log /> line in the <action> section, only the matched 
> events are logged. Triggers are not executed for events that are not 
> logged, but this doesn't matter, because the trigger is only applied 
> to matching records, just as the log line is only applied to matching 
> records. Regardless, I would remove the redundant <deny> statement, as 
> it complicates a reader's understanding of the filter.
>
> 4. The xdas_commit_record function is failing because the record is 
> invalid once it's been denied by the filter. If XDAS_S_NO_AUDIT is 
> returned, according to the XDAS preliminary specification, the record 
> should be deleted by the xdas function that indicated no audit. Thus 
> the record handle is no longer valid once NO_AUDIT has been returned.
>
> 5. The 10012 error code is again a hexidecimal value. It should 
> properly be read 0x00010012. This is because all XDAS status codes 
> returned are actually two part error codes. The upper 16 bits 
> represent a calling error code - in this case 0x0001. Zero in this 
> field means that no calling error was detected - that is, the routine 
> was called correctly. The three possible values of calling error are:
>
> XDAS_S_CALL_INACCESSIBLE_READ (defined as 1)
> XDAS_S_CALL_INACCESSIBLE_WRITE (defined as 2)
> XDAS_S_CALL_BAD_STRUCTURE (defined as 3)
>
> The lower 16 bits are defined as the XDAS status code - in this case 
> 0x0012, which indicates a decimal value of 18, or 
> XDAS_S_INVALID_RECORD_DESCRIPTOR. The right way to interpret XDAS 
> error codes is to use the macros provided in the xdas.h header file:
>
> routine_error = XDAS_ROUTINE_ERROR(return_code);
> calling_error = XDAS_CALLING_ERROR(return_code);
>
> In this case, your test program should detect XDAS_S_NO_AUDIT returned 
> from the xdas_start_record routine, and not call xdas_commit_record in 
> that case. This is why you received a calling error - because the 
> record handle was invalid by the time you called xdas_commit_record.
>
> I hope this helps.
>
> Regards,
> John
>
> On 5/22/2009 1:43 AM, Leonardo Straniero wrote:
> Hi John,  hi All,
> thanks for your response. But the question on /bandit-list/ is 
> different and more detailed than the /openxdas-users/ list. I insert 
> details about the C and Java APIs and the different behavior with and 
> without the filter.
> I tested the "copy" command in a cmd window and it works perfectly.
> This is my xdas.log file and all seems work without problems (but I 
> don't see any lines beginning with "xfilter:" string):
> ------------------------------xdas.log----------------------------------
> [Thu May 21 18:20:07 2009] Starting xdasd version 0.6.xxx...
> [Thu May 21 18:20:07 2009] Using configuration file C:\WINDOWS/xdasd.conf.
> [Thu May 21 18:20:07 2009] Using filter specification file 
> C:\WINDOWS/xdasd.filter.
> [Thu May 21 18:20:07 2009] Using message queue directory 
> C:\WINDOWS/xdasd.mcache.
> [Thu May 21 18:20:07 2009] Using unique ipc path/string 
> C:\WINDOWS/xdasd.ipc.
> [Thu May 21 18:20:07 2009] syslog: Windows Event Service keys already 
> in place.
> [Thu May 21 18:20:07 2009] Logger C:\program 
> files\openxdas\Loggers\xdm_syslog.dll loaded and initialized.
> [Thu May 21 18:20:07 2009] Listening on TCP socket...
> [Thu May 21 18:20:07 2009] main: Successfully initialized.
> [Thu May 21 18:20:07 2009] Entering main run loop...
> ------------------------------xdas.log----------------------------------
> Please read the new e-mail to know the additional details.
> Any ideas will be appreciated.
>
> Thanks in advance,
>                Leonardo.
> *From:* _ba...@co..._ 
> <mailto:ban...@co...> 
> [_mailto:ban...@co..._] *On Behalf Of 
> *John Calcote
> *Sent:* giovedì 21 maggio 2009 20.22
> *To:* _le...@tx..._ 
> <mailto:leo...@tx...>; 
> _ba...@co..._ 
> <mailto:ban...@co...>
> *Subject:* Re: [Bandit-dev] OpenXDAS Record Filtering
>
>
> Dr. Straniero,
>
> I should also mention that the xdasd.log file will indicate if there 
> was a filter file parse problem. Just look for lines beginning with 
> "xfilter:". This may help you decipher the problems you may be having.
>
> John
>
> On 5/21/2009 10:55 AM, Leonardo Straniero wrote:
> Hi Daniel, hi All,
> in the next weeks we will analyze the solutions for the DIT and the 
> Authentication Method we mentioned in our previous mails. I will keep 
> you informed on our decisions and progress. Thanks anyway for you 
> suggestions and hints.
> We are currently analyzing and trying to configure and use  the 
> OpenXDAS Framework used in Bandit IdP for Auditing purposes. All seems 
> to work perfectly, I'm able to use different loggers (SysLog, 
> NetStream, ODBC and FileLog), with the only exception with the 
> filtering feature.
> Indeed, when I try to use the "XDAS Record Filtering" functionality 
> adding an  xdas.filter file in the SystemRoot directory (I'm using a 
> Windows XP Pro machine) with the following content:
> -----------------filter-1-----------------------
> <filter-list version='OX1'>
> <filter name='Account Created' status='On' type='Submit, Import'>
> <match>
> <allow attr='HdrEvent' op='EQ'>0x01000007</allow>
> <deny attr='HdrOutcome' op='NE'>0</deny>
> </match>
> <action>
> <trigger>
> <![CDATA[
>                  copy "C:\ fileXXX.YYY" "D:\log_allarm"
>        ]]>
> </trigger>
> </filter>
> </filter-list>
> -----------------filter-1-----------------------
> I didn't get what expected.
> If we correctly understood the OpenXDAS explanation, this filter spec 
> will copy the fileXXX.YYY (e.g. a test file I have) into the indicated 
> directory every time a *successful create session* event (0x01000007 
> Event Number and Outcome 0) is passed to the XDAS daemon; isn't it?
> But when the event occurs the filter doesn't copy the specified file. 
> In the OpenXdas Manual Vers 0.0.294 (page 35) the "*_COMPSEC_*" 
> environment variable has to be defined pointing to 
> */%SystemRoot%\system32\cmd.exe/*.
> I already have in my default environment variables a "*_ComSpec_*" 
> variable that points on the same location.
> As you can see that is a mismatch between the two names, Is it an 
> error on the manual or I must define another variable?
> I actually try to define this additional variable without any result.
> I also wrote two applications to test the Java and C XSAS APIs.
> For this two application I add an xdas.filter as follows:
> -----------------filter-2-----------------------
> <filter-list version='OX1'>
> <filter name='Account Created' status='On' type='Submit, Import'>
> <match>
> <allow attr='HdrEvent' op='NE'>0x01000007</allow>
> <deny attr='HdrEvent' op='EQ'>0x01000007</deny>
> </match>
> <action>
> <log />
> <trigger>
> <![CDATA[
>                                               copy "C:\aa.log" "C:\AppDev"
>                                               ]]>
> </trigger>
> </action>
> </filter>
> </filter-list>
> -----------------filter-2-----------------------
>
> (I want log all events but the Create_Session Audit Record event). 
> When the deny matching occurs, the C application program fails in two 
> points (the Java application works perfectly). This Is the C code:
> ----------------code-----------------
> #include <xdas.h>
> #include <stdio.h>
> #include <stdlib.h>
> #define 
> CHECK(x)                                                                                                                                            
> \
>    {                                              \
>       int err;                                    \
>      if ((err = (x)) != 0)         {                      \
>          printf("xdastest: error %x at: %s(%d).\n", err, __FILE__, 
> __LINE__);                                          \
>       }                                           \
>                  else                                                                                                                                                                 
> \
>                                printf("xdastest: success %x at: 
> %s(%d).\n", err, __FILE__, __LINE__);                              \
>    }
> int main()
> {
>    int minor;
>   xdas_audit_ref_t dasref;
>   xdas_audit_rec_desc_t arec;
>    /* initialize */
>    char * org_info = "waldo/apache:http%://waldo.novell.com"
>                                                                               ":_http:waldo:root:0_ 
> <http://waldo:root:0>";
>   CHECK(xdas_initialize_session(&minor, org_info, &dasref));
>    char * initiator_info = "waldo/nfs:joe:15";
>    char * tgt_info = "waldo/apache:http%://waldo.novell.com/index.html";
>    char * event_information = "laf-id=1701,my_attribute=32";
>   CHECK(xdas_start_record(&minor, dasref, &arec, 
> XDAS_AE_CREATE_SESSION, XDAS_OUT_SUCCESS, initiator_info, tgt_info, 
> event_information));
>   CHECK(xdas_commit_record(&minor, dasref, &arec));
>   CHECK(xdas_terminate_session(&minor, &dasref));
>   system("PAUSE");
>   return 0;
> }
> ----------------code-----------------
> The xdas_start_record returns an error code number 16 
> (XDAS_S_INVALID_ORIG_INFO, which is indeed  a Return code of  
> xdas_initialize_session method not of the xdas_start_record!).
> Additionally, the xdas_commit_record returns an error code 10012 that 
> is not defined in the xdas.h file.
> Note: if I use the filter-1 spec (which is used with the Bandit IdP) 
> the C application works perfectly and returns all 0 error codes 
> (XDAS_S_SUCCESS).
> Of course, I have no idea if the behaviour with filter-1 is due to the 
> filtering rule not being fired or to bugs in my code or in the 
> OpenXDAS Lib C code.
> As stated my Java test code doesn't report unsuccessful return codes, 
> even if the 2nd filtering rule is partially performed (i.e. the events 
> are logged/not logged according to the specified rule, but the copy 
> command is never executed).
> Any Ideas?Did I forgot something?
> I hope you have experience with the XDAS also and can help me (or 
> perhaps you can address me to someone else).
>
> Thanks in advance.
> Best Regards,
> Leonardo.
>
>
>
>
>
>
> _______________________________________________
> Bandit-dev mailing list
> _Ba...@co..._ 
> <mailto:Ban...@co...>
> _https://code.bandit-project.org/mailman/listinfo/bandit-dev_
> ------------------------------------------------------------------------
>
> The following section of this message contains a file attachment
> prepared for transmission using the Internet MIME message format.
> If you are using Pegasus Mail, or any other MIME-compliant system,
> you should be able to save it or view it from within your mailer.
> If you cannot, please ask your system administrator for assistance.
>
>     ---- File information -----------
>       File:  OpenXdas_Test.txt
>       Date:  27 May 2009, 18:24
>       Size:  2511 bytes.
>       Type:  Text
>    

Re: [openxdas-users] [Bandit-dev] OpenXDAS Record Filtering

[John C. <joh...@gm...>]

Dr. Straniero,

I'm sorry I missed the differences before. I've spent some time working 
through your example filters and code this morning. Here are my thoughts:

1. On Windows comspec, ComSpec, and COMSPEC all represent the same 
environment variable. This is not true on Linux or Unix systems of course.

2. Filter1 is missing the closing tag on the <action> member. It should 
directly follow the </trigger> close tag.

Consider Filter1's match clause:

<match>

<allow attr='HdrEvent' op='EQ'>0x01000007</allow>

<deny attr='HdrOutcome' op='NE'>0</deny>

</match>


The match criteria of Filter1 state that all events with an EVENT code 
equal to 0x01000007 are matched. Of the events that match, only those 
with an OUTCOME code equal to 0 are remain matched. You might think you 
could write this filter like this:

<match>

<allow attr='HdrEvent' op='EQ'>0x01000007</allow>

<allow attr='HdrOutcome' op='EQ'>0</allow>

</match>


But what you end up with are all events whose EVENT code is 0x01000007 
OR whose OUTCOME code is 0.

I considered various ways to define Boolean logic that would be useful, 
but an XML record format that defined Boolean logic with appropriate 
precedence rules built into the structure was much more complicated to 
write. Effectively, you get Boolean logic using this structure by 
considering allow statements as OR statements, and deny statements as 
AND statements. The precedence comes from the order of these allow and 
deny statements. Unfortunately it's simply not as powerful as a full 
Boolean logic engine. However, I didn't see it as being much of a loss, 
as I don't think there are many situations where very complex Boolean 
logic is required to accomplish most end-goals here. But all of this is 
mentioned in the doc.

Anything matching the match criteria should cause the trigger to 
execute. I've done this before, with a very similar trigger script on 
both Windows and Linux, and it works for me. Perhaps the missing close 
tag on the action element is causing your problems here.

3. The problem with Filter2 is a bit more complicated to explain. The 
error 16 you're getting back is actually 0x16 - hexadecimal. The decimal 
value is 22, which translates to XDAS_S_NO_AUDIT. This status code is 
returned when a defined filter causes the particular message to not be 
audited.

One use of filtering is to provide trigger actions, which occur when an 
event matches the filter. But another primary use of filtering is to 
discard classes of messages to keep audit logs smaller. Filter2's match 
criteria

<match>

<allow attr='HdrEvent' op='NE'>0x01000007</allow>

<deny attr='HdrEvent' op='EQ'>0x01000007</deny>

</match>


indicates that only a record whose EVENT field is not equal to 
0x01000007 -- AND -- whose EVENT field is not equal to 0x01000007 are 
passed by the filter. While this is redundant, it should work to allow 
only events whose EVENT field is 0x01000007 to match.

Because of the <log /> line in the <action> section, only the matched 
events are logged. Triggers are not executed for events that are not 
logged, but this doesn't matter, because the trigger is only applied to 
matching records, just as the log line is only applied to matching 
records. Regardless, I would remove the redundant <deny> statement, as 
it complicates a reader's understanding of the filter.

4. The xdas_commit_record function is failing because the record is 
invalid once it's been denied by the filter. If XDAS_S_NO_AUDIT is 
returned, according to the XDAS preliminary specification, the record 
should be deleted by the xdas function that indicated no audit. Thus the 
record handle is no longer valid once NO_AUDIT has been returned.

5. The 10012 error code is again a hexidecimal value. It should properly 
be read 0x00010012. This is because all XDAS status codes returned are 
actually two part error codes. The upper 16 bits represent a calling 
error code - in this case 0x0001. Zero in this field means that no 
calling error was detected - that is, the routine was called correctly. 
The three possible values of calling error are:

XDAS_S_CALL_INACCESSIBLE_READ (defined as 1)
XDAS_S_CALL_INACCESSIBLE_WRITE (defined as 2)
XDAS_S_CALL_BAD_STRUCTURE (defined as 3)

The lower 16 bits are defined as the XDAS status code - in this case 
0x0012, which indicates a decimal value of 18, or 
XDAS_S_INVALID_RECORD_DESCRIPTOR. The right way to interpret XDAS error 
codes is to use the macros provided in the xdas.h header file:

routine_error = XDAS_ROUTINE_ERROR(return_code);
calling_error = XDAS_CALLING_ERROR(return_code);

In this case, your test program should detect XDAS_S_NO_AUDIT returned 
from the xdas_start_record routine, and not call xdas_commit_record in 
that case. This is why you received a calling error - because the record 
handle was invalid by the time you called xdas_commit_record.

I hope this helps.

Regards,
John

On 5/22/2009 1:43 AM, Leonardo Straniero wrote:
>
> Hi John,  hi All,
>
> thanks for your response. But the question on /bandit-list/ is 
> different and more detailed than the /openxdas-users/ list. I insert 
> details about the C and Java APIs and the different behavior with and 
> without the filter.
>
> I tested the "copy" command in a cmd window and it works perfectly.
>
> This is my xdas.log file and all seems work without problems (but I 
> don't see any lines beginning with "xfilter:" string):
>
> ------------------------------xdas.log----------------------------------
>
> [Thu May 21 18:20:07 2009] Starting xdasd version 0.6.xxx...
>
> [Thu May 21 18:20:07 2009] Using configuration file C:\WINDOWS/xdasd.conf.
>
> [Thu May 21 18:20:07 2009] Using filter specification file 
> C:\WINDOWS/xdasd.filter.
>
> [Thu May 21 18:20:07 2009] Using message queue directory 
> C:\WINDOWS/xdasd.mcache.
>
> [Thu May 21 18:20:07 2009] Using unique ipc path/string 
> C:\WINDOWS/xdasd.ipc.
>
> [Thu May 21 18:20:07 2009] syslog: Windows Event Service keys already 
> in place.
>
> [Thu May 21 18:20:07 2009] Logger C:\program 
> files\openxdas\Loggers\xdm_syslog.dll loaded and initialized.
>
> [Thu May 21 18:20:07 2009] Listening on TCP socket...
>
> [Thu May 21 18:20:07 2009] main: Successfully initialized.
>
> [Thu May 21 18:20:07 2009] Entering main run loop...
>
> ------------------------------xdas.log----------------------------------
>
> Please read the new e-mail to know the additional details.
>
> Any ideas will be appreciated.
>
>
> Thanks in advance,
>
>                 Leonardo.
>
> *From:* ban...@co... 
> [mailto:ban...@co...] *On Behalf Of 
> *John Calcote
> *Sent:* giovedì 21 maggio 2009 20.22
> *To:* leo...@tx...; ban...@co...
> *Subject:* Re: [Bandit-dev] OpenXDAS Record Filtering
>
> Dr. Straniero,
>
> I should also mention that the xdasd.log file will indicate if there 
> was a filter file parse problem. Just look for lines beginning with 
> "xfilter:". This may help you decipher the problems you may be having.
>
> John
>
> On 5/21/2009 10:55 AM, Leonardo Straniero wrote:
>
> Hi Daniel, hi All,
>
> in the next weeks we will analyze the solutions for the DIT and the 
> Authentication Method we mentioned in our previous mails. I will keep 
> you informed on our decisions and progress. Thanks anyway for you 
> suggestions and hints.
>
> We are currently analyzing and trying to configure and use  the 
> OpenXDAS Framework used in Bandit IdP for Auditing purposes. All seems 
> to work perfectly, I'm able to use different loggers (SysLog, 
> NetStream, ODBC and FileLog), with the only exception with the 
> filtering feature.
>
> Indeed, when I try to use the "XDAS Record Filtering" functionality 
> adding an  xdas.filter file in the SystemRoot directory (I'm using a 
> Windows XP Pro machine) with the following content:
>
> -----------------filter-1-----------------------
>
> <filter-list version='OX1'>
>
> <filter name='Account Created' status='On' type='Submit, Import'>
>
> <match>
>
> <allow attr='HdrEvent' op='EQ'>0x01000007</allow>
>
> <deny attr='HdrOutcome' op='NE'>0</deny>
>
> </match>
>
> <action>
>
> <trigger>
>
> <![CDATA[
>
>                   copy "C:\ fileXXX.YYY" "D:\log_allarm"
>
>        ]]>
>
> </trigger>
>
> </filter>
>
> </filter-list>
>
> -----------------filter-1-----------------------
>
> I didn't get what expected.
>
> If we correctly understood the OpenXDAS explanation, this filter spec 
> will copy the fileXXX.YYY (e.g. a test file I have) into the indicated 
> directory every time a *successful create session* event (0x01000007 
> Event Number and Outcome 0) is passed to the XDAS daemon; isn't it?
>
> But when the event occurs the filter doesn't copy the specified file. 
> In the OpenXdas Manual Vers 0.0.294 (page 35) the "*_COMPSEC_*" 
> environment variable has to be defined pointing to 
> */%SystemRoot%\system32\cmd.exe/*.
>
> I already have in my default environment variables a "*_ComSpec_*" 
> variable that points on the same location.
>
> As you can see that is a mismatch between the two names, Is it an 
> error on the manual or I must define another variable?
>
> I actually try to define this additional variable without any result.
>
> I also wrote two applications to test the Java and C XSAS APIs.
>
> For this two application I add an xdas.filter as follows:
>
> -----------------filter-2-----------------------
>
> <filter-list version='OX1'>
>
> <filter name='Account Created' status='On' type='Submit, Import'>
>
> <match>
>
> <allow attr='HdrEvent' op='NE'>0x01000007</allow>
>
> <deny attr='HdrEvent' op='EQ'>0x01000007</deny>
>
> </match>
>
> <action>
>
> <log />
>
> <trigger>
>
> <![CDATA[
>
>                                                copy "C:\aa.log" 
> "C:\AppDev"
>
>                                                ]]>
>
> </trigger>
>
> </action>
>
> </filter>
>
> </filter-list>
>
> -----------------filter-2-----------------------
>
>
> (I want log all events but the Create_Session Audit Record event). 
> When the deny matching occurs, the C application program fails in two 
> points (the Java application works perfectly). This Is the C code:
>
> ----------------code-----------------
>
> #include <xdas.h>
>
> #include <stdio.h>
>
> #include <stdlib.h>
>
> #define 
> CHECK(x)                                                                                                                                             
> \
>
>    {                                              \
>
>       int err;                                    \
>
>      if ((err = (x)) != 0)          {                      \
>
>          printf("xdastest: error %x at: %s(%d).\n", err, __FILE__, 
> __LINE__);                                           \
>
>       }                                           \
>
>                 
>   else                                                                                                                                                                  
> \
>
>                                 printf("xdastest: success %x at: 
> %s(%d).\n", err, __FILE__, __LINE__);                               \
>
>    }
>
> int main()
>
> {
>
>    int minor;
>
>   xdas_audit_ref_t dasref;
>
>   xdas_audit_rec_desc_t arec;
>
>    /* initialize */
>
>    char * org_info = "waldo/apache:http%://waldo.novell.com"
>
>                                                                               
>  ":http:waldo:root:0 <http://waldo:root:0>";
>
>   CHECK(xdas_initialize_session(&minor, org_info, &dasref));
>
>    char * initiator_info = "waldo/nfs:joe:15";
>
>    char * tgt_info = "waldo/apache:http%://waldo.novell.com/index.html";
>
>    char * event_information = "laf-id=1701,my_attribute=32";
>
>   CHECK(xdas_start_record(&minor, dasref, &arec, 
> XDAS_AE_CREATE_SESSION, XDAS_OUT_SUCCESS, initiator_info, tgt_info, 
> event_information));
>
>   CHECK(xdas_commit_record(&minor, dasref, &arec));
>
>   CHECK(xdas_terminate_session(&minor, &dasref));
>
>   system("PAUSE");
>
>   return 0;
>
> }
>
> ----------------code-----------------
>
> The xdas_start_record returns an error code number 16 
> (XDAS_S_INVALID_ORIG_INFO, which is indeed  a Return code of  
> xdas_initialize_session method not of the xdas_start_record!).
>
> Additionally, the xdas_commit_record returns an error code 10012 that 
> is not defined in the xdas.h file.
>
> Note: if I use the filter-1 spec (which is used with the Bandit IdP) 
> the C application works perfectly and returns all 0 error codes 
> (XDAS_S_SUCCESS).
>
> Of course, I have no idea if the behaviour with filter-1 is due to the 
> filtering rule not being fired or to bugs in my code or in the 
> OpenXDAS Lib C code.
>
> As stated my Java test code doesn't report unsuccessful return codes, 
> even if the 2nd filtering rule is partially performed (i.e. the events 
> are logged/not logged according to the specified rule, but the copy 
> command is never executed).
>
> Any Ideas?Did I forgot something?
>
> I hope you have experience with the XDAS also and can help me (or 
> perhaps you can address me to someone else).
>
>
> Thanks in advance.
>
> Best Regards,
>
> Leonardo.
>
>   
> ------------------------------------------------------------------------
>
>
>    
>   
> _______________________________________________
> Bandit-dev mailing list
> Ban...@co...  <mailto:Ban...@co...>
> https://code.bandit-project.org/mailman/listinfo/bandit-dev
>    
>

Re: [openxdas-users] [Bandit-dev] OpenXDAS Record Filtering

[Leonardo S. <leo...@tx...>]

Hi John,  hi All,

thanks for your response. But the question on bandit-list is different and
more detailed than the openxdas-users list. I insert details about the C and
Java APIs and the different behavior with and without the filter.

I tested the “copy” command in a cmd window and it works perfectly.

 

This is my xdas.log file and all seems work without problems (but I don’t
see any lines beginning with “xfilter:” string):

 

------------------------------xdas.log----------------------------------

[Thu May 21 18:20:07 2009] Starting xdasd version 0.6.xxx...

[Thu May 21 18:20:07 2009] Using configuration file C:\WINDOWS/xdasd.conf.

[Thu May 21 18:20:07 2009] Using filter specification file
C:\WINDOWS/xdasd.filter.

[Thu May 21 18:20:07 2009] Using message queue directory
C:\WINDOWS/xdasd.mcache.

[Thu May 21 18:20:07 2009] Using unique ipc path/string
C:\WINDOWS/xdasd.ipc.

[Thu May 21 18:20:07 2009] syslog: Windows Event Service keys already in
place.

[Thu May 21 18:20:07 2009] Logger C:\program
files\openxdas\Loggers\xdm_syslog.dll loaded and initialized.

[Thu May 21 18:20:07 2009] Listening on TCP socket...

[Thu May 21 18:20:07 2009] main: Successfully initialized.

[Thu May 21 18:20:07 2009] Entering main run loop...

------------------------------xdas.log----------------------------------

 

Please read the new e-mail to know the additional details.

 

Any ideas will be appreciated.


Thanks in advance,

                Leonardo.

 

From: ban...@co...
[mailto:ban...@co...] On Behalf Of John
Calcote
Sent: giovedì 21 maggio 2009 20.22
To: leo...@tx...; ban...@co...
Subject: Re: [Bandit-dev] OpenXDAS Record Filtering

 

Dr. Straniero,

I should also mention that the xdasd.log file will indicate if there was a
filter file parse problem. Just look for lines beginning with "xfilter:".
This may help you decipher the problems you may be having.

John

On 5/21/2009 10:55 AM, Leonardo Straniero wrote: 

Hi Daniel, hi All,

 

in the next weeks we will analyze the solutions for the DIT and the
Authentication Method we mentioned in our previous mails. I will keep you
informed on our decisions and progress. Thanks anyway for you suggestions
and hints.

 

We are currently analyzing and trying to configure and use  the OpenXDAS
Framework used in Bandit IdP for Auditing purposes. All seems to work
perfectly, I’m able to use different loggers (SysLog, NetStream, ODBC and
FileLog), with the only exception with the filtering feature. 

Indeed, when I try to use the “XDAS Record Filtering” functionality adding
an  xdas.filter file in the SystemRoot directory (I'm using a Windows XP Pro
machine) with the following content:

 

-----------------filter-1-----------------------

<filter-list version='OX1'>

  <filter name='Account Created' status='On' type='Submit, Import'>

   <match>

     <allow attr='HdrEvent' op='EQ'>0x01000007</allow>

     <deny attr='HdrOutcome' op='NE'>0</deny>

   </match>

   <action>

     <trigger>

       <![CDATA[

                  copy "C:\ fileXXX.YYY" "D:\log_allarm"

       ]]>

     </trigger>

 </filter>

</filter-list>

-----------------filter-1-----------------------

 

I didn't get what expected.

If we correctly understood the OpenXDAS explanation, this filter spec will
copy the fileXXX.YYY (e.g. a test file I have) into the indicated directory
every time a successful create session event (0x01000007 Event Number and
Outcome 0) is passed to the XDAS daemon; isn't it?

 

But when the event occurs the filter doesn’t copy the specified file. In the
OpenXdas Manual Vers 0.0.294 (page 35) the “COMPSEC” environment variable
has to be defined pointing to %SystemRoot%\system32\cmd.exe. 

I already have in my default environment variables a “ComSpec” variable that
points on the same location. 

As you can see that is a mismatch between the two names, Is it an error on
the manual or I must define another variable? 

I actually try to define this additional variable without any result.

 

I also wrote two applications to test the Java and C XSAS APIs. 

For this two application I add an xdas.filter as follows:

 

-----------------filter-2-----------------------

<filter-list version='OX1'>

  <filter name='Account Created' status='On' type='Submit, Import'>

   <match>

     <allow attr='HdrEvent' op='NE'>0x01000007</allow>

     <deny attr='HdrEvent' op='EQ'>0x01000007</deny>

   </match>

                <action>

                               <log />

                               <trigger>

                                               <![CDATA[

                                               copy "C:\aa.log" "C:\AppDev"

                                               ]]>

                               </trigger>

                </action>

 </filter>

</filter-list>

-----------------filter-2-----------------------


(I want log all events but the Create_Session Audit Record event). When the
deny matching occurs, the C application program fails in two points (the
Java application works perfectly). This Is the C code:

 

----------------code-----------------

#include <xdas.h>

#include <stdio.h>

#include <stdlib.h>

 

#define CHECK(x)
\

   {                                              \

      int err;                                    \

     if ((err = (x)) != 0)          {                      \

         printf("xdastest: error %x at: %s(%d).\n", err, __FILE__,
__LINE__);                                           \

      }                                           \

                  else
\

                                printf("xdastest: success %x at: %s(%d).\n",
err, __FILE__, __LINE__);                               \

   }

 

int main()

{

   int minor;

  xdas_audit_ref_t dasref;

  xdas_audit_rec_desc_t arec;

 

   /* initialize */

 

   char * org_info = "waldo/apache:http%://waldo.novell.com"

 
":http:waldo:root:0 <http://waldo:root:0> ";

  CHECK(xdas_initialize_session(&minor, org_info, &dasref));

 

   char * initiator_info = "waldo/nfs:joe:15";

   char * tgt_info = "waldo/apache:http%://waldo.novell.com/index.html";

   char * event_information = "laf-id=1701,my_attribute=32";

  CHECK(xdas_start_record(&minor, dasref, &arec, XDAS_AE_CREATE_SESSION,
XDAS_OUT_SUCCESS, initiator_info, tgt_info, event_information));

 

  CHECK(xdas_commit_record(&minor, dasref, &arec));

 

  CHECK(xdas_terminate_session(&minor, &dasref));

 

  system("PAUSE");

  return 0;

}

----------------code-----------------

 

The xdas_start_record returns an error code number 16
(XDAS_S_INVALID_ORIG_INFO, which is indeed  a Return code of
xdas_initialize_session method not of the xdas_start_record!).

Additionally, the xdas_commit_record returns an error code 10012 that is not
defined in the xdas.h file.

 

Note: if I use the filter-1 spec (which is used with the Bandit IdP) the C
application works perfectly and returns all 0 error codes (XDAS_S_SUCCESS).

Of course, I have no idea if the behaviour with filter-1 is due to the
filtering rule not being fired or to bugs in my code or in the OpenXDAS Lib
C code. 

As stated my Java test code doesn't report unsuccessful return codes, even
if the 2nd filtering rule is partially performed (i.e. the events are
logged/not logged according to the specified rule, but the copy command is
never executed).

 

Any Ideas?Did I forgot something?

 

I hope you have experience with the XDAS also and can help me (or perhaps
you can address me to someone else).


Thanks in advance.

Best Regards,

Leonardo.

 



  _____  



 
_______________________________________________
Bandit-dev mailing list
Ban...@co...
https://code.bandit-project.org/mailman/listinfo/bandit-dev
  

 

Re: [openxdas-users] Help about OpenXDAS Recrod Filtering

[John C. <joh...@gm...>]

Dr. Straniero,

I'm sorry it took so long to respond to this message. The message was 
caught in the mailman processing queue because you aren't registered for 
the openxdas-users mailing list. This isn't a problem for me, as we 
don't get much traffic, so I don't mind going in an manually approving 
such messages, but for some reason I hadn't received the notice from the 
sourceforge mailman server.

Now, to your question:

A point you are perhaps failing to understand is that the contents of 
the CDATA section in this filter are intended to be interpreted by the 
system shell. Thus, whatever you can do in the system shell on the 
system that is running xdasd, you can do in the CDATA section. On the 
other hand, invalid shell commands for the system in question will fail. 
The xdasd daemon copies the contents of the CDATA section into a shell 
script and then executes it.

Here in your example, it appears that you are running xdads on Windows. 
The Windows cmd.exe shell is rather limited in functionality, in 
comparison to bash on Linux. For example, so called "here documents" are 
not recognized by cmd.exe as you're using them in your example. 
Basically, what you need to do is to write, and then manually test a 
cmd.exe batch file that accomplishes your desired task. There are 
third-party utilities that you may use to send email messages on Windows 
(eg., blat, febooti). You may also use the mapisend utility which comes 
with the MS Back Office Resource Kit.

Of course the XDAS variables are available on all platforms, but how you 
use them depends on the shell that's available on your system.

Kind Regards,
John Calcote

On 5/20/2009 3:11 AM, Leonardo Straniero wrote:
>
> Hi All,
>
> I am using OpenXDAS for Auditing purpose on the Bandit Identity 
> Provider Application. I want use the "Record Filtering" functionality.
>
> I try to understand the "xdas.filter" file. I copy this file into the 
> %SystemRoot%\Windows directory.
>
> This is my "xdas.filter" XML file:
>
> <filter-list version='OX1'>
>
> <filter name='Account Created' status='On' type='Submit, Import'>
>
> <match>
>
> <allow attr='HdrEvent' op='EQ'>0x01000007</allow>
>
> <deny attr='HdrOutcome' op='NE'>0</deny>
>
> </match>
>
> <action>
>
> <trigger>
>
> <![CDATA[
>
> mailx -s "Session $XDAS(TGTNAME) opened by $XDAS(INTNAME)" 
> leo...@tx... <<InputFromHERE
>
> $XDAS
>
> InputFromHERE
>
>         ]]>
>
> </trigger>
>
> </action>
>
> </filter>
>
> </filter-list>
>
> I want send a mail to my address if an User session is created 
> (0x01000007 Event Number and Success Outcome) but I not receive any 
> e-mail messages.
>
> I forgot some settings? What is the problem?
>
> Any suggestion will be appreciated.
>
> Thanks in advance.
>
> Best Regards.
>
> *============================*
>
> *Dr. Leonardo Straniero*
>
> CRS - Corporate Research
>
> cid:ima...@01...B03180 <http://www.txt.it/>
>
> c/o Tecnopolis N.O.
>
> Strada Prov. per Casamassima Km 3
>
> 70010 Valenzano (BA) - Italy
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers&  brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing,&
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA,&  Big Spaceship. http://www.creativitycat.com
> ------------------------------------------------------------------------
>
> _______________________________________________
> openxdas-users mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openxdas-users
>    

Re: [openxdas-users] help

[John C. <joh...@gm...>]

Daniele,

You are correct that xdasd may be loaded on multiple computers. Much
like syslogd, xdasd is designed to be loaded onto every computer that is
configured generate XDAS audit events. OpenXDAS clients will not send to
remote xdasd services, however. OpenXDAS clients require the daemon be
loaded on the local host system, so that events from multiple client
processes may be consolidated into a single event stream per host.

I can see that what you are asking is a bit broader than that: Can event
streams from multiple hosts be consolidated into a single event stream,
managed by one host? The answer today is no. We're heading in that
direction, and there are things you can do to help if you wish.

The intent of the *xdas* logger module is just this - to consolidate
event streams from multiple hosts into a single event stream. We just
never finished the xdas logger module before the XDAS standards work
began to move again. We've sort of put OpenXDAS development on hold
until we are more clear on the direction that the Open Group's XDAS 2.0
standard will take.

The work that needs to be done to combine event streams is fairly
trivial, but will require some intense effort for several days:

1. The xdasd service needs to be slightly enhanced to listen for events
from remote xdasd services. This needs to be configured to happen over
encrypted channels using openssl.

2. The xdas logger module needs to be completed so that it will send
XDAS events over a secure channel to a configured xdasd service.

3. This communication channel should be configurable for at least mutual
authentication so that clients (xdasd daemon A) and servers (xdasd
daemon B) can reliably determine who they're both talking to.

At this point, the xdasd daemon acting as the service will combine event
streams from multiple xdasd hosts. This work still needs to be done.

Now, with that said, there is still another alternative: The *netstream*
logger is already working over clear text (and in fact, has the
framework in place for using OpenSSL). This logger will send
CRLF-terminated text strings (XDAS 1.0 events) to any remote host
listening on a TCP port. So you could conceivably configure all of your
OpenXDAS daemons to send events to the netstream logger module, which
would then be configured to forward all events to a single listener.
This listener would be very simple - merely pulling events from the wire
and stuffing them into a file in the order received. This is a simpler
interim solution, and might be able to be implemented easily with a
perl, python or php script. It's not secure, but if you're behind a
firewall anyway, it might be good enough until OpenXDAS is more
functional. And if you don't mind using the trivial security features of
these scripting languages in your server, and digging in just a little
bit with the netstream logger, it would be rather trivial to make it
secure by finishing up the openssl framework in the netstream logger.

I'll be working on these things over Christmas anyway, so you could also
just wait... :)

Warm regards,
John Calcote
OpenXDAS Project Lead,
Novell, Inc.

Daniele De Santis wrote:
> Hi!
> I'm new user of openxdas.
> I managed the xdas.filter file in the same pc where xdasd is loaded.
> I use this java class as client:
>  
> *public class AllTests
> {
>  public static void main(
>   String[] args) throws XDasException, SocketException, IOException
>  {
>   try
>   {
>   // String sOriginatorLocationName, String
> sOriginatorLocationAddress, String sOriginatorServiceType, String
> sOriginatorAuthAuthority, String sOriginatorPrincipalName, String
> sOriginatorPrincipalIdentity
>    XDasSession session = new XDasSession("sOriginatorLocationName",
>                                      "sOriginatorLocationAddress",
> "sOriginatorServiceType", "sOriginatorAuthAuthority",
> "sOriginatorPrincipalName", "sOriginatorPrincipalIdentity");
>    
>    //String sInitiatorInfo,String sTargetInfo,String sEventInfo
>    XDasRecord rec =
> session.XDasStartRecord(XDasEvents.XDAS_AE_QUERY_ASSOC_CONTEXT,
> XDasOutcomes.XDAS_OUT_ENTITY_NON_EXISTENT,
>                                                     
> "sInitiatorInfoSSSSS",
>                                                      "sTargetInfo",
>                                                      "sEventInfo");   
>   // rec.
>    
>             rec.commit();
>   }
>   catch (XDasException ex)
>   {
>    System.out.println( "XDas Error: " + ex.getStatus() + ", Minor
> Code: " + ex.getMinorStatus());
>   }
>  }
> }*
>  
> With this class I send an event that I filter in the xdas.filter file.
> With this file I sent a mail to a mail account.
>  
> Some questions:
>  
> How can I send an event from a PC to other PC? (xdasd may loaded on
> the two pc,isn't right?)
> if I send an event with AllTests class on a server that filtered it,
> that will be send to other server xdasd?
>  
> Thank you
> ---------------------------------------------
> Daniele De Santis
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> openxdas-users mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openxdas-users
>   

[openxdas-users] help

[Daniele De S. <dan...@en...>]

Hi!
I'm new user of openxdas. 
I managed the xdas.filter file in the same pc where xdasd is loaded. 
I use this java class as client:

public class AllTests
{
 public static void main(
  String[] args) throws XDasException, SocketException, IOException 
 {
  try
  {
  // String sOriginatorLocationName, String sOriginatorLocationAddress, String sOriginatorServiceType, String sOriginatorAuthAuthority, String sOriginatorPrincipalName, String sOriginatorPrincipalIdentity
   XDasSession session = new XDasSession("sOriginatorLocationName",
                                     "sOriginatorLocationAddress", "sOriginatorServiceType", "sOriginatorAuthAuthority", "sOriginatorPrincipalName", "sOriginatorPrincipalIdentity");
   
   //String sInitiatorInfo,String sTargetInfo,String sEventInfo
   XDasRecord rec = session.XDasStartRecord(XDasEvents.XDAS_AE_QUERY_ASSOC_CONTEXT, XDasOutcomes.XDAS_OUT_ENTITY_NON_EXISTENT,
                                                     "sInitiatorInfoSSSSS",
                                                     "sTargetInfo",
                                                     "sEventInfo");   
  // rec.
   
            rec.commit();
  }
  catch (XDasException ex)
  {
   System.out.println( "XDas Error: " + ex.getStatus() + ", Minor Code: " + ex.getMinorStatus());
  }
 }
}

With this class I send an event that I filter in the xdas.filter file. With this file I sent a mail to a mail account.

Some questions:

How can I send an event from a PC to other PC? (xdasd may loaded on the two pc,isn't right?)
if I send an event with AllTests class on a server that filtered it, that will be send to other server xdasd?

Thank you
---------------------------------------------
Daniele De Santis

Re: [openxdas-users] OpenXDAS Requires: rpmlib(PayloadIsLzma) <= 4.4.2-1

[John C. <joh...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shawn McKinney wrote:
> Greetings,
> 
> We are trying out OpenXDAS on a Centos 5 workstation.
> When I try to install the below package I receive a
> dependency error on
> D:  Requires: rpmlib(PayloadIsLzma) <= 4.4.2-1        

Shawn,

Where did you get this rpm from? The OpenSUSE build service? If so, I've
not tested that particular build. Perhaps you could try building from
source? It's really pretty simple. Just go get the current tar.gz (or
bz2) file from http://www.sf.net/projects/openxdas, unpack it and do the
usual "configure && make" dance.

In fact, you'll find that the source tarball is a bit more up to date
(minor tweaks), as I haven't had time to get out to the build service
lately and update the build.

I know this isn't an ideal answer. It would be nice to have a binary
package to install, but I don't have a CentOS test bed. (Although I do
have VMWare workstation, and I've been meaning to set up a few VM's that
I can use to test such install packages -- not enough time in the day).

Let me know if I can help.

Regards,
John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkh1B5kACgkQdcgqmRY/OH9jXwCffGCUDFuGFYxRyOXe8VTSXLp5
s1QAniA3ciI5atsx2GY9K53mgzcSbnoT
=w958
-----END PGP SIGNATURE-----

[openxdas-users] OpenXDAS Requires: rpmlib(PayloadIsLzma) <= 4.4.2-1

[Shawn M. <smm...@sb...>]

Greetings,

We are trying out OpenXDAS on a Centos 5 workstation. 
When I try to install the below package I receive a
dependency error on 
D:  Requires: rpmlib(PayloadIsLzma) <= 4.4.2-1        
     

I have searched the Web and can't seem to locate the
required lib.  Is there somewhere I can download the
necessary rpm from?

Thanks in advance for your reply.

Shawn


Here is the trace from the attempt to install
OpenXDAS:

[root@centos5 OpenXDAS]# rpm -Uvv
openxdas-devel-0.6.294-1.7.i586.rpm
D: ============== openxdas-devel-0.6.294-1.7.i586.rpm
D: Expected size:        39963 =
lead(96)+sigs(348)+pad(4)+data(39515)
D:   Actual size:        39963
D: opening  db environment /var/lib/rpm/Packages
joinenv
D: opening  db index       /var/lib/rpm/Packages
rdonly mode=0x0
D: locked   db index       /var/lib/rpm/Packages
D: opening  db index       /var/lib/rpm/Pubkeys rdonly
mode=0x0
warning: openxdas-devel-0.6.294-1.7.i586.rpm: Header
V3 DSA signature: NOKEY, ke
y ID 9a39eba4
D: opening  db index       /var/lib/rpm/Providename
rdonly mode=0x0
D:      added binary package [0]
D: found 0 source and 1 binary packages
D: ========== +++ openxdas-devel-0.6.294-1.7
i586/linux 0x0
D: opening  db index       /var/lib/rpm/Depends create
mode=0x0
D:  Requires: rpmlib(PayloadFilesHavePrefix) <= 4.0-1 
     YES (rpmlib provides                             
                                              )
D:  Requires: rpmlib(CompressedFileNames) <= 3.0.4-1  
     YES (rpmlib provides                             
                                              )
D:  Requires: rpmlib(PayloadIsLzma) <= 4.4.2-1        
     NO
D: package openxdas-devel-0.6.294-1.7.i586 has
unsatisfied Requires: rpmlib(Payl                     
                                                     
oadIsLzma) <= 4.4.2-1
D: opening  db index       /var/lib/rpm/Conflictname
rdonly mode=0x0
D: closed   db index       /var/lib/rpm/Depends
error: Failed dependencies:
        rpmlib(PayloadIsLzma) <= 4.4.2-1 is needed by
openxdas-devel-0.6.294-1.7                            
                                               .i586
D: ========== recording tsort relations
D: ========== tsorting packages (order, #predecessors,
#succesors, tree, depth,                              
                                              breadth)
D:     0    0    0    0    1    0  
+openxdas-devel-0.6.294-1.7.i586
D: closed   db index       /var/lib/rpm/Pubkeys
D: closed   db index       /var/lib/rpm/Conflictname
D: closed   db index       /var/lib/rpm/Providename
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages

[openxdas-users] OpenXDAS 0.6.294 Released!

[John C. <joh...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Everyone,

I'm happy to announce that version 0.6.294 of the OpenXDAS project has
been released today. This version includes the following changes:

* An enhanced netstream logger, that has the beginnings of SSL code in
order to handle encrypted data streams. While this change doesn't affect
users directly, it does show our direction with the netstream logger.
The next release will have full encryption.

* Documentation has been enhanced for this release.

* The Win32 side of the system logger has been much enhanced to properly
submit the XDAS record as the text log entry, rather than the associated
binary data, as has been done in previous releases. This should make
auto-parsers much happier with XDAS records found in the the Win32 event
logs.

* The java client class is now in the correct name space.

* Both the C and Java clients now support the extended OpenXDAS events
(currently being added to the new XDAS standard as part of the
Update-XDAS initiative sponsored by Novell and the Open Group Security
Forum. These events include authentication material modification,
workflow and role management events.

* We're now taking full advantage of the OpenSuSE Build Service (OBS) at

  http://software.opensuse.org/search

Enter "openxdas" in the search dialog and select your desired platform,
or select "all" to find out which platforms are currently available.
We're working every day to get new platforms added, so don't be
discouraged if you don't find your's in the list.

Where to get it...
==================

Please visit the openxdas web site download and documentation pages at

  http://openxdas.sourceforge.net/download.html
  http://openxdas.sourceforge.net/documentation.html

to find links for downloading this new version and it's associated
documentation.

Enjoy!
John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIPu6OdcgqmRY/OH8RAma6AKCX0gI/lvMUNHmDQSJ4is4/kJgu9gCbBThI
5eQ8ZHfNfXvnSTMwJUcL/ns=
=S1UN
-----END PGP SIGNATURE-----

Re: [openxdas-users] OpenXDAS for Win32 under .NET framework

[John C. <jca...@no...>]

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:John Calcote
TEL;WORK:1-801-861-7517
ORG:;Unified Identity System Eng TE
TEL;PREF;FAX:801/861-2292
EMAIL;WORK;PREF;NGW:JCA...@no...
N:Calcote;John;;Sr. Software Engineer
TITLE:Sr. Software Engineer
ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;1800 South Novell Place;Provo;UT;8460=
66194
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:John Calcote=3D0A=
=3D
PRV-H-511=3D0A=3D
1800 South Novell Place=3D0A=3D
Provo, UT  846066194
END:VCARD

[openxdas-users] Windows VC8 redistributable runtime libraries available

[John C. <jca...@no...>]

Everyone,

It's recently come to my attention that the OpenXDAS .msi installer package for windows depends on the Visual C++ 8 C-language runtime library - part of the so-called redistributable package provided by Microsoft for programs built using Visual Studio 2005 (VC8). 

The reason I didn't notice this earlier is that these runtime libraries are already installed on machines where the development environment is installed (including all of my development machines). It wasn't until a user without visual studio tried to install the openxdas msi and found the service wouldn't launch that I became aware of this issue. 

In response, I've published a self-contained executable installer called vcredist_x86.exe as part of the OpenXDAS downloadable package set on sourceforge.net. 

Please download both vcredist_x86.exe and the current openxdas msi installer, then run the vcredist package first before attempting to install the msi package.

We'll integrate the vc8 redistributable package with the openxdas msi installer in a future release. 

Thanks for your patience,
John

-----
John Calcote (jca...@no...)
Sr. Software Engineeer
Novell, Inc.