caker wrote:
PaulC wrote:
Any reason for picking http (80)? wouldn't ident (113) be a better choice?
I don't think it matters -- it's not making a complete TCP connection, only looking for a response. I would think 113 would be more alarming to admins/users, as it's commonly associated with IRC etc.
True. Just so long as apache doesn't get a regular jab in the ribs

caker wrote:
PaulC wrote:
what value are you using for --scan_delay?
The default (zero?). With the fixes I've made (only one host will now monitor), I don't think there's any performance reason to increase the delay.
Thanks for doing that, it should definitely help. If you'll indulge another suggestion, perhaps '-T Polite' would be a good option to include? If I understand the
nmap man page correctly, the default is "as quickly as possible without overĀloading the network or missing hosts/ports". I'm no nmap expert, but I thought it's somewhat adaptive in setting timeouts depending on the responsiveness of the system it is probing, so 'as quickly as possible' may not be desirable.
caker wrote:
PaulC wrote:
I found your last comment puzzling. The UML networking fails if there isn't regular network activity?
Ahh, that's my scare tactic to keep people from filtering my monitoring. A response from your IP is required or the monitoring will mark your IP down. If the other assertions fail (pid, process, etc) it will mark your Linode down, but under normal circumstances you won't have any problems.
Strange, I don't know why someone would intentionally prevent their service provider from monitoring that they're actually providing the service

I was only puzzled because the IP addresses sourcing the traffic were so different from my local IP address (though I should've just done a reverse-DNS lookup, as you suggested).
Could this sort of info be captured in a 'Configuring your Linode' page somewhere? This forum is still small enough to sift through to find the nuggets, but that won't last forever
Paul