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

Fedora 9 Announced

Yesterday Fedora 9 was announced. Using Fedora can give you a look at what may be in Red Hat Enterprise Linux down the road – and give you an exciting Linux distribution to boot.

There are a number of new exciting features to be found in Fedora 9. First, everything is updated to the latest versions, including GNOME 2.22, KDE 4.0.3, and Xfce 4.4.2.

Fedora 9 introduces the new filesystem ext4 as an option. While ext4 remains an experimental filesystem, it may be good to try it out. Like ext3, it remains compatible in both directions (an ext4 filesystem can be mounted as ext3, and vice versa).

Fedora 9 also replaces the System V initd process with an event-based replacement, upstart. Upstart was created and developed for Ubuntu Linux, and has spread to Fedora and Debian. Each process is started through a response to an event, and each process may generate another event.

Fedora 9 has several different spins or variations based on different sets of packages. For example, there could be a KDE spin, a GNOME spin, and a Xfce spin for example. The Fedora project has a page tracking spins for those who might be interested in custom spins.

This version of Fedora introduces support for Jigdo, which is a CD distribution mechanism that the Debian project has used for years. I’ve not used Jigdo, but the description given in the release notes suggests a large speedup if you have most of the data already.

It sounds like a very exciting distribution; I’ll be looking around my electronic wasteland to see where to install it.

How much memory is in the box? (all UNIX, OpenVMS)

How much memory is in this machine?

It would seem that answering this question ought to be easy; it is – but every system has the answer in a different place. Most put an answer of some sort into kernel messages reported by dmesg (AIX apparently does not).

Most systems have a program for system inventory which reports a variety of things, including memory.

Rather than go into great detail about each one, we’ll just put these out there for all of you to reference. Each environment has multiple commands that give available memory; each command is listed below.

Without further ado, here are a few answers to this burning question:

Solaris

1. dmesg | grep mem
2. prtdiag | grep Memory
3. prtconf -v | grep Memory

AIX

1. bootinfo -r
2. lsattr -E1 sys0 -a realmem
3. getconf REAL_MEMORY

HPUX

1. dmesg | grep Physical
2. /opt/ignite/bin/print_manifest | grep Memory
3. machinfo | grep Memory

Linux

1. dmesg | grep Memory
2. grep -i memtotal /proc/meminfo
3. free

OpenVMS

1. show mem /page

Update:

FreeBSD

1. dmesg | grep memory
2. grep memory /var/run/dmesg.boot
3. sysctl -a | grep mem

Generating a coredump (gcore)

If you wish to examine a runaway program outside of its element, you may choose to use the utility gcore. This utility is found in Solaris, Linux, and HP-UX, and perhaps others. The program syntax is:

gcore [ -o corename ] pid

The pid is the process id of the process to dump core, and the corename is the base of the filename to use for the core dump – the full name is the base name plus period (“.”) and the process id number. The default is to use “core“.

HP-UX systems will accept multiple process ids instead of just one. Solaris has several additional flags (as well as multiple pids). The additional Solaris flags won’t be covered here.

Once core has been dumped, the program continues operation; it does not stop. Thus, gcore is especially useful for taking a snapshot of a running process.

For example, consider a program with the process id 6674:

gcore 6674

This command generates a core file in the current directory with the name “core.6674“. This file then can be read by the GNU debugger gdb. Solaris also provides the dbx(1), mdb(1), and pstack(1) utilities. HP-UX provides gdb as well as the HP adb(1) utility. Both Solaris and HP-UX provide a core management utility coreadm(1m) – which is a topic for another day.

This article has an excellent description of working with core files in Solaris.

Using OPIE on Fedora 7

Well, it turned out that installing OPIE went smoother once I figured out what was causing the RPM rebuild to fail.

I took the source RPM from OpenSUSE, and installed it onto the Fedora system:

rpm -ivh opie-2.4-630.src.rpm

This installs the files in their appropriate locations in the RPM build tree. In Red Hat distributions, this means /usr/src/redhat: the spec file goes into /usr/src/redhat/SPECS, and the sources and patches go into /usr/src/redhat/SOURCES.

