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 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.
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.
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:
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.
- Fixing the initscript to restore the default context for the PID file before starting the dæmon:
--- /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
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