Posted by Pat
Thu, 26 Jan 2006 07:19:00 GMT
In awstats – The Static Way, I showed you how to generate static stats pages using awstats. Shane quickly pointed out that the icons won’t work properly. I hadn’t noticed this, because awstats has very nice alt tags, but he’s absolutely right. There’s a much easier way to fix it though, and it involves using a nice (though apparently poorly documented) feature of our favorite webserver – mod_alias.
mod_alias is kind of like a simple mod_rewrite, but instead of rewriting the URL, it takes the incoming URL and maps it to a different location on the file system. This allows you to set up an single alias in your lighty config file, and use that path among all your sites. In the case of awstats, the HTML files all link to images in /awstatsicons/. If you followed my instructions though, that won’t exist. mod_alias to the rescue.
First just add mod_alias to the list of modules in lighttpd.conf. It’ll end up looking something (though perhaps not exactly) like this:
server.modules = (
"mod_rewrite",
"mod_redirect",
"mod_proxy",
"mod_access",
"mod_fastcgi",
"mod_alias", # Add this line
"mod_compress",
"mod_accesslog" )
The next thing to do is set up an alias. In our case, we want /awstatsicons/ to be accessible to every site we run, and the icons are stored in /usr/local/www/awstats/icons. So in your config file, before any virtual hosts are defined, add this line:
alias.url = ( "/awstatsicons/" => "/usr/local/www/awstats/icons/" )
Now load up your stats page, and you’ll see the pretty icons!
Final Thoughts
As you can see, mod_alias is a pretty useful module for sharing static assets. If you have a bunch of images or CSS files that you want to share among a number of different web sites, you can simply use mod_alias to set up a common URL path. Pretty slick.
Posted in lighttpd | Tags awstats, lighttpd, mod_alias | no comments
Posted by Pat
Tue, 24 Jan 2006 06:30:00 GMT
There was a post on the Rails list the other day about installing awstats on lighttpd. If you don’t know, awstats is a log analyzer tool that runs through your web server logs and generates cool stats. Since I want to see how much traffic I’m (not) getting, I figured I’d install it. Should be a breeze, because I’m using FreeBSD :)
cantona# cd /usr/ports/www/awstats/
cantona# make install clean
Now awstats is installed to /usr/local/www/awstats/. Follow the instructions on the link above to finish..took me about 5 minutes. I’d like to see if somehow I can make stats.mydomain.org automatically append the config for the incoming hostname. That sure would be sweet..might have to hack the script up a little bit.
Tip: In your lighttpd config file, you may have virtual hosts set up with something like:
$HTTP["host"] =~ "(www\.)?mydomain\.com"
I was stumped for a minute because it kept matching “stats.mydomain.com” when I didn’t think it should. Anyway, since it’s using Perl pattern matching, the key is to make sure that you check to see that the domain starts with that, which you do using ^:
$HTTP["host"] =~ "^(www\.)?mydomain\.com"
Pretty simple..regular expressions sure are fun.
Posted in FreeBSD, lighttpd | Tags awstats, lighttpd | 2 comments
Posted by Pat
Thu, 25 Aug 2005 07:22:00 GMT
Almost there!
The last thing we have to do to get the basics of this sweet environment set up is lighttpd. (I say basics because we’ll also go over SVN, mail servers, and more over time). Right now we’re going to install and configure lighttpd, and get it set up serving a real Rails app – Typo (that’s the software that runs this sweet blog).
Installing lighttpd
The mailing list and irc channel is often filled with people asking how to set up lighttpd with fastcgi and Rails. Apparently a lot of people find it really hard…in fact, I may have found it just as difficult until I learned how. I’m going to make it really easy for you.
All we’ll do right now is install lighttpd itself. I go with the default options (OPENSSL only).
# cd /usr/ports/www/lighttpd/ && make install clean
Now let’s start up lighttpd just to make sure it’s running. As with Postgres, we’ll have to add an entry to the rc.conf file. So open /etc/rc.conf and add the line:
Now we need to copy the sample configuration file, so that we can make changes to it.
# cd /usr/local/etc && cp lighttpd.conf.sample lighttpd.conf
Before we start the server, we need to create the log files it will use. The defaults are /var/log/lighttpd.access.log and /var/log/lighttpd.error.log. We need to make sure these are writable by www.
# cd /var/log/ && touch lighttpd.access.log lighttpd.error.log && chown www:www lighttpd.*.log
Now start up lighttpd, and navigate to your server’s IP in your web browser. The default document root is /usr/local/www/data, but since there’s nothing in there, you’ll get a 404. It’s nothing pretty, but we know that lighttpd is working.
Set up directory structure
I like to set up my sites so that I know exactly what sites belong to which client. I keep their site data and log files in their home directory. For the fastcgi processes, I like them to all be grouped together so I don’t have to go hunting for them. You’ll see how to set this up in the section on configuring lighttpd.
The first thing to do is create the www and logs files in your user’s home directory. Set these up as root so you can easily change permissions.
# cd /home/username && mkdir logs www
Next we create a site directory in the user’s www dir. I like to keep all the sites grouped in that directory, but they should all be in their own dirs to make things easy. What you call the dir doesn’t matter (‘site’ in the example- definitely change that!). I name them after the site that will be running the app. Do the same for the logs directory, to keep all the log files separate.
# mkdir www/site && mkdir logs/site
Because I have a number of clients on my server, I need a way to separate them all from each other, but still allow lighttpd to serve their files. The first step in setting this up is by creating different user accounts on the server for each client, and then creating the www and logs directories for each one, as we saw above. But in order to allow lighttpd to view the necessary files, we can take advantage of FreeBSD’s permission system. I add all my client accounts, as well as the www user, to a group named clients. So first we’ll create the clients group, then add the necessary users to it.
# pw groupadd clients
# pw groupmod clients -m www,username
Now that those are added, we’ll set the proper permissions so that lighttpd can read and write to the www and logs directories.
# chown -R username:clients logs www
# chmod -R 775 logs www
This configuration allows lighttpd to write to the logs and www directories, but it also allows
ANY user in the clients group to write to those. The clients that I host don’t have
SSH access to the machine, so it’s not really that big of a deal. If you need to set things up a bit differently, by all means go ahead.
The last part of setting this up is creating a place for all the fastcgi processes to live. I put these in /var/lighttpd/, but you can put them wherever you want.
# cd /var && mkdir lighttpd
# chown www:www lighttpd && chmod 755 lighttpd
h3. Setting up Typo
Typo is very nice blogging software, written by Tobias Luetke. We’re setting this up now because it’s a pretty easy app to set up, and a lot of people like blogs.
Download typo and extract it to the site directory. Since this is the user’s app, su back to the user and the privileges will come out fine. To get the latest stable release, go to
Typo Stable Downloads. At the time of this writing, the latest release was 2.5.5, but you should check for the latest one and use that in the following commands.
% cd www/site
% fetch http://rubyforge.org/frs/download.php/5602/typo-2.5.5.tgz && tar zxf typo-2.5.5.tgz
Check out the
README file for instructions on how to set it up…or follow these instructions. First we’ll set up the database tables.
% cd typo-2.5.5 && psql typo typo < db/schema.psql.sql
Now edit the config/database.yml file so that Rails can connect to our typo db. The only important one at this point is the production settings, so let’s edit that. It should look like the following block (of course your database/username/password may be different if you chose anything different earlier):
production:
adapter: postgresql
database: typo
host: localhost
username: typo
password: typ0
The last bit of command-line setup work for typo is to give write access to lighttpd on two directories – log and public.
% chmod -R 775 log/ public/
We also have to create the production log file. You’ll understand more about what this is later. For now, just know that we need to create this for Typo to be happy.
% touch log/production.log && chmod 666 log/production.log
To see that typo is working (and to set up basic admin stuff), start up the rails server, and then visit the index page in your browser. We specify that Webrick should run in the production environment, so Rails knows to use the database settings we set earlier..
%./script/server -e production
Now visit the index page in your browser. It will let you register an account, and then you can set up your blog. Play around for a while…change the title, make a few posts, whatever you want.
Making Typo run on lighttpd
Now for the meat of it, the final step in setting up
FLPR. Here we’ll edit the lighttpd config file so that it knows to run our Rails app using fastcgi. You can either edit /usr/local/etc/lighttpd.config, or you may decide to wipe it out and just paste this one in (changing a couple names for the user and site). You need to make sure you enable (by uncommenting) mod_rewrite, mod_alias, mod_fastcgi, and mod_accesslog. You can comment all the other server modules if you want. Below is the meat of the config – it’s the virtual host config for our Typo app.
$HTTP["host"] =~ "(www\.)?mysite.com" {
server.document-root = "/home/username/www/site/typo-2.5.5/public/"
server.errorlog = "/home/username/logs/site/lighttpd-error.log"
accesslog.filename = "/home/username/logs/site/lighttpd-access.log"
url.rewrite = ( "^/$" => "index.html", "^([^.]+)$" => "$1.html" )
server.error-handler-404 = "/dispatch.fcgi"
fastcgi.server = ( ".fcgi" =>
( "localhost" =>
(
"socket" => "/var/lighttpd/site.socket",
"bin-path" => "/home/username/www/site/typo-2.5.5/public/dispatch.fcgi",
"bin-environment" => ( "RAILS_ENV" => "production" ),
"min-procs" => 5,
"max-procs" => 5,
"idle-timeout" => 60
)
)
)
}
Not sure if that looks strange to most of you, or if it looks normal. I’ll try to break it down.
- $HTTP[“host”] – That sets a virtual host. It can be an IP address, a domain name, or a regular expression (like above). If you just want to set it to a single address, use == instead of =~, and obviously use your address as the value.
- server.document-root, server.errorlog, accesslog.filename – All self-explanatory
- url.rewrite – This is a rewrite rule that basically just makes Rails work. I can’t explain it, because I didn’t write it.
- server.error-handler-404 – /dispatch.fcgi is the script that converts web requests into Rails action requests. This setting just says to use it for any 404 errors.
- fastcgi.server – This code block signifies the use of fastcgi, saying it should act on files ending in .fcgi on the server localhost.
- socket – The name of the fastcgi socket that gets created
- bin-path – The script to use to create the fastcgi socket
- bin-environment – This is where you can set environment variables for the fastcgi processes. Just like when we used the -e flag in Webrick earlier, we set RAILS_ENV to production so it uses our DB, along with just making general production optimizations such as caching and less logging.
- min-procs – This is the minimum number of fastcgi processes to run
- max-procs – The max number of fastcgi processes to run
You run multiple fastcgi processes to improve the performance of your application. If there’s only one process running, it can only handle one request at a time. Create 5 processes, and now there are five little fastcgis waiting to handle a request. Some people have reported zombie processes if the min and max aren’t the same, so that’s why we made them the same. Plus your app will run faster because as soon as one process gets killed, another one starts up immediately, instead of waiting for a request.
full lighttpd.conf
Now (re)start lighttpd and you’ve got Typo running on lighttpd!
# /usr/local/etc/rc.d/lighttpd start
h3. All done (for now)
Well, that’s the end of this “tutorial” on setting up FLPR. I’ll keep posting tips and tricks on setting up your machine to host all your Rails projects. I hope you enjoyed reading this, you learned a lot, and most of all now have a nice production server for your Rails applications.
Posted in lighttpd, Rails | Tags lighttpd, rails | 4 comments
