he1ix' blog

ever wondered where TSM stores its passwords? Documentation and lots of websites are talking about the file TSM.PWD, but where is it?

Voilà: /etc/adsm/TSM.PWD

just to remember how to test if a certain directory and its files are included in the backup using the TSM commandline interface:

./dsmc preview backup -console /path/to/dir/

delete one or more files from your backup (NOTE: the quotes in the second command are important, otherwise bash will expand the pattern and produce a list of files, which will confuse the TSM-client):

./dsmc delete backup /backups/mysql/mysqldump-complete-2010-01-20-1823.sql.gz
./dsmc delete backup '/backups/mysql/*.gz'

for mail in $(sudo mailq | grep frozen | cut -c 11-26) ; do
    sudo exim4 -Mrm $mail
done

extend or adjust the grep-pattern as required by your situation…

by far the best article I’ve read for somebody used to subversion (and tied to an SVN-repo) who wants to use git locally:

Git-SVN: Whys And Hows

thanks!!

Ever got messages like this in your Apache logfiles, wondering why setting properties via a client on your (otherwise working) WebDAV is failing?

Could not open the property database.  [500, #205]
(2)No such file or directory: Could not open property database.  [500, #1]
(2)No such file or directory: Attempted to set/remove a property without a valid, open, read/write property database.  [500, #202]

Well, simply add a directory called “.DAV“ (note the leading dot!) to your WebDAV base-directory, that is writeable to the webserver. That’s where the corresponding information will be stored by Apache. Note that this is “somehow” mentioned by the mod_dav documentation at webdav.org, but not by Apache’s documentation itself. Yes, that’s bad and pretty annoying.

you really should have a look here: bryan murdock’s blog

Easy Window Dragging
andLinux
http://www.winsplit-revolution.com/
http://sourceforge.net/projects/console/
http://virtuawin.sourceforge.net/
http://sourceforge.net/projects/xming/

finally, CalDAV evolves to a pretty common standard. sun microsystems is about to contribute a client for symbian: blog.symbian.org.

migrating the blog to the new server is finished and thanks to the professional service from prosite, even switching the domain was done in five minutes!

In the progress of migrating to a different server, I decided to upgrade my textpattern-installation. So I used the current release 4.2.0, basic installation was quite easy as expected. Next, I tried once again to install a theme since textpattern looks awful by default… Since the official theme-site lists an updated version of my old theme “Gentle Calm” this was the choice to go for – and this is where once again the pain starts.

Documentation talks about sth. like “easy and quick” installation procedure. Followed by dozen steps that include uploading and naming images, adjusting CSS by hand, editing existing templates and so on. What a PITA!!! Just to discover in the end that AGAIN half of the basic stuff like archives, RSS and so on is not working. And even more, none of the recommended plugins is available anywhere on the textpattern web-resources. Nothing but dead links.

Being disappointed once again this hard, I decided to test a different blogging-software. After a close look at HelixBlog (guess why…) which looks really interesting, I decided anyhow to give WordPress a chance.

And that’s where the nice part of the story begins. Basic installation was quite the same, but what a difference with what you are greeted after that: a nice admin-panel, many details but very well-organized. One-Click-Installation of new themes (or one-tar-installation, depending on your preferences). And the most shocking: an import-tool to migrate from textpattern to WordPress.

After all, the whole procedure of installing WP, a convenient theme and importing all information from textpattern took less time than going halfway through the theme-installation with TXP.

textpattern is dead. really.

since (at least on debian/ubuntu default installation) the homedir for user “nagios” points to /var/run/nagios the known_hosts file is lost after a reboot and check_by_ssh refuses to connect to any configured ssh-machine…

make sure to connect to all ssh-targets as user “nagios” and especially have a close look to connect exactly the same way as the nagios-process does (DNS-name / IP-address)

see also: check_by_ssh-booster