archiver-appliance / epicsarchiverap

This is an implementation of an archiver for EPICS control systems that aims to archive millions of PVs.
Other
39 stars 38 forks source link

Very strict hostname check at startup #50

Closed frazor closed 6 years ago

frazor commented 6 years ago

Hi there, I'm writing to you to ask regarding a startup error I'm seeing in the appliance. The appliance compares the hostname from appliance.xml with the hostname from getCanonicalHostname(). Now, in the case below, the hostname appears with and without FQDN (in my case, mainly due to the order in which fqdn and short name was entered in the local hosts file), and I just wonder if this isn't a bit too aggressive on the name matching. Is there an explanation as to the need for this strict name matching in the archiver appliance?

Best regards, Fredrik / European Spallation Source

HTTP Status 500 - The config service for this installation did not start up correctly. Please check the logs for any exceptions or FATAL errors. The hostname from appliances.xml is ics-archiver11.ics.esss.lu.se and from a call to InetAddress.getLocalHost().getCanonicalHostName() (typially FQDN) is ics-archiver11. These are not identical. They are probably equivalent but to prevent multiple appliances binding to the same identity we enforce this equality. org.epics.archiverappliance.config.exception.ConfigException: The hostname from appliances.xml is ics-archiver11.ics.esss.lu.se and from a call to InetAddress.getLocalHost().getCanonicalHostName() (typially FQDN) is ics-archiver11. These are not identical. They are probably equivalent but to prevent multiple appliances binding to the same identity we enforce this equality.

slacmshankar commented 6 years ago

I just wonder if this isn't a bit too aggressive on the name matching. Is there an explanation as to the need for this strict name matching in the archiver appliance

I think this was intended to minimize a couple of catastrophic configuration issues -

1) To avoid the cut & paste error of folks forgetting to set the ARCHAPPL_MYIDENTITY correctly for a cluster. If more than one appliance starts up with the same ARCHAPPL_MYIDENTITY, then you could potentially have two appliance writing to the same LTS files and thus corrupting the data.

2) To avoid folks building a cluster with localhost; which could lead to "split brain" conditions.

You are probably right in that this is probably a bit aggressive; but I wanted to completely eliminate the first case and this was one mechanism I could think of...

Regards,

Murali


From: Luthander notifications@github.com Sent: Monday, March 26, 2018 5:55:22 AM To: slacmshankar/epicsarchiverap Cc: Subscribed Subject: [slacmshankar/epicsarchiverap] Very strict hostname check at startup (#50)

Hi there, I'm writing to you to ask regarding a startup error I'm seeing in the appliance. The appliance compares the hostname from appliance.xml with the hostname from getCanonicalHostname(). Now, in the case below, the hostname appears with and without FQDN (in my case, mainly due to the order in which fqdn and short name was entered in the local hosts file), and I just wonder if this isn't a bit too aggressive on the name matching. Is there an explanation as to the need for this strict name matching in the archiver appliance?

Best regards, Fredrik / European Spallation Source

HTTP Status 500 - The config service for this installation did not start up correctly. Please check the logs for any exceptions or FATAL errors. The hostname from appliances.xml is ics-archiver11.ics.esss.lu.se and from a call to InetAddress.getLocalHost().getCanonicalHostName() (typially FQDN) is ics-archiver11. These are not identical. They are probably equivalent but to prevent multiple appliances binding to the same identity we enforce this equality. org.epics.archiverappliance.config.exception.ConfigException: The hostname from appliances.xml is ics-archiver11.ics.esss.lu.se and from a call to InetAddress.getLocalHost().getCanonicalHostName() (typially FQDN) is ics-archiver11. These are not identical. They are probably equivalent but to prevent multiple appliances binding to the same identity we enforce this equality.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/slacmshankar/epicsarchiverap/issues/50, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACeVsh0WzVjjJMyf0OXVikt5jE6fWrZYks5tiOU6gaJpZM4S7Efm.

frazor commented 6 years ago

Hi Murali,

thank you for your swift reply. I understand your concern that those scenarios should never happen. At this point in time I'm not sure there's any proposal to lessen the checks in place, we were mainly curious as to the background of it. Closing the issue for now, will reopen in case we want to discuss a different approach. Best regards, Fredrik/ESS