Ubuntu 12.04 LTS in Virtualbox SLOOOOOWWWWWW

I've been trying to install Ubuntu 12.04 LTS in Virtualbox 4.2.4 for about a week now.  It would install eventually, but it was slow to do so, and almost unbearable to actually try to use.  Someone mentioned that if you had multiple CPUs configured for the VM, change it to one.  I had only one CPU assigned, so I changed it to two, and restarted my install.  It completed in less than five minutes.  Moral, if your having performance issues installing or using Ubuntu 12.04 LTS, make sure you're using more than one CPU.

Linux Mint 14 - Suggestions in Search Bar from Google - Why doesn't this work?

So, I've been demoing various Linux OS' for a few days trying to figure out what to use to replace Ubuntu (12.10).  I didn't like Unity, I just didn't like the approach they were using.  I tried out three or four other distro/versions/respins before I tried out Linux Mint 14 (Cinnamon).  After a couple of hours of playing around with it, I was convinced that it was the right choice for my work flow/environment/etc.  I notice that Firefox doesn't even include Google for use in the Search Bar.  Fine, I follow their procedure and add it.  I look stuff up, I get a lot of Abstracts and papers, and not the results I was looking for.  Turns out I'd installed the Google Scholar search engine instead of the plain Google.  Fine.  Correct that, and now while I can search and they return "correct" results, I'm not getting any "suggestions" as I type my searches in to the Search Bar.  After a few hours (too many) I begin to suspect that its the search provider xml that is installed via the Linux Mint website,  I pull a copy of the search provider off a Windows box, drop it in the searchplugins directory, and magically it all work now.  The big tip off is that the Google icon for the version install by the Linux Mint website used a different icon.

Hope that helps someone.


*EDIT* - You can also download a fresh copy of Firefox and extract the searchplugin xml files from there and copy them over to your profile.

**EDIT** - You can also look through the Google entries at http://mycroft.mozdev.org/ to find a search provider that does what you want (I wanted Suggestions).

Zenoss - WMI Counters for Disks

I mentioned previously that I was having an issue with my step-child monitoring system, Zenoss, where the WMI disk counters were not behaving correctly.  The disks would be found when the system was modeled (or re-modeled) but they would always show up "bad counter for..", instead of you know, working.  My original train of thought was related to the zWinUser and zWinPassword properties that were used to collect WMI stats from all of our Windows boxen.  However, I wasn't entirely convinced because we use the same user/password for all of the Windows systems in that domain, and none of the others was exhibiting this behavior.  After some more research and a little bit of actively NOT thinking about the problem, I realized that the all of the other WMI events/stats were being pulled just not disks.  It turns out you can disable perf counters for disks via the registry in W2k3 server, via this key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Perfdisk\Performance\Disable Performance Counters

On my server that was acting up, this was set to 1.  I changed the value to 0,  and remodeled the device (its Zenoss, I do it everytime I change something) and all my events cleared themselves.

Pulling zWinUser and zWinPassword out of Zenoss ZopeDB

In my continuing saga of having to maintain a sparsely documented Zenoss instance.  I was trying to troubleshoot some WMI errors (that will be a later post), but I had no idea what the password was for the user we are using to pull this information from our various Windows servers.  And yes, I could have reset the password, but that may open a whole other can of worms that I didn't want to deal with.  So, using zendmd, which I mentioned previously, I used the following to pull zWinUser and zWinPassword:

$ zendmd
Welcome to the Zenoss dmd command shell!
'dmd' is bound to the DataRoot. 'zhelp()' to get a list of commands.
Use TAB-TAB to see a list of zendmd related commands.
Tab completion also works for objects -- hit tab after an object name and '.'
 (eg dmd. + tab-key).
>>> d = dmd.Devices.findDevice('192.168.1.11')
>>> d.zWinUser,d.zWinPassword
('DOMAIN\\user', 'password')
>>>

Good luck and godspeed...

Zenoss ZopeDB Access

So, I'm sort of tangentially in charge of our Zenoss monitoring system, and on and off over the past couple of years I've derided the fact that Zenoss decided to store the important information about objects in a Zope database, and I couldn't figure out how to query it without writing Python to interact with it programatically.  Today, I guess I stumbled across the right set of search terms for Google to spit out something genuinely useful: zendmd.  I'm not going to get in to how to use it, as there is some at least decent information out there, and once you get in, its very Python interpreter-y, it should be easy to get your bearings.

