PaulHowarth/Blog/2008-05

Paul's Blog Entries for May 2008

Saturday 3rd May 2008

Allotment

Planted my main crop potatoes, Cara in the section nearest the path and Desiree in the next section down.

Monday 5th May 2008

Local Packages

  • Updated sendmail to 8.14.3

Tuesday 6th May 2008

Local Packages

  • Updated nmap to 4.62

Wednesday 7th May 2008

Local Packages

  • Updated curl to include the API documentation in the libcurl-devel package as per Fedora, and to use a different method to fix the bogus RPATHs on x86_64 (hacking the upstream-supplied libtool rather than using the distribution one), which removes the build requirement of libtool.

Fedora Project

  • Somebody else closed the curl merge review so I sent in a patch to merge the last few differences between the Rawhide version and mine (other than the cruft I carry to support building on older distributions and eventually building compat- packages), i.e.:

    • Don't need -D_GNU_SOURCE for visibility of NI_MAXHOST anymore

    • Don't need buildreq of libtool

    • CHANGES and README files needed converting to UTF-8

    • Fix RPATH in x86_64 package

Friday 9th May 2008

Local Packages

  • Updated libpng10 to 1.0.37; this finally resolved the autotools issues that have affected libpng for the last few releases - I helped to test this one prior to release

Fedora Project

  • Updated libpng10 to 1.0.37 in Rawhide, built the same packages for testing in Fedora 7, 8, and 9

Monday 12th May 2008

Fedora Project

Whilst setting up my infrastructure to handle Fedora 9, I came across my first F9-specific bug, whereby createrepo failed with the -C option. The fix came quickly enough but I'm not convinced about the merits of closing Fedora bugs as UPSTREAM (as happened here) since the bug is still an issue for Fedora users until such time as the upstream fix makes it into Fedora.

Tuesday 13th May 2008

Local Packages

  • Updated perl-Jcode to 2.07

  • Updated ppp to merge the new speeds patch as found in Rawhide (Bug #446132)

Wednesday 14th May 2008

Fedora 9

I got a shiny new PC at work this week so of course Fedora 9 had to be the OS. I'm up and running now after overcoming a few quirks.

Network

Fedora 9 uses NetworkManager by default rather than the traditional network initscript. A consequence of this is that the network comes up later in the boot sequence and the hostname stays as localhost.localdomain unless you tell it to use something else. I did this by using system-config-network and setting the hostname on the DNS tab.

However, this is not sufficient to support a usable workstation on the LAN (i.e. one that uses network-based authentication and home directories), so it's back to the old style for this release at least:

# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

32-bit Application Support on x86_64

For one reason or another, it's necessary to run some 32-bit applications on a 64-bit OS. In Fedora 9, the default multilib policy is to install only 64-bit packages by default and pull in 32-bit packages only when explicitly required. This differs from previous Fedora releases where both 32- and 64-bit versions of packages were installed by default when available (this mostly covers libraries and a few key applications like wine).

A consequence of this change is that some 32-bit applications may fail in strange ways due to missing 32-bit support libraries, particularly where the dependencies aren't obvious (e.g. with VMware, which has no explicit dependencies at all), or with pam, where the dependencies depend on system configuration.

Since my company uses LDAP authentication, a lot of pain can be saved by installing the 32-bit nss_ldap package if there is any intention of running 32-bit software like VMware or Sun's Java Web Start:

# yum install nss_ldap.i386

Without this, attempting to start vmware resulted in this:

$ vmware
Cannot get temporary directory for log file.


VMware Server Error:
VMware Server unrecoverable error: (vmui)
Cannot get temporary directory for log file.
Please request support.  
To collect files to submit to VMware support, run vm-support.
We will respond on the basis of your support entitlement.


Press "Enter" to continue...

I'd expect that most people using 32-bit software would at least need pam.i386.

VMware Server

# rpm -Uvh VMware-server-1.0.5-80187.i386.rpm

Before configuring VMware, it's necessary to install a few additional packages, patch the kernel modules, and make an SELinux tweak. VMware defaults to using a reserved port (902) for the server; it's easier to make it play nice with SELinux by using an unreserved port such as 4800.

# yum install gcc-c++ kernel-devel xinetd 'perl(ExtUtils::MakeMaker)' 'perl(ExtUtils::Embed)' libXt.so.6 libXtst.so.6 libXrender.so.1 libz.so.1 libgdk-x11-2.0.so.0
# cd
# semanage port -a -t inetd_child_port_t -p tcp 4800
# wget http://download.rsbac.org/tmp/vmware-any-any-update117.tar.gz
# tar xf vmware-any-any-update117.tar.gz
# cd vmware-any-any-update117
# ./runme.pl
# restorecon -v /etc/services

{i} I found the vmware-any-any-update117.tar.gz reference at http://sidux.com/PNphpBB2-printview-t-8493-start-0.html

/!\ I found that I had to remove the computer account for my virtual machine on the domain and re-add it before I could log in using domain credentials. I suspect that this was a result of moving the virtual machine from my old machine to the new one but I'm not sure about that.

{i} Although VMware supply many of the GUI libraries needed for the console, there's a compatibility issue with Fedora 9. If the Fedora versions of libgdk-x11-2.0.so.0 and its dependencies aren't installed, attempting to start vmware results in this:

$ vmware
/usr/share/themes/Nodoka/gtk-2.0/gtkrc:37: error: unexpected character `(', expected character `}'
Locking assertion failure.  Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x3a7767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0x3a7831]
#2 /usr/lib/libX11.so.6(_XReply+0x244) [0x2e8f64]
#3 /usr/lib/vmware/lib/libXrender.so.1/libXrender.so.1(XRenderQueryFormats+0x109) [0x1d9969]
#4 /usr/lib/vmware/lib/libXrender.so.1/libXrender.so.1(XRenderFindFormat+0x4c) [0x1d9f4c]
#5 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0 [0x538180]
#6 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0 [0x538d2c]
#7 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0(gdk_draw_pixbuf+0x270) [0x508c14]
#8 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0 [0x51524f]
#9 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0(gdk_draw_pixbuf+0x270) [0x508c14]
#10 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0(gdk_pixbuf_render_pixmap_and_mask_for_colormap+0x255) [0x514b34]
#11 /usr/lib/vmware/lib/libgtk-x11-2.0.so.0/libgtk-x11-2.0.so.0 [0xaca298]
#12 /usr/lib/vmware/lib/libgtk-x11-2.0.so.0/libgtk-x11-2.0.so.0 [0xaca586]
#13 /usr/lib/vmware/lib/libgtk-x11-2.0.so.0/libgtk-x11-2.0.so.0 [0xacc77e]
#14 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0xd1) [0x218459]
#15 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0 [0x2003a1]
#16 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0(g_closure_invoke+0x1b1) [0x200076]
#17 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0 [0x2176eb]
#18 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0(g_signal_emit_valist+0x91e) [0x216d46]
#19 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0(g_signal_emit+0x38) [0x2170b8]
Locking assertion failure.  Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x3a7767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x2e) [0x3a790e]
#2 /usr/lib/libX11.so.6 [0x2e8109]
#3 /usr/lib/libX11.so.6(XAddExtension+0x2c) [0x2ca23c]
#4 /usr/lib/vmware/lib/libXft.so.2/libXft.so.2(_XftDisplayInfoGet+0x77) [0x1eaed7]
#5 /usr/lib/vmware/lib/libXft.so.2/libXft.so.2 [0x1e98b1]
#6 /usr/lib/vmware/lib/libXft.so.2/libXft.so.2 [0x1e9d39]
#7 /usr/lib/vmware/lib/libXft.so.2/libXft.so.2(XftDrawPicture+0x10) [0x1e9ec0]
#8 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0 [0x5369b6]
#9 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0 [0x538d75]
#10 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0(gdk_draw_pixbuf+0x270) [0x508c14]
#11 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0 [0x51524f]
#12 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0(gdk_draw_pixbuf+0x270) [0x508c14]
#13 /usr/lib/vmware/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0(gdk_pixbuf_render_pixmap_and_mask_for_colormap+0x255) [0x514b34]
#14 /usr/lib/vmware/lib/libgtk-x11-2.0.so.0/libgtk-x11-2.0.so.0 [0xaca298]
#15 /usr/lib/vmware/lib/libgtk-x11-2.0.so.0/libgtk-x11-2.0.so.0 [0xaca586]
#16 /usr/lib/vmware/lib/libgtk-x11-2.0.so.0/libgtk-x11-2.0.so.0 [0xacc77e]
#17 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0xd1) [0x218459]
#18 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0 [0x2003a1]
#19 /usr/lib/vmware/lib/libgobject-2.0.so.0/libgobject-2.0.so.0(g_closure_invoke+0x1b1) [0x200076]
vmware: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy->request)) >= 0)' failed.

