Re: [Openvas-discuss] planning release openvas-libraries 1.0.1
Now that OpenVAS is working on my Gentoo box, I thought I'd give it a go on the OpenBSD 4.2 (stable) box. The OpenBSD system is also running AMD64, so 64-bit-ness applies... First attempt to build -libraries: checking for a BSD-compatible install... /usr/bin/install -c checking for __dn_expand in -lresolv... no configure: error: you need to install resolve library with development files # grep -ir dn_expand /usr/include/resolv.h /usr/include/resolv.h:#define dn_expand __dn_expand /usr/include/resolv.h:int dn_expand(const unsigned char *, const unsigned char *, I did find this article dealing with 'libresolv' issues in OpenBSD (though from other poking about, it seems to be the same in all Berkeley based *NIX's). http://www.onlamp.com/pub/a/bsd/2006/04/27/openbsd-3_9.html?page=3 it looks like the '-lresolv' function is deprecated, having been pulled into the main 'libc.so' library. http://nixdoc.net/man-pages/OpenBSD/dn_expand.3.html Hope this helps. -- Ed Vazquez 2008-03-27 09:07 Engineer: A person who knows a great deal about very little and who goes along knowing more and more about less and less, until finally he knows practically everything about nothing. -Original Message- From: [EMAIL PROTECTED] [mailto:openvas- [EMAIL PROTECTED] On Behalf Of Jan-Oliver Wagner Sent: Wednesday, March 26, 2008 18:33 To: openvas-discuss@wald.intevation.org Subject: [Openvas-discuss] planning release openvas-libraries 1.0.1 Hi, quite a lot of code cleanups happened for openvas-libraries. No real new functionality has been added. In fact, some have been removed as agreed. However, some of the cleanups are about the include files and one consquence is that build might fail on some platforms, especially other than GNU/Linux. As discussed earlier on this list is that this should not stop us in making this the 1.0.1 release nonetheless. If there is no objection I'd like to do the release end of this week. After all it is an intermediate step as there are some cleanups left to do. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner ___ Openvas-discuss mailing list Openvas-discuss@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss smime.p7s Description: S/MIME cryptographic signature ___ Openvas-discuss mailing list Openvas-discuss@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
[Openvas-discuss] OpenVAS Gentoo AMD64 not working properly.
OK, looked in the logs and what I'm seeing is are entries like this: [Thu Mar 27 10:09:31 2008][12463] no404.nasl depends on httpver.nasl which could not be found In turn, this seems to cause: [Thu Mar 27 10:09:31 2008][12463] user evazquez starts a new scan. Target(s) : 172.16.8.241, with max_hosts = 20 and max_checks = 4 [Thu Mar 27 10:09:31 2008][12463] user evazquez : testing 172.16.8.241 (172.16.8.241) [12464] [Thu Mar 27 10:09:39 2008][12464] SIGSEGV occured ! [Thu Mar 27 10:09:39 2008][12463] user evazquez : test complete on each test cycle. There seem to be about 113 depends on files that the log file claims are missing, even though they are actually present. E.g.: [Thu Mar 27 11:48:17 2008][12452] connection from 172.16.16.56 [Thu Mar 27 11:48:18 2008][12854] Client requested protocol version 12. [Thu Mar 27 11:48:18 2008][12854] successful login of evazquez from 172.16.16.56 [Thu Mar 27 11:48:21 2008][12854] no404.nasl depends on httpver.nasl which could not be found [Thu Mar 27 11:48:21 2008][12854] no404.nasl depends on webmirror.nasl which could not be found ... [Thu Mar 27 11:48:21 2008][12854] invision_power_board_calendar_sql_injection.nasl depends on invision_power_board_detect.nasl which could not be found [Thu Mar 27 11:48:21 2008][12854] user evazquez starts a new scan. Target(s) : 172.16.8.241, with max_hosts = 20 and max_checks = 4 [Thu Mar 27 11:48:21 2008][12854] user evazquez : testing 172.16.8.241 (172.16.8.241) [12855] [Thu Mar 27 11:48:29 2008][12855] SIGSEGV occured ! [Thu Mar 27 11:48:29 2008][12854] user evazquez : test complete # ls -al /usr/local/lib/openvas/plugins/no404.nasl -r--r--r-- 1 root root 9831 Mar 26 15:52 /usr/local/lib/openvas/plugins/no404.nasl # ls -al /usr/local/lib/openvas/plugins/httpver.nasl -r--r--r-- 1 root root 5323 Mar 26 15:52 /usr/local/lib/openvas/plugins/httpver.nasl # ls -al /usr/local/lib/openvas/plugins/webmirror.nasl -r--r--r-- 1 root root 31229 Mar 26 15:52 /usr/local/lib/openvas/plugins/webmirror.nasl Very odd - any ideas on cause? More data I can provide for troubleshooting? Thanks, -- Ed Vazquez 27 March 2008 11:52:15 Segal's Law: A man with a watch knows what time it is. A man with two watches is never sure. smime.p7s Description: S/MIME cryptographic signature ___ Openvas-discuss mailing list Openvas-discuss@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
Re: [Openvas-discuss] OpenVAS Gentoo AMD64 not working properly.
Hello Ed, On Thursday 27 March 2008 18:54, Vazquez, Ed wrote: OK, looked in the logs and what I'm seeing is are entries like this: [Thu Mar 27 10:09:31 2008][12463] no404.nasl depends on httpver.nasl which could not be found that is OK. Many NASL scripts of Nessus were not Free Software and thus the OpenVAS project removed but kept other scripts that depend on them. In turn, this seems to cause: [Thu Mar 27 10:09:31 2008][12463] user evazquez starts a new scan. Target(s) : 172.16.8.241, with max_hosts = 20 and max_checks = 4 [Thu Mar 27 10:09:31 2008][12463] user evazquez : testing 172.16.8.241 (172.16.8.241) [12464] [Thu Mar 27 10:09:39 2008][12464] SIGSEGV occured ! [Thu Mar 27 10:09:39 2008][12463] user evazquez : test complete on each test cycle. hm, I can not repdoduce this on my Debian Sarge box. There seem to be about 113 depends on files that the log file claims are missing, even though they are actually present. E.g.: [Thu Mar 27 11:48:17 2008][12452] connection from 172.16.16.56 [Thu Mar 27 11:48:18 2008][12854] Client requested protocol version 12. [Thu Mar 27 11:48:18 2008][12854] successful login of evazquez from 172.16.16.56 [Thu Mar 27 11:48:21 2008][12854] no404.nasl depends on httpver.nasl which could not be found [Thu Mar 27 11:48:21 2008][12854] no404.nasl depends on webmirror.nasl which could not be found ... [Thu Mar 27 11:48:21 2008][12854] invision_power_board_calendar_sql_injection.nasl depends on invision_power_board_detect.nasl which could not be found [Thu Mar 27 11:48:21 2008][12854] user evazquez starts a new scan. Target(s) : 172.16.8.241, with max_hosts = 20 and max_checks = 4 [Thu Mar 27 11:48:21 2008][12854] user evazquez : testing 172.16.8.241 (172.16.8.241) [12855] [Thu Mar 27 11:48:29 2008][12855] SIGSEGV occured ! [Thu Mar 27 11:48:29 2008][12854] user evazquez : test complete except for the SIGSEGV I have the same. Very odd - any ideas on cause? More data I can provide for troubleshooting? I'd like to know more about the SIGSEGV. You don't have any lines like [Thu Mar 27 22:36:18 2008][16493] user jan : launching find_service.nes against localhost [16513] ? (I.e. does SIGSEGV occur for any single test?) Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner ___ Openvas-discuss mailing list Openvas-discuss@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
Re: [Openvas-discuss] planning release openvas-libraries 1.0.1
Here's the snippet from config.log on the OpenBSD system: configure:8115: result: /usr/bin/install -c configure:8133: checking for __dn_expand in -lresolv configure:8168: gcc -pipe -o conftest -g -O2 conftest.c -lresolv 5 /usr/bin/ld: cannot find -lresolv collect2: ld returned 1 exit status configure:8174: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME | #define PACKAGE_TARNAME | #define PACKAGE_VERSION | #define PACKAGE_STRING | #define PACKAGE_BUGREPORT | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | /* end confdefs.h. */ | | /* Override any GCC internal prototype to avoid an error. |Use char because int might match the return type of a GCC |builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern C | #endif | char __dn_expand (); | int | main () | { | return __dn_expand (); | ; | return 0; | } configure:8192: result: no configure:8197: error: you need to install resolve library with development files -- Ed Vazquez 2008-03-27 16:12 Murphy's Computer Law 33: A program generator creates programes that are more buggy than the program generator. -Original Message- From: [EMAIL PROTECTED] [mailto:openvas- [EMAIL PROTECTED] On Behalf Of Jan-Oliver Wagner Sent: Thursday, March 27, 2008 16:03 To: openvas-discuss@wald.intevation.org Subject: Re: [Openvas-discuss] planning release openvas-libraries 1.0.1 Hi Ed, On Thursday 27 March 2008 16:18, Vazquez, Ed wrote: Now that OpenVAS is working on my Gentoo box, I thought I'd give it a go on the OpenBSD 4.2 (stable) box. I do not have a OpenBSD box here for testing. Can you send the respective part of config.log? In fact, I'd welcome some OpenBSD guys to help on this. Else, perhaps searching for configure.in files of other software products that successfuly configure on OpenBSD might show a solution ... Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner ___ Openvas-discuss mailing list Openvas-discuss@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss smime.p7s Description: S/MIME cryptographic signature ___ Openvas-discuss mailing list Openvas-discuss@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss