Linux 7.2.0 agent not reporting back to the Enterprise Console

Hi,

If you look on the management server in the issued certificates log file, do you see 2 entries for the Linux machine?  To know this would be useful.  Otherwise, you need to trace the cert request messages from the router logs on the client to the router logs on the server.  This would be a good place to start.

Thanks,

Jak

Thanks for the info Jak.  Support wrote back and had me make some modifications to files in the RMS directory on the end point and restart the sav-rms service.  This supposedly removed my old cert and requested a new one.  The client is still greyed out but I can see the requests in the log file for new certificates with the current date and time.  I only saw an entry in the log from the initial install and now since the old cert is invalid.

The machine in question has never been managed, it had the stand alone version of SAV prior to getting 7.2.x installed.

Regards,

Jim

Jak,

I may have misunderstood your request. I see the Received Message request, a Sent Unique token message And Acknowledged message, Issued public key certificate, sent certificate and a final acknowledge message.

Jim

Hi Jim,

I can tell you how the certification bootstrap works on Windows and as far as I know there aren't many differences other than the registry is emulated using text files on Linux.

1. Setup.exe copies cac.pem (the certification managers public key) and mrinit.conf to the Remote Management System directory of the client.  Mrinit.conf is short for message router config and contains the configuration settings the router will have when the information is transferred into the registry (on Linux text files). This includes the address of the parent message router, port numbers and some identity keys. Cac.pem is also transferred into the registry by the install.  So once done, mrinit.conf and cac.pem as files are no longer used by the client, the registry values are.

2. The RMS packages is installed by AutoUpdate and the information in cac.pem and mrinit.conf is added to the registry by an installer helper exe called clientmrinit.exe.  

3. The message mouter on the client starts up at this point without any certificates and is therefore not trusted on the system.  It reads the ParentAddress and parent ParentPort number values from the registry/config files, these tell it to make a connection to: <server>:8192

4. The router reads the IOR string from the server, i.e. <server>:8192.  This string essentially tells the client on which port and IP address to connect back on, by default this should be: <ServerIP>:8194.

5. The client message  router now makes a connection to 8194 of the server, logs on to the certification interface of the parent router and requests a token: the token is a unique number issued by the certification manager on the server.  This number is to ensure that when setup, the client router has a unique name in the system as the rest of the name comprises the machine name. As there could be 2 machines in the system with the same name, this token ensures each system has a unique RMS address.

6. Once the client router has the token, it requests a certificate for the router.  It makes the cert request and then polls for it on the short poll interval.  If the client router has received a certificate you will see a pkc and pkp value under the router section of the registry or config file on Linux. This is the second step in a 3 step process.  The first being the token request and the third being the certificate for the agent.

7.  Now the router has a certificate, it can host a local IOR for the local management agent to connect to and start its certification procedure.  This behaves as the client router did to get a certificate, it reads the IOR of the local router in this case, sees the IP and port it needs to connect to (8192) and asks the router on the client to essentially get it a certificate (Note: the local agent doesn’’’’t need a token as it is made unique in the system by the router name which is unique).  

The client router requests a certificate on behalf of it’’’’s local agent, the server router receives the request, the CM is logged on to the server router, sees the request and issues a certificate.  At this point you see the second entry in the issued certificate log file on the server for this client.  The first being for the router, the second for the agent.  The server router then attempts to send the agents certificate to the client router. It is worth noting at this point the server router is trying to connect to port 8194 of the client, if this is unable to occur, e.g. firewall on the client, this part of the process is delayed until the client router polls the server to check for outstanding messages.  

8. One the client is sent the certificate or the agent receives it via polling the server, you should see a pkc and pkp entry under the management agent part of the registry or in the text files on Linux.  At this point the agent can then log onto the local message router as an agent, gather status from all the components it is managing and sent is a status message back to the management server.

It is this status messages that provides all the information about the machine in SEC but it can only be sent when the client router and agent have certificates.

I hope this brief outline of the steps gives you things to check.  In summary:

1. Ensure port 8192 and 8194 are open on the management server

2. Ensure port 8194 is open on the client (this will speed up downstream message delivery)

3. Check there is at least 2 entries in the Issued Cert log on the server for each client.

4. Check that the router and agent on the client both have a pkc and pkp pair.

The following article:

http://www.sophos.com/support/knowledgebase/article/36337.html

details the key names and adds a little more detail regarding each.

Good luck

Jak