I have an iPhone. I am not afraid to say this: the N900 smashes it.  Here's just a quick example -- in the form of an interaction demo video -- of what the N900 can do:

For a blow-by-blow feature comparison against the 3GS, go here.

Edit: and the promo video is to die for!

User Moo__ in the #plone channel at Freenode alerted me to the solution.  What happens is this:

1. You uninstall a product.
2. Plone detects this, and to prevent malfunctions, any of the content types in the product get registered in a secret exclusion list.  Whenever the navigation is shown, this list is consulted so as to not make Plone fail because the type of the uninstalled objects can't be found.
3. You install the product again.
4. Items remain in this secret list, and do not get removed no matter how hard you tinker with the Navigation control panel.

The solution is to remove the excluded content types in the portal_properties folder of your Zope Management Interface:

1. Open your ZMI.
2. Browse to portal_properties within your Plone site.
3. Go to the Properties tab and look for the list parentMetaTypesNotToQuery.
4. Remove the content types that got added there.

That's it!  Now, why isn't this documented somewhere?

In the Fedora 11 flavor of LTSP, you can set a default language and desktop environment for the users' session by editing the file /etc/ltsp/ldm-global-dmrc.  This is "documented" behavior; Warren Togami kindly wrote a one-line blurb about it in the RPM change log.  A Busey clap for their dedication to not documenting their "configuration" options publicly:

* Thu Dec 11 2008 Warren Togami <wtogami@redhat.com> - 2.0.22-1
  - Show good names in Session menu
  - Use and write to user .dmrc
    It is now possible to set a default session that is not GNOME.
    Set LDM_GLOBAL_DMRC=/etc/ltsp/ldm-global-dmrc in lts.conf
      and specify your choice in /etc/ltsp/ldm-global-dmrc on the server.

I wanted to understand how a file in the server filesystem, not exported via NFS to the client, gets to affect the configuration of the terminal itself.

My first look was inside the ldminfod RPM package -- a companion package to the LDM greeter that goes in the terminal and serves some information the terminal needs to display to the user on the greeter.  Since that file is distributed inside the ldminfod RPM package, that was the logical step, right?  But said file does not appear to be read by the ldminfod on-demand xinetd daemon, so I was left stumped and wondering where and how it's read.

In case you wanted to know, it's read by the terminal client itself upon LDM login, when it's time to set up the desktop session, in the script /opt/ltsp/i386/usr/share/ldm/rc.d/X50-dmrc-processing.

The way that the script works is rather convoluted (I would have expected the LDM info daemon to give out the information in the file to the LDM greeter).  The script specified in /var/lib/tftpboot/ltsp/i386/lts.conf in the variable LDM_GLOBAL_DMRC (which defaults to the file name in the first paragraph) is copied via scp to a temporary location into the terminal memory, along with the .dmrc of the user.  Those files are then merged, and finally a decision on desktop environment and language is made upon the merged content of those files.

How did I discover this?  Thanks to the audit subsystem.  I set a watch on the file of interest, and watched it be fetched by the terminal when I logged on to it.

I admit: this scp shenanigan is rather ingenious.  However, unless having a user .dmrc is so important, I think it's overengineering; in my humble opinion, the LDM info daemon should export that information instead; after all, it's just security-insensitive defaults.

In fact, this whole LDM_GLOBAL_DMRC problem could be easily bypassed if LTSP simply obeyed the global terminal server configuration.  I don't see why I should need to specify a default language in a separate file, when that default language has already been specified in the system configuration via the LANG environment variable.  I also do not see why I should need to specify a default desktop environment, when that information has already been specified via distribution methods -- just run whatever gets me the session that I use when I logon locally and that's it!

For example, in Fedora, you just launch the Xsession script with the name of the desktop session that you want to run.  Which is, all in all, what the terminal ends up remoting via SSH on the server, so the session piggybacks to the client display.  The whole thing could be done by serving a "default" session line in the LDM info daemon output before all the lines of the other sessions, and serving the default language as the first line as well.  Then LDM can use the first choice of language as the default language, and the default session gets to be the default system session.  It would all work integrated with the Fedora X Window System client startup subsystem.

