Closed frazor closed 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.
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
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