Putting Fedora 16 onto a Dell Optiplex 745

I purchased a Dell Optiplex 745 (ultra small form factor) from a used equipment sale at the local university. I had hoped that it would be low power as well, but that does not seem to be the case – although a more modern computer is always going to be more efficient (or at least you would think so).

First, I had to reset the BIOS as it had been password protected against changes. Resetting the BIOS was simple: remove the password jumper in the system, boot fully once, then replace the password jumper. The full description is available at eHow. The only sticking point was trying to find the jumper in the case; it turned out to be roughly in the center of the board underneath one of the airflow covers. If you are looking at the system from the top – with the front facing you – the relevant cover is in the back left corner, and the jumper (a tiny blue shiny plastic jumper with extended grasping handle) is towards the center of the board.

I’ve not yet found how to reset the “title” that comes up when the system is booted; this does not seem to be in the BIOS settings anywhere. I could fully reset the CMOS entirely (rather than just the password) but that always scares me – what else will be lost?

Trying to use the CDROM, I ran into some difficulties. It appears it may be easy to put the CDROM in incorrectly; be sure to put it in the right way and seat it fully.

I decided I would put Fedora 16 on this system – and went with Fedora 16 64bit. This went quite smoothly and the system runs well. Specifically, I went with the Fedora 16 XFCE spin – which means it runs fast and light. Running a lightweight desktop on a fast machine is even nicer than I would have expected. I did load WindowMaker but haven’t yet tried it. Who knows – I might try 9wm once.

I loaded up everything that one needs for a home desktop: DVD playback, MP3 playback, and so on. I couldn’t get Parole to work with DVDs, so I went with Totem instead. In the same manner, I installed RhythmBox to play MP3s. I also had no problems getting Flash or Java to work. On the web, an excellent resource for all of these steps is at LinuxForDummies. Video and sound were recognized without problem.

This is definitely a nice setup: both the hardware (the Optiplex 745) and the software (Fedora XFCE 64-bit spin) are recommended.

Tips and Tidbits About LDAP

Setting up and understanding LDAP is not easy. In my opinion, nothing is obfuscated more and unnecessarily so than LDAP. There are a number of tips that can help you to understand LDAP.

LDAP is not authentication. This was the number one problem I had when I started (a while back). The first time user might search for documents on setting up LDAP when in fact they are looking for documents on how to set up UNIX and Linux authentication using LDAP. An LDAP server at its most basic doesn’t understand UNIX uids, doesn’t understand GECOS fields, doesn’t understand UNIX gids, and doesn’t understand Linux shadow files. Support for all of this must be added.

Support for UNIX authentication must be added. You would think that the most common usage for LDAP would come bundled and ready to go with the server; however, often this is not the case. Even if it is the case, you may find that for certain capabilities you are expected to add new LDIF files to support the fields in LDAP.

LDAP is not just another database server. Virtually everything in LDAP has a different name; it is unlike anything you’ve done before. Take heart: X.500 (where LDAP comes from) was worse. You’ll have to slog through a pile of new terms, but after a while it will become easier to understand.

OpenLDAP is not synonymous with LDAP. There are other servers out there. OpenLDAP does come with virtually every Linux platform; there are however, many others – many of which may be easier to use. There is the 389 Directory Server from Red Hat, the ApacheDS (part of the Apache Directory Project) from Apache, and OpenDJ from ForgeRock. OpenDJ itself is a spin-off from OpenDS, originally from Sun.

OpenLDAP is known for making non-backwards-compatible changes. The most recent example is the complete replacement of the configuration system.

OpenLDAP no longer uses slapd.conf. This will cause you no end of problems: there are a lot of people trying to explain how to set up OpenLDAP, and with a single strike (as of version 2.3) OpenLDAP made all of that documentation obsolete and useless. This is incomprehensible, but it is a fact.

Using and administering LDAP requires command line expertise. This is basically true, but like many things, it is not the complete truth. There are many programs designed to make it easy to browse LDAP stores, along with editing capabilities. Some of the more interesting products include Jxplorer, Luma, and the Apache Directory Studio. Of these, the Apache Directory Studio is the most capable, robust, and actively developed – and by far the largest.

Some LDAP entries can be present more than once or have more than one value. If you are comparing LDAP to a database, then this will come as a surprise. One valuable example is UNIX groups: the original UNIX systems only had one group per user; later, secondary groups were added – thus presenting a single user with multiple groups. This is handled in LDAP in a variety of ways, but they all amount to having multiple entries with different values.

