Unable to access /fog/token.dat file

[rmishra1004]

O.S: CentOS 7
Fog Version: 1.5.8

The Fog server is behind a firewall, thus we have requested the ports 80 443 21 3306 2049 20048 111 138 139 445 to be open, but it seems that there is still a blockage while trying to access the token.dat file.

FirewallD and IPTables are disabled on the Fog Server.

Could you please let us know how can we access this file from the network.

[Kiweegie]

Hi @rmishra1004

there are quite a few hits in the forum for this issue. I’d suggest searching there first as it seems to have happened to others and fixes suggested.

Start here or here.

regards Tom

[Sebastian Roth]

@rmishra1004 While @Kiweegie’s suggestion on searching the forum is definitely a great hint I might a bit of information as well.

The message “Could not find file … token.dat” is more or less a warning. See the line above the yellow marked lines… “this is expected…”.

The key error message in this case is “Private key path not found”. First run ls -al /opt/fog/snapins/ssl/ on your FOG server and post output here. As well check the storage node settings in the FOG web UI. Pay attention to the value of SSL Path. Is it set to the correct path?

Note: this is not something you’d need to fiddle with in a “normal” install situation. So there must be something customized or tinkered with that would cause this issue.

[rmishra1004]

@Sebastian-Roth The path for the storage node on Fog UI seems correct i.e. /opt/fog/snapins/ssl/

Here is the response of

ls -al /opt/fog/snapins/ssl/
total 16
drwxrwxrwx 3 fogproject apache   78 Nov  7 11:50 .
drwxrwxrwx 3 fogproject apache   16 Nov  7 11:50 ..
drwxrwxrwx 2 fogproject apache   51 Nov  7 11:50 CA
-rwxrwxrwx 1 fogproject apache   96 Feb 24 14:41 ca.cnf
-rwxrwxrwx 1 fogproject apache 1679 Feb 19 12:59 fog.csr
-rwxrwxrwx 1 fogproject apache  231 Feb 19 12:59 req.cnf
-rwxrwxrwx 1 fogproject apache 3243 Feb 19 12:59 .srvprivate.key

What specific port is used to handshake the token.dat file such as 443 or 80? It seems like a firewall issue with our network people.

[Sebastian Roth]

@rmishra1004 said in Unable to access /fog/token.dat file:

The path for the storage node on Fog UI seems correct i.e. /opt/fog/snapins/ssl/
Here is the response of
ls -al /opt/fog/snapins/ssl/

Hmmm, from what you posted this seems to be all fine. Can you take a picture/screenshot of the web UI setting just to make absolutely sure. Sometimes more eyes can stop what’s wrong. The other thing that comes to my mind is that there might be a hidden space character at the end or something like that?!

Just to make sure, you have SELinux disabled on that server?

What specific port is used to handshake the token.dat file such as 443 or 80? It seems like a firewall issue with our network people.

As you see in the logs it uses http://… so it’s port 80 and nothing else for this communication.

[rmishra1004]

@Sebastian-Roth

[Sebastian Roth]

@rmishra1004 Sorry for the delay. I have looked at this a couple of times now but just can’t see why you’d get the error.

@Tom-Elliott Would you have an idea on this one?

[Tom Elliott]

@Sebastian-Roth the token.dat file is not an issue as when the fog-client initially loads it looks to authenticate with the fog server. During that first look, the token.dat file doesn’t exist. I’m just replying so people know I am looking into things, but haven’t yet read through all the posts.

That being said the issue seems to be the private key the client is looking for is not the created on the local machine. So there’s no encryption being made at the client side. Will update once I have a better understanding of the problem in whole.

[Tom Elliott]

@Sebastian-Roth I have reviewed and still unsure what would be causing this. The file seems to exist and has correct ownership and, maybe over the top, permissions so no real reason for it to be failing this way.

I suppose we could try moving the SSL files into the /var/www/fog path and update entry on the related storage node.

I’m not entirely sure on the config though.

For example if the listing we see is for storage node ip is ( example only of course ) 192.168.1.1 and the fog client is looking for the key on 192.168.1.2, if .2 doesn’t have the key generated for it then that could explain the issue.

I hope, and no offense meant OP, that this client is looking at the same machine we have the directory listing for.

[JJ Fullmer]

@rmishra1004 is this happening on all hosts or just this one? Have you tried hitting the ‘reset host encryption keys’ on the host in the webgui?
If you copy past the url that fails, what happens? I believe you should see an error message like this

{"error":"im"}

when going to it in a browser