unregister a node from control tier

[mastinder singh]

How to unregister a node from control tier and how to delete entry of
a node from all files.

[Anthony Shortland]

Remove the node resource from your project by deleting it in Workbench our using the command line APIs, or the Ant/Java task bindings.

On Feb 2, 2012, at 6:55 AM, mastinder singh wrote:

> How to unregister a node from control tier and how to delete entry of
> a node from all files.
>

> --
> You received this message because you are subscribed to the Google Groups "ControlTier" group.
> To post to this group, send email to contr...@googlegroups.com
> To unsubscribe from this group, send email to controltier...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/controltier?hl=en
> http://wiki.controltier.org

[Bhaskar Mukherjee]

You can log into workbench delete the node using nodemanager. Not sure about your second requirement, could you be more specific on this?

With warm regards,
Bhaskar Mukherjee
Slough, United Kingdom

On Thu, Feb 2, 2012 at 2:55 PM, mastinder singh <mast...@gmail.com> wrote:

How to unregister a node from control tier and how to delete entry of
a node from all files.

[mastinder singh]

thing is we have moved control tier server from old server to new
server and i guess we have entry for it on files inside following
folders inside src builders nodes and sites.How to remove entry of
old control tier server and put entry for new control tier server on
all files.

Please Wait while we retrieve RELEASE TRAIN information
10-Feb-2012 13:10:04
======================================================================================================================
10-Feb-2012 13:10:07 error: com.jcraft.jsch.JSchException: Auth cancel
10-Feb-2012 13:10:07 -------- Current cluster server release train
deployed is ------
10-Feb-2012 13:10:07
======================================================================================================================
10-Feb-2012 13:10:07 Please Wait while adding new patch dependencies
10-Feb-2012 13:10:07
======================================================================================================================
10-Feb-2012 13:10:09 number of nodes to dispatch to: 2, (threadcount=1)
10-Feb-2012 13:10:09 Connecting to older server location:22
10-Feb-2012 13:10:10 error: com.jcraft.jsch.JSchException: Auth cancel

On 2/2/12, Bhaskar Mukherjee <bhask...@gmail.com> wrote:
> *You can log into workbench delete the node using nodemanager. Not sure

> about your second requirement, could you be more specific on this?

> **
>
> With warm regards,
> **Bhaskar Mukherjee
> Slough, United Kingdom
>
> *

>
>
>
> On Thu, Feb 2, 2012 at 2:55 PM, mastinder singh <mast...@gmail.com> wrote:
>
>> How to unregister a node from control tier and how to delete entry of
>> a node from all files.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ControlTier" group.
>> To post to this group, send email to contr...@googlegroups.com
>> To unsubscribe from this group, send email to
>> controltier...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/controltier?hl=en
>> http://wiki.controltier.org
>
> --
> You received this message because you are subscribed to the Google Groups
> "ControlTier" group.
> To post to this group, send email to contr...@googlegroups.com
> To unsubscribe from this group, send email to
> controltier...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/controltier?hl=en
> http://wiki.controltier.org

--
regards,

Mastinder singh
Uk Number +447624169401
India +918105601518
USA 1-855-946-2329 / (205) 588-4757

[Anthony Shortland]

Didn't see the "files inside following folders", but if you've moved the ControlTier server the best approach is to re-install the software itself (since the installer will deal with the hostnames in various configuration files) and update your projects (particularly the server node resource and any other resource that refers to the old hostname - e.g. pack repository URLs). You can do that via the Workbench UI and/or ProjectBuilder.

I'd point out that a good bit of "self-defence" is to establish a CNAME in DNS for your ControlTier server (e.g. "deploy.mycompany.com") so that the next time you move it you can keep the same name!

Anthony.

[Moses Lei]

You can use something like:

sed -i.bak -re 's/old.server.fqdn/new.server.fqdn/g' {folder1,folder2,folder3}/*.xml

To quickly replace all of the instances of your old server name with your new one.

Moses
--
Moses Lei
[ Professional Services | DTO Solutions, Inc. ]
[ mobile: +1 703.901.5969 | e-mail: ml...@dtosolutions.com | aim/gtalk: ml...@controltier.com | yahoo: moseslei | windows live (msn): ml...@dtosolutions.com ]

[mastinder singh]

ok I have removed old control tier from workbench from nodes.I have
another issue now.

I am remotely trying to call new control tier and getting different outputs.

[ PATCHBUILDS-PATCHSTGNA3-JOB1]$ ctl-exec -p project -I tags=ctier
newcontroltier

[ PATCHBUILDS-PATCHSTGNA3-JOB1]$ ctl-exec -p project -I tags=ctier --
ctl -p project
number of nodes to dispatch to: 1, (threadcount=1)
Connecting to server2(oldcontrottier):22
error: com.jcraft.jsch.JSchException: Auth cancel

[mastinder singh]

and when i try same command from control tier server it works
fine.From remote agent it gives error.

--
regards,

Israel *057 - 9463862
Website: http://mastinder.in
*

[Anthony Shortland]

Looks to me that the node "newcontroltier" has a hostname attribute of "oldcontrottier" and that ssh is not setup for the private key configured for ctl-exec (framework.properties) on the system where the command is being executed.

[mastinder singh]

Hi,

I am able to ssh from remote node to new controltier server.But
ctl-exec is not working from remote node .Which file i need to edit
and where { on remote node or new controltierserver}.

--
regards,

Mastinder singh

*

[mastinder singh]

on server it is on following locations

/ctl/etc/framework.properties
./src/ctl-dispatch-3-6-support/maven-ctl-plugin/src/test/resources/ctlbase1/etc/framework.properties
./src/ctl-dispatch-3-6-support/target/ctl_base/etc/framework.properties

[dnbiadm@dtdnbibl02 ctier]$

[mastinder singh]

/ctl/etc/framework.properties this file have correct hostname entry
and pointed to new control tier server
framework.server.hostname

[Anthony Shortland]

Oh ... it was the ssh key in framework properties I was alerting you to ... and check the hostname attributes of your the node resources in your workbench project.

[mastinder singh]

Hi,

W have 6 build servers boxes.They are running from build user and connection  to control tier server which are running as admin user.

They were able to connect to each other few days back.I have check ssl key in framework.properties file and also hostname attributes everything fine to me.I am able to ssl between boxes.I have still no clue why this command try to connect to old control tier we have shut it down.

[mastinder singh]

6 build boxes running as build user(used for patching and building artifacts)
rest of them running as admin users(deployment of artifacts from repository)
ssl key =id_rsa in framework.properties file
hostname attributes are all fine in workbench.

Error ( connecting control tier server from build boxes.It was all running fine few day back).

[Anthony Shortland]

Hmm ...

On the ControlTier server system as the admin user run the command "ssh -v -i ~/.ssh/id_rsa user@hostname id" where "user@hostname" are the user and hostname attributes on one (or more) of the nodes you have defined in your Workbench project.

Post the output of this experiment so we can work out exactly what's going wrong.

Anthony.

[Moses Lei]

So is the problem that from your build boxes, ctl-exec still wants to try to ssh to the old server?

If so then something's going on on those systems... maybe an out of date resources.xml or something?

Moses

--
Moses Lei
[ Professional Services | DTO Solutions, Inc. ]
[ mobile: +1 703.901.5969 | e-mail: ml...@dtosolutions.com | aim/gtalk: ml...@controltier.com | yahoo: moseslei | windows live (msn): ml...@dtosolutions.com ]

[Anthony Shortland]

To Moses' point ... if you're trying to dispatch commands from nodes other than the ControlTier server, then:

1) Get logged in as the user on the source node

2) Check the value of the ssh key in framework.properties

3) Decide the username and hostname for the target node in your Workbench project (and even double-check the local resources.xml as Moses notes)

4) Run the command "ssh -v -i ~/.ssh/id_rsa user@hostname id" (to closely emulate the JSch invocation from ctl/ctl-exec)

... and post its output.

Anthony.

[mastinder singh]

Hi Anthony,

I have able to run it successfully on three nodes and rest three nodes failed.

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to port 22.
debug1: Connection established.
debug1: identity file /home/adm/.ssh/id_rsa type 1
debug1: loaded 1 keys
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host ' is known and matches the RSA host key.
debug1: Found key in /home/adm/.ssh/known_hosts:40
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Next authentication method: publickey
debug1: Offering public key: /home/adm/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8

passed

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 22.
debug1: Connection established.
debug1: identity file /home/adm/.ssh/id_rsa type 1
debug1: loaded 1 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host is known and matches the RSA host key.
debug1: Found key in /home/adm/.ssh/known_hosts:39
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure. Minor code may provide more information
Unknown code krb5 195

debug1: Next authentication method: publickey
debug1: Offering public key: /home/adm/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: password

failed

[mastinder singh]

Hi Anthony,

It seems to work today.Do we have any history tab in control tier to
see what was changes on it recently.

[Anthony Shortland]

Hi Mastinder,

The output is much more useful if you include the command you ran itself.

These test commands are not influenced by ControlTier at all; so the changes must have been in your system or network (DNS?).

Anthony.

[mastinder singh]

Hi Anthony,

i have run ssh -v -i ~/.ssh/id_rsa build@hostname command and also i have included id_rsa in authentication_key of target server.Still key don't work in three build server but it works fine on rest three server.Also where i will find what changes were down on control tier say about last 10 days.

[mastinder singh]

cat ~/.ssh/id_rsa.pub | ssh $user@$server "cat >> ~/.ssh/authorized_keys",I have tried this as well from control tier server to build servers.it don't work on three nodes but it work other way around from node to control server.

[Anthony Shortland]

The last few lines of the debug output indicate that ssh did try authenticating with the RSA key "/home/adm/.ssh/id_rsa":

>> debug1: Offering public key: /home/adm/.ssh/id_rsa

>> debug1: Authentications that can continue:

>> publickey,gssapi-with-mic,password

>> debug1: Next authentication method: password

>>

>> failed

... but failed.

There are any number of reasons why this might be the case:

• You're not connecting to the user@server you think you are, perhaps due to name resolution issues.
• The public key file associated with  /home/adm/.ssh/id_rsa (usually /home/adm/.ssh/id_rsa.pub)  has not been added to "~user/.ssh/authorized_keys" on "server" (or has been added incorrectly in some garbled fashion).
• ~user/.ssh/authorized_keys does not have the correct permissions set (i.e. 400 or 600).
• ~user/.ssh does not have the correct permissions set (i.e. 500 or 700).
• ~user does not have the correct permissions set (i.e 750 or 700 or similar).

Perhaps I've missed a couple of tricks here ... but none of this is intrinsically to do with ControlTier being specifically related to general configuration of ssh key-based authentication.

Anthony.

[mastinder singh]

Hi Anthony,

I works and i am able to do ssh to build servers now.
Chmod 755 on users help it.