Got it working (sort of)! This is what I get from getting "too familiar" with variant recipes. I'd been using several prior recipes that put the gsad web support on port 9392. Forgot the exact port, but was looking for it up there, so figured it to be the 9393 from the command line - and that's where the GnuTLS library was getting into error. Obviously I was starting to connect to the wrong component (which nonetheless presented an encyrption cert the browser, which of course I should have spotted was wrong for --http-only anyhow). Port 80, okay it's there. Whew. Sorry for being dumb.
The "(sort of)" is because the resulting scanner, when running its default "Full and Fast" scan against the same port range I'd been testing with the Fedora installs (16, which segfaulted, and 15, which looked much better) still comes up without finding any of the open ports except for the on NTP port on the one system (which happens to be the ISP's router). Now, I see in this instance the newer VM doesn't have nmap on it (the others did), so I'll try installing that and see if it adds capability ... nope. OpenVAS is still blind. While the target /27 is the same, this latest instance is in an entirely different location - a small cloud provider, while the prior attempts were on one of my own networks (a separate one from the /27 scanned). When you run scans your scans do your scans find the obvious stuff, the things that nmap can see right away? Is the "Full and fast" scan profile as distributed not really ready for use? Am I expecting too much that it should show off an ability to find the obvious stuff? There's nothing weird about the /27 I'm scanning. I'm responsible for whatever defenses are there, and there's not any tripwire to stealth it from scans. I've run Nessus against it, and everything's obvious, just as to nmap - but not OpenVAS yet. Thanks again, Whit _______________________________________________ Openvas-discuss mailing list [email protected] http://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
