How To Burn The Swedish Goat?

Derek writes me today to tell me about a 43ft straw goat sitting dead-center in the Swedish town of Gävle. Now a huge straw goat just sitting right out there in the open is obviously a target for sabotage, but the Swedes have won a special place in my heart by making a tradition out of burning these things to the ground. Apparently in the 40 years they’ve been putting them up, 66 goats have been built and 35 of them have been destroyed. Despite the government’s unending attempts to protect them by surrounding the straw target with a huge fence fewer than half of these festive goats have survived.

Derek Writes:

It has been destroyed almost every year by some creative individual. Many times it has been burned down. One time it was ripped apart. Another time I guy ran his car through the fence and into the goat, tipping it over. A few years ago an American got caught, put in jail, and fined a lot of money. Last year some other guy was a bit smarter, hitting it with a flaming arrow from a bow, and he wasn’t caught. It went up in flames!

There is even a webcam trained on the goat 24/7! The discussion boards have had some excitement as the occasional fire truck rolls by, but the goat still stands, defying us.

FestiveGoat.jpgI have to say that this is one Christmas tradition that I can really get behind! Aparently I’m not alone either, as some have gone so far as to setup discussion boards to try to figure out how to take this thing down.

It would seem that the government is not messing around this year though. There is the webcam of course, but they have also hired a British firm to drench the entire goat in Noflan Flammestopp which is a Complex of Alkyl-Phosphonates designed to keep just about anything from burning. The company has thrown down the gauntlet by guraenteeing that the “goat will not burn this year”.

That sounds like taunting to me.

Many ideas on how to destroy this goat have been tossed around, but it all comes down to a few possible end results.

  • Burn it
  • Blow it up
  • Decapitate it
  • Split it in half so it falls over
  • Cut off a leg to tip it over
  • Make it yummy so animals eat it
  • Make it disappear (I wonder if Roderick is up for this one?)
  • Transform it into something else

Some things to think about and important facts about the goats location:

  • Disguise would be needed because of the webcams.
  • The fire department is about 3 streets away and can respond quickly.

Some ideas that have been tossed around about how to destroy to goat are:

  • Could there be a chemical that you mix with the flame retardant, and the two react and the result is combustible or corrosive?
  • Blow something up nearby to cause a diversion.
  • Span a hot-wire (like the kind used to cut styrofoam) across its back under tension, and in several hours it would burn through the hay, chop it in half, and then you could pull it apart so both halves tip over).
  • Tie chains around the legs and tie them to cars – when the cars pull away they might rip apart the legs.
  • Put it on rollers and if it’s on a slant it could go rolling down the hill.
  • Put a mirror on the ground and a focusing frensel lens on a building… focus the sun onto the mirror, then the focused light hits the underbelly of the goat (where maybe people won’t notice it) and it can heat up and cut through the belly until it spontaneously ignites.
  • Put acid on the thing so that it dissolves.
  • Span ropes from building to building above it and work from above, but it would be easy to catch us. We would need a diversion.
  • Frame someone else.
  • Fake it at one moment or day, and then follow up hours or a day later when people are breathing a sigh of relief.
  • We could dress like city workers and act like we are picking up trash around the thing.
  • Turn it into something else, like a Christmas tree – somehow.
  • Make it grow fur or paint it or put clothes on it.

Since tradition would have us burn it down, it is my feeling that this is the best option. There has been some talk that enough water would wash away the Alkyl-Phosphonates enough for the goat to be set ablaze, but that leaves the problem of getting it dry in time. It seems that the most promising route would be to neutralize the flame retardant enough to get it to catch fire… Any chemistry heads out there? There is plenty of news coverage for the person who manages it.

UPDATE: The Gävle Goat has survived an attack from arsonists on the 15 December. Somebody tried to set one of the legs on fire, but the fire was immediately stopped by the flame retardant chemicals. Some straw was bruned, but they have replaced now, says Anna Ostman, spokeswoman of the Goat Committee.

UPDATE: The Natural Science Club goat has burned, but the larger Southern Merchants Association goat still stands in defiance.

Horde / IMP on RHEL 4 From RPM HOWTO

Whenever you go to install applications and services on registered RHEL servers, it’s always nice to use the RPMs because up2date will keep everything current for you. Managing upgrades gets a whole lot easier when you can bring your system up to current with one simple command. Because of this, I decided that I would try to use as many RPMs as I could when I set up our latest Horde / IMP installation.

Unfortunately, RedHat does not supply RPMs for the Horde applications, but luckily CentOS does. You should be able to download them from here. Get the latest version, which at the time of this writing was horde-3.1.3-1 and imp-h3-4.1.3-1.

Don’t install them yet though because Horde and IMP have always had a lot of dependancies which must be installed and enabled first. Installing the following RPMs should take care of them.

  • mysql-4.1.20-1.RHEL4.1.i386.rpm
  • mysqlclient10-3.23.58-4.RHEL4.1.i386.rpm
  • mysqlclient10-devel-3.23.58-4.RHEL4.1.i386.rpm
  • mysql-devel-4.1.20-1.RHEL4.1.i386.rpm
  • mysql-server-4.1.20-1.RHEL4.1.i386.rpm
  • perl-DBD-MySQL-2.9004-3.1.i386.rpm
  • php-4.3.9-3.15.i386.rpm
  • php-devel-4.3.9-3.15.i386.rpm
  • php-domxml-4.3.9-3.15.i386.rpm
  • php-imap-4.3.9-3.15.i386.rpm
  • php-ldap-4.3.9-3.15.i386.rpm
  • php-mysql-4.3.9-3.15.i386.rpm
  • php-pear-4.3.9-3.15.i386.rpm

Assuming you will want up2date to handle upgrades of these packages, it is very important that you either use “up2date” to install them, or download them from correct channel at the RedHat website. You could also simply get them from the CD distribution that you used to install the system itself.

Once PEAR is installed, you will have to upgrade it, and install the PEAR::Log module.

[root@server]# pear upgrade -a PEAR-1.3.6
[root@server]# pear upgrade PEAR

Ok, now let’s make sure the web server is configured to start when the system comes up:

[root@server /]# /sbin/chkconfig --list httpd

You should see this:

httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

But if you see 5:off, simply run:

[root@server /]# /sbin/chkconfig httpd on

Now we enable and start up our new MySQL database server:

[root@server /]# /sbin/chkconfig mysqld on
[root@server /]# /sbin/service mysqld start

And we’re ready to install Horde and IMP. Install the following RPM’s, which will put everything in /usr/share/horde and creates a file called horde.conf in /etc/httpd/conf.d/

  • horde-3.1.3-1.c4.noarch.rpm
  • imp-h3-4.1.3-1.c4.noarch.rpm

This will install the HORDE and IMP packages in /usr/share, and /usr/share/horde respectively.

Finally, we start or restart apache:

[root@server /]# /sbin/service httpd start

Grab a browser and go to the following URL to proceed with the Horde and IMP configuration.

Getting ntpd to work correctly on RHEL

When many new servers are delivered from the factory, the system clock is way off. Most UNIX systems run “ntpd” to keep the time in sync with internet time servers, which are, in turn synchronized against an atomic clock. This results in a system time that is very very close to the “actual” time of day. The downside, however, is that even a properly configured “ntpd” will not synchronize the system clock if it is too far out of sync with the time server. To remedy this, we first have to run “ntpdate” to get the system clock close to the correct time, and then enable “ntpd” to keep it there.

The first thing we have to do is “ntpd” to free up the port for “ntpdate”:

[root@server /]# /sbin/service ntpd stop
Shutting down ntpd:                                        [  OK  ]

This frees up the port for ntpdate. Next we run:

[root@server /]# /usr/sbin/ntpdate

Now the time should be set correctly. We then change the default time servers to something like the following in /etc/ntp.conf:


We can use any time server we want, but I like these and find them to be reliable.

Finally, start backup up your “ntpd” service, and your all set to go.

[root@server /]# /sbin/service ntpd start
Starting ntpd:                                        [  OK  ]

Remember to use “chkconfig” to make sure “ntpd” is enabled to come up when the system starts.

Installing OpenGroupWare 1.1.5 on RHEL 3

OpenGroupWare is an open source groupware package intended as an alternative to proprietary applications such as Exchange and PostPath. It is fairly robust in its feature set, and even integrates well with MS Outlook.

Its strongest points, in my opinion are that it does not depend in any way on Active Directory, and that it integrates well with open source standards like Open LDAP and University of Washington IMAP. Its downsides are that the documentation is sparse and scattered, that is is backed with PostgreSQL rather than MySQL, and that the package is bundled into a TON of RPM's.

I have not tried installing it from source, though I suspect that it would not be much more work than using the RPM's. Anyhow, if you want to install it for yourself, here are some quick scripts to help you, as well as some quick cookbook instructions. I installed it on RHEL 3 Workstation, though I suspect that it would work most Linux distributions.

The first thing we have to do is install the foundation for OpenGroupWare From the RHEL CD's or Website:

Install apache
Install PostgreSQL
Install PostgreSQL-devel
Install php
Install php_PostgreSQL

Next, run the following commands to get the database and webserver started:

# /sbin/chkconfig httpd on
# /sbin/chkconfig postgresql on
# /sbin/service postgresql start
# /sbin/service httpd start

Sendmail should already be installed and running, but if not, you will have to install it as well.

OK, so I said before that there are a TON of RPM's that you will have to install. These can be found at the OpenGroupWare website. Get them however you want, but if you have "wget" installed, you can use my script to fetch everything you need. You can omit the "devel" packages if you don't want to install the source code.

  1. ###### SNIP #######
  2. #!/bin/sh
  4. wget
  5. wget
  6. wget
  7. wget
  8. wget
  9. wget
  10. wget
  11. wget
  12. wget
  13. wget
  14. wget
  15. wget
  16. wget
  17. wget
  18. wget
  19. wget
  20. wget
  21. wget
  22. wget
  23. wget
  24. wget
  25. wget
  26. wget
  27. wget
  28. wget
  29. wget
  30. wget
  31. wget
  32. wget
  33. wget
  34. wget
  35. wget
  36. wget
  37. wget
  38. wget
  39. wget
  40. wget
  41. wget
  42. wget
  43. wget
  44. wget
  45. wget
  46. wget
  47. wget
  48. wget
  49. wget
  50. wget
  51. wget
  52. wget
  53. wget
  54. wget
  55. wget
  56. wget
  57. wget
  58. wget
  59. wget
  60. wget
  61. wget
  62. wget
  63. wget
  64. wget
  65. wget
  66. wget
  67. wget
  68. wget
  69. wget
  70. wget
  71. wget
  72. ###### /SNIP #######

Ok, so now we have a directory filled up wit RPM's. Many of these have a lot of dependancies, so the order of install is important. The script below has them in the correct order, so you can either use it as a reference to install them yourself, or just save the script in the directory that has all your RPM's and run it. Your choice.

  1. ###### SNIP #######
  2. #
  3. #!/sbin/sh
  4. rpm -Uvh ogo-gnustep_make-1.10.0-0.i386.rpm
  5. rpm -Uvh sope45-xml-4.5.8-r1321.0.i386.rpm
  6. rpm -Uvh sope45-xml-devel-4.5.8-r1321.0.i386.rpm
  7. rpm -Uvh libfoundation11-1.1.3-r155.0.i386.rpm
  8. rpm -Uvh libfoundation11-devel-1.1.3-r155.0.i386.rpm
  9. rpm -Uvh sope45-core-4.5.8-r1321.0.i386.rpm
  10. rpm -Uvh sope45-core-devel-4.5.8-r1321.0.i386.rpm
  11. rpm -Uvh sope45-mime-4.5.8-r1321.0.i386.rpm
  12. rpm -Uvh sope45-mime-devel-4.5.8-r1321.0.i386.rpm
  13. rpm -Uvh sope45-appserver-4.5.8-r1321.0.i386.rpm
  14. rpm -Uvh sope45-appserver-devel-4.5.8-r1321.0.i386.rpm
  15. rpm -Uvh sope45-gdl1-4.5.8-r1321.0.i386.rpm
  16. rpm -Uvh sope45-gdl1-devel-4.5.8-r1321.0.i386.rpm
  17. rpm -Uvh sope45-ldap-4.5.8-r1321.0.i386.rpm
  18. rpm -Uvh sope45-ldap-devel-4.5.8-r1321.0.i386.rpm
  19. rpm -Uvh sope45-ldap-tools-4.5.8-r1321.0.i386.rpm
  20. rpm -Uvh ogo-logic-1.1.5-r1717.0.i386.rpm
  21. rpm -Uvh ogo-logic-devel-1.1.5-r1717.0.i386.rpm
  22. rpm -Uvh ogo-logic-tools-1.1.5-r1717.0.i386.rpm
  23. rpm -Uvh ogo-docapi-1.1.5-r1717.0.i386.rpm
  24. rpm -Uvh ogo-docapi-devel-1.1.5-r1717.0.i386.rpm
  25. rpm -Uvh ogo-docapi-db-project-1.1.5-r1717.0.i386.rpm
  26. rpm -Uvh ogo-docapi-db-project-devel-1.1.5-r1717.0.i386.rpm
  27. rpm -Uvh ogo-docapi-fs-project-1.1.5-r1717.0.i386.rpm
  28. rpm -Uvh ogo-docapi-fs-project-devel-1.1.5-r1717.0.i386.rpm
  29. rpm -Uvh ogo-webui-core-devel-1.1.5-r1717.0.i386.rpm
  30. rpm -Uvh ogo-webui-app-1.1.5-r1717.0.i386.rpm ogo-theme-default-1.1.5-r1717.0.i386.rpm ogo-webui-resource-en-1.1.5-r1717.0.i386.rpm ogo-webui-resource-de-1.1.5-r1717.0.i386.rpm
  31. rpm -Uvh ogo-environment-1.1.5-0.i386.rpm
  32. rpm -Uvh sope45-ical-4.5.8-r1321.0.i386.rpm
  33. rpm -Uvh sope45-ical-devel-4.5.8-r1321.0.i386.rpm
  34. rpm -Uvh sope45-gdl1-postgresql-4.5.8-r1321.0.i386.rpm
  35. rpm -Uvh mod_ngobjweb-2.0.46-r1323.0.i386.rpm
  36. rpm -Uvh ogo-database-setup-1.1.5-0.i386.rpm
  37. rpm -Uvh ogo-pda-1.1.5-r1717.0.i386.rpm
  38. rpm -Uvh ogo-pda-devel-1.1.5-r1717.0.i386.rpm
  39. rpm -Uvh ogo-theme-blue-1.1.5-r1717.0.i386.rpm
  40. rpm -Uvh ogo-theme-kde-1.1.5-r1717.0.i386.rpm
  41. rpm -Uvh ogo-theme-ooo-1.1.5-r1717.0.i386.rpm
  42. rpm -Uvh ogo-theme-orange-1.1.5-r1717.0.i386.rpm
  43. rpm -Uvh ogo-tools-1.1.5-r1717.0.i386.rpm
  44. rpm -Uvh ogo-webui-calendar-1.1.5-r1717.0.i386.rpm
  45. rpm -Uvh ogo-webui-contact-1.1.5-r1717.0.i386.rpm
  46. rpm -Uvh ogo-webui-core-1.1.5-r1717.0.i386.rpm
  47. rpm -Uvh ogo-webui-mailer-1.1.5-r1717.0.i386.rpm
  48. rpm -Uvh ogo-webui-mailer-devel-1.1.5-r1717.0.i386.rpm
  49. rpm -Uvh ogo-webui-news-1.1.5-r1717.0.i386.rpm
  50. rpm -Uvh ogo-webui-project-1.1.5-r1717.0.i386.rpm
  51. rpm -Uvh ogo-webui-resource-basque-1.1.5-r1717.0.i386.rpm
  52. rpm -Uvh ogo-webui-resource-dk-1.1.5-r1717.0.i386.rpm
  53. rpm -Uvh ogo-webui-resource-es-1.1.5-r1717.0.i386.rpm
  54. rpm -Uvh ogo-webui-resource-fr-1.1.5-r1717.0.i386.rpm
  55. rpm -Uvh ogo-webui-resource-hu-1.1.5-r1717.0.i386.rpm
  56. rpm -Uvh ogo-webui-resource-it-1.1.5-r1717.0.i386.rpm
  57. rpm -Uvh ogo-webui-resource-jp-1.1.5-r1717.0.i386.rpm
  58. rpm -Uvh ogo-webui-resource-nl-1.1.5-r1717.0.i386.rpm
  59. rpm -Uvh ogo-webui-resource-no-1.1.5-r1717.0.i386.rpm
  60. rpm -Uvh ogo-webui-resource-pl-1.1.5-r1717.0.i386.rpm
  61. rpm -Uvh ogo-webui-resource-pt-1.1.5-r1717.0.i386.rpm
  62. rpm -Uvh ogo-webui-resource-ptbr-1.1.5-r1717.0.i386.rpm
  63. rpm -Uvh ogo-webui-resource-sk-1.1.5-r1717.0.i386.rpm
  64. rpm -Uvh ogo-webui-task-1.1.5-r1717.0.i386.rpm
  65. rpm -Uvh ogo-xmlrpcd-1.1.5-r1717.0.i386.rpm
  66. rpm -Uvh ogo-zidestore-1.1.5-r1717.0.i386.rpm
  67. rpm -Uvh ogo-zidestore-devel-1.1.5-r1717.0.i386.rpm
  68. rpm -Uvh ogo-meta-1.1.5-r1717.0.i386.rpm
  69. ###### /SNIP #######

Some things to note about the install.

These all have to be done on one line or "rpm" will complain that it can's resolve dependancies:
rpm -Uvh ogo-webui-app-1.1.5-r1717.0.i386.rpm ogo-theme-default-1.1.5-r1717.0.i386.rpm ogo-webui-resource-en-1.1.5-r1717.0.i386.rpm ogo-webui-resource-de-1.1.5-r1717.0.i386.rpm

ogo-database-setup-1.1.5-0.i386.rpm sets up your PostgreSQL database and database user for you. The output should look something like this:

Preparing...                     ########################################### [100%]
1:ogo-database-setup             ########################################### [100%]
PostgreSQL seems to be already initialized
and I can see it running:
PIDS used: 3456 3458 3459
We're on PostgreSQL 7 (7.4)
checking /var/lib/pgsql/data/postgresql.conf
need to patch /var/lib/pgsql/data/postgresql.conf for 7.4
backup current one to /var/lib/pgsql/data/postgresql.conf.20061213-153319
checking /var/lib/pgsql/data/pg_hba.conf
need to patch /var/lib/pgsql/data/pg_hba.conf for 7.4
backup current one to /var/lib/pgsql/data/pg_hba.conf.20061213-153319
The changes we've made require that we restart PostgreSQL...
Stopping postgresql service:    [  OK  ]
Starting postgresql service:      [  OK  ]
OK! PostgreSQL runs again: (3909 3911 3912)
creating database user: OGo
creating the database itself: OGo
we've successfully created both the user OGo and the raw database OGo
we'll now fill the database with the scheme itself
checking the logfile created during scheme rollin... 
removing log - not needed anymore

OK... Now everything is installed, and if you run the following command:

# /sbin/chkconfig --list | grep ogo

You should see the following output:

ogo-zidestore   0:off   1:off   2:on    3:on    4:on    5:on    6:off
ogo-webui       0:off   1:off   2:on    3:on    4:on    5:on    6:off
ogo-xmlrpcd     0:off   1:off   2:on    3:on    4:on    5:on    6:off
ogo-nhsd        0:off   1:off   2:on    3:on    4:on    5:on    6:off

Now, let's fire up these services:

# /sbin/service ogo-zidestore start
# /sbin/service ogo-webui start
# /sbin/service ogo-xmlrpcd start
# /sbin/service ogo-nhsd start

Everything should be up and running now, so you can grab a web browser and go to the following RUL:

You will be logged in as the root user, so make sure to change the password.

If you are using this system as a stand-alone server, you are pretty much all set. We needed to authenticate it against our central LDAP, and point it towards our IMAP server though, so I added the following lines to "/var/lib/":

LSAuthLDAPServer = "";
LSAuthLDAPServerRoot = "dc=mydomain,dc=com";
imap_host = "";
UseSkyrixLoginForImap = YES;

Make sure to put these lines at the end of the file, but before the closing braces.

The file should look something like this:

###### SNIP #######
"skyrix_id" = "";
LSConnectionDictionary = {
  databaseName = OGo;
  hostName = "";
  password = "";
  port = 5432;
  userName = OGo;
  LSNewsImagesPath = "/var/lib/";
  LSNewsImagesUrl = "/ArticleImages";
  Languages = (
  TimeZoneName = GMT;
  WOHttpAllowHost = (
  LSAuthLDAPServer = "";
  LSAuthLDAPServerRoot = "dc=domain,dc=com";
  imap_host = "";
  UseSkyrixLoginForImap = YES;
###### /SNIP #######

Since the system won't let you authenticate the "root" user against the local database if your are using LDAP, you have to create a root user on your central LDAP.

Create an LDIF file called root.ldif like so:

###### SNIP #######
dn: uid=root,ou=People,dc=mydomain,dc=com
objectClass: organizationalPerson
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
uid: root
uidNumber: 0
gidNumber: 0
sn: Root
cn: Root
homeDirectory: /root
loginShell: /bin/bash
gecos: Root
###### /SNIP #######

Finally, run the following command to add the root user:

ldapadd -x -D "cn=Manager,dc=mydomain,dc=com" -W -f root.ldif"

You should now be authenticating against your central LDAP server. Have fun!

Blue Seed Review

Buying anime without first having seen at least one episode is a gamble, and I'm happy to say that Blue Seed is one gamble that definitely paid off! The story is solid, the animation quality is superb and the characters are all incredibly likable. There's is even some fanservice to top it all off.

Blue Seed is a Television series with 26 episodes that are 25 minutes each. It is based largely on the Shinto legend of Susano'o and the Yamata no Orochi. In Japanese mythology, Susano'o (須佐之男命) is the god of the sea and storms and Yamata no Orochi (八岐の大蛇) is a huge eight-headed snake. In this series, Susano'o is the young God of the Aragami, and Yamata no Orochi is one seriously angry tree.

The female lead is a cute girl named Fujimiya Momiji who is part of the Kushinada clan which has been tasked for centuries with protecting Japan from the Aragami, a plant-based race of monsters who would level the nation and revert all humans back into vegetation. Momiji becomes part of a government sponsored agency called the TAC, which is responsible protecting Japan from Aragami and researching their true purpose.

Kusanagi Mamoru is a half-plant, half-human man that has been given the task of protecting the Kushinada. He and Momiji become a team of sorts, and of course, she ends up falling in love with him. When the series begins it seems like he's going to end up being a bit of a jerk, but like all the characters in this anime, he ends up being very likable, and his flirtation with Momiji is down right hilarious. Momiji is not a the typical helpless girl we see so often in anime, but she does end up getting herself in trouble a lot, and Kusanagi is always there to rescue her.

One of the things I like most about anime is the romantic tension that is built up between characters. This series has that to be sure, but unlike many titles the relationship actually goes somewhere. Not wanting to spoil anything, I won't say how it all times out, but suffice to say, we aren't left at the end of the last episode wondering if the two will get together.

It is also refreshing that we are not left with a bewildering feeling of ambiguity when the series ends. I remember reading somewhere that this series is like Neon Genesis Evangelion without the downtime. I would have to agree. It predates NGE by more than a year, but the story never falls apart, and the ending is actually quite good! Highly recommended and a true classic!

Japanese Sushi Police Crack Down

Japanese food, and sushi in particular, has become very popular around the world, and inevitably the word has managed to screw it up. So much so, in fact, that many Japanese citizens are coming back from traveling abroad and calling their government with complaints about soggy seaweed, limp noodles and sushi with toppings that are far from traditional.

As Japan is a culture that values its tradition and national identity, the Japanese Agriculture Ministry has responded by putting together a blue ribbon panel of experts and tasking it with evaluating and certifying the world sushi restaurants. The panel is set to unveil its standards for certification by the end of February, and starting next April, inspectors will spread out around the world to give restaurants either the all-important stamp of approval or the dreaded stamp of shame.

Some people think it's not right for the Japanese government to impose their rigid standards on restaurants in other countries, but I disagree. Perhaps it's just that I'm more interested in Japanese culture than the average person, but when I go out for sushi, I'm also trying to learn something about Japanese etiquette. Should I ever find myself in Japan, or any other country for that matter, I would like to have some idea what I'm doing so I'm not seen as just another stupid American tourist.

Setting Up The Automounter Service on RHEL

Mounting filesystems in RHEL is pretty straightforward and easy. Occasionally, however, you will not want the filesystem to remain mounted all the time, but rather to automatically mount for a set period of time only when it is needed. Because of networking overhead, and the general unreliability of networks, NFS mounts are a good example of when this can be especially useful.

In order to manage the automatic mounting and unmounting of filesystems on RHEL, we use the Automounter service. Here is how.

First, The main configuration file is "/etc/auto.master". It should look something like this:

# $Id: auto.master,v 1.3 2003/09/29 08:22:35 raven Exp $
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#/misc  /etc/auto.misc --timeout=60
#/misc  /etc/auto.misc
#/net   /etc/

Let's assume that we want to set up an NFS mount on "/misc/backups". We would first create an entry in this file that looks something like this:

/misc   /etc/auto.misc --timeout=120

This tells the autofs service that we want to use it to manage mounts from within "/misc", that the configuration file is "/etc/auto.misc", and that it should disconnect after 2 minuets of inactivity.

Now, let's edit the "/etc/auto.misc" file. The file has three columns: the mount point from within the /misc directory, the options for mounting the filesystem, and the filesystem to be mounted. It also includes the remote server's name since we are using NFS. It should look something like this when you are done:

# $Id: auto.misc,v 1.2 2003/09/29 08:22:35 raven Exp $
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# Details may be found in the autofs(5) manpage

cd              -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
backups         -rw,soft,intr remoteservername:/path/to/nfs/export

# the following entries are samples to pique your imagination
#linux          -ro,soft,intr 
#boot           -fstype=ext2            :/dev/hda1
#floppy         -fstype=auto            :/dev/fd0
#floppy         -fstype=ext2            :/dev/fd0
#e2floppy       -fstype=ext2            :/dev/fd0
#jaz            -fstype=ext2            :/dev/sdc1
#removable      -fstype=ext2            :/dev/hdd

Next, we create the directory for the mount point in /misc:

# mkdir /misc/backups

And finally we restart the autofs service:

# service autofs restart

That should pretty much do it. If you don't have autofs configured to start up, you can use chkconfig to enable it. "/misc/backups" will now be mounted whenever a user or process attempts to access data on it, and it will be automatically disconnected after 120 seconds of inactivity. Last, but not least, you can always confirm that it is running with the "service" command:

# service autofs status

As always, change the details to match your own requirements.