Just tried to update ILO3 on a HP DL 380 G7 from version 1.16 (Dec 17 2010) to one of the latest version 1.55 (Feb 19 2013) but got the following error message in the browser:

The last firmware update attempt was not successful. Ready for the next update.

A quick look in the readme file of the ILO3 1.55 package reveals:

PART NUMBER:  592410-013
FILE NAME:    ilo3_155.bin
TITLE:        Integrated Lights-Out 3 Firmware 1.55
[...]
PREREQUISITE:  iLO 3 v1.20
[...]
FIRMWARE DEPENDENCY: iLO 3 should be upgraded to v1.20 before upgrading to this version.

But it also works with version 1.28 as intermediate version.

Just a quick update to inform that performance data has been activated in check_zpools. See https://github.com/Napsty/nagios-plugins/tree/master/check_zpools.

Due to parsing limitations on different operating systems, the only performance data available are the percentage of a single or all datastores.

Google Play notified me yesterday about a new update of the Facebook app on my Android phone (CyanogenMod 9/Android 4.0.4 running on Samsung Galaxy S2 GT-I9100). Because I've had some bad experiences in the past with some app-updates (especially Facebook), I read the comments. Quoting some:

*Updated* Even more diminished quality. After the last update, the app launches with a greyish black screen, then closes. Tried powering down then back up after update, same result. Can we please get this right? You were so close with the last build. Droid Razr Maxx

 This app is good but takes up alot of memory on my android phone I can only have this app and 1 more. It makes my phone run slow. Can you please fi this. Thanks.

I would be a lot happier if I was able to open the app more than once or twice. I am constantly getting a error saying there was an error in Facebook.katana the app will now forceclose, or some other type of error that gives me the option to forceclose, wait, or report. No matter which option I choose it ALWAYS forcecloses! I have not been happy with this app since it has been installed on every phone I have had, there has always been some sort of issue this one needs fixed ASAP!

 Closes out of pages and profiles .. etc ..... Fix please. Won't show comments when I post them or show the likes I get on statuses and it won't refresh worth crap !

But because on most comments the Android version or the phone model was not mentioned, I decided to install the update anyway. Mistake. Big mistake.

As soon as I installed the Facebook update, I tried to launch the app. First I only saw a black screen, for around 10 seconds. The the Facebook logo appeared on blue background. Waited another like 5 seconds and then the News Feed finally appeared. For around 2 seconds, then the application crashed. Oh great, I thought. But it got worse. Several services and other apps started to crash, one after another. I then tried to force close the Facebook app in the App Settings, which was still running, although it crashed. In a period of 5 minutes trying to stop the Facebook processes and getting a hell lot of notifications about crashed apps, the battery drowned from 40% to 7%!

I rebooted the phone and hoped it would help. Unfortunately not. Although I didn't start the Facebook app, the system started to crash again. I just had time to see the list of running processes and saw that Facebook now automatically starts two processes, using up 38MB of RAM. Time to uninstall! I thought. Because as soon as I pushed the "Uninstall app" button, the system crashed and the phone rebooted. Or tried to reboot - it was a boot loop where only a battery removal would help. I tried several times to uninstall the app, only to reproduce the same bug.

To uninstall the app and prevent the phone from crashing every 2 minutes, I did the following:

1) Login to Google Play on your computer. As you probably know, one can install and uninstall apps on your phone via your computer.  
Uninstalled the Facebook app (by clicking on the trash icon). Got notification, that the app would be uninstalled shortly on my device.

2) Rebooted device, connected to Internet. Got a warning symbol, that the Facebook application was uninstalled. But system kept on crashing.

3) Rebooted device into Recovery mode. Wiped Cache and Dalvik Cache.

4) Normal reboot to Android - but still got crash notifications "Unfortunately trebuchet has stopped". On an Android community board I found a post (http://forum.xda-developers.com/showthread.php?t=1878099) indicating, that such crashes could come from too few home screens (when an app tries to create an icon but there's no space anymore) or when there's still an icon of an non-existing app. The latter case is my case because the Facebook icon was still on my home-screen. 

5) Removed the Facebook icon from home screen.

