Posted by Pat
Tue, 06 Dec 2005 23:16:00 GMT
A while ago we used portsnap to upgrade the ports tree when first installing FreeBSD. If you’ve made the upgrade to 6.0, portsnap is a part of the base system, so you should remove the package and any configuration.
It’s pretty easy. Just delete the package get rid of the existing portsnap database and regenerate it.
# cd /usr/ports/sysutils/portsnap && make deinstall
# rm -rf /var/db/portsnap/* && rm -rf /usr/local/portsnap
# rm /usr/local/etc/portsnap.conf
# portsnap fetch && portsnap extract
portsnap works because it uses the config at /etc/portsnap.conf now. The new portsnap binary is located in /usr/sbin, so you’ll need to update your crontab entries to reflect that.
Posted in FreeBSD | Tags freebsd, portsnap | no comments
Posted by Pat
Mon, 05 Dec 2005 08:58:00 GMT
In a previous article, we installed the ruby-postgres adapter using the ports system. I’ve spoken with a few people, and they’ve suggested using the postgres gem instead.
Unfortunately you can’t just do a “gem install postgres” to install it, you have to go through a few extra steps in order to get it to build cleanly on FreeBSD. Fortunately, I’ve done it and have all the steps here :)
You’ll get a bunch of errors and it’ll say it can’t create the Makefile. Don’t worry about that. We have to manually configure and install the gem.
For whatever reason, the Postgres installation doesn’t put the libpq-fe.h file in its include dir, so we need to symlink it. Then we’ll configure and install the gem.
# ln -s /usr/local/include/libpq-fe.h /usr/local/include/postgresql/server/
# cd /usr/local/lib/ruby/gems/1.8/gems/postgres-0.7.1/
# ruby extconf.rb --with-pgsql-include-dir=/usr/local/include/postgresql/server --with-pgsql-lib-dir=/usr/local/lib/postgresql
# make install
Should be all good to go. You’ll want to remove the ruby18-postgres package if you have it installed.
Posted in FreeBSD, PostgreSQL | Tags freebsd, postgresql, ruby | no comments
Posted by Pat
Wed, 16 Nov 2005 11:10:00 GMT
I finally got around to upgrading the server to FreeBSD 6.0 tonight. Sweet. I forgot to write down all the steps I took and turn it into a guide, but there’s really nothing to do. Just change your supfile to use RELENG_6_0, follow the basic upgrade procedures and you’re good to go. mergemaster is a pain…lots of stuff to do. Be sure to merge the group and master.passwd files, otherwise you’re in for a world of hurt.
Remember after you’ve upgraded to run ‘portupgrade -af’ to rebuild all your ports. You need to do this because the new libraries and interfaces in 6.0 can break your ports compiled against 5.x.
Posted in General, FreeBSD | Tags freebsd | no comments
Posted by Pat
Tue, 30 Aug 2005 03:23:00 GMT
Why the need for version control?
Because I screw up all the time. Seriously. I break my code so much, thrash up my system all the time…I need to be able to go back to a time when things worked. So I use version control.
There are also some pretty nifty things you can do with it to help deploy your apps. I’ll cover some of those in a future article.
There are a couple different pieces of software for version control. CVS, RCS (which I had to use when I was doing Software Engineering at RIT – bleh), and Subversion. Subversion seems to be the tool of choice for Rails developers, so that’s why I started using it. Again, not really based on good technical reasons, but it works really well for me. I’m not sure many people would notice a lot of difference in version control systems because most of us have simple needs, so it’s not that big of a deal.
Getting it set up.
I almost feel bad making a post, because subversion is so easy to set up on FreeBSD.
# cd /usr/ports/devel/subversion && make install clean
And that’s it. I’ll admit this is the first article I’ve written where I’m not typing in the steps as I do them, but I’m pretty sure that’s right.
Next I like to create a subversion user, and store all my repositories under that user’s home dir. It’s pretty simple, just use FreeBSD’s adduser command to create the user. I always set it up as username ‘svn’, random password, rest are defaults. Only time I ever become svn is when I su from root. Alter the setup to match your preferences.
I had initially started instructions on how to create a repository, import a project, etc but that’s all covered very well in the SVN Quickstart Guide. Just so you guys know, I like to store all my repositories in /home/svn/repositories, and I put a bunch of scripts in /home/svn.
Running svnserve to serve up your repository
For people to be able to access your repositories, you have to actually serve it somehow. I do it with svnserve, but you can also use apache+mod_dav_svn. That’s all covered in the excellent SVN Book.
I put the following command in a shell script that I execute as the svn user:
#!/bin/sh
svnserve -d -r /home/svn/repositories --listen-host machine.hostname
Just chmod+x it and run it whenever you want to start up your
SVN server. The command means svnserve will run in daemon mode (basically transparent, runs as a background process), and the root is at /home/svn/repositories, so if someone accesses svn://yourserver/projectname it serves up the repository named projectname under /home/svn/repositories – good for security so people can’t just access any file on your system. The last thing to mention is the—listen-host directive. I have to put this in because by default, svnserve runs with IPv6 enabled, so I’m unable to actually make a connection to my server. You may or may not need it – I’d just leave it in.
Last thing to do is connect to your svn server. This is pretty simple. From a remote machine (whatever you develop on, usually), type:
%svn checkout svn://hostname/projectname
And you’ve got an up-to-date copy of your project. Check out the quickstart and boook for more info.
SVN runs on port 3690 by default, so be sure to open that in your firewall, or specify a different port using the—listen-port directive.
Setting up authentication for users
If you want to make sure that only authorized users ever take a look at or modify your code, you’ll need to set up basic authentication. After you’ve created a repository, you should have a svnserve.conf file in the conf directory. Edit the contents to contain:
[general]
password-db = passwd
anon-access = none
realm = My Projects Repository
This will prevent anyone from checking out or making modifications to your code without authenticating. If you want people to check it out, set anon-access to read.
The password-db command means that the password database will be stored in a file named passwd. So create a passwd file in the conf directory that looks like
[users]
pergesu=ilovefreebsd
That means I can authenticate with username pergesu and password ‘ilovefreebsd’. That’s not my actual password, by the way :)
Now that you’ve set up authentication, you’ll need to be sure to use it when checking out a project:
% svn checkout --username pergesu svn://hostname/myproject
Enter your password at the prompt, good to go. Once you’ve authenticated once, you never need to use—username in there again. Not sure how – must be magic.
Wrapping up
So you should have a working SVN repository going, maybe even with authentication. Check out the SVN Book to learn how to do practically everything with SVN. It’s pretty cool. I’ll show you my neat little deployment set up in a couple days. Have fun for now
Posted in FreeBSD | Tags freebsd, subversion | no comments
Posted by Pat
Thu, 25 Aug 2005 00:21:00 GMT
This is the nitty-gritty
Now we’re going to upgrade the base system. FreeBSD is different from linux in that “FreeBSD” isn’t simply a kernel like linux is – it’s a combination of the kernel and all the basic system utilities you’re used to. Those are called the “userland apps” in FreeBSD-speak.
Some of you may be wondering when we’re getting to the Rails stuff…that’s a bit later. As I said in the first post, this series of guides is to help you set up a deployment platform. A key component of that is making sure that your system is up-to-date, so you don’t have to worry about any security issues.
Upgrading the kernel isn’t all that hard…though it can be kind of scary at first. I’ll be honest, the first few times I upgraded my kernel I was scared shitless, hoping my machine would boot up. But don’t worry, it’s pretty easy stuff.
Most importantly, be sure to read the FreeBSD Handbook section on Configuring the FreeBSD Kernel. Failure do so will lead to you being lost, and may even screw up your machine. I’ll take you through the steps necessary, but you should still read up on it. Don’t say I didn’t warn you.
Install cvsup and update your sources
cvsup is a nifty little utility that updates your system sources, so you can upgrade your base system whenever you need. It can actually be used for updating anything basically, including the ports tree, but I just use it for the base. portsnap is excellent for managing the ports tree.
# cd /usr/ports/net/cvsup-without-gui/ && make install clean
Once you’ve got it installed, you need to tell cvsup what sources to update, where to get them from, and what versions. These are all read in by default from a file of your choosing, sometimes called a supfile. The following is my supfile, which updates the base system for FreeBSD 5.4, and only does security updates.
# vi /usr/local/etc/security-supfile
*default host=cvsup7.freebsd.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_5_4
*default delete use-rel-suffix
src-all
Now update the base system sources using cvsup. It’ll connect to the cvs servers and download all the latest code:
# cvsup -L 2 /usr/local/etc/security-supfile
h3. Create a kernel config file
The first thing I do now is create a custom kernel config file. I’ll show you where to go, but I won’t give my example config file because you need to enable different settings based on your machine. Take a look at
The Configuration File to find out what all the options are.
# cd /usr/src/sys/i386/conf/
# cp GENERIC HOSTNAME
# vi HOSTNAME
What I will recommend you put in the kernel config is PF support. PF is a firewall, though you can use a couple others if you don’t want it. For more info, check out the info on
The OpenBSD Packet Filter.
# pf support
device pf
device pflog
device pfsync
# ALTQ support
options ALTQ
options ALTQ_CBQ # Class Bases Queuing (CBQ)
options ALTQ_RED # Random Early Detection (RED)
options ALTQ_RIO # RED In/Out
options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC)
options ALTQ_PRIQ # Priority Queuing (PRIQ)
I like to copy my config file to /root as well, just because when I do backups, I don’t backup the /usr/src directory and its subdirectories.
Rebuild the kernel and system binaries
Very first thing to do is check to see if you need to do anything special when upgrading…to do so, read the /usr/src/UPDATING file
Note: If you’ve got /tmp set to noexec, you’ll run into problems here. The system updating process requires that /tmp be executable, so just temporarily enable it.
Now go to the sources directory and start the build. The -j4 flag just makes it run faster. This will take a while, depending on the speed of your machine.
# cd /usr/src
# make -j4 buildworld
Now build the kernel. This will only take a few minutes. Substitute
HOSTNAME with whatever you named your kernel config file earlier.
# make buildkernel KERNCONF=HOSTNAME
Once this is done, install the kernel. This should be pretty quick.
# make installkernel KERNCONF=HOSTNAME
Then install the world (userland apps).
The last step is to run mergemaster. This takes all your existing configuration files and merges necessary changes into them. You’ll want to back up your existing config files, in case something goes wrong.
# cp -Rp /etc /home/backupetc
Now run mergemaster
This will prompt you to make changes to your files. For the most part, you can just install the changes. However,
DO NOT INSTALL A NEW master.passwd, passwd, or group files. If you do, you’ll have to recover them from the backup you just made. Also, don’t overwrite any custom files you may have like firewall config files.
If you’re prompted to make a change, enter ‘i’ to install the change, and ‘d’ to discard it. Sometimes the file may be longer than the screen, in which case you can scroll down to see it in its entirety, or just hit ‘q’.
When the last file is done, you’ll be asked to delete the temp root directory. Choose ‘yes’.
Now reboot your machine and pray (just kidding! sorta…)
Rejoice or recover
In all likelihood your machine booted just fine. If not, you can recover it by loading the old kernel. Do this by doing a soft reboot (ctrl+alt+delete). When the machine is booting up, it will ask if you want to boot a different kernel by pressing any key other than ‘Enter’. So press something other than ‘Enter’ and type
# unload
# boot kernel.GENERIC
If your server is hosted at a datacenter, and you don’t have physical access to it, submit a support ticket and have one of their techs boot to the old kernel.
Posted in FreeBSD | Tags cvsup, freebsd, kernel | 2 comments
Posted by Pat
Wed, 24 Aug 2005 17:03:00 GMT
Assumptions
I assume that you already have FreeBSD installed…a pretty big assumption, I realize. However, I just got a new server, and I have to set it up anyway, so it’s a good opportunity for me to take you through the steps I take when configuring a server for Rails hosting. I’ll make another article at a later date going over FreeBSD installation…but for the mean time, read the Installing FreeBSD section of the FreeBSD Handbook
Also, I assume that you did the Developer install, which includes the base system sources. You should also install the ports tree, which the handbook covers.
Setting up the ports utilities
The first thing I ever do is upgrade the ports system, so that any software I install is at the latest version. We’ll also set up cron jobs to check all your software for security flaws (these are checked against a database created by the FreeBSD Security Team).
We’ll be installing three ports.
portaudit – Checks your installed ports against a database for any known security flaws
portsnap – Updates the ports tree to the latest versions
portupgrade – Amazingly, upgrades your installed ports
su to root and execute the following commands
# cd /usr/ports/security/portaudit && make install clean
# cd /usr/ports/sysutils/portsnap && make install clean
# cd /usr/ports/sysutils/portupgrade && make install clean
Note: Depending on your ports tree version, the installation of portupgrade may fail. That’s because portaudit notices a vulnerability in a dependency and doesn’t let you install it. If it fails, skip to the “Upgrade ports tree” and then install portupgrade.
After you install the ports utilities type “rehash” at the command prompt so that you can run the newly installed programs.
Update the ports tree
We want to install the latest version of any software we install, so you’ll need to update the ports tree. First thing to do is copy your portsnap.conf file to its proper location:
# cd /usr/local/etc/ && cp portsnap.conf.sample portsnap.conf
Next thing to do is fetch and extract the updated ports tree.
# portsnap fetch
# portsnap extract
This is optional, but at this point I set up portsnap to fetch the latest ports tree in a cron job, so I don’t manually have to, or at least it will be mostly updated when I do run fetch/extract, thus take less time. I have this entry in my /etc/crontab file:
0 2 * * * root /usr/local/sbin/portsnap cron
That runs portsnap at 2 am every night.
Note: If you haven’t installed portupgrade because it failed the first time around, do so now
Upgrade your installed ports
First get the absolute latest snapshot of the ports three. You’ll have this since we just installed it, so this is mostly just a reference for the future. Keep in mind you should run it even if you have a cron job set up, so that you get any changes made between the time the cron job ran and the time you’re updating your ports.
# portsnap fetch && portsnap update
There are a number of ways to check out what ports are up-to-date and which ones need updating. Personally, I use pkg_version, which will list all the packages you have installed, along with whether they’re up-to-date with, ahead or behind of the ports tree. To just see which ones need updating, do
You’ll want to read the upgrade notes before upgrading. The vast majority of the time you can upgrade your ports without worrying about anything, but occasionally one will need some steps taken before you can upgrade.
Upgrade a single port using portupgrade:
Or to upgrade all the ports on your system, use the -a flag:
h3. Congratulations (and a sweet little treat!)
You’re all done getting the ports tree updated, installed a few nice utilities to help check the security of your ports, as well as update them.
I’ve got a nice little surprise for you at this point…when you installed portupgrade, FreeBSD installed ruby along with it because it’s listed as a dependency. Think I’m kidding?
# ruby --version
ruby 1.8.2 (2004-12-25) [i386-freebsd5]
You’ve got the latest version of Ruby and didn’t even have to do anything – sweet! Go ahead, play around a bit.
Next we’ll learn how to bring the base system up to date.
Posted in FreeBSD | Tags freebsd, ports, portsnap, portupgrade | 2 comments
Posted by Pat
Sat, 20 Aug 2005 07:57:00 GMT
What is FLPR?
If LAMP is the Open Source Web Platform, then FLPR is the Most Excellent Open Source Web Platform. Party on dudes.
FLPR stands for FreeBSD Lighttpd PostgreSQL Rails
Why should I use it?
This is just the opinion of one tiny web developer (but don’t worry, with FLPR, I’m going to take over the world!). There’s tons of debate all over the net on MySQL vs Postgres, FreeBSD vs Linux, Rails vs PHP/ASP/Java/FlavorOfTheWeek.
Here are my thoughts on it. I’m actually going to explain it all in reverse order. As I mentioned, there’s already a ton of exiting content debating the merits of all the various technologies. I’m just going to discuss why I use this particular setup (besides the obvious fact that it makes a cool acronym).
- Rails – This is just a sweet, sweet web framework. That’s basically my reasoning for using it. Development is easy and just makes sense. I can code a lot faster in it than Java (my previous lang of choice), and it’s (gasp!) fun.
- PostgreSQL – This is about as enterprise a database as you can get and still be free. Free as in beer, free as in speech. Can’t beat that. Views, stored procedures, and it’s been totally solid and lightning quick for me. I feel in general it’s superior to MySQL, and Rails has awesome support for it, so it just makes sense. Plus it’s true open source, vs MySQL’s pseudo-open source ;)
- lighttpd – Apache is the de facto for web hosting…except in Rails apps. I’m not even sure why, really. Basically it’s taht Rails has to run as a CGI app, Rails in CGI is slooooow so you have to use FastCGI, and lighttpd + FastCGI is super quick. I’ve just played around with it a bit and it seems pretty nice so far. It’s been very stable (no crashes yet), very fast, and uses less resources than Apache. Most excellent.
- FreeBSD – This, as they say on MTV’s Cribs, is where the magic happens. I think this is the best server OS around right now. Solid, fast, secure…and maintaining it is super easy. Best of all, I think Rails was written to run on it, because of how easy it is. Have problems installing Ruby and Rails on another OS? Not on FreeBSD! Installing the pure Postgres adapter is a cakewalk when you install from ports, compared to being a pain in every other OS I’ve tried.
Okay so as I look at that list, there isn’t really a compelling reason to use FLPR over LAMP, or any combination of OS, httpd, database, and language. I’ve used a lot of web languages and a lot of OSes, and it really comes down to feel for me. The combination I discuss here just feels right when developing, and so far it’s been a winner in production.
I think the FLPR combo is absolutely killer for developing and deploying web apps. If you like it, awesome, if not, that’s cool too. Over the next week, I’ll be posting instructions on how to build a FLPR machine from scratch. The point of this will be to build a machine that can host your web applications online, and eventually I hope to incorporate all aspects of a standard internet server (web, ftp, etc).
Why can’t I use Linux?
Cause then you’re a LLPR, and that means your apps fall apart. (I’ll be here all week, don’t forget to tip your waitress)
Posted in General | Tags flpr, freebsd, lighttpd, postgresql, rails | 6 comments
