It is very typical to run multiple sites on a single server, since it would be overkill to run each small website and blog on its own VPS instance. The default Apache setup: mod_php and prefork-mpm does not offer any privilege separation or hardening for virtual hosts. Hence the need for additional security measures.

What are the general approaches taken to securing PHP?

The approaches taken in securing PHP can be divided into two broad categories:

1. Hardening PHP. This approach aims to improve the security of PHP scripts by limiting dangerous functionality on a site-by-site basis and by preventing flaws from escalating through additional patches to the PHP core. The main examples are: a) tweaking PHP core settings such as open_basedir and b) running a version of PHP which includes additional options to limit functionality and prevent flaws such as buffer overflows (Suhosin).
2. Privilege separation. This approach limits the extent to which other sites can be damaged if one of the websites on the shared server is compromised. There are several solutions, including mod_suPHP and suEXEC.

How can PHP and Apache interact?

There are several ways in which PHP and other scripts can be invoked by Apache:

• CGI (Common Gateway Interface) is a standard protocol that defines how webserver software can delegate the generation of webpages to a console application. It operates on a “one new process per request” basis.
• FastCGI is a protocol introduced in the mid-1990s that improves upon the older CGI protocol. It allows a single persistent process pool to handle multiple requests over its lifetime, reducing overhead.
• In-process as an Apache module, such as the default mod_php.

The default interaction between PHP and Apache is handled by the mod_php module. The most common ways of implementing privilege separation use either CGI or FastCGI to interface with PHP. PHP supports both CGI and FastCGI protocols.

Privilege separation can be done either:

1. by using CGI scripts and suEXEC, a feature built in Apache
2. by using Apache modules that make invoking CGI scripts easier
   • Apache modules are bundles that can be loaded to add new functionality to Apache. They are integrated into the Apache server and add new functionality to instances of the server, such as the capability to interpret PHP scripts.
   • Examples: mod_php, mod_suPHP, mod_fastcgi and mod_fcgid.
3. by using Apache MPMs that support privilege separation
   • Apache MPMs (Multi-Processing Modules) are responsible for binding to network ports on the machine, accepting requests, and dispatching children to handle the requests. There are several different MPMs – the Unix platform default is the prefork mpm.
   • Examples: prefork, worker, perchild, mpm_itk, mpm_peruser

What are the options for privilege separation?

suEXEC

suEXEC is a feature built into Apache, but not included in the default Apache installation. It makes all CGI scripts execute with the user id and permissions of their owners. It can be used with PHP and with other CGI scripts.

It consists of a setuid “wrapper” binary that is called by the main Apache web server, and which executes CGI scripts with the correct used id.

+ Tried and tested

+ Can be used with other languages than PHP

- Low performance without FastCGI (similar to suPHP)

- Separate script files are a minor hassle

Module: mod_suPHP

mod_suPHP makes PHP scripts execute with the user id and permissions of their owners.

It consists of an Apache module (mod_suphp) and a setuid root binary (suphp), which calls PHP as a CGI process.