Limiting user logins by host is not available in LDAP. This capability is most likely to be done by using the client host. There are a number of ways to do it, but all require LDAP client configuration, and all are limited in their application. Without client configuration, all LDAP users will have authenticated access to the host.

Be prepared to do a lot of web searches for documentation and solutions. The best places to go for searches are: Google (of course) and Ubuntu Documentation.

There are also very good articles and documents on using LDAP for authentication. There is an article about OpenLDAP authentication on FreeBSD (FreeBSD articles tend to be very well-written). Similarly, Ubuntu documentation is well-written as well; each of the Ubuntu versions has a section in the documentation on using and configuring OpenLDAP for authentication. Ubuntu 11.04 documentation has a good article on OpenLDAP for example.

Ubuntu documentation also includes a lot of well-written (and current) articles. For example, there are articles on OpenLDAP Server (a general article), LDAP Client Authentication, Samba and LDAP (from the 10.04 Server documentation), and Securing OpenLDAP Conenctions. If you plan to use 389 Server instead, there are even a couple of articles on using it with Ubuntu: Fedora Directory Server (the original name of 389 Server) and Fedora Directory Server Client Howto.

A nice overview of LDAP comes from Brian Jones at O’Reilly: specifically, his 2006 articles on Demystifying LDAP and Demystifying LDAP Data. Linux Journal also has myriad different articles on LDAP (not to mention an OpenLDAP theme for the December 2002 issue). Linux Journal also has an article from 2007 on Fedora Directory Server (now 389 Server).

Lastly, an excellent resource is the “book” LDAP for Rocket Scientists from Zytrax.com. You simply must go and read portions of this book. One very apt quote from the introduction to the book which sums up the state of LDAP documentation generally:

The bad news is that [in our humble opinion] never has so much been written so incomprehensibly about a single topic with the possible exceptions of BIND and … and …

(It should be noted that the other book at Zytrax is about DNS. Is it any surprise?)

UPDATE:

Yet another trick to LDAP:

The cn= attribute is not solely a leaf attribute. This can be seen in OpenLDAP’s cn=config tree with OpenLDAP configuration. For example, a typical admin user can be designated like so:

cn=admin,dc=bigcorp,dc=com

However, when you use OpenLDAP’s configuration, the designation for the admin user is this:

cn=admin,cn=config

When you look into the configuration tree, there are more cn= entries – like this:

cn={4}misc,cn=schema,cn=config

Log Rotation for MySQL using logrotate

The logrotate utility is a powerful and underrated utility used to rotate logs. It is one of Red Hat’s lesser known utilities; even so, it is available for a number of platforms, including Ubuntu.

However, its set up for MySQL is missing on Red Hat and incomplete on Ubuntu.

For Ubuntu, there is no rotation of the slow query logs. To rotate these logs, just add them to the standard Ubuntu logrotate file for MySQL – that is, /etc/logrotate.d/mysql-server. Add the logs to rotate to the beginning of the file, adding to the list of files already present there.

For Red Hat, a complete MySQL log rotation file is needed as there is none at all. The MySQL logrotation script was removed as part of a security update to Fedora Core 4 back on 17 May 2006, and later removed from Red Hat Enterprise Linux 4 Update 4. The reasoning was detailed in Bug #180639 (not available?) and Bug #182025. Since then, this missing logrotate file has been the subject of several bugs (such as Bug #547007) and also of message threads like this one from Red Hat’s rhelv5-list in July of 2007.

The response to all these queries is that the MySQL logrotate script is broken and it’s up to MySQL to fix it. However, this does not seem to take into account the new FLUSH LOGS command, and admins everywhere are creating their own scripts.

Over at Question Defense, Alex has a fabulous description of the entire process – from enabling logging through implementing log rotation. However, this process uses ~/.my.cnf to automatically log in; better is to use a file like /etc/mysql/maint.cnf the way that Debian (and Ubuntu) does it. In that case, Debian creates a special user and a password to go with it, and puts these into a file /detc/mysql/debian.cnf; here is a sample debian.cnf:

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = localhost
user     = debian-sys-maint
password = i5Px6N4SZ9UhfSWa
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = i5Px6N4SZ9UhfSWa
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

For most purposes, only the [client] section is needed, along with the first three entries (host, user, and password). You could also specify the section as [mysqladmin] instead, which would limit the username and password to being used for mysqladmin only – which is the tool used during log rotation.

The critical command is this one:

/usr/bin/mysqladmin --defaults-file=/etc/mysql/logrotate.cnf

…where logrotate.cnf contains username and password details as described above. All the rest of the logrotate file is settings and script-bulletproofing:

# Modified Ubuntu logrotate script for MySQL server
#
# Untested under Red Hat, but should work: filenames will have to be changed
/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log {
        daily
        rotate 7
        missingok
        create 640 mysql adm
        compress
        sharedscripts
        postrotate
                test -x /usr/bin/mysqladmin || exit 0
                MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/logrotate.cnf"
                if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
                  if killall -q -s0 -umysql mysqld; then
                    exit 1
                  fi 
                else
                  $MYADMIN flush-logs
                fi
        endscript
}

User Experiences with System Updates (Fedora)

There has been a lot of discussion about the direction of Fedora, apparently brought on in part by massive updates being pushed to recent Fedora users. I’ve not used Fedora for a long time – for various reasons – but this is good discussion.

Máirín Duffy has a fantastic article (it is a must read!) describing possible user profiles for Fedora Linux, as well as a description of how updates should be done. One thing she mentions that I haven’t seen in Linux before is the idea of an “update bundle”.

Bundled updates are done in many UNIX environments, including HP-UX and Solaris. In my experience with HP-UX, all of the updates are available separately, but there are also patch bundles that are put through strenuous QA together. With all of the patches run through QA as well as the bundle, this leads to better stability for the environment.

Also in HP-UX, each patch is posted with a “patch readiness level” that explains what amount of QA the patch has actually seen so far. Thus, you can load that patch early if you want, or wait until its rating (given in a star rating) rises, indicating less likelihood that the patch will break the system.

Most Linux systems are run through QA as a system, with each package being tested and sent through QA individually.

With all of the discussion that I read, it seems almost like a new spin or distribution is almost necessary which would capture the essence of Fedora with the stability found in Debian Stable or Ubuntu LTS. The camps seem to be split between two sorts of people:

• People who want the latest versions of everything all the time, no matter how many updates are needed.
• People who want a system that is stable and doesn’t change.

If the current leadership is unwilling to accommodate those that want stability and reliability, then they will go somewhere else to find it. This would be a dramatic loss to the Fedora community in my opinion.

A New Init for Fedora 14

Apparently, a new project (to replace init, inetd, and cron) named systemd is nearing release and will be used to replace upstart in Fedora 14 (to be released in November – with Alpha Release due today!).

There is a healthy crop of init replacements out there, and the field is still shaking out. Replacing init – or specifically, System V init and init scripts – seems to be one of those never-ending projects: everyone has an idea on how to do it, no one can agree on how.

Let’s recap the current crop (excluding BSD rc scripts and System V init):

• Upstart
• Apple’s launchd
• Solaris’s System Management Facility (SMF)
• runit
• Richard Gooch’s simpleinit (and introduced in a paper at the 2002 Ottawa Linux Symposium)
• initng
• daemontools
• NetBSD and rc.d
• Make

I am still waiting for the shakeout – it bugs me that there are dozens of different ways to start a system, and that none of them have taken over as the leader. For years, BSD rc scripts and System V init have been the standard – and both have stood the test of time.

My personal bias is towards SMF (OReilly had a nice article on it) and towards simpleinit – but neither has expanded like upstart has.

So where’s the replacement? Which is The One? It appears that no one is willing to work within a promising project, but rather starts over and creates yet another replacement for init, fragmenting the market further.

Lastly, if the current init scheme is so bad, why hasn’t anything taken over? Commercial UNIX environments continue to use the System V scheme, with the sole exception of Solaris which made the break to System Management Facility (or SMF). Why doesn’t HP-UX or AIX use SMF or Upstart if the current environment is horrible?

Sigh. It’s not that the current choices of replacement are bad – it’s just that there are so many – and more keep coming up every day. Perhaps we can learn something about the causes of this fragmentation from a quote from a paper written about the NetBSD rc.d startup scripts and their design:

The change [in init] has been one of the most contentious in the history of the [NetBSD] project.

Bug: synergyc freezes

