oscartheduckin’ around

October 13, 2008

remote port building issue #1

Filed under: freebsd — Tags: , — oscartheduck @ 4:28 pm

So, I have some ruby and some shell. I think the shell is doing better than the ruby, but I can also see where teh ruby is coming in.

I have this vague design in mind:

1. locally, you state that you want to perform installation of port X.
2. a list is built which is rsynced over to the remote machine
3. the remote machine has a daemon listening which can build the packages — yeah, there’s a good chance of a security hole here, but that’s recognised.
4. build the software as packages remotely
5. notify the machine that its build is ready — some mechanism to acknowledge this and allow for the reverse rsync automagically will be nice.
6. install the packages

Now, see the problem? Libraries. Ports are nefarious beasts; the machines need to perfectly in sync to do this easily, which is doable with Jails, but.

I don’t want jails to have to be the solution. Building the packages statically would help out, but inflate things.

I need to work out what changes to the ports infrastructure would make this easier. Any ports ninjas reading this?

October 12, 2008

decisions, decisions, decisions

Filed under: freebsd, ruby — Tags: , , , — oscartheduck @ 8:04 pm

I’ve been thinking about writing a new ports installation tool which solves a few problems I’ve always thought would be neat to solve. Thus:

1. decision 1 — write a new ports tool or extend an existing one?

This is really hard. I’d write a new ports tool in ruby or shell. Guess what the two existing main ports tools are written in? That’s right, ruby and shell! So I just sit here thinking about the wisdom of potentially rewriting a lot of functionality. Especially with portupgrade being written by a hacker who’s ten times the programmer I am, and portmaster being, well, fucking fantastic.

Here’s some of my aims:

1. The ability to instruct a remote machine to build every port needed
for a local upgrade of ports as a packaged to be pkg_added.
2. The ability to cross compile everything. This means that a local
arm board can upgrade its onboard dns server by having a remote
xeon based computer build the port.
3. The ability to run the command without super user privileges. I
want to have a directory I have write access to that my ports
can build to and be able to do an upgrade of those ports
4. The ability to synchronise ports across machines. This should be
architecture independent, and should take into account that
ports can with this tool be installed into home.

Which leads to decision 2:

2. How do I technologically best accomplish this?

Which is the same as decision one, really.

There are so many decisions. How do you search for a port when someone wants to install it? The other two tools I usually use for this stuff answer this question by saying “we don’t”.

So, accepting my premise that I’m not as good as these other folks at solving this issue, I won’t either.

A second: how do you determine if a port is to be upgraded? Well, there are two options I see:
1. roll my own method of doing so
2. use someone else’s method of doing so

I prefer the idea of number 2. Software is something that should be built modularly, so that each piece can be upgraded independently. And if I just use someone else’s tool, then I inherit their improvements.

portupgrade looks like the tool I shoould be thinking about, but I don’t want to follow their design decisions. I instinctively think portmaster has the right idea with not using an external database; maintaining pkgdb is annoying, irritating, and a whole host of other words which mean the same damn thing. There are a host of poorly documented prompts when repairing the database; stale dependency, eh? Great! What does it MEAN? I’ve always _assumed_ it was a reference to the idea that a dependency listed in the database is no longer needed, or somesuch thing; googling around can tell you, I’m sure, but the man page for pkgdb doesn’t, and if it ain’t in the man page then it’s undocumented. And that means that yes, I do consider man man to be inadequate because it tells you there a re other sections of the manual but doesn’t tell you _what_they_are_. I know what they are, they’re historically significant and everyone should know them, but man man should list them too.

I’m getting dangerously close to ranting, when I’m actually trying to document something. The aim here is to give people who’ve never written this sort of tool an idea of how the thought process goes. It’s all decisions, and no decision is correct.

June 30, 2008

Eleven. Megabytes. Suckers.

Filed under: freebsd — oscartheduck @ 1:43 am

I emailed my mentor yesterday night with the news that I now have FreeBSD available in 11meg.

And I can shrink it further.

There’s really a simple objection to this statement, though. It is implied by this: “James, have you tested that thing yet?” and the answer is, “OHGOTOHELL”. Evidence of the cruftiness of this thing is available in the fact that this tiny 11 meg of nothing sits in a whopping great big 493 meg disk image that I haven’t shrunk down yet.

I imagine I’ve screwed /etc/rc up, too. But that thing’s tiny, really. It’ll be simple enough.

