[Linaro-validation] time to move away from conmux?

[William Mills]

On 05/18/2012 09:26 AM, Paul Larson wrote:
>
> On Fri, May 18, 2012 at 4:50 AM, Dave Pigott <dave.pigott at linaro.org
> <mailto:dave.pigott at linaro.org>> wrote:
>
>     On 18 May 2012, at 10:47, Alexander Sack wrote:
>
>      > On Fri, May 18, 2012 at 9:32 AM, Zygmunt Krynicki
>      > <zygmunt.krynicki at linaro.org
>     <mailto:zygmunt.krynicki at linaro.org>> wrote:
>      >> W dniu 18.05.2012 09:29, Dave Pigott pisze:
>      >>
>      >>> On 18 May 2012, at 01:20, Michael Hudson-Doyle wrote:
>      >>>
>      >>>> Hi,
>      >>>>
>      >>>> After the last few days of poking at things, I think it's time to
>      >>>> finally move fully away from conmux to a connection_command /
>      >>>> hard_reset_command based approach.
>      >>>>
>      >>>> I think the actual config file mangling can be done with a
>     short shell
>      >>>> script. Although lava-core will fix this properly, I can spend
>     a quick
>      >>>> 10 minutes hacking up lava console and lava powerstab commands
>     to get
>      >>>> around the loss of easy conmux-console based command lines.
>      >>>
>      >>>
>      >>> I agrees, however the one thing I will miss is being able to go
>     into
>      >>> conmux and do "~$hardreset" to reboot a board. What would be
>     nice is if we
>      >>> built a small tool set that allowed us to get the boards serial
>     port and PDU
>      >>> details by name, connect to the board and reboot the board.
>      >>
>      >>
>      >> Let's make sure we can call: $ lava-dev device reset beagle01
>      >
>      > Also, in the light of "flashing to sd mux" (which needs board powered
>      > off) commands for "poweroff" and "poweron" would be awesome I guess
>      > :).
>
>     +1
>
> If you haven't already, you should take a look at the existing script
> that conmux calls to do this. It doesn't currently support off/on, but
> the PDU does support those - it's just a different function on the menu
> that it would need to pick. Should be pretty straightforward to add.
>

If your going to rev this functionality anyway, any thought about using 
snmp access to the APC instead of the menu script that it appears to 
currently use?  The snmp seems a lot more automation friendly.

In our lab we use:
         PORT=1 # 1 to 8
         STATUS=1 # 1 for on, 2 for off, 3 for reboot
         RWPASSWD=private
         ROPASSWD=public
         IPADDR=10.218.114.11
         snmpset -c $RWPASSWD -v1 $IPADDR 
enterprises.318.1.1.4.4.2.1.3.$PORT i $STATUS
         snmpget -c $ROPASSWD -v1 $IPADDR 
enterprises.318.1.1.4.4.2.1.3.$PORT

snmp is not encypted like SSH would be.  I don't know if you care or 
not.  Should not be a real issue for us but we plan to use VPNs anyway 
to isolate the APCs.  Of course you should change the RW & RO passwd's 
on the device.

BTW: Hi.  short time listner, first time caller.