|Problems? Is your data what you think it is?|
Re^4: making NET:SSH quietby DeadPoet (Scribe)
|on Jan 12, 2011 at 18:10 UTC||Need Help??|
You defeat the purpose of automation. A simple upgrade to SSH on UNIX and all your automation is no longer automated until known_host entries are cleared.
Use the option, don't use the option, it is the implementer's choice and an understanding of their environment. To your point, which I agree with if you are implying "sparingly", this option should not be used to just be used, it should have a purpose--such as the case for automation. If you do not care about failed connections or are going to write some type of exception process, then yes you do not need it. But to just silently fail, such as with the '-q', why did it fail? Was it a true connection issue? Was it a bad command? Was it just the known_host file? Who knows!
Moreover, before attempting a connection I would check for host availability, which I talked about. So, what would I know using this process?
* Server is available.
* SecureShell is available.
* If the command fails then it is probably on the target side.
Okay, now one is probably going to say well what about firewalls and port blockage? Well, as part of the preliminary checks, which includes ping, I would also check if the port is available one manner, and not the only way, is to use IO::Socket::INET. For example:
It all just depends on what one needs and wants to accomplish. If one is going to account for issues with some type of exception process, then you got it. If the script is going to be left unattended, then you probably need it.--Poet