Skip to content

iStat Menus alternative?

For quite some time now I'm using iStat Menus (now by Bjango). With its latest version 3, it's now a paid app and one is urged to upgrade for $16. I don't mind the price so much, but the only reason (for me!) to upgrade would be a fix to one particular bug, the rest is just bloat I won't need anyway. With that being the case, I'm now looking for alternative programs for the features I'm currently using:
  • smcFanControl - displays temperature and fanspeed in the menubar. It even offers to tweak the fanspeed (why would I want to do this??) but it doesn't display all the other sensors available. However it's opensource, so a big plus here!

  • MenuMeters - displays CPU and network load (also disk and memory, but I don't need that). Seems clean and simple enough. And it's free (not only as in "beer") too!

The only feature left is the clock from iStat Menus where you can have different timezones displayed and a calendar on top. But maybe I finally have to make friends with the dashboard now. Oh well...

Exim4 with clamd

Either my Xen DomU gets slower or my MTA keeps getting busier. But when looking at the stats I could see that a lot of clamscan have been spawned on every fetchmail. Nothing unusual, this is how it always worked. But to be honest, the setup was rather inefficient, to say the least: for every incoming mail, maildrop spawns a clamscan process, sometimes more than one in parallel. ps(1) shows, for just one process:
 PID  %MEM    RSS    SZ    VSZ  COMMAND
 8749 12.8 164500 49081 196324 clamscan
So, one process needs 12.8% of the systems memory, with just 5 process we're at 64% - and the box was indeed swapping heavily. So I finally got around *) to move the virus-scanning to Exim and let it speak to clamd instead:
  • /etc/exim4/conf.d/main/02_exim4-config_options
  •      +av_scanner = clamd:/var/run/clamav/clamd.ctl
    
  • /etc/exim4/conf.d/acl/40_exim4-config_check_data
  •      +  warn
         +    message = X-Virus-Status: Infected
         +    demime  = *
         +    malware = *
    
    Note: I chose warn over deny here - I still want to have those viruses, I just want to have it annotated :-)

  • /etc/clamav/clamd.conf
  •      User clamav
         AllowSupplementaryGroups true
         LocalSocketGroup Debian-exim
         LocalSocketMode 0660
    
For Debian/5.0, I also had to:
# usermod -G Debian-exim clamav
# mkdir -m0770 /var/spool/exim4/scan
# chown Debian-exim:Debian-exim /var/spool/exim4/scan
With all this in place (plus disabling the clamscan directives in .mailfilter), the box is far less loaded now. According to ps(1), our single clamd now goes sometimes up to 16%, but that's still just one process and better than those >60% before.

Btw, if you want to test your email AV setup and your mailprovider doesn't even allow the sending of the Eicar Test File, try this instead.

Update: And it helped indeed, see the loadavg going down after changing the configuration to use clamd now. Phew, now I wonder why I haven't done this earlier....

*) I hate MTA configurations, I really do :-\

Notice of Claim of Copyright Infringement, pt. II

Almost to the hour two months after the last email ("Harry Potter Audio Books", yeah...right) I got contacted again. This time someone thinks I'm distributing "Iron Man 2" (again, srsly?). The Tor legal FAQ was helpful as always, so...let's see how this one pans out - if it does anything at all, I haven't gotten any reply to the first letter yet (apart from a Zimbra-mangled auto-reply). Is this a good sign? No?

svn: Repository moved permanently; please relocate

Apparently, ispCP has changed its repository URL (why :800? Think of the children^Wfirewalls!), leading to:
$ svn update
svn: Repository moved permanently to 'http://isp-control.net/ispcp_svn/trunk' ; \
please relocate
Luckily, svn switch is here to help, the magic command to resolve this one was:
$ svn switch --relocate \
  http://www.isp-control.net/ispcp_svn http://isp-control.net:800/ispcp_svn .

$ svn info | grep -A1 ^URL
URL: http://isp-control.net:800/ispcp_svn/trunk
Repository Root: http://isp-control.net:800/ispcp_svn

That's When I Reach For My Resolver

So, the primary nameserver is down but luckily /etc/resolv.conf has been equipped with a secodary nameserver entry - great! And nslookup works like a charm too, heh! But all the other useful tools are waiting for ages until they'll get a response from the backup server - why is that?
$ time ping eve
eve is alive