These instructions should work in Fedora 11, and probably Ubuntu as well.  You will probably lose the ability to pair up Bluetooth audo gear, like lose  autotunneling capabilities to networked audio devices through Zeroconf, but hey, you get what you pay for ;-)  I also hear there are security considerations stemming from the fact that users allowed access to PulseAudio may break something in it, but for home use it is probably going to be just fine.

Starting up PulseAudio on boot

Put this text in the file /etc/event.d/pulseaudio:

start on runlevel [2345]
stop on runlevel [016]

exec pulseaudio --system --realtime --log-target=syslog

respawn

description "PulseAudio system server"

pre-start script
	for a in `seq 60` ; do
		sleep 1
		killall -0 hald && killall -0 dbus-daemon && break
	done
end script

post-start script
	( sleep 1 ; paplay /usr/share/sounds/login.wav ) &
end script

The text in italics is optional -- either don't include it, or replace it with something that will play a sound file confirming that PulseAudio has started.

As you can see, this is a straightforward script that waits until hald and D-Bus are active before starting PulseAudio (both are needed to get the hardware list), and then starts it up.

Setting up default client settings

Add these lines in the file /etc/pulse/client.conf:

default-server = /var/run/pulse/native
autospawn = no

Allowing users access to the audio service

Add every user that is allowed to use the audio device to the group pulse-access.

Allowing PulseAudio access to Bluetooth

In order to pair up with Bluetooth devices, you need to add the following text to the file /etc/dbus-1/system.d/pulse.conf:

<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
	<policy user="root">
		<allow own="org.pulseaudio.Server"/>
                <allow send_destination="org.bluez"/>
                <allow send_interface="org.bluez.Manager"/>
	</policy>
	<policy user="pulse">
		<allow own="org.pulseaudio.Server"/>
                <allow send_destination="org.bluez"/>
                <allow send_interface="org.bluez.Manager"/>
	</policy>
	<policy context="default">
                <deny own="org.pulseaudio.Server"/>
                <deny send_destination="org.bluez"/>
                <deny send_interface="org.bluez.Manager"/>
        </policy>
</busconfig>

Preventing PulseAudio from starting on graphical logon

A pesky program tries to start PulseAudio every time you log on, which may cause conflicts.  Prevent this by running the following command as root:

chmod -x /usr/bin/start-pulseaudio-x11

You may need to run this command whenever you upgrade your system and, in the course of the upgrade, PulseAudio itself is upgraded.

I've submitted a patch for PulseAudio that will render this step unnecessary soon, if it's accepted. It's logged as ticket 606 in the PulseAudio bug tracker.

That's it!

Close your session and reboot your machine.  PulseAudio should start on boot now, and all applications will be able to play sound, whether they are console or graphical applications, and without the need to actually log on beforehand.  In addition, if PulseAudio dies, it will be automatically restarted and you will hear a confirmatory sound (provided you actually put the italicized text with a command to play audio).

The latest release of ALSA (Advanced Linux Sound Architecture) ships a sound virtualization plugin that uses (to the extent that my hearing can tell) HRTF to virtualize multichannel sound.  This plugin is called vdownmix and it has the ability to mix down both quadraphonic and 5.1 surround sound so they sound more "spatial" with headphones.

Here, we'll learn how to set that up with Fedora 11 -- with the advantage that this solution works with PulseAudio just fine.  Users of other distributions may adapt these instructions to their packaging and configuration.  We assume, of course, that you don't have a home theater installed in your system -- rather, you only have a set of headphones plugged into your stereo or sound card.

Step 1: install the requisite software

Launch your software installer tool and look for a package named alsa-plugins-vdownmix.  Install it.  For those of you who like to use the command line:

yum install -y alsa-plugins-vdownmix

Step 2: set the software up

By default, this plugin comes with a neutered configuration that you have to explicitly request in your application.  This is silly.  The way we're going to set it up is rather simple: we're going to tell ALSA to disregard the standard multichannel outputs in the cards with this short ALSA configuration script:

pcm.!surround51 {
        @args [ CARD DEV ]
        @args.CARD {
                type string
                default {
                        @func getenv
                        vars [
                                ALSA_SURROUND51_CARD
                                ALSA_PCM_CARD
                                ALSA_CARD
                        ]
                        default {
                                @func refer
                                name defaults.pcm.surround51.card
                        }
                }
        }
        @args.DEV {
                type integer
                default {
                        @func igetenv
                        vars [
                                ALSA_SURROUND51_DEVICE
                        ]
                        default {
                                @func refer
                                name defaults.pcm.surround51.device
                        }
                }
        }
        type vdownmix
        slave.pcm {
                @func refer
                name {
                        @func concat
                        strings [
                                "cards."
                                {
                                        @func card_driver
                                        card $CARD
                                }
                                ".pcm.surround51." $DEV ":CARD=" $CARD
                        ]
                }
        }
        hint {
                description "Downmix to stereo 5.1 Surround output to Front, Center, Rear and Subwoofer speakers"
                device $DEV
        }
}

pcm.!surround40 {
        @args [ CARD DEV ]
        @args.CARD {
                type string
                default {
                        @func getenv
                        vars [
                                ALSA_SURROUND51_CARD
                                ALSA_PCM_CARD
                                ALSA_CARD
                        ]
                        default {
                                @func refer
                                name defaults.pcm.surround40.card
                        }
                }
        }
        @args.DEV {
                type integer
                default {
                        @func igetenv
                        vars [
                                ALSA_SURROUND51_DEVICE
                        ]
                        default {
                                @func refer
                                name defaults.pcm.surround40.device
                        }
                }
        }
        type vdownmix
        slave.pcm {
                @func refer
                name {
                        @func concat
                        strings [
                                "cards."
                                {
                                        @func card_driver
                                        card $CARD
                                }
                                ".pcm.surround51." $DEV ":CARD=" $CARD
                        ]
                }
        }
        hint {
                description "Downmix to stereo 4.0 Surround output to Front, Center, Rear and Subwoofer speakers"
                device $DEV
        }
}

 Save the contents of this script in the file /etc/alsa/pcm/vdownmix.conf (do this as root, obviously). Now we're going to tell ALSA to pick this configuration file up, by editing the file /etc/asound.conf. The original file should look like this:

#
# Place your global alsa-lib configuration here...
#

@hooks [
        {
                func load
                files [
                        "/etc/alsa/pulse-default.conf"
                ]
                errors false
        }
]

Add a new line as per this example:

#
# Place your global alsa-lib configuration here...
#

@hooks [
        {
                func load
                files [
                        "/etc/alsa/pcm/vdownmix.conf"
                        "/etc/alsa/pulse-default.conf"
                ]
                errors false
        }
]

You're finished with the setup. You can verify that the configuration has been picked up properly by running the command aplay -L on a console -- you should see the description of the surround51 definition begin with Downmix....

And that's it.  Your system is now properly set up to virtualize surround sound to your headphones. 

Now, you should know this configuration is not applied by default: PulseAudio still needs to be informed when you intend to play multichannel audio, otherwise PulseAudio performs non-spatialized mixdown of your multichannel audio.  Here's how you prevent that from happening.

How to activate and deactivate virtualization on the fly

Whenever you want to listen to multichannel audio on your headphones, you will want to tell PulseAudio to output multichannel audio on your gear.  You do this by:

1. Opening the PulseAudio Volume Control
2. Going to the Configuration tab (the last tab in the application)
3. Selecting Output Analog 5.1 on the drop-down of your sound card

This lets PulseAudio know that you have a "surround-sound capable" sound card, which makes PulseAudio relay each sound channel straight into the ALSA downmixer, which in turn mixes each channel down to the correct virtual position.

Finally: when you go back to your speakers or to listening stereo music, select Output Analog Stereo again, and the spatialization will be disabled.

And that's it!

What NEPOMUK is about

The stable KDE 4.2 release is a phenomenal work of art that lets every application share and modify metadata using an unified ontology, all mediated through the great D-Bus protocol.  This is known as NEPOMUK and the way it works is as follows:

• There is a daemon that starts up when your desktop environment starts.  This daemon (the NEPOMUK daemon) starts a bunch of little services -- storage backends, query server, indexer (known as Strigi).
• This daemon latches onto the D-Bus session associated with your desktop environment.  It sits there listening to queries -- they can be questions in SPARQL, or method calls to get/set specific pieces of metadata.
• The daemon mediates the job of searching the storage backends and manipulating the data.
• Applications query it through D-Bus using a standardized interface that works for full-text-search queries and other sorts of metadata-related queries.
  