+ Easy to install, in RPMForge repo (http://wiki.centos.org/AdditionalResources/Repositories/RPMForge)

+ Quite commonly used

- Low performance relative to others (similar to suEXEC)

- PHP specific solution

= Recommended for low load sites which are not using their resources to their limits.

Module: FastCGI (mod_fastcgi or mod_fcgid)

mod_fastcgi and mod_fcgid implement process persistence between page views and communicate with PHP using FastCGI. They do not by themselves perform privilege separation, suEXEC is needed.

+ Decent performance when using suEXEC with FastCGI, similar or better performance than mod_php has been reported

+ Can be used with other languages than PHP

- FastCGI may require more memory because there are more persistent processes (more suited for servers with a lot of memory)

- Separate script files are a minor hassle

= Recommended for higher load sites.

MPM: mpm_itk and mpm_peruser

These are alternative MPMs for Apache that replace the default preform MPM and perform additional privilege separation.

mpm_itk works in a manner similar to regular CGI scripts in that it does not reuse processes after each request. However, unlike CGI scripts, it invokes each process with the user id and group specified for that virtual host.

+ Neat solution with decent performance, some systems have it in the repos

- Must patch and compile separately in Centos

- Not as commonly used as suEXEC or suPHP

= Recommended as a upcoming solution that is higher performance than mod_suPHP and easier to setup than suEXEC+FastCgi.

mpm_peruser creates one or more apache child processes for each unique user/group, each handling its own set of virtual hosts.

+ Faster than mpm_itk

- Must patch and compile separately in most systems

- Development and adoption seems to be more limited than mpm_itk

1. To write about things you care about for yourself

Have I succeeded? Yes. This is probably the goal I am most satisfied with. I find myself referring back to my own posts (e.x. on how to setup DKIM on Centos, or how to implement semantic naming in CSS), which I think is an indication that what I write has longer-lasting value to me.

Lesson learned #1: Writing helps you clarify your own thoughts. To me, this not an online diary – my blog is my online whiteboard.

Lesson #2: Writing a blog helps you with expressing your ideas briefly. Writing a blog has been educational, because one needs to really stick to simple, short and easy-to-skim posts. My point of comparison is academic writing, which is much more rigorous with the details and definitions of concepts. With blog posts, you can’t do that because of space limitations.

Lesson #3: The best test for content you write in my opinion is whether you would give a damn if someone else wrote about this very same topic. Another good question is whether you think you will give a damn in a week, a month or a year? Not all content is evergreen, but I do think it should either be something worth revisiting/updating later; or if that is not possible at least timely and helpful.

2. To learn about marketing and publicity without having to face high stakes

Have I succeeded?Not really. Writing a blog has kept the thought of marketing it in the back of my mind, but so far I have done very little about it.

Lesson #3: Headlines and searchability matters. As of now, I have about 2000 monthly visitors, or 60-70 per day. Most of that traffic comes from Google searches on the relevant topic. The posts that get no traffic are those that have a title that no-one searches for.

Lesson #4: Blogging is about taking part in a conversation with other people. If you want traffic, you need to interact with other blogs and contribute. Search engines can only give you the traffic that cares about that specific topic, long-term engagement seems to be a result of building connections and referrals.

Lesson #5: A blog is an extension what you do offline. No point in getting obsessed with getting referred to online if you do not connect to people in the real world. I’d prefer my blog to be a convenient way of learning more about me and the topics I discuss off the Internet rather than a separate endeavor.

3. Realize that the rest of the world does not, in fact, give a damn

Have I succeeded? Yes. Woohoo! Nobody cares, and I don’t give a damn. As Derek Sivers said, “Nobody’s going to help you. Does that encourage you or discourage you?”

Lesson #6: In my opinion, if something is worth doing, it’s worth doing whether or not other people give a damn.

One of my favorite recent quotes is from James Stockdale, a Vietnam POW: “You must never confuse faith that you will prevail in the end—which you can never afford to lose—with the discipline to confront the most brutal facts of your current reality, whatever they might be.” That nobody cares is a reality, and if that makes you feel like crying, you might as well not try.

What will 2010 look like?

What I will NOT do:

I’ve made a Finnish translation for the Wordpress Subscribe2 -plugin, download it here: subscribe2-fi.zip

Upload the subscribe2-fi.mo file to the wp-content/plugins/subscribe2/ directory. If WPLANG in wp-config.php is something other than the default “fi”, then change “fi” in the filename to the correct value.

I was reminded again how hard it is do proper translations in Finnish because of the differences in word order compared to English, e.g. “For digest notifications, date order for posts is” -> “Yhteenvetomuotoisissa päivityksissä artikkelien (aika)järjestys on”…

If you want to improve the translation, open the .po -file in Poedit or some other editor. The translation was done in one go, so I some of the wordings could be improved. (Then again, the terminology in the Finnish Wordpress itself is sometimes rather confusing.)

Asennusohjeet

Tein suomenkielisen käännöksen Wordpressin Subscribe2 -pluginiin, lataa se tästä: subscribe2-fi.zip

Lataa tiedosto subscribe2-fi.mo kansioon wp-content/plugins/subscribe2/. Jos WPLANG -kohta wp-config.php -tiedostossa ei ole “fi” (oletusarvo suomenkielisessä Wordpressissä), muuta “fi” tiedostonnimessä oikeaan arvoon eli WPLANG:in mukaiseksi.

In my opinion, there are two parts to the problem:

1. the easy part, which is to apply JS programming patterns
2. the hard part, which is doing so in a consistent and maintainable manner

The easy part: Namespaces, modules and commenting conventions

Namespace and module pattern

Javascript has no explicit syntax for advanced language features such as namespaces and private variables, but these can be implemented using very simple programming patterns.

A lot has been written on the namespace and module pattern, so I will only illustrate it here.

I like to add a “placeholder” function shown below to prevent me from making errors while modifying the module (IE6 freaks out if there is a comma after the last item). This used to happen when I moved or added the methods and forgot to check whether that the commas are correct.

The example code below is adopted from (http://yuiblog.com/blog/2007/06/12/module-pattern/):

// create a namespace
YAHOO.namespace("myProject");
// Assign the return value of an anonymous function to the namespace
/** @namespace */
YAHOO.myProject.myModule = function () {
	/** @private */
	var myPrivateVar = "I can be accessed only from within YAHOO.myProject.myModule.";
 
	/** @private */
	var myPrivateMethod = function () {
		YAHOO.log("I can be accessed only from within YAHOO.myProject.myModule");
	}
 
        /** @scope YAHOO.myProject.myModule */
	return  {
		/** describe myPublicProperty here */
		myPublicProperty: "I'm accessible as YAHOO.myProject.myModule.myPublicProperty."
		/** describe myPublicMethod here */
		myPublicMethod: function () {
			YAHOO.log("I'm accessible as YAHOO.myProject.myModule.myPublicMethod.");
 
			//Within myProject, I can access "private" vars and methods:
			YAHOO.log(myPrivateVar);
			YAHOO.log(myPrivateMethod());
 
			//The native scope of myPublicMethod is myProject; we can
			//access public members using "this":
			YAHOO.log(this.myPublicProperty);
		},
		/**
		* A placeholder function to prevent errors due to not having a comma after the last function in the return statement for this module.
		*/
		placeholder: function () {}
};
 
}(); // the parens here cause the anonymous function to execute and return

Commenting conventions. Pick a commenting tool and stick with it. Comment the intent of the code and any gotchas as well as the expected arguments and purpose of methods.

The two main JavaScript commenting tools are: JsDoc-Toolkit (self-contained Java) and YuiDoc (Python).

File names and splitting code into files. Put all the hard-to-reuse code into its own namespace (ex. Framework. ModuleName. ModulePart.ApplicationName) in a separate file (application.js or custom.js). This way you keep the library clean of any application-specific stuff. It is often hard to avoid implementing some things in a one-off manner, so you might as well organize all the single-use stuff in its own file.

That is, if writing your own extensions to an existing framework, you will most likely have:

1. code that is fully reusable (specialized or pre-configured widgets, utilities etc.)
2. code that is hard or pointless to reuse (page- or application-specific messages, formatting and utilities)

The hard part: structuring code for reuse, logical naming conventions

Structuring code for reuse. Encourage reuse by splitting code into configuration, implementation and customization.

1. Configuration is anything that might need to change on each instantiation of your widget. It should be single section within a module (a private object in JSON notation). Make sure you have good and documented defaults, because this makes it easier to use the code again.
2. Implementation is the main code. It should NEVER contain hardcoded ID’s, messages or other things that will eventually need to be overridden.
3. Customization is a set of page-specific blocks of code that alter the configuration. You only override the few things that are needed for the specific functionality on the page.

Here is an example (from http://www.wait-till-i.com/2008/05/23/script-configuration/):

myProject.myModule = function(){
// CONFIGURATION
  var config = {
    CSS:{
     classes:{
       hover:'hover',
       active:'current',
       jsEnabled:'js'
     },
     ids:{
       container:'maincontainer'
     }
    },
    timeout:2000,
    userID:'chrisheilmann'
  };
 
  // IMPLEMENTATION
  function init(){ };
  // make init and config public
  return {
    init:init,
    config:config
  };
}();
 
// CUSTOMIZATION
// This makes it possible to override stuff before calling init
module.config.CSS.ids.container = 'header';
module.config.userID = 'alanwhite';
module.init();

Naming conventions. I don’t mean deciding whether or not to use camelCase, but rather how the logical organization names of variables and widgets should be done. It is reasonably simple to stop using global variables and functions to avoid name conflicts, but what is harder is to come up with a logical naming convention that allows any code to be reused anywhere.

In particular, when you create new widgets, you often need to be able to connect them to one another in some manner. Being able to identifying the type (class) and retrieve/replace data from a new widget using a standard interface takes some planning and a lot of discipline, but it makes reusing the widgets much easier.

ID and name attribute naming convention. I use “data[widgetName][recordIndex][fieldName]” for input names (because PHP will parse this into arrays automatically) and “widgetName_fieldName_recordIndex” for ID attributes (because it makes string comparisons easier).

Widget instance naming convention. I use YAHOO.ApplicationName.WidgetInstanceName for widget instances, and use WidgetInstanceName to create any related tags with IDs.

I am still looking for a good logical naming convention for widgets, but it seems this topic is not as commonly discussed. If you have any tips, please leave a comment!

Reference stuff

http://stackoverflow.com/questions/211795/are-there-any-coding-standards-for-javascript

http://ajaxian.com/archives/maintainable-javascript-videos-are-now-available

http://yuiblog.com/blog/2007/06/12/module-pattern/

http://www.wait-till-i.com/2008/05/23/script-configuration/

MVC frameworks: full stack vs. glue frameworks

There are the two basic options with MVC frameworks: glue frameworks and full stack frameworks.

1. “Glue frameworks” are collections of components and libraries which you can use to build an application. Most of the functionality is optional and often you must make decisions regarding how you will structure control flow within your application.
2. “Full stack frameworks” are integrated sets of components in which most of the components and libraries are mandatory and most of the design decisions have been made for you in advance.

How full stack frameworks sometimes get in the way: an example

Most frameworks are optimized for the 0-3 month project. All the basic functionality you need is there, but the expectation seems to be that you are creating a custom version of a blog or a CMS and that the most complex bits will be the views (custom code) and the models (posts, users, tags, comments). However, the more you’re dealing with complexity with regards to business logic, integration, regulatory validation and scaling requirements, the more likely it is that a full-stack framework will require manual optimizations and supplementary mechanisms which are not easily implementable in a full stack framework.

Here is one example of how a full stack framework can end up in more complexity than a glue framework. In CakePHP (a full stack framework), if you want to show multiple “flash” messages, you have to rather actively work around the existing mechanism, because it does not support multiple flash messages easily. Yes, you can set one message per action and you can set custom styles, but setting more than one message becomes unnecessarily complex (see this article and have a look at the comments as well) because by default, the Session flash messages overwrite each other rather than appending to the existing set of messages.

This is a very trivial example – and you can use the existing Session classes to create most of the functionality necessary to fix this. But if you do that, you will end up with two “flash” message functionalities: the default one and the one you built to make it easy to set more than one message of each type.

A glue framework might offer the Session functionality without directly supporting flash messages. This does mean that you have to write your own, but you’ll end up with a slightly simpler codebase. These kinds of small things add up if you have a larger project.

Now, the key question to me when deciding which to use is:

What kind of complexity/problems are you tackling in your application?

The optimal choice of framework depends on covering the 80% case effectively (without compromising constraints like performance).

Here are some questions to consider when picking the right framework for your project:

1. Complex views – What are the most probable uses of the system? Make sure you can cover the technical functionality needed to implement the most important client goals in a way that delights or at least does not annoy your customer. What is key here is the user experience you can deliver, not just technical sophistication.
2. Complex data structures – What data structure requirements are most likely to change? If possible, pick an architecture that makes the most likely changes relatively cheap to make. This may imply a tradeoff of some kind with other functionality.
3. Complex business logic – What are the key concepts and processes, and how are these likely to change? How easy is it to create exceptions to the rule and how can rules be verified and tested?
4. Complex integration – What are the key connecting technologies, and how well are they supported by the framework? Ideally, you can use pre-existing and tested code to integrate key areas.
5. Strict performance requirements – What is the everyday workload going to be? What mechanisms will allow you to identify bottlenecks in the system? Is there a possibility to optimize functionality by scaling horizontally or by bypassing some unnecessary functionality?
6. Scaling requirements – How can you partition your workload? How well do the core mechanisms lend to custom enhancements to fulfill scalability requirements?
7. Strict schedule requirements – What is the minimum feature set? How well does the framework support rapid implementation and testing of the minimum feature set? What are the main dependencies, and are there pre-existing modules or plugins for them?

If what you are building is not particularly complex, or the primary complexity is in building the views, then a full-stack framework is likely to be a great choice – particularly if you are have a very limited schedule. An example of this would be a brochure website, which has most of its complexity in the views.

The larger and more complex the application, the less likely you are to obtain significant productivity gains from using a framework. This is simply because having a framework can at best save you a few hundred hours of work (which should be more than what it would take for you to replicate the functionality you use). If the project is big, the time saved doing this becomes less significant compared to the time needed to build the rest of the application (e.g. the useful parts).

On a surface level I believe it is rather easy to agree with the Agile values. Working in a small company, whether or not the right things are done comes down mostly to a question of self-discipline: there is a number of time-consuming and less exciting things that have a high payoff, but are not done because each person (this includes you, reader) has a preferred way of working. In most cases this good: second-guessing oneself is hardly productive. But in order to actually benefit from best practice one must not only be aware of it but also try to implement it as best possible – blindingly obvious, but somehow frequently ignored.

McDonald et al. (2008) make an interesting reference to Auguste Compte’s Law of Three Stages from 1830. The law proposes that a scientific discipline progresses through three stages: theological (belief-based knowledge), metaphysical (philosophy-based knowledge) and positive (based on scientific reasoning). The authors (each with SW development background of at least 20 years) propose that the Agile movement and manifesto represent a move from belief-based practices towards the second, philosophical stage. This is interesting because it implies that they see Agile (with a big A) is still more as a philosophy than a full methodology – or more importantly, that doing Agile well requires that you pick and define an overall framework within which you apply the Agile principles.

In a post on his website, Scott Ambler asks five questions to help determine whether a team is Agile:

1. Is the team is doing developer regression testing, or better yet taking a test-driven approach to development?
2. Are stakeholders active participants in development?
3. Is the team producing high-quality, working software on a regular basis?
4. Is the team is working in a highly collaborative, self-organizing manner within an effective governance framework?
5. Is the team improving their process on a regular basis?

Some further questions

I think these are very good questions to identify whether the Agile principles are used in developing software. But if you are thinking about implementing Agile practices, you ought to also be able to answer further questions about the underlying process:

1. What are you doing to detect, predict and prevent defects? “Regression testing” is not an answer: what part of your testing is automated? What is the role of practices such code reviews, test scenario development and design validation in your process? Who is responsible for quality assurance and how are defects tracked?

2. How do you manage and communicate requirements? Who talks to the stakeholders? How do you disseminate the information? How do you track fulfilled and unfulfilled requirements? How do requirement changes influence planning and scheduling?

3. How are you ensuring that quality and security concerns are addressed and that lessons learned from previous projects are remembered?

These are just a few process-related questions off the top of my head.

Why can’t you answer?

If you can’t answer, or aren’t doing one or more of these practices, ask why not. My answer to “why not?” is that this is a result of a lack of appreciation of whatever the unimplemented best practices could bring, such as: automated testing, active stakeholder participation, better scheduling or controls, self-organization or process improvement accountability. While these are best practices, that does not mean that adopting them is always in the personal interest of the participants of the software development process. For example:

1) Active stakeholder participation may not be valued because it is considered to be customer interference rather than a method of increasing the focus on customer value, or it may not be valued because a consultancy may prefer to have a costly billable change process.

2) Better scheduling or controls may be seen as overhead and micromanagement by developers.

3) Increasing accountability for mistakes may be uncomfortable and thus seen as undesirable.