Where am I going from here:

1. verify the functionality. Yeah, I have to do this still. Once I can boot to the command prompt, I’ll be happy.

2. once I have that functionality, evaluate needed binaries and crunchgen ’em. I think of this in a vague way as returning TinyBSD to its PicoBSD roots, though this shouldn’t be read as my hubristically stating I’m as awesome as the TinyBSD developers or PicoBSD.

3. cross compile for ARM. The aim for this has been from the start to build it for non-x86 chips. ARM especially is so huge right now it makes sense as a target.

In a moment of blog type reminiscence, one of my friends was a huge Acorn fan, so working with ARM feels like looking back on my past somehow.

I told my mentor that I felt peculiar about this project because it’s so clearly not the same as many other projects, and as he has many times already he gave me the right advice. This isn’t a development down-on-the-ground-pointing-pointers kind of project, it’s a 10 000 foot view project. I feel daft because it’s not as down in the works as I’d like sometimes, but I feel good because I look at what I’m doing and it’s basically using these fantastic tools that other developers have spent their time making.

Thus far, TinyBSD is the main tool I’ve been working with. Those folks have making a small OS down to such a simple tool, it’s hard for me to imagine doing this without it.

June 7, 2008

booting to pxe

Filed under: freebsd — oscartheduck @ 6:52 pm

My initial plan was to only use compact flash, but I have to buy a card. So for your viewing pleasure, the initial boot screen. PXE server appearing on my laptop in a couple of hours.

U-Boot 1.1.5 (Nov  2 2006 – 10:31:07)

DRAM:  64 MB
NAND:  NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (<NULL> NAND 256MiB 3,3V 8-bit)
256 MiB
Nb pages:   8192
Page Size:   1056
Size= 8650752 bytes
Logical address: 0xD0000000
Area 0:x09D0000000 to D0003FFF (RO)
Area 1:x09D0004000 to D0007FFF
Area 2:x09D0008000 to D0037FFF (RO)
Area 3:x09D0038000 to D083FFFF
In:    serial
Out:   serial
Err:   serial
DM9161A PHY Detected
No link
MAC: error during RMII initialization
Hit any key to stop autoboot:  3 x08x08x08 2 x08x08x08 1 x08x08x08 0
DM9161A PHY Detected
No link
MAC: error during RMII initialization
BOOTP broadcast 1

April 30, 2008

Reading code

Filed under: freebsd, Uncategorized — oscartheduck @ 1:58 am

Today, I finally got to really start a beginning on my embedded BSD proposal; I started reading NanoBSD and TinyBSD, to see what they’re doing.

I love reading other coders’ code, because it’s always a learning experience. Poul-Henning Kamp, for example, writes very nice shell script. Very nice indeed.

As I am about to redistribute his code a little, let me include this :


# Copyright (c) 2005 Poul-Henning Kamp.
# All rights reserved.
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# $FreeBSD: src/tools/tools/nanobsd/nanobsd.sh,v 1.30 2008/01/12 22:58:06 simon Exp $


Now that that’s over with, a little code is in order:


# Name of this NanoBSD build. (Used to construct workdir names)

# Source tree directory

# Where nanobsd additional files live under the source tree

# Where cust_pkg() finds packages to install

# Object tree directory
# default is subdir of /usr/obj

# The directory to put the final images
# default is ${NANO_OBJ}


See what he did there? He’s declaring variables. Every one of them is prefixed with a comment that says “This next variable means this”. I swear, I started reading this and admired the time put in simply to make the code easier to follow.

I was a little worried, though. It looks wordy. But I got down to the code:

# The functions which do the real work.
# Can be overridden from the config file(s)

