On 02/11/2014 04:35 PM (US Eastern Time), Thorsten Alteholz wrote:
On Tue, 11 Feb 2014, Bhaskar, K.S wrote:
Dominique's suggestion makes sense. There's no issue changing the
latest release and having fis-gtm reflect that, so that someone
installing fis-gtm always gets the latest release. My concern is just
to make sure that installing the latest release when fis-gtm is
updated should not delete prior releases already on the system.
So for testing the user needs to install the versionless package
fis-gtm and such will get updates and informations about problems with
the current versions.
With respect to Thorsten's question about security and grave bugs: So
far, we have been lucky and to date have never had a grave bug that
caused us to withdraw a release.
This is good to hear, but now we need to agree on the meaning of grave
:-).
According to https://www.debian.org/Bugs/Developer#severities a grave
bug can cause data loss. So you never had such a bug? Everybody could
use the version from oldstable forever and will just miss some new
features? Anyways, if this would happen, would you (as upstream)
provide patches for older versions?
[KSB] This is a difficult one to answer. I went through release notes
for releases going back to 2007 checking for bugs we fixed that could
cause data loss. There were a few that pertained to the REORG
(defragmentation) operation if it was run while applications were
actively using and updating the database. We did not patch existing GT.M
releases, since the workaround was to run the reorg when there were not
active users on the system, or to to run reorg (databases tend not to get
fragmented in normal use except under certain pathological access
patterns). We did have one fix to a bug that could cause data loss, but
it was an edge case encountered in our own test environment and never
encountered in a user site. It was fixed in a subsequent release. I
personally cannot remember any production site where the root cause of a
data loss was a GT.M bug. We do expect sites to set up GT.M applications
correctly, e.g.:
* We do expect sites running databases containing data that they care
about to run with journaling turned on (and use replication,
depending on the specific need). If you are running without
journaling, and the system crashes, your database may be very
difficult to recover manually. But if you are running with
before-image journaling, GT.M automatically recovers the database,
with journal records that have been committed to disk. [In the event
of a system crash, anything in flight that is still in memory is of
course lost. GT.M has transaction processing functionality for
situations when transaction Durability is a must, and in those cases
will not move past a TCommit command until it has done an fsync to
disk. This is how online financial transactions are handled by the
FIS Profile core banking application built on GT.M.]
* We do expect sites running applications with databases that have data
they care about to make sure they don't run out of space, especially
in the journal file system. And as added protection, we do expect
sites that cannot guarantee that they are monitoring the space so
that they don't run out of it to use functionality in GT.M that
freezes updates when you run out of space.
* We do expect sites to not randomly kill shared memory segments and
randomly kill processes with kill -9. [GT.M has logic that tries to
recover after a process is terminated with a kill -9, but that logic
cannot unconditionally recover.]
So, while it is possible to set up a database and lose data, if you set
it up correctly (and we have a lot of training material), you should
expect to never lose data. GT.M even tries to protect itself against its
own bugs by detecting and cleaning up out of design conditions.
With respect to security issues, we have had two
security issues in the last so many years (actually, one issue in
2007, followed by a second because the fix for the first issue was not
complete). As the vulnerability was not in the GT.M core, we were able
to distribute a fix that wrapped & isolated the vulnerable component
and could be retrofitted to existing installations of older releases.
Ok, in such a rare case you will provide the needed patches or
workarounds for all versions in Debian?
[KSB] It is hard for me to generalize from such a small sample. Our
action would depend on the nature of the vulnerability, the nature of the
fix and the nature of the workaround. So, while we can promise to take
security seriously (and we have to, because GT.M today is the database of
record for well over a hundred million bank accounts around the world),
we can't promise a solution without knowledge of a problem it must solve.
Regards
-- Bhaskar
Thorsten
--
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
