Issue Setting Relay for a Linux Client on Initial Installation

Usage and Config Platform
1

Hi all …

I set up a RHEL Linux 6.7 client according to the instructions here: http://www-01.ibm.com/support/knowledgecenter/SSQL82_9.2.0/com.ibm.tivoli.tem.doc_9.2/Platform/Adm/c_red_hat_installation_instructi.html

I am using BigFix 9.2.6.94.

I want to assign this client to a relay on first use of the BigFix client. So I created the following besclient.config file and placed it in /var/opt/BESClient:

[Software\BigFix\EnterpriseClient]
EnterpriseClientFolder = /opt/BESClient

[Software\BigFix\EnterpriseClient\GlobalOptions]
StoragePath = /var/opt/BESClient
LibPath = /opt/BESClient/BESLib
    
[Software\BigFix\EnterpriseClient\Settings\Client\__RelayServer1]
effective date  = Sun,%2004%20Dec%202016%2016:31:01%20+0900
value = http://myrelay.myserver.com:52311/bfmirror/downloads/

[Software\BigFix\EnterpriseClient\Settings\Client\__RelayServer2]
effective date = Sun,%2004%20Dec%202016%2016:31:01%20+0900
value = http://myrelay.myserver.com:52311/bfmirror/downloads/

[Software\BigFix\EnterpriseClient\Settings\Client\__RelaySelect_Automatic]
effective date = Sun,%2004%20Dec%202016%2016:31:01%20+0900
value = 0

[Software\BigFix\EnterpriseClient\Settings\Client\_BESClient_EMsg_File]
effective date = Sun,%2004%20Dec%202016%2016:31:01%20+0900
value = /var/log/BESClient/besclient.log

[Software\BigFix\EnterpriseClient\Settings\Client\_BESClient_EMsg_Detail]
effective date = Sun,%2004%20Dec%202016%2016:31:01%20+0900
value = 10000

[Software\BigFix\EnterpriseClient\Settings\Client\_BESClient_EMsg_EvalLog]
effective date = Sun,%2004%20Dec%202016%2016:31:01%20+0900
value = 1

(Yes, I wanted the extended debugging.)

I created the /var/log/BESClient directory for the extended debugging log.

As part of my setup, this client can’t connect to the BigFix server directly. I don’t want it to; I am simulating a firewall between my client and the BigFix server by not defining the IP address of my BigFix server in the /etc/hosts file.

When I start the client for the first time, it gets stuck trying to find the relay. There is a 7 minute delay while this communication is attempted and then it tries to connect to the BigFix server directly, which it won’t; therefore this connection will fail. The relay is not being found even though I have the IP address of myrelay.myserver.com defined in /etc/hosts, I can ping it and I can telnet to myrelay.myserver.com on port 52311.

The BESClient log:

ICU local character set: UTF-8
   ICU transcoding between fxf and local character sets: DISABLED
   ICU transcoding between report and local character sets: DISABLED
At 16:29:27 -0500 -
   Starting client version 9.2.6.94
   FIPS mode disabled by default.
   Cryptographic module initialized successfully.
   Using crypto library libBEScrypto - OpenSSL 1.0.1p-fips 9 Jul 2015
   Restricted mode
   Beginning Relay Select
At 16:37:28 -0500 -
   RegisterOnce: Attempting secure registration with 'https://mybigfix.server.com:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=9.2.6.94&Body=0&SequenceNumber=0&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://mybigfix.server.com%3a52311&AdapterInfo=00-50-56-9e-57-4c_192.168.40.0%2f24_192.168.40.194_0&AdapterIpv6=00-50-56-9e-57-4c%5efe80%3a%3a250%3a56ff%3afe9e%3a574c%2f64_0'
   RegisterOnce: GetURL failed - General transport failure. - winsock error -6 - registration url - http://mybigfix.server.com:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=9.2.6.94&Body=0&SequenceNumber=0&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://mybigfix.server.com%3a52311&AdapterInfo=00-50-56-9e-57-4c_192.168.40.0%2f24_192.168.40.194_0&AdapterIpv6=00-50-56-9e-57-4c%5efe80%3a%3a250%3a56ff%3afe9e%3a574c%2f64_0