{i} Update: Since writing this, VMware-server version 1.0.6 has been released, which does not require the any-any-update to build the kernel modules in Fedora 9.

Fedora Project

  • Updated pptp to 1.7.2 in Rawhide; the newly-added Solaris compatibility in this version requires stropts.h, which isn't shipped in Fedora 9 onwards, though it was harmless to simply patch that out

Local Packages

  • Updated pptp to 1.7.2, with extra patch added to support building on Red Hat Linux 7 and 8.

PPTP Project

  • Updated pptp.spec in CVS for the new release, built the 1.7.2 packages for all supported distribution releases, and updated the repositories to support Fedora 9

Thursday 15th May 2008

Local Packages

  • Updated gtkwave to 3.1.10

Fedora Project

  • Updated gtkwave to 3.1.10 in Rawhide (i.e. for Fedora 10)

Friday 16th May 2008

SHAS Website

Earlier this week I finally managed to get the Sale Horticultural & Allotment Society website migrated over to my own machine from Freeola. I'd been trying on and off to get this done for the best part of two years, the hold-ups being due to the fact that the domain was registered long before I joined the society and the contact details hadn't been kept up to date, so it was difficult to actually do anything with the domain.

Now that the website is served from my own machine, I can use Apache features like XbitHack when doing server-side includes instead of having to rename pages to .shtml as I had to do when using Freeola's hosting. Of course, since the site has been there for a long time, the search engines all have links to the .shtml pages that no longer exist, so I needed a quick hack to provide the correct content when people followed those links. All that was necessary was a RedirectMatch directive in the site's VirtualHost container:

    # Search engines have cached .shtml links
    RedirectMatch       seeother (/.*)\.shtml$ $1.html

Monday 19th May 2008

Local Packages

Over the weekend I updated my build system to Fedora 9. This was one of the most painless updates I can recall having made, and everything worked from the buildsys perspective except for mock builds for Red Hat Linux 8 and Fedora 1 targets.

For Red Hat Linux 8, I got this somewhat unexpected error message:

ERROR: Command failed: 
 # /usr/bin/yum --installroot /var/lib/mock/pptps-redhat-8-i386/root/  install buildsys-build
