Talk to lights-out adapters

313 views
Skip to first unread message

Frits Hoogland

unread,
Aug 30, 2014, 7:44:20 AM8/30/14
to ansible...@googlegroups.com
I am trying to create a playbook to make lights-out adapters report issues. The lights-out adapter type I have to talk to is sun/oracle ilom. But if this can be made to work, it would probably be usable for any lights-out adapter that is using ssh.

My current playbook looks like this:

---
- hosts: iloms
remote_user: root
gather_facts: false
tasks:

-name: run show faulty command
raw: show faulty
register: showfaulty

Upon running this playbook, I get this in my stdout:

shell: Invalid credentials\n\n\n

It appears that despite ansible is executing "raw commands", it first tries to set a shell, which is non-existent on an ilom adapter, because it has a fixed limited shell which works totally different.

Is there some way to truly issue raw commands? This would open up Ansible usage to a lot of devices that are talking ssh.

Thanks!

Henry Finucane

unread,
Aug 30, 2014, 1:35:55 PM8/30/14
to ansible...@googlegroups.com
On Sat, Aug 30, 2014 at 4:44 AM, Frits Hoogland
<frits.h...@gmail.com> wrote:
> It appears that despite ansible is executing "raw commands", it first tries to set a shell, which is non-existent on an ilom adapter, because it has a fixed limited shell which works totally different.
>
> Is there some way to truly issue raw commands? This would open up Ansible usage to a lot of devices that are talking ssh.

Ask, and ye shall receive: http://docs.ansible.com/raw_module.html


--
-----------------------
| Henry Finucane
| "I hear aphorisms are popular"
-----------------------

Frits Hoogland

unread,
Aug 30, 2014, 1:40:16 PM8/30/14
to ansible...@googlegroups.com
Of course i've looked into the documentation. It might be me, but I couldn't make the error go away.

Henry Finucane

unread,
Aug 30, 2014, 2:27:39 PM8/30/14
to ansible...@googlegroups.com
Sorry, I probably should drink more coffee before talking in public.
As a control, if you do

ssh root@iloms "show faulty"

If it doesn't, does this work?

echo 'show faulty' | ssh root@iloms

It might be interesting to see -vvvv output, as well.

On Sat, Aug 30, 2014 at 10:40 AM, Frits Hoogland
<frits.h...@gmail.com> wrote:
> Of course i've looked into the documentation. It might be me, but I couldn't make the error go away.
>
> --
> You received this message because you are subscribed to the Google Groups "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/f0105e4f-8416-4e5e-8b3f-670a210f7543%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Frits Hoogland

unread,
Aug 31, 2014, 5:19:03 AM8/31/14
to ansible...@googlegroups.com
indeed, that doesn't work:

[ansible@ansiblevm ansible]$ ssh root@enkdb01-ilom "show faulty"
Password:
shell: Invalid credentials

this however, does work:

[ansible@ansiblevm ansible]$ echo "show faulty" | ssh root@enkdb01-ilom
Pseudo-terminal will not be allocated because stdin is not a terminal.
Password:

Oracle(R) Integrated Lights Out Manager

Version 3.0.16.15.e r87097

Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.

-> show faulty
Target              | Property               | Value
--------------------+------------------------+---------------------------------

-> Session closed 

This is ssh -vvvv root@enkdb01-ilom "show faulty":