To me, the key question is how can we can raise the perceived value of these practices in order to create the internal motivation to implement these processes more stringently – and hence hopefully realize the benefits of best practice in our organization?

Example: TDD

For example, let’s look at why TDD might not be valued.

Regression testing / test-driven development may not be seen as valuable because of beliefs such as “the real work of development is implementation” and “quality is achieved by molding software into shape by correcting defects” (McDonald et al. 2008). What could be done to create the internal motivation to implement TDD?

One part would be to examine these beliefs and examine the benefits of defect prevention via TDD. In particular, it may be that the negative impact of the ripple effect of flaws on dependent functionality and the cost in customer satisfaction are underestimated.

Second, there is a larger question of whether quality ought to take precedence over other potential priorities – because focusing on quality does not mean following best practices only when they are convenient, and throwing them out when the going gets tough. Would you trade intangibles such as quality over tangibles such as lines of codes or number of features or maintaining a release schedule? A quality-oriented organization ought to choose quality over features or schedule and be confident that this will still lead to a better result than prioritizing features or schedule.

Third, there ought to be an increase in emphasis on the test and quality assurance results as a deliverable. Are your test results a deliverable, and do you actually deliver them? Can you make them a deliverable? By making it clear that the results of an intangible activity are still deliverable and are visible work will increase their perceived value. An internal report may be less important than a report going to the customer (even if the report is an aggregate) and will likely help shift the emphasis from an internal, optional activity to a deliverable, required activity.