glibc-common-2.3.2-4.80.8.i386 from updates-released has depsolving problems
  --> glibc-common conflicts with glibc
glibc-2.2.93-5.i386 from core has depsolving problems
  --> Missing Dependency: glibc-common = 2.2.93-5 is needed by package glibc-2.2.93-5.i386 (core)
glibc-debug-2.2.93-5.i686 from core has depsolving problems
  --> Missing Dependency: glibc-devel = 2.2.93-5 is needed by package glibc-debug-2.2.93-5.i686 (core)
Error: Missing Dependency: glibc-devel = 2.2.93-5 is needed by package glibc-debug-2.2.93-5.i686 (core)
Error: Missing Dependency: glibc-common = 2.2.93-5 is needed by package glibc-2.2.93-5.i386 (core)
Error: glibc-common conflicts with glibc

By pure guesswork I tried adding to the yum.conf for the configuration:

exclude=glibc.i386

and that did the trick.

For Fedora 1, all builds failed at the point where the first command run in the chroot (groupadd as it happens), though the root.log indicated that glibc's post-install scriptlet was the first problem:

...
DEBUG util.py:250:  Transaction Summary
DEBUG util.py:250:  =============================================================================
DEBUG util.py:250:  Install     86 Package(s)
DEBUG util.py:250:  Update       0 Package(s)
DEBUG util.py:250:  Remove       0 Package(s)
DEBUG util.py:250:  Total download size: 77 M
DEBUG util.py:250:  error: %post(glibc-2.3.2-101.4.2.legacy.i686) scriptlet failed, exit status 115
DEBUG util.py:250:  error: %post(bash-2.05b-34.i386) scriptlet failed, signal 11
DEBUG util.py:250:  error: %post(info-4.5-2.i386) scriptlet failed, signal 11
DEBUG util.py:250:  error: %post(sed-4.0.8-2.i386) scriptlet failed, signal 11
DEBUG util.py:250:  error: %post(grep-2.5.1-17.4.i386) scriptlet failed, signal 11
...

This was another manifestation of Bug #121351, which until now had only affected 32-bit host systems as far as mock was concerned. I suspect that the merge of the x86 and x86_64 trees in recent kernels is the reason why this has just cropped up, and the workaround is similar to that for 32-bit hosts. To fix it for the running kernel:

# sysctl -w abi.vsyscall32=0

For subsequent boots, add to /etc/sysctl.conf:

# FC1 glibc bug workaround (#121351)
abi.vsyscall32 = 0
  • Updated dovecot-sieve to 1.0.3

  • Updated perl-Unix-Syslog to 1.1

  • Updated pptp to do routing via /sbin/ip rather than /bin/ip; upstream is debian-based, and the location of the ip utility differs from Red Hat-based distributions

  • Updated python-twisted to 8.1.0

  • Updated python-twisted-conch to 8.1.0

  • Updated python-twisted-core to 8.1.0

  • Updated python-twisted-lore to 8.1.0

  • Updated python-twisted-mail to 8.1.0

  • Updated python-twisted-names to 8.1.0

  • Updated python-twisted-news to 8.1.0

  • Updated python-twisted-web to 8.1.0

  • Updated python-twisted-words to 8.1.0

Fedora Project

  • Updated pptp in Rawhide as per the local package

  • Raised Bug #447317 on smolt, which has problems with some mount table entries that have spaces in their pathnames, leading to tracebacks like this:

    # smoltGui 
    Traceback (most recent call last):
      File "/usr/bin/smoltGui", line 261, in <module>
        app = SmoltGui(sys.argv)
      File "/usr/bin/smoltGui", line 72, in __init__
        self.profile = smolt.Hardware()
      File "/usr/share/smolt/client/smolt.py", line 351, in __init__
        self.fss = get_file_systems()
      File "/usr/share/smolt/client/smolt.py", line 264, in get_file_systems
        file_systems = get_fslist()
      File "/usr/share/smolt/client/fs_util.py", line 100, in get_fslist
        return [FileSystem(mnt) for mnt in get_mtab()]
      File "/usr/share/smolt/client/fs_util.py", line 91, in get_mtab
        mtab_map = __cache_mtab__(mtab)
      File "/usr/share/smolt/client/fs_util.py", line 107, in __cache_mtab__
        mtab = [MntEntObj(line) for line in f.read().split('\n') if len(line) > 0]
      File "/usr/share/smolt/client/fs_util.py", line 41, in __init__
        self.mnt_freq, self.mnt_passno) = input.split()
    ValueError: too many values to unpack

PPTP Client Project

  • Updated pptp as per the local package

Tuesday 20th May 2008

Fedora Project

According to Bug #447247, spamass-milter won't start in Fedora 9. So I tested it and it was true! :-(

The dæmon started but died straight away. There was no obvious reason for it, but by following the hit the bug reporter gave that it might be something to do with writing the PID file, I guessed it might be an SELinux issue. This was confirmed when I did a setenforce 0 to go into permissive mode and found that the service started without problems. There were no AVCs so whatever the problem was must have been dontaudit-ed in policy. So I turned off the dontaudit rules and tried restarting the service:

# semodule -DB
# service spamass-milter restart

This revealed the following issues:

type=AVC msg=audit(1211213302.497:1653): avc:  denied  { unlink } for  pid=27301 comm="spamass-milter" name="spamass-milter.pid" dev=dm-2 ino=254033 scontext=unconfined_u:system_r:spamd_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
type=AVC msg=audit(1211282537.032:1800): avc:  denied  { write } for  pid=6975 comm="spamass-milter" name="spamass-milter.pid" dev=dm-2 ino=254033 scontext=unconfined_u:system_r:spamd_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file