[ansible@ansiblevm ansible]$ ssh -vvvv root@enkdb01-ilom "show faulty"
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to enkdb01-ilom [192.168.8.206] port 22.
debug1: Connection established.
debug1: identity file /home/ansible/.ssh/identity type -1
debug1: identity file /home/ansible/.ssh/identity-cert type -1
debug3: Not a RSA1 key file /home/ansible/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/ansible/.ssh/id_rsa type 1
debug1: identity file /home/ansible/.ssh/id_rsa-cert type -1
debug1: identity file /home/ansible/.ssh/id_dsa type -1
debug1: identity file /home/ansible/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug3: Wrote 960 bytes for a total of 981
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijnda...@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijnda...@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijnda...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijnda...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com
debug2: kex_parse_kexinit: none,zl...@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug3: Wrote 24 bytes for a total of 1005
debug2: dh_gen_key: priv key bits set: 129/256
debug2: bits set: 525/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: Wrote 144 bytes for a total of 1149
debug3: check_host_in_hostfile: host enkdb01-ilom filename /home/ansible/.ssh/known_hosts
debug3: check_host_in_hostfile: host enkdb01-ilom filename /home/ansible/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 6
debug3: check_host_in_hostfile: host 192.168.8.206 filename /home/ansible/.ssh/known_hosts
debug3: check_host_in_hostfile: host 192.168.8.206 filename /home/ansible/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 8
debug1: Host 'enkdb01-ilom' is known and matches the RSA host key.
debug1: Found key in /home/ansible/.ssh/known_hosts:6
debug2: bits set: 505/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: Wrote 16 bytes for a total of 1165
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug3: Wrote 48 bytes for a total of 1213
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/ansible/.ssh/identity ((nil))
debug2: key: /home/ansible/.ssh/id_rsa (0x7f4fa7d33f10)
debug2: key: /home/ansible/.ssh/id_dsa ((nil))
debug3: Wrote 64 bytes for a total of 1277
debug1: Authentications that can continue: publickey,keyboard-interactive
debug3: start over, passed a different list publickey,keyboard-interactive
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ansible/.ssh/identity
debug3: no such identity: /home/ansible/.ssh/identity
debug1: Offering public key: /home/ansible/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1645
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/ansible/.ssh/id_dsa
debug3: no such identity: /home/ansible/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: Wrote 96 bytes for a total of 1741
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64)
debug3: Wrote 80 bytes for a total of 1821
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)
debug3: Wrote 80 bytes for a total of 1901
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-...@openssh.com
debug1: Entering interactive session.
debug3: Wrote 128 bytes for a total of 2029
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug3: Ignored env HOSTNAME
debug3: Ignored env SELINUX_ROLE_REQUESTED
debug3: Ignored env ANSIBLE_SSH_ARGS
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env HISTSIZE
debug3: Ignored env SSH_CLIENT
debug3: Ignored env SELINUX_USE_CURRENT_RANGE
debug3: Ignored env QTDIR
debug3: Ignored env OLDPWD
debug3: Ignored env QTINC
debug3: Ignored env SSH_TTY
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env SELINUX_LEVEL_REQUESTED
debug3: Ignored env HISTCONTROL
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env QTLIB
debug3: Ignored env CVS_RSH
debug3: Ignored env SSH_CONNECTION
debug3: Ignored env LESSOPEN
debug3: Ignored env G_BROKEN_FILENAMES
debug3: Ignored env _
debug1: Sending command: show faulty
debug2: channel 0: request exec confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: Wrote 128 bytes for a total of 2157
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
shell: Invalid credentials


debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype e...@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

debug3: channel 0: close_fds r -1 w -1 e 6 c -1
debug3: Wrote 32 bytes for a total of 2189
debug3: Wrote 64 bytes for a total of 2253
Transferred: sent 2040, received 1912 bytes, in 0.5 seconds
Bytes per second: sent 3861.5, received 3619.3
debug1: Exit status 0

And this is echo "show fault" | ssh -vvvv root@enkdb01-ilom:

