Configure pure-ftpd in Debian

January 27th, 2010

Currently there is a lack of good documentation about how to configure pure-ftpd in Debian and Ubuntu. It’s easy to find information about the command-line flags for pure-ftpd but in Debian you are supposed to use files in the /etc/pure-ftpd/conf directory. Information about what filenames to use and what they should contain is hard to find, so here is a list that translates the command-line flag to filenames.

Not all files requires a contents, it’s sufficient if you just “touch” it. See the pure-ftpd documentation for details about the flag values.

Flag Filename Value
-W AllowAnonymousFXP
-z AllowDotFiles
-w AllowUserFXP
-O %s AltLog string
-t %s AnonymousBandwidth range
-M AnonymousCanCreateDirs
-i AnonymousCantUpload
-e AnonymousOnly
-q %d:%d AnonymousRatio range
-s AntiWarez
-r AutoRename
-S %s Bind string
-b BrokenClientsCompatibility
-o CallUploadScript
-A ChrootEveryone
-j CreateHomeDir
-Z CustomerProof
-B Daemonize
-D DisplayDotFiles
-H DontResolve
-P %s ForcePassiveIP IP-number
-F %s FortunesFile string
-4 IPV4Only
-6 IPV6Only
-K KeepAllFiles
-L %d:%d LimitRecursion range
-1 LogPID
-c %d MaxClientsNumber
-C %d MaxClientsPerIP integer
-k %d MaxDiskUsage integer
-I %d MaxIdleTime integer
-m %d MaxLoad integer
-u %d MinUID integer
-N NATmode
-E NoAnonymous
-R NoChmod
-G NoRename
-0 NoTruncate
-p %d:%d PassivePortRange range
-y %d:%d PerUserLimits range
-X ProhibitDotFilesRead
-x ProhibitDotFilesWrite
-n %d:%d Quota range
-f %s SyslogFacility string
-Y %d TLS integer
-a %d TrustedGID integer
-V %s TrustedIP IP-number
-U %s:%s Umask file:dir
-T %s UserBandwidth range
-Q %d:%d UserRatio range
-d VerboseLog

There is a bugreport for this problem so hopefully it will be fixed in the future.

Smarty for e-mail templates

November 29th, 2009

As you’ve realized Smarty can be used to more than just site templates. You can set up templates for almost anything, for example e-mails. When you do this you have to decide on an approach, and I’ll cover three of them here.

Simple and straightforward
You can see this approach in the Smarty manual. The template simply states the message body, and if you have multiple bodies, say one in plain text and one in HTML, you can do like this.

mail.text.tpl:
Hi {$name},

You've got mail!

mail.html.tpl:
// HTML-header here
<body>
<h1>Hi {$name},</h1>

<p>You've got mail!</p>
</body>

Now you can simply fetch your two versions of the mail body and use them with your PHP code to send mails. The benefit here is that you keep a good abstraction, the person who makes the mail templates does not have to care about hos the mail is sent. A drawback is that you can’t store all information for this e-mail in one place; where do you store the subject?

The advanced solution
The advanced solution creates just one template containing all data needed for the e-mail message. Your template could look like this:
gotmail.mail.tpl:
Date: {$mail.date|date_format:"%a, %d %b %Y %H:%M:%S %z"}
From: "{$sender.name}" <{$sender.email}>
To: "{$recipient.name}" <{$recipient.email}>
Subject: New mail

Hi {$recipient.name},

You've got mail!

Here you just fetch the mail data and sends it. The benefit is that you store all data related to the e-mail at the same place. The drawbacks are that this method needs extra parsing to work with the built-in PHP mail() function and the abstraction is poor since the person creating the template now has to know how to enter all mail headers as well.

Best of all?
In this version you get the benefits from the two previous versions, eleminating the drawbacks. Here we can store all information about the e-mail in the template and we can still use them when sending the e-mail using PHP. Consider this template:
gotmail.mail.tpl:
Hi {$name},

You've got mail!
{assign var="subject" value="New mail"}

Now you can, as in the simple version, fetch the template to get the body text and then use the get_template_vars() Smarty method to get the subject from the template. Just apply some more Smarty tweaking using the built-in {capture} function or simply {insert} the templates from the first example to get a multi-body message in just one template file.

The code above should be considered as proof-of-concept or pseudo code, there are a few problems not solved in the examples above.

DocBook for PHP, a tool you can’t afford to ignore

November 27th, 2009

You’ve heard it before but it’s worth mentioning again - you have to properly document you code! Programmers realized this back in the 1960s when the first industrial programming languages were defined, they came up with something called “comment lines”. For 27 years this was apparently considered enough, but in 1993 the first documentation generator was created by Eric Artzt, called Autoduck. Two years later, in 1995, a more commonly known documentation generator was released by Sun Microsystems, called Javadoc. In the year 2000 a similar generator was created by Joshua Eichorn for PHP, called the phpDocumentor and it’s this documentation generator that is the reason why I’m writing this post.

I’ve been using phpDocumentor for quite some time now but only to parse my classes to get an overview. Now I’m building a framework. I soon realized that writing a tutorial for each class wasn’t what I wanted. It’s always good with examples but it doesn’t show how a bunch of classes work together to solve a larger problem. I want to collect all documentation in one place so it’s impractical to write tutorials stored in some other place. So, for the first time I decided I’d take a look at the possibility to use external documentation with phpDocumentor.

DocBook “provides a system for writing structured documents using SGML or XML”, as stated in the preface in the DocBook documentation. It’s used in development projects like PHP and KDE. Although the PEAR manual states that DocBook should be used, nothing is said about the document type and no example is given. Instead, I found an short example in the phpDocumentor quickstart document. A more elementary example than that is hard to find, but if you combine that with the documentation about how you create a reference page in the DocBook documentation you’ll understand what you are doing. You don’t have to use the <refentry> top-level element but it is recommended if your code may become part of PEAR.

Since the phpDocumentor parses the DocBook file you can use some of the phpDocumentor syntax in your external documentation. It’s mainly two tags that you’ll use in your external documentation, and that’s the {@id} and {@toc} tags. The {@link} may also be useful to link between documents. There’s no need for me to dig any deeper in this, you can read a great tutorial about how to write tutorials for PHP at the phpDocumentor site.

Good luck!