A Django site.
April 25, 2008
» This Site Will Be Upgrading To Ubuntu 8.04 Server Today

This is the last of my servers / desktops / laptops that is not yet running Ubuntu 8.04 “Hardy”.  In my testing on non-production machines and semi-production machines the upgrades have worked absolutely perfectly.  I wanted to post an announcement / warning that I would be upgrading this server to Ubuntu 8.04 at some point today.  I’ll post on the progress.  Heads up however.  If the blog manages to disappear altogether you’ll know what happened ;)

Related

March 17, 2008

Jeremy Robb
scothoser
Scothoser's Corner
» Kerberos Issues with Open Directory 10.5? Here is a Sure-Fire Fix

I thought I would post this, as we had a similar situation within our class with this issue. At times, when you try to start Kerberos in Mac OS X 10.5 Server, the domain gives you trouble. The first thing you should do is check the host name with changeip, and determine the issue with your DNS. Then, you can fix your Kerberos issues with the following steps as found here on Apple’s documents page:

1. Fix Your DNS: This is necessary, otherwise steps below will not work.

2. Fix your /etc/hosts file: Best done in Terminal. Run sudo bash and authenticate to get to root, and then run vi /etc/hosts. Once in there, add your server’s IP Address and fully qualified domain name, like this: 10.1.0.1 mainserver.pretendco.com

3. Set your Host Name: This can be done as root with the following command: scutil –set HostName mainserver.pretendco.com. Replace the Mainserver entry with your own domain name in this step, and all subsequent steps you see.

4. Initialize Kerberos: This requires three steps (and being logged in as root):
slapconfig -kerberize diradmin MAINSERVER.PRETENDCO.COM (diradmin would be the directory admin login name)
sso_util configure -r MAINSERVER.PRETENDCO.COM -f /LDAPv3/127.0.0.1 -a diradmin -p diradmin_password -v 1 all (replace diradmin and diradmin_password with your directory admin and password)
sso_util configure -r MAINSERVER.PRETENDCO.COM -f /LDAPv3/127.0.0.1 -a diradmin -p diradmin_password -v 1 ldap

Once you finish these steps, reboot the machine, and check your Server Admin utility. You should see that you have all your services running on your Open Directory Master.

Even with this trouble, Kerberos seems really simple to set up with a Mac server. I’ve never tried it on a Linux server, but from the expressions on some friend’s faces when I suggest it, it doesn’t seem to be very simple. I’m not sure how it’s implemented in Active Directory either, though I do know it’s just as frustrating when it doesn’t work.

April 3, 2008
» Dapper To Hardy Direct Server Upgrade Works!

The other day I thought I’d give the Ubuntu 6.06 LTS to 8.04 LTS direct upgrade path a try on my Ubuntu 6.06 server.  It ran smoothly (over ssh no less), until I ran into one bug at the end.  I reported it, with a reply back the next day.  Two days later it has been fixed and I tried an upgrade again.  I’m happy to say that the direct upgrade path worked perfectly on a fresh install of Ubuntu 6.06 Server.  Here is how I did it:

Ubuntu 6.06 to Ubuntu 8.04 Upgrade (Server)

I verified that my current install was completely up to date:

sudo aptitude update
sudo aptitude upgrade
sudo aptitude dist-upgrade

Also, to be thorough, this is what my sources.list looked like (each ‘deb’ entry should be one single line):

deb http://archive.ubuntu.com/ubuntu dapper main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu dapper-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu dapper-security main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu dapper-proposed main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu dapper-backports main restricted universe multiverse

Once I had applied all updates (if you’re already up to date, you don’t need a reboot) I then installed the server-based update utility:

sudo aptitude install update-manager-core

Once this is installed you’re ready to begin the upgrade process.  You can start the upgrade using:

sudo do-release-upgrade -d

note: once Ubuntu 8.04 final is released the -d option will no longer be needed.

At this point it’ll do some checking, verify and update the newer repository and ask you a few questions along the lines of “There is no going back from here, are you sure you want to upgrade?”  After that its smooth sailing.

If you do run into any issues during the upgrade please report them against the update-manager-core package in Launchpad.

March 17, 2008

Jeremy Robb
scothoser
Scothoser's Corner
» Kerberos Issues with Open Directory 10.5? Here is a Sure-Fire Fix