The only caveat has been the performance – I was so frustrated I installed (and ultimately rejected) the vast majority of other (PHP) editors. There is a simple fix if you have memory to spare: increase the heap size in the startup options. The Java VM default heap size seems to be way too small, causing a lot of swapping within the Java VM (while not using all the memory available from the OS perspective).

Fixing Netbeans scanning performance

Open /etc/netbeans.conf (e.g. C:\Program Files\Netbeans 6.x\etc\netbeans.conf). If you are on Windows 7, you need to start your text editor with Administrator privileges (right click and select Run as..).

Change the line: netbeans_default_options=”-J-client -J-Xverify:none ….”

by adding the following to the single line (AFTER “-J-client -J-Xverify:none”):

-J-Xmx2048m -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled
-J-XX:+CMSPermGenSweepingEnabled

The -Xmx option changes the maximum heap size the Java virtual machine can address to 2048M from the default value (which is a “best guess” method). The other three are explained in the conf file.

DONE! Ever since I made this tweak (about two months ago) there have been no additional pauses at all. My theory is that the Netbeans scanning code was exhausting the heap, and a majority of the time “scanning” was instead spent dealing with the heap exhaustion. Now I will not say that it is reasonable for an IDE to consume 2 gigabytes of memory – but if that’s what it takes to fix performance, fine.