At 16:39:29 -0500 -
   RegisterOnce: Attempting secure registration with 'https://mybigfix.server.com:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=9.2.6.94&Body=0&SequenceNumber=1&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://mybigfix.server.com%3a52311&AdapterInfo=00-50-56-9e-57-4c_192.168.40.0%2f24_192.168.40.194_0&AdapterIpv6=00-50-56-9e-57-4c%5efe80%3a%3a250%3a56ff%3afe9e%3a574c%2f64_0'
   RegisterOnce: GetURL failed - General transport failure. - winsock error -6 - registration url - http://mybigfix.server.com:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=9.2.6.94&Body=0&SequenceNumber=1&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://mybigfix.server.com%3a52311&AdapterInfo=00-50-56-9e-57-4c_192.168.40.0%2f24_192.168.40.194_0&AdapterIpv6=00-50-56-9e-57-4c%5efe80%3a%3a250%3a56ff%3afe9e%3a574c%2f64_0

The extended debug log pretty much says the same thing so I’m not including it here.

If I use the relay’s IP address in besclient.config instead of the hostname defined in my hosts file, the connection is made. The relevant lines in besclient.config are changed to:

[Software\BigFix\EnterpriseClient\Settings\Client\__RelayServer1]
effective date = Sun,%2004%20Dec%202016%2016:31:01%20+0900
value = http://192.168.40.187:52311/bfmirror/downloads/
    
[Software\BigFix\EnterpriseClient\Settings\Client\__RelayServer2]
effective date = Sun,%2004%20Dec%202016%2016:31:01%20+0900
value = http://192.168.40.187:52311/bfmirror/downloads/

The besclient log file when I use IP address shows the connection to the relay was made:

Current Date: January 8, 2016
   Client version 9.2.6.94 built for RedHat 5 x86_64
   Current Balance Settings: Use CPU: True Entitlement: 0 WorkIdle: 10 SleepIdle    : 480
   ICU data directory: '/var/opt/BESClient'
   ICU init status: SUCCESS
   ICU report character set: UTF-8
   ICU fxf character set: UTF-8
   ICU local character set: UTF-8
   ICU transcoding between fxf and local character sets: DISABLED
   ICU transcoding between report and local character sets: DISABLED
At 16:49:28 -0500 -
   Starting client version 9.2.6.94
   FIPS mode disabled by default.
   Cryptographic module initialized successfully.
   Using crypto library libBEScrypto - OpenSSL 1.0.1p-fips 9 Jul 2015
   Restricted mode
   Beginning Relay Select
At 16:49:29 -0500 -
   RegisterOnce: Attempting secure registration with 'https://192.168.40.187:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=9.2.6.94&Body=0&SequenceNumber=0&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://mybigfix.server.com%3a52311&AdapterInfo=00-50-56-9e-57-4c_192.168.40.0%2f24_192.168.40.194_0&AdapterIpv6=00-50-56-9e-57-4c%5efe80%3a%3a250%3a56ff%3afe9e%3a574c%2f64_0'
   Unrestricted mode
   Scheduling client reset; Computer id changed to 4789552
   Configuring listener without wake-on-lan
   Registered with url 'https://192.168.40.187:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=9.2.6.94&Body=0&SequenceNumber=0&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://mybigfix.server.com%3a52311&AdapterInfo=00-50-56-9e-57-4c_192.168.40.0%2f24_192.168.40.194_0&AdapterIpv6=00-50-56-9e-57-4c%5efe80%3a%3a250%3a56ff%3afe9e%3a574c%2f64_0'
   Registration Server version 9.2.6.94 , Relay version 9.2.6.94
   Relay does not require authentication.
At 16:49:30 -0500 -
   Completed automatic client authentication key exchange.
   Client has an AuthenticationCertificate
   Created mailboxsite and marking to gather
   Relay selected: 192_168_40_187.mycompany.com. at: 192.168.40.187:52311 on: IPV4
  [...]

Did I miss something with my attempt to assign a relay on first use of the BigFix client in Linux? If not, does anyone have an explanation as to why it appears to work if I specify the relay’s IP address but not with the relay’s hostname? It’s almost like the hosts file is being ignored by the BigFix client.

Also, once the connection is made, if I try to reassign the relay from 192.168.40.187:52311 to myrelay.myserver.com:52311 with the BigFix console, that fails, too. I am not a Linux expert by any means but I know enough to navigate my way through the command prompt :smile: .

Any enlightenment is appreciated!

–Mark

2

I don’t see anything obvious, particularly if telnet worked.

Why do you need to use the hosts file specifically? Can you put the related entry in DNS?

3