Permission Denied when excuting a script on OpenMediaVault

Couldn't execute my AV scan script for my downloaded files:

root@omv:/media/data/usenet/scripts# ./av_scan.sh
-bash: ./av_scan.sh: Permission denied
root@omv:/media/data/usenet/scripts# ls -lah av_scan.sh
-rwxr-xr-x 1 root root 71 Jul  9 23:20 av_scan.sh

Fought with it for a couple of hours on and off before I realised what might be going on:

 # mount

<snip>

/dev/mapper/data_vg-data_lv on /media/fa12c9af-de6a-4068-b55f-71d798ee8b6b type xfs (rw,noexec,usrquota,grpquota)

The OpenMediaVault developer made a decision that nothing on the "data" filesystem should be allowed to be executed.  I understand why it might be best for it to be that way, so I relocated the scripts to a directory on another filesystem, and everything works as it should.

Getting a SYBA Serial card working under Debian Squeeze

I have a SYBA SY-PCI15003 that I used previously to connect to a UPS under FreeBSD 7.3 (FreeNAS).  When I moved that system over to run Debian Linux Squeeze (OpenMediaVault), NUT would not detect my UPS.  I read a bunch of pages, went down a few blind alleys, and eventually just figured it out myself.  So, here's what I did to get the serial port to be usable again:

1) Is the card detected at all, yes it is:

lspci -v

04:05.0 Serial controller: NetMos Technology PCI 9865 Multi-I/O Controller (prog-if 02 [16550])
    Subsystem: Device a000:1000
    Flags: medium devsel, IRQ 17
    I/O ports at bce8 [size=8]
    Memory at df9fb000 (32-bit, non-prefetchable) [size=4K]
    Memory at df9fc000 (32-bit, non-prefetchable) [size=4K]
    Capabilities: [48] Power Management version 2

04:05.1 Serial controller: Illegal Vendor ID Device 9865 (prog-if 02 [16550])
    Subsystem: Device a000:1000
    Flags: medium devsel, IRQ 18
    I/O ports at bcf0 [size=8]
    Memory at df9fd000 (32-bit, non-prefetchable) [size=4K]
    Memory at df9fe000 (32-bit, non-prefetchable) [size=4K]
    Capabilities: [48] Power Management version 2

04:05.2 Serial controller: Illegal Vendor ID Device 9865 (prog-if 00 [8250])
    Subsystem: Device a000:0000
    Flags: medium devsel, IRQ 19
    I/O ports at bcf8 [size=8]
    I/O ports at <unassigned>
    Memory at df9ff000 (32-bit, non-prefetchable) [size=4K]
    Capabilities: [48] Power Management version 2
    Kernel driver in use: serial

 2) What does the system think IRQ/IO for the device is:

# setserial -a /dev/ttyS0
/dev/ttyS0, Line 0, UART: unknown, Port: 0x03f8, IRQ: 19
    Baud_base: 115200, close_delay: 50, divisor: 0
    closing_wait: 3000
    Flags: spd_normal skip_test

3) Since this configuration doesn't work, let's change it to point to the parent device:

setserial /dev/ttyS0 uart 16550 irq 17 port 0xbce8


The documentation for the device states that the uart is a 16550, and lspci -v gave the IRQ and the I/O port (make sure that you include the 0x before the I/O port).  After the changes its looks like this:

# setserial -a /dev/ttyS0
/dev/ttyS0, Line 0, UART: 16550, Port: 0xbce8, IRQ: 17
    Baud_base: 115200, close_delay: 50, divisor: 0
    closing_wait: 3000
    Flags: spd_normal

4) Test. I already had NUT configured for my UPS, so my testing was as easy as starting up the service and it actually finding the UPS.  There's tons of info about how to test your serial ports, so I won't go into that here.

5) Make configuration persistent.  This will depend on what distribution you're using, for Debian Squeeze, I found the easiest thing to do was use /etc/serial.conf.  Mine didn't exist, but the contents of the file are very simple, its just the arguments to setserial, in my case I could create it thusly:

# echo "/dev/ttyS0 uart 16550 irq 17 port 0xbce8" >> /etc/serial.conf

6) Reboot if you'd like, to make sure it correctly persists.

C'est fini!