Voilà... my system and other apps aren't crashing anymore and I can use my phone again!

To Facebook: No - I won't install your app anymore. There have been too many bugs from your side! Already in the past your app contained a lot of bugs. But now it made my phone unusable and I can't let that happen. So bye bye Facebook. 

This week I compared several Nagios plugins to monitor zfs pools (see article Monitor zfs pools - which Nagios plugin should be used?). After having compared seven plugins found on exchange.nagios.org,  I finally decided to continue with plugin number 3 (check_zpools), a bash/shell plugin.

Although the plugin already "did its job", I had to make some changes anyway to guarantee compatibility to both Solaris and FreeBSD systems. Besides that I completely revamped the plugin; I added help, options and thresholds for pool usage and changed the "design" of the plugin.

The modified plugin can be found on my github account:
http://raw.github.com/Napsty/nagios-plugins/master/check_zpools/check_zpools.sh

I successfully tested it on the following operating systems (no modifications or additional installations are necessary):
- Solaris 10
- Open Solaris 11
- SmartOS
- FreeBSD 8.3

I asked the author of the last version to merge my modifications, so I think the my adapted version will soon be available on Nagios Exchange.

At my work there are several machines running with zfs file systems. Some of them also use zfs pools, which can define a raid out of a system without raid controller (a bit like mdraid simply explained - please don't hit me Solaris guys!). To be able to monitor the status of such zfs pools, there are many Nagios plugins around. Alone on exchange.nagios.org  I found seven plugins which check zfs file systems and/or pools. But which one should I take, given that we run different operating systems with zfs?

To answer this question I compared all seven plugins if they work, how they're working and what they can do on the following operating systems on physical machines:
- Solaris 10
- OpenSolaris 11
- SmartOS 2012Q2
- FreeBSD 8.3

The following plugins were compared:

1. Check ZFS file systems and data pools (check_zfs.pl)
   Author: Michael Simoni
   http://exchange.nagios.org/directory/Plugins/Operating-Systems/Solaris/Check-ZFS-file-systems-and-data-pools/details
   
   
2. check_zfs
   Author: Nathan Butcher
   http://exchange.nagios.org/directory/Plugins/Operating-Systems/Solaris/check_zfs/details
   
   
3. Check Solaris ZFS Pools (check_zpools)
   Author: vitaliy@gmail.com
   http://exchange.nagios.org/directory/Plugins/Operating-Systems/Solaris/Check-Solaris-ZFS-Pools/details
   
   
4. Solaris Zpools checker (check_zpools)
   Author: Aldo Fabi
   http://exchange.nagios.org/directory/Plugins/Operating-Systems/Solaris/Solaris-Zpools-checker/details
   
   
5. check_zpool_fs
   Author: Suraj K Abraham
   http://exchange.nagios.org/directory/Plugins/Operating-Systems/Solaris/check_zpool_fs/details
   
   
6. check_zpool.pl
   Author: ?
   http://exchange.nagios.org/directory/Plugins/Operating-Systems/Solaris/check_zpool-2Epl/details
   
   
7. check_zpool (check_zpool.sh)
   Author: Søren Klintrup
   http://exchange.nagios.org/directory/Plugins/Operating-Systems/Solaris/check_zpool/detaills
   

Plugins output (examples):

1. check_zfs.pl on a Solaris 10:

# Check all pools
./check_zfs.pl -p
OK: ZFS on solaris-server - No zfs failures detected

# Check single pool:
./check_zfs.pl -p -z rpool
OK: ZFS on solaris-server - No zfs failures detected

2. check_zfs on an OpenSolaris 11:

# Check with verbose level 2
./check_zfs.pl datapool1 2
OK ZPOOL datapool1 : ONLINE {Size:13.6T Used:13.2T Avail:449G Cap:96%}

# Check with verbose level 3 (shows all disks)
./check_zfs.pl datapool1 3
OK ZPOOL datapool1 : ONLINE {Size:13.6T Used:13.2T Avail:449G Cap:96%} c9t2d0:ONLINE c10t1d0:ONLINE c9t3d0:ONLINE c10t2d0:ONLINE c9t4d0:ONLINE c10t3d0:ONLINE c9t5d0:ONLINE c10t4d0:ONLINE c9t6d0:ONLINE c10t5d0:ONLINE c9t7d0:ONLINE c10t6d0:ONLINE c9t1d0:ONLINE c10t7d0:ONLINE c9t8d0:ONLINE c10t8d0:ONLINE c9t9d0:ONLINE c10t9d0:ONLINE c9t10d0:ONLINE c10t10d0:ONLINE c9t11d0:ONLINE c10t11d0:ONLINE c9t12d0:ONLINE c10t12d0:ONLINE c9t13d0:ONLINE c10t13d0:ONLINE c9t14d0:ONLINE c10t14d0:ONLINE c9t15d0:ONLINE c10t15d0:ONLINE [SPARES]:-

3. check_zpools on FreeBSD 8.3 and on OpenSolaris 11:

# FreeBSD 8.3:
./check_zpools
OK:datapool:23%:ONLINE OK:dbpool:4%:ONLINE

# OpenSolaris 11:
./check_zpools  
WARNING:datapool1:96%:ONLINE OK:rpool:25%:ONLINE

4. check_zpools on Solaris 10:

./check_zpools   
OK:rpool:5%:ONLINE

5. check_zpool_fs on Solaris 10 and OpenSolaris 11:

# Solaris 10
./check_zpool_fs rpool 90 95
/rpool: 5%used - (Used: 8.12G/Total: 136G) (90%): OK

# OpenSolaris 11
./check_zpool_fs datapool1 90 95
/datapool1: 96%used - (Used: 13.2T/Total: 13.6T) (95%): CRITICAL

6. check_zpool.pl on FreeBSD 8.3:

./check_zpool.pl
Can't locate Nagios/Plugin.pm in @INC (@INC contains: ....

7. check_zpool.sh on FreeBSD 8.3, SmartOS and Solaris 10:

#FREEBSD
./check_zpool.sh    
  / datapool: online / dbpool: online

# SMARTOS
./check_zpool.sh
  / zones: online

# SOLARIS 10
./check_zpool.sh
sed: illegal option -- E
Bad string
 / rpool: unknown state

Comparison table:

Plugin	Help	Verbose	Solaris10	OpenSolaris11	SmartOS	FreeBSD 8.3	Active?
1	y	y	y	y	n (*4)	n (*6)	n
2	y (*1)	y	y	y	n (*4)	y (*7)	n
3	n	n	y	y	y	y (*8)	?
4	n	n	y	y	y	y (*8)	n
5	y (*1)	n	y	y	n (*5)	n (*5)	?
6	y	y	n (*2)	n (*2)	n (*4)	n (*2)	?
7	n	n	n (*3)	n (*3)	y	y	?

Legend:
Plugin: The plugin number tested (see above for list)
Help: Is there a help function of the plugin available? (--help, or -h, etc)
Verbose: Is there a verbose function for additional information?
Solaris10: Does the plugin work on Solaris 10?
OpenSolaris11: Does the plugin work on Open Solaris 11?
SmartOS: Does the plugin work on SmartOS (2012Q2)?
FreeBSD 8.3: Does the plugin work on FreeBSD 8.3?
Active: Is this plugin in active development?

*1: No real help available but shows usage as help
*2: Additional perl modules are required
*3: sed -E is used, which is not recognized by the sed installed on the OS
*4: Perl is required
*5: Invalid option error
*6: Plugin outputs that it only works on Solaris 10 when launched on FreeBSD
*7: Works, but always returns CRITICAL output
*8: Works after paths of commands were adapted to FreeBSD

Additional comments:

Plugin 2) I really like the output of this plugin! A real bummer that it doesn't work on SmartOS due to perl usage :-(
Plugin 3+4) This is actually very much the same plugin, 3) is a fork of 4) with some minor changes
Plguin 6) requires additional perl modules to work (Nagios::Plugin and Switch at least)

