Re: [Os-sim-devel] OSIM arquitecture: too many components?

[DK <dk...@ip...>]

Hi,

El 9/27/03 16:46, "Jose Vicente Nunez Zuleta" <jo...@ne...>
escribi=F3:

> Hi to all, my answers are below
>
>> Os-sim is growing very fast and at this point I agree with you, we have
>> to
>> be careful about what direction we want take. This is why we stopped
>> development for a few days so we can decide what, when and how we want
>> to
>> integrate tools, what DB / languages to use and how to glue everything
>> together.
>=20
> I think an update on the architecture diagram is a must. Also it is impor=
tant
> to have a list of deliverables,
> so people interested in the project knows what to expect when (maybe this=
 is
> probably too much).
>=20

Both issues are going to be solved when we release the roadmap (I don't kno=
w
when, hopefully next week) so we can provide the following:

- In depth system architecture.
- What to expect from updates until 1.0 is released. What we want to do
until 2.0. When to expect all of this.
- Tasks for ourselves as well as for anyone wishing to help with the
project.

>>=20
>> Again I have to ask you to excuse us for the lack of documentation. I
>> hope
>> this will change soon, we are working on it so we are able to transmit
>> our
>> thoughts and ideas about how everything should work.
>>=20
>=20
> I was thinking than maybe a less loosely coupled architecture is the best
> here; In that way the product could be
> integrated not only with OpenNMS but other NMS out there as well.
>=20
> I'm sending a deployment diagram i draw, maybe you will find it interesti=
ng :)
>=20

Interesting indeed. Why do you think it would be useful to integrate jabber
?
Besides, our intention is to move as many things we can away from syslog
because syslog (or syslog-ng, as you want) slows things down. We have to
speed everything up, speed it a lot up so that's our main focus as of today=
.

I have to draw a new architecture map, hopefully this week I can get two
hours to redraw it.

>>=20
>>=20
>> Then next four questions (except PHP vs. Java) should be answered soon.
>> Please have a look at my diary
>> (http://sourceforge.net/developer/diary.php?diary_id=3D14122&diary_user=3D82=
5580
>> ) where I posted some thoughts today. I didn't want to show them on the
>> main
>> site because they are personal thoughts and I would like to discuss
>> them
>> whit the rest of the team so we can come up with some good
>> documentation /
>> todo list / roadmap.
>>=20
>> Resuming what I wrote related to your questions:
>>=20
>> - We want to get rid of MRTG. We don't need it.
>=20
> ok
>=20
>>=20
>> - We have to decide between mysql & postgresql. Both have its pro's and
>> con's.
>>=20
>=20
> Ok. Again, i think PostgreSQL is better suited for this task (this can be
> discussed in detail).

We have to decide this issue soon. I think it is going to be easier to
rewrite our C code to make use of postgresql rather than move OpenNMS to
MySQL. No decision taken as of today.

>=20
>> - Of course nessus-opennms integration would be done after talking with
>> Opennms's creators.
>=20
> Great.
>=20
>> - We have to write a data consolidator which accepts input from many
>> more
>> devices.
>=20
> Syslog could be a first option, and then more could be added as 'plugins'=
?
>=20

As stated before, we want to move away from syslog for speed reasons, but o=
f
course not everything because some products are better integrated within
syslog. And we want to correlate system events too (both unix & windows).

>> - C is needed. Perl isn't but can solve temporary problems. At the end,
>> the
>> whole core should be written in C.
>=20
> You could still use a language like Python to do the scripting part; Is e=
asier
> to extend in C than Perl (you don't need
> Swig for that). Supports objects better than Perl, etc. Also if you wanna=
 use
> Jython instead of Python that makes it easier
> to glue it together with Java.
>=20
> I would use C only for tasks that require the speed, i think Java is bett=
er
> suited as the main languaje of the application.

Personally I don=B9t like Java although this opinion is changing lately. The
scripting part is only a temporary solution because every single component
needs to run as fast as possible so C is going to be used for the main core=
.
Around that we can build over every language that suits our needs. Java is
going to be an alternative, that for sure, but we will also use PHP, Perl
and why not, python is also an alternative (I love python).

=20
>>=20
>> We want to make use a lot of opennms's many good features but we think
>> some
>> of them are better kept separated because there are already very good
>> programs out there that do their specific job.
>>=20
>> I don't think it is such a good idea to rewrite ntop entirely only to
>> get a
>> tighter integration with opennms.
>>=20
> I agree. Actually i would leave out NTOP and would rely on OpenNMS for th=
e
> network monitoring and analysis.

Agreed.

>>=20
>> As of network discovery, at this moment we use nmap only for a couple
>> of
>> things. It's planned to add service discovery but I think its better to
>> compare and complement NMS data with nmaps input rather than to rely
>> entirely on its own network discovery, mainly because many times we
>> don't
>> want the full set of opennms's discovery and poller related features.
>>=20
>=20
> But again, what sense it makes to have two applications discovering nodes=
 at
> the same time? OpenNMS discovery capabilitites
> can be extended easily using Java plugins and the Assest database is fair=
ly
> complete; I think the goal of this project
> should be focus on how to analize all the data gathered by OpenNMS, Snort=
,
> Syslog instead of replicate
> the polling and discovery functionality.

Perhaps my lack of knowledge of the inner workings of OpenNMS misleads me,
but I think for some small specific functions we should better rely on
specific programs, as with Ntop.

How does opennms's service detection work ? Does it rely on port number or
does it make some checks to ensure port 53 is DNS indeed (for example) ? Is
this work based on existing applications like amap or is it a complete new
write up in Java ?

What about host and port discovery ? Does it use nmap or scanrand or
something similar or is it written up from 0 ?

If you have tried the program out you'll have noticed that OpenNMS
integration at this point is minimal. Only one link from the main page but
not as tight integrated as ntop or rrd for example.

One of the first items in my TODO list is to dissect OpenNMS's code so to
know exactly what can be used where, but as always, time, time, time...

>>=20
>> Again thank you very much.
>=20
> Let me known if you're looking for developers.

As soon as our roadmap is complete.

Thanks for the input.

DK