The first of these isn't a problem; the DAC permissions for the /var/run directory also prevent the dæmon (running as user sa-milt) from deleting the PID file. The problem is the second denial, where the dæmon (running in context spamd_t) is prevented from writing the PID to the PID file (which is initrc_var_run_t since it was created by the initscript). This represents a change in policy since Fedora 8, where spamd_t was allowed to do this write.

The solution was to change the context of the PID file to spamd_var_run_t so that the dæmon would be allowed to write to it. Hard coding the context type into the initscript is a no-no as it would make the initscript policy-specific. So the fix actually took two parts:

  1. Fixing policy to make the default context for /var/run/spamass-milter.pid one that is writeable by the spamass-milter dæmon (i.e. spamd_var_run_t in current policy). This was done in selinux-policy-3.3.1-55.fc9.

  2. Fixing the initscript to restore the default context for the PID file before starting the dæmon:
  3. --- /etc/rc.d/init.d/spamass-milter.orig        2008-05-20 12:48:02.000000000 +0100
    +++ /etc/rc.d/init.d/spamass-milter     2008-05-20 12:38:24.000000000 +0100
    @@ -44,6 +44,7 @@
            echo -n $"Starting ${desc} (${prog}): "
            touch ${pidfile}
            chown sa-milt:sa-milt ${pidfile}
    +       [ -x /sbin/restorecon ] && /sbin/restorecon ${pidfile}
            daemon --user sa-milt /usr/sbin/${prog}-wrapper -p ${SOCKET} -P ${pidfile} ${EXTRA_FLAGS}
            RETVAL=$?
            echo
  4. This fix was incorporated into spamass-milter-0.3.1-8.fc9

With that I was able to turn back off the dontaudit rules, go back into enforcing mode and successfully restart the service:

# semodule -B
# setenforce 1
# service spamass-milter restart

Wednesday 21st May 2008

Fedora Project

Having a few spare minutes on my hands, I decided to fix some of the compiler warnings generated during the build of the old libxml package, particularly the implicit function declaration ones, which may result in the benefits of FORTIFY_SOURCE being lost. There is talk of adding -Werror-implicit-function-declaration to the default compiler flags at some point, at which point this sort of fix will become necessary rather than just desirable.

Having created the necessary patch and done local mock builds for Rawhide (i386 and x86_64), I committed the changes into CVS and requested a build. To my surprise, the build on the ppc64 architecture failed. Suspecting some subtle problem with my patch, I tried a scratch build of the un-patched package and that failed in the same way:

gcc -shared  SAX.lo entities.lo encoding.lo error.lo parser.lo parserold.lo HTMLparser.lo HTMLtree.lo debugXML.lo tree.lo xpath.lo xmlIO.lo xmlmemory.lo nanohttp.lo nanoftp.lo valid.lo xlink.lo uri.lo -Wl,-soname -Wl, -o .libs/
/usr/bin/ld: cannot open output file .libs/
: Is a directory
collect2: ld returned 1 exit status

Comparing the build logs with the successful ppc build showed that libtool was a problem since it didn't recognize the host type:

checking host system type... Invalid configuration `ppc64-redhat-linux-gnu': machine `ppc64-redhat' not recognized
checking build system type... Invalid configuration `ppc64-redhat-linux-gnu': machine `ppc64-redhat' not recognized
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
... (snip) ...
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... no
checking if libtool supports shared libraries... no

A thread on fedora-devel-list revealed that this problem was caused by a recent change in the redhat-rpm-config package in Rawhide to address Bug #211069, whereby the traditional behaviour of the %configure macro of overwriting a package's own config.sub and config.guess scripts with the ones from redhat-rpm-config was ceased since it caused issues for cross-compilation. So now libxml was being built with its own versions of config.sub and config.guess, which date back to early 2002 and have never heard of the ppc64 architecture.

The fix wasn't difficult really:

--- libxml-1.8.17/config.guess  2002-01-23 22:49:14.000000000 +0000
+++ libxml-1.8.17/config.guess  2008-05-21 10:53:14.000000000 +0100
@@ -811,6 +811,9 @@
        rm -f $dummy.c $dummy
        echo powerpc-unknown-linux-gnu${LIBC}
        exit 0 ;;
+    ppc64:Linux:*:*)
+       echo powerpc64-unknown-linux-gnu
+       exit ;;
     alpha:Linux:*:*)
        cat <<EOF >$dummy.s
          .data
--- libxml-1.8.17/config.sub    2002-01-23 22:49:14.000000000 +0000
+++ libxml-1.8.17/config.sub    2008-05-21 11:25:57.000000000 +0100
@@ -721,6 +721,10 @@
                ;;
        ppc-*)  basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'`
                ;;
+       ppc64)  basic_machine=powerpc64-unknown
+               ;;
+       ppc64-*) basic_machine=powerpc64-`echo $basic_machine | sed 's/^[^-]*-//'`
+               ;;
        ppcle | powerpclittle | ppc-le | powerpc-little)
                basic_machine=powerpcle-unknown
                ;;

And with that patch, libxml built happily in Rawhide once again. It's possible I'll have to revisit this at some point to cater for secondary architectures like sparc and ia64; we'll see.

Thursday 22nd May 2008

Fedora Project