I thought I would post this, as we had a similar situation within our class with this issue. At times, when you try to start Kerberos in Mac OS X 10.5 Server, the domain gives you trouble. The first thing you should do is check the host name with changeip, and determine the issue with your DNS. Then, you can fix your Kerberos issues with the following steps as found here on Apple's documents page:

1. Fix Your DNS: This is necessary, otherwise steps below will not work.

2. Fix your /etc/hosts file: Best done in Terminal. Run sudo bash and authenticate to get to root, and then run vi /etc/hosts. Once in there, add your server's IP Address and fully qualified domain name, like this: 10.1.0.1 mainserver.pretendco.com

3. Set your Host Name: This can be done as root with the following command: scutil --set HostName mainserver.pretendco.com. Replace the Mainserver entry with your own domain name in this step, and all subsequent steps you see.

4. Initialize Kerberos: This requires three steps (and being logged in as root):
slapconfig -kerberize diradmin MAINSERVER.PRETENDCO.COM (diradmin would be the directory admin login name)
sso_util configure -r MAINSERVER.PRETENDCO.COM -f /LDAPv3/127.0.0.1 -a diradmin -p diradmin_password -v 1 all (replace diradmin and diradmin_password with your directory admin and password)
sso_util configure -r MAINSERVER.PRETENDCO.COM -f /LDAPv3/127.0.0.1 -a diradmin -p diradmin_password -v 1 ldap

Once you finish these steps, reboot the machine, and check your Server Admin utility. You should see that you have all your services running on your Open Directory Master.

Even with this trouble, Kerberos seems really simple to set up with a Mac server. I've never tried it on a Linux server, but from the expressions on some friend's faces when I suggest it, it doesn't seem to be very simple. I'm not sure how it's implemented in Active Directory either, though I do know it's just as frustrating when it doesn't work.

January 28, 2006

Lonnie Olson
fungus
LonnieOlson
» Jabber

Google now has open-federation with all other jabber servers. This could finally be the thing to push jabber into mainstream usage.

Now I gotta install a Jabber server on MyFungus. Very simple install of net-im/jabberd. Almost all defaults worked well. I was hoping to get it to use PAM as my userbase for authentication. Unfortunately the instructions say you have to run jabber as root. That scares the hell out of me. Oh well, I’ll just leave it open for anyone to be able to sign up.

January 5, 2006

Lonnie Olson
fungus
LonnieOlson
» SSL certificates

  1. I need a few SSL certs for security
  2. I don’t have a lot of money
  3. I hate self-signed certs

I guess I have to maintain my own CA. FreeBSDDiary has a great article about using SSL certs. Part of it delves into creating your own CA. It was actually a lot easier than I had thought.

So now I created SSL certs for almost every hostname I needed, including one for my personal www.kittypee.com site. I feel much safer.

Unfortunately, the error that pops up everywhere really sucks. But this is another reason having your own CA rocks. I just had to install/trust my CA cert in the browsers I use, and poof no more warnings.

January 3, 2006

Lonnie Olson
fungus
LonnieOlson
» Virtualmin

I installed Virtualmin from ports. It had installed version 2.50 because 3 wasn’t released yet. I checked their site and noticed that they now offer a Professional paid version. My use of it will not be this paid version as I am using it for more simple things, and I am not making any money anyway.

Virtualmin requires a bit of configuration before using, but work quite well after. I was quite impressed with the idea on how it handles virtual users. Virtual users are giving a real UNIX user account and UID like any other account, but is assigned to the group of the parent account. This method makes it very easy to integrate with many applications like Mail, Web, FTP, etc. Quotas are still manageable via groups. It works well with Postfix, my current MTA of choice.

Perhaps now that version 3 is available I may upgrade, but not very soon.

February 2, 2008
» How to Configure Listadmin : Command Line Mailman Moderation

First of all I need to thank Daniel for turning me onto this tool. I’m administrator on more lists than I’d prefer and this has been a godsend!

If you happen to be one that missed his post recently on the planet, or if you’re just finding this via Google, Listadmin is a tool to help you bulk moderate mailman lists. If you are the admin or moderator on more than one mailman list do yourself a favor and keep reading. If you have no idea what I’m talking about, well, thanks for the visit anyway.

Installation

