Archive for the ‘drupal’ Category

Devops in Munich

Май 1st, 2012

Devopsdays Mountainview sold out in a short 3 hours .. but there's other events that will breath devops this summer.
DrupalCon in Munich will be one of them ..

Some of you might have noticed that I`m cochairing the devops track for DrupalCon Munich,
The CFP is open till the 11th of this month and we are still actively looking for speakers.

We're trying to bridge the gap between drupal developers and the people that put their code to production, at scale.
But also enhancing the knowledge of infrastructure components Drupal developers depend on.

We're looking for talks both on culture (both success stories and failure) , automation,
specifically looking for people talking about drupal deployments , eg using tools like Capistrano, Chef, Puppet,
We want to hear where Continuous Integration fits in your deployment , do you do Continuous Delivery of a drupal environment.
And how do you test ... yes we like to hear a lot about testing , performance tests, security tests, application tests and so on.
... Or have you solved the content vs code vs config deployment problem yet ?

How are you measuring and monitoring these deployments and adding metrics to them so you can get good visibility on both
system and user actions of your platform. Have you build fancy dashboards showing your whole organisation the current state of your deployment ?

We're also looking for people talking about introducing different data backends, nosql, scaling different search backends , building your own cdn using smart filesystem setups.
Or making smart use of existing backends, such as tuning and scaling MySQL, memcached and others.

So lets make it clear to the community that drupal people do care about their code after they committed it in source control !

Please submit your talks here


PlanetMySQL Voting: Vote UP / Vote DOWN

Devops in Munich

Май 1st, 2012

Devopsdays Mountainview sold out in a short 3 hours .. but there's other events that will breath devops this summer.
DrupalCon in Munich will be one of them ..

Some of you might have noticed that I`m cochairing the devops track for DrupalCon Munich,
The CFP is open till the 11th of this month and we are still actively looking for speakers.

We're trying to bridge the gap between drupal developers and the people that put their code to production, at scale.
But also enhancing the knowledge of infrastructure components Drupal developers depend on.

We're looking for talks both on culture (both success stories and failure) , automation,
specifically looking for people talking about drupal deployments , eg using tools like Capistrano, Chef, Puppet,
We want to hear where Continuous Integration fits in your deployment , do you do Continuous Delivery of a drupal environment.
And how do you test ... yes we like to hear a lot about testing , performance tests, security tests, application tests and so on.
... Or have you solved the content vs code vs config deployment problem yet ?

How are you measuring and monitoring these deployments and adding metrics to them so you can get good visibility on both
system and user actions of your platform. Have you build fancy dashboards showing your whole organisation the current state of your deployment ?

We're also looking for people talking about introducing different data backends, nosql, scaling different search backends , building your own cdn using smart filesystem setups.
Or making smart use of existing backends, such as tuning and scaling MySQL, memcached and others.

So lets make it clear to the community that drupal people do care about their code after they committed it in source control !

Please submit your talks here


PlanetMySQL Voting: Vote UP / Vote DOWN

Site update with a welcome news

Март 12th, 2012

As I updated my website, migrating from Drupal to WordPress, a welcome news followed in the evening when Swansea beating Manchester City 1-0. The female assistant to the referee, Sian Massey, gladly judging Micah Richards for an offside. United had a rough time taking over WBA, but ensuring a relatively comfortable 2-0.


PlanetMySQL Voting: Vote UP / Vote DOWN

New! Cloud-based MySQL Database Monitoring from Monitis

Февраль 16th, 2012

New feature provides significantly faster insight and root cause analysis

SAN JOSE, Calif., February, 15, 2012Monitis, the leading cloud and web application monitoring software provider, today announces that it has added comprehensive MySQL database monitoring to its award-winning Application Performance Management & Monitoring platform. The robust Software-as-a-Service (SaaS) tool enables users to gain significantly faster insight when conducting root cause analysis.

The MySQL monitoring feature includes 246 monitoring variables and more than 21 different metrics to provide one of the easiest to use, yet comprehensive database monitoring tools available. It was first introduced into the free Monitor.Us platform back in June last year and has seen the code battle hardened by many hundred free users over the last 8 months.

Hovhannes Avoyan, founder and General Manager at Monitis commented “This feature makes it easy for systems administrators and web developers to measure and monitor the performance of their php environments such as Joomla and WordPress, from multiple locations around the world. It gives them a true picture of application performance from where ever in the world the user is. Because the Monitis MySQL monitor is part of the Monitis platform it provides an unprecedented holistic view of software, database and underlying hardware, giving pressured techs the ability to quickly and easily diagnose the root cause of slow application performance.”

The service uses a small Linux agent that can monitor inside an organization’s firewall and distributed systems. The Monitis agent connects to a local or remote database and collects a variety of health and performance metrics that are graphically displayed in real-time on a web-based dashboard. Users can also set up notifications (should their database go down or pass a certain level of access volume) based on client-defined thresholds and rules.

Some metrics tracked and reported on by Monitis — which can be set up in minutes — include:

MySQL Monitoring Metrics

  • Database size
  • Resource utilization
  • Analysis of responsiveness/latency
  • Analysis of throughput
  • Database usage
  • Scalability

“Monitis’ SaaS delivery and pay as you go pricing mean it’s easy to get going and has low set up and running costs. It puts the power of MySQL monitoring in the reach of techs who otherwise wouldn’t have had the time to set up or budget to afford such a comprehensive solution.” adds Avoyan

Monitis MySQL Monitoring provides much greater check-in frequency, as low as every 5 minutes, and the ability to check the performance of the database from multiple locations around the world.

 

About Monitis

Monitis is the leading provider of Cloud-based Application Performance Management & Monitoring solutions for System Admins and Web Developers. Over 80,000 users worldwide have chosen Monitis to increase uptime and user experience of their services and products.

Monitis’ core product offerings include website monitoring, website full page load testing, transaction monitoring, application and database monitoring, cloud resource monitoring, and server and internal network monitoring. What makes Monitis’ software different is how fast it is to deploy, its flexible pricing and feature-rich technology that provides a comprehensive single-pane view of on-premise and off-premise infrastructure and applications.

More information on Monitis MySQL Monitoring is available on our website.

Share Now:
  • del.icio.us
  • Digg
  • Facebook
  • LinkedIn
  • BlinkList
  • DZone
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • Twitter
  • RSS

PlanetMySQL Voting: Vote UP / Vote DOWN

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