[ansible@ansiblevm ansible]$ echo "show faulty" | ssh -vvvv root@enkdb01-ilom
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to enkdb01-ilom [192.168.8.206] port 22.
debug1: Connection established.
debug1: identity file /home/ansible/.ssh/identity type -1
debug1: identity file /home/ansible/.ssh/identity-cert type -1
debug3: Not a RSA1 key file /home/ansible/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/ansible/.ssh/id_rsa type 1
debug1: identity file /home/ansible/.ssh/id_rsa-cert type -1
debug1: identity file /home/ansible/.ssh/id_dsa type -1
debug1: identity file /home/ansible/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug3: Wrote 960 bytes for a total of 981
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijnda...@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijnda...@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijnda...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijnda...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com
debug2: kex_parse_kexinit: none,zl...@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug3: Wrote 24 bytes for a total of 1005
debug2: dh_gen_key: priv key bits set: 119/256
debug2: bits set: 503/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: Wrote 144 bytes for a total of 1149
debug3: check_host_in_hostfile: host enkdb01-ilom filename /home/ansible/.ssh/known_hosts
debug3: check_host_in_hostfile: host enkdb01-ilom filename /home/ansible/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 6
debug3: check_host_in_hostfile: host 192.168.8.206 filename /home/ansible/.ssh/known_hosts
debug3: check_host_in_hostfile: host 192.168.8.206 filename /home/ansible/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 8
debug1: Host 'enkdb01-ilom' is known and matches the RSA host key.
debug1: Found key in /home/ansible/.ssh/known_hosts:6
debug2: bits set: 499/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: Wrote 16 bytes for a total of 1165
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug3: Wrote 48 bytes for a total of 1213
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/ansible/.ssh/identity ((nil))
debug2: key: /home/ansible/.ssh/id_rsa (0x7fa50b3cff10)
debug2: key: /home/ansible/.ssh/id_dsa ((nil))
debug3: Wrote 64 bytes for a total of 1277
debug1: Authentications that can continue: publickey,keyboard-interactive
debug3: start over, passed a different list publickey,keyboard-interactive
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ansible/.ssh/identity
debug3: no such identity: /home/ansible/.ssh/identity
debug1: Offering public key: /home/ansible/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1645
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/ansible/.ssh/id_dsa
debug3: no such identity: /home/ansible/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: Wrote 96 bytes for a total of 1741
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64)
debug3: Wrote 80 bytes for a total of 1821
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)
debug3: Wrote 80 bytes for a total of 1901
debug1: Authentication succeeded (keyboard-interactive).
debug2: fd 4 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-...@openssh.com
debug1: Entering interactive session.
debug3: Wrote 128 bytes for a total of 2029
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug3: Ignored env HOSTNAME
debug3: Ignored env SELINUX_ROLE_REQUESTED
debug3: Ignored env ANSIBLE_SSH_ARGS
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env HISTSIZE
debug3: Ignored env SSH_CLIENT
debug3: Ignored env SELINUX_USE_CURRENT_RANGE
debug3: Ignored env QTDIR
debug3: Ignored env OLDPWD
debug3: Ignored env QTINC
debug3: Ignored env SSH_TTY
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env SELINUX_LEVEL_REQUESTED
debug3: Ignored env HISTCONTROL
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env QTLIB
debug3: Ignored env CVS_RSH
debug3: Ignored env SSH_CONNECTION
debug3: Ignored env LESSOPEN
debug3: Ignored env G_BROKEN_FILENAMES
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: Wrote 112 bytes for a total of 2141
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
debug2: channel 0: read<=0 rfd 4 len 0
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug3: Wrote 48 bytes for a total of 2189
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
debug3: Wrote 32 bytes for a total of 2221

Oracle(R) Integrated Lights Out Manager

Version 3.0.16.15.e r87097

Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.

-> sdebug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug1: channel 0: forcing write
how faulty
Target              | Property               | Value
--------------------+------------------------+---------------------------------

-> Session closed
debug3: channel 0: will not send data after close
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

debug3: channel 0: close_fds r -1 w -1 e 6 c -1
debug3: Wrote 32 bytes for a total of 2253
debug3: Wrote 64 bytes for a total of 2317
debug1: fd 0 clearing O_NONBLOCK
Transferred: sent 2072, received 2696 bytes, in 0.8 seconds
Bytes per second: sent 2565.8, received 3338.6
debug1: Exit status 0

Oh, to make the information more complete, the ansible host is Oracle Linux 6u5 x86_64, updated to the newest public available packages. The EPEL repo is added, and ansible is installed from there. This means ansible is version 1.6.6. 
 

Frits Hoogland

unread,
Aug 31, 2014, 7:40:01 AM8/31/14
to ansible...@googlegroups.com
Searching and researching this topic, it seems that this issue has been raised on several places. Still, I haven't seen a resolution yet.

It seems that this problem arises whenever you try to make Ansible talk to a machine that has it's own shell behind ssh. It's my personal opinion that Ansible would become more valuable if you can make it talk to these kind of devices, like cisco routers and ILO cards, for change orchestration.

Frits Hoogland

unread,
Sep 3, 2014, 7:41:40 AM9/3/14
to ansible...@googlegroups.com
Anyone else interested in looking into this issue? 

Michael DeHaan