Installing Listadmin is just as simple as installing anything else really. Use the following command (or click the link using apturl):

sudo aptitude install listadmin

Configuration

Before we can begin moderating our lists we’ll need to tell Listadmin which lists to moderate. This is done by creating a file in your home directory ~/.listadmin.ini

With your favorite editor create the file and follow the below example, replacing with your own information:

default skip

# this example uses the same password
# for the users, process and admin lists
adminurl http://{domain}/mailman/admindb/{list}
password mypassword
users@lists.example.org
process@lists.example.org
admin@lists.example.org

# this example uses different passwords
# for the supporters and staff lists
adminurl https://{domain}/mailman/admindb/{list}

password "myotherpassword"
supporters@lists.example.com

password "mythirdpassword"
staff@lists.example.com

As you can see the configuration is pretty simple. The address to the list, the password needed and the lists you want to moderate.

If the lists use the same password you can list them under a single password block.

If the lists use different passwords you can list the by individual password and address.

Once you’ve replaced the details with your own information there is one more step before we run the utility. Considering this file holds sensitive passwords you’ll want to limit access to the file.

chmod g-r,o-r .listadmin.ini

Go ahead now and launch the tool and moderate your lists:

listadmin

I’ve been using this now for only two days or so but I’m so thankful I found it. Instead of manually moderating a large number of lists I simply run this tool once a day, clean out the garbage and get back to real work.

January 16, 2008
» Configuring AWStats on Ubuntu Server

Last nite I sat down and configured AWStats on my Ubuntu 7.10 server. I had previously been using statcounter, a free stat service, but I had noticed that it was one of the causes of slowdown on my page loads. Having to access an external site and javascript wasn’t helping. I also run the server so I have full access to the server logs, why not just use those directly.

So far I am really happy with AWStats. It appears to be running properly and pulling in a lot more data than statcounter ever did. It actually is showing me that I had much more traffic than I thought. I had mentioned 5,000 the other day, which I have long since surpassed based on AWStats output.

I’d like to share the steps I took for installing and configuring AWStats on my Ubuntu Server.

Installation

Ubuntu has the AWStats package available in the repositories, which we can install with:

sudo aptitude install awstats

This will install the basic files, but there is still a bit of configuring to do, so we’ll dive into that next.

Auto Configuration

From the tutorials that I found elsewhere in my searching there is a awstats_configure.pl file that will try to configure it for you. I did not use this personally, but if you’d like to try it you can run:

sudo perl /usr/share/doc/awstats/examples/awstats_configure.pl

The rest of this tutorial will discuss manual configuration, but if anyone can offer feedback concerning the configure script I’m sure many would be interested.

Manual Configuration

I configured my system manually, which I will outline below. The only requirements here are that you have access to the apache2 logs, or that you have custom log locations for each of your virtual domains (if used). For more information on custom log locations for virtual domains see my previous post, Configuring Virtual Hosting on Ubuntu with Apache2.

The first step is creating an awstats.conf file for your domain. This can be done by moving or copying the /etc/awstats.conf, and giving it a more unique name:

sudo cp /etc/awstats/awstats.conf /etc/awstats/awstats.domain.tld.conf

I created a unique file, using the syntax awstats + domain.tld + conf for each of the domains hosted on my server. Each of these also has their own unique log file as well.

We’ll then edit our new /etc/awstats with custom values for that domain. The main points you’ll want to look for within this file:

  • LogFile=”/path/to/your/domain/access.log”
  • LogFormat=1 (this will give you more detailed stats)
  • SiteDomain=”domain.tld”
  • HostAliases=”www.domain.tld localhost 127.0.0.1″

Once you’ve made these changes you’ll want to build your initial statistics, which will be generated from the current logs on your machine. We can do this using:

sudo /usr/lib/cgi-bin/awstats.pl -config=domain.tld -update

What this will do is scan the /etc/awstats folder for anything of the pattern awstats + domain.tld + conf, reading that config to generate its output. You should see some output here, and depending on the size of your logs it’ll take anywhere from a few seconds to a few minutes or hours. Each time it is run after that will be minimal, as it only updates the information, but the initial generation can take some time.

Configure Apache to Display AWStats

At this point our statistics should be generated (if not, go back and double check you haven’t missed anything!), but we need a way to see them. We’ll need to configure Apache2 to show us these stats. The way I did this was by using an Include in my apache2.conf, instead of cluttering up the default config file. This is generally my preferred method.

