* Stjepan Gros [21. Dec 2008]:
> This wasn't so easy. I _think_ this works, but I didn't yet tested
> enough, and also, there is a catch. If you try to make subdirectories
> inside plugins directory it'll complain that it can not find include
> files. This can not be solved without introducing include directories,
> what I'll do in the next few days. Also, my intention to keep things
> compatible with the previous installations/versions (meaning, if you
> don't specify cache_folder in conf. file that everything behaves as
> before) complicates things a bit, but not so drastically.
Thanks a lot for your hard work! I've already skimmed over your patch so
far, it looks pretty sound to me.
> The main problem with the introduction of the cache directory is that
> it's hardcoded in, at least, two places. First, some functions inside
> store.c themselves construct path by adding ".desc" on the plugins
> directory, while the other use variable "sys_store_dir" which has the
> same value. It doesn't seem necessary to be so, but this has to be
> discussed. Additionaly, the functionality can be placed in several
> places and it's hard to determine the best one based on the partial
> knowledge of openvas I have.
I agree that this should be consistent and preferably not hardcoded.
Regarding the placement, feel free to make a suggestion, I (and others)
will be glad to assist you with that.
> And, finally, two notes. First, it seems that when openvasd server
> sends the client data about plugins, for several attributes that are
> sent, it reads disk and loads cached version of a plugin for each
> attribute. I didn't investigate it further, but maybe someone can say
> more about that. The execution path is send_plug_info ->
> plug_get_{version,cve_id,bugtraq_id,xref,tag,family,summary,description,copyright}
> -> store_fetch_{...} -> store_get_plugin (which reads cached plugin).
I'll have to look into that myself, I might be able to take a closer
look after the holiday season. I've noticed some unexpected results
while using the cache, it might be a good idea to think about cleaning
up there while we are at it.
I have notice we seem to be constructing a lot of paths and filenames
"by hand" with snprintf and the like. I recently discovered (thanks to
Felix) that glib offers some nice functionality there in the form of
g_build_path and g_build_filename. Do you think it might be useful to
use them as well with your work?
Regards,
Michael
--
Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
_______________________________________________
Openvas-devel mailing list
Openvas-devel@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
