Virtual Desktop Size in RHEL5 Beta 1

I had trouble getting the virtual screen size in RHEL5 Beta 1 to match my monitor's native resolution. It is an HP L1706 attached to a dc5100 SFF.

RHEL defaulted to 1600x1280 (or so) and the LCD's native resolution is 1280x1024 @ 60Hz. This resulted in the display panning around the virtual desktop when the mouse reached a screen edge. It also caused the menu and task bars to not always be available on screen, since they were at the edges of the virtual desktop.

Unfortunately the settings from System-->Administration-->Display, system-config-display, did not correct this. X reverted to the larger size.

I tried to use

system-config-display --set-resolution 1280 1024

This sets the Virtual setting, but /var/log/Xorg.0.log told me there was no matching mode. Well, system-config-display has no command line switch for setting the mode(s).

So, I manually edited /etc/X11/xorg.conf to contain:

SubSection "Display"
       Virtual   1280 1024
       Modes "1280x1024x60"
EndSubSection

in the Screen section.

This produced the desired effect, running the monitor at its recommended settings and setting the virtual desktop size to match it.

Building BOINC Samples on CentOS

Why am I blogging this? Because I initially (and repeatedly) missed the "documentation" at the top of Makefile.

Previously, I was editing the makefile to be more "portable". Only, those edits did not link against the static version of libstd++, which is the prefered way of linking applications that will be pushed down to the client. Doing so avoids runtime issues with missing or mismatched library versions.

But first, you need to build the BOINC client software. Then, as mentioned above, some of the examples like uppercase require a link to the static version of libstdc++.a. The makefiles for those projects contain:

# Do this first:
# ln -s `g++ -print-file-name=libstdc++.a`
# This creates a symbolic link to the C++ library,
# which is linked statically

So, just do:

ln -s `g++ -print-file-name=libstdc++.a`
make

to get them going.

Building the BOINC Client on CentOS-4

UPDATE: Fixed directions on adding lines to curl-local.spec.

Both Red Hat Enterprise Linux 4 and its clone, CentOS-4, need some updated packages to build the BOINC client out of the box. For example, they both ship libcurl 7.12.1 and BOINC requires 7.15.5 or better. They already ship RPMs for the older version, we just need to create an RPM for the newer version.

The only instructions that should be CentOS specific are related to retrieving the source RPM files. For Red Hat, you might try:

$ sudo up2date --get-source 

On CentOS:

$ wget ftp://rpmfind.net/linux/redhat/updates/enterprise/4AS/en/os/SRPMS/curl-$(yum -C list|grep curl-devel|awk '{print $2}').src.rpm

will work. This calls yum (which does not exist in RHEL4) to find out what the current version of curl-devel is. Then awk spits out only the version information and the whole thing is plopped down into the middle of the URL passed to wget, which retrieves the file.

Once retrieved:

sudo rpm -Uhv curl*.src.rpm

will install the source and files necessary to build an RPM. Following that, everything should be available under /usr/src/redhat.

Let's change to that directory to update and build cURL.

cd /usr/src/redhat

The latest released version of cURL is always available from http://curl.haxx.se. They are very proactive in supporting the package, issuing updates, and fixing any security related bugs that are found.

If you are going to locally compile and install software on a machine, I highly recommend creating an account at freshmeat.net and subscribing to get announcements for updates to that project. This includes security fixes. I would also recommend subscribing to the CentOS or RHEL announcement mailing list.

First, we have packages such as PHP that depend upon the libcurl version 3 ABI, so we need to arrange to have both the old version, and the new version installed. Start by:

cd SPECS

Then, either get the spec files from compat-curl-local.spec and curl-local.spec, saving them into the SPECS directory or create them afther this fashion:

sudo cp curl.spec compat-curl-local.spec

Then,

1. Edit compat-curl-local.spec:
2. Change the Name: to compat-curl
3. Append .local.1 to the Release: line
4. Change the Source: line to reference curl- instead of %{name}.
5. Add -n curl-%{version} to the end of the %setup line.
6. Save it.

Then,

sudo rpmbuild -ba compat-curl-local.spec

Running:

sudo wget -P ../SOURCES http://curl.haxx.se/download/curl-7.16.0.tar.bz2

will place the latest (as of this writing) released source into the ../SOURCES subdirectory.

sudo cp curl.spec curl-local.spec
sudo <your-favorite-editor> curl-local.spec

Change Version: to 7.16.0
Change Release: string to 0.rhel4.local.1
Add a Prefix: /usr line near the top of the file. This makes the package relocatable.
Delete all patches except #1 and renumber it to 0.
After %setup remove all %patch lines greater than 0.
Under %files add:

%{_libdir}/pkgconfig/libcurl.pc