Take for instance:

1. Writing a CV. Best practice states that shorter is better, but oh so many people still want to have an eight-page CV because they are special.
2. Web frameworks. Best practice states that using an established, documented and supported framework is better, but look at the proliferation of different MVC frameworks, ORM systems, CSS frameworks et cetera. And these are just the published examples: there are many many more in private use, because the authors were special and had special needs.
3. Pitching. Best practice states that you should rehearse, keep your presentation short and focused, you should do market research and you should not rely on “chinese math”. Yet we have tons of pitches which are not rehearsed, overly long, unfocused, unresearched and based on lazy assumptions – because people expect to succeed because they are special.
4. You can probably think of ten more examples pretty quickly.

Why oh why do we have to be in this situation? Can’t other people figure out that we don’t care about their overly long CV, their self-authored web framework and boring, unrealistics pitches?

The “I’m special” excuse

I hate the excuse that someone is special, and therefore does not need to follow good advice. And yet I find myself compelled to, for instance, write my own web framework. 

As always the problem is other people. And the worst thing is that to other people, you are another person!

I will stick with the web frameworks example, because it is so common and easy to recognize as a problem.

Writing your own web framework – are you really that special?

Why on earth would anyone want to reinvent the wheel by writing yet another web framework? The justifications I think come down to one of:

1. Speed. The existing web frameworks are slow, because whomever wrote them was either incompetent or because they included the kitchen sink with their framework.
2. Ease of coding. The existing web frameworks are horribly documented, and you prefer to reinventing the wheel to reading API documentation.
3. Unique problems or novel ideas. You have a really unique problem or a really innovative new idea, and the existing frameworks do not support it.
4. Learning experience.