This provides a central location which applications can access the metadata, either directly through D-Bus or abstracted through the available application libraries.  It's a rather powerful idea, since applications no longer need to link directly to metadata libraries or use ad-hoc methods like stat calls to piece together metadata for files in your computer.

Couple this with a KIO slave called nepomuksearch:, and you have live searches or data feeds for your applications.  That's right, you can put a list of files tagged TO-DO or a list of files with the word rabbit right on your desktop.

Or at least you ought to be able to.

The problem

The problem is that NEPOMUK simply does not work in KDE 4.2 as it was supposed to work.

The database technology used in NEPOMUK is called Soprano.  It was chosen because it has several pluggable backends (sort of on-disk formats).  The problem with Soprano is that its default backend (the Redland one) does not support certain query methods on its database, methods that NEPOMUK requires.  So the NEPOMUK developers decided to use the Sesame2 backend, which is feature-complete and fast enough for their needs.

One problem, though: Sesame2 is a Java library that almost nobody in the distribution world has bothered to package for almost no distributions.  And with good reason too -- most distributions require a compilation from source, while the Sesame2 backend is being distributed as a JAR file instead.

The result is clear:  nepomuksearch: (the whole point behind NEPOMUK) does not work in any distribution except perhaps for Mandriva.

And, in that manner, the NEPOMUK developers royally tied themselves up into a Gordian Knot.

The fix

...is not that simple.

The quick fix is to package the Sesame2 backend.  Rdieter has done this himself, and I have rebuilt the packages so they are installable.  Here is a package for Fedora 11, derived from an OpenSUSE package.  Here you go:

• 64-bit Fedora 11 RPM

But distributions do not want to go there, namely because distributing KDE in this manner would introduce a dependency to Java.  That's about two hundred megabytes to ship just one feature.  So what they're doing, long-term, is write a Soprano C++ backend (Virtuoso) to replace the need for the Sesame2 backend.  There have been talks about merging the Akonadi and NEPOMUK databases too -- and, frankly, it is quite moronic to have a SPARQL daemon and a MySQL daemon running per desktop session anyway, and it's also quite moronic to have to deal with data format impedance mismatches between client applications, so these talks do make quite a lot of sense.

On account of the original eye chart at Joe Stewart's site being down, I've taken the liberty of creating this eye chart in replacement.

How to interpret

Explanation

Conficker (aka Downadup, Kido) is known to block access to over 100 anti-virus and security websites.

If you are blocked from loading the remote images in the first row of the top table above (AV/security sites) but not blocked from loading the remote images in the second row (websites of alternative operating systems) then your Windows PC may be infected by Conficker (or some other malicious software).

If you can see all six images in both rows of the top table -- or at least the top ones, as the bottom ones seem to be DDoSed at the time -- you are either not infected by Conficker, or you may be using a proxy server, in which case you will not be able to use this test to make an accurate determination, since Conficker will be unable to block you from viewing the AV/security sites.

Detecting Conficker on your network through a port scanner

Net-Security suggests that, to scan for Conficker, you can a command such as:

 nmap -PN -T4 -p139,445 -n -v --script=smb-check-vulns --script-args safe=1 [targetnetworks]

Credits

F-Secure and the F-Secure Logo are trademarks of F-Secure Corporation.
SecureWorks and the SecureWorks Logo are registered trademarks of SecureWorks Inc.
Trend Micro and the T-Ball logo are trademarks or registered trademarks of Trend Micro Inc.
The Conficker Eye Chart is a concept by Joe Stewart. This derivative work was set up to help Joe Stewart's efforts.
Copyleft 2009.

