In this primer I will show how to improve the security of your MariaDB installation by using two-step verification and how to use it from your Windows GUI client.

Let’s suppose you have your data in MariaDB, installed, say, on Ubuntu. And your users connect to it to run ad hoc queries, using some sort of a Windows GUI client. You don’t want them to write the access password on post-it notes or have it auto-entered by the client. And you don’t want anyone see the password when one of the salespersons connects to the mother ship from his laptop in the Internet café. So you decide to use the two-step verification, just like Google does, to secure the access to the data.

Continue reading

OLX, a free classifieds site, is serving up 40 million pages a day using MariaDB. Not an insignificant task.

There’s a nice write-up in the MariaDB knowledgebase with particulars. In short, the 5.2 series of MariaDB and some of the unique features of the project have made a migration easy and valuable.

It’s nice to hear such stories. Both because we like interesting sites and projects, as well as our natural interest in larger scale or larger visibility deployments. Got a story to share? Please create a KB entry, or e-mail the community team.

I don’t know about you, but I like diff -p [1].  Having used it for years, I can read these diffs like a text, while diffs without -p often need to have the original file opened side by side, just to get enough of the context.

Loving diff -p so much, I want to see it everywhere (evil laughter). Alas, in bzr only diff command can easily use -p, just run it as bzr diff --diff-options=-p or store it as an alias in the ~/.bazaar/bazaar.conf.

Actually, for an alias there is a better, although more verbose, alternative:

Unlike simple -p it will not think that a word ending with a semicolon (like a label or, say, public: and private:) is a “C function name”.

But the problem is — only bzr diff can be tuned this way. Bzr email plugin still sends diffs without function names. And bzr gdiff does not show them. And, of course, all other bzr commands — bzr commit, for example, or bzr shelve, bzr unshelve --preview, bzr log --show-diff and others — they are still as unfriendly as before.

I was solving it on a case by case basis — added a post_commit_diffoptions configuration option to the bzr-email plugin, then a command line option to bzr gdiff. But then it occurred to me that I can attack the problem at its core!
Continue reading