I am aware that the "n" could easily become a "y" when perl is installed, but my requirement for the plugin is that it works out of the box, without having to install anything.
Unfortunately, a physical SmartOS doesn't come with a lot of software, so minimum compatibility is important in my case.

And the lovely winner is...:

If I could choose, I'd prefer candidate 2's output mixed with the compatibility of candidate 4 (because its a shell script).
So at the end I decided for plugin 3 (Check Solaris ZFS Pools) but I'll have to adapt the source code anyway so it also works on FreeBSD systems. 

I hope this comparison was helpful to you.

Update May 9th 2013: As mentioned, I decided for check_zpools. But for compatibility reasons (SmartOS, FreeBSD, Solaris) I made a lot of changes. Take a look at the next article "Presenting check_zpools - a Nagios plugin to monitor zfs pools".

Today seems to be the perfect day to solve PHP compiling issues... (see previous articles, also from today).

So I tried to compile PHP 5.4.14 from source. configure ran through without error (after having solved some issues before, see articles "PHP 5.4 compilation error: build with IMAP works... no" and "Another confusing PHP 5.4 compilation error: This time mcrypt_module_open"). But then make always stopped at the same step with an error:

/bin/sh /root/downloads/php-5.4.14/libtool --silent --preserve-dup-deps --mode=compile g++ -I/usr/include  -Iext/intl/ -I/root/downloads/php-5.4.14/ext/intl/ -DPHP_ATOM_INC -I/root/downloads/php-5.4.14/include -I/root/downloads/php-5.4.14/main -I/root/downloads/php-5.4.14 -I/root/downloads/php-5.4.14/ext/date/lib -I/root/downloads/php-5.4.14/ext/ereg/regex -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap -I/root/downloads/php-5.4.14/ext/mbstring/oniguruma -I/root/downloads/php-5.4.14/ext/mbstring/libmbfl -I/root/downloads/php-5.4.14/ext/mbstring/libmbfl/mbfl -I/root/downloads/php-5.4.14/ext/sqlite3/libsqlite -I/root/downloads/php-5.4.14/TSRM -I/root/downloads/php-5.4.14/Zend      -c /root/downloads/php-5.4.14/ext/intl/msgformat/msgformat_helpers.cpp -o ext/intl/msgformat/msgformat_helpers.lo
env: g++: No such file or directory
make: *** [ext/intl/msgformat/msgformat_helpers.lo] Error 1