And here are the reasons why you shouldn’t be doing it:

Speed.

Assume for a moment that all other developers are not incompetent (I know, it’s a huge jump for someone as special as you!). This implies that the reason frameworks are slower is that they have more features, which inevitably increases execution time. Thus you can quite safely assume that by the time you reach the same level of functionality as any top-tier web framework, you will be equally slow or slower.

The only way you will reach that point and know for sure is through grueling reinvention of the wheel.If you want certainty about performance, pick a reasonably fast existing framework and go make it slower by adding your own functionality. As Don Knuth said: “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”

How many times have your customers called you and complained about performance? I’m not saying that performance does not matter – it clearly does – but this isn’t likely to be the most significant business, or even technical problem you encounter.

Ease of coding

The lack of documentation is in my humble opinion a valid criticism of existing frameworks. While some documentation and tutorials exist for existing frameworks, the state of documentation in PHP web frameworks is rather bad.

However, how well documented is your own framework? You will be familiar with it when coding it, but what about five years from now? What about the other people you will want to add if your project succeeds?

Unique problems or novel ideas

How unique are your problems? Most of what web applications is a variation of a theme rather than a wholly novel problem. In fact, I have a hard time thinking of a counterexample. It is true that some frameworks make working with complex backend logic harder – but this is more a matter of picking the right framework; having the perfect framework won’t still make the backend logic any more simple.

Is your novel idea actually useful? Imagine that you had built that crazy new framework with that neat idea – how much time would it save you in practice?

I’m pretty convinced that this reason is in fact just an excuse for not liking the aesthetic feel of whatever frameworks were evaluated, rather than a real reason. The core reason is that whatever you are doing is complex, and having your own framework will only provide a slight relief at a huge maintenance cost.

Learning experience

I think this is a legitimate reason. There is no substitute for learning by doing – but if you deploy that code into production, you are no longer learning: you have gone into the business of framework maintenance.

The main technologies are reverse DNS checking, SPF, SenderID, Domainkeys and DKIM. I will discuss all of these here and provide my tips on setting up SPF, SenderID and DKIM. Please keep in mind that I am not an expert on email servers – but I hope this helps someone! It took me about half a day to figure this all out, so it is probably worth doing to improve your email delivery rates.

This blog entry from Dave Zohrom provides a nice discussion of sending email to a general audience (part 2 of a 3-post series).

Introduction

SPF or Sender Policy Framework

SPF is easy to setup. It uses DNS TXT records to allow the email providers to check which servers are authorized to send email for a particular domain. The SPF project has done a great job at making this simple to setup. Just go to their homepage and use the setup wizard to generate the appropriate TXT records (the text field underneath “Deploying SPF”). Then change the values in your DNS records.

One thing to note is that if you have multiple servers and send email from a server with a different hostname (e.g. “mail.example.com”), you need to setup a record for that server as well. See the common mistakes page on the SPF site. Also, if you have hostnames that are not supposed to send mail, you ought to indicate this as well.

Another thing is that if you are using Google Apps for Your Domain to send email, then you will need to have to add “include:aspmx.googlemail.com” to also allow mail from Google to validate. See this answer for more.

SenderID from Microsoft

SenderID is a variant of SPF, which for most practical cases is the same as SPF. Just setup SPF and this should produce a validation pass for SenderID as well. The semantics of the validation are a bit different,  but this does not seem to be a major practical problem. See testing tips below to make sure that this is also true in your case.

DomainKeys

DomainKeys is an older version of DKIM (DomainKeys Identified Mail) developed by Yahoo. Despite having very similar names, these ARE NOT the same!

Both DomainKeys and DKIM store public key information in DNS records and sign the message headers of every email sent. The recipient can then verify the signature.

DomainKeys was deprecated in 2007, but some email providers may still be using it. However, these are a shrinking minority and Yahoo does support the newer DKIM. Because of this I did not add DomainKeys support but opted only to use DKIM.

You can add it to sendmail or Postfix using the dk-milter project code, but the unofficial RPM release is not maintained anymore, which means you will need to install it from source (available via SourceForge).

DKIM, or DomainKeys Identified Mail

DKIM on the other hand seems to be gaining momentum. It is used by Gmail, Yahoo and AOL and many others, and also works by publishing public keys via DNS TXT records and by signing the emails at the email server.

To setup DKIM, you need an additional filter which takes the completed email and adds the DKIM signature to the email prior to sending it out.

Postfix and sendmail support “milters“, which is apparently short for “mail filter”. There is a DKIM-milter package available for Centos at the EPEL repositories (see Centos page for 3rd party repos).

Setting up DKIM-milter with sendmail

For Postfix, use these instructions from All About LAMP. If you want to use sendmail as I did, here are my additional tips:

Steps 1-7 as in the linked tutorial.

Step 8. Configure dkim-milter