Today I started to look at the bugs that have been amassing for smbldap-tools. I thought I'd start with an easy one like Bug #441833, where the tools assume that the user is using an ISO-8859-1 based locale, but Fedora defaults to UTF-8 everywhere so this results in bogus conversions to UTF-8 and back again.

However, when I tried on test my first effort at a patch for this on my local Fedora 9 box, I got this result:

# smbldap-userlist 
Can't locate Unicode/MapUTF8.pm in @INC (@INC contains: /usr/sbin/ /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at /usr/lib/perl5/vendor_perl/5.10.0/smbldap_tools.pm line 28, <DATA> line 228.
BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.10.0/smbldap_tools.pm line 28, <DATA> line 228.
Compilation failed in require at /usr/sbin/smbldap-userlist line 30, <DATA> line 228.
BEGIN failed--compilation aborted at /usr/sbin/smbldap-userlist line 30, <DATA> line 228.

It turned out that the perl-Unicode-MapUTF8 package hadn't been rebuilt for perl 5.10 in the Fedora 9 development cycle. There had been a mass rebuild of perl packages but somehow this one had slipped through the cracks. As I'm a co-maintainer for this package in EPEL, I checked in some changes to tidy up the spec and verified that the resulting package fixed the problem. I also raised Bug #447921 to track the issue and alert AurelienBompard, the package's maintainer, to tag and build the update.

Local Packages

  • Merged some spec file updates from Rawhide into dovecot, particularly regarding the scriptlets

Friday 23rd May 2008

Fedora Project

Had a crack at Bug #447758, which again looked like an easy fix. It was a race condition in the setting of the ownership of a home directory created by smbldap-useradd, whereby a call to chown could be made and that program try to look up the UID of a newly-added username before the necessary data had replicated to the LDAP slave it was trying to obtain that information from. My fix for that was to use the UID rather than the username when calling chown. I've updated smbldap-tools on Rawhide to include an update to 0.9.5, this fix, and yesterday's fix for Bug #441833.

After doing that build, I then turned my attention to Bug #430105, which looked as though it might require a little more thought. I looked at the suggested patch for the issue and then looked at the current code to get a feel for what was going on. Much to my surprise I found that it looked as though the patch had already been applied upstream (the bug report was for the previous upstream release - 0.9.4 - which is the version present in Fedora 8 and 9). Looking through the changelog, I found that there was a similar bug report in the upstream tracker from a different reporter. So that's going to be an easy fix too :-)

Local Packages

  • Updated smbldap-tools as per Fedora

Sunday 25th May 2008

Local Packages

  • Updated perl-Test-File to 1.24; the test suite is broken but this is fixed in the current development version (1.24_02) so I applied patches from there

Tuesday 27th May 2008

Shrinking Disk?

After installing Fedora 9 onto my firewall/Internet server box using the existing partitioning/RAID/LVM layout, I found the kernel complaining that one of my disk partitions extended past the end of the drive, something that was never an issue on Fedora 8.

May 26 15:20:27 goalkeeper kernel: scsi 0:0:1:0: Direct-Access     ATA      WDC WD800BB-75CA 16.0 PQ: 0 ANSI: 5
May 26 15:20:27 goalkeeper kernel: sd 0:0:1:0: [sdb] 156250000 512-byte hardware sectors (80000 MB)
May 26 15:20:27 goalkeeper kernel: sd 0:0:1:0: [sdb] Write Protect is off
May 26 15:20:27 goalkeeper kernel: sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
May 26 15:20:27 goalkeeper kernel: sd 0:0:1:0: [sdb] 156250000 512-byte hardware sectors (80000 MB)
May 26 15:20:27 goalkeeper kernel: sd 0:0:1:0: [sdb] Write Protect is off
May 26 15:20:27 goalkeeper kernel: sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
May 26 15:20:27 goalkeeper kernel:  sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 >
May 26 15:20:27 goalkeeper kernel:  sdb: p6 exceeds device capacity
May 26 15:20:27 goalkeeper kernel: sd 0:0:1:0: [sdb] Attached SCSI disk
May 26 15:20:27 goalkeeper kernel: attempt to access beyond end of device
May 26 15:20:27 goalkeeper kernel: sdb: rw=0, want=156296145, limit=156250000
May 26 15:20:27 goalkeeper kernel: Buffer I/O error on device sdb6, logical block 4608608
May 26 15:20:27 goalkeeper kernel: attempt to access beyond end of device
May 26 15:20:27 goalkeeper kernel: sdb: rw=0, want=156296145, limit=156250000

I wonder whether it was always past the end of the disk and Fedora 8 just didn't care (and it wasn't an issue because I wasn't using all of the space in the affected volume group), or whether the kernel's view of the number of cylinders on the disk changed in Fedora 9.

Anyway, after booting Fedora 9, this is what I had:

# fdisk -l /dev/sdb

Disk /dev/sdb: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x9dc96e9e

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          19      152586   fd  Linux raid autodetect
/dev/sdb2              20          38      152617+  fd  Linux raid autodetect
/dev/sdb3              39        5392    43006005   fd  Linux raid autodetect
/dev/sdb4            5393        9729    34836952+   5  Extended
/dev/sdb5            5393        7434    16402333+  fd  Linux raid autodetect
/dev/sdb6            7435        9729    18434556   fd  Linux raid autodetect

So the extended partition /dev/sdb4 and the logical partition /dev/sdb6 both extended past the end of the drive by 3 cylinders. Now fortunately I'm in the habit of building everything on top of RAID1 these days, so the machine was still running happily with a degraded array, having removed /dev/sdb6 as faulty.