Of course I was googling for a solution, but nothing came up. When I almost gave up, I thought maybe the problem is the g++ compiler and installed the gcc c++ compiler, which would be installed normally on my machines, but this was a new setup test machine:

zypper in gcc-c++
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW packages are going to be installed:
  gcc-c++ gcc47-c++

Ran again configure and make, and this time it worked:

/bin/sh /root/downloads/php-5.4.14/libtool --silent --preserve-dup-deps --mode=compile cc -I/usr/include  -Iext/intl/ -I/root/downloads/php-5.4.14/ext/intl/ -DPHP_ATOM_INC -I/root/downloads/php-5.4.14/include -I/root/downloads/php-5.4.14/main -I/root/downloads/php-5.4.14 -I/root/downloads/php-5.4.14/ext/date/lib -I/root/downloads/php-5.4.14/ext/ereg/regex -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap -I/root/downloads/php-5.4.14/ext/mbstring/oniguruma -I/root/downloads/php-5.4.14/ext/mbstring/libmbfl -I/root/downloads/php-5.4.14/ext/mbstring/libmbfl/mbfl -I/root/downloads/php-5.4.14/ext/sqlite3/libsqlite -I/root/downloads/php-5.4.14/TSRM -I/root/downloads/php-5.4.14/Zend    -I/usr/include -g -O2 -fvisibility=hidden  -c /root/downloads/php-5.4.14/ext/intl/msgformat/msgformat_format.c -o ext/intl/msgformat/msgformat_format.lo

