From agialluc@redhat.com Wed Sep 3 15:11:40 2014 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by underdog.stansell.org (8.14.9/8.14.9) with ESMTP id s83FBbF5007066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 3 Sep 2014 15:11:39 GMT Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s83FBa5n000540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 3 Sep 2014 11:11:37 -0400 Received: from agialluc.f20 (wlan-196-102.bos.redhat.com [10.16.196.102]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s83FBZ5G020997 for ; Wed, 3 Sep 2014 11:11:36 -0400 Message-ID: <54072FA7.2010806@redhat.com> Date: Wed, 03 Sep 2014 11:11:35 -0400 From: Anthony Gialluca Reply-To: agialluc@redhat.com Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: users@conserver.com Subject: SEGV in conserver ver 8.1.20 Content-Type: multipart/alternative; boundary="------------020302080803020700090702" X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Spam-Score: -3.141 () BAYES_00,HTML_MESSAGE,RP_MATCHES_RCVD X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 15:11:40 -0000 This is a multi-part message in MIME format. --------------020302080803020700090702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello fellow conserver users, I wanted to reach out to everone in reference to an issue that I've been having with conserver ver 8.1.20. I am hoping you may see something I'm doing wrong or, hopefully, you could provide some advice or recommendations. I've been trying to use a 'task' but I keep getting SEGV core dumps. The following is long and I apologize, but wanted you to get the necessary information. I've configured conserver.cf in this manner (please note I've truncated it to the relevant parts, passwords and hostnames have been changed): --- cut here ---- task a { cmd "/usr/bin/ipmitool -I lanplus -H Q -U root -P XXXYYY chassis power on"; confirm yes; description "Power On"; subst Q=hs; } task b { cmd "/usr/bin/ipmitool -I lanplus -H Q -U root -P XXXYYY chassis power off"; confirm yes; description "Power Off"; subst Q=hs; } task c { cmd "/usr/bin/ipmitool -I lanplus -H Q -U root -P XXXYYY chassis power reset"; confirm yes; description "Power Reset"; subst Q=hs; } task d { cmd "/usr/bin/ipmitool -I lanplus -H Q -U root -P XXXYYY chassis power status"; confirm no; description "Power Status"; subst Q=hs; } default dell-ipmi-default-PW { type exec; exec "/usr/bin/ipmitool -I lanplus -H Q -U root -P XXXYYY sol deactivate && echo 'Disconnected' ;ulimit -v 31720 ; /usr/bin/ipmitool -I lanplus -H Q -U root -P XXXYYY sol activate"; execsubst Q=hs; tasklist a,b,c,d; } default * { include global; master conserver.com; } console system01.com { include dell-ipmi-default-PW; system01.com; } --- cut here ---- I can connect via 'console' command to system01.com. I can see the list of tasks correctly via ^EC!? as in: $ console -lroot system01.com Enter root@conserver.com's password: [Enter `^Ec?' for help] Red Hat Enterprise Linux Server release 6.5 (Santiago) Kernel 2.6.32-431.el6.x86_64 on an x86_64 system01.com login: ^EC!? [task list] a - `Power On' b - `Power Off' c - `Power Reset' d - `Power Status' Red Hat Enterprise Linux Server release 6.5 (Santiago) Kernel 2.6.32-431.el6.x86_64 on an x86_64 system01.com login: However every attempt to execute a task results in a disconnect. On the server side the conserverd that is to run the task is exiting on an 'invalid pointer' as in: *** glibc detected *** /usr/sbin/conserver: free(): invalid pointer: 0x00007fffa79b9f10 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3351476166] /usr/sbin/conserver[0x421bee] /usr/sbin/conserver[0x40ba74] /usr/sbin/conserver[0x40d993] /usr/sbin/conserver[0x410131] /usr/sbin/conserver[0x411079] /usr/sbin/conserver[0x413b9f] /lib64/libc.so.6(__libc_start_main+0xfd)[0x335141ed1d] /usr/sbin/conserver[0x403d19] ======= Memory map: ======== 00400000-00436000 r-xp 00000000 fd:01 926441 /usr/sbin/conserver > Large Memory Map outputs here< I tried setting up a command shell to eliminate the possibility that ipmitool put output to stdout was the problem. All the task was to do was to echo "PING" to a file. ---- cut here ----- #!/bin/bash echo "PING" 2>&1 > /tmp/OUTPUT ---- cut here ----- Modified the task 'c' in /etc/conserver.cf to: cmd "/tmp/run.sh Q"; But still got the SEGV even with this trivial task. By recompiling the source with added debug statements I've tracked down the SEGV to FallBack() and/or GetPseudoTTY(). This is as far as I can track it. Thanks in Advance, -Tony -- --------------------------------------------------------------- Anthony Gialluca email: agialluc@redhat.com Westford Seat: 1E221 --------------020302080803020700090702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello fellow conserver users,

I wanted to reach out to everone in reference to an
issue that I've been having with conserver ver 8.1.20.

I am hoping you may see something I'm doing wrong or,
hopefully, you could provide some advice or recommendations.

I've been trying to use a 'task' but I keep getting
SEGV core dumps.  The following is long and I apologize,
but wanted you to get the necessary information.

I've configured conserver.cf in this manner (please note I've
truncated it to the relevant parts, passwords and hostnames
have been changed):

--- cut here ----
task a {
    cmd "/usr/bin/ipmitool -I lanplus -H Q -U root -P XXXYYY chassis power on";
    confirm yes;
    description "Power On";
    subst Q=hs;
}
task b {
    cmd "/usr/bin/ipmitool -I lanplus -H Q -U root -P XXXYYY chassis power off";
    confirm yes;
    description "Power Off";
    subst Q=hs;
}
task c {
    cmd "/usr/bin/ipmitool -I lanplus -H Q -U root -P XXXYYY chassis power reset";
    confirm yes;
    description "Power Reset";
    subst Q=hs;
}
task d {
    cmd "/usr/bin/ipmitool -I lanplus -H Q -U root -P XXXYYY chassis power status";
    confirm no;
    description "Power Status";
    subst Q=hs;
}
default dell-ipmi-default-PW {
    type exec;
    exec "/usr/bin/ipmitool -I lanplus -H Q -U root -P XXXYYY sol deactivate && echo 'Disconnected' ;ulimit -v 31720 ; /usr/bin/ipmitool -I lanplus -H Q -U root -P XXXYYY sol activate";
    execsubst Q=hs;
    tasklist a,b,c,d;
}
default * { include global; master conserver.com; }

console system01.com { include dell-ipmi-default-PW; system01.com; }
--- cut here ----

I can connect via 'console' command to system01.com.
I can see the list of tasks correctly via ^EC!? as in:

$ console -lroot system01.com
Enter root@conserver.com's password:
[Enter `^Ec?' for help]
Red Hat Enterprise Linux Server release 6.5 (Santiago)
Kernel 2.6.32-431.el6.x86_64 on an x86_64

system01.com login:
^EC!?
[task list]
 a - `Power On'
 b - `Power Off'
 c - `Power Reset'
 d - `Power Status'
 
Red Hat Enterprise Linux Server release 6.5 (Santiago)
Kernel 2.6.32-431.el6.x86_64 on an x86_64

system01.com login:
However every attempt to execute a task results in a disconnect.

On the server side the conserverd that is to run the task is exiting on an 'invalid pointer' as in:

*** glibc detected *** /usr/sbin/conserver: free(): invalid pointer: 0x00007fffa79b9f10 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3351476166]
/usr/sbin/conserver[0x421bee]
/usr/sbin/conserver[0x40ba74]
/usr/sbin/conserver[0x40d993]
/usr/sbin/conserver[0x410131]
/usr/sbin/conserver[0x411079]
/usr/sbin/conserver[0x413b9f]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x335141ed1d]
/usr/sbin/conserver[0x403d19]
======= Memory map: ========
00400000-00436000 r-xp 00000000 fd:01 926441                             /usr/sbin/conserver
   >  Large Memory Map outputs here<


I tried setting up a command shell to eliminate the possibility that
ipmitool put output to stdout was the problem.  All the task was to
do was to echo "PING" to a file.

---- cut here -----
#!/bin/bash

echo "PING" 2>&1 > /tmp/OUTPUT
---- cut here -----

Modified the task 'c' in /etc/conserver.cf to:
    cmd "/tmp/run.sh Q";

But still got the SEGV even with this trivial task.

By recompiling the source with added debug statements I've tracked down
the SEGV to FallBack() and/or GetPseudoTTY().   This is as far as I can track it.

Thanks in Advance,
-Tony

-- 
---------------------------------------------------------------
Anthony Gialluca

email: agialluc@redhat.com
Westford Seat: 1E221
--------------020302080803020700090702-- From yoshi314@gmail.com Wed Sep 10 12:10:08 2014 Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by underdog.stansell.org (8.14.9/8.14.9) with ESMTP id s8ACA64R011908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Sep 2014 12:10:08 GMT Received: by mail-qa0-f46.google.com with SMTP id k15so206891qaq.5 for ; Wed, 10 Sep 2014 05:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tPfljpPDpxWgvbpeq9ZnUQMSSwE4gcLECaRewnvHgZM=; b=HUhwdB8GWv/t92xlKGA5zwj2wKb+AhcGT6jLxNhTmoVmGUWdDTaPHY9flrKPoHgWH5 qgPzBQduTQgHDFHpchA+R03ETpOSM5D+T3SmvqEyc+GQjL7cmbCmtSP2IsBiMxzg5Ro9 I3aUysnIXhQLNbYSaLWLOma8yfqwDks143jPJgnYDMF/PRAXAhJplT2wKJmvUEXI7Q9o Xld2hsWnZCPNotYcySclVMtEhDaGkabLkfplzicxQ3CP//OZjLFRK57uTsZqm2r/7LQp xWXV7VYBOtOFne+6CeQUSxdl78MeXGsrIJFfZ6HPbgOQTFtfv+MAdsClVyksclNjiy1n zS5Q== MIME-Version: 1.0 X-Received: by 10.229.140.70 with SMTP id h6mr59303094qcu.3.1410351004103; Wed, 10 Sep 2014 05:10:04 -0700 (PDT) Received: by 10.140.42.7 with HTTP; Wed, 10 Sep 2014 05:10:04 -0700 (PDT) Date: Wed, 10 Sep 2014 14:10:04 +0200 Message-ID: Subject: Strange tty behavior with multiple iLO 2.23 hosts and conserver + expect scripts on openVZ From: marcin kowalski To: users@conserver.com Content-Type: multipart/alternative; boundary=001a1132ec329bc2c80502b4ee6f X-Spam-Score: -1.238 () BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 12:10:08 -0000 --001a1132ec329bc2c80502b4ee6f Content-Type: text/plain; charset=UTF-8 Hi, all I am using the following configuration : default ilo-connection { type exec; execsubst X=hs; exec /etc/conserver/ilo-vsp.sh X; break 1; } console ilo-test { host 1.2.3.4; include ilo-connection; } (...) with expect script like so : set send_slow {1 0.02} set ilom [lindex $argv 0] spawn ssh -vv admin@$ilom expect { "Are you sure you want to continue connecting (yes/no)?" { sleep 1 ; send -s "yes\r" ; expect "admin@" { send -s "password\r" ; sleep 1 } } "admin@" { send -s "password\r" ; sleep 1 } } sleep 1 interact exit 0 Script also calls vsp command later, but it's commented out for now. The problem is that certain iLO servers fail to work correctly like this. It mostly happens with ones that identify as "iLO2 2.23" (regardless of variant in the version string, as i encountered a few of those so far) . Everything from expect script is accepted, but my commands are echoed back to me and no output is displayed. The escape string for ilo "^](" seems to be accepted (it results in ilo displaying the prompt screen again) but nothing else is. Sometimes the ssh password is accepted, but it's still echoed back to me. What i've figured out so far - Other ilo versions work correctly, - running expect script directly and making it setup a session with that ilo host also works fine, from the same openvz machine - Same configuration on non openvz host works correctly across all machines i have configured for conserver (including the ilo2 ones), although there is a diferent ssh version on it. Anyone has any useful tips on running conserver under openVZ that might help here? Does that ilo version require some special treatment, or maybe there is some ssh bug here? --001a1132ec329bc2c80502b4ee6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, all I am using the following configuration=C2=A0 :
=
default ilo-connection {
=C2=A0=C2=A0=C2=A0 type exec;
=C2=A0=C2= =A0=C2=A0 execsubst X=3Dhs;

=C2=A0=C2=A0=C2=A0 exec /etc/conserver/i= lo-vsp.sh X;

=C2=A0=C2=A0=C2=A0 break 1;

}

console ilo= -test=C2=A0 {
=C2=A0=C2=A0=C2=A0 host 1.2.3.4;
=C2=A0=C2=A0=C2=A0 inc= lude ilo-connection;
}

(...)

with expect script like so=C2= =A0 :

set send_slow {1 0.02}
set ilom [lindex $argv 0]
spawn s= sh -vv admin@$ilom
expect {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 "Are you sure you want to continue connecting (yes/no)?"
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sleep 1 ; s= end -s "yes\r" ;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expect "admin@" { s= end -s "password\r" ; sleep 1 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "admin@&q= uot;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 { send -s "password\r" ; sleep 1 }
}<= br>
sleep 1
interact
exit 0


Script also calls vsp comma= nd later, but it's commented out for now.


The problem is tha= t certain iLO servers fail to work correctly like this. It mostly happens w= ith ones that identify as "iLO2 2.23" (regardless of variant in t= he version string, as i encountered a few of those so far) .

Everyth= ing from expect script is accepted, but my commands are echoed back to me a= nd no output is displayed. The escape string for ilo "^](" seems = to be accepted (it results in ilo displaying the prompt screen again) but n= othing else is.

Sometimes the ssh password is accepted, but it's= still echoed back to me.

What i've figured out so far

- = Other ilo versions work correctly,
- running expect script directly and= making it setup a session with that ilo host also works fine, from the sam= e openvz machine
- Same configuration on non openvz host works correctly= across all machines i have configured for conserver (including the ilo2 on= es), although there is a diferent ssh version on it.

Anyone has any= useful tips on running conserver under openVZ that might help here? Does t= hat ilo version require some special treatment, or maybe there is some ssh = bug here?
--001a1132ec329bc2c80502b4ee6f-- From yoshi314@gmail.com Thu Sep 11 07:35:29 2014 Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by underdog.stansell.org (8.14.9/8.14.9) with ESMTP id s8B7ZQoD000095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Sep 2014 07:35:28 GMT Received: by mail-qc0-f171.google.com with SMTP id x3so20836332qcv.16 for ; Thu, 11 Sep 2014 00:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GwBwMS5eqLYOa+Z5pLUQaNP/qADka07FKbf/6amAHSk=; b=zob3ZsJ3funp+jw77BK8WryiBkI2MHmvu6eg0gXgmhOW1IKbI32vG42q47LgKYYdax eb//uwS2Ebt4Yc1eTsUUHHYWIl7BQp/OBoxbWH2zaJIzd/hRYXWpRtl8P7U7wZMjkdO+ HaTWZDOEhkpvG7VPXMrINtE9gsORIyhNAn5EyNn1BuvwiY65wV3gLU/YR3+0KivJFgPG YRzjwfuxa/bwWK1AC/s2cGiZmEZpNubyBSTFBMI8am7Xw13jyJG94iZ6gFxrLEXatdxc L68gcc/TPUpCjvRlfszaIVzkiCOp7jn1Kr7sPZqpajED9CVpji3Q79Fw/N/yQIwT5dKi B07Q== MIME-Version: 1.0 X-Received: by 10.224.51.197 with SMTP id e5mr66707084qag.48.1410420925588; Thu, 11 Sep 2014 00:35:25 -0700 (PDT) Received: by 10.140.42.7 with HTTP; Thu, 11 Sep 2014 00:35:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Sep 2014 09:35:25 +0200 Message-ID: Subject: Re: Strange tty behavior with multiple iLO 2.23 hosts and conserver + expect scripts on openVZ From: marcin kowalski To: users@conserver.com Content-Type: multipart/alternative; boundary=001a11c2d35e40e8b00502c5361a X-Spam-Score: -1.238 () BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, T_DKIM_INVALID X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 07:35:29 -0000 --001a11c2d35e40e8b00502c5361a Content-Type: text/plain; charset=UTF-8 Followup - if someone has similar issues, i migrated setup to dropbear client and switched to using expect script as initcmd, and now everything works fine with every version of ilo host. Attaching config excerpts: config * { } default full { rw *; } default * { logfile /var/log/conserver/&.log; timestamp ""; include full; logfilemax 50m; master localhost; # options !autoreinit,ondemand; options reinitoncc; } #domyslne parametry polaczenia iLO default ilo-connection { type exec; execsubst X=hs; exec dbclient admin@X ; initcmd /etc/conserver/dropbear-ilo.sh ; break 1; } console ilo-3-4 { host 1.2.3.4;; include ilo-connection; } access * { trusted 127.0.0.1; allowed 127.0.0.1; admin konsola; } The dropbear-ilo.sh script: ----------------------------------------------------- #!/usr/bin/expect -f # debug # exp_internal 1 set send_slow {1 0.02} set ilom [lindex $argv 0] expect { "Do you want to continue connecting? (y/n)" { sleep 1 ; send -s "y\r"; expect "admin@" { send -s "sekrit\r" ; sleep 1 } } "admin@" { send -s "sekrit\r" ; sleep 1 } } sleep 1 expect "hpiLO->" send -s "vsp" sleep 1 send "\r" # try accessing vsp every 60 seconds, if it's locked expect { "Virtual Serial Port is currently in use by another session." { sleep 60; send -s "vsp\r"; exp_continue } } exit 0 ----------------------------------------------------- 2014-09-10 14:10 GMT+02:00 marcin kowalski : > Hi, all I am using the following configuration : > > default ilo-connection { > type exec; > execsubst X=hs; > > exec /etc/conserver/ilo-vsp.sh X; > > break 1; > > } > > console ilo-test { > host 1.2.3.4; > include ilo-connection; > } > > (...) > > with expect script like so : > > set send_slow {1 0.02} > set ilom [lindex $argv 0] > spawn ssh -vv admin@$ilom > expect { > "Are you sure you want to continue connecting (yes/no)?" > { > sleep 1 ; send -s "yes\r" ; > expect "admin@" { send -s "password\r" ; sleep 1 } > } > "admin@" > { send -s "password\r" ; sleep 1 } > } > > sleep 1 > interact > exit 0 > > > Script also calls vsp command later, but it's commented out for now. > > > The problem is that certain iLO servers fail to work correctly like this. > It mostly happens with ones that identify as "iLO2 2.23" (regardless of > variant in the version string, as i encountered a few of those so far) . > > Everything from expect script is accepted, but my commands are echoed back > to me and no output is displayed. The escape string for ilo "^](" seems to > be accepted (it results in ilo displaying the prompt screen again) but > nothing else is. > > Sometimes the ssh password is accepted, but it's still echoed back to me. > > What i've figured out so far > > - Other ilo versions work correctly, > - running expect script directly and making it setup a session with that > ilo host also works fine, from the same openvz machine > - Same configuration on non openvz host works correctly across all > machines i have configured for conserver (including the ilo2 ones), > although there is a diferent ssh version on it. > > Anyone has any useful tips on running conserver under openVZ that might > help here? Does that ilo version require some special treatment, or maybe > there is some ssh bug here? > --001a11c2d35e40e8b00502c5361a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Followup - if someone has similar issues, i migrated setup= to dropbear client and switched to using expect script as initcmd, and now= everything works fine with every version of ilo host.

Attaching con= fig excerpts:

config * {
}
default full {
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 rw *;
}
default * {
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 logfile /var/log/conserver/&.log;
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 timestamp "";
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 include full;
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 logfilemax 50m;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 master localhost;
#=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 options !aut= oreinit,ondemand;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 options rei= nitoncc;
}


#domyslne parametry polaczenia iLO

default = ilo-connection {
=C2=A0=C2=A0=C2=A0 type exec;
=C2=A0=C2=A0=C2=A0 exe= csubst X=3Dhs;
=C2=A0=C2=A0=C2=A0 exec dbclient admin@X ;
=C2=A0=C2= =A0=C2=A0 initcmd /etc/conserver/dropbear-ilo.sh ;
=C2=A0=C2=A0=C2=A0 br= eak 1;
}



console ilo-3-4 {
=C2=A0 host 1.2.3.4;;
= =C2=A0 include ilo-connection;
}

access * {
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 trusted 127.0.0.1;
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 allowed 127.0.0.1;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 admin konsola;
}




The dropbear-ilo.sh script:-----------------------------------------------------

#!/usr/bin/e= xpect -f

# debug
# exp_internal 1

set send_slow {1 0.02}
set ilom [lindex $argv 0]

expect {
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Do you want to continue connecting? (y/n)"=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sleep= 1 ; send -s "y\r";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expect "admin@&quo= t; { send -s "sekrit\r" ; sleep 1 }
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "ad= min@"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { = send -s "sekrit\r" ; sleep 1 }
}=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0

sleep 1
expect "</>hpiLO->"
=C2=A0=
send -s "vsp"
sleep 1
=C2=A0
send "\r"
=

# try accessing vsp every 60 seconds, if it's locked
expect = {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Virtual Serial Port = is currently in use by another session." {
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sleep 60= ;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 send -s "vsp\r";
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 exp_c= ontinue
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
}

exit 0<= br>-----------------------------------------------------


2014-09-10 14:10 GMT+0= 2:00 marcin kowalski <yoshi314@gmail.com>:
Hi, all I am using the following configu= ration=C2=A0 :

default ilo-connection {
=C2=A0=C2=A0=C2=A0 type e= xec;
=C2=A0=C2=A0=C2=A0 execsubst X=3Dhs;

=C2=A0=C2=A0=C2=A0 exec= /etc/conserver/ilo-vsp.sh X;

=C2=A0=C2=A0=C2=A0 break 1;

}
console ilo-test=C2=A0 {
=C2=A0=C2=A0=C2=A0 host 1.2.3.4;
=C2= =A0=C2=A0=C2=A0 include ilo-connection;
}

(...)

with expec= t script like so=C2=A0 :

set send_slow {1 0.02}
set ilom [lindex = $argv 0]
spawn ssh -vv admin@$ilom
expect {
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Are you sure you want to continue connecting (y= es/no)?"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 sleep 1 ; send -s "yes\r" ;
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expect &quo= t;admin@" { send -s "password\r" ; sleep 1 }
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 "admin@"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { send -s "password\r"= ; sleep 1 }
}

sleep 1
interact
exit 0


Script al= so calls vsp command later, but it's commented out for now.


= The problem is that certain iLO servers fail to work correctly like this. I= t mostly happens with ones that identify as "iLO2 2.23" (regardle= ss of variant in the version string, as i encountered a few of those so far= ) .

Everything from expect script is accepted, but my commands are e= choed back to me and no output is displayed. The escape string for ilo &quo= t;^](" seems to be accepted (it results in ilo displaying the prompt s= creen again) but nothing else is.

Sometimes the ssh password is acce= pted, but it's still echoed back to me.

What i've figured ou= t so far

- Other ilo versions work correctly,
- running expect s= cript directly and making it setup a session with that ilo host also works = fine, from the same openvz machine
- Same configuration on non openvz ho= st works correctly across all machines i have configured for conserver (inc= luding the ilo2 ones), although there is a diferent ssh version on it.
=
Anyone has any useful tips on running conserver under openVZ that might= help here? Does that ilo version require some special treatment, or maybe = there is some ssh bug here?

--001a11c2d35e40e8b00502c5361a-- From asavkov@redhat.com Wed Sep 24 14:52:38 2014 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by underdog.stansell.org (8.14.9/8.14.9) with ESMTP id s8OEqa0U005243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 24 Sep 2014 14:52:38 GMT Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8OEqZnK009951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 24 Sep 2014 10:52:36 -0400 Received: from littlebeast.usersys.redhat.com (dhcp-1-102.brq.redhat.com [10.34.1.102]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8OEqYfl030308 for ; Wed, 24 Sep 2014 10:52:35 -0400 Received: by littlebeast.usersys.redhat.com (Postfix, from userid 23532) id 308231018DD; Wed, 24 Sep 2014 16:52:34 +0200 (CEST) Date: Wed, 24 Sep 2014 16:52:34 +0200 From: Artem Savkov To: users@conserver.com Subject: [PATCH] Fix for invalid free on task execution. Message-ID: <20140924145234.GA14785@littlebeast.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Spam-Score: -2.549 () BAYES_00,RP_MATCHES_RCVD X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 14:52:39 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hello All, Attached patch fixes a SEGV mentioned by Anthony Gialluca in his 'SEGV in conserver ver 8.1.20' email. The segfault is caused by an unitialized execSlave variable in StartTask() which then calls FallBack(). The issue is still present in 8.2.0 and supplied patch is for this version. -- Regards, Artem --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="conserver_execSlave_init.patch" --- a/conserver/group.c 2014-09-18 17:08:03.390198988 +0200 +++ b/conserver/group.c 2014-09-18 17:08:25.886201733 +0200 @@ -1746,7 +1746,7 @@ extern char **environ; char *pcShell, **ppcArgv; extern int FallBack(char **, int *); - char *execSlave; /* pseudo-device slave side */ + char *execSlave = NULL; /* pseudo-device slave side */ int execSlaveFD; /* fd of slave side */ int cofile; --BXVAT5kNtrzKuDFl-- From idurkacz@inf.ed.ac.uk Wed Sep 24 19:12:17 2014 Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by underdog.stansell.org (8.14.9/8.14.9) with ESMTP id s8OJCEQF015452 for ; Wed, 24 Sep 2014 19:12:16 GMT Received: from lmtp1.ucs.ed.ac.uk (lmtp1.ucs.ed.ac.uk [129.215.149.64]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s8OJBvWi012548; Wed, 24 Sep 2014 20:12:02 +0100 (BST) Received: from smtp.staffmail.ed.ac.uk (mailwfe6.staffmail.ed.ac.uk [129.215.17.206]) by lmtp1.ucs.ed.ac.uk (8.13.8/8.13.7) with ESMTP id s8OJBkZr020196; Wed, 24 Sep 2014 20:11:51 +0100 (BST) Received: from cpc13-sgyl31-2-0-cust94.18-2.cable.virginm.net (cpc13-sgyl31-2-0-cust94.18-2.cable.virginm.net [82.43.156.95]) by www.staffmail.ed.ac.uk (Horde Framework) with HTTP; Wed, 24 Sep 2014 20:11:46 +0100 Message-ID: <20140924201146.132633br132ypj8k@www.staffmail.ed.ac.uk> Date: Wed, 24 Sep 2014 20:11:46 +0100 From: Ian Durkacz To: Artem Savkov Subject: Re: [PATCH] Fix for invalid free on task execution. References: <20140924145234.GA14785@littlebeast.usersys.redhat.com> In-Reply-To: <20140924145234.GA14785@littlebeast.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.8) X-Originating-UUN: idurkacz X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.72 on 198.151.248.21 X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 X-Scanned-By: MIMEDefang 2.52 on 129.215.149.64 X-Spam-Score: 0.951 () BAYES_50,RP_MATCHES_RCVD Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 19:12:17 -0000 Artem, > Attached patch fixes a SEGV mentioned by Anthony Gialluca in his > 'SEGV in conserver ver 8.1.20' email. Thank you very much. I confirm that that appears to clear the SEGV for me. Regards, Ian -- Ian Durkacz | idurkacz @ inf. ed. ac. uk School of Informatics, Univ of Edinburgh | Tel: +44 (0)131 650 5188 -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.