Am Donnerstag 23 April 2009 schrieb Michael Wiegand: > Hello, > Hi Michael and Jan, > Jan and I have been thinking about discontinuing the release of > openvas-plugins tarballs and distributing the plugins only through the > existing Feed Services. > > The background is that using both the tarball and the openvas-nvt-sync > script does under certain conditions lead to a race condition in the > plugin cache which causes openvasd to use an outdated cached version of > a plugin even though the plugin has changed in the feed. We have tried > to compensate for this by making adjustments in the synchronization > script, but this has the side effect of disproportionately increasing > the time and bandwidth needed to synchronize with the feed. > > I would like your opinions regarding the following issues: > > - What would be the consequences of discontinuing the tarball release? > There should not be installations which use only the tarball and never > sync, should there? >
I think, there were be no consquences at all. The only thing, that copmes in my mind, would be a possibility to transport the tarball to factories, which might have (for waht reasons ever) , no access to the internet. In this case it would be nice, to have a possibility to add new plugins or add plugins at all. > - What mechanisms should be available for users who cannot sync using > rsync due to restrictions on firewall or proxy level? > I think, most users should have access to the internet with http, and as far as I know, rsync offers an option, to use http (if I remember correctly). In other case, there comes the word "tunneling" in my mind. Maybe to invent an easy way for users, to tunnel through http??? > - Should openvasd force an initial sync during installation or just > display a notice that a sync is need to use OpenVAS? > I suggest, not to force an initial sync, as some users or security analysts might want to test new plugins before they break things at their customners. It might be, they want to keep old plugins during tests. IMO the suggestion is the better way, so the security analyst can decide for himself, if to upgrade or not. > - Any other issues you can think of. :) None at the moment. :) > > I'm looking forward to your opinions. Please do not hesitate to ask if > my proposal does not make sense to you. > > I am crossposting this to openvas-discuss and openvas-plugins as well to > reach all involved parties. Please keep crossposting to a minimum in > your replies and try to reply in openvas-devel. Thank you! > > Regards, > > Michael Best regards Hans-J. Ullrich -- Firma Ullrich-IT-Consult Inh.: Hans-J. Ullrich Münstedter Weg 10 31246 Oberg www: http://www.ullrich-it.de www2: http://www.ccpeine.de IT-Spezialist für die Bereiche IT-Sicherheit, Linux und Unix, EDV-Schulungen und -Workshops
_______________________________________________ Openvas-devel mailing list Openvas-devel@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