/bin/sh /root/downloads/php-5.4.14/libtool --silent --preserve-dup-deps --mode=compile g++ -I/usr/include  -Iext/intl/ -I/root/downloads/php-5.4.14/ext/intl/ -DPHP_ATOM_INC -I/root/downloads/php-5.4.14/include -I/root/downloads/php-5.4.14/main -I/root/downloads/php-5.4.14 -I/root/downloads/php-5.4.14/ext/date/lib -I/root/downloads/php-5.4.14/ext/ereg/regex -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap -I/root/downloads/php-5.4.14/ext/mbstring/oniguruma -I/root/downloads/php-5.4.14/ext/mbstring/libmbfl -I/root/downloads/php-5.4.14/ext/mbstring/libmbfl/mbfl -I/root/downloads/php-5.4.14/ext/sqlite3/libsqlite -I/root/downloads/php-5.4.14/TSRM -I/root/downloads/php-5.4.14/Zend    -g -O2  -c /root/downloads/php-5.4.14/ext/intl/msgformat/msgformat_helpers.cpp -o ext/intl/msgformat/msgformat_helpers.lo

/bin/sh /root/downloads/php-5.4.14/libtool --silent --preserve-dup-deps --mode=compile cc -I/usr/include  -Iext/intl/ -I/root/downloads/php-5.4.14/ext/intl/ -DPHP_ATOM_INC -I/root/downloads/php-5.4.14/include -I/root/downloads/php-5.4.14/main -I/root/downloads/php-5.4.14 -I/root/downloads/php-5.4.14/ext/date/lib -I/root/downloads/php-5.4.14/ext/ereg/regex -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap -I/root/downloads/php-5.4.14/ext/mbstring/oniguruma -I/root/downloads/php-5.4.14/ext/mbstring/libmbfl -I/root/downloads/php-5.4.14/ext/mbstring/libmbfl/mbfl -I/root/downloads/php-5.4.14/ext/sqlite3/libsqlite -I/root/downloads/php-5.4.14/TSRM -I/root/downloads/php-5.4.14/Zend    -I/usr/include -g -O2 -fvisibility=hidden  -c /root/downloads/php-5.4.14/ext/intl/msgformat/msgformat_parse.c -o ext/intl/msgformat/msgformat_parse.lo

Note that this time the cc compiler is used (--mode=compile cc). And this time PHP compiled without a problem.
Summary: DO NOT use g++ as a compiler.

Update May 5th 2013: This problem seems to be related to bug  #63104 (php fail to build with --enable-intl) which mentions, that the wrong C libraries are linked.

As just posted a couple of minutes ago (PHP 5.4 compilation error: build with IMAP works... no), the confusing compilation errors continue. This time during the mcrypt checks:

checking for stdarg.h... (cached) yes
checking for mcrypt support... yes
checking for libmcrypt version... >= 2.5.6
checking for mcrypt_module_open in -lmcrypt... no
checking for mcrypt_module_open in -lmcrypt... no
configure: error: Sorry, I was not able to diagnose which libmcrypt version you have installed.

By common sense, this would be a missing libmcrypt-devel package, but that exists. I took another look in the config.log:

configure:78094: checking for mcrypt_module_open in -lmcrypt
configure:78129: cc -o conftest -I/usr/include -g -O2 -fvisibility=hidden  -L/usr/lib64  -lltdl conftest.c -lmcrypt  -lstdc++ -lcrypt -lpam -lfreetype -lpng -lz -ljpeg -lcurl -lbz2 -lz -lrt -lm -ldl -lnsl  -lxml2 -lz -lm -lssl -lcrypto -lcurl -lxml2 -lz -lm -lssl -lcrypto -lssl -lcrypto -ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio >&5
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lltdl
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
configure:78136: $? = 1

I've tried to look for ltdl packages in the repository, but couldn't find any libltdl*-devel packages. I continued with lstdc++ as the check might look for either ltdl or stdc++ libraries. I found the devel package for stdc++:

zypper in libstdc++47-devel

And this time it worked:

checking for mcrypt support... yes
checking for libmcrypt version... >= 2.5.6
checking for mcrypt_module_open in -lmcrypt... yes

Yesterday I tried to compile the newest PHP 5.4.14 on an opensuse 12.2 system but got stuck when configure was at the IMAP check.