Can you ping the Relay? During Relay Detection (whether Automatic or Manual), the client will attempt to hit the Relay via ICMP before attempting BES communication on port 52311. If none of the Relays or BES Server is pingable, the client will eventually try to connect to the server defined in masthead on port 52311 without the ping.

You can override the “failback to BES Server” with some settings. Looks like you may have found this page already, but for anyone else looking check out https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Configuration%20Settings

What you’ll need are

_BESClient_RelaySelect_FailoverRelay
_BESClient_RelaySelect_FailoverRelayList

These are the “relays of last resort” that will be used if none of the servers or relays can be pinged.

1 Like
4

@jgstew, in my case, it’s a test environment and there’s no DNS server.

It’s almost like the client connection process is not attempting to resolve the relay by host name.

–Mark

5

@JasonWalker … Yes, I can ping the relay by both its hostname and its ip address. When I specify the relay server’s IP address in besclient.config, connectivity is successful. When I specify the relay server’s IP hostname, and define the hostname / IP address relationship in the hosts file, connectivity fails.

It almost seems like the client connection process is not attempting to, or is failing to, resolve the relay by hostname if that hostname is defined in the hosts file. (I don’t have a DNS server in my test environment).

I tried the settings you listed. No change in behaviour. I even tried _BESClient_Relay_NameOverride and that also didn’t make a difference.

–Mark

6

I agree, it certainly looks like a name resolution problem but I’ve not known the BigFix client to do anything nonstandard for name resolution. In fact I’ve overcome connectivity problems by “faking it”, mapping the name of a BES Root Server to the IP address of a local relay in /etc/hosts, so I know the hosts file is referenced (by default).

Is HOSTS resolution defined correctly at /etc/nsswitch.conf? Any issues related to shortname vs FQDN? Can you capture a network sniff during the connection attempt?

I haven’t enabled message-level encryption yet, have you? I wonder if there could be a problem with encryption failing? The relay would build a certificate based on what it believes its own hostname to be, which maybe doesn’t match the name the client is using to reach it?

Try the relays.dat parser tool at https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli+Endpoint+Manager/page/Relays.dat+Parser . The __BESData/actionsite/Relays.dat file should list all of the relays in the enterprise, see if the relay’s name advertised there matches what you expect.

1 Like
7

Hi @JasonWalker …

Is HOSTS resolution defined correctly at /etc/nsswitch.conf?

Yes. I did not change this file. Relevant section:

#hosts:     db files nisplus nis dns
hosts:      files dns

Any issues related to shortname vs FQDN?

Nope. I can ping and telnet the relay on both shortname and FQDN.

[root@mflinux7 actionsite]# ping -c 3 iem92linuxrelaymark
PING iem92linuxrelaymark.mycompany.com (192.168.40.187) 56(84) bytes of data.
64 bytes from iem92linuxrelaymark.mycompany.com (192.168.40.187): icmp_seq=1 ttl=64 time=0.471 ms
64 bytes from iem92linuxrelaymark.mycompany.com (192.168.40.187): icmp_seq=2 ttl=64 time=0.417 ms
64 bytes from iem92linuxrelaymark.mycompany.com (192.168.40.187): icmp_seq=3 ttl=64 time=0.341 ms

--- iem92linuxrelaymark.mycompany.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.341/0.409/0.471/0.058 ms
[root@mflinux7 actionsite]# ping -c 3 iem92linuxrelaymark.mycompany.com
PING iem92linuxrelaymark.mycompany.com (192.168.40.187) 56(84) bytes of data.
64 bytes from iem92linuxrelaymark.mycompany.com (192.168.40.187): icmp_seq=1 ttl=64 time=0.328 ms
64 bytes from iem92linuxrelaymark.mycompany.com (192.168.40.187): icmp_seq=2 ttl=64 time=0.440 ms
64 bytes from iem92linuxrelaymark.mycompany.com (192.168.40.187): icmp_seq=3 ttl=64 time=0.445 ms

--- iem92linuxrelaymark.mycompany.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.328/0.404/0.445/0.056 ms

Can you capture a network sniff during the connection attempt?

Yes, I ran the tcpdump utility from the start of the BigFix client until it reported the error connecting to BigFix. Is there something I should look for, or did you want me to send it to you?

I haven’t enabled message-level encryption yet, have you?

No message encryption.

Try the relays.dat parser tool at Legacy Communities - IBM TechXchange Community . The __BESData/actionsite/Relays.dat file should list all of the relays in the enterprise, see if the relay’s name advertised there matches what you expect.

