Subject | Re: Security patches - How? |
---|---|
Author | Adam |
Post date | 2007-02-06T23:03:52Z |
--- In firebird-support@yahoogroups.com, "wiesn" <johanneskonert@...>
wrote:
tracker on the firebirdsql.org website and also third party trackers.
1.x http://secunia.com/product/1449/
2.x http://secunia.com/product/11516/
You may want to also consider tracking security issues reported on
Interbase 6, an the ancestor of Firebird 1.0
is probably the pdfs. This is probably smaller than the update patches
you speak of.
it is just a case of uninstall and reinstall (which takes about 30
seconds). Otherwise, you will need to perform a backup-restore the
database(s).
a backup database server while you upgrade the main one. The effort
you go to here just depends on how much downtime is acceptable.
But ....
Your database server should never be exposed to the internet. This is
standard industry practice, and mitigates probably 99% of the attack
vectors. You could install a firewall between your web server and your
database server and only forward 3050 to the database server, and only
if it is coming from the IP address of your web server (if you rely on
events, you may need a secondary port).
If your web front end talks to an application server which in turn
talks to the database server, then it is even better.
sure that any benchmarks used are not related to Superserver which can
only make use of a single core at a time.
But most results are going to vary depending on the queries you run
and the concurrent attempts you try (and for MySQL the storage engine
you choose). You should develop your own tests, or at least use tests
that closely relate to the sorts of queries you run most frequently.
Depending on which tests you run, you could say that any one of the
three is fastest.
Adam
wrote:
>Generally speaking, the release notes but there is also an issue
> Dear Firebird experts,
> I am currently evaluating the different available DB-Systems and did
> not find exact information about
> - where security updates and issues about firebird are anounced
tracker on the firebirdsql.org website and also third party trackers.
1.x http://secunia.com/product/1449/
2.x http://secunia.com/product/11516/
You may want to also consider tracking security issues reported on
Interbase 6, an the ancestor of Firebird 1.0
> - how they are fixed (means: will there be a patch or a "new" versionNew version. The installer itself for 2.0 is only 4MB, most of which
> to download)
is probably the pdfs. This is probably smaller than the update patches
you speak of.
> - how to apply security fixes? (means: Can we simply exchange theUnless the ODS must change (on disk structure of the database file),
> install-dir with the new fixed version or is a dump/re-import
> necessary)..how quick will that update be done on a "hot" webserver
> installation?
it is just a case of uninstall and reinstall (which takes about 30
seconds). Otherwise, you will need to perform a backup-restore the
database(s).
> The Web-DB has definitely to be down during update/patchIt depends what you mean by down. You could certainly replicate it to
> time, right?
a backup database server while you upgrade the main one. The effort
you go to here just depends on how much downtime is acceptable.
But ....
Your database server should never be exposed to the internet. This is
standard industry practice, and mitigates probably 99% of the attack
vectors. You could install a firewall between your web server and your
database server and only forward 3050 to the database server, and only
if it is coming from the IP address of your web server (if you rely on
events, you may need a secondary port).
If your web front end talks to an application server which in turn
talks to the database server, then it is even better.
> Thanks you for your help.Firebirds SMP server mode is 'Classic Server'. You will need to make
> And....are there any performance benchmarks for
> multi-prozessor-systems comparing Firebird with e.g. MySql or Postgres ?
sure that any benchmarks used are not related to Superserver which can
only make use of a single core at a time.
But most results are going to vary depending on the queries you run
and the concurrent attempts you try (and for MySQL the storage engine
you choose). You should develop your own tests, or at least use tests
that closely relate to the sorts of queries you run most frequently.
Depending on which tests you run, you could say that any one of the
three is fastest.
Adam