@jason-alexander
Forum Replies Created
-
AuthorReplies
-
September 30, 2014 at 7:37 pm in reply to: Help – Explanation of Post-Xlate Queue Depth Alert? #81333
Thanks, James. That was my suspicion but I had not had a chance to confirm it and that was exactly the information I needed.
Yup, verified unique as part of the initial build. We’ve run into that before so we have that step as part of our build process. Field length of 8 still results in a panic. Sorry for not being more explicit about that in the original post. Jeff, contact me at jalex@u.washington.edu and I will send you a copy of the modified cl_check_ack that we use. We worked with Charlie 15 years ago to add this functionality back in 3.3. and have been carrying it forward since then including the upgrade to the new ack handling routines.
For charges we still strongly recommend using extremely long or even infinite timeouts as knowing when you have sent two copies of a message due to timeout doesn’t really save you anything once Epic has processed both copies of the message anyway. As a result I would not call even our code a solution for charges.
It’s not clear to me which piece is actually acting as the server for the connection but it should not matter. Regardless, the ssh connection handling should be handled by a protocol layer, just like the TCP layer of the OS handles your TCP connections.
In other words, the SSH keys are in use by the protocol layer in whatever OS you are on and not by the Cloverleaf engine itself.
I’m going to venture a guess that your failover uses name/IP swapping so that your remote hosts don’t have to change the configuration of any of their clients. That means that they’re going to try connecting to you using exactly the same credentials (i.e. combination of hostname/IP and SSH key) after you fail over. This will (and *should*) fail unless you take explicit steps to make it work. From the client’s point of view this looks exactly like a man-in-the-middle attack so you *want* it to fail unless you know exaclty what happened.
In the case of a failover, you know what happened and you want them to be able to connect to this new box so you want to configure it to accept exactly the same credentials. In a UNIX environment that’s trivial. You take the entire .ssh directory from the host and account(s) that have been working and you copy them exactly to the new host in the same accounts. You can do functionally the same thing on a Windows environment and I believe that it is almost as easy but I am not familiar with the process. This matches the suggestion that your Server group gave.
The risk is fairly straight forward and it has everything to do with what SSH keys are and nothing to do with Cloverleaf. An SSH key is literally the key to your front door. You have two machines and if you set them up to use the same keys then if one machine is compromised the other is automatically compromised as well. Other than that, in the Unix environment at least, SSH doesn’t care if you connect from your primary to your standby even if the keys are the same. It doesn’t ask “so, is the key I am sending the same as the key I would accept” or anything like that.
How long are you allowing it to hang?
The engine allocates the memory for and then reads the messages and it does this before it does anything else, including responding to the command you ran. For particularly large message volumes or particularly large messages (our rule of thumb has always been about 500kb although that was strictly empirical) you can expect an hcicmd or the testing tool to time out before the read is complete.
David Barr from MedStar Health out in Maryland was kind enough to send me the following proc to do what is needed. You need to pass in the delimiter list as well as the string to process.
######################################################################
# Name: unescape_HL7
# Purpose: Remove HL7 escape sequences and replace them with
# the actual characters represented (including escaped
# hexadecimal values)
# Args: Two strings required
# input – the actual string to be unescaped
# delimiters – the delimiters as foudn in MSH-1 and MSH-2
#
# Comments:
proc unescape_HL7 { input delimiters } {
set delim_f [string range $delimiters 0 0]
set delim_s [string range $delimiters 1 1]
set delim_r [string range $delimiters 2 2]
set delim_e [string range $delimiters 3 3]
set delim_t [string range $delimiters 4 4]
set output “”
while {[ string length $input ]} {
set char [string range $input 0 0]
set input [string range $input 1 end]
#echo processing $char
if { [string equal $char $delim_e] } {
set esc “”
set char [string range $input 0 0]
set input [string range $input 1 end]
while {![string equal $char $delim_e]} {
append esc $char
set char [string range $input 0 0]
set input [string range $input 1 end]
}
#echo “escape sequence: $esc”
switch -exact [string range $esc 0 0] {
“F” {
append output $delim_f
}
“E” {
append output $delim_e
}
“S” {
append output $delim_s
}
“T” {
append output $delim_t
}
“R” {
append output $delim_r
}
“X” {
scan [string range $esc 1 end] “%x” x
append output [format “%c” $x]
}
default {
#echo unknown escape sequence $esc
}
}
} else {
append output $char
}
}
return $output
}
The issue that I am running into is that they have generated the file in such a way that you cannot do pattern matching. The string that taught me this painful lesson was M>teYESSEX0D\X0A
No way to order your decoding of the escape sequences (if you’re pattern matching) so that this decodes correctly. It’s got to be done by reading the string character-at-a-time and decoding escape sequences as they occur.
April 6, 2005 at 11:48 pm in reply to: Looking for information about GE Muse results encoding #56275More information now apparent… Instead of converting everything to hexadecimal (which would allow one-pass decoding) they converted some things to hexadecimal and some to standard HL7 escape sequences. Now all I have to do is figure out what order to decode things in so that the files come out clean.
-
AuthorReplies
