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.
|