Client update still fails to work for us. What does it do? It downloads a clientupdate binary to the ~client/tmp directory. It can run manually:
clientupdate --update=sunos8v14
So it fails somewhere between getting the clientupdate binary and running the clientupdate binary. Is there anything I can try to further troubleshoot this?
Found update in progress or failed update (started 10 minutes ago) 2006-08-03 16:34:49 connect to bbd failed - Connection refused 2006-08-03 16:34:49 Whoops ! bb failed to send message - Connection failed Cannot fetch new client tarfile tar: blocksize = 0 2006-08-03 16:40:17 connect to bbd failed - Connection refused 2006-08-03 16:40:17 Whoops ! bb failed to send message - Connection failed Cannot fetch new client tarfile tar: blocksize = 0 Found update in progress or failed update (started 4 minutes ago)
Is this going to be fixed for 4.2. There seem to be quite a number of bugs. How about a second release candidate?
-- David Gore (v965-3670) Enhanced Technology Support (ETS) Network Management Systems (NMS) IMPACT Transport Team Lead - SCSA, SCNA Page: 1-800-PAG-eMCI pin 1406090 Vnet: 965-3676
On Thu, Aug 03, 2006 at 06:16:20PM +0000, David Gore wrote:
Client update still fails to work for us. What does it do? It downloads a clientupdate binary to the ~client/tmp directory. It can run manually:
clientupdate --update=sunos8v14
What happens is this:
hobbitclient.sh runs "clientupdate --update=VERSION --reexec" This copies the clientupdate tool to the client/tmp/.update.HOSTNAME.TIMESTAMP.tmp, makes it executable and launches it with the options "--update=VERSION --remove-self". The reason for this is to avoid unpacking errors if the clientupdate utility is overwritten while running.
The temporary binary opens a connection to the hobbit server and uses the "download" command to fetch the file "VERSION.tar". This file must exist in the Hobbit servers' ~hobbit/server/download/ directory. The downloaded data is passed to a "tar xf -" command via a pipe. So this downloads and unpacks the new client file in one operation.
When the unpacking is complete, it exec's the (new) client/bin/clientupdate with the "--suid-setup" option which does nothing unless you've compiled it with a special option.
So it fails somewhere between getting the clientupdate binary and running the clientupdate binary. Is there anything I can try to further troubleshoot this?
Found update in progress or failed update (started 10 minutes ago) 2006-08-03 16:34:49 connect to bbd failed - Connection refused 2006-08-03 16:34:49 Whoops ! bb failed to send message - Connection failed Cannot fetch new client tarfile
Hmm - what's your BBDISP and BBDISPLAYS setting ? I've just finished troubleshooting another problem with "bb" connecting to the wrong servers.
Is this going to be fixed for 4.2.
Yes, we all need this working for 4.2.
There seem to be quite a number of bugs. How about a second release candidate?
I'm considering it, but haven't decided yet whether to do an extra round of another RC release. I'll spend some time tomorrow getting an overview of what bugs have been fixed during the RC, and then decide after that.
Regards, Henrik
Henrik Stoerner wrote:
On Thu, Aug 03, 2006 at 06:16:20PM +0000, David Gore wrote:
Client update still fails to work for us. What does it do? It downloads a clientupdate binary to the ~client/tmp directory. It can run manually:
clientupdate --update=sunos8v14
What happens is this:
hobbitclient.sh runs "clientupdate --update=VERSION --reexec" This copies the clientupdate tool to the client/tmp/.update.HOSTNAME.TIMESTAMP.tmp, makes it executable and launches it with the options "--update=VERSION --remove-self". The reason for this is to avoid unpacking errors if the clientupdate utility is overwritten while running.
The temporary binary opens a connection to the hobbit server and uses the "download" command to fetch the file "VERSION.tar". This file must exist in the Hobbit servers' ~hobbit/server/download/ directory. The downloaded data is passed to a "tar xf -" command via a pipe. So this downloads and unpacks the new client file in one operation.
When the unpacking is complete, it exec's the (new) client/bin/clientupdate with the "--suid-setup" option which does nothing unless you've compiled it with a special option.
So it fails somewhere between getting the clientupdate binary and running the clientupdate binary. Is there anything I can try to further troubleshoot this?
Found update in progress or failed update (started 10 minutes ago) 2006-08-03 16:34:49 connect to bbd failed - Connection refused 2006-08-03 16:34:49 Whoops ! bb failed to send message - Connection failed Cannot fetch new client tarfile
Hmm - what's your BBDISP and BBDISPLAYS setting ? I've just finished troubleshooting another problem with "bb" connecting to the wrong servers.
BBDISP="0.0.0.0" # IP address of the Hobbit server BBDISPLAYS="hobbit1 hobbit2" # IP of multiple Hobbit servers. BBDISP must be "0.0.0.0".
I suppose that makes it sort of interesting, since we are configuring the clientupdate on hobbit1 only. Both hobbits are up and running and are up to date in regards to statuses for all the standard and customized columns. Perhaps trying to get the tar file from hobbit2 where it does not exist causes some grief?
Is this going to be fixed for 4.2.
Yes, we all need this working for 4.2.
There seem to be quite a number of bugs. How about a second release candidate?
I'm considering it, but haven't decided yet whether to do an extra round of another RC release. I'll spend some time tomorrow getting an overview of what bugs have been fixed during the RC, and then decide after that.
Regards, Henrik
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
On Thu, Aug 03, 2006 at 06:16:20PM +0000, David Gore wrote:
Client update still fails to work for us. What does it do? It downloads a clientupdate binary to the ~client/tmp directory. It can run manually:
Thanks to a lot of help from David, I managed to figure out what was going on. David has two servers that the client reports to, and the download code simply could not handle that setup - it would end up trying to download the new client file from a server at IP "0.0.0.0". Which happens to work on some systems (it's handled like 127.0.0.1), but not all.
The solution is in the current snapshot (updated at 07:03 AM UTC today), and requires updating the client-side "bb" utility. Note that this only bites you if you have multiple servers that your clients report to, i.e. BBDISP is "0.0.0.0".
Regards, Henrik
participants (2)
-
David.Gore＠verizonbusiness.com
-
henrik＠hswn.dk