HowTo Fix: “[…] only available with the XS version of Scalar::Util”

Recently, we upgraded our systems, and one of the updates was an update to Perl. After this update, a portion of Bugzilla failed to work as expected; the problem turned out to be in SOAP::Lite:

# perl -MSOAP::Lite -e "print;"
weaken is only available with the XS version of Scalar::Util at /usr/lib/perl5/vendor_perl/5.8.8/SOAP/ line 2502
BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.8.8/SOAP/ line 2502.
Compilation failed in require.
BEGIN failed--compilation aborted.

This is on a machine running Red Hat Enterprise Linux (RHEL) 5.7. The bug (Bug #375621) was initially reported back in November 2007 with RHEL 5.2. The final resolution came with bug #594768, where the problem was explained completely and resolved for good in RHEL 6.

The problem is that the updates to Perl are overwriting files added via CPAN. When this happens, versions that have an XS version are reverted back to their original forms without XS support. This appears to happen with Scalar::Util the most.

The fix is to reinstall the CPAN modules affected by the Perl upgrade. A force will be necessary. For example, this command to install Scalar::Util:

cpan> force install Scalar::Util
Running install for module Scalar::Util
Running make for G/GB/GBARR/Scalar-List-Utils-1.23.tar.gz
Fetching with LWP:
CPAN: Digest::MD5 loaded ok
Fetching with LWP:
Checksum for /root/.cpan/sources/authors/id/G/GB/GBARR/Scalar-List-Utils-1.23.tar.gz ok
Scanning cache /root/.cpan/build for sizes

Once the relevant modules are reinstalled, the files will be reverted back to the way they were before the upgrade took place – and all should be working again.

Using Meta-packages to Standardize Servers

Both Ubuntu and Red Hat offer meta-packages which have no files of their own, but depend on others – thus requiring a set of packages to be present. You can use these packages to require a set of software to be present on a server, especially those that are not normally installed by the vendor’s install process.

A meta-package can save you time – you don’t have to install each package one at a time. A meta-package can also be included as part of a Puppet environment, so that all servers will be kept up-to-date with the current set of packages. A meta-package can also be a part of an automatic install process, also bringing in all necessary software and simplifying the installation steps.

In Ubuntu, creating your own meta-packages is made easy by using the equivs package. With RPM, you’ll have to create a meta-package using rpm-build and the appropriate SPEC file.

The only way that using a meta-package will truly save time is if you are using a program like APT or YUM to do installations because they will automatically compute the dependencies required and install them automatically when the meta-package is installed.

With a meta-package, you can require a set of packages that should be on every server – as well as force some packages to be removed. You can create a meta-packages that includes all packages that should be on a server, but aren’t usually installed (like gawk, logrotate, sysstate, ntp, logwatch, make, and m4 for instance). When the package server-main is then installed, all of its dependencies will also be installed. Any packages that are listed as conflicting packages will also be removed: packages like unattended-upgrades and command-not-found for instance.

Meta-packages could be created for packages that are from the Ubuntu Main repository, and for those packages that are in the Ubuntu Universe repository. This makes it simple to only include software from the Main repository and preclude those packages that are from the Universe repository.

These meta-packages could then be added to a local repository and added to a system during installation; this simplifies the package installation part of the install process and allows you to update any currently installed systems simply.

As an example, here’s my list for requirements (put into server-main) from the Ubuntu Main Repository:

  • lvm2
  • byobu
  • ruby
  • vim
  • snmpd
  • snmp
  • mlocate
  • postfix
  • ltrace
  • strace
  • wget
  • ntp
  • m4
  • make
  • ifenslave
  • dnsutils
  • procps
  • sysstat
  • logrotate
  • logwatch
  • sharutils
  • pdksh
  • dc
  • bsd-mailx
  • nut
  • finger
  • xfsdump
  • xfsprogs

And from the Universe repository, these are my suggested requirements (used as dependencies for server-universe):

  • iperf
  • jwhois
  • apt-file
  • chkconfig
  • atop
  • dstat
  • maatkit

Administrator Experiences with VMware and SUSE Linux

Recently, VMware announced a partnership with Novell in which they would support Novel SUSE Linux Enterprise Server (SLES) directly on VMware vSphere. Neil over at VirtuallyNil wrote about his experiences with SLES and VMware ESXI. Unfortunately, he had some problems with VMware’s additions to SLES.

To enhance the experience with virtual machines, virtual environment managers add tools to the guest environments – and VMware is no different. For SLES there are tools available that permit advanced operations directly from the virtual machine manager. With ESXI, these are available for SLES 10 and SLES 11 – but not SLES 11 SP1.

This means that you either build your own SLES 11 SP1 tools or you cannot upgrade your SLES 11 to the most recent patch level. This is unfortunate.

I have experienced this before with an application that required a particular version of Red Hat Linux (7.1 if I remember rightly) even though that version of Red Hat was no longer supported by Red Hat itself.

Also, Neil points out two other sites that have images of people’s direct experiences with the new VMware-supported SLES. One first look comes from (a blog by Eric Gray, a VMware employee); the other comes from Jase McCarty at Jase’s Place.

About a Ubuntu Add-on CD

Where I live, there is only three choices for Internet: dial-up, cellular 3G, and satellite. There is no cable – no DSL – no BBoP – nothing that has any high-speed capabilities. Cellular (new in the area!) works but there is a 5Gb limit for the month – otherwise they will assume that you are performing tasks against your usage contract and reserve the right to cancel without notice (!).

There has been lots of talk about creating an Ubuntu Add-On CD, but nothing official and nothing lasting. There is an Add On CD Creation project as well as a (dated) Unofficial Ubuntu 5.10 Add On CD: neither of these projects seem to have continued. Over at Bounty Source, there is another project called the Ubuntu Plus AddOnCD; likewise, this has not kept pace. There used to be something at Ubuntu Guide but the link is no longer valid to that specific page, although the site seems active and current.

There’s also a DVD built by one or more Indonesian containing Ubuntu repositories; if I could read Indonesian, I could read the websiteand tell you more about it. There do appear to be multiple distributors across Indonesia.

There are two sources that seem to have kept pace, although neither supports Ubuntu Jaunty Jackalope or its descendents. One is an Italian who creates an add-on CD and posts it; it is the UbuntuPiù CD. Another is called the Ubuntu ADDONCD. Hopefully one or both of these sites will update with Jaunty Jackalope soon.

The main method of creating an Ubuntu add-on CD is to create an Ubuntu (Debian) repository then burn it onto CDROM. This is fine as far as it goes – however, the current Ubuntu repositories are 70+ gigabytes in size and mirroring the entire repository at this point is a big deal – especially when terabyte drives are not yet common.

The Debian APT Repository How To is an expansive document describing how to make your own repository. There is also an excellent article on creating an Ubuntu repository with apt-mirror.

Also, some projects assume that you have downloaded all of your added packages without ever having run “apt-get clean” – despite the fact that the apt-get man page recommends that you do so and says that any program that uses dselect will call apt-get clean as part of its normal processing. Using this download cache seems to be very short-sighted, but it is done by tools such as aptoncd which are otherwise very promising.

The apt-move How To, while otherwise quite useful, also makes this assumption. The assumption that “apt-get clean” will not be run is not a valid one!

Perhaps the only way to resolve the matter is to force a download of the desired packages – but currently there doesn’t seem to be any way to download a package and all dependencies not found in the Ubuntu install CDROM – in fact, there’s no way to download all dependencies at all. It should be possible to create a script to do it some how.

To download a specific package – but without its dependencies – is to do thus:

apt-get install --reinstall -dy package

This will put the package into the apt cache for use by other programs that seem to think the cache is never cleaned out.

To get a list of dependencies, you have to use apt-cache and massage the output to get a list:

apt-cache depends bzflag | sed -n '/^[^ ]/d; /]*>/d; s/^.*: //; s/^ *//; p;'

Once you have this list of dependencies you might be able to download the files with something like:

apt-get install --reinstall -dy $(cat resultsfile)

…if you’ve saved it to a file called resultsfile. One problem is that a dependency could be a virtual package – and since the program is working from a cache of repositories, it reports all packages that provide the virtual package, not those that are installed.

One more thing – if you are trying to build a repository and are building from the system’s APT cache – then you can only build a repository relating to the current environment. Thus, if running Ubuntu Hardy Heron, you can’t use the cache to create a repository for Ubuntu Jaunty Jackalope.

I can’t let this end without mentioning RPM. Debian’s biggest weakness is, in my opinion, dpkg: RPM when combined with APT-RPM is so much more powerful than the dpkg and APT environment. RPM is very clean and is even portable: administrators running RPM on Solaris and other machines is not entirely unusual: running dpkg on Solaris would be news-making. Too bad there isn’t a version of Ubuntu that uses RPM (is that a hint?).

Spacewalk (or Red Hat Satellite)

The code base for Red Hat Satellite was released as open source some time ago as Spacewalk, and the future looks quite bright. I am excited to see this, and am interested in the possibilities that it presents for Linux management.

There are two nasty drawbacks that aren’t mentioned up front (though are mentioned in the technical FAQ): first, it relies on an Oracle database rather than PostgreSQL or mySQL or other open source database; secondly, it will support Fedora clients or CentOS clients or Red Hat clients – only one of the three at a time. This also suggests that it will not support other RPM-based distributions such as Yellow Dog or OpenSuSE.

Presumably, it also will not work with APT – and not because APT doesn”t support RPM because it does (in the form of APT-RPM).

Running Linux/UNIX under VMware Server 1.0

I have the distinct pleasure of having tried a number of systems under VMware Server, including OpenSUSE 10.3, Kubuntu 7.10, OpenBSD, and Solaris Express Developer Edition.  All work quite nicely.

There is one caveat – this environment uses a dual-monitor setup for Windows, and if the emulator autodetects the desktop size it expands to something approximating the two monitors put together.  The emulated environment works just fine (usually) with this screen, but it can’t be used in full-screen mode (since that goes to one screen only).

In that line of video mishaps, Solaris detected the video but only wants to allow 1024×768 (I’ve 1280×1024 here).  Whatever.

I also did not try OpenBSD as a desktop environment – I’ve actually yet to really put it through its paces that way (although I did set up OpenBSD 3.0/Mac68k with WindowMaker a while back….).

Which one do I like the most?  Currently I find myself looking toward OpenSUSE 10.3 more and more – and loving to use it.  The new KDE menu is a pleasure to use, and I love the immense selection of RPMs (and I do like RPM as it is).

The fact that they split up the KDE RPMs seems ghastly to me – too many things to choose.  For example, KDE Office is available in all its little bits – as is KDE Toys, KDE Games, and whatever else.  Nicer just to choose to install KDE Toys or not… I’m not sure whether I like having KDE 3 as a base with all of the KDE 4 applications available – but it seems to work alright.

I’d like to install BeleniX next, but they’ve not updated their system yet – the last hard disk install was buggy. I’m waiting eagerly….

UNIX Fragmentation

Did you ever notice that while UNIX and Linux versions are uniform in most areas, there are certain areas where every system seems to do things their own way? These are the things that nobody seems satisfied with, and so has to create their own version – and thus confuse new users. From what I’ve seen these areas are:

  • Menu-based system administration tools
  • Package management
  • Locations of user-added software
  • Filesystems

The last two are not so bad – user-added software locations are generally limited to /usr/local and to /opt (if any), and filesystems don’t tend to “wander” from one UNIX to another – and managing filesystems is not done often enough to make the slight differences annoying.

The real annoyances to system administrators tends to be the first two – system administration tools and packaging. Consider these options of system administration tools for various systems:

  • smit (AIX)
  • sam (HP-UX 11v2-)
  • smh (HP-UX 11v3+)
  • yast (SUSE Linux)
  • redhat-config-* (Red Hat)
  • sysadm (Unixware)
  • webmin (portable)

This doesn’t take into account all the others – IRIX, other Linuxes, ad nauseum. What is it about system administration that every last distributor has to do it their own way? Perhaps webmin will help some, but do we really want a web server on every server? Even so, this is becoming a requirement imposed by the distributors already – so might as well standardize on webmin, right? Perhaps not….

And packaging is even worse. We have these options:

  • RPM (Red Hat)
  • pkg (Solaris)
  • depot (HP-UX)
  • dpkg (Debian)
  • pkg (Unixware)
  • Ports Tree (FreeBSD)
  • emerge (Gentoo)
  • pbi (PCBSD)
  • lrp (Linux Router Project and spinoffs)
  • packages (MacOS X)
  • ports (NetBSD)
  • ESP (portable)

What is it that people just can’t leave well enough alone? Perhaps if BSD had come out of Berkeley with these tools, things might have been different.

There is one ray of hope in this ghastly array of choices: the most flexible and powerful (in my opinion) is also portable: RPM. So all of the systems previously mentioned will also run RPM. Too bad that they won’t necessarily run APT-RPM, but that’s another problem.