/dev/blog

I’m using BackUpWordPress to do regular database and file tree backups of this blog. Unfortunately, there is a nasty bug in this plugin which may cause the tarball to contain every backuped file multiple times (to be precise, every file except the first one will go into the tarball exactly three times).

The problem is that the . and .. directories may appear in a somewhat random order and not necessarily as the first entries in a directory. This is probably host specific (I encountered this error for the first time after I relocated this blog to another server).

To fix BackUpWordPress v0.4.5, locate line 103 in Directory.php (resides in wp-content/plugins/backupwordpress/Archive/Reader/) and change the while-loop inside the next() function

...
        while ($this->source === null ||
              ($error = $this->source->next()) !== true) {
...

like this

...
        $file = null;
        while ($this->source === null ||
              $file == '.' || $file == '..' ||
              ($error = $this->source->next()) !== true) {
...

Alternatively, you can use the following patch:

--- Directory.php.orig	2010-07-17 15:02:56.093238736 +0200
+++ Directory.php	2010-07-17 15:04:10.367237641 +0200
@@ -103,0 +104 @@
+        $file = null; 

@@ -104,0 +106 @@
+              $file == '.' || $file == '..' || 

Resources:
http://pear.php.net/bugs/bug.php?id=6546

Sometimes, rpm dependencies get rather complex. It’s not always easy for an rpm maintainer to keep track of the runtime requirements of his package and therefore, huge rpm dependency trees develop. And it’s even more difficult so see which packages get pulled by yum, because only a tiny part of those are actually listed as requirements in the spec file. The tree gets huge with recursion!

With rpmdep, there’s a small tool that will help you visualize those dependency trees. It’s part of Fedora’s rpmorphan-package, so you can easily pull it with yum:

# yum install rpmorphan

rpmdep itself is just a perl script, that walks down the rpm tree recursively. It can produce a Graphviz dot-file, which in turn can be used to make rather since pictures. For example,

$ rpmdep -dot firefox.dot firefox
$ dot -Tpng firefox.dot -o firefox.png

produces a complete rpm dependency tree for firefox. An exemplary picture (firefox’s dependencies in Fedora 13):

Click image for full size (1.6MB)

Graphvic can produce quite a few output formats. For an overview about all available commands, have a look at http://www.graphviz.org/doc/info/command.html.

Every X server internally manages an ACL (Access Control List) of those hosts, that are allowed to connect. The server only authorizes connections from X clients, whose host is on that list and rejects access to all others. The xhost program is used to add or revert access to the X server for specified hosts. It’s also possible to specify a user and a hostname pair.

Host-based Control (xhost)

To see if access control is enabled, type xhost. It displays the current ACL:

$ xhost
access control enabled, only authorized clients can connect
SI:localuser:user
SI:localuser:gdm
SI:localuser:root

If the access control is disabled, it prints:

$ xhost
access control disabled, clients can connect from any host

To disable the access control type xhost + which allows any host to access your X server. You probaly don’t want to do this because it allows the world to open windows on your screen and grab the keystrokes you type.

To enable the access control again type xhost - and only authorized clients/hosts are allowed to do the things mentioned above.

A simple example

Now let’s do something useful, e.g. grant another user on the local machine access to our X server. It’s pretty easy:

$ xhost +SI:localuser:anotheruser
localuser:anotheruser being added to access control list

And after that, anotheruser should show up in the ACL:

$ xhost
access control disabled, clients can connect from any host
SI:localuser:anotheruser
SI:localuser:user
SI:localuser:gdm
SI:localuser:root

To revoke the access right for anotheruser, use

$ xhost -SI:localuser:anotheruser
localuser:anotheruser being removed from access control list

For granting access to users on different hosts, have a look at the xhost manpage or the examples provided on http://linux.about.com/library/cmd/blcmdl_xhost.htm.

When an upgrade includes changes to a default configuration file, the package will write either a .rpmnew or a .rpmsave file instead of overwriting the configuration file on your system. Which file a package creates is up to the discretion of the package maintainer.

From “Dealing with .rpmnew and .rpmsave files” By Bruce Byfield:

An .rpmnew file contains the new default configuration file and leaves your original configuration file untouched. By contrast, and .rpmsave file is a copy of your original configuration file, which has been replaced by the new default file.

The following script can be helpful to find (and possibly merge) those files with your original configuration

for a in $(find /etc /var -name '*.rpm?*'); do diff -u $a ${a%.rpm?*}; done

You may also want to check on yum-merge-conf, a yum plugin to merge configuration files.

Sometimes, packages you never actually use get installed as dependency by yum (or even during initial installation by anaconda). package-cleanup is a great tool that helps you find packages not required by other packages. It it part of the yum-utils package which can easily be pulled with yum:

# yum install yum-utils

1. Find and review “unused” packages

You can find packages not required by other packages with

# package-cleanup --leaves

These packages could be candidates for removal, but check to see whether you use them directly or if they are used by applications not backed by rpm packages.

2. Find and review “lost” packages

You can find orphaned packages (i.e. packages not in the repositories anymore) with

# package-cleanup --orphans

This will also show packages which have been partially uninstalled but where the “%postun” script failed.

q.v. package-cleanup manpage