Here are the contents of the file; iem92linuxrelaymark.mycompany.com is the relay I am trying to connect to. As you can see, the relay name matches what I’ve put into the besclient.config file.

C:\temp\temp100>ParseRelaysDotDat.exe Relays.dat
Affiliation: toplevel
Name:        IEMTopLvlRelay.
Port:        52311
Priority:    0
Weight:      100

Affiliation: Unaffiliated
Name:        iem92linuxmark.mycompany.com.
Port:        52311
Priority:    0
Weight:      0

Affiliation: Unaffiliated
Name:        iem92linuxrelaymark.mycompany.com.
Port:        52311
Priority:    0
Weight:      100

Affiliation: east
Name:        iem92winrelaymf.
Port:        52311
Priority:    0
Weight:      100

(What’s the dot that appears at the end of each name? I didn’t put that there).

Thanks for your help on this.

–Mark

8

(Just to be clear, I’m not IBM Support, I’m just another customer too).

Frankly I’m starting to grasp at straws here, it’s not making a lot of sense.

As for the relays.dat output, the trailing dots are normal (at least, I see them in mine as well). I think that’s to follow the DNS client convention of “don’t append additional domain names if the name ends with a dot”. I don’t have any asterisks in my output, did you add those to yours for clarity or were they really present in the output listing?

On the network sniff, I’d look for ICMP as well as TCP port 52311. That might show something interesting like Pings or TCP on IPv6 instead of IPv4; maybe the IPv6 connections getting blocked but the IPv4 is working (and only used when you specify an IPv4 address instead of a hostname)?

Is there any way the BES Client might be blocked reading the ‘hosts’ or ‘nsswitch.conf’ files? Are you running the BigFix client in a service account instead of ‘root’? Do the permission on /etc/nsswitch.conf and /etc/hosts allow Read to all of User:Group:Other?

1 Like
9

@JasonWalker … I appreciate the help and if nothing else, I’ll have ruled out everything I could think of before pursuing a PMR. This is a good learning experience if nothing else (and that attitude will keep my frustration down :slight_smile: )

The asterisks were me setting that text to bold, as that’s the relay in question.

I’ll take a look at the tcpdump output for occurrences of ICMP and 52311.

Is there any way the BES Client might be blocked reading the ‘hosts’ or ‘nsswitch.conf’ files?

I would think that if this were the case, I’d see some kind of error in the extended debug output. I don’t see any errors like this.

Are you running the BigFix client in a service account instead of ‘root’?

It is running as root.

Do the permission on /etc/nsswitch.conf and /etc/hosts allow Read to all of User:Group:Other?

Yes:

[root@mflinux7 ~]# ls -l /etc/nsswitch.conf
-rw-r--r--. 1 root root 1688 May  4  2010 /etc/nsswitch.conf
[root@mflinux7 ~]# ls -l /etc/hosts
-rw-r--r--. 1 root root 380 Jan  8 15:35 /etc/hosts

–Mark

1 Like
10

Hi all …

Here is an update to this issue. Recall that I was recreating a customer issue where I simulated a firewall between my client and the BigFix server by not defining the IP address of my BigFix server in the /etc/hosts file.

I found out that the customer who had this issue defines their firewall rules by IP address. They told me that if we used the hostname to make a connection, that the connection over the firewall would not be successful. I’m not a firewall guy but that definitely seems like the cause here, given that when I changed the hostname to IP address in the besclient.config file, the connection to the relay was made successfully.

So if this happens to you in the future, you should ask the firewall guys how they define their rules (by hostname, IP address or both). If it’s just by IP address, then use the IP address in your besclient.config / clientsettings.cfg file. Hopefully this will save you a lot of head scratching.

–Mark

1 Like
11

If the root and/or DMZ relays have fairly static IPs, then it is not a bad idea to define some failover relays by IP address in addition to hostname.

This not only matters in this particular case, but also if there is a failure with DNS somewhere.

This also provides an interesting option for selecting local relays. You could define the first relay to be selected to be 192.168.1.200 which could be a different physical relay for every site using NAT with this subnet.

Given the odd configuration of this customer, it might make sense to have a relay in their network just to make it a bit easier for the clients to get to a relay.

12

I just ran into this myself. My problem stemmed from having a messed up /etc/hosts file and having /etc/nsswitch set to look at files before DNS. I resolved the problem by putting an entry for my relay at the very top of /etc/hosts, and the agent successfully registered.

1 Like