This will make sure that any version 7.16.0 that is released by Red Hat will replace our local one. Yet, it will also guarantee that no 7.x versions less than that will overwrite our local one.

Then,

sudo rpmbuild -ba curl-local.spec

When this is done, it's time to install:

sudo rpm --force -Uhv ../RPMS/i386/compat-curl-7.*.local.1.i386.rpm
sudo rpm --force -Uhv ../RPMS/i386/compat-curl-devel-7.*.local.1.i386.rpm
sudo rpm -e curl curl-devel
sudo rpm -Uhv --prefix=/usr/local ../RPMS/i386/curl-7.16.0-0.rhel4.local.1.i386.rpm
sudo rpm -Uhv --prefix=/usr/local ../RPMS/i386/curl-devel-7.16.0-0.rhel4.local.1.i386.rpm

We first force the installation of our new compat- RPMs, because they will conflict with the originals. (The supply the same files under a different name. The name change is necessary so that our newer version does not result in an upgrade removing the old ABI version 3 files entirely.) Once those are in place we remove (erase) the original packages to make way for the new ones. Then we load our new local versions prefixing them into the /usr/local hierarchy to avoid interfering with the old files.

Once the updated cURL is in place we need the OpenGL and JPEG development libraries.

sudo up2date xorg-x11-devel freeglut-devel libjpeg-devel

Another fairly large component that we need are the wxWidgets. We get these from building a spec file that is part of the RPMforge project. I could not find the corresponding binary RPM for RHEL4.

cd /usr/src/redhat/SPECS
sudo wget http://svn.rpmforge.net/svn/branches/rpms/matthias/wxGTK/wxGTK.spec
sudo wget -P ../SOURCES http://downloads.sourceforge.net/wxwindows/wxGTK-2.6.2.tar.bz2
sudo up2date gtk2-devel SDL-devel libgnomeprintui22-devel libpng-devel libtiff-devel
sudo rpmbuild -ba --define 'dist el4' wxGTK.spec
cd ../RPMS/<architecture>
sudo rpm -Uhv wxGTK-2.6.* wxGTK-gl-2.6* wxGTK-devel-2.6.*

For most, <architecture> is going to be i386.

cd ~/src/boinc
./configure  --enable-unicode
make

I have to commend the guys working on BOINC, especially Rom Walton. Prior to revision 1.20 of clientgui/SkinManager.cpp this would blow up compiling for UNICODE due to some character width mismatch errors. I sent in a patch and the very next day it was already in their CVS repository.

That's like a breath of fresh air in FOSS development. Too many projects make it difficult to get your patches accepted into the mainstream. It shouldn't be that way.

Installing the BOINC Server Software

This explains the process of installing the actual BOINC server software on a machine and setting up a skeleton project.

Development Tools

If you have previously followed the guide on installing CentOS-4 for a BOINC Server, you will need to add the development tools required to compile BOINC. This may be done by going to Applications-->System Settings-->Add/Remove Applications. Then, scroll down, check Development Tools and click Update. You may be prompted to insert a CentOS CD, insert either the CD (or DVD, if you have it) and continue on.

After installing the development tools, it is a good idea to apply any available updates. Right-click on the Update Notification Icon and select Check for updates. If there are updates, apply all of them even the ones that are normally flagged to be skipped.

Accounts and Permissions

Since it is really too long for ablog post, read the rest of this document online at Google Documents and Spreadsheets.

Running a BOINC Server on SELinux

This is a shortened excerpt of one version of a much longer document. It has enough use on its own than I am posting it here separately.

In my previous post on Creating Users and Groups for a BOINC Server, I explained how to create the boinc user and group. Here I explain how to grant the appropriate permissions to allow a project to operate without disabling or crippling SELinux.

After you have used make_project to create the basic files for a project, you need to change some of the permissions.

Assuming you have done as shown on The make_project script page and that you created a cplan project in the projects directory inside of your home directory as explained there, you will need to grant read permission to your home directory. You can do this with

$ sudo chmod 755 ~

That will allow the Apache webserver to access files hosted in your home directory. Then we need to grant the boinc group access to the new files in the project.

$ sudo chgrp -R boinc ~/projects/cplan/html

Without SELinux running this would be sufficient to allow access to the project. However, if you have SELinux enabled, a few more steps are necessary. If you loaded your project into one of the system web server directories instead of creating them within a user's directory, you should replace httpd_user_content_t with httpd_sys_content_t in the following instructions.

$ sudo chcon -R -h -t httpd_user_content_t ~/projects/cplan/html
$ sudo chcon -h -t httpd_user_content_t ~/projects/cplan
$ sudo chcon -h -t httpd_user_content_t ~/projects/cplan/config.xml
$ sudo chcon -R -h -t httpd_user_script_exec_t ~/projects/cplan/cgi-bin