clean_build ( ) (
echo “## Clean and create object directory (${MAKEOBJDIRPREFIX})”

if rm -rf ${MAKEOBJDIRPREFIX} > /dev/null 2>&1 ; then
chflags -R noschg ${MAKEOBJDIRPREFIX}
printenv > ${MAKEOBJDIRPREFIX}/_.env
make_conf_build ( ) (
echo “## Construct build make.conf ($NANO_MAKE_CONF)”


build_world ( ) (
echo “## run buildworld”
echo “### log: ${MAKEOBJDIRPREFIX}/_.bw”

cd ${NANO_SRC}

A note which tells us “variables are over now, busters”, then straight into code.

It’s a good example of how to write a shell script. There’s enough information to get one oriented, but after that you’re on your own. And let’s face it, if you can’t work this stuff out reading it then no number of comments are going to help.

In reading it, I ran across a couple of programs I’ve never used. I figured, though, what better time to get familiar with them than by also reading their source code? So I gleefully started wandering through my source tree, discovering what there is to discover there. And as ever, I was impressed by how simple a lot of programs are.

chflags, for example, is basically two case statements.

I love usage statements. This code is covered under the same copyright as above, though I cannot see its author listed in the file. Author, please let me know who you are!

“usage: chflags [-h] [-R [-H | -L | -P]] flags file …\n”);

My favourite program in the source tree right now is hostname; I remember the first time I saw it being struck by how well the various pieces of the operating system fall together to form a cohesive whole. It features a case statement that becomes a cascading case statement. The logic of the program is tiny: In substance it reads:

if (*argv) {
if (sethostname(*argv, (int)strlen(*argv)))
err(1, “sethostname”);
} else {
if (gethostname(hostname, (int)sizeof(hostname)))
err(1, “gethostname”);
if (sflag) {
p = strchr(hostname, ‘.’);
if (p != NULL)
*p = ”;
(void)printf(“%s\n”, hostname);
I love it for several reasons. It’s simple, it taught me a lot about unix, it’s just plain awesome.

For example, sethostname? Where is that function? Well, it’s declared as: extern int sethostname(char *, int);

Where? Well, use unix to tell you! cd /usr/src && grep -R sethostname *. /usr/src/contrib/gcc/sys-protos.h

Ach, what’m I talkin’ about, anyway. I just like greppin’ code and seeing what there is to be found.

January 15, 2008

FreeBSD ports management articles

Filed under: freebsd — oscartheduck @ 3:10 pm

I found these useful over the last twelve months or so. All well worth reading, not more than about half an hour’s worth of reading there to increase your comfort with ports by an order of magnitude:






An honorary OpenBSD mention, on how (not) to use a mailing list:

November 25, 2007


Filed under: freebsd, wordpress — oscartheduck @ 4:53 pm

I’ve been wondering about the upgrade path for a wordpress installation I have on a webserver.

If I’d just left wordpress in the default location, ports would automatically upgrade it for me. I’d occasionally have issues from that, but that’s not what I did, so I don’t have issues from it. Instead, I have wordpress permanently stuck around version 2.1. Which is non-optimal.

So I’ve been thinking about how to resolve this. I imagine it’s as simple as finding the default location and cping a binary, but I’m uncertain. And if I break that website, there will be hell to pay, where hell is a hot place that’s very uncomfortable.

Aq recently wrote a post about this very conundrum: http://www.kryogenix.org/days/2007/11/23/wordpress-through-subversion  – so good for him. I’m going to try out a dual pronged approach. First, I’ll clone the mysql database/wordpress install from the website and throw it over to the vm, then see if I can update it safely by copying a port-installed binary. If so, score. If not, I’ll try the subversion approach.

July 25, 2007

On ports vs pkg_add — a digression into keeping your FreeBSD programs up to date with the latest patches and software

Filed under: freebsd, how to — oscartheduck @ 1:57 pm

Something that confused the hell out of me when I first started using FreeBSD was ports vs pkg_add. It was worth getting used to ports, I think, because these days I use nothing else.

What’s the difference?

The initial difference that struck me was speed. pkg_add installs things a lot faster than ports. Recently, I had to install TeXMacs, a program I hope dies a painful death in a pit full of wildebeest droppings somewhere, and I had to install it fast. To do that, I started building the port, installed the binary package with pkg_add and once my port was finished being made I deinstalled the pkg and installed the port. It took about ten seconds to install the pkg, and about an hour and a half to install the port.

Given that MASSIVE speed difference, why the hell would anyone use ports? The answer is that they’re magically delicious in every single way.

No, but seriously. Once you start using ports rather than pkges, I doubt you’ll ever ever ever go back to the pkg.

Yeah, but what’s the sodding difference?

Okay. A pkg is a prebuilt binary. A port is building the same binary, but doing it from source on the local machine.

So, a pkg is built in a generic kind of way. It runs on most machines. A prebuilt binary is how windows, Mac OS, most linuxes, all distribute their stuff. My linux of choice is Ubuntu. When you do an add/remove programs install, a synaptic install, or (for me) an apt-get install, you’re installing prebuilt binaries. They’re convenient, as they generally have a lot of the fiddly bits they need prepackaged with them. When a pkg just works, it’s a beautiful and fast thing.

The problem is when they don’t. That’s when ports shine.

A port is to a pkg as gold is to brass. Brass is nice, but once you sell a pound of brass and a pound of gold then you’ll never want brass again.

The best way to get familiar with ports is by using them. Do you have a ports tree? If so, and you’ve never used it, it’ll be out of date.

If not, that sucks and you should have one.

It is necessary, absolutely necessary, to have your ports tree always up to date if you’re running on ports. I discovered this in a painful way, by mixing ports and pkges.

A Brief Digression
Back when I first started running FreeBSD, I completely destroyed my system installing the simplest stuff. Eventually, nothing would install. I do mean nothing. I had no idea what was going wrong, I just knew that I was frustrated. So I stopped using FreeBSD for a long time.

When I came back to it, I had no idea what to do. Fortunately, a friend of mine is a FreeBSD guru. So I asked him. And he talked me through solving all my issues.

First, he said, update your ports tree. He left me to work out how to do it. I read things about cvsup, I read things about new tools that had just been developed, I had no idea. I stumbled through the most excellent FreeBSD diary until I discovered the solution, and I updated my ports tree.

Next, he said, you’re fortunate to have installed portupgrade a long time ago. Run this command:

portupgrade -ay

This took about three or four days to run. A long long time. Especially as I did not know what screen was back then. Ouch!

There were options screens occasionally, which I answered as best I could, and eventually it was done. And my god, the system worked! I had to know more!

Digression Digressed

First, become root. This assumes you’re root. If you don’t have a /usr/ports directory, do a:

mkdir /usr/ports

If you don’t have a /usr directory, you are in a world of pain and I pity you.

FreeBSD contains a tool that brings a ports tree up to date in a relatively painless way. This is portsnap. To update your ports tree using portsnap, run:

portsnap fetch

This takes a little time to run. Be patient, brew a cup of tea and drink it.

Now run:

portsnap extract

This takes time to run, too. Maybe five, ten minutes depending on your computer’s speed. Notice what’s being spread across your screen: why, it’s pathnames with packagenames inside!

Once it’s done, execute:

cd /usr/ports

And do an ls.

You’ll notice names of types of packages. Here’s mine right now:

.cvsignore INDEX-6.bz2 Templates audio deskutils ftp java net ports-mgmt textproc x11-fonts
.portsnap.INDEX INDEX-6.db Tools benchmarks devel games korean net-im portuguese ukrainian x11-servers
CHANGES KNOBS UIDs biology distfiles german lang net-mgmt print vietnamese x11-themes
COPYRIGHT LEGAL UPDATING cad dns graphics mail net-p2p russian www x11-toolkits
GIDs MOVED accessibility chinese editors hebrew math news science x11 x11-wm
INDEX Makefile arabic comms emulators hungarian mbone packages security x11-clocks
INDEX-5 Mk archivers converters finance irc misc palm shells x11-drivers
INDEX-6 README astro databases french japanese multimedia polish sysutils x11-fm

Lots of packages. Some indexes, a README, a file named UPDATING and so on.

Good stuff. Damn good stuff.

cd into something! How about this:

cd ports-mgmt

An ls will show a bunch of package names. They’re all tools that manage ports. This is the ports management section of the ports tree.

The first thing I always install is portupgrade.

cd portupgrade

Before going any further, do an ls. You’ll see some neat files. A pkg-descr, a Makefile, a pkg-message, a pkg-plist and distinfo. What are all of these?

Well, it took me a long time to discover, but I know these days.

The Makefile describes everything FreeBSD needs to know to make a binary of this package. It tells FreeBSD where to download the source code from, then what to do with it. It tells FreeBSD what options are available for this port, so that it builds differently, and anything else FreeBSD needs to know to build this file so it will work on your computer.

Do a less on the Makefile and give it a read. You’ll understand some stuff, not others. It’s all shell script, and you’ll eventually get very very very used to reading it if you administer a FreeBSD system.

distinfo contains information for FreeBSD to know that when you download the source code (which FreeBSD will do automatically for you at the right time) it is not corrupt. It contains an md5sum and a SHA256 sum and a size for the package. If you don’t know how these work, it’s interesting reading around and finding out what they do. For now, though, just understand that they GUARANTEE that your package will be built properly.

The pkg-descr is exactly what it almost sounds like. It’s a description of the contents of the package. For this package, the most useful thing to note iniside it is that you’re going to get several cool extra tools, like pkg_deinstall and pkgdb. My god, if I could count the number of times pkgdb has saved my ass, wow.

pkg-mesg is a neat message that’ll pop onto the screen when the port is installed, giving VERY USEFUL information about how to configure it properly. You often have to scroll the screen up a little to see its contents, so bear that in mind. The pkg-mesg for moinmoin, for example, tells you where and how your moin install is and what to do to make it work. Ports are friendly that way, they often tells you what you need to do to make your install work.

pkg-plist contains a list of packages installed by this port, so that when deinstall happens everything is deinstalled properly.

Some of these files may not exist, some different files might be there. The canonical reference is, as ever, the handbook.

So anyway, to install portupgrade from this port, type “make install clean”. You’ll see a bunch of downloading occur, a bunch of making of files, maybe a bunch that you weren’t aware you need to have installed. For example, it’s not uncommon to see ruby on rails be installed by ports managment stuff, a lot of it seems to be written in ruby, or for moinmoin you’ll see python installed because that’s the language python is written in.

The neat thing is for web related stuff. Ports are so damn smart that if you’ve got apache installed and you install moin, it’ll install mod_python for you automatically so that you’re ready to go. If you hadn’t already installed apache, you’ll have to do some manual fiddling, though.

So now you’ve got portupgrade installed, the best thing to do is decide whether you’re going for a ports based system or a pkg based system. YOU SHOULD NOT MIX. PICK ONE AND STICK WITH IT. HELL WILL HAPPEN IF YOU DON’T.

Why Hell?

pkges are built for you at specific version numbers. Ports, on the other hand, you build from the ports tree you download with portsnap. The Makefiles are often at different version numbers than the pkges. But pkg_add will clobber your currently installed ports! So you can install an old version of a package over a new version.

Remember above, I said ports download recursively, satisfying their dependencies? Well, if your version of moin is dependent on python 2.5, and the current pkg was only at 2.4, then when you pkg_add python and destroy your current version, moin will stop working!

Now, stop panicking quite so much, FreeBSD is smarter than this overly simple example. But the principle is true. Minor revisions are actually important numbers.

You will mire your entire operating system in a world of shit by mixing the two different systems.

How To Solve This Issue?

We actually just installed the tool to solve this issue, portupgrade. Run:

“portupgrade -ay”

It will discover all your installed ports OR packages, test their version number against the version in the ports tree and make sure you’re at the appropriate version. Portupgrade is discussed in the handbook, but be aware that it’s simply a completely badass tool.

There are other tools available for keeping your installed packages up to date with the latest packages and patches and so on, but these are the ones I use.

Isn’t There a Catch?

There are a couple of catches to using ports.

First, pkgdb, the database it uses to keep track of everything, occasionally notices conflicts that must be fixed. There is one command to solve this:

pkgdb -F

Last weekend, for whatever reason I had to run this four times in a row. But that’s all I had to do to solve the issue, run that command. That’s ease of use for you, as far as I’m concerned. If you try to install anything with a conflict, the install will fail telling you to run pkgdb -F.

The other is UPDATING. In /usr/ports, there’s a text file called UPDATING. This contains useful information on known security issues, problems with certain installs. Recently, FreeBSD moved to xorg 7.2, and there’s a whole list in UPDATING on how to update to 7.2 using ports. It’s a pain having to follow the steps, but that’s all you have to do. Just follow the UPDATING steps and you’ll be fine. FOLLOW ALL OF THEM.

And that’s that.

This upgrades all your installed ports to be the latest and greatest. It’s the tools that automate everything that make ports so amazing to me. That and knowing that every package is there specifically for my machine.

But I Need It In A Hurry

This was the issue with TeXMacs. I needed it fast. So, what did I do? I cded into /usr/ports/editors/texmacs && make

This started making the binary in the background.

Then I crossed my fingers, prayed, and did a pkg_add -r texmacs.

This installed hte binary which, fortunately, didn’t clash with my system. I used the binary until the port was built (ports are usually fast, incidentally, just not in the case of larger installs) and then did a:

cd /usr/ports/editors/texmacs && make deinstall && make install && make clean

So I deinstalled the pkg, which ports is smart enough to do, then installed my already built binary and cleaned up afterwards.

I’ve ran into versioning issues with pkg_add, but never with ports. And it’s never hard to keep up to date with ports. To find a port to install, simply:

cd /usr/ports

make search name=pkgname

So to locate the latest version of python:

make search name=python | less

Bunches of stuff flies past the screen, so pipe it to less so you can read at your leisure. You’ll find it.

Ports is very very comprehensive. It seems to have, for example, the entire CPAN library for Perl. It doesn’t have all the python packages I’d like, but it has a lot of them. If you find something that ports doesn’t have, consider making a port and submitting it: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ is the documentation for how to make a port.

Now that you’ve solved your package maintenance issues, in the future we’ll consider how to make your base distribution up to snuff with the current patches.

P.S I’m Security Paranoid

For those amongst us who TRUST NOTHING, consider the port portaudit port. It’s in /usr/ports/ports-mgmt — go ahead and cd into the portaudit directory and make install clean.

It will email your administrator email address with the results of a portaudit scan against the latest portaudit database every night, telling you about known security issues with anything and how to resolve those issues if any resolution is available. Damn useful! For more information, read the handbook page on portaudit.

June 2, 2007

create new NIS user account and another project

Filed under: freebsd, how to, red hat, Uncategorized — oscartheduck @ 12:55 pm

I need to write this down because I do it maybe once every eight months and it’s a struggle each time.

Okay. It’s simple.

vi /etc/passwd.nis and add the appropriate individual.

cd /etc/sp && make


I’m thinking of writing a little script to take a list of file names and grep ’em. I was thinking about calling it something like grepgle and adding a couple of optimisations:

1. when activated with a -1 flag, grepgle uses locate to discover the list of files to grep

2. when activated with a -2 flag, grepgle uses find to discover the list of file names

I’ve got to consider whether it’s worth the time to code it, though.

&title=”> Stumble it!

May 3, 2007

permission permission permission ( moin on apache 2.2 )

Filed under: apache, freebsd, moin, MoinMoin — oscartheduck @ 12:18 am

This took too long to solve. My head hurts.

Okay. In apache2.2, every new directory that you create needs to have associated with it specific permission to access that directory. I like that, actually, because it’s safer. Here’s the relevant portion from the documentation:

# Each directory to which Apache has access can be configured with respect
# to which services and features are allowed and/or disabled in that
# directory (and its subdirectories).
# First, we configure the "default" to be a very restrictive set of
# features.
<Directory />
    AllowOverride None
    Order deny,allow
    Deny from all

# Note that from this point forward you must specifically allow
# particular features to be enabled - so if something's not working as
# you might expect, make sure that you have specifically enabled it
# below.

The syntax for giving permission is relatively simple. Here’s the exact code from my httpd.conf in order to enable access to moin: Note that although the moin documentation says you should add this stuff at the end of the httpd.conf file, that’s relevant only to apache 1.X. Apache 2.2 really expects to see it in a specific place set aside for it.

# Alias: Maps web paths into filesystem paths and is used to
    # access content that does not live under the DocumentRoot.
    # Example:
    # Alias /webpath /full/filesystem/path
    # If you include a trailing / on /webpath then the server will
    # require it to be present in the URL.  You will also likely
    # need to provide a <Directory> section to allow access to
    # the filesystem path.

    <Directory "/usr/local/share/moin/">
      Allow from all
      Include etc/apache22/Includes/*.conf

    Alias /wiki/ "/usr/local/share/moin/htdocs/"

    <Directory "/usr/local/www/wiki/">
      Allow from all
      Include etc/apache22/Includes/*.conf
    # ScriptAlias: This controls which directories contain server scripts.
    # ScriptAliases are essentially the same as Aliases, except that
    # documents in the target directory are treated as applications and
    # run by the server when requested rather than as documents sent to the
    # client.  The same rules about trailing "/" apply to ScriptAlias
    # directives as to Alias.
    ScriptAlias /cgi-bin/ "/usr/local/www/apache22/cgi-bin/"

    ScriptAlias /mywiki "/usr/local/www/wiki/moin.cgi"

Note that although the moin documentation says you should add this stuff at the end of the httpd.conf file, that’s relevant only to apache 1.X. Apache 2.2 really expects to see it in a specific place set aside for it. Note that my paths are all for FreeBSD, which has a very very simple moin install. You install apache, python, mod python and so on. Then cd /usr/ports/www/moinmoin && make install clean && make instance

That’s it. You now have a wiki instance in /usr/local/www/wiki. Love that OS.

Older Posts »

Blog at WordPress.com.