unread,
Sep 3, 2014, 7:45:30 AM9/3/14
to ansible...@googlegroups.com
I don't think it's an issue so much as a feature request - though it doesn't seem like there are, given lack of response to this email thread.

I will say connections in ansible aren't meant to talk to non-computers, and in many cases, this may be something that needs to write a module to talk to them, similar to what we do with various load balancers.

There was a recent thread about HP switches and not really having a shell when you login that's the same kind of thing.

Most folks are using ILO's for basic power management via fence and haven't automated a lot more.

Anyway, a module is probably appropriate, though we are probably unlikely to include it in core if the goal is to simulate a monitoring system.








On Wed, Sep 3, 2014 at 7:41 AM, Frits Hoogland <frits.h...@gmail.com> wrote:
Anyone else interested in looking into this issue? 

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

Frits Hoogland

unread,
Sep 3, 2014, 7:57:47 AM9/3/14
to ansible...@googlegroups.com
I am actually quite surprised by the lack of response.

When using Ansible for implementing changes across systems, I can't help to think you want to talk to network devices and alter rules? Also, when doing operating system and hardware updates, you want to talk to the BMC, for which the ssh port is the most reliable way!

I've gone through researching, and actually this seems to be a question/feature request that pops up reasonably frequently at different places.

When seen as a feature request, it would be to implement a mode in the raw module, which makes raw to just log on, and issues a command and reads the output, instead of requesting a shell. mode=shell or plain. 

In my opinion adding a raw plain mode would open up access to a lot of devices which are inherently unreachable by other orchestration engines because they require an agent. The magic is in the fact that you can issue any command to the device, instead of writing a module specifically for a specific device. 

Cheers,

Frits

Michael DeHaan

unread,
Sep 3, 2014, 8:47:06 AM9/3/14
to ansible...@googlegroups.com
On Wed, Sep 3, 2014 at 7:57 AM, Frits Hoogland <frits.h...@gmail.com> wrote:
I am actually quite surprised by the lack of response.

When using Ansible for implementing changes across systems, I can't help to think you want to talk to network devices and alter rules? Also, when doing operating system and hardware updates, you want to talk to the BMC, for which the ssh port is the most reliable way!

 

I've gone through researching, and actually this seems to be a question/feature request that pops up reasonably frequently at different places.

When seen as a feature request, it would be to implement a mode in the raw module, which makes raw to just log on, and issues a command and reads the output, instead of requesting a shell. mode=shell or plain. 


I'm open to this.


 

In my opinion adding a raw plain mode would open up access to a lot of devices which are inherently unreachable by other orchestration engines because they require an agent. The magic is in the fact that you can issue any command to the device, instead of writing a module specifically for a specific device. 

Cheers,

Frits


On Wednesday, September 3, 2014 1:45:30 PM UTC+2, Michael DeHaan wrote:
I don't think it's an issue so much as a feature request - though it doesn't seem like there are, given lack of response to this email thread.

I will say connections in ansible aren't meant to talk to non-computers, and in many cases, this may be something that needs to write a module to talk to them, similar to what we do with various load balancers.

There was a recent thread about HP switches and not really having a shell when you login that's the same kind of thing.

Most folks are using ILO's for basic power management via fence and haven't automated a lot more.

Anyway, a module is probably appropriate, though we are probably unlikely to include it in core if the goal is to simulate a monitoring system.








On Wed, Sep 3, 2014 at 7:41 AM, Frits Hoogland <frits.h...@gmail.com> wrote:
Anyone else interested in looking into this issue? 

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

Frits Hoogland

unread,
Sep 4, 2014, 6:52:08 AM9/4/14
to ansible...@googlegroups.com
Is there anything I can do to make the the plain feature be introduced?
Sadly I am not python savvy enough to create this.

Cheers,

Frits

Michael DeHaan

unread,
Sep 4, 2014, 7:47:25 AM9/4/14
to ansible...@googlegroups.com
Filing a ticket about it on github would be good regardless.

We'll likely have to incorporate it into the action plugin source for raw, which I don't think will be especially difficult, though I will say it may be some time before this happens due to other things in the queue.

If others would like to attempt this, I'm suggesting something like:

raw: /usr/bin/foo asdf bar shell=false

And the code would have to parse off the free-form argument "shell=" if present, before sending the command.  


Reply all
Reply to author
Forward
0 new messages