Hello Stjepan,
On Tuesday 09 December 2008 18:16:59 Stjepan Gros wrote:
> On Tue, Dec 9, 2008 at 9:40 AM, Jan-Oliver Wagner
> > * note that there are still some C-plugins (*.nes) in the plugins
> > directory that are platform-dependent.
> > We are working on resolving them, but it will take some time.
> > So, the directory reorganization should consider this in some way.
>
> This is, as I understand it, short term state, and thus can be ignored
> because eventually they will be replaced with platform independent
> versions.
uh, well, depends on the definition of "short term" :-)
In fact I 'd like to get rid of *.nes during 2009.
> Furthermore, what I'm proposing is to introduce appropriate
> infrastructure into openvas that will allow plugins to be reorganized
> but in the end, this infrastructure is (almost) independent from the
> chosen plugin organization.
Indeed a good plan.
> The patch, as I wrote it, doesn't care about the exact organization.
> You could say:
>
> plugins_folder=/usr/local/share/openvas/plugins
> include_folder=/usr/local/share/openvas/plugins/nvt/lib
correct.
> and this would work. What wouldn't work (yet) is cache directory which
> has to be changed to store cached plugins to follow OIDs.
> the small problem could be when there is numerical OID without
> symbolic name. in that case openvas server can use numerical value as
> a name of directory, but, this can cause some confusion when symbolic
> name is introduced into the server and now there is numerical as well
> as symbolic directory. the best place to put numeric to symbolic
> mapping would be in configuration file, but it will take some time to
> be implemented and also exact configuration directives have to be
> defined. maybe i would leave this after the first version works.
we could also have symbolic links to have both, the number and name
representation. However, I don't think it is a really urgent problem.
> > Another aspect is the search path: will .inc files first searched for in
> > the same directory as the .nasl is?
>
> I don't have any special opinion about this, both cases are of the
> same implementation complexity. Maybe one pro for search of the same
> directory is that in that case include files could be overwritten with
> the local version. But in the end, I think it's better to ask plugin
> writers what they want/think about this issue.
yes.
> > I propose a careful step-by-step implementation.
> > For example, moving the caching into a separate directory would be a
> > first nice step. There, it could already be realized to have a directory
> > strucure based on the OIDs of the NVTs.
>
> This idea is fine with me. I could split patch so that only cache is
> changed. This could be first iteration. What is not implemented is
> storing plugins according to OID and to try to implement that part
> would be the second iteration.
that would be just perfect.
Best
Jan
_______________________________________________
Openvas-devel mailing list
Openvas-devel@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