checking for IMAP support... yes
checking for IMAP Kerberos support... no
checking for IMAP SSL support... yes
checking for utf8_mime2text signature... new
checking for U8T_DECOMPOSE...
checking for pam_start in -lpam... no
checking for crypt in -lcrypt... yes
checking whether rfc822_output_address_list function present... no
checking whether build with IMAP works... no
configure: error: build test failed. Please check the config.log for details.

At the begin I thought, that's easy to solve, as I already had this error before. The IMAP development files have a funny name called libc-client, at least that's what it was in the past. See my post "PHP compilation fails on IMAP U8T_DECOMPOSE: The Debian solution" for more information. But the imap dev files (they're now called imap-devel on opensuse) are already installed:

rpm -qa | grep imap-dev
imap-devel-2007e_suse-12.1.2.x86_64
# rpm -qa| grep libc-client
libc-client2007e_suse-2007e_suse-12.1.2.x86_64

ll /usr/lib64/ | grep libc-client
lrwxrwxrwx  1 root root       13 May  3 18:58 c-client.a -> libc-client.a
-rw-r--r--  1 root root  4887050 Jul 16  2012 libc-client.a
lrwxrwxrwx  1 root root       25 May  3 18:58 libc-client.so -> libc-client.so.2007e_suse
-rwxr-xr-x  1 root root  1108008 Jul 16  2012 libc-client.so.2007e_suse

So I took a look at the config.log, at the relevant information:

| #define HAVE_IMAP2000 1
| #define HAVE_IMAP2004 1
| /* end confdefs.h.  */
|
| #include
| #include
|
| int
| main ()
| {
|
|         SIZEDTEXT *src, *dst;
|         utf8_mime2text(src, dst);
|
|   ;
|   return 0;
| }
configure:65718: result: new
configure:65731: checking for U8T_DECOMPOSE
configure:65761: cc -c -I/usr/include/imap  conftest.c >&5
configure:65768: $? = 0
configure:65788: result:
configure:65927: checking for pam_start in -lpam
configure:65962: cc -o conftest -I/usr/include -g -O2 -fvisibility=hidden  -L/usr/lib64  conftest.c -lpam  -lfreetype -lpng -lz -ljpeg -lcurl -lbz2 -lz -lrt -lm -ldl -lnsl  -lxml2 -lz -lm -lssl -lcrypto -lcurl -lxml2 -lz -lm -lssl -lcrypto >&5
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lpam
collect2: error: ld returned 1 exit status
configure:65969: $? = 1
configure: failed program was:

This means that the IMAP check was actually successful, at the c-client header files were successfully included. But another message is very important in that output: "cannot find -lpam".
That's interesting... the information in the ./configure output is actually very misleading and makes one think there's a problem with the imap/libc-client devel files, but it actually seems to be a missing pam devel!

Install pam-devel and try again to configure:

zypper in pam-devel

[...]
checking for iconv support... yes
checking for iconv... yes
checking if iconv is glibc's... yes
checking if iconv supports errno... yes
checking if your cpp allows macro usage in include lines... yes
checking for IMAP support... yes
checking for IMAP Kerberos support... no
checking for IMAP SSL support... yes
checking for utf8_mime2text signature... new
checking for U8T_DECOMPOSE...
checking for pam_start in -lpam... yes
checking for crypt in -lcrypt... yes
checking whether rfc822_output_address_list function present... yes
checking whether build with IMAP works... yes
checking for InterBase support... no
checking whether to enable internationalization support... yes
[...]

Finally it ran through! From the beginning it actually required the pam-devel that the build with imap would work.

Side note: I also tried to compile imap from source (ftp://ftp.cac.washington.edu/imap/imap-2007f.tar.gz)  to see if there was a problem in the opensuse devel files and the compilation failed with the following error:

`cat CCTYPE` -c `cat CFLAGS` `cat OSCFLAGS` -c osdep.c
osdep.c:89:31: fatal error: security/pam_appl.h: No such file or directory
compilation terminated.

That was another hint, that pam-devel was missing.

Since a recent update of some installed packages, my chef command 'knife' suddenly didn't work anymore:

knife status
ERROR: knife encountered an unexpected error
This may be a bug in the 'status' knife command or plugin
Please collect the output of this command with the `-VV` option before filing a bug report.
Exception: NoMethodError: undefined method `name' for #<Hash:0x00000002893508>

So I launched knife again, as mentioned, with the -VV option:

knife status -VV
DEBUG: Using configuration from /home/ckuenzler/.chef/knife.rb
DEBUG: Signing the request as xxx
DEBUG: Sending HTTP Request via GET to chef.exmample.com:443/search/node
DEBUG: ---- HTTP Status and Header Data: ----
DEBUG: HTTP 1.1 200 OK
DEBUG: server: nginx/1.1.19
DEBUG: date: Fri, 03 May 2013 11:10:53 GMT
DEBUG: content-type: application/json; charset=utf-8
DEBUG: transfer-encoding: chunked
DEBUG: connection: close
DEBUG: ---- End HTTP Status/Header Data ----
/usr/lib64/ruby/gems/1.9.1/gems/chef-10.16.2/lib/chef/knife/status.rb:88:in `block in run': undefined method `name' for #<Hash:0x00000001296fe8> (NoMethodError)
        from /usr/lib64/ruby/gems/1.9.1/gems/chef-10.16.2/lib/chef/knife/status.rb:58:in `each'
        from /usr/lib64/ruby/gems/1.9.1/gems/chef-10.16.2/lib/chef/knife/status.rb:58:in `run'
        from /usr/lib64/ruby/gems/1.9.1/gems/chef-10.16.2/lib/chef/knife.rb:408:in `run_with_pretty_exceptions'
        from /usr/lib64/ruby/gems/1.9.1/gems/chef-10.16.2/lib/chef/knife.rb:168:in `run'
        from /usr/lib64/ruby/gems/1.9.1/gems/chef-10.16.2/lib/chef/application/knife.rb:123:in `run'
        from /usr/lib64/ruby/gems/1.9.1/gems/chef-10.16.2/bin/knife:25:in `<top (required)>'
        from /usr/bin/knife:23:in `load'
        from /usr/bin/knife:23:in `<main>'

Well that does not tell me the exact reason of the problem, but my guess is, that ruby itself was updated during the latest package patching, but the gem files still staid the same. So the newer ruby would probably run into issues with the old gems.

To solve this, the gems have to be redownloaded and reinstalled (as root):

gem install knife-block --no-rdoc --no-ri
gem install knife-audit --no-rdoc --no-ri
gem install knife-preflight --no-rdoc --no-ri
gem install knife-essentials --no-rdoc --no-ri
gem install knife-env-diff --no-rdoc --no-ri
gem install knife-flip --no-rdoc --no-ri
gem install chef --no-rdoc --no-ri

Afterwards, the knife command worked again:

knife status -VV
DEBUG: Signing the request as xxx
DEBUG: Sending HTTP Request via GET to chef.example.com:443/search/node
DEBUG: ---- HTTP Status and Header Data: ----
DEBUG: HTTP 1.1 200 OK
DEBUG: server: nginx/1.1.19
DEBUG: date: Fri, 03 May 2013 11:13:00 GMT
DEBUG: content-type: application/json; charset=utf-8
DEBUG: transfer-encoding: chunked
DEBUG: connection: close
DEBUG: ---- End HTTP Status/Header Data ----
2 minutes ago, linux15, linux15.example.com, 10.0.34.15, centos 6.3.

I just had to solve a spamming issue on a shared hosting server, where a Joomla 1.5 (time to upgrade, eh?!) was hacked and used to upload several files, one of them a cgi web shell:

The interesting thing is, that this file extension doesn't end in ".cgi" or ".php", which makes it more difficult to automatic search mechanisms, which for example search for uploaded php files, to discover the file.
The hacker uploaded a .htaccess file into the cgiweb folder, declaring that the file extension ".root" should be used as cgi-script through AddHandler definition.

When the correct password was given, shell commands could be executed in the web shell, for example uname:

How to solve this? Well, a temporary solution is to delete the uploaded files and folders. But as old and end of life Joomla versions are and will stay vulnerable, the only real solution is that this web-customer upgrades his Joomla CMS.