[Hypercontent-users] Important code update improves long-term HC maintenance

[Alex V. <al...@bi...>]

Hi everyone,
	I have just checked a change into CVS that should remove a long-term  
HC server maintenance issue that everyone seems to run across  
periodically - that is a piling up of stale files in the bootstrap  
directory ".server-public-keys" which can lead to a general slow-down  
of most operations.

Please patch your servers with this update from CVS at your earliest  
convenience: the updated code is in the class

org.hypercontent.server.SecureStore

I would encourage you, of course, to deploy the update in a test  
environment first to make sure there are no unintended consequences!   
Especially make sure to test FTP/SFTP publishing that prompts the  
user for a username/password.  Should you discover any issues, please  
let me know.  I observed no problems in my own environment.

Note: this is NOT an urgent fix, but it is an important one for your  
long term stability and happiness!

-Alex


FAQ:

What is .server-public-keys?
	This directory is used to store encrypted flat-file databases that  
can be used to share data securely between active instances of  
HyperContent.  For example, if you have 2 or more HC instances  
running and start a publish job to an FTP server, the public key file  
is used to encrypt the FTP password into the instance secure DB so  
each instance has access to the password without leaving it  
vulnerable to discovery.  Each running HC instance holds the private  
key that can decrypt the password in memory, and a new key pair is  
created upon each restart.
	Even if you are running only a single instance, these files are  
still loaded and used, so don't think you'll be immune to the problem!

What causes the files to pile up here?
	During a normal shutdown, an instance of HC will delete its own  
public key and DB files from this directory.  However, if for any  
reason the shutdown is not graceful (e.g. kill -9, hard crash, etc),  
the files are left behind.  Over the course of 6 months to a year  
enough of these might accumulate to slow things down.

What is the solution?
	Until now, the only solution was to periodically manually check  
the .server-public-keys directory and remove any obviously stale  
files.  The new, automatic solution to this problem is for each  
instance to register a heartbeat by updating the last mod date of its  
public key every 5 minutes - if another instance detects that a key  
file has not been touched in 10 minutes, it will delete that key file  
and its associated db.  Thus HC is now self-maintaining in this  
regard.  In the unlikely event that an instance is still running but  
fails to update the last mod in time (e.g. if it temporarily loses  
network or SAN connectivity), and its key and DB are deleted by  
another instance, it will create itself a new key pair and db when it  
goes to register its heartbeat.