Re: Updating fis-gtm package to 6.1
Hi Bhaskar,
On Fri, Feb 07, 2014 at 12:14:31PM -0500, Bhaskar, K.S wrote:
> >
> >[KSB] Since a GT.M release is frozen for all time once it's
> >released, one answer is as many releases as we have disk for.
> >Another answer is that although we periodically get e-mails from
> >people with five and ten year old releases, we normally consider
> >releases to have a two year window of peak use, and maintaining
> >three years' worth is a good number. That will probably translate
> >to about ten releases.
>
> [KSB2] GT.M users often have multiple GT.M releases installed on
> their systems. Here is a representative example: A system hosts
> the systems of record for the medical records of both Clinic A and
> Clinic B. Clinic A uses release 1 of GT.M, whereas Clinic B uses
> release 2 of GT.M (perhaps because Clinic B came online later and
> used the latest release of GT.M then available, whereas Clinic A
> never upgraded). Release 3 becomes available and has new
> functionality that both clinics want. Here is an upgrade scenario:
>
> * Set up replica of the production database of Clinic A with GT.M
> release 3 and real-time replication from the current instances to the
> new instance (so that if a patient record is updated on the Clinic A
> system of record in GT.M release 1, it shows up right away also in
> the replica using release 3). The replica of Clinic A is created by
> taking a backup of the release 1 instance and upgrading it - no
> dump/restore is required. Also, the two instances can share the same
> source code for the routines of Clinic A, but the object code for the
> same source code is different for each release.
> * Once satisfied that the replica of Clinic A on release 3 is stable,
> at convenient time, switch over so that the system of record on
> release 3 is replicating to the system of record on release 1. The
> switchover itself can be scripted and executes in seconds. After the
> switchover, in the event Clinic A on release 3 has issues, a simple
> switchover reverts Clinic A production to release 1.
> * Once satisfied that Clinic A on release 3 is stable, shut down
> replication to the release 1 instance, and eventually delete it.
> * Upgrade Clinic B the same way.
>
> In this representative scenario, there are three GT.M releases
> concurrently installed and in use on the system, with no change to
> the OS version.
Thanks for this verbose explanation.
Is this a vote to keep three fis-gtm versions at the same time inside a
Debian release? If I understood Luis correctly we are at first
targeting at some educational VistA installation. From your explanation
it seems to become clear that if you want to support a Clinic you
somehow need a support company that might perfectly profit from our
fis-gtm packages but the maintenance of all previous versions need to be
put on their shoulders. We should not try to push the burden on the
Debian release team / security team. That's simply not how Debian
works.
> As there is not a reliable way to automatically ensure that a GT.M
> release is no longer in use, we strongly recommend that a new GT.M
> release always be installed in a new directory.
I think this item became clear and we are using versioned dirs.
> Because bugs in GT.M are very infrequently encountered in
> production,
I'm sorry but as long as any software is not written by the magical good
of infallibility it will have bugs. So we need to be prepared to fix it
and we should try to keep the burden for people who need to do the
actual work at a bearable amount.
> Apropos the hard links issues, they are legitimate. The hard links
> are security related hard-links between a sub-directory and a parent
> directory. The subdirectory is created as part of the GT.M
> installation and is thus never on a different filesystem. Please do
> not replace them with soft-links, and instead flag them as
> legitimate.
While I personally do not see the drawback of softlinks and I have no
idea in how far a hard-link might be more secure than a soft-link we
might use a lintian override. Thanks for the clarification.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: