How many times have you made a change to a server to only a couple of days or weeks later discover the change you did broke something? It happened to me a bunch of times. Sure, call me irresponsible, but sometimes I’m in a rush and don’t have time to document the change and write nice comments about it. I try to do so, but sometimes I forget.

For quite some time I’ve thought about a simple way to track the changes to my servers, but without coming up with any perfect solution. My ideas have included everything from wikis to blog-style logging to Tripwire. Sure, a change-blog would work, but it would take quite some extra time to write the entry.

One day when I was working with our development tracker a quite brilliant solution stroke me: why not use CVS/SVN on /etc? It sounds like overkill, but it would do the trick. By using this you would be able to:

* Display when the changes were made
* See what change was made
* Revert to a previous version

There are two different ways to go along using a repository for /etc. One way is to create a CVS/SVN tree on a different server and sync the entire /etc directory to that repository. The benefit with this is that you could have the repository on a different server and be to collect all your servers /etc on the same repository. By combining this with a web-interface, one would be able to easily compare and contrast the configurations of the different servers. Moreover, the change logs would be kept in the repository, and not on the individual servers, creating a cleaner file-structure. Another benefit would be that you could easily sync the /etc filesystem with your local workstation and modify/create your config-files there. The drawback with this solution is that you need to make your local changes first, and then upload the files to the repository. Once you’ve uploaded the files from your local workstation you can go ahead and sync the actual server with the repository to commit the changes.

Another solution would be to use a custom file-system. There are two different filesystem that supports version-tracking: CVSFS and Wayback. Between these two alternatives, Wayback appears to be the most developed alternative. Worth noting though is that both these alternatives only targets the Linux-platform.

The benefit for using such approach is that you don’t need to set up a separate repository to keep the files in, as well as that it enables you to make changes in a traditional way on the server. The drawback is that neither of these two filesystems are very well maintained. It appears that both these programs were last updated back in 2004, rendering them both quite obsolete. The question is if you really want to put the faith of your /etc-folder in a program that no one longer maintain.

Regardless of which one of these two alternatives you find most appealing, the concept is very interesting. I have still not tried to use this myself, but I would certainly argue that having a /etc-folder that allows you to keep track of changes is far superior to the traditional way of keeping /etc.

Edit 1: Since the article was published, I’ve found two more file-systems worth mentioning: CopyFS and ext3cow. Both these filesystems appears to be useful for /etc usage. Out of these two alternatives, ext3cow appears to be more sophisticated. However, CopyFS appears to be easier to set up.

           

If you’ve followed us for a while, you might remember our article ‘Selecting an Accounting System’. Not too many things have changed since then. The developers over at Quickbooks are still not competent enough to write an OS independent web-app, and no other major events have occurred. The most interesting thing that have happened since we wrote the article was that SQL-Ledger silently changed license from GPLv2 to SQL-Ledger Open Source License. Although we would rather have seen SQL-Ledger staying GPLv2, we don’t really blame them. The company needs to make some money in order to survive. So, despite the change of license, we still decided to use SQL-Ledger as our accounting system. At least for now.

Enough about that, let’s get started. First time I installed SQL-Ledger I ran into a couple of problems. Even though I spent a fair amount of time doing research on how to set everything up, I still hit a couple of speed bumps. Since I’m quite new to PostgreSQL, some of my problems were related to this. Some other problems were related to the fact that the manuals did not really match what I saw on the screen.

Now, let’s get started. First we start with updating the ports to make sure we’re getting the latest version.

# portsnap fetch; portsnap update


After updating our ports-tree, we need to install PostgrsSQL. When writing this post, the 8.2-series is the latest stable series.

# cd /usr/ports/database/postgres82-server/
# make config


Select the flags you prefer. The only flag I changed from the default was the optimization flag. Not that I know if it makes much of a different, but if you’re compiling it you might as well try to build more optimized binaries.

# make install


Now Postgres is installed. However, in the normal FreeBSDish manner, we need to enable it in rc.conf before we can fire it up.
Edit /etc/rc.conf and add postgresql_enable=”YES”

When you’ve activated Postgres, we first need to initiate the database, and then start the service.

# /usr/local/etc/rc.d/postgresql.sh initdb
# /usr/local/etc/rc.d/postgresql.sh start


Voila, now we have Postgres initiated and up running.

Let’s take a look at the package we’re actually interested in installing: SQL-Ledger.

We’re just going to use a simple ports-installation of SQL-Ledger.

# cd /usr/ports/finance/sql-ledger
# make install


After installing the package, we need to make changes to Apache in order to enable SQL-Ledger. Simply add the following line at the appropriate location in your httpd.conf or ssl.conf:

Include /usr/local/etc/sql-ledger-httpd.conf


To make sure our Apache-file is intact, we run:

# apachectl -t


And if that went well, we run:

# apachectl restart


The only step remaining now is some database-related stuff.
Since I’m not an expert at Postgres, I might not be explaining this in the best way. Anyways, I’m just trying to share my experience, since this was the step where I ran into some speed bumps when first setting up SQL-Ledger. The problems I was facing was that the prompts I received differed quite a bit from the ones found in the various manuals I read before installing.

First, log into the Postgres user

# su - pgsql


When you’re logged in, we need to create a user for SQL-Ledger:

# createuser -d -P sql-ledger
Enter password for new role:
Enter it again:
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) y


Note that if you remove the -P, you won’t be prompted for password. However, I personally prefer setting a password here.

Lastly, we need to copy the template.

#createlang plpgsql template1


Hopefully that went without any problems. Now it’s time to surf into SQL-Ledger to make the final configurations. Open your browser and surf into http:///sql-ledger/admin.pl. Log in without any password.

Select the “Database Administration” link.

Use the user ‘sql-ledger’ and the password you assigned when creating it. For ‘connect to,’ use ‘template1.’ When you’re done filling that out, hit ‘create dataset.’

The next screen that will pop up is the Create Dataset-screen. Here you need to set the name of your dataset. Use only lower-case letters. I’d suggest the name ‘sql-ledger’ to keep things from being complicated later on. For ‘encoding,’ select UTF8. As for the ‘chart of accounts,’ it really depends on what business you’re setting up SQL-Ledger for.

You’re done! All you need to do now is to set up the users. Since this is quite straight forward, I’m not going to cover that.

For more information, please visit sql-ledger.org. You might also want to take a look at this ‘unofficial’ manual (the official one costs $190).

Edit 1: Dieter Simader, the founder of SQL-Ledger, e-mailed me to point out that the only non-GPL’d version of SQL-Ledger is the 2.8-series. The 2.6-series used by FreeBSD ports is still under GPL.

           

In the past I have used MoinMoin Wiki for my wiki needs, with great success . MoinMoin Wiki is very easy to set up and doesn’t have all too fancy requirements on the server side. The other day I was setting up a new wiki, and unlike my previous wiki projects this one would be facing the public. In order to get the syntax, template system and features most people recognize I went with the famous, Wikipedia powering MediaWiki software instead.

MediaWiki requires much more manual work to install than MoinMoin Wiki. Unfortunately, I was unable to find a comprehensive guide detailing how to go from scratch to fully operational wiki. There is the Installation Guide which details the basic server setup. It then redirects you to two pages: one on configuration and one on administration. Most of these documents are fine but at the time of this writing the ‘configuration’ document is fairly empty and I was left wondering about many configuration options. Hence this guide which will try to tie together all the things you need in order to get up and running.

To keep things moving this guide will be written at a fairly advanced level. If you don’t feel comfortable installing server side software you may want to check out some of our other How To’s for inspiration.

These instructions are suitable for FreeBSD 5.3-RELEASE-p37 and MediaWiki 1.9.3, although you will probably find it useful regardless of the platform and MediaWiki version you use.

Basic Installation

This part is covered very well by the Installation page of MediaWiki. Here’s the super condensed FreeBSD take on installation:

To install MediaWiki in FreeBSD,

# cd /usr/ports/www/mediawiki
# make install

This will install MediaWiki into /usr/local/www/mediawiki/, by default. You will probably want to copy this installation to some other folder since MediaWiki changes files in its installation folder during use.

# cp -Rf /usr/local/www/mediawiki /www/mywiki

Then,

1. Make sure the config folder is writable by the httpd user (www usually).
2. Set up your web server to serve pages from the location.
3. Surf to your new wiki. You will be prompted to go through an installation procedure. This part is very straight forward.
4. Move config/LocalSettings.php to the root of the wiki installation. You can now delete the config folder.

Now that was the easy part. Here comes the stuff that took a little bit longer to figure out. Thanks to Playing With Wire you’ll be able to do it in minutes! :)

Additional Manual Configuration

The installer does some things but not everything. While many online applications such as WordPress come with fancy online configuration tools, MediaWiki uses more traditional configuration files which you’ll be editing by hand.

Here’s what you’ll need to do:

1. Copy AdminSettings.sample to AdminSettings.php in the base folder. Edit the new file. The config file requires you to configure a database account for maintenance scripts. Presumably you may use the same account you used for the wiki, although I didn’t run any of the maintenance scripts yet to test this.
2. Edit LocalSettings.php. This file has been created for you by the installer, so it will contain some good defaults.

LocalSettings.php is the primary configuration file of your new wiki. This file contains the actual basic settings for MediaWiki, and it overrides the defaults found in includes/DefaultSettings.php. You shouldn’t edit DefaultSettings.php directly, but it should be your first stop if you’re wondering what variables you can put in LocalSettings.php.

Linking up the Help Pages

By default MediaWiki ships without help pages. Unless you want to write them yourself you have a couple of options. The option I chose is to simply copy all Help sections from the primary MediaWiki site – they’re released into the public domain. Follow the instructions on Help:Copying to do this.

You may wish to export the following pages:

Help:Contents
Help:Navigation
Help:Searching
Help:Tracking_changes
Help:Editing_pages
Help:Starting_a_new_page
Help:Formatting
Help:Links
Help:Categories
Help:Images
Help:Templates
Help:Tables
Help:Variables
Help:Managing_files
Help:Preferences
Help:Skins
Help:Namespaces
Help:Interwiki_linking
Help:Special pages
Template:PD_Help_Page
Template:Meta
Template:Admin_tip
Template:Prettytable
Template:Hl2
Template:Hl3
Template:Thankyou
Image:Example.jpg
Image:Geographylogo.png
Help:Editing
Image:PD-icon.svg

This is the same list as found on the Help:Copying page at the time of this writing, with the addition of the two last entries.

Notice that Template:Languages isn’t included in this list, although it is referenced from Template:PD_Help_Page. You may wish to edit the PD Help Page template and remove the {{Languages}} part towards the end to get rid of this dependency.

You will have to download and upload the images separately by clicking them and finding their respective file downloads. Upload the images using the normal ‘Upload file’ link from your wiki. The .svg image probably won’t upload by default. We’ll tackle the SVG format later.

Nice URLs

At this point the installer script has probably given you URLs that look like,

http://www.yourdomain.com/index.php/My_Page

(Unless your PHP runs as a CGI script in which case things might even look worse. Don’t run as CGI.)

To make your URLs more readable, you’ll need to configure both your web server and MediaWiki to cooperate. Here’s a good resource: Using a very short URL.

Basically you will want to edit your httpd.conf, if you can do that, or an appropriate .htaccess file, if you have to. Remember that a .htaccess file is slower than httpd.conf. If you can use httpd.conf, do that and disable .htaccess support.

Here’s how to set things up within Apache’s httpd.conf. Edit your Directory entry to resemble the following:

<Directory /www/mysite.com/>
        Options Includes FollowSymLinks

        AllowOverride None

        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

Notice the AllowOverride None line. This is the part that turns off .htaccess support. It’ll give you a bit of a speed boost since your web server won’t have to look for a .htaccess file for every request made.

Next, add this line to LocalSettings.php:

$wgArticlePath = "$wgScriptPath/$1";

Change the Wiki Theme or Looks

MediaWiki’s term for themes is ‘skins’. The default skin looks exactly like Wikipedia, so you may want to change this if you’re looking to achieve a spiffy unique look for your public wiki.

To find out what skins came with your MediaWiki installation, look in your skins/ folder. You will see something like,

# ls skins 
Chick.deps.php          Nostalgia.php           common
Chick.php               Simple.deps.php         disabled
CologneBlue.php         Simple.php              htmldump
MonoBook.deps.php       Skin.sample             monobook
MonoBook.php            SkinPHPTal.sample       myskin
MySkin.deps.php         Standard.php            simple
MySkin.php              chick

From this list you can infer the list of available skins. In this case it looks like we have Chick, CologneBlue, MonoBook, MySkin, Nostalgia, Simple and Standard. The folder names (the lower case names) are the skin names.

To make the change, edit your LocalSettings.php file again and alter the line that reads,

$wgDefaultSkin = ...

In our case we might put,

$wgDefaultSkin = 'cologneblue';

If you make a mistake setting the property you will get a default skin.

You can find more skins here. Each skin is accompanied by instructions for how to set it up. Normally this involves downloading a zip file and unzipping it into the skins/ folder. You may also have to edit theme files to set up proper paths.

Changing User Access Levels

If you want to disable anonymous editing, you can add something like the following to LocalSettings.php:

$wgGroupPermissions['*'    ]['createaccount']   = true; 
$wgGroupPermissions['*'    ]['read']            = true;
$wgGroupPermissions['*'    ]['edit']            = false;
$wgGroupPermissions['*'    ]['createpage']      = false;
$wgGroupPermissions['*'    ]['createtalk']      = true;

For other possible settings, take a look at the defaults provided in includes/DefaultSettings.php. Again, remember not to edit the defaults file: just copy the lines you want to change to LocalSettings.php and make your changes there.

Support for SVG images

The SVG image file format is very useful but turned off by default in MediaWiki. Look in include/DefaultSettings.php and locate the SVG related stuff. For my installation this is what I had to add to LocalSettings.php:

$wgSVGConverter = 'inkscape';
$wgSVGConverterPath = '';
$wgSVGMaxSize = 1024;
$wgMaxImageArea = 1.25e7;
$wgThumbnailEpoch = '20030516000000';
$wgIgnoreImageErrors = false;
$wgGenerateThumbnailOnParse = true;

$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'svg' );

You will also need to install inkscape. There are options to use rsvg, ImageMagick and others instead but none of those options worked for me. Rsvg and ImageMagick didn’t render gradients right, and I was unable to install the other alternatives on FreeBSD without crashes or other problems. This is unfortunate because inkscape is positively enormous if you also consider all the pre-requirements that you normally wouldn’t have to install on a server. It is the one program that does things right though and SVG is a really nice format to have support for.

Conclusion

That’s it. You are all set. Your next steps will probably be to create your own account and then use the Sysop account to turn your own account into an admin account. Happy writing!

           

A while back I became responsible for the IT infrastructure for another company. Fortunately, these type of companies tend to be easy to manage with the right software and hardware. However, this time I thought about trying something new. For many, many years I’ve been running Linux on the server for a variety of companies, but now I’m thinking about taking things one step further; migrating the desktops. I already did some initial research about what applications the company is using, and it appears as the few ‘Windows only’ applications they’re using can be run through Wine.

With the impressive improvements Ubuntu done to Linux on the desktop, it might be about time to give it a shot. Ubuntu Desktop comes with all softwares needed for the business (word-processing, spread sheet, web-browser, e-mail etc.), which makes it convenient to install and maintain.

At the moment this other company is in really bad shape in terms of their IT infrastructure. They have no server, and use one of their workstations to ‘share’ files used for critical business application. Obviously this needs to change.

If we start with the server, I’m considering using either Ubuntu Server (which goes well with Ubuntu Desktop), or CentOS, which is a clone of RedHat Enterprise Linux for the operating system. As for the hardware, I’m considering some cheap Dell or HP server, with 2 extra SATA hard drives to run on a RAID 1 array for the critical files. Furthermore, the server needs to have a UPS attached to ensure good uptime.

So now we have both our server and desktops running Linux, and we get that good feeling in our chest. Now what? The next (and final thing) is to set up file-sharing and central-user administration. The problem with this step is that there are many different paths to choose. However, I chose tree different options to consider.

Samba PDC login with Samba file-sharing
• Benefit: Works well even in a mixed environment with Windows Machines.
• Drawback: No native UNIX filesystem, hence no support for UNIX privileges on files.

Kerberos with NFS file-sharing
• Benefit: Been around for quite some time. Fully compatible UNIX filesystem. Recommended by FreeBSD’s handbook.
• Drawback: More complicated to setup. A 2nd slave server strongly recommended.

NIS with NFS file-sharing
• Benefit: Also been around for quite some time. Fully compatible UNIX filesystem. Easy to setup.
• Drawback: Old. Not as secure as Kerberos.

All of these solutions may be run with OpenLDAP as a back-end, which makes administration and integration of other application easier later on. In one way the flexibility of Linux/Unix may become somewhat of a disadvantage. Since there are almost infinitely many ways to approach this problem, it involves a great amount of research.

In my research, I posted first a post at Ubuntu’s forum, and then later a post at Gentoo’s forum. However, none of them really gave me a good answer. Right now I’m leaning toward Kerberos, since it appears to be more secure and robust.

Since this project is scheduled for the summer, I haven’t started implementing this yet. However, I’m curious about what you readers think. How would you approach this problem?

             

What is Samba?

For all you new users out there, I just want to let you know that Samba is great piece of Open Source software. It solves many issues for both sysadmins and ordinary users. What it does is to give UNIX users the ability to share files and printers with Windows users. Since Samba is available on most modern platforms, it’s also a great way to share files in a multi-platform environment. Samba can even act PDC (Primary Domain Controller), and BDC (Backup Domain Controller) to handle domain logins from Windows clients. PDCs and BDCs were something that used to required a purchase of a Windows NT or Windows 2000/2003 Server license, but they can now be done fairly simple with Samba under UNIX or Linux.

Now that you know a bit about Samba, lets get started.

Adding a public share to Samba

One of the things I miss as a default feature in OS X is the ability to share folders with Samba. The default configuration of Samba only shares the users’ home directories after authorization. However, since I wanted to share my files with non-Mac users, I simply made some changes to smb.conf (the Samba config-file). After running Samba in various *nix-environment for years, this was a simple modification to do.

First open the Terminal, and type in the following commands:

$ sudo nano /private/etc/smb.conf

Now you’re in a text editor called Nano. A simple, but useful editor. Scroll down to the end of the first part, under the [global] section, and type in the following:

security = share
workgroup = whatever-your-workgroup-is-called
netbios name = Your-computers-name

Note that under Tiger (might be under other versions too), the line “workgroup” already exists. If that is the case, then just replace whatever it was previously set to with your workgroup of choice.

That was the first part. Now you’ve made it possible for everybody to access you public shares.
By default though, Samba isn’t configured to have any public shares. Don’t worry, we’ll take care of that next.

Now it’s time to add the actual sharing to the list of public shares. This is done by adding the following lines to your Samba file. There are different ways to configure a share in Samba, but this is a pretty straight-forward and simple way. At the end of the file, add the following lines (still under the [global] section):

[public]
path = /path/to/the/share
public = yes
only guest = yes
writable = no
printable = no

Where [public] can be set to whatever name you want for your share, and the path is equal to the path to
the directory you want to share.

Note that you can add as many shares as you’d like. Also, pay attention to the line that says writable: that line determines whether you clients will be able to write files to your share or not. If you want your share to be writable, you want this to say “writable = yes”.

Make sure that there are no typos, and that everything looks proper. Exit Nano and save changes to the file by pressing “ctrl + x” followed by “y” and Enter.

Now we need to set the proper permission to the shared folder. The simplest way to do this is to just type the following command:

$ chmod -R a+rx /path/to/the/share

Note that if you decided to allow write-access to the share, use the command $ chmod -R a+rwx /path/to/share instead of the above command

To verify that your smb.conf is properly configured, we use a command called ‘testparm’. In the Terminal, type:

$ testparm

Look at the output. If you observe something that doesn’t look right, back up and fix the error in smb.conf.

If everything did work out fine, you’re just one step from getting your share visible. The last step is to fire up samba (or restart it if you already had it running). This is can be done either through the System Preferences, or trough the console. I prefer the latter, and here are the commands:

$ sudo service smbd stop
$ sudo service nmbd stop
$ sudo service smbd start
$ sudo service nmbd start

Connecting to the share(s)

Now you’re supposed to be up and running. The most simple way to test if everything worked is to mount your share locally. Here is how it’s done:

In Finder, go to the menu “Go” and click at “Connect to Server” and type in:

You will most likely be prompted for username and password now, but just hit “ok” without entering anything. Since it’s a public share, anyone is able to access it without authorization.

If everything went well, you will find your share mapped in Finder. Now all Windows machines and *nix-machines should be able to browse your files.

This is the beauty with OS X: you are running a commercial desktop OS, but still have all the benefits that a UNIX-environment brings. Running UNIX-programs (as Samba) is done painlessly.

Since Samba is a part of Mac OS X out-of-the-box, Apple has already done half the work for you. The possibilities are many: theoretically, you could make your Mac act as a PDC and replace an entire Windows NT or Windows 2000/2003 Server. I’m not sure about what modifications Apple has done to the source, but if you compile the source code from scratch yourself, it shouldn’t be too hard. Samba simply gives UNIX-users the ability to share files and printers with Windows users.

Please give us feedback if something didn’t work for you.

For further information about Samba, please visit samba.org.

If you have the possibility, please donate to the Samba-team. These guys work for free, and contribute with a lovely piece of software to the Open Source-world. However, they are in need of your donations to be able to invest in new hardware needed to improve Samba further.