If this machine survives the current hundreds-of-hits per second traffic storm, consider GPLHost for your next Web service venture (I'm using a 768 MB RAM VPS).  And, for your next consulting need, consider me.  Back in the day, I used WordPress; today, I use Plone.  So far, I seem to know what I'm doing to serve big traffic, and I hope you'll let me do that for you too.

I've finished upgrading my workstation to Fedora 11 beta.  Since Fedora 10, Amarok 2 has been shipping in lieu of Amarok 1, but since the import tool in Amarok 2 was unusable, I had remained with Amarok 1 instead.  This time around, I decided to take Amarok 2 (specifically, 2.0.2) for a spin. So, I diligently backed up my KDE config and application data for Amarok 1, and nuked it from the original places.

Before anybody accuses me of using a beta for this rant, bear in mind that the rest of the KDE 4 applications in this system are functioning correctly.  Of course, if you want to skip the rant, click here for the solution.

The launch -- failure #1

I launched Amarok 2.

No cookie.  It didn't even launch -- it ended with a SIGSEGV after an St9_bad_alloc C++ exception.  What could be going on?

Turns out it was my security configuration.  I have my system set up to never grant more than 1 GB of RAM to any application, using the ulimit command; and for good reason too, since Kopete every once in a while decides to run away with all system memory and freeze my machine.

But this only lets me ask the question: why would a music player need to allocate in excess of one gigabyte of RAM just to start up?  I am appalled at this.  It makes me want to go back to MS-DOS .OVL files as a memory management strategy.

Well, never mind, let's increase that to 2 GB and try again. 

The import -- failure #2

This time around, Amarok launches, and presents me with a collection configuration screen.  I check the folders I had checked in the old Amarok 1 configuration, then click Import.  The importer appears -- I feed it my database information and I hit Next.  It starts importing.  This import function is vital to me, since my entire music collection habit and mobile music experience is powered by Amarok 1 statistics and other metadata like tags.

The importer takes 5 minutes to list all of my music, spitting quite a few TagLib errors on the console.  And then... it just spins.  It spins using 100% of one CPU core for twenty minutes.  I am about to terminate Amarok 2... and then the Finish button on the importer lights up.  I hit Finish.  Remember, I'm now half an hour trying to get this junk to work, and so far nothing.

Now, like any regular person, I'd expect the importer to have succeeded.  Surprise, surprise, the collection pane is empty.  Not a single song has been imported!

Drag and drop, Ogg edition -- failure #3

So, okay, maybe the statistics were imported but not the collection itself, which may need a rescan, right?

Let's move on to the file browser panel.  In Amarok 1, I had a series of bookmarks pointing to commonly accessed directories.  No such luck in Amarok 2!

That's okay, I know my way around my collection, so let's browse to an Ace of Base folder which contains several tracks I listen frequently.  Let's drag the song Beautiful life.ogg to the playlist... wait... why isn't my favorite Ace of Base song showing up in the pane?

What?  Only MP3 files are showing up!  All the Ogg files are gone!

I launch Dolphin and browse to the folder and, sure enough, the Ogg files are there!  Why would Amarok not show me my Ogg files?

OK so let's try and drag the file in question from Dolphin to Amarok's playlist... nice, the drop target shows a black bar where it's going to be inserted.  Let's release the mouse button... nothing!  Amarok plainly refuses to accept Ogg files dropped into it!

By now I'm furious.

OK, maybe at least Amarok will let me drop an MP3 file.  So I try with Angel eyes.mp3.  Sure enough, the black bar appears, and this time the file gets actually added...

Metadata fail -- failure #4

...only there's something funny about the playlist.  It doesn't show me any info except for the file name.  No album, no artist, no track, no number, no nothing!

I right-click the file and select the option to edit tags (which shows me a number of things, not just the tags).  Whaddya know?  Amarok thinks the file is zero bytes long and the only things that it shows correctly are:

1. The path to the file
2. The number of plays that song has seen

Aha.  Well, will it play the song?  Let's double-click it... and bingo, sound!

OK, so let's go fix the collection thing.  Let's request a collection update.  I do that... and boom, segfault again.  Despite that taking place, there are several amarokcollectionscanner processes running amok on my system and slowing it down to a nearly unusable crawl.

So, in the words of a friend wise beyond his years, a la verga los pastores, se acabó la Navidad.  killall -9 amarokcollectionscanner && rpm -e amarok.

The recap

1. Amarok 2 refuses to load when limited to less than one gigabyte of RAM.
2. The importer doesn't work.
3. You can't play Ogg files.
4. If you so much as sneeze, it dies and leaves mongrels that make your system unusable.

Let me remind you, the Amarok developers have the audacity to call this the second bug fix release of the second version.

If I, a Linux developer with 12 years of experience who knows his way around UNIX like the back of his hand, can't get this ersatz "music player", with elementarily dumb oversights, mistakenly shipped by the Fedora release managers as stable software, what can a regular user who just wants to play music have in the way of hope?

Now I go to the IRC channel in Freenode where the Amarok developers dwell, and voice my complaints.  They tell me to stop complaining and file bugs.  What for?  It isn't the first bug I have filed about Amarok, and bugs take months or even years to be sorted out.

This on top of a number of regressions I discovered months ago that I'm pretty sure aren't fixed yet:

1. Playlist import didn't work.  Especially if one of your playlists had a track entry that had been moved and is no longer in the collection.  In fact, you cannot even put a song outside your collection in a playlist, since the database doesn't store paths but rather IDs from songs in the collection.  So you had to manually fix all of your playlists in order to prevent data loss.  Fortunately, I scripted this task so I did do it months ago in the good faith that I would be able to use Amarok 2 some day.
   
2. Any statistics (ratings, labels, play counts, scores) for songs outside your collection is lost.  Lost.  If you have been listening to songs outside your collection folder, expect to say goodbye to all track metadata applied to these tracks.  The reason it is lost is, again, because Amarok does who knows what with the imported statistics data that used to show (not anymore!  so you can say this is a bug atop a bug!)  on the playlist when a non-collection track was first added, but gets utterly reset when the non-collection track finishes playing.
   
3. Intelligent playlists weren't imported either.  If you were feeding your iPod using one of these, bye bye.
4. There is no way to mass-edit tag information right from the playlist, something I very much frequently did when using Amarok 1.
   

Systemic failure.  That's all I can say.  A group of developers set out to write a music player that has less features than the old generation one, and has more bugs than an ant colony.  Then they code code code without any meaningful testing.  Then they ship it implying it is stable software under the banner of "we need more testers", but with no working migration path from the old version of the software, and double the hardware requirements.  Good-willed people in charge of distributing good software get duped into shipping this bag of FAIL, updating perfectly-working software already-deployed into millions of users' workstations.  And when the users complain, some people have the gall to say that we are rude.

Lenin would be proud.

If you want to accuse me of being an ungrateful son of a bitch, can that accusation.  Not only is my criticism valid in a world where you're validated by how good the results of your work is -- regardless of end-user price -- I have actually gone out of my way to provide a solution for you and help you avoid these disasters.  Scroll down.

The solution

Well, since I cannot live without Amarok 1, I decided to built it for Fedora 11.  I had to patch a number of deficiencies in the Amarok 1 source code (namely, the use of obsolete libraries and C include practices) with patches I found around the globe for Gentoo and other distributions.  It wasn't that hard, but it wasn't easy either.  The RPM packages ready to install are on The missing RPMs repository (which I do not recommend you actually add to your Yum configuration if you're using Fedora 11) and you can get them here directly:

1. Amarok 1.4.10 for Fedora 11 64 bits.
2. Amarok 1.4.10 source package to rebuild for Fedora 11 or Fedora 10 (32 or 64 bits).
   

You install them by downloading them and then using the rpm -Uvh --oldpackage command, so this package actually replaces the newer Amarok package.  After doing that, you're strongly encouraged to lock Amarok from being upgraded with yum by putting a line exclude=amarok in your /etc/yum.conf file.

Tip: if you use the Smart package manager, you can install the package using point-and-click, and it will automatically erase the newer version for you, no need for funny commands or anything.  After installing the package, lock the version of the newly installed Amarok package so it won't get upgraded in future upgrade cycles.

In Apacheland, if you access a folder, Apache automatically redirects you to a new URL ending in a slash (/).  Not so with Plone or Zope -- any resource can or cannot have a slash at the end, which is not nice for neither Web caches nor Google Analytics -- it groups content based on the slash, so the same resource linked twice, once with a slash and once without a slash, those are two separate pages.

The fix

So, how do we fix this?  We fix this with the following Varnish configuration stanza:

sub vcl_recv {
    # Redirect slash-ended requests
    if (req.url != "/" && req.url ~ "/$") {
            set req.http.New-Location = regsub(req.url,"/+$","");
            error 301 "Redirecting you to the non-slash representation...";
    }
}

sub vcl_error {
    if (req.http.New-Location) {
            set obj.http.Location = req.http.New-Location;
    }
}

That is it.  The receive routine will detect the URL has a slash at the end, will rewrite the location into a temporary HTTP header, and throw an HTTP error 301.  The error routine will detect the presence of this temporary header and use it to base the Location header for the HTTP error 301 (Moved Permanently) itself.

If your Plone Documentation Center 1.5 is barfing out when trying to see one of the sub-elements (manuals, FAQ, ...) with a traceback that mentions right_slots or "Name is not defined' (here are a few examples), work around it with this:

1. Open your Plone Doc Center
2. Manage it by tacking /manage to the end of the URL
3. Go to Properties
4. Add a string property with any content, named right_slots

That is it.

Super easy.

1. Open file home/rudd-o/.kde/share/config/kuriikwsfilterrc (replace rudd-o with your own user name).
2. Nuke its contents.
3. Save.
4. Kill KRunner.
5. Rerun KRunner from a terminal, or restart your desktop session.
   

The missing RPMs is proud to announce that it now carries the latest stable Plone packages for your use.  They have been tested in CentOS 5.2 but they should work in any RPM-based distribution.  So go there and have a field day installing Plone now!  And don't forget to read the manual for a few details of this RPM-based release.

Engineering information

• The scripts used to build the Plone RPMs are all in The missing RPM's Yum repository.
• The only Plone RPM that was rebuilt and updated with a patch from the upstream sources is the plone.app.layout package, which required a patch to make Google Sitemaps work with LinguaPlone.
  

The bug

You've installed qSEOptimizer (version 1.5.1 or version 1.6.0), and now every visitor to your Plone Documentation Center documents experiences an error.  The details of the error are like this:

Site Error
 
An error was encountered while publishing this resource.
 
AttributeError
Sorry, a site error occurred.
 
Traceback (innermost last):
 
    * Module ZPublisher.Publish, line 202, in publish_module_standard
    * Module ZPublisher.Publish, line 150, in publish
    * Module plone.app.linkintegrity.monkey, line 21, in zpublisher_exception_hook_wrapper
    * Module Zope2.App.startup, line 221, in zpublisher_exception_hook
    * Module ZPublisher.Publish, line 119, in publish
    * Module ZPublisher.mapply, line 88, in mapply
    * Module ZPublisher.Publish, line 42, in call_object
    * Module Shared.DC.Scripts.Bindings, line 313, in __call__
    * Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
    * Module Products.CMFCore.FSPageTemplate, line 216, in _exec
    * Module Products.CacheSetup.patch_cmf, line 48, in FSPT_pt_render
    * Module Products.CacheSetup.patch_cmf, line 120, in PT_pt_render
    * Module zope.tal.talinterpreter, line 271, in __call__
    * Module zope.tal.talinterpreter, line 346, in interpret
    * Module zope.tal.talinterpreter, line 891, in do_useMacro
    * Module zope.tal.talinterpreter, line 346, in interpret
    * Module zope.tal.talinterpreter, line 536, in do_optTag_tal
    * Module zope.tal.talinterpreter, line 521, in do_optTag
    * Module zope.tal.talinterpreter, line 516, in no_tag
    * Module zope.tal.talinterpreter, line 346, in interpret
    * Module zope.tal.talinterpreter, line 586, in do_setLocal_tal
    * Module zope.tales.tales, line 696, in evaluate
      URL: file:/opt/prod/zeocluster/parts/plone/CMFPlone/skins/plone_templates/main_template.pt
      Line 32, Column 4
      Expression: <PythonExpr putils.listMetaTags(here).items()>
      Names:
 
      {'container': <PloneSite at /Plone>,
       'context': <ATDocument at /Plone/front-page>,
       'default': <object object at 0x7f69289ae200>,
       'here': <ATDocument at /Plone/front-page>,
       'loop': {},
       'nothing': None,
       'options': {'args': ()},
       'repeat': <Products.PageTemplates.Expressions.SafeMapping object at 0xc8acb00>,
       'request': <HTTPRequest, URL=http://www.onlinehr.co.nz/front-page/document_view>,
       'root': <Application at >,
       'template': <FSPageTemplate at /Plone/document_view used for /Plone/front-page>,
       'traverse_subpath': [],
       'user': <SpecialUser 'Anonymous User'>}
 
    * Module Products.PageTemplates.ZRPythonExpr, line 49, in __call__
      __traceback_info__: putils.listMetaTags(here).items()
    * Module PythonExpr, line 1, in <expression>
    * Module Products.qSEOptimizer, line 79, in listMetaTags
    * Module Products.qSEOptimizer.adapters, line 23, in listKeywords
 
AttributeError: qSEO_Keywords (Also, the following error occurred while attempting to render the standard error message, please see the event log for full details: qSEO_Keywords)

Do not despair.  I've got your back.

The hotfix

Kindly engineered with the help of jl_ at the Plone chat channel.

1. Locate the qSEOptimizer files on your server.
2. Find the file named adapters.py and open it into a text editor.
3. Find this text, around line 23:
   

   keywords = list(self.context.qSEO_Keywords())

4. Nuke it.  Replace it with:
   

   try: keywords = list(self.context.qSEO_Keywords())
   except AttributeError: keywords = []

   Remember to stay at the same indentation level.
5. That's it.  Restart your Zope application server.

Now, your qSEOptimizer should no longer bork out with horrible errors when people access your PHC documents.

Step 1: patch or reconfigure Plone

For plone 3.1.x users

The following patch should be applied by you to your Plone sources.  Find your Plone's python library directory, and apply this patch to it:

diff -urN lib/python/plone/session/plugins/session.py lib/python/plone/session/plugins/session.py
--- lib/python/plone/session/plugins/session.py 2009-01-28 12:55:40.000000000 -0500
+++ lib/python/plone/session/plugins/session.py 2009-01-28 12:57:36.000000000 -0500
@@ -7,6 +7,7 @@
 from AccessControl.SecurityInfo import ClassSecurityInfo
 from plone.session.interfaces import ISessionPlugin, ISessionSource
 import binascii
+import datetime,time

 try:
     from AccessControl.requestmethod import postonly
@@ -85,7 +86,9 @@
         cookie=self.source.createIdentifier(userid)
         cookie=binascii.b2a_base64(cookie).rstrip()

-        response.setCookie(self.cookie_name, cookie, path=self.path)
+        expires = datetime.datetime.now() + datetime.timedelta(365)
+        expires = time.strftime("%a, %d-%b-%Y %H:%M:%S GMT", expires.timetuple())
+        response.setCookie(self.cookie_name, cookie, path=self.path, expires=expires)


     # IExtractionPlugin implementation

Once this patch is applied, the login cookie that Plone sets is going to last for a year, or until you log off explicitly (whichever happens first).

For plone 3.2.x users

1. Open your ZMI interface
2. In there, browse to your Plone site
3. Browse into acl_users/session
4. Click on the Properties tab
5. Set the cookie lifetime in days to a number larger than 0.  Only positive integers are accepted.
   

Step 2: make Plone sessions last longer

However, this patch alone still won't keep you logged on -- your session with Plone will expire, by default, after thirty minutes of inactivity.  To change that, locate your Plone instance's etc/zope.conf file, and open it in a text editor.  Then look for the line that says # Directive: session-timeout-minutes.  You are going to add a new directive session-timeout-minutes like this:

session-timeout-minutes 10080

That makes Plone not expire its sessions in RAM for one week.  Or until you restart the server.  Your call.

And that's it!  Now your users' sessions and yours will last for a week or until you log off.  Just remember to explicitly log off whenever you're using a shared computer!

dd if=/dev/zero of=bigassfile bs=1M count=1 seek=9999

See what I did there?

This command, issued in a console, literally means: Duplicate data from /dev/zero (a zero generator) into bigassfile.  Do it in blocks of 1 mebibyte each, write only one block, but skip forward to 9999 blocks in the bigassfile.

So what does Linux do when it sees this?  Pretty simple: it creates a bigassfile that is ten thousand megabytes in size, but only bothers to write the very last 1 mebibyte, leaving the first 9999 MiBs empty.  Since only one mebibyte is ever written to disk, it's nearly instantaneous.  When you list the file, it will show as having ten thousand mebybites, but if you use an on-disk size analyzer, the file will only occupy one mebibyte.  As you write data to the file, Linux will use free disk space to supply the big-ass file with room to save the incoming data.

So, remember the trick: give a block size, ask the command to write only one block, and skip N - 1 blocks, where N is the size in blocks of the file you want.

There you go.

Note that this trick does not work in Windows FAT16 or FAT32 filesystems.