real    0m30.045s
user    0m0.007s
sys     0m0.018s
Other than e.g. nslookup, the normal applications have to use the the resolver(4) to get their name requests answered. Now, we could cheat and put our backup server before the faulty one, but let's see if we can tackle this from a different angle. resolv.conf(4) was most helpful, of course:
options
   Allows certain internal resolver variables to be modified.

timeout:n / retrans:n
   Sets the amount of time the resolver will wait for a response from a remote 
   name server before retrying the query by means of a different name server.
   Measured in seconds, the default is RES_TIMEOUT. See 

attempts:n / retry:n

   Sets the number of times the resolver will send a query to its name 
   servers before giving up and returning an error to the calling application.
   The default is RES_DFLRETRY. See .
In our resolv.h (Solaris 10) we have :
$ egrep 'RES_TIMEOUT|RES_MAXRETRANS|RES_DFLRETRY' /usr/include/resolv.h
#define RES_TIMEOUT         5      /* min. seconds between retries */
#define RES_MAXRETRANS     30      /* only for resolv.conf/RES_OPTIONS */
#define RES_DFLRETRY        2      /* Default #/tries. */

So, let's tweak those options:
$ grep options /etc/resolv.conf 
options timeout:1 retry:1

$ time ping eve
eve is alive

real    0m7.794s
user    0m0.007s
sys     0m0.018s
Whooha, not bad.
Note: in Linux the retry: parameter is called attempts:

Let's tweak the retry: parameter a bit more:
$ grep options /etc/resolv.conf 
options timeout:1 retry:0

$ time ping eve
eve is alive

real    0m2.100s
user    0m0.007s
sys     0m0.018s
Even better. Of course, one has to realize that with zero retries the resolver will jump to the next nameserver on the first failure - so, if our backup server is a bit sleepy we won't get a reply at all. If you enable nscd, subsequent requests to the same name will be answered instantly:
$ sudo svcadm enable svc:/system/name-service-cache
$ time ping eve
eve is alive

real    0m3.218s
user    0m0.007s
sys     0m0.018s

$ time ping eve
eve is alive

real    0m0.198s
user    0m0.007s
sys     0m0.017s

VMware Server & Ubuntu 10.04

Wow, what a ride. Upgrading to Ubuntu 10.04 LTS worked flawlessy, as always (hint: use aptitude -V dist-upgrade this time, it's a bit more sophisticated than apt-get). But VMware Server 2.0.2 (i386) didn't like the new 2.6.32-22-generic-pae kernel too much. Lot's of warnings and the compilation errors were enough to look for solutions elsewhere. Finally, after hours of searching and trying, I propose 4 patches to be applied:
  • 00-vmware-2.6.32_functional.diff - this one fixes the actual compile errors and has been provided by drgr33n back in October 2009.

  • 01-vmware-2.6.32_cosmetic.diff - this one fixes (hides?) all the warnings. The patch is not mandatory (the modules will compile without it) but it makes it a lot easier to catch real error messages when it's applied. This patch is basically just implementing what rbihlmeyer proposed back in September 2009.

  • 02-vmnet-include.diff - while we're at it: I noticed that in vmnet.tar all the header- and source-files were in one directory, while they're located in include/ resp. linux/ for all the other modules. Again, not mandatory, but it's a nice cleanup, maybe the VMware guys will pick it up.

  • vmware-config.pl.diff - and finally, vmware-config.pl needs to be patched, so that the vsock.ko module can use the symbols from vmci it requires, otherwise the module fails to build. Thanks again, drgr33n!

With all these patches applied, running vmware-config.pl should look like this. You can use this script to do all the patching for you (be sure to alter the DIR and PATCHES variables to your needs).

A few more notes on the whole VMware shebang:
  • In my case it helped to boot both the host and the guest with clocksource=acpi_pm, otherwise the clock would skew away. YMMV though.

  • In the /var/log/vmware/hostd.log logfile, the following error message can be seen:
       An error occurred while loading configuration "../vmware-server/lib/vmware/settings",
       not all entries are being read. It is strongly encouraged that you manually 
       inspect the file and fix any corruptions.
       
    However, /opt/vmware-server/lib/vmware/settings does not even exist. VMware Server and its guests continue to run. Don't know what to make of this error yet...

  • As the old VMware console GUI has been discontinued, one is left with a Web GUI (https://server:8333). To access the actual console, one must install either vmware-vmrc-win32-x86.exe (for IE, but install-privileges are needed) resp. vmware-vmrc-{win32|linux}-x86.xpi (for Firefox, user rights sufficient). Of course, the VMware vSphere Client can also be used to access the VMware installation, but one has to pay for it, IIRC.