Open configuration file /etc/mail/dkim-milter/dkim-filter.conf and use the following configuration:

Canonicalization simple
Domain example.com
KeyFile /some/path/to/whatever-your-keyfile-was
Selector name-of-the-selector
SignatureAlgorithm rsa-sha256
Socket inet:8891@localhost
Syslog Yes
Userid dkim-milter

NOTE: you will be configuring dkim-milter to use the loopback interface instead of a socket file. I was unable to get dkim-milter to work via the socket file with sendmail. If you get it working, let me know.

You may also want to setup the following:

SubDomains Yes
SyslogSuccess Yes
X-Header Yes

The X-Header and Syslog options are useful for debugging. See the config file, each option should be documented there.

Step 9. Change the default init.d script to use the loopback interface

The default init script uses a socket, this needs to be changed. Open /etc/init.d/dkim-milter and change/comment the line:

SOCKET=local:/var/run/${name}/${name}.sock

to:

SOCKET=inet:8891@localhost

Step 10. Configure sendmail to use dkim-milter

First a few reminders about sendmail configuration, remember that:

1. Sendmail comments DO NOT USE # as the comment, instead “dnl”  (delete through newline) at beginning of the line is used to comment lines out.
2. Sendmail configuration is built from the *.mc script files using the M4 macro processor.
3. You need to install the sendmail-cf package for dependencies and install the m4 macro processor separately.
4. In the configuration, the opening quote is a grave accent ` and the closing quote is a straight quote ‘.

To configure sendmail, open the “/etc/mail/submit.mc” file (which contains the settings for message sending; in older sendmail versions this config was in sendmail.mc).

10.1 Edit submit.mc by adding the following entry to it:

INPUT_MAIL_FILTER(`dk-filter', `S=inet:8891@localhost')dnl

(for example just before “FEATURE(`msp’, `[127.0.0.1]‘)dnl”). Make sure that there are no define(`confINPUT_MAIL_FILTERS’, `…’)dnl lines after this; if there are, you will need to add dkim-milter manually to the INPUT_MAIL_FILTERS list.

10.2 Build and install a new submit.cf:

m4 /etc/mail/submit.mc > submit.cf

Tip: use m4 -d /etc/mail/submit.mc to debug first.

10.3 Restart sendmail

service sendmail restart

Testing tips

Some possible errors:

1. Errors getting the sendmail configuration generated: Check whether the dependencies (m4 and sendmail-cf) are installed and paths are correct.
2. Errors starting sendmail: Make sure you replaced the correct files (submit.mc to submit.cf and sendmail.mc to sendmail.cf) and if you modified sendmail.mc in addition to submit.mc, make sure you have regenerated both.
3. Errors starting dkim-milter: check the permissions on the key file
4. Sendmail seems to ignore the dkim-milter, no X-dkim-milter header is in the mail even after you enabled the X-Header option in dkim-filter.conf:
   1. Check /var/log/maillog.
   2. Sendmail seems to default to ignoring the milter if it cannot connect to it. This was the problem I ran into when using sockets; after switching to the loopback interface everything started working.
   3. Also, check whether your mail is sent from a recipient for whom mail is supposed to be signed! If you haven’t setup your hostname, then this may lead to email not being signed (eg. hostname -F hostname plus /etc/hosts plus /etc/sysconfig/network).  See, for example this tutorial for configuring sendmail.
   4. Also, check if you need to configure masquerading for Sendmail, see http://www.sendmail.org/m4/masquerading_relaying.html

Sending email from the console using only sendmail

Create a file with the following content:

To: "Recipient name" <john.doe@example.com>
From: "Sender name" <admin@example.com>
Reply-To: admin@example.com
Subject: Hello world
This is the content of the message, end it with a line containing only a period as sendmail expects this.
.

Then cat the file and pipe to sendmail -t:

cat message.txt |sendmail -t

Checking all of the technologies mentioned above

Port25.com offers a free service which check SPF, SenderID, DomainKeys and DKIM: http://port25.com/domainkeys/

Quote:

• If you wish to receive the results at the address in the “mail_from,” the sample message should be sent to check-auth@verifier.port25.com.
• If you wish to receive the results at the address in the “from” header, the sample message should be sent to check-auth2@verifier.port25.com.

A reply email will be sent back to you with an analysis of the message’s authentication status. The report will perform the following checks: SPF, SenderID, DomainKeys, DKIM and SpamAssassin.

Additional resources:

How to Setup DKIM for Postfix in Fedora using dkim-milter

How to Prevent Web Server Emails from being Marked as SPAM

DomainKey Implementor’s Tools and Library for email servers & clients

Sendmail DKIM

Setting up DKIM, SPF, Domainkeys DNS, Regular DNS on CentOS 5.3 at Pacificrack.com

How to manually install DKIM-Filter with Sendmail

