mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
I spotted something strange and immediately installed a routine to automatically impose an iptables block when the key used for database access is excessively long.
My URL was something like this
...../...../.....php?key=123456
The injection was something like this
...../...../.....php?key=876711111111111111111111111111' UNION SELECT 13,CONCAT([X],count(*),[X],13,13,13,13,13,13 FROM information_schema.TABLES WHERE `TABLE_NAME` LIKE "%wp_users%" -- /* order by 'as
There are no user permission on information_schema.
There seems to be 2 versions of the coding floating around on Austrian and Russian IPs. One is ineffective but the other works. It seems the author is expert in the intricate structure and design of SQL.
Am 24.03.2016 um 04:21 schrieb Always Learning centos@u64.u22.net:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
Current version on C5 is mysql55, 5.0 does not get any updates anymore!
-- LF
On 03/24/2016 03:54 AM, Leon Fauster wrote:
Am 24.03.2016 um 04:21 schrieb Always Learning centos@u64.u22.net:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
Current version on C5 is mysql55, 5.0 does not get any updates anymore!
Let me reiterate this:
the mysql-5.0.95* packages are not supported. A very long time ago, Red Hat upgraded mysql for el5 to an SCL. The current supported version is:
mysql55-mysql-5.5.45-1.el5*
I guarantee that the 5.0.95 packages have security issues. Here is how to move to the newer mysql55 packages:
I can't stress enough, mysql-5.0 on el5 is absolutely not updated security wise. The last update to it happened on 22-Jan-2013 and was in CentOS-5.9 .. we are now in 5.11 and there have been upgrades to mysql55 since then to fix security issues.
Here is more info on this MySQL 5.0 to 5.5 upgrade, that was required starting in CentOS 5.10.
Thanks, Johnny Hughes
On 03/24/2016 10:48 AM, Johnny Hughes wrote:
On 03/24/2016 03:54 AM, Leon Fauster wrote:
Am 24.03.2016 um 04:21 schrieb Always Learning centos@u64.u22.net:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
Current version on C5 is mysql55, 5.0 does not get any updates anymore!
Let me reiterate this:
the mysql-5.0.95* packages are not supported. A very long time ago, Red Hat upgraded mysql for el5 to an SCL. The current supported version is:
mysql55-mysql-5.5.45-1.el5*
I guarantee that the 5.0.95 packages have security issues. Here is how to move to the newer mysql55 packages:
I can't stress enough, mysql-5.0 on el5 is absolutely not updated security wise. The last update to it happened on 22-Jan-2013 and was in CentOS-5.9 .. we are now in 5.11 and there have been upgrades to mysql55 since then to fix security issues.
Here is more info on this MySQL 5.0 to 5.5 upgrade, that was required starting in CentOS 5.10.
This shoule not be news to anyone .. it was in the CentOS-5.10 release notes:
https://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.10
(first two bullets in 'New Features' section)
There were also discussions on this list:
https://lists.centos.org/pipermail/centos/2013-October/137939.html
Thanks, Johnny Hughes
On Thu, 2016-03-24 at 10:48 -0500, Johnny Hughes wrote:
I guarantee that the 5.0.95 packages have security issues. Here is how to move to the newer mysql55 packages:
I can't stress enough, mysql-5.0 on el5 is absolutely not updated security wise. The last update to it happened on 22-Jan-2013 and was in CentOS-5.9 .. we are now in 5.11 and there have been upgrades to mysql55 since then to fix security issues.
Here is more info on this MySQL 5.0 to 5.5 upgrade, that was required starting in CentOS 5.10.
Thanks. Reading it now.
On Thu, Mar 24, 2016 at 9:08 AM, Always Learning centos@u64.u22.net wrote:
I can't stress enough, mysql-5.0 on el5 is absolutely not updated security wise.
Thanks. Reading it now.
Just to be clear: you absolutely should upgrade to a currently maintained version of MySQL.
However, upgrading will not protect you from SQL injection attacks. The probes you're seeing aren't targeting the SQL server. They're targeting your php code.
On Thu, 2016-03-24 at 09:40 -0700, Gordon Messmer wrote:
Just to be clear: you absolutely should upgrade to a currently maintained version of MySQL.
Agreed. Its going to be rainy in England this Easter weekend, so am contemplating upgrading the last production C5 to C6.
However, upgrading will not protect you from SQL injection attacks. The probes you're seeing aren't targeting the SQL server. They're targeting your php code.
Have already upgraded my PHP routine which blocks IP addresses when GET data exceeds its acceptable field size.
On 03/23/2016 08:21 PM, Always Learning wrote:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
I spotted something strange and immediately installed a routine to automatically impose an iptables block when the key used for database access is excessively long.
My URL was something like this
...../...../.....php?key=123456
The injection was something like this
...../...../.....php?key=876711111111111111111111111111' UNION SELECT 13,CONCAT([X],count(*),[X],13,13,13,13,13,13 FROM information_schema.TABLES WHERE `TABLE_NAME` LIKE "%wp_users%" -- /* order by 'as
There are no user permission on information_schema.
There seems to be 2 versions of the coding floating around on Austrian and Russian IPs. One is ineffective but the other works. It seems the author is expert in the intricate structure and design of SQL.
Always use parameterized statements (aka prepared statements) for SQL that involves untrusted input.
I like to use them even for input that involves trusted input because it is easy to make a change in my code and not think about how it impacts the parameters.
-=-
This is an attack on WordPress ??? Or just trying to get WordPress database from a different app?
Be careful with WordPress - it's database handler doesn't actually use parameterized statements, it emulates them with printf - one (of many) reasons I do not like the product.
If it is not an attack on WordPress directly - your WordPress database should be using a different uname/pass from anything else, so actual queries for data should fail.
Be careful with WordPress - it's database handler doesn't actually use parameterized statements, it emulates them with printf - one (of many) reasons I do not like the product.
This is a rather controversial statement. There's nothing wrong with using sprintf when building sql queries. Besides
"Using a prepared statement is not always the most efficient way of executing a statement. A prepared statement executed only once causes more client-server round-trips than a non-prepared statement."
On 03/24/2016 04:53 AM, Александр Кириллов wrote:
Be careful with WordPress - it's database handler doesn't actually use parameterized statements, it emulates them with printf - one (of many) reasons I do not like the product.
This is a rather controversial statement. There's nothing wrong with using sprintf when building sql queries. Besides
"Using a prepared statement is not always the most efficient way of executing a statement. A prepared statement executed only once causes more client-server round-trips than a non-prepared statement."
The only time database has ever been a bottleneck for me is when I am not using something like apcu to cache query results. Use of prepared statements is slower for single queries never repeated but not the bottleneck in any application I've dealt with.
WordPress lack of genuine prepared statements has however caused me issues when I would like to make a query that is used more than once with different parameters.
On Thu, 2016-03-24 at 04:08 -0700, Alice Wonder wrote:
Always use parameterized statements (aka prepared statements) for SQL that involves untrusted input.
I like to use them even for input that involves trusted input because it is easy to make a change in my code and not think about how it impacts the parameters.
-=-
This is an attack on WordPress ??? Or just trying to get WordPress database from a different app?
Be careful with WordPress - it's database handler doesn't actually use parameterized statements, it emulates them with printf - one (of many) reasons I do not like the product.
If it is not an attack on WordPress directly - your WordPress database should be using a different uname/pass from anything else, so actual queries for data should fail.
I write my own database applications (each has its own unique user-id and password and only essential permissions on tables) and do not use any packaged solution. Thus no Wordpress or anything like it.
The hacker tried many variants like this - which baffle me.
' UNION SELECT (-x1-Q-,-x2-Q-,-x3-Q-,-x4-Q-,-x5-Q-,-x6-Q-)
' UNION SELECT 1,CONCAT(ddd,[X],file_priv,[XX],3,4,5,6,7,8 FROM mysql.user limit 0,1 (I do not have mysql.user)
' UNION SELECT 13,CONCAT([X],count(*),[X],13,13,13,13,13,13 FROM information_schema.TABLES WHERE `TABLE_NAME` LIKE "%wp_users%" -- /* order by 'as
LIKE "%user%" LIKE "%usr%" LIKE "%phpbb%" LIKE "»%" LIKE "m%" LIKE "%member%" LIKE "%forum%" LIKE "%reg%" LIKE "%moder%" LIKE "%ftp%" LIKE "%jos%" LIKE "¬ces%" LIKE "%wso%"
Am 24.03.2016 um 09:54:11 +0100 schrieb Leon Fauster:
Current version on C5 is mysql55, 5.0 does not get any updates
anymore!
Thank you. That server is the last production server on C5. I need to shift it to C6 and Maria 10.
I am 'always learning' security is a perpetual task. Thankfully I always read the daily logs and reports (an arduous task).
Many thanks.
On 03/24/2016 07:33 AM, Always Learning wrote: *snip*
Thank you. That server is the last production server on C5. I need to shift it to C6 and Maria 10.
I am 'always learning' security is a perpetual task. Thankfully I always read the daily logs and reports (an arduous task).
Many thanks.
I would shift to CentOS 7.
Always deploy the latest version of CentOS unless you know something you have absolutely will not work in it.
That's my philosophy.
That doesn't mean I upgrade as soon as a new version comes out, though I frequently do simply because there are advantages with the new versions of software.
On Thu, 2016-03-24 at 08:00 -0700, Alice Wonder wrote:
I would shift to CentOS 7.
With the, among others, systemd controversy I dread moving to C7. C6 works well and having just one version of an operating system simplifies everything. I also lack sufficient time to exploring and learning the C7 differences and changes of operational logic.
C6 is, from my perspective, very similar to C5. C7 is not.
This is obviously an application level problem. What is this php file? You should upgrade wordpress and remove or block access to the plugin or custom page which allows sql injections.
On Thu, 2016-03-24 at 14:27 +0300, Александр Кириллов wrote:
This is obviously an application level problem. What is this php file? You should upgrade wordpress and remove or block access to the plugin or custom page which allows sql injections.
Yes, my mistake. I should have imposed strict controls on the length of parameters passed to programmes via web pages $_GET[] such as:-
UNION SELECT CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45),CHAR(45,120,51,45,81,45),CHAR(45,120,52,45,81,45),CHAR(45,120,53,45,81,45),CHAR(45,120,54,45,81,45),CHAR(45,120,55,45,81,45),CHAR(45,120,56,45,81,45),CHAR(45,120,57,45,81,45),CHAR(45,120,49,48,45,81,45),CHAR(45,120,49,49,45,81,45),CHAR(45,120,49,50,45,81,45),CHAR(45,120,49,51,45,81,45),CHAR(45,120,49,52,45,81,45),CHAR(45,120,49,53,45,81,45),CHAR(45,120,49,54,45,81,45),CHAR(45,120,49,55,45,81,45),CHAR(45,120,49,56,45,81,45),CHAR(45,120,49,57,45,81,45),CHAR(45,120,50,48,45,81,45),CHAR(45,120,50,49,45,81,45),CHAR(45,120,50,50,45,81,45),CHAR(45,120,50,51,45,81,45) -- /*
and reject any incoming string containing ' or " in addition to PHP's strip_tags and (deprecated in later versions) mysql_real_escape_string($_GET['....'],$link);
I do not use Wordpress or anything like it.
On 03/24/2016 07:57 AM, Always Learning wrote:
I should have imposed strict controls on the length of parameters passed to programmes via web pages $_GET[] such as... and reject any incoming string containing ' or " in addition to PHP's strip_tags and (deprecated in later versions) mysql_real_escape_string($_GET['....'],$link);
No. No. Nooooooooo.
You're missing the point that everyone is trying to communicate to you. Do not use string concatenation. Do not use sprintf. Do not use mysql_real_escape_string().
Use prepared statements. http://php.net/manual/en/mysqli.quickstart.prepared-statements.php
On Thu, 2016-03-24 at 09:18 -0700, Gordon Messmer wrote:
On 03/24/2016 07:57 AM, Always Learning wrote:
I should have imposed strict controls on the length of parameters passed to programmes via web pages $_GET[] such as... and reject any incoming string containing ' or " in addition to PHP's strip_tags and (deprecated in later versions) mysql_real_escape_string($_GET['....'],$link);
No. No. Nooooooooo.
You're missing the point that everyone is trying to communicate to you. Do not use string concatenation. Do not use sprintf. Do not use mysql_real_escape_string().
I have never (not once) used non-prepared SQL statements, nor string concatenation, nor sprintf.
mysql_real_escape_string() is useful for storing in tables words with apostrophes.
On 03/24/2016 10:13 AM, Always Learning wrote:
I have never (not once) used non-prepared SQL statements, nor string concatenation, nor sprintf.
Perfect!
mysql_real_escape_string() is useful for storing in tables words with apostrophes.
You shouldn't need to escape anything if you're using prepared statements.
On Wed, March 23, 2016 10:21 pm, Always Learning wrote:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
I spotted something strange and immediately installed a routine to automatically impose an iptables block when the key used for database access is excessively long.
Indeed. There are several flaws in how mysql handles data. This is why to the best of my ability I am trying to avoid mysql, and use postgresql if whatever chunk of software I need is designed to work also with postgresql. And I recommend developers I work with/for the same (to use postgresql). These are good examples:
https://www.youtube.com/watch?v=1PoFIohBSM4
I know, this may inflame [***]SQL wars here, but I hope, this will help somewhat those who are not married to mysql (yet).
Just my $0.02
Valeri
My URL was something like this
...../...../.....php?key=123456
The injection was something like this
...../...../.....php?key=876711111111111111111111111111' UNION SELECT 13,CONCAT([X],count(*),[X],13,13,13,13,13,13 FROM information_schema.TABLES WHERE `TABLE_NAME` LIKE "%wp_users%" -- /* order by 'as
There are no user permission on information_schema.
There seems to be 2 versions of the coding floating around on Austrian and Russian IPs. One is ineffective but the other works. It seems the author is expert in the intricate structure and design of SQL.
-- Regards,
Paul. England, EU. England's place is in the European Union.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev wrote:
On Wed, March 23, 2016 10:21 pm, Always Learning wrote:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
<snip>>
Indeed. There are several flaws in how mysql handles data. This is why to
Ok, do you have a link or two to info about that?
the best of my ability I am trying to avoid mysql, and use postgresql if whatever chunk of software I need is designed to work also with postgresql. And I recommend developers I work with/for the same (to use
We seem to be moving to postgresql. I find I do not like it - it's much more of a pain to work with than mysql is. Do you have any opinions about meria d/b? Are there improvements over the flaws you're aware of with mysql? <snip>
mark
On Thu, March 24, 2016 9:48 am, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On Wed, March 23, 2016 10:21 pm, Always Learning wrote:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
<snip>>
Indeed. There are several flaws in how mysql handles data. This is why to
Ok, do you have a link or two to info about that?
Mark, you seemed to snip away the link to presentation on youtube :
https://www.youtube.com/watch?v=1PoFIohBSM4
which I gave in my post. That even though a bit old, was instructive for me.
the best of my ability I am trying to avoid mysql, and use postgresql if whatever chunk of software I need is designed to work also with postgresql. And I recommend developers I work with/for the same (to use
We seem to be moving to postgresql.
Great!
I find I do not like it - it's much more of a pain to work with than mysql is. Do you have any opinions about meria d/b? Are there improvements over the flaws you're aware of with mysql?
Mariadb being a fork of mysql likely inherited mysql's "inconsistencies". Not that I would say mysql (and mariadb surely) folks are not working on improvements. E.g., the default installation of latest mysql does not have any accounts with empty password (I was weeding these away for years with every new installation of mysql. Oh, well, maybe I'm wrong, as this I just had seen fixed on FreeBSD, so it is possible that package maintainer did this nice cleaning). I'm not the one who can have any opinion on something (mariadb) which he doesn't use, still...
Valeri
<snip>
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev wrote:
On Thu, March 24, 2016 9:48 am, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On Wed, March 23, 2016 10:21 pm, Always Learning wrote:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
<snip>>
Indeed. There are several flaws in how mysql handles data. This is why
Ok, do you have a link or two to info about that?
Mark, you seemed to snip away the link to presentation on youtube :
Oh. I really dislike videos of people explaining something I could read, if they'd just typed it up.... (I mean the author, not you). But I suppose I'll watch it. <snip>
We seem to be moving to postgresql.
Great!
I find I do not like it - it's much more of a pain to work with than mysql is. Do you have any opinions about meria d/b? Are there improvements over the flaws you're aware of with mysql?
Mariadb being a fork of mysql likely inherited mysql's "inconsistencies". Not that I would say mysql (and mariadb surely) folks are not working on improvements. E.g., the default installation of latest mysql does not have any accounts with empty password (I was weeding these away for years with every new installation of mysql. Oh, well, maybe I'm wrong, as this I just had seen fixed on FreeBSD, so it is possible that package maintainer did this nice cleaning). I'm not the one who can have any opinion on something (mariadb) which he doesn't use, still...
Well, remember that it was forked after the Evil Empire took over mysql. I just wonder if Oracle is *not* fixing some security issues... because they obviously want you to "fix" that problem by simply buying Oracle. With that train of thought, that's why I'm wondering if the mariad/b team *is* fixing the issues.
mark
On 03/24/2016 08:28 AM, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On Thu, March 24, 2016 9:48 am, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On Wed, March 23, 2016 10:21 pm, Always Learning wrote:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
<snip>>
Indeed. There are several flaws in how mysql handles data. This is why
Ok, do you have a link or two to info about that?
Mark, you seemed to snip away the link to presentation on youtube :
Oh. I really dislike videos of people explaining something I could read, if they'd just typed it up.... (I mean the author, not you). But I suppose I'll watch it.
I'm with you there. It is getting worse because people are trying to monetize it with the ads that YouTube plays first.
But you can't scan it, easily move back when you need to, etc.
I wish more online help and tutorials were text like they use to be.
On Thu, March 24, 2016 10:32 am, Alice Wonder wrote:
On 03/24/2016 08:28 AM, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On Thu, March 24, 2016 9:48 am, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On Wed, March 23, 2016 10:21 pm, Always Learning wrote:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
<snip>>
Indeed. There are several flaws in how mysql handles data. This is why
Ok, do you have a link or two to info about that?
Mark, you seemed to snip away the link to presentation on youtube :
Oh. I really dislike videos of people explaining something I could read, if they'd just typed it up.... (I mean the author, not you). But I suppose I'll watch it.
I'm with you there. It is getting worse because people are trying to monetize it with the ads that YouTube plays first.
But you can't scan it, easily move back when you need to, etc.
I wish more online help and tutorials were text like they use to be.
I agree with you both, gentlemen. But I gave the link I had handy. It is kind of laziness on my part, I admit: I decided to not invest into search of convenient equivalent, and gave something I already had reference to, letting those who are interested find out either from this video or find better - readable - source. If someone finds better source, I would appreciate it. As my users will benefit if I refer them to better digestible presentation. Thanks in advance!
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev wrote:
On Thu, March 24, 2016 10:32 am, Alice Wonder wrote:
On 03/24/2016 08:28 AM, m.roth@5-cent.us wrote:
<SNIP>
Ok, do you have a link or two to info about that?
Mark, you seemed to snip away the link to presentation on youtube :
<MVNCH> Ok, now I *really* dislike videos. Since I'm not at home, and not putting the video on a 42" TV, I *CANNOT* read most of what they're typing, and the system responses not at all.
However, if, just before the video goes from the lead page announcing "postgresql" to the video of them typing, for about a 3 sec pause, you freeze the video, it says "this is from http://sql-info.de/mysql/gotchas.html
Great, so here's the text. And I start reading.... Excerpt: he MySQL database server is being continually improved. Some gotchas described here are no longer relevant for the latest versions; in these cases the version numbers affected are noted at the top of each section. As a rule gotchas have been tested against the most recent stable versions from the 3.23.x, 4.0.x and 4.1.x series. --- end excerpt ---
It says, at the bottom, that it was last updated in 2014.
When did mysql 5.0 come out - five years ago? more? Oh, sorry, I google mysql 5.0 release, and I find release notes for 5.0.24... from TEN YEARS AGO.
I don't really feel like testing out some of the site's gotcha in the mysql we have running here... but everything here is from the std. base repo, and for CentOS 6, is 5.1.73-5.
mark
So, I don't have a lot of confidence in the gotchas, until I test it, or find someone who's tested them in the last 10 years against the main branch.
mark
On Thu, March 24, 2016 10:28 am, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On Thu, March 24, 2016 9:48 am, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On Wed, March 23, 2016 10:21 pm, Always Learning wrote:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
<snip>>
Indeed. There are several flaws in how mysql handles data. This is why
Ok, do you have a link or two to info about that?
Mark, you seemed to snip away the link to presentation on youtube :
Oh. I really dislike videos of people explaining something I could read, if they'd just typed it up.... (I mean the author, not you). But I suppose I'll watch it.
<snip> >> We seem to be moving to postgresql. > > Great! > >> I find I do not like it - it's much >> more of a pain to work with than mysql is. Do you have any opinions >> about meria d/b? Are there improvements over the flaws you're aware >> of with mysql? > > Mariadb being a fork of mysql likely inherited mysql's > "inconsistencies". > Not that I would say mysql (and mariadb surely) folks are not working on > improvements. E.g., the default installation of latest mysql does not > have > any accounts with empty password (I was weeding these away for years > with > every new installation of mysql. Oh, well, maybe I'm wrong, as this I > just > had seen fixed on FreeBSD, so it is possible that package maintainer did > this nice cleaning). I'm not the one who can have any opinion on > something > (mariadb) which he doesn't use, still...
Well, remember that it was forked after the Evil Empire took over mysql. I just wonder if Oracle is *not* fixing some security issues... because they obviously want you to "fix" that problem by simply buying Oracle. With that train of thought, that's why I'm wondering if the mariad/b team *is* fixing the issues.
I was going to add the following, and I didn't. This actually is not about mysql or mariadb vs postgresql, but more about one's general approach to what you will choose. Way back when there were continuing security issues with sendmail (which were being promptly fixed, still...) I was looking for what I could use as mail server software. And I chose postfix, as it was architectured from the very beginning with security in mind. There probably will be no often need of fixing issues, as from the very beginning the code was created so to have as minimal number of potential issues as possible. I don't invite into jumping in discussion about variety of particular MTA etc. I was just trying to say in general: something better written from the very beginning vs something that needs many fixes. The last, BTW, will more likely make you suffering down the road because of the change of internals with upgrade to next version etc.
I hope I managed to convey the thought...
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 3/24/2016 7:48 AM, m.roth@5-cent.us wrote:
We seem to be moving to postgresql. I find I do not like it - it's much more of a pain to work with than mysql is. Do you have any opinions about meria d/b? Are there improvements over the flaws you're aware of with mysql?
and I find mysql a real pain to work with.
the biggest difference is, postgresql is much stricter about data types. it will not, for example, allow you to store 2015-02-30 as a date. also, postgres is very strict about the atomicity of transactions, its all or nothing.
John,
John R Pierce wrote:
On 3/24/2016 7:48 AM, m.roth@5-cent.us wrote:
We seem to be moving to postgresql. I find I do not like it - it's much more of a pain to work with than mysql is. Do you have any opinions about meria d/b? Are there improvements over the flaws you're aware of with mysql?
and I find mysql a real pain to work with.
the biggest difference is, postgresql is much stricter about data types. it will not, for example, allow you to store 2015-02-30 as a date. also, postgres is very strict about the atomicity of transactions, its all or nothing.
And I have serious issues trying to figure out the structure of, say, the barios d/b. But I did NOT ask for a comparison to postgresql, or care to have any kind of argument about it at all. I was asking about mariadb vs. mysql.
Oh, and the link I posted, to MySQL gotchas, that was last updated in '14? I tried emailing them, at the link they gave, and my email bounced.
mark mark
Indeed. There are several flaws in how mysql handles data. This is why to the best of my ability I am trying to avoid mysql, and use postgresql if whatever chunk of software I need is designed to work also with postgresql. And I recommend developers I work with/for the same (to use postgresql). These are good examples:
http://dev.mysql.com/doc/refman/5.1/en/sql-mode.html#sql-mode-strict
-
Alice Wonder -
Always Learning -
Gordon Messmer -
John R Pierce -
Johnny Hughes -
Leon Fauster -
m.roth＠5-cent.us -
Valeri Galtsev -
Александр Кириллов