TASdvlper has asked for the wisdom of the Perl Monks concerning the following question:

All,

I am a test engineer that is currently designing a automation system. Basically, the thought is the master server will run tests on multiple remote systems and gather return codes, messages, etc. So, there are 3 solutions I am looking at (but not limited too): rsh, telnet/expect (using the Telnet/Expect modules) or client/server (usiing IO::Socket) app.

I was wondering if anybody had experience with the above and has suggestions/recommendations on what is the best approach ? I just started my research and they all seems to have some pros/cons.

One gotcha I need to keep in mind, is that our remote systems, that run tests, could be a variety of different OS's (Windows, Solaris, NetBSD just to name some).

Any feedback on this would be greatly appreciated. Thx

update (broquaint): title change (was Testing on remote systems: what is the most robust (logical approach): rsh, telnet/expect or client/server app (or others ?))

  • Comment on Pros/cons of testing on remote systems?

Replies are listed 'Best First'.
Re: Pros/cons of testing on remote systems?
by jreades (Friar) on Oct 27, 2003 at 14:42 UTC

    Well what are you testing for?

    The correct testing framework will depend on what the behaviour of the remote system is supposed to be. For instance:

    • If the remote host is a Web server, my ability to telnet to it is irrelevant. The host's ability to respond to a request on port 80 is, however, most relevant.
    • If the remote host is running a service (say, LDAP) then presumably I would want to test that particular funcationality by either testing the actual function itself (preferrable) or checking to see that it is at least running (acceptable).

    A little more detail would help a great deal.

    Also, applications like NetSaint may well already do a great deal of what you want to test.

[reply]
      ooops. didn't mean to add urls. ahhh ... Sorry for the lack of information. Basically, the remote system will most likely run scripts that we have generated, 3rd party scripts, unit tests (for developers), etc, really no limits. Basically, the master server will have what we call a "agenda" to run on a remote system (which is basically just a list of scripts to call - some in serial, some in parallel) and the master server will for a child for each unique call to a remote system. To break it down more: The master server may want to do this (very simple example). Agenda has 1 elemen. run: "perl /test/dvlp/mytestscript.pl <input 1> <input 2>" on remote system: 111.22.33.44 and get back the return code and any output (if available). I'm looking now if we can get back return codes from using the Telnet module ... no luck yet.
[reply]
Re: Pros/cons of testing on remote systems?
by hardburn (Abbot) on Oct 27, 2003 at 15:44 UTC

    Don't bother with rsh anymore. Use ssh instead. Or, if you don't really care about encrypted connections, go with telnet/expect. In either case, there is no good reason to use rsh anymore, excepting the always-annoying PHB factor.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    :(){ :|:&};:

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]
      Use ssh instead. Or, if you don't really care about encrypted connections, go with telnet/expect.

      I agree that using ssh is best. In fact, I'd suggest using it unless it failed to meet some requirements such as performance or portability rather than merely "if you don't really care". But I don't agree with using telnet/expect rather than rsh.

      there is no good reason to use rsh anymore, excepting the always-annoying PHB factor.

      I'll give you three:

      1. Rsh may well be more convenient than trying to use expect which is notoriously messy.
      2. Rsh won't require you to store a readable password somewhere.
      3. If you ever decide you do want to use ssh in the future, it'll be a drop-in replacement for rsh.
      And if I sound like a PHB saying so, well, so be it. ;-) 

      -sauoq
"My two cents aren't worth a dime.";
[reply]
        Thanks for your feedback. Why would you recommend using ssh rather than telnet ? From reading CPAN telnet seems to give you a lot of functionality that may come in handy.
[reply]
      yeah, I'm seeing that rsh is sort of a pain. I'm actually looking at the Telnet module which seems to be the best utility for my needs. But, what I'm trying to figure out is a way to capture the return code from a script that Telnet executed. Not sure if this is even possible or not ...
[reply]

        This might be overkill, but you could try creating a SOAP::Lite application. I wrote an article on securing SOAP applications a while back (here) which should get you started.

        ----
        I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
        -- Schemer

        :(){ :|:&};:

        Note: All code is untested, unless otherwise stated

[reply]
[d/l]

Back to Seekers of Perl Wisdom