Over the years I’ve read quite a pile of books particularly related to programming, general business, entrepreneurship and software engineering. Now that I am reading up on new topics such as organizational development, lean methods and statistical research methods I am having real trouble finding books I would consider reading just based on the table of contents and Amazon reviews. This is probably a good thing, since the most efficient way to get information is to only read good books.

Here are a couple of guidelines for picking good non-fiction books:

1. Number of reviews. If there is only a small number of reviews, there is a risk that those reviews are written by the author or his/her friends. A book with more reviews is more credible, as is a book which has had more editions.
2. Distribution of reviews. If the reviews are split between 5-star and 1-star reviews, the 5-star reviews are most likely fake. This is an absolutely disgusting practice, but unfortunately common.
3. Credentials of the authors. If the authors are practitioners and not scientists, make sure they do not work for a consultancy. I have unfortunately 1-2 books that I did not check adequately and ended up getting a useless brochure book.
4. The table of contents.
   1. What is the starting point of the discussion? This defines the prerequisite knowledge that you are expected to have. Reading a book which is for beginners is incredible boring, while reading an advanced book as a beginner is frustrating.Evaluate whether you have the prerequisite knowledge and could read the first few chapters without getting bored to tears. Remember that most popular business books are written for an audience that reads just a few books per year – this pretty much makes them too repetitive if you read more than that.
   2. What is the emphasis of the book? Is it oriented towards: a) practice or b) checklists, c) proper theory or d) undergraduate students textbook? (See below for more)
   3. How many pages are dedicated towards each topic? Don’t expect anything good from a book that has a 200 pages and cover 200 topics: that’s just one tiny page per topic.Good books don’t cover everything with the same small amount of pages, because everything is not equally important in real life.
5. The actual content of the reviews. Don’t bother with 5- or 4-star reviews, they will just tell you the book is good. Read the 1-star and 3-star reviews.See if the 1-star reviews seem to be justified or are just a result of the reviewer being an idiot (e.g. “Haven’t received book from Amazon” or “This book is too difficult” -reviews).3-star reviews are usually the best, since the author did like some aspects but did not like others. Pay attention to reviews that say that a book is too basic or simple. If this is said more than once, you probably don’t want to read that book – American writing in particular is already very verbose and too many books are written where a five-page article would do, hence reviews which state that the book is too simple should be taken very seriously.
6. Number of and affiliation of authors. If all the authors are from the same institution or organization, the book is probably of lower quality. A huge warning sign is a “collection” book that has multiple chapters on different topics by the same authors, all from the same decade. This indicates that the authors have not bothered to contact the people who are at the top of their respective fields; articles which are all from the same decade are likely to be just a random set of articles which were written for the book rather than the result of good editorial work.
7. Order of topics. Scientific collection books usually order the chapters so that the better and more widely applicable material is at the front of the book, and the more specialized and less interesting material is at the end. It is safe to assume that if the chapter that seems decent for your purpose is at the end of the book, you are better off finding a more specialized book.

Four classes of books:

I would put books in four broad categories, two of which are useful and two are useless:

1. Practical books
2. Academic books
3. Ego-booster books
4. Motivational books

Practical books: experience-based vs checklist books

Practical books are in my opinion divisible into two categories: advice from practitioners and advice from people who like to write checklists. That is, you have books that are based on the experiences of a practitioner, and then you have books that are written by people who have not actually done that much but wanted to write a book and ended up writing a checklist – a list of things that might be of use without really emphasizing what is important.

Try to get a feel of the book from the preview (if you can’t, don’t buy it!), search for a couple of phrases that interest you. Does the author know what they are doing, or are they just collecting information from other people? Sometimes a “checklist book” is not bad – when you just need the basics and can’t be bothered to collect all the information. However, usually the experience-based book is better.

Academic books: theory vs textbook

When it comes to academic books, the two main types are proper theory books and textbooks. The more I have seen and read textbooks, the less I like them. Generally speaking they try to cover everything and end up saying nothing.

If you care about the topic, don’t get a textbook. Instead, get a proper collection of influential articles if it exists (ex. Oxford Handbook of X). You will perhaps not be fully prepared for everything you read, but you will learn something useful. Unlike after reading a textbook, where you just have fuzzy awareness of the fact that “all kinds of things happen” in a particular field.

Ego-booster books: academic and practical

There is also another category of books which are basically books written for the author’s ego. Some books are not written to be read, they are written either to impress others or to act as marketing tools.

The academic substitute for having a nice car sometimes seems to be writing an obtuse treatise which is downright hostile towards the reader, while consultancies in particular are guilty of writing books in which the answer to every question is “hire our consultancy”. The academic ego book is harder to spot, so pay attention when previewing the book.

Motivational books: feeling good doesn’t make it so

Finally, there is a category of fiction books which pretend to be non-fiction books. The motivational books may be a fun read at times, and are usually the most popular books in their category.

However, they are fiction for your entertainment. Feeling good is nice, but that does not change the fact that there are people who are knowledgeable, talented and well-connected doing whatever the book is about, and that feeling good does not make you knowledgeable, talented or well-connected.