Apache2.conf already has a line near the botton Include /etc/apache2/conf.d/, which will read anything in there as additional data. What I did was create a new file in the /etc/apache2/conf.d/ directory called awstats, and filled it with the following content:

Alias /awstatsclasses "/usr/share/awstats/lib/"
Alias /awstats-icon/ "/usr/share/awstats/icon/"
Alias /awstatscss "/usr/share/doc/awstats/examples/css"
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
ScriptAlias /awstats/ /usr/lib/cgi-bin/
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch

This is basically creating some access aliases, and defining the cgi-bin paths, etc. Once this is saved you should be able to restart Apache2 and we’ll should be able to access our stats. Restart Apache2 using:

sudo /etc/init.d/apache2 restart

You should now be able to access your statistics using:

http://domain.tld/awstats/awstats.pl

Assuming you didn’t get any errors during your stats generation, and Apache2 didn’t complain when you restarted the service, you should see statistics at this point.

Continually Updating Your Stats

The last thing you’ll probably want to do is update your statistics via cron. This will allow you to have your site statistics updated on a regular basis, not requiring intervention on your part. What I have done is added a line to my /etc/crontab file telling AWStats to update every ten minutes. I have seen minimal system load even when updating a dozen sites on that interval. To update every ten minutes we’ll add the following line:

*/10 * * * * root /usr/lib/cgi-bin/awstats.pl -config=domain.tld -update >/dev/null

Repeat this line, updating the domain.tld value for any site you want continually updated.

Securing Statistics

If you’d like to make your statistics private you might be interested in one of my previous posts, Limiting Access To Websites & Directories with .htaccess.

November 8, 2007
» PLUG: DoS Attack

Plug.org experienced a brief DoS attack Wednesday night. The source of the attack originated from Korea. It was a simple application port exhaustion attack against port 80 (http/Apache). Due to some great efforts by local #plug'ites the attacker was slowed long enough to get a block in place. We will remain vigilant.

As a side note, this delayed getting meeting details out tonight. We are still on for next Wednesday at 7:30pm. Details to follow very soon. The meeting will be a little different this time, so don't expect to show up at the usual place.

July 9, 2007

Jeremy Robb
scothoser
Scothoser's Corner
» MacBook Pro with Mac OS X Server Installed: Why It's Not Supported

A while ago I had an authentication problem with Mac OS X Server 10.4.9. I set up my classroom server with a specific account (Sharon Accounte), and my students were supposed to authenticate to their server, which was connected to my server. Instead, they received an error denying access, and suggesting that the account was wrong. I checked the account on the server, authenticated locally without any trouble, so I knew it wasn't the account. I then checked the server logs, and found no errors within the Directory or Password Server logs.

I then checked with other Server Essentials instructors to see what the problem could be. Everyone suggested checking the directory entry using the command line tool dscl. This tool will let you navigate the directory entry as though it were a file system, and you can read the authentication information the server provides. While checking this, I noticed that everything was being provided, and stumped the other instructors as to what the cause could be.

Well, after running some tests after the class, I found out what the issue was. First, it's important to note that I had used a MacBook Pro as the server (our lab is mobile, and it was the most convenient way to get it done), so the problem is not typical as laptops are not a supported platform for Server. Next, I had upgraded to 10.4.9, which provided Airport support (and didn't crash the system as 10.4.8 did).

Before I had upgraded, the authentication worked just fine. After upgrading, it wouldn't authenticate, and there were no errors in the Password Server log. It seems that, at least for a laptop install, the server has trouble authenticating with later releases (I haven't tried 10.4.10 yet).

So, for anyone out there that is using a MacBook or MacBook Pro as their mobile lab server, this may be of some use. I'll test it with 10.4.10 next week during the Server class Challenge. For now, the base install of 10.4.7 on a MacBook Pro will work, sans the Airport. But, as the server should be connected through Ethernet anyway, it shouldn't be that much of a problem.

But the question still remains: What is significantly different from the Mac Pro to the MacBook Pro that would cause the server to fail in authenticating without providing error log entries? I'm not sure I will ever find out, but at least I now know that the classroom server will work just fine, and I don't have to lug around a Mac Pro just to teach a class.