Then I had to remove a line from the spec file (opie.spec) that read:

%debug_package

Otherwise, the Fedora RPM suite complained thusly when built using rpmbuild:

error: Package already exists: %package debuginfo

Building the binary RPM consists of:

rpmbuild /usr/src/redhat/SPECS/opie.spec

The RPMs will be created in RPMS/i386.

Installing the RPMs is then very straightforward:

rpm -Uvh opie-2.4-630.i386.rpm

These steps bring us to the point where we now have opie available (and installed as an RPM). The rest is configuring opie. In the file /etc/pam.d/system-auth, add a line under the line that mentions pam_unix.so:

auth sufficient pam_opie.so use_first_pass

This line adds support for one-time passwords during logins – including most all forms of logins. However, some login programs do not handle the extra output and requirements well. KDM (related to XDM) perhaps does not handle it the best: a message is put up, and then it goes away without any indication that the password request has changed.

In any case, to support a user with OTP requires initializing their OTP key. This is done with:

opiepasswd -c user

This initializes the password and OTP for the specified user. This command should only be used in a secure environment (such as over SSH or on the system console). It will ask for a new password to create (only needed for a few things, but important) and then generates your secret password (along with the sequence number and the seed). All three of these things will be needed when using OTP calculators. Remember that your secret password is just like any other normal password: that is, it must be kept secret. The sequence number and seed are not enough to get in, and the generated OTP are not enough either (though they should also be kept secret).

It is possible to generate a list of the next series of OTP passwords to use; for example:

$ opiekey -n 5 -5 499 my9999
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
495: KAY TRY GLOM NOVA CALF KIM
496: OVAL JADE RUNT LATE MIT JAKE
497: MYRA COED LIND TO GREY FIG
498: NESS WAKE BLOC COAT GAIT ROWE
499: CLAW GAGE HOST MARK FAIN PAP

However, do not do this over an insecure line – such as from telnet, xterm, rsh, and so forth – as your secret pass phrase will be sent in the clear. Whenever using an OTP password calculator, make sure that your password is not seen by others, whether on the wire or in person: again, it is just like a regular password and should be treated as such. The generated passwords should also be kept secret; however, during use secrecy is not required. That’s because as soon as it is typed in, it is no longer valid.

Using OPIE

Setting up OPIE (One-time Passwords In Everything) in OpenSUSE was easy: there is a opie RPM in the standard repository, and it installs cleanly and easily.  Then it is just a matter of initializing the database and modifying the PAM configuration to match.  Then each user is added to the database (/etc/opiekeys) one at a time.  I’ll describe the exact process on OpenSUSE at a later time.

Insufferingly, it appears that Fedora (and Red Hat) do not offer any form of one-time passwords anywhere – and certainly not OPIE.  RPMs for opie are exclusively for OpenSUSE and for the Polish PLD distribution (both of which seem to have everything).  How extremely frustrating!  This sounds like a good time to switch my home system from Fedora 5 to OpenSUSE 10.3.

OpenSUSE has supported LVM, XFS, KDE, and many other technologies when Red Hat staunchly refused to.  Even now, OpenSUSE support for all of these is much more integrated and time-tested than Red Hat’s.

Lest I sound like I hate Red Hat – I don’t – and that’s what makes it so frustrating.  Grrr….

The search for one-time passwords for HP-UX and for OpenVMS was even more fruitless.  HP-UX apparently has a third party skey package available; OpenVMS has nothing – though it could be added through programming the ACME interface (which provides similar capabilities to PAM – though perhaps not as flexible).

It looks like the BSDs aren’t a lot better: FreeBSD has OPIE built into the core (with a full section on OPIE in the FreeBSD Handbook on it); NetBSD and OpenBSD do not appear to have it (!).

Looks like my settling in to FreeBSD and OpenSUSE has paid off.  I don’t even need to suggest Debian – Debian has everything - and OPIE is no exception.  And of course, Ubuntu follows suit as well.