Archive for the ‘drupal’ Category

Adding dynamic fields to Signups on Drupal

Февраль 8th, 2012

In my day job at SkySQL I work with Drupal as our content management system.  One thing we often need to do is provide a way for people to sign up for events and the like.  One such event is the upcoming SkySQL and MariaDB: Solutions Day for the MySQL® Database and unlike other events we needed to take into account the dietary requirements of those wishing to attend.

For events registration we use the Signup module and use a theme template function to provide a set of standard fields.  The code looks something like this:

function ourtheme_signup_user_form($node) {
$form = array();
// If this function is providing any extra fields at all, the following
// line is required for form form to work -- DO NOT EDIT OR REMOVE.
$form['signup_form_data']['#tree'] = TRUE;

$form['signup_form_data']['FirstName'] = array(
'#type' => 'textfield',
'#title' => t('First Name'),
'#size' => 40, '#maxlength' => 64,
'#required' => TRUE,
);
$form['signup_form_data']['LastName'] = array(
'#type' => 'textfield',
'#title' => t('Last Name'),
'#size' => 40, '#maxlength' => 64,
'#required' => TRUE,
);

And so on, building up the elements and then returning the form.  This is great because it allows us to have a standard set of fields for all signup pages, making life a lot simpler when creating content that requires registration.  But the Solutions Day event required an extra field.  I could have done this a number of ways, including putting logic in the template file to check for that particular node and only display the field then, or perhaps some other hack specific to this node.  I, however, don't like specifics and tend to look for a generic solution, as the exception invariably becomes the rule.

For this exercise I wanted to be able to have a way of specifying for a particular node any extra fields that are available for this form.  So I now have in the template.php file the following code:

// If there is a special field required for this, check and display
if (!empty($node->field_signup_extra) && !empty($node->field_signup_extra[0]['value'])) {
$extras = explode("\n", $node->field_signup_extra[0]['value']);
foreach ($extras as $field_def) {
$field_def = trim($field_def);
if (empty($field_def)) {
continue;
}
$elems = explode('|', $field_def);
$field_name = array_unshift($elems);

$form['signup_form_data'][$field_name] = array();
foreach ($elems as $field_element) {
list($key, $val) = explode('=',$field_element);
if ($key == 'options') {
$val = explode(',', $val);
}
$form['signup_form_data'][$field_name]['#' . $key] = $val;
}
}
}

Now all I need to do is create a field that is non-displayable but contains information to build extra fields.  For example the content that describes the Dietary Requirements field is:

dietary_requirements|title=Dietary Requirements|size=40|type=textfield

The production version does a little more analysis of the input to ensure there are no possible attack vectors, but I've left that out for clarity sake.

Now, if I have an event (or other content type) that needs extra signup fields, I ensure that the content type has the new Signup Extras field and fill it on the new content with a simple field definition that Signup can use.


PlanetMySQL Voting: Vote UP / Vote DOWN

How to log all MySQL queries in Drupal

Декабрь 22nd, 2011
In order to benchmark a Drupal site performance you need to see all the database queries related to your Drupal site. In case you don’t have access to the my.cnf file If you don’t have access to the my.cnf file, you can log the queries from the Drupal code itself: cp includes/database.mysql-common.inc includes/database.mysql-common.inc.backup.orig vim includes/database.mysql-common.inc [...]

PlanetMySQL Voting: Vote UP / Vote DOWN

Stop Disabling SELinux!

Декабрь 22nd, 2011

I see a lot of people coming by #centos and similar channels asking for help when they’re experiencing a problem with their Linux system. It amazes me how many people describe their problem, and then say something along the lines of, “and I disabled SELinux...”. Most of the time SELinux has nothing to do with the problem, and if SELinux is the cause of the problem, why would you throw out the extra security by disabling it completely rather than configuring it to work with your application?

read more


PlanetMySQL Voting: Vote UP / Vote DOWN

Open Query training at Drupal DownUnder 2012

Декабрь 7th, 2011

DrupalDownUnder 2012 will be held in Melbourne Australia 13-15 January. A great event, I’ve been to several of its predecessors. People there don’t care an awful lot for databases, but they do realise that sometimes it’s important to either learn more about it or talk to someone specialised in that field. And when discussing general infrastructure, resilience is quite relevant. Clients want a site to remain up, but keep costs low.

I will teach pre-conference training sessions on the Friday at DDU:

The material is made specific to Drupal developers and users. The query design skills, for instance, will help you with module development and designing Drupal Views. The two half-days can also be booked as a MySQL Training Pack for $395.

On Saturday afternoon in the main conference, I have a session Scaling out your Drupal and Database Infrastructure, Affordably covering the topics of resilience, ease of maintenance, and scaling.

I’m honoured to have been selected to do these sessions, I know there were plenty of submissions from excellent speakers. As with all Drupal conferences, attendees also vote on which submissions they would like to see.

After DDU I’m travelling on to Ballarat for LinuxConfAU 2012, where I’m not speaking in the main program this year, but will have sessions in the “High Availability and Storage” and “Business of Open Source” miniconfs. I’ll do another post on the former – the latter is not related to Open Query.


PlanetMySQL Voting: Vote UP / Vote DOWN

Integrating Aegir with Linux and FTP

Ноябрь 8th, 2011

Due to the insane cost of bandwidth (compared to the rest of the developed world) in Australia, I've recently decided to move some of our hosting clients to Linode. This means they can move more data more cheaply and I don't need to come up with (and administer) a bandwidth accounting system for my Australian based web VM.

We pretty much exclusively use Drupal for hosting clients, so to make management a bit easier I decided to use Ægir on the new Linode. Installation was a relative breeze, after a quick google to find out how to specify that I didn't want to use Apache and wanted to use a separate server as dedicated MySQL host.

The problem (there is always a problem) arose when I needed to give a hosting client access to their Drupal installation, so they could manage themes and site-specific modules. Just adding an account and providing SSH access was out of the question, as all sites are stored under a single system user. Anyone logging in with permissions to edit their own Drupal can then also edit all other sites and even the Ægir installation itself.

FTP would be a solution, as FTP accounts can be chrooted (locked into a specific directory) quite easily, but I didn't want to have to manage a list of FTP accounts separate from the Drupals in Ægir. That isn't the lazysysadmin way.

After a bit of thought I remembered that on an older web host, I had happily used libnss-mysql and libpam-mysql, which integrate accounts defined in a (any) MySQL database with the Linux system. The trick is to get MySQL to cough up the account information in the correct format, so the system can parse it as if these accounts were normal system users.

Ægir allows me to assign Site nodes to Client nodes and allows these Client nodes to be owned by Drupal users. In addition, there are Platform nodes which define in which directories on disk all sites are stored. Between those content types, there is enough information to create the account entries used by the system. It just requires a MySQL query which joins 4 or 5 tables in the Ægir database. And libpam-mysql is able to authenticate against MD5 hashes, which is how Drupal 6 stores user passwords.

To avoid a giant and unreadable configuration file for libnss-mysql I decided to embed these queries as views. That means I embed some logic in the database itself and in return I can configure really simple SELECT queries in the libnss-mysql and libpam-mysql conguration files.

The logic embedded in the views ensures that people using accounts for Drupal users marked as blocked or Ægir sites marked as disabled or deleted are not able to login and that these accounts as listed as such when displayed via the standard Linux account administration tools.

After you install libnss-mysql-bg (which is the package name on Debian) you'll have to configure /etc/libnss-mysql.cfg and /etc/libnss-mysql-root.cfg. The latter exists to allow the account tools to use different credentials on the MySQL server in case they need to run UPDATE or DELETE queries. You won't be doing that, so all you need is to make sure that if there is anything in that file, it's commented out and won't interfere.

It's views Jim, but not 6.x-3.0

First up, create a MySQL user that is allowed to select data from your Ægir database. Connect to MySQL as administrator and run the following query. Adjust it, so it uses the correct host and database and a somewhat safer password.

GRANT SELECT ON aegir.* TO libnss@localhost IDENTIFIED BY 'secret';

Next, switch to the Ægir database to add the views that libnss-mysql will use. First off, the view nss_getpwnam that will return standard account inormation, such as username, home directory and shell.

You'll see I used 10000 as the uid and gid in this query. That's because my aegir system user has these user and group ID. The virtual users from MySQL need to have these same user and group IDs, so that when they login via FTP, they are the owner of their home directory and able to write files.

You should change these numbers in this query to match the user and group IDs for the aegir user on your system!

CREATE VIEW `nss_getpwnam` AS
SELECT
  DISTINCT LCASE(`n`.`title`) AS `username`,
  'x' AS `password`,
  10000 AS `uid`,
  10000 AS `gid`,
  CONCAT(`nc`.`title`, ',,,') AS `gecos`,
  CONCAT_WS('/', `p`.`publish_path`, 'sites', `n`.`title`) AS `homedir`,
  IF (s.status = 1, '/bin/true', '/bin/false') AS `shell`
FROM `hosting_site` `s`
LEFT JOIN `node` `n`
  ON (`s`.`vid` = `n`.`vid`)
LEFT JOIN `hosting_client_user` `c`
  ON ((`s`.`client` = `c`.`client`) AND (`c`.`user` <> 1))
LEFT JOIN `node` `nc`
  ON (`nc`.`nid` = `s`.`client`)
LEFT JOIN `users` `u`
  ON ((`u`.`uid` = `c`.`user`) AND (`u`.`status` <> 0))
LEFT JOIN `hosting_platform` `p`
  ON (`s`.`platform` = `p`.`nid`)
;

The username that willl be used is the title of the site node (in lowercase). There's a bit of logic there that creates a home directory for the user out of the platform path and the site name and the account shell is set to /bin/true if the site is enabled or /bin/false if it isn't. This matters, as you'll configure the FTP server to disallow logins for users who have their shell set to /bin/false. The view also disregards Ægir users 0 and 1, the guest and administrator. If you migrate the site to a different platform, the view will automatically use the new platform_path to create an updated home directory.

Next up, the view nss_getspnam that returns secure account data, such as the encrypted password and expiry information.

CREATE VIEW `nss_getspnam` AS
SELECT
  DISTINCT `n`.`title` AS `username`,
  IF((`s`.`status` = 1, `u`.`pass`, '*'), AS `password`,
  1 AS `lstchg`,
  0 AS `min`,
  99999 AS `max`,
  0 AS `warn`,
  0 AS `inact`,
  IF((`s`.`status` <> 1), 0, -(1)) AS `expire`,
  0 AS `flag`
FROM `hosting_site` `s`
LEFT JOIN `node` `n`
 ON (`s`.`vid` = `n`.`vid`)
LEFT JOIN  `hosting_client_user` `c`
  ON ((`s`.`client` = `c`.`client`) AND (`c`.`user` <> 1))
LEFT JOIN `users` `u`
  ON ((`u`.`uid` = `c`.`user`) AND (`u`.`status` <> 0))
;

This again contains a little bit of logic that prevers users from logging in if their associated Drupal site isn't enabled in Ægir, by setting the encrypted password to * instead of their Drupal password and the expire field to 0 (which means it expired in January 1970).

The other two views (nss_getgrman and nss_gidsbymem) you need for libpam-nss take care of group name to ID and group membership by user mapping. In this case all you want is for these accounts to be members of the aegir group, so all they need to do is return the name 'aegir' and the gid 10000.

CREATE VIEW `nss_getgrnam` AS
SELECT
  'aegir' AS `group`,
  'x' AS `password`,
  10000 AS `gid`
;

CREATE VIEW `nss_gidsbymem` AS
  SELECT 10000 AS `gid`
;

That was easy :-)

Finally, the view that will allow libpam-mysql to check login passwords for the FTP server. This returns the Site node title as username, the associated Ægir user's Drupal password as the password and the Ægir site status as a field that allows you to reject logins for disabled sites.

CREATE VIEW `nss_mysql` AS
SELECT
  DISTINCT `n`.`title` AS `username`,
  IF((`s`.`status` = 1), `u`.`pass`,'*') AS `password`,
  s`.`status` AS `status`
FROM `hosting_site` `s`
LEFT JOIN `node` `n`
  ON (`s`.`vid` = `n`.`vid`)
LEFT JOIN `hosting_client` `c`
  ON (`s`.`client` = `c`.`nid`)
LEFT JOIN `hosting_client_user` `cu`
  ON ((`s`.`client` = `cu`.`client`) and (`cu`.`user` <> 1))
LEFT JOIN `users` `u`
  ON ((`u`.`uid` = `cu`.`user`) AND (`u`.`status` <> 0))
;

There is a bit of logic again that returns * as password for Ægir users that are blocked, meaning they cannot FTP to their site and access is denied for user #1.

You can have a play with these and see what account information you now have by simply selecting data from the view, for instance SELECT * FROM nss_getpwnam;

Tell Papa Linux

That's it for the work that you need to do on the MySQL server. Next, configure libnss-mysql to use these views for account information retrieval. Add the following content to /etc/libnss-mysql.cfg:

getpwnam    SELECT username,'x',uid,gid,gecos,homedir,shell \
            FROM nss_getpwnam \
            WHERE username = '%1$s' \
            LIMIT 1
getpwuid    SELECT username,'x',uid,gid,gecos,homedir,shell \
            FROM nss_getpwnam \
            WHERE uid = '%1$u' \
            LIMIT 1
getspnam    SELECT username,password,lstchg,min,max,warn,inact,expire,flag \
            FROM nss_getspnam \
            WHERE username='%1$s' \
            LIMIT 1
getpwent    SELECT username,'x',uid,gid,gecos,homedir,shell \
            FROM nss_getpwnam
getspent    SELECT username,password,lstchg,min,max,warn,inact,expire,flag \
            FROM nss_getspnam
getgrnam    SELECT group,password,gid \
            FROM nss_getgrnam \
            WHERE group='%1$s' \
            LIMIT 1
getgrgid    SELECT group,password,gid \
            FROM nss_getgrnam \
            WHERE gid='%1$s' \
            LIMIT 1
memsbygid   SELECT username
            FROM nss_getpwnam \
            WHERE gid='%1$u'
gidsbymem   SELECT gid \
            FROM nss_gidsbymem

host        localhost
database    aegir
username    libnss
password    secret

And be sure to edit the final four lines to match the MySQL server credentials for the libnss user that you created earlier. The beauty of using MySQL views is that the WHERE and LIMIT clauses will just work, as if they were appended to the query defined in the view.

When this is done, you can tell your system to start using libnssl-mysql for account detail lookups. Open up /etc/nsswitch.conf and append the word mysql to the end of the passwd line.

passwd:   compat mysql

This will cause your system to first check /etc/passwd for account information and then interrogate libnss-mysql (which you've now configured to ask Ægir). You can test this by running the command getent passwd, which should now give you a list of system users, followed by a list of Ægir site names.

A nice side-effect of this is that you can now cd to the site's home directory in your shell. Doing this will pop you in the correct directory under sites in the correct platform. Even tab completion works on these site-based account names.

If you have enabled sites in Ægir and you only see users from /etc/passwd you should make sure the libnss MySQL user can connect to the server and run its defined queries on the views you created.

Install FTP

Next up, install an FTP server and configure it. Exactly how you go about this depends on the FTP server you choose, but you should ensure to disable anonymous logins, force all users to be chrooted and set the umask to 002. Check the FTP server documentation for how to do this. If it doesn't come with documentation, choose a different FTP server. It also needs to be able to use PAM (Pluggable Authentication Modules) for authentication, though I think most are able to do this.

Be sure to add /bin/true to /etc/shells, as most FTP servers are configured to disallow logins for users whose shell is not listed in that file.

I chose Pure-FTPD, after running into odd problems with vsftpd (which I've used successfully elsewhere).

The umask is used to set default permissions on files and directories uploaded by users. Setting it to 002 means that anyone sharing the aegir group (which is the group all these virtual users share) is able to modify these files and directories, without having to be the aegir user. That means I can use my own system account to make changes to these files if I need to without making them inaccessible to FTP users.

Because all FTP users are locked into their own directories via the chroot, they cannot access each others sites.

Enabling PAM

The last step is to configure authentication for the FTP server, to allow users to login and upload (or download) stuff. On Linux, authentication is taken care of by PAM, which by default uses /etc/passwd and /etc/shadow. It can be made to use a MySQL server by installing the libpam-mysql or the newer libpam-mysql-bg package. On my Debian server, only the latter is available.

Configuration for PAM can be done separately for each service that uses authentication or centrally, by having each service include a common configuration file (or files). You'll create a common configuration file for MySQL authentication and then include that in the FTP specific file.

Create a file called /etc/pam.d/common-aegir with the following content:

# Use pam-mysql to grant access to Drupal Ægir clients.
auth required pam_mysql.so \
  user=libnss passwd=secret host=localhost db=aegir table=nss_mysql \
  usercolumn=username passwdcolumn=password crypt=3 where=status=1
account sufficient pam_mysql.so \
  user=libnss passwd=secret host=localhost db=aegir table=nss_mysql \
  usercolumn=username passwdcolumn=password crypt=3 where=status=1

I've broken up the lines to make them fit on screen. They should be single long lines in your file. Also make sure you change the MyQSL credentials to the ones you created earlier, or PAM won't be able authenticate users.

The important bits here are crypt=3, which tells PAM the passwords are in MD5 format (as used by Drupal) and the where=status=1 part which will prevent users from authenticating if their site is disabled in Ægir.

Finally, edit the specific PAM configuration file for the FTP server so it includes the new common-aegir file. In my case, with /etc/pam.d/pure-ftpd, that means I need to comment out or remove the existing @include directives and add in a new one:

# PAM config for pure-ftpd
# Standard behaviour for ftpd(8).
auth required pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed

@include common-aegir

That's all folks

You can now login to FTP using the site name as username and the associated Ægir user's password as password. Logging in will put you in the site-specific directory under the correct platform, so you can upload modules and themes.

I've attached copies of all the files I refer to, so you can grab them without having to copy and paste everything from this post.

Caveats & TODOs

I can't help myself, I have to add some caveats to this post. Though Ægir users can now FTP to their Drupal sites, the solution isn't exactly ideal. If multiple users are associated with a single Client, the queries I use above only return the enctypted password for one of them. And it's not clear which one. The login names on FTP and on Ægir are alo not the same, which is perhaps security through obscurity, but it's also un-ideal.

In an ideal world, FTP would perhaps use the password for user #1 on a given site, to login using that site as username. However, that would mean joining a table on a database name that's defined as a field in an Ægir table that's different for each site. It can probably be done, but it also means the libnss MySQL users needs SELECT access on all databases on the system.

As-is, the system can also not cope with Ægir installs that use multiple frontend web servers. That would require some extra WHERE statements on each frontend, so only users whose site runs on that frontend are able to login there.

AttachmentSize
libnss-views.sql_.txt1.27 KB
libnss-mysql.cfg_.txt1.11 KB
nsswitch.conf_.txt481 bytes
common-aegir.txt378 bytes
pure-ftpd.txt443 bytes

PlanetMySQL Voting: Vote UP / Vote DOWN

Slides from DrupalDownUnder2011 on Tuning for Drupal

Июнь 16th, 2011

By popular request, here’s the PDF of the slides of this talk as presented in January 2011 in brisbane; it’s fairly self-explanatory. Note that it’s not really extensive “tuning”, it just fixes up a few things that are usually “wrong” in default installs, creating a more sane baseline. If you want to get to optimal correctness and more performance, other things do need to be done as well.


PlanetMySQL Voting: Vote UP / Vote DOWN

Migrating users and content profiles

Декабрь 29th, 2010

For some time now I've been working on a Drupal site that consists mainly of scraped content from a proprietary, ASP based CMS from the late nineties. The Simple HTML Dom Parser, used from within a drush script, has been invaluable. It made scraping the old site content and importing it as Drupal nodes a relative breeze. (No access to the database used by the CMS, boo!)

Part of setting up the new site is importing users and their content profile nodes from a different Drupal site, that was setup a year or two ago to manage an event.

I had hoped there would be a way for me to export these users and their profile nodes from one Drupal to the other, but though I found modules to export one or the other, I might still end up with profile nodes that were no longer related to their users. Of course, that's pretty useless.

When I remembered I was also supposed to add all these users to a simplenews newsletter, the proverbial light bulb came on.

A spot of theory

I have previously done some bulk simplenews subscriptions by selecting Drupal data from one database table into another. In theory, that works fine across different databases as well. By inserting selected data from one Drupal's users table into another (avoiding uid clashes) I should be able to copy all users, keeping a predictable uid, so I could then do the same for their profile nodes.

First off, export the profile content type to the new Drupal site using the CCK content export module.

The grab the schema of all the tables I would need to transpose data to. These should be the same as the tables the data will come from. In my case the tables were: users, content_type_profile, node and node_revisions. The easiest way to grab the schema is via the mysql command line tool, using this query:

MySQL [source]> SHOW CREATE TABLE users\G

The \G means the data is shown in a single column, not in a column per field, which wouldn't fit across the terminal. Just repeat this for the other tables that need to be transposed and keep the output in a text editor window or something. Basically, this is just so you can easily copy and paste the field names.

At the bottom of each schema, you'll see a line like this one:

) ENGINE=InnoDB AUTO_INCREMENT=6221 DEFAULT CHARSET=utf8

The one from the node_revisions table is the important one. The AUTO_INCREMENT value tells us the next id that will be assigned on the primary auto_increment field in that table. In this case that is the vid field. It's important, because in all likelihood there is already a vid in this table for each value below the AUTO_INCREMENT value.

If you simply copy the node data across, chances some node.nid or node_revisions.vid will clash, causing the copy to break, leaving you with a cleanup to do. They do need to be included in the copy, though, because they are the way the user, her profile node and its CCK fields are linked together. If I simply copied all the other table columns and had the database assign new uids, nids and vids, I'd have a mess of information without its relational links intact.

My table has at most 6220 node revisions, so if I start with 10000 as the nid and vid for the copied nodes, there will never be a clash. Because I already had some users on the new Drupal, I decided to restart all copied user uid from 10000 as well.

At the end of the day the user.uid, node.nid and node_revisions.vid are just automatically assigned numbers, so if a chunk of them between 6220 and 10000 are not used, that hardly matters.

Run some queries

Time to migrate some data. In the following examples I execute all queries on the target database. All source data is coming from the Drupal tables in the oldevent database. These queries all need to be run by a MySQL user with INSERT privileges on the target Drupal database and at least SELECT privileges on the source Drupal database.

First, copy the users and give them a predictable non-clashing new user.uid. I exclude user id 1, as it already exists on the new Drupal site. I knew the other user's names would not clash, so I did not need to limit the query any further.

MySQL [source]> INSERT INTO users (SELECT uid+10000, name, pass, mail, mode, sort, threshold, theme, signature, signature_format, created, access, login, status, timezone, language, picture, init, data, timezone_name FROM oldevent.users WHERE oldevent.users.uid > 1);

Now copy all profile node CCK fields, making sure the nid and vid will not clash.

MySQL [source]> INSERT INTO content_type_profile (SELECT vid+10000, nid+10000, field_profile_firstname_value, field_profile_surname_value, field_profile_position_value, field_profile_organisation_value, field_profile_phone_value FROM oldevent.content_type_profile);

Note that iIf you have multi-value fields in your user's profiles, you will also need to perform this for all content_field_profile_* tables.

Next, copy across all profile nodes:

MySQL [source]> INSERT INTO node (SELECT nid+10000, vid+10000, type, language, title, uid+10000, status, created, changed, comment, promote, moderate, sticky, tnid, translate FROM oldevent.node WHERE oldevent.node.type='profile');

And finally, copy all profile node revisions across as well:

MySQL [source]> INSERT INTO node_revisions (SELECT nid+10000, vid+10000, uid+10000, title, body, teaser, log, timestamp, format FROM oldevent.node_revisions WHERE oldevent.node_revisions.nid IN (SELECT nid FROM oldevent.node WHERE oldevent.node.type='profile'));

And that's it. I did not need to copy any of the user's roles across, so at this point I was done. I migrated just under 1500 users and all revisions of their profiles from one Drupal to another in approximately two minutes.

Inevitable caveat!

If your users are set up with profile pictures, you'll need to make sure the users.picture field points at the right directory under files on the new Drupal site. You can do a quick search & replace query to update the path using REPLACE().

MySQL [source]> UPDATE users SET picture=REPLACE(picture, 'old-sub-string', 'new-sub-string');

Note that the picture filename will not match the user's uid anymore. If you use a tool like mmv or a shell script to rename the picture files, be sure to also update the field in the database. (Hint: generate a new file path via CONCAT() , using the user.uid field)

Trackback URL for this post: http://cafuego.net/trackback/390


PlanetMySQL Voting: Vote UP / Vote DOWN

Leaving MariaDB/Monty Program

Ноябрь 19th, 2010

Last week I announced internally that after my paternity leave ends next year, I will not be returning to Monty Program.

When I joined the company over a year ago I was immediately involved in drafting a project plan for the Open Database Alliance and its relation to MariaDB. We wanted to imitate the model of the Linux Foundation and Linux project, where the MariaDB project would be hosted by a non-profit organization where multiple vendors would collaborate and contribute. We wanted MariaDB to be a true community project, like most successful open source projects are - such as all other parts of the LAMP stack.

read more


PlanetMySQL Voting: Vote UP / Vote DOWN

Call for Papers: "MySQL and Friends" Developer Room at FOSDEM 2011 (Feb. 5th, Brussels, BE)

Ноябрь 2nd, 2010

FOSDEM banner

It's that time of the year again — the nice folks at FOSDEM have granted us a developer room at their upcoming conference (February 5+6 2011 in Brussels, Belgium)!

As usual there were more applications than they were able to accommodate, so we are very grateful for this opportunity for collaboration. Titled "MySQL and Friends", our room next year will be H.2213 with a capacity of 100 seats. It will be at our disposal on Saturday 5th, from 13:00 till 19:00. Like last year, we would like to set up a schedule of talks related to the MySQL server and the various projects that surround it. Each talk will last 20 minutes, plus 5 minutes of Q&A and a 5 minute break for switching speakers, giving us 12 slots in total to fill with excellent tech talks. Take a look at this year's schedule for some examples! I hope we can assemble an even more exciting and interesting schedule for next year.

Quoting from my last year's call for papers:

We are looking for covering a wide range of topics that attract both MySQL DBAs as well as application developers that work with MySQL as their database of choice. Are you developing a new storage engine or other plugin? Do you want to share your experiences and best practices in administering or deploying MySQL servers? Did you develop a new method to scale a MySQL setup? Let us and the audience know about it! You can submit your talk proposal via this submission form.

The deadline for turning in your proposal is Sunday, 26th of December, 2010, after which there will be a voting and rating period to identify the most interesting and attractive topics.

Please check the FOSDEM 2011 information page on the MySQL Forge Wiki for more details and don't hesitate to contact me directly, if you have any questions or suggestions. I look forward to your proposals!
PlanetMySQL Voting: Vote UP / Vote DOWN

LAMP stack Halloween cake

Октябрь 31st, 2010

Barry Jaspan and his wife Heather spent 20 hours creating this incredible cake for Acquia's Halloween party. Creative duo! Not only did it look great, it was yummy. Trick or treat!

Halloween
Halloween

PlanetMySQL Voting: Vote UP / Vote DOWN