tarvid's blog

drupal modsecurity args

root@helen:/etc/apache2/conf.d/modsecurity# diff modsecurity_crs_23_request_limits.conf ~/modsecurity_crs_23_request_limits.conf
28c28
< SecRule &ARGS "@gt 1023" "phase:2,t:none,deny,log,auditlog,status:403,msg:'Too many arguments in request',id:'960335',severity:'4'"
---
> SecRule &ARGS "@gt 255" "phase:2,t:none,deny,log,auditlog,status:403,msg:'Too many arguments in request',id:'960335',severity:'4'"
http://ls.net/admin/user/permissions was failing with error 403

nodewords -

drush dl nodewords-6.x-1.x-dev works. A simple drush up leads to database errors.

Email gateway

Fairly easy to set up with only a few wrinkles. The standard 6.x-1.10 generated a lot of error messages byt the "dev" module - mailhandler-6.x-1.x-dev - worked like a champ. Getting the gmail mailbox to worked took the usual Google Mail tricks: Pop3, domain - pop.gmail.com, port 995, the username  required the domain suffix and the "Extra command" is "/ssl/novalidate-cert".

Configuring .htaccess and settings.php

Don't.

If you modify .htaccess, you will have to maintain your changes through every core upgrade. There is no compelling reason to modify .htaccess. PHP configuration is better done with php.ini and errors in vhost configuration are better fixed in Apache.

Drupal 6 will configure sites/default/settings.php on initial installation. If you get your database configuration right at that point in time, you are set unless you muck with your database. Don't do that either.

resume

rev. james tarvid, pca
61 caprine lane
independence, va 24348
tarvid@ls.net

Upgrading Ubuntu Feisty > Gutsy > Hardy

Diligence and hard work pays off in the long run but procrastination pays off immediately.

One of the disadvantages of experience is that you retain memories of past failures. Like hunting with Dick Cheney and upgrading operating systems. A former Mandrake Linux fan, I once destroyed a fledging managed hosting business by insisting on installing the "latest" version on a number of servers.

Running a Drupal site locally under Windows XP

There are many reasons for running a copy of a Drupal website on a local machine among them backup, offline development or more likely a perverse desire to show that it can be done. The perversity is hightened by doing this on a Windows machine, in this case Windows XP. This case study is based on the real world user "varley" and the site "vekon.com". You may get your case to work with appropriate substitions.

Drupal vs. Dreamweaver

Rather inadequately, I have explained the difference between a CMS website and a conventional website as a matter of who contributes content, a CMS encourages wider participation in the website creation process. But that understates the significance of collaboration and networking. For example one site featured at the recent DrupalCon in DC was OAN. It is just difficult to imagine Dreamweaver in the driver's seat.

Implementing php5-xcache

Of the three "free" php opcode caching schemes APC, eAccelerator and Xcache, the latter had an installable package and appeared simplest to implement. I tried it on my local workstation first (always a good idea) and it came up with little difficulty.

apt-get install php5-xcache

Now generate the password.

echo -n "my_password" | md5sum -

Modify the username and password in /etc/php5/apache2/conf.d/xcache.ini

Hang the web code someplace easy to get at.

Tuning MySQL query_cache

An appropriate amount of "query_cache" is believed to improve MySQL performance at the expense of available memory. "Appropriate" will vary widely with usage and "performance" on a live site can be elusive. On Ubuntu, the defaults are modest but "work".

# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 16M

Drupal 5.x provides a summary at "admin/logs/status/sql" and 6.x at "admin/reports/status/sql".

Syndicate content