RFE: Client installer reference relay.dat at installation time

Hello all, I’m here to solicit votes for my RFE: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=89670

Basically, I’m asking for the client installers to be able to reference a relay.dat file at installation time, just as it references a clientsettings.cfg or masthead.axfm file. Based on my own experience and multiple postings in this forum, I think the main reason most people create a clientsettings.cfg file is to specify the relays available to the client at installation time. These people end up having to either maintain multiple installers for distinct clientsettings.cfg in each site/network, or, like me, have to build external scripts to build a clientsettings.cfg file on-the-fly at installation time.

If we could take an existing relay.dat from our infrastructure and reference it at installation time, we could greatly reduce the number of client installers we maintain and reduce the complexity of installing the client. With a working relay.dat at installation time, the client would not be limited to contacting the root server or manually-specified __RelayServer1 / __RelayServer2 / Tertirary / Failover relay lists. Instead they could perform a normal relay selection and register with any available relay listed in the relay.dat file.


automatic relay selection at client installation time
this would be great…

1 Like

Can you provide more details about the issue and what effect you need?

Couldn’t you just put all of the relays in the relays.dat file into the clientsettings.cfg file in a list?

Or why not set the client to do automatic relay selection, but have a few options in the failover list?

You could use the hosts file to point the root FQDN to the local relay. If you can control the DNS that the clients use at each site differently, then you could do something similar at the DNS level.

I personally primarily use the clientsettings.cfg file to set a bunch of client settings that will speed up initial provisioning of the client, as well as many that I think are a good idea in general.

It might be possible to handle the inclusion of relays.dat with my install_bigfix script: https://github.com/jgstew/tools/blob/master/bash/install_bigfix.sh

My install_bigfix scripts take a relay FQDN as a parameter and automatically set it as a failover relay for the client, so you could actually use this to get the desired affect already. The script actually works on Linux as well which don’t support clientsettings.cfg normally.

See the windows version here: https://github.com/jgstew/tools/blob/master/CMD/install_bigfix.bat

This is actually a combined version, which should work on Win or Linux: https://github.com/jgstew/tools/blob/master/CMD/install_bigfix_universal.bat

Original post about this: Script to kickstart the installation of BigFix on OS X, Debian-family, RHEL-family

What I’d like is to be able to host the same client installer package, and let any of our admins, on any network segment, install it without having to customize it. They don’t need to understand the details of our relay architecture or where they fit into it.

Updating the clientsettings.cfg for each environment is what I’m doing now; but each setting is limited to 256 characters, so I can’t just put all of my relays into the failover list.

Updating the client HOSTS file is something I’d much prefer not to do - if it came to that, I could edit the registries to force a __RelayServer1 for that matter. I’d also like to remove my custom script that’s wrapping it now to hit all of our Relays.

I’m also running a script out of Task Scheduler to check the BES client health, that goes as far as uninstalling, deleting the directories, and reinstalling the client if nothing else works. It would be great to deploy a single Scheduled Task for this, that works everywhere in the enterprise.

1 Like

Sounds like you are interested in Windows clients specifically?

You don’t have an internet facing relay that could be used if needed in the beginning?

No, there’s no single relay everyone can use.

Dealing with regional differences (different states), as well as political (“my” side of the firewall is different from “their” side, even if “they” are just the next cube over).

And we need both Windows and Linux, and ideally AIX as well.

1 Like

Have you ever tried installing the client, then copying a relays.dat file into the right place from another client and see what happens? (without using a clientsettings.cfg and starting/restarting the client after the relays.dat file is in place?)

I have never tried this myself, but if it works, it could be incorporated into my script, though my script currently doesn’t work on AIX and I don’t have any access to AIX to test it on.

Not yet…but that’ll probably be tried soon.

1 Like

I created an issue/enhancement here: https://github.com/jgstew/tools/issues/14

Let me know if copying relays.dat works so I can incorporate that into what I’m doing.

Do you have a GitHub account?

1 Like

I don’t have a GitHub account right now, but I might end up registering for one.

As for what I’ve found with the client (Windows client at least), is that I can run the installer with a minimal ClientSettings.cfg to enable Automatic Relay Select:

When the BES Client setup.exe installs, the client initially fails to register (trying only the BES Root Server). But if I copy a working Relays.dat to __BESData\actionsite and restart the BES Client service, it does use the Relays.dat and performs an automatic relay select, finds a relay, and registers successfully!

So I think I can use that process for now; it still requires using a wrapper script to handle dropping the Relays.dat and restarting the BES client, but that’s considerably less complex than what I’m doing now (using wget.exe to hit every relay in a list and building a specific clientsettings.cfg based on which relay responds first).


That is awesome, thanks for doing that testing for me.

This means I should be able to add a feature to my install_bigfix scripts so that if you have a Relays.dat file in the current working directory when you run the script, then it will copy it into place for you automatically. This is what I am already doing with the clientsettings.cfg file and I intend to also do something similar for the masthead/actionsite file.