Moreover, since I run LVM on top of my RAID1, and the volume group was not fully utilized, I was able to "fix" this issue with minimal disruption and no data loss...

The first step was to shrink the offending partitions down by 3 cylinders so that they fit on the disk. This would destroy the content of /dev/sdb6 but that was OK as it had already been automatically failed out of the RAID array and wasn't in use. I removed the oversized extended partition /dev/sdb4 and that took out the logical partitions /dev/sdb5 and /dev/sdb6 too:

# fdisk /dev/sdb

The number of cylinders for this disk is set to 9726.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sdb: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x9dc96e9e

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          19      152586   fd  Linux raid autodetect
/dev/sdb2              20          38      152617+  fd  Linux raid autodetect
/dev/sdb3              39        5392    43006005   fd  Linux raid autodetect
/dev/sdb4            5393        9729    34836952+   5  Extended
/dev/sdb5            5393        7434    16402333+  fd  Linux raid autodetect
/dev/sdb6            7435        9729    18434556   fd  Linux raid autodetect

Command (m for help): d
Partition number (1-6): 4

Command (m for help): p

Disk /dev/sdb: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x9dc96e9e

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          19      152586   fd  Linux raid autodetect
/dev/sdb2              20          38      152617+  fd  Linux raid autodetect
/dev/sdb3              39        5392    43006005   fd  Linux raid autodetect

I then added a new extended partition /dev/sdb4 of the correct size, restored /dev/sdb5 in exactly the same position as the old one, and a slightly smaller /dev/sdb6 that now fit the remaining space:

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
e
Selected partition 4
First cylinder (5393-9726, default 5393): 
Using default value 5393
Last cylinder or +size or +sizeM or +sizeK (5393-9726, default 9726): 
Using default value 9726

Command (m for help): n
First cylinder (5393-9726, default 5393): 
Using default value 5393
Last cylinder or +size or +sizeM or +sizeK (5393-9726, default 9726): 7434

Command (m for help): n
First cylinder (7435-9726, default 7435): 
Using default value 7435
Last cylinder or +size or +sizeM or +sizeK (7435-9726, default 9726): 
Using default value 9726

Command (m for help): p

Disk /dev/sdb: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x9dc96e9e

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          19      152586   fd  Linux raid autodetect
/dev/sdb2              20          38      152617+  fd  Linux raid autodetect
/dev/sdb3              39        5392    43006005   fd  Linux raid autodetect
/dev/sdb4            5393        9726    34812855    5  Extended
/dev/sdb5            5393        7434    16402333+  83  Linux
/dev/sdb6            7435        9726    18410458+  83  Linux

Command (m for help): t
Partition number (1-6): 5
Hex code (type L to list codes): fd
Changed system type of partition 5 to fd (Linux raid autodetect)

Command (m for help): t
Partition number (1-6): 6
Hex code (type L to list codes): fd
Changed system type of partition 6 to fd (Linux raid autodetect)

Command (m for help): p

Disk /dev/sdb: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x9dc96e9e

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          19      152586   fd  Linux raid autodetect
/dev/sdb2              20          38      152617+  fd  Linux raid autodetect
/dev/sdb3              39        5392    43006005   fd  Linux raid autodetect
/dev/sdb4            5393        9726    34812855    5  Extended
/dev/sdb5            5393        7434    16402333+  fd  Linux raid autodetect
/dev/sdb6            7435        9726    18410458+  fd  Linux raid autodetect

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

Before I could do any work with the smaller new /dev/sdb6 partition, I needed to reboot so that the kernel would see the updated partition table.

# reboot

Broadcast message from root@goalkeeper.city-fan.org
        (/dev/pts/0) at 12:09 ...

The system is going down for reboot NOW!

The next step was to create a new RAID1 array to replace /dev/md2 that /dev/sdb6 had been part of. The new one would be three cylinders smaller of course. I would eventually add /dev/sda6 (the other half of /dev/md2) to the new array, but /dev/md2 (and hence /dev/sda6) was still in use as part of LVM volume group vgOSa, so I created the the new array /dev/md6 with /dev/sdb6 and a missing mirror to be added later:

# mdadm --create --level=1 --raid-devices=2 --auto=md /dev/md6 /dev/sdb6 missing
mdadm: array /dev/md6 started.
[root@goalkeeper ~]# mdadm --detail /dev/md6
/dev/md6:
        Version : 00.90.03
  Creation Time : Tue May 27 12:14:58 2008
     Raid Level : raid1
     Array Size : 18410368 (17.56 GiB 18.85 GB)
  Used Dev Size : 18410368 (17.56 GiB 18.85 GB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 6
    Persistence : Superblock is persistent

    Update Time : Tue May 27 12:14:58 2008
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           UUID : bf013ddf:1da1e663:2bb59604:4d695037
         Events : 0.1

    Number   Major   Minor   RaidDevice State
       0       8       22        0      active sync   /dev/sdb6
       1       0        0        1      removed

I could now create an LVM physical volume on the new array. However, pvcreate was concerned that I was overwriting an existing physical volume, which of course I was:

# pvcreate /dev/md6
  Found duplicate PV biKO5Kz1nDpu1nBuT3Pc3vZsXvKWgRTO: using /dev/md2 not /dev/md6
  Can't initialize physical volume "/dev/md6" of volume group "vgOSa" without -ff

So I blew away the metadata by filling the first megabyte of the array with zeroes and tried again:

# dd if=/dev/zero of=/dev/md6 bs=1024 count=1024
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 0.176955 s, 5.9 MB/s
# pvcreate /dev/md6
  Physical volume "/dev/md6" successfully created

I could now add the new array to the volume group that the existing /dev/md2 belonged to, vgOSa:

# vgextend vgOSa /dev/md6
  Volume group "vgOSa" successfully extended
# vgdisplay -v vgOSa
  --- Volume group ---
  VG Name               vgOSa
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  8
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                6
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               35.09 GB
  PE Size               32.00 MB
  Total PE              1123
  Alloc PE / Size       484 / 15.12 GB
  Free  PE / Size       639 / 19.97 GB
  VG UUID               h029AZ-TRm5-gS2F-iq1l-MSxC-5eko-Vu6J6G
   
...
   
  --- Physical volumes ---
  PV Name               /dev/md2     
  PV UUID               biKO5K-z1nD-pu1n-BuT3-Pc3v-ZsXv-KWgRTO
  PV Status             allocatable
  Total PE / Free PE    562 / 78
   
  PV Name               /dev/md6     
  PV UUID               yyQPHZ-xM8o-qbgM-kv5U-6G1M-0oMZ-Le9L8P
  PV Status             allocatable
  Total PE / Free PE    561 / 561

The next step was to move all of the data off the old array /dev/md2 and onto the new one /dev/md6. This is easily done with the system fully live using pvmove:

# pvmove /dev/md2 /dev/md6
# vgdisplay -v vgOSa
    Using volume group(s) on command line
    Finding volume group "vgOSa"
  --- Volume group ---
  VG Name               vgOSa
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  16
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                6
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               35.09 GB
  PE Size               32.00 MB
  Total PE              1123
  Alloc PE / Size       484 / 15.12 GB
  Free  PE / Size       639 / 19.97 GB
  VG UUID               h029AZ-TRm5-gS2F-iq1l-MSxC-5eko-Vu6J6G
   
...
   
  --- Physical volumes ---
  PV Name               /dev/md2     
  PV UUID               biKO5K-z1nD-pu1n-BuT3-Pc3v-ZsXv-KWgRTO
  PV Status             allocatable
  Total PE / Free PE    562 / 562
   
  PV Name               /dev/md6     
  PV UUID               yyQPHZ-xM8o-qbgM-kv5U-6G1M-0oMZ-Le9L8P
  PV Status             allocatable
  Total PE / Free PE    561 / 77

With no data left on /dev/md2, I could now remove it from the volume group, the volume group now being fully migrated onto the new array:

# vgreduce vgOSa /dev/md2
  Removed "/dev/md2" from volume group "vgOSa"
# vgdisplay -v vgOSa
    Using volume group(s) on command line
    Finding volume group "vgOSa"
  --- Volume group ---
  VG Name               vgOSa
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  17
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                6
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               17.53 GB
  PE Size               32.00 MB
  Total PE              561
  Alloc PE / Size       484 / 15.12 GB
  Free  PE / Size       77 / 2.41 GB
  VG UUID               h029AZ-TRm5-gS2F-iq1l-MSxC-5eko-Vu6J6G
   
...
   
  --- Physical volumes ---
  PV Name               /dev/md6     
  PV UUID               yyQPHZ-xM8o-qbgM-kv5U-6G1M-0oMZ-Le9L8P
  PV Status             allocatable
  Total PE / Free PE    561 / 77

The old array /dev/md2 was no longer in use and could be stopped:

# mdadm --stop /dev/md2
mdadm: stopped /dev/md2
# mdadm --detail /dev/md2
mdadm: md device /dev/md2 does not appear to be active.

I could now add the /dev/sda6 partition into the new array /dev/md6 since it was no longer in use by /dev/md2. It didn't matter that the partition size was slightly larger than the array size; the extra space just doesn't get used.

# fdisk -l /dev/sda

Disk /dev/sda: 82.3 GB, 82348277760 bytes
255 heads, 63 sectors/track, 10011 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0007b59d

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          19      152586   fd  Linux raid autodetect
/dev/sda2              20          38      152617+  fd  Linux raid autodetect
/dev/sda3              39        5392    43006005   fd  Linux raid autodetect
/dev/sda4            5393       10011    37102117+   5  Extended
/dev/sda5            5393        7687    18434556   fd  Linux raid autodetect
/dev/sda6            7688        9982    18434556   fd  Linux raid autodetect
# fdisk -l /dev/sdb

Disk /dev/sdb: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x9dc96e9e

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          19      152586   fd  Linux raid autodetect
/dev/sdb2              20          38      152617+  fd  Linux raid autodetect
/dev/sdb3              39        5392    43006005   fd  Linux raid autodetect
/dev/sdb4            5393        9726    34812855    5  Extended
/dev/sdb5            5393        7434    16402333+  fd  Linux raid autodetect
/dev/sdb6            7435        9726    18410458+  fd  Linux raid autodetect
# mdadm /dev/md6 -a /dev/sda6
mdadm: added /dev/sda6
# mdadm --detail /dev/md6
/dev/md6:
        Version : 00.90.03
  Creation Time : Tue May 27 12:14:58 2008
     Raid Level : raid1
     Array Size : 18410368 (17.56 GiB 18.85 GB)
  Used Dev Size : 18410368 (17.56 GiB 18.85 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 6
    Persistence : Superblock is persistent

    Update Time : Tue May 27 12:49:15 2008
          State : clean, degraded, recovering
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1

 Rebuild Status : 1% complete

           UUID : bf013ddf:1da1e663:2bb59604:4d695037
         Events : 0.34

    Number   Major   Minor   RaidDevice State
       0       8       22        0      active sync   /dev/sdb6
       2       8        6        1      spare rebuilding   /dev/sda6

A few minutes later the array was fully recovered and the oversize partition problem had been fixed, all online with no data loss and no need to backup and restore the data.

Another related niggle I had was that another RAID1 array, /dev/md0, made up from /dev/sda1 and /dev/sdb1, which was used as the /boot partition for the previous Fedora 8 installation, wasn't showing up in Fedora 9 (I partition my system up so that I can do a fresh install of new Fedora versions without writing over the the current version in case I have big problems and need to go back to the old version for a while). I suspect that the installer had changed something in the metadata:

# mdadm --query /dev/sda1
/dev/sda1: is not an md array
/dev/sda1: device 0 in 2 device undetected raid1 /dev/.tmp.md0.  Use mdadm --examine for more detail.
# mdadm --query /dev/sdb1
/dev/sdb1: is not an md array
/dev/sdb1: device 1 in 2 device undetected raid1 /dev/md0.  Use mdadm --examine for more detail.
# mdadm --examine /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : c0be5227:82b8bda1:055163eb:7970b0f9
  Creation Time : Sun Dec  3 15:19:27 2006
     Raid Level : raid1
  Used Dev Size : 152512 (148.96 MiB 156.17 MB)
     Array Size : 152512 (148.96 MiB 156.17 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0

    Update Time : Mon May 26 15:08:35 2008
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : f9147855 - correct
         Events : 0.58


      Number   Major   Minor   RaidDevice State
this     1       8       49        1      active sync   /dev/sdd1

   0     0       8       33        0      active sync   /dev/sdc1
   1     1       8       49        1      active sync   /dev/sdd1

I'm not sure why /dev/sda1 had been tweaked to be in /dev/.tmp.md0 rather than /dev/md0 but that was easily fixed:

# mdadm --create --level=1 --raid-devices=2 --auto=md /dev/md0 /dev/sd[ab]1
mdadm: /dev/sda1 appears to contain an ext2fs file system
    size=152512K  mtime=Mon May 26 15:05:33 2008
mdadm: /dev/sda1 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Sun Dec  3 15:19:27 2006
mdadm: /dev/sdb1 appears to contain an ext2fs file system
    size=152512K  mtime=Mon May 26 15:05:33 2008
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Sun Dec  3 15:19:27 2006
Continue creating array? y
mdadm: array /dev/md0 started.
# mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90.03
  Creation Time : Tue May 27 12:53:46 2008
     Raid Level : raid1
     Array Size : 152512 (148.96 MiB 156.17 MB)
  Used Dev Size : 152512 (148.96 MiB 156.17 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue May 27 12:53:46 2008
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 8fa04abe:c3894ab6:29fb567d:92fd1cec
         Events : 0.1

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1

I was then able to mount /dev/md0 and the existing data was still there as expected (i.e. the contents of the Fedora 8 /boot partition).

Wednesday 28th May 2008

Fedora Project

  • The mystery of the infinite recursive loop between pkg-config and gnome-config as described in Bug #445981 was solved by a commenter on that bug. It's a little-known fact that pkg-config falls back to trying gnome-config and a few other *-config utilities when it can't find the .pc file that it's looking for. I created a fixed gnome-libs package to alleviate the problem, built it for Rawhide, and created update packages for Fedora 8 and 9.

  • Raised Bug #448735 on perl in Fedora 9; the i386 version has an @INC path that includes module directories for older perl versions, and the x86_64 version doesn't. There are also a bunch of packages that include perl modules located in old perl directories rather than 5.10.0 directories that Fedora 9's perl should be looking in.

Local Packages

  • Updated gnome-libs as per the Fedora package

Friday 30th May 2008

Local Packages

  • New package moin-theme-dew, which I'm going to use as a starter for the wiki version of the SHAS website.

  • Updated dkms to 2.0.19.1

SHAS Website

With a view to making it easier for people to get content on to the website, I've created an experimental wiki version of the SHAS website.

This is a root wiki using mod_fcgid, and the Apache configuration is basically this:

# Virtual server for wiki.shas.org.uk
<VirtualHost *:80>

  ServerName          wiki.shas.org.uk

  # DocumentRoot is irrelevant since there are no static pages
  DocumentRoot        "/srv/www/shas/content"

  ServerAdmin         webmaster@shas.org.uk

  RewriteEngine On
  RewriteLogLevel 0

  # Point to moin shared static files
  RewriteRule ^/moin_static163/(.*)$ /usr/share/moin/htdocs/$1 [last]

  <Directory "/usr/share/moin/htdocs/">
      Options Indexes FollowSymLinks
      AllowOverride None
      Order allow,deny
      Allow from all
      <IfModule mod_expires.c>
           ExpiresActive On
           ExpiresDefault "access plus 1 month"
      </IfModule>
  </Directory>

  # FastCGI dynamic application with mod_fcgid
  RewriteRule ^(.*)$ /srv/www/shas-wiki/cgi-bin/moin.fcg$1 [type=application/x-httpd-fcgid]
  <Directory "/srv/www/shas-wiki/cgi-bin/">
      Options Indexes FollowSymLinks ExecCGI
      AllowOverride None
      Order allow,deny
      Allow from all
  </Directory>

</VirtualHost>

Previous Month: April 2008
Next Month: June 2008

Recent