I was bemused by the below error when attempting to run an Ansible playbook on a new (Linux) server for the first time:

PLAY [someserver] ***************************************************************** 

GATHERING FACTS *************************************************************** 
failed: [someserver] => {"failed": true, "parsed": false}

SUDO-SUCCESS-fdhntaxupgygzrcocwghbosdkgbgguvy
/bin/sh: 1: powershell: not found

This happened with gather_facts set to true. Setting it to false worked around the issue, however I'm pretty sure powershell hasn't been ported to Debian... Ansible version:

$ ansible-playbook --version
ansible-playbook 1.8 (devel ffee9a8fe0) last updated 2014/09/27 14:24:58 (GMT +900)

The actual cause was the absence of python on the target server; this will need to be manually installed before Ansible can be of much use.

After upgrading to openSUSE 13.1, the Samba configuration - which I use mainly to share a directory on my workstation-cum-fileserver to a media player on the local network - mysteriously failed to work as expected. The client could mount, but not see, any directories or files. The only vaguely relevant clue appeared to be this entry in /var/log/samba/log.smbd:

Invalid key 0 given to dptr_close

After much head-scratching, it turns out AppArmor is enabled by default on openSUSE 13.1 and was the source of the error. Resolving the issue with AppArmor brought Samba back to life.

I made the mistake of installing VirtualBox from the openSUSE repository, and after much pain trying to troubleshoot the error "This usually means that the vboxdrv module is not loaded. Try again after loading the module" (which pops up every time a virtual machine is launched), I remember the least painful way to install VirtualBox on openSUSE is to follow these instructions, adjusting the version numbers (both for openSUSE and for VirtualBox) accordingly.

As of the time of writing, download.virtualbox.org doesn't provide packages for openSUSE 13.1, however the packages for 12.3 installed just fine and seems to work so far using some pre-existing images, including different Windows versions.

Note: this issue appears to have gone away in OpenSUSE 13.2.

I find (hah) myself using find a lot to locate file system objects in the current directory, however find recurses into subdirectories by default. Using the parameters -mindepth 1 -maxdepth 1 restrict find to the current directory, are however a pain to type each time.

To make my own personal life easier I created this wrapper script (named find1):

#!/bin/sh

