Automated Client Updates
I'm testing out the client update feature. Here's my experience so far:
- I read the directions, and prepared a client tarfile and placed it (hobbitclient-420.tar) in the download directory.
- I added the following to my client-local.cfg: [linux] log:/var/log/messages:10240 ignore MARK
- clientversion:hobbitclient-420*
- I waited awhile (30+ mins) for the clients to update.
- When I click the info column on some clients, it shows: *Client S/W:hobbitcli* Is it supposed to be truncated like that? Does this indicate that the new client is running? Is there any other way to verify the client version? If not maybe it should be available in the "client data" status somewhere.
- *-Charles
On Thu, Aug 10, 2006 at 04:29:43PM -0700, Charles Jones wrote:
I'm testing out the client update feature. Here's my experience so far:
- I read the directions, and prepared a client tarfile and placed it (hobbitclient-420.tar) in the download directory.
- I added the following to my client-local.cfg: [linux] log:/var/log/messages:10240 ignore MARK
- clientversion:hobbitclient-420*
- I waited awhile (30+ mins) for the clients to update.
It can take a while:
- hobbitd re-loads the client-local.cfg file every 10 minutes. So worst case, it will take 10 minutes for the change to take effect. You can force this by doing a "kill -HUP <hobbitd-pid>".
- The client needs to contact the server to pick up the new config. If the timing is bad, that might not happen until 5 minutes after the client-local.cfg change was loaded. So now 15 minutes have passed.
- If you're running the clients via the hobbitfetch/msgcache pull-style connection, there's an additional 5 minute delay due to the extra hop between the server and the client.
- After the update, it will be another 5 minutes before the client runs again and you can see the change.
So all in all, it takes between 5 and 25 minutes.
- When I click the info column on some clients, it shows: *Client S/W:hobbitcli* Is it supposed to be truncated like that?
No, it looks like you upgraded the client software from one of the beta/RC versions. They did truncate the clientversion string to 9 characters max.
Does this indicate that the new client is running? Yes. The next time you update, it should show the full version string.
Is there any other way to verify the client version?
Add a "file" check to one of the updated files, perhaps with an md5 hash check to be 100% sure it's the new version.
Regards, Henrik
Does hobbit support this feature ?
Ie, if oracle processes died an alert will sent to oracle team. cron process died, the unix team will receive this alert.
Last time I posted similiar question but it was for disk partitions.
If not already avaiable, can someone (Henrik) please implement this kind of fine-grain monitoring ?
Regards T.J. Yang
On Fri, Aug 11, 2006 at 09:02:47AM -0500, T.J. Yang wrote:
Does hobbit support this feature ?
Ie, if oracle processes died an alert will sent to oracle team. cron process died, the unix team will receive this alert.
Yes.
Look at the GROUP setting in hobbit-clients.cfg, which goes together with the GROUP rule in hobbit-alerts.cfg.
Henrik
Le 11/08/2006 17:02, Henrik Stoerner a écrit :
Look at the GROUP setting in hobbit-clients.cfg, which goes together with the GROUP rule in hobbit-alerts.cfg.
Hi Henrik
I have a similar question : would it be possible to allow disable of an "instance" of a resource ?
Something like :
$ BB $BBDISP "disable servername procs cron"
Thanks in advance for your answer.
--
Frédéric Mangeant
Steria EDC Sophia-Antipolis
On Fri, Aug 11, 2006 at 05:31:32PM +0200, Frédéric Mangeant wrote:
I have a similar question : would it be possible to allow disable of an "instance" of a resource ?
Something like :
$ BB $BBDISP "disable servername procs cron"
Not without some major changes to how acksand disables are handled. Sorry.
Regards, Henrik
participants (4)
-
frederic.mangeant@steria.com
-
henrik@hswn.dk
-
jonescr@cisco.com
-
tj_yang@hotmail.com