BES Client(s) using Proxy when I need direct connectivity

ENV: BIG Fix EndPoint Server v9.1.1117
ILMT v9.2.3.1
OS Linux Redhat v6.3

Hi guys,

I’m very, very new to BIG fix and ILMT so please be gentle with me!

I’ve inherited an ILMT / Big FIX environment and I’ve been asked to look into something that I’m hoping you can help me with. When I intially got the environment one of my first tasks was to get the BIG Fix Endpoint server to download the new IBM_service_catalog, the only reason the fixlets were unable to do this was because the server had invalid proxy connections so was therefore not able to connect out to the internet to grab it. To fix this we simply adjusted the settings in the “/var/opt/BESServer/besserver.config” file to use the correct settings and we were able to speak to IBM again.

However, we now see that all the computers that the new catalog will be distributed to are now reporting a “pending download” status with the error (ignore the X’s - this is me removing confidential data);

Download error: "HTTP Error 56: Failure when receiving data from the peer: Received HTTP code 403 from proxy after CONNECT"
Download requested on server:
URL: https://XXX.XX.XX.XX:9081/sam/CIT_catalog_LINUX.xml.bz2
Hash: (sha1)XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Size:
Next retry: 7 minutes. Retry now

To me it looks like the clients are now trying to connect to the server to pull down the catalog using a proxy, when I need a direct connection! I’ve found the follow document where by I think we should make a change on the config of the client to use a direct connection if the proxy fails;

https://www.ibm.com/support/knowledgecenter/en/SS63NW_9.1.0/com.ibm.tivoli.tem.doc_9.1/Platform/Adm/c_proxy_on_client.html#configuringaproxyconnectiononclient

_BESClient_Comm_ProxyManualTryDirect has been set to “2” (try direct first) but still the client is trying through a proxy? I’m sure I’m doing something obivously wrong, can somebody please direct me as I’ve hit a bit of a wall.

Thanks in advance for your help.
Rgds,
Dil

try with proxy exception on localhost, ip, hostname and fully qualified domain name
also, try if machine can resolve that URL, if not you can use IP if its hostname now

Hi Michal,

Thanks for your response, on your second point. I’ve already logged on to the linux machine in question and from a console fired up firefox where I was able to download the file using the link the client is trying to. This suggests that connectivity does exist from the machine I guess?

I can’t see variables on the client that represent a “proxy exception”, can you please provide some further details on what your suggesting please? Apologies, I’m new to this!

Dil

It’s actually your Root Server that will use the given URL to download the catalog. You should only need to configure the proxy settings on the root server.

The easiest way to do that is to use the BES Admin Tool on the root server, where you can specify both the proxy server to use (for Internet downloads) and the proxy exceptions. The Proxy Exceptions should at least include localhost, 127.0.0.1, and the IP addresses and names of your BFI server.

check http_proxy on your linux and use no_proxy if needed

export no_proxy=“127.0.0.1, localhost, *.cnn.com, 192.168.1.10, domain.com:8080

also set proxy exxception on BigFix
https://www.ibm.com/support/knowledgecenter/SSQL82_9.5.0/com.ibm.bigfix.doc/Platform/Installation/c_proxy_on_server.html

Thanks Michal/Jason,

Just to summaris, the plan would be from the End Point Linux machine run the command;

/opt/BESServer/bin/BESAdmin.sh -setproxy [-proxy=<proxy_host>[:<proxy_port>] -exceptionlist= localhost, 127.0.0.1, <EndPointServerIP>

This will mean that all clients connected will try proxy first and then revert to the exception if this first connection fails. As a plan B I will then set up the environment variable on the client(s);

export no_proxy=“127.0.0.1, localhost, *.cnn.com, 192.168.1.10, domain.com:8080”

Does this make sense to you guys?
Thanks again for all your support and understanding on this.

Rgds,
Dil

The proxy setup only needs to happen on your Bigfix Root Server, unless you’ve taken specific config settings to change that.

When the client needs a download, it sends a download request to its relay. The relay sends that request up its chain to the root server. Only the root server actually goes out to Internet (or your BFI setver) to download files.

The Server then notifies the relays when the file is cached, they download then file from their parent server, and then the client downloads it from its relay.

Only the root server isngoing to Internet, so only the root server needs its proxy configured

1 Like

Endpoint catalog download is not an internet download. BigFix root server is trying to download catalog file from BigFix Inventory server and its using HTTP proxy to do that, while most likely it should not. Especially if those are on the same machine.

Good point, on reread I see my post wasn’t clear.

In General, only the BES Root Server performs downloads for the whole deployment. It sounds like you’ve configured Proxy settings on the root server so it uses a proxy to reach the internet; and you need to add exceptions so it does not use the proxy to reach the BFI server.

2 Likes

Hi guys,

So, thanks again for all your support. By adding the “ProxyExceptionList” to the besserver.config on the EndPoint Server, the “Action” for the “Catalog Download” is showing 100% complete, so that is definitely a win, so thanks very much!

I have noticed something else however, ILMT is still showing “outdated catalog’s” for all clients even though I’ve done a new import. When I check the catalog version on the End Point management console (Computers -> Summary -> Software Scan Status section) the catalog version is still showing as the previous version? Any idea’s why this might be happening? Am I missing a step?

Rgds,
Dil

You can create action and manually send new catalog to endpoints. See little ? icon on Catalog Upload page.

Thanks Michal - that worked a treat! All BES Clients now have the latest catalog uploaded with ILMT reporting the same. Thanks you so much for your support!

Rgds,
Dil

1 Like