if [ ($# < 1) ]; then
  FINDPATH=.
else 
  FINDPATH=$1
  shift
fi

find $FINDPATH -mindepth 1 -maxdepth 1 $@

which automatically prepends the -mindepth and -maxdepth to find (they need to be first in the argument list).

As mentioned previously, it's possible to install the usual set of command-line tools without the full XCode installation. However this seems to confuse Apache (at least with version 2.2), which is expecting to find a C compiler in the XCode folder:

checking for chosen layout... Apache
checking for working mkdir -p... yes
checking build system type... x86_64-apple-darwin12.2.1
checking host system type... x86_64-apple-darwin12.2.1
checking target system type... x86_64-apple-darwin12.2.1

Configuring Apache Portable Runtime library ...

checking for APR... yes
  setting CC to "/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc"
  setting CPP to "/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc -E"
  setting CFLAGS to " "
  setting CPPFLAGS to " -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK"
  setting LDFLAGS to " "

Configuring Apache Portable Runtime Utility library...

checking for APR-util... yes
checking for gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc
checking whether the C compiler works... no
configure: error: in `/Users/ian/src/httpd-2.2.24':
configure: error: C compiler cannot create executables

As mentioned previously, it's now possible to install XCode's command line tools without installing the entire XCode environment. This is particularly handy when setting up an environment on a remote Mac. However it looks like MacPorts is still expecting to find the full XCode installation and will complain like this:

Some-Mac-mini:~ root# port install somepackage
Error: 
Error: No Xcode installation was found.
Error: Please install Xcode and/or run xcode-select to specify its location.
Error: 

Occasionally I've needed to set up some kind of script or even a server application in a remote office, where the only computer with a UNIX-style environment is a Mac. Although OS X comes with a fair amount of tools built-in, these are usually not sufficient for the specialised configuration required, which means I need to compile some applications from scratch and probably install a command-line driven package management system such as MacPorts. To get this up and running of course, I need a compiler and associated tools, which are not built in. These are available from Apple as part of the XCode package; recently the non-IDE parts of XCode have been made available as a separate dmg file.

Occasionally I like to remove a bunch of cookies from a SeaMonkey profile, unfortunately at some point it appears the Great Dumbing Down is spreading even to obscure browsers such as this Netscape descendant, and the "Tools > Cookie Manager > Manage Stored Cookies" dialogue only allows you to delete cookies for individual sites (trying to mark multiple sites no longer works).

Luckily it appears there is a hidden chrome URL which still offers this functionality:

chrome://communicator/content/permissions/cookieViewer.xul

(paste into the address bar).

There's a list of similar useful chrome URLs here: http://kb.mozillazine.org/Chrome_URLs

While installing Debian 6 on VirtualBox, I noticed it evidently detected it was running in VirtualBox and automatically added three virtualbox-ose-guest-* packages to the install, which is nice. However they are somewhat dated - version 3.2.x whereas the GuestAdditions virtual CD mounted by VirtualBox provides 4.1.x.

Remove the existing packages with:

  apt-get remove virtualbox-ose-guest-dkms virtualbox-ose-guest-utils virtualbox-ose-guest-x11

(otherwise the GuestAdditions installer will complain) and reboot to remove installed kernel modules.

The virtual CD does not appear to be startable from a double click - the error "Cannot find the autorun program" pops up - instead run the script directly with:

  bash VBoxLinuxAdditions-x86.run

A further reboot will activate the GuestAdditions.

After upgrading my development environment to openSuSE 12.1, I started getting a bunch of notices like the below after every Subversion operation which uses SSH:

The issue is discussed here; in a nutshell, the solution is to add "-q" to the ssh command invoked by SVN, which is defined in the configuration file (typically ~/.subversion/config). In my case, the line in question now looks like this:

ssh = $SVN_SSH ssh -q -o ControlMaster=no

Note: ensure this line is in the [tunnels] section of the config file.

I got the following error when building PHP with cURL (on openSuSE 12.1):

/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: ext/curl/.libs/interface.o: undefined reference to symbol 'CRYPTO_set_id_callback'
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: note: 'CRYPTO_set_id_callback' is defined in DSO /lib64/libcrypto.so.1.0.0 so try adding it to the linker command line
/lib64/libcrypto.so.1.0.0: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

Not sure why it's happening, but a look in Makefile showed that EXTRA_LIBS contained "-lcrypt" twice:

EXTRA_LIBS = -lcrypt -lz -lresolv -lcrypt -lpq -lrt -lpq -lpng -lz -ljpeg -lcurl -lrt -lm -ldl -lnsl -lxml2 -lzlcurl -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt

Changing the last "-lcrypt" to "-lcrypto" resolved the problem:

EXTRA_LIBS = -lcrypt -lz -lresolv -lcrypt -lpq -lrt -lpq -lpng -lz -ljpeg -lcurl -lrt -lm -ldl -lnsl -lxml2 -lzlcurl -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypto

I was idly watching some Apache access logs scroll by (well actually I was busy doing something, but like to keep an eye on things to spot any interesting or worrying trends early) and noticed a bunch of entries like this:

94.228.34.238 - - [06/Feb/2011:06:21:23 +0100] "GET /blog/?o=10 HTTP/1.1" 301 290 "-" "magpie-crawler/1.1 (U; Linux amd64; en-GB; +http://www.brandwatch.net)"
94.228.34.238 - - [006/Feb/2011:06:21:33 +0100] "GET /blog/?o=40 HTTP/1.1" 301 290 "-" "magpie-crawler/1.1 (U; Linux amd64; en-GB; +http://www.brandwatch.net)"

Never noticed that UA before, and it never seemed to follow up on the (perfectly valid) 301 redirects. A scan through 3 months of logs shows it's been doing that all the time - what a dumb bot.

Checking the URL provided, this appears to be the home page of a UK-based company providing "Social Media Monitoring Tools" - and who don't have the courtesy to provide any more information about their bot / crawler. Which is evidently not popular in some quarters.

So, as "Brandwatch" provides neither myself not the sites I run with any conceivable benefit, it's on the blocklist they go.

(I wonder if they monitor their own brand?)