If you are using Synergy in your daily work, you may have noticed that the Linux client is not working as it should. A bug (Bug #194029) reported to the Ubuntu development team provides extensive reports about the problem and possible resolutions. The biggest problem is sifting through all of them, as well as the realization that they don’t seem to have it fixed yet.

Admittedly, my problems are with Fedora 9 and Windowmaker (which shows that its not Ubuntu-specific, nor is it specific to GNOME or KDE). However, the resolutions seem to work under Fedora just as well as under Ubuntu.

The resolutions recommended are:

• Run synergy as root: sudo synergyc. This resolution seems to be one least likely to work.
• Run synergy with the highest priority possible using chrt: chrt -p 99 synergyc. This method can be incorporated into a startup script thusly: /usr/bin/synergyc myserver; pgrep synergyc | sudo xargs chrt -p 99
• Recompiling the Linux kernel with a different scheduler: instead of configuring with CONFIG_FAIR_USER_SCHED use CONFIG_FAIR_CGROUP_SCHED.
• Patching synergyc to fix the problem.
• Enabling (for Ubuntu only) the hardy-proposed repository and updating the kernel to 2.6.24-16 or 2.6.24-17-generic seemed to work (although there were complaints that the desktop became sluggish).

In the case of Fedora 9 at least, this bug remains present even though it is almost a year old. I don’t use synergyc on a Ubuntu client – my Kubuntu host I use almost entirely at the console directly.

So what is the answer? I’d try using chrt first (for me that lessened the problem dramatically) and try upgrading to a new kernel configuration.

Installing OpenSUSE 10.3 onto a HP nc4010

I installed OpenSUSE 10.3 onto a HP nc4010, and it went smooth. I am still working out the problems (here and there) as well as creating a number of new problems as I keep piling on the software (I always do that….)

This time I downloaded Billix and expanded it to cover installs of OpenSUSE 10.3, OpenSUSE 11.0, and Fedora 9. Billix is not actually a Linux distribution; it is a collection of distributions that are installable from the USB stick or CDROM (as well as utilities such as chntpw, memtest+, and Darik’s Boot and Nuke).

The biggest problem with installation so far seems to be that the grub installers I’ve seen so far cannot cope with the situation that Billix presents:

• The boot disk (install disk) is the first in the chain (i.e., hd0).
• The operating system is being installed on the second disk (i.e., hd1).
• The startup disk (after installation) will be what is hd1 during installation, but will become hd0 on startup.

The end result is that the operating system install does almost everything just right but then installs grub onto the USB stick, and configures it to boot the hard disk. Thus, if you boot normally, the process halts mysteriously with no message; if you boot with the USB stick in place (booting from USB), then the USB stick will boot the operating system located on the hard drive.

Recovering both Billix and the native operating system are easy enough. To recover Billix, just redo the master boot record initialization process:

• Install the MBR: install-mbr -p1 /dev/usbstick
• Reactivate and reinstall syslinux: syslinux -s /dev/usbstick1

Note that install-mbr requires the disk device (such as /dev/sdb) whereas syslinux requires the relevant partition (such as /dev/sdb1).

Once the disk is properly configured, it is just a matter of finishing the install process. The install process reboots to finish, and it is all quite straightforward. Installing OpenSUSE is a breeze, and the amount of work that has gone into making a very easy-to-use desktop Linux is obvious from start to finish.

Even the bluetooth daemon, which caused problems after hibernation under Kubuntu, had absolutely no problems in OpenSUSE. Even turning the device on and off using the button on the laptop worked beautifully.

One thing that stood out was that there is no way to pair a bluetooth device. Nope. But let me explain…. If you try to pair a device, there is no way to do it. If you try to use your bluetooth device (copy files to it, etc.) then the system will ask you to pair the device at that time. I would have prefered both options, but oh well.

The experience in using OpenSUSE has been a delight; everything has been designed to present you with the best possible Linux experience possible. The choice of task bar applications on startup, the configuration of the desktop, the entire experience shows an attention to detail that many distributions do not have.

As a system administrator, you should try Billix. As a user, you should try OpenSUSE. Simple, eh?

Is FreeBSD a better choice for the desktop? (or dispelling myths)

It’s strange I should come across this article in one of my favorite blogs just after I switched from my FreeBSD desktop to Kubuntu. I’m also surprised at the lack of knowledge and the propagation of some long-standing myths about Linux and FreeBSD for that matter.

There are some ways that FreeBSD (or better put, BSD) is better than Linux – but the comparisons must be valid and appropriate without myths and falsehoods.

Perhaps the primary myth is that FreeBSD is a complete operating system and Linux is a boat-load of different distributions in all different flavors with different setups and so on. However, FreeBSD also has a large number of alternatives, including OpenBSD, NetBSD, PCBSD, DesktopBSD, PicoBSD, and Dragonfly BSD to name just a few.

Another comparison is that FreeBSD is put together by the FreeBSD Core team and that this is better than Linux (which has a “benevolent dictator” model). There’s no discussion of OpenBSD, for instance, which also follows this “benevolent dictator” model. There’s also no comparison to Red Hat Enterprise Linux, for example, which has a large number of people working towards putting together a complete distribution, not just the kernel.

The documentation is definitely an argument in favor of BSD – virtually everything that is in the system anywhere is documented in the online documentation, and the FreeBSD Handbook is without equal. It can be proven programmatically that there are commands in Red Hat (or other distributions) that are not documented. I daresay that the FreeBSD documentation beats other BSD variants as well.

Another benefit of FreeBSD specifically is the vast number of ports available. There are more ports for FreeBSD than any other system but Debian GNU/Linux. The sheer amount of packages available in both environments has made them appealing to me – and perhaps to others. Where else are you going to get Steel Bank Common Lisp for example? Both Debian and FreeBSD have it.

The article specifically asked about FreeBSD for the desktop: FreeBSD is definitely not ready for the desktop at all. When I installed it for my desktop (twice now), the basics are there certainly – but there were numerous problems that I had to overcome. Among them, I had to set up my own system bootsplash, and had to configure and set up my own login screen (kdm). USB devices plugged in weren’t properly recognized. Hibernation and sleep didn’t work. Flash doesn’t work. Unlike what has been said before, the drivers are much less available than they are for Linux: hardware manufacturers don’t see a need to support BSD, and many new UNIX users (and developers) don’t see a need to use anything but Linux. Wireless support is perhaps an exception, but that development is centered in OpenBSD, not FreeBSD.

There is also, in my mind, a benefit to BSD that goes often unmentioned: it has the smallest kernel of the open source UNIX and Linux kernels out there today. FreeBSD and OpenBSD will run in smaller environments that Linux won’t: on my 512M laptop, a Compaq Armada E500, Fedora 5 would crash during the install (not enough memory) – whereas the much more current FreeBSD 6.2 installed just fine.

Now, when I installed Kubuntu onto a Compaq nc4010 with 1G of memory, it went will – and it recognized everything – wireless, hibernate, bluetooth, USB devices, PCMCIA, video display, power capabilities, etc. – all without special configuration. (I might note that, here too, on this machine Fedora crashed – this time the Live USB Fedora 9 crashed during exit – sigh…) Preconfigured and tested support for Flash, Java, and MP3s was a click away.

When it comes to the desktop, FreeBSD has a long way to go (perhaps PCBSD is a lot better?). However, on the server end, I would propose that FreeBSD is a better way to go than Linux in many cases (except for OpenBSD might, in my opinion, be even better). It is unfortunate that none of the BSD variants are often considered for enterprise server use – especially considering FreeBSD is commonly found in NetCraft‘s list of top uptime.

Putting Linux on a Compaq nc4010

The HP/Compaq nc4010 is a business-class laptop with no CDROM, no DVD, and no floppy – but with network, modem, USB ports, SD slot, and PCMCIA slot. The system has a 1.7GHz Pentium M – snappier than a Pentium II for sure. It will also boot from the network with PXE or from the USB ports.

Booting this platform is the most difficult part. I didn’t try using PXE, because although I was once set up for PXE on my home network, I don’t have the distributions (Kubuntu and Fedora) set up for installing from PXE and it seemed like a bigger headache than try to make it boot through USB. USB booting is not (apparently) enabled by default; it requires setting USB to use Legacy in the BIOS settings – and in my case, it also required playing with the setting for Quickboot: I had turned it off, but upon re-enabling it the system booted from a USB key.

I tried using Fedora 9, but the Live USB version come up in a lower resolution and crashed upon exiting. I tried also Kubuntu Hardy (8.04.1) and it worked beautifully.

Loading Kubuntu was a breeze – and recognized all of the capabilities of the laptop (amazing!). USB works, network works (albeit with proprietary drivers), PCMCIA works – it just works. Even hibernate works (although suspend may not).

I’ve never quite liked Ubuntu, and I mostly chalked that up to its standard themes (brown and orange) and its use of Gnome and so on – never fully experiencing Ubuntu and always wanting to get a better feel for it. I’ve tried running Kubuntu (which uses KDE) before, but never as an “active” desktop.

Kubuntu made a believer out of me. Everything works in the laptop. Even MP3s, Adobe Flash, Java – it all installed cleanly (upon demand) and works out of the box. Installation was extremely simple. The available packages are quite extensive, and include Debian’s packages.

I attribute some of this ease of support (specifically, MP3 support, Flash, Java, proprietary drivers) to the fact that the company behind Ubuntu (Canonical) is not an American company, but a South African company – which has different laws. So they can make it easy to get proprietary “parts” that they could not sell or support otherwise.

I’m switching from my FreeBSD laptop to this one for the most part: this system is smaller, lighter, faster, and has more memory. It was good to build a FreeBSD desktop though – and took more doing than I thought. I wonder what PC-BSD would be like….. Hmm….

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).