The chcon command changes the SELinux context that is assigned to an object. In this case were are changing the type of the object to indicate that it is for use by httpd, but resides in a user's directory. The first command recursively gives permission to the html directory. The second gives permission to be able to see config.xml in the directory and the third grants access to the configuration file itself. The last line indicates that scripts should be allowed to run in the cgi-bin directory.

You still have the details of writing your project and configuring Apache to serve it, but hopefully this post has helped with any SELinux issues you may have had.

Creating Users and Groups for a BOINC Server

The BOINC Groups and permissions page covers most of what you need to know in order to set this up. But, I present this from the perspective of running a CentOS-4 server using graphical tools and performing these operations before the project is actually created.

Run Applications-->System Settings-->Users and Groups. Start by adding a user and group, both named "boinc". The following steps will create both at one time.

1. Click Add User.
2. Enter a user name, I used "boinc".
3. Enter a "Full Name", try "BOINC Server".
4. Enter a password and confirm it.
5. Set Login Shell to /sbin/nologin.
6. Uncheck Create home directory.
   
7. Check Create a private group for the user.
8. Click OK.
   

Now lets add the "apache" user to the "boinc" group.

1. Click the Groups tab.
2. Double-click the "boinc" group.
3. Click the Group Users tab.
4. Check the box next to "apache".
5. Click OK.

That's all there is to it. Now you have a boinc user, a boinc group and apache has access to all files that belong to the boinc group.

Linux BOINC Server CentOS-4 Installation

This explains the process that was used to install CentOS 4 onto the workstation that is used as a BOINC server for SciLINC development. There may be subtle differences in the installation as described here and the installation as it may be seen if run again later. This may be due to differences in a pristine install and a re-install, it may also be due to the slightly modified installation procedure that was required to obtain the screen shots for this document. The most up to date version of this document is published online.

The original plan was to install Fedora Core because it is sponsored by Red Hat and ultimately its content feeds into the next official Red Hat Enterprise Linux, RHEL. The (possibly incomplete) document covering that is "Linux BOINC Server Fedora Core 6 Installation." These plans were changed for two reasons. One, the rate of change on the recently released Fedora Core 6 is too high to make it worth tracking for a test server deployment. And two, we discovered CentOS 4, the Community ENTerprise Operating System. This is a distribution that is built directly from the publicly available source RPMs for RHEL 4. The project's web site describes it this way:

CentOS is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor. CentOS conforms fully with the upstream vendors [sic] redistribution policy and aims to be 100% binary compatible. (CentOS mainly changes packages to remove upstream vendor branding and artwork.) CentOS is free.

In essence CentOS is a synthesis of Red Hat Enterprise Linux WS, ES and AS. The administrator is free to pick and choose from among the components offered by these various versions. In that sense it is suitable for desktop, workstation, and server usage.

Since it is really too long for a blog post, read the rest of this document online at Google Documents and Spreadsheets.

Linux BOINC Server Fedora Core 6 Installation

This document explains the process that was used to install Fedora Core 6, FC6, onto the workstation that is used as a BOINC server for SciLINC development. FC6 is also referred to by the code name, "Zod".

...

Fedora Core actually has two separate meanings. The first is in reference to the operating system itself. The second is a reference to the Fedora Core repository. The Core repository contains a set of relatively tightly managed and non-overlapping applications that may be used to configure a server, a knowledge worker desktop or a developer workstation.

Where Fedora Core has overlapping functionality is usually a matter of widely accepted "standard" packages that provide the same functionality. The vim and emacs editors are examples of this. Also, Fedora supports both the GNOME and KDE desktops. Each desktop may have some programs with similar purposes that are better integrated into its environment. The firefox and konqueror web browsers would fall into this category.

Since it is really too long for a blog post, read the rest of this document online at Google Documents and Spreadsheets.

Configuring Xen Domain 0 Memory Allocation at Boot Time

According to the GRUB Configuration section of the Xen User Guide the memory allocation of the host operating system may be set in the grub.conf file as follows:

title Xen 3.0 / XenLinux 2.6
kernel /boot/xen-3.0.gz dom0_mem=262144
module /boot/vmlinuz-2.6-xen0 root=/dev/sda4 ro console=tty0

"The kernel line tells GRUB where to find Xen itself and what boot parameters should be passed to it (in this case, setting the domain 0 memory allocation in kilobytes and the settings for the serial port)."

Setting up Completely Passwordless Bi-Directional SSH

If you have two machines and you want to be able to ssh from "local" to "remote" without using a password at all, do the following, where $local is a command-prompt on the local machine and $remote is a prompt on the remote machine. Replace the words REMOTE and LOCAL with the actual network names of the machines:

$local ssh-keygen -t dsa
$local scp ~/.ssh/id_dsa.pub REMOTE:.
$remote cat ~/id_dsa.pub >>~/.ssh/authorized_keys
$remote ssh-keygen -t dsa
$local scp REMOTE:.ssh/id_dsa.pub .
$local cat ~/id_dsa.pub >>~/.ssh/authorized_keys

At this point you should be able to:

$local ssh REMOTE

without a password, you may be prompted to accept the fingerprint of the other machine. Do so. Then in the remote shell:

$remote ssh LOCAL

This may also generate a fingerprint-acceptance message. Just accept it.

You can also delete the id_dsa.pub files in the login directory of each machine. Do not copy the id_dsa (without the .pub extension) this is your private key and the connection is only as secure as that file. If someone has the file, they can impersonate you. This is also why some people recommend supplying a passphrase when running ssh-keygen and then using ssh-agent provide similar behavior, but with the need to enter your passphrase once per session.

Controlling Two Computers with One Keyboard and Mouse

The x2x program allows the keyboard and mouse on one X display to be used to control another X display. It also shares X clipboards between the displays. Basically this allows you to have two machines sitting side-by-side and use a single keyboard an mouse on them.

I choose to use ssh tunneling as the authentication mechanism between them. The first step is to setup passwordless ssh in both directions between the two machines. Then, I copied one of the quick-launch buttons on the GNOME menu bar to the menu bar by control-dragging it and edited the copy to have the following settings:

Type:

Application

Name:

x2x

Command:

ssh OTHER_MACHINE_NAME DISPLAY=:0.0 ssh -X THIS_MACHINE_NAME x2x -from :0 -east&

Comment:

Control the other display with this mouse and keyboard

Clicking the launcher will then run x2x and allow the mouse and keyboard to control the other machine. I used the -east command-line switch because my "other" machine sets to the right of "this" machine. So when I move the mouse off of the "this" screen to the east, right, it appears on the "other" screen and vice-versa.

UPDATE: If this is run more than once, there will be multiple instances of ssh running on the remote machine. This can happen if the connection is lost for some reason and then reestablished. (Changing the remote machines firewall settings will do this.)

A simple workaround is to kill or killall the ssh session(s) on the remote machine and then rerun this again. Before doing a killall ssh on remote, manually close any local ssh connections to the remote machine to avoid losing any unsaved data.

BOINC Stable Tag is Only for the Client

At last, David Anderson clarifies the "stable" tag for BOINC's CVS repository:

The "stable" tag applies only to the core client and Manager, NOT to the server software, API, PHP, etc. If you check out server software with the "stable" tag you'll get an old version, with lots of bugs. The most reliable server and API software is always the current version. Sorry we didn't make this clear before; I changed http://boinc.berkeley.edu/source_code.php to say this.

[boinc_dev] "stable" tag applies ONLY to client software (core client and Manager)

HP dc5100 Audio Problems in Linux

After installing Fedora Core 6 Linux on an HP dc5100 SFF (small form factor) machine with an "Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)", I had a number of problems.

• The system beep always went through the on-board speaker.
• Mute did not work.
• The head phone jack did not disable the sound playing on the built-in speaker.

Headphone Jack

Getting the head phone jack working was the easiest. Although finding out how to do this was not.

1. Open Volume Control, this is found under System|Preferences in GNOME.
2. Select Edit|Preferences.
   
3. Check the "Headphone Jack Sense" button.
   
4. While you're there you might as well check "Line Jack Sense" button as well.

This will add some entries to the "Switches" tab, or add the tab if it did not already exist.

Next

• Check the "Headphone Jack Sense" and "Line Jack Sense" buttons on the "Switches" tab.

This will enable the detection of a headset or line device and automatically disable the built in speaker.

System Beep

It also turned out to be easy to disable the system beep.

1. Open the Sound Preferences applet under System|Preferences|Sound.
   
2. Select the "System Beep" tab.
   
3. Uncheck "Enable system beep".
   
4. Optionally check "Visual system beep" and "Flash window titlebar" or "Flash entire screen".

I prefer entire screen. That way if I am on a different virtual desktop, I still see the flash. Because I have "Desktop Effects" enabled I do not get a flash, I get a reverse flash. The entire screen dims.

The Use of BOINC Upload and Download Servers

Rom Walton has a good little post on the problems of using a single server for a BOINC project and the "proper" usage of upload and download servers to stem the tide of requestn being made on the database. Here is a sample:

I believe that the file upload and download servers are used as dams most of the time to keep the rest of the system from keeling over, for instance if the those servers were not keeping the hoards of machines at bay and everything was gated on the database then after an outage nobody would be able to use the website, or read/post in the forums.

ROMWORLD - FOLLOW-UP: The evils of 'Returning Results Immediately'

It's not too long and worth reading.