Weird bug – babel SVN Build BC070806 – Agents offline

[manu]

Like it

Up

0

Down

Drop it

::

Hi David,

Can you confirm me you’re using version 2.0 of babel?

[davidp]

Like it

Up

0

Down

Drop it

::

I’m using the SVN trunk version 1.1

I recompiled it because it runs on a x64 CPU.

David

[Sancho]

Like it

Up

0

Down

Drop it

::

Hi all,

The only disgression I did from the original setup is that I do not allow the the mysql user to do anything else than insert / select / delete / alter records. Is there a right (like execute scripts) which is needed to operate babel on the mysql server?

Best regards,
David

Seems to be everything ok. Offline Agents have data inside ?. What is the interval for that agents ?. Remember that interval in babel is in MINUTES, so a 10080 interval is for gathering data every week.

[davidp]

Like it

Up

0

Down

Drop it

::

The agents are still declared offline, although on the server, I get a lot of :

[code:1]Registering audit #x from agent ‘host’

On the babel console, I see that the policy is run, but it’s like it has returned no data or something.

[manu]

Like it

Up

0

Down

Drop it

::

Can you run the agent in debug mode and see if the XML has any data?

[davidp]

Like it

Up

0

Down

Drop it

::

If started in gdb, the output is as follow:

[code:1]babel-server v1.0.0 (build 080131) 2005-2007 (web site ommited)

Program received signal SIGSEGV, Segmentation fauilt.
0x00002ac88e67cbb0 in strlen () from /lib64/libc.so.6

The bt command returns the following:
[code:1]#0 0x00002b988549abb0 in strlen () from /lib64/libc.so.6

#1 0x00002b988546a84d in vfprintf () from /lib64/libc.so.6

#2 0x00002b988548cb7d in vasprintf () from /lib64/libc.so.6

#3 0x00002b98847fcc50 in g_vasprintf () from /usr/lib64/libglib-2.0.so.0

#4 0x00002b98847ee590 in g_strdup_vprintf () from /usr/lib64/libglib-2.0.so.0

#5 0x00002b98847c1a68 in ?? () from /usr/lib64/libglib-2.0.so.0

#6 0x00002b98847c1b21 in g_set_error () from /usr/lib64/libglib-2.0.so.0

#7 0x000000000040df78 in babel_db_connection_query ()

#8 0x000000000040fc92 in babel_server_init_source ()

#9 0x000000000040fe58 in babel_server_start ()

#10 0x0000000000406ce9 in main ()

I guess it’s expected from code coming from trunk, but it was running flawlessly previously so I’m a bit at a loss. No update has been done on the OS either.

[manu]

Like it

Up

0

Down

Drop it

::

Oh no, you miunderstood me, or I didn’t explain myself well.
I meant put the agent in debug mode, this means, edit babel_agent.conf and set debug 1
debug mode means that the agent will run as expected but the XML will remain in /var/spool/babel/data_out it won’t be copied to the server so you can analyze it.

So, set the debug mode and when the agent is done, take a look at the XML and see if there’s data in it.

Let us know what’s going on!

[davidp]

Like it

Up

0

Down

Drop it

::

As requested, here’s an exert from a typical xml file on the babel server “/var/spool/babel/babel_in”:

[code:1]

02/15/08 05:26:40

10080

Account Policyuser_policy
is not /etc/login.defs
is not /etc/login.defs
is not /etc/login.defs
is not /etc/login.defs

.
.
.
Service enabled
Service enabled
Service enabled
Service enabled

SnmpAgentremote
_Dangerous community name

SetUID Filessetuid

Tomcat5remote

UID0uid0

Regards,
David

[Sancho]

Like it

Up

0

Down

Drop it

::

As requested, here’s an exert from a typical xml file on the babel server “/var/spool/babel/babel_in”:
Regards,
David

Rename to .xml and try to open locally with a browser (mozilla/firefox) to check if XML is correct. This could the first problem, some 1.1 modules generate bad XML…

[manu]

Like it

Up

0

Down

Drop it

::

Hi Davidp

did you delete any data of that XML before posting it here?
There’s no name for the agent in that XML, that could be a problem

[Sancho]

Like it

Up

0

Down

Drop it

::

Hi Davidp

did you delete any data of that XML before posting it here?
There’s no name for the agent in that XML, that could be a problem

A big problem 🙂

[davidp]

Like it

Up

0

Down

Drop it

::

It seems that something in the “trunk” branch of svn was broken after all.

I solved the problem by compiling from ./branch version of babelserver instead ./trunk and everything began working properly.

This thread can now be closed, thanks for the help. 🙂

Regards,
David

[manu]

Like it

Up

0

Down

Drop it

::

Could be, even though I installed a Babel (with all its components; agent, database, console and server) three days ago and I didn’t face any problem. I got it directly from the trunk/
Your problem is weird :-/

[davidp]

Like it

Up

0

Down

Drop it

::

Were you using a i386 or x64 system?

The problem I experienced was with a x64 system.

If you tell me what to type in gdb, I can compile it with symbols and let you see where it crashes.

Regards,
David

[manu]

Like it

Up

0

Down

Drop it

::

x86

Given the XML you posted here, it’s more likely an agent problem, not a server one.
As long as the XML doesn’t have any agent name in it, the server doesn’t know who assigns the data to.

Did you erase any data of the XML you posted here or you just posted it as you had it in your system without any modification?

[davidp]

Like it

Up

0

Down

Drop it

::

Yes, as the text was making 96Kb

Besides, I still have the sourcecode, I could recompile trunk but as I said, I was getting segmentation fault with the trunk “babelserver” lately.

That said, I didn’t change the agents, just the server and the thing began working so if it was an XML issue, “branch” babelserver would still crash.

The fact I dropped the database and recreated it might have helped too.

I’ll have to retest with the ” trunk ” babelserver later today. I’ll keep you posted.

[manu]

Like it

Up

0

Down

Drop it

::

Yeah, please let me know what happens.
The babelserver of the trunk/ is by far much better than the 1.1 one