Rick Wargo
March 2nd, 2010 - 06:50pm
I just enjoyed a delicious salad made with the following ingredients (quantities are approximate):
- 1/2 large head chopped romaine
- 2 carrots, diced
- 1 stalk celery, diced
- 1 large red bell pepper, diced
- 1/3 small can sliced beets, diced
- several artichoke hearts, diced
- 5 hearts of palm, diced
- 1/2 oz sunflower seeds
- 1 large plum tomato, diced
- 1 avocado, diced, large chunks
- 1 smallish sweet onion, diced
- Walden Farms Honey Dijon Dressing (Sugar Free, Calorie Free, Fat Free, Carb Free, Gluten Free) to taste
- pepper to taste
I used the Progressive International Fruit and Vegetable Chopper to diced the veggies and it works beautifully. With all the different colors, the salad has a beautiful presentation and a taste to match.
Rick Wargo
January 13th, 2010 - 11:45am
I added a new check command to nagios to check the sendmail mail queue but received an error while executing within nagios:
/usr/bin/mailq = can not chdir(/var/spool/mqueue/): Permission denied
Program mode requires special privileges, e.g., root or TrustedUser.
CRITICAL: Error code 78 returned from /usr/bin/mailq
This is because the nagios process (which runs as the nagios user) does not have the permissions to look at the spool directory for mail (/var/spool/mqueue) – the permissions on that directory are 700 and owned by root.
The fix is to permit nagios to execute this command as root and also to run the /usr/bin/mailq program with sudo in the check_mailq perl script.
Step 1: Modify check_mailq
Edit the check_mailq file, after making a backup of the file. Search for the place where the mailq is opened for reading from the pipe and add /usr/bin/sudo prior to the command. The resulting line looks like the following (note: this is does using sendmail as the MTA):
if (! open (MAILQ, "<em><strong>/usr/bin/sudo </strong></em>$utils::PATH_TO_MAILQ | " ) ) {
Step 2: Modify sudoers
Edit the sudoers file to give nagios permission to execute /usr/bin/mailq as root without requiring a password. I accomplished this by adding the following line to the end of the file:
nagios ALL= (root) NOPASSWD: /usr/bin/mailq
Test prior to reloading nagios by executing the check_mailq command as nagios:
su nagios -c "./check_mailq -w 5 -c 10"
If you see an error message about a tty, like:
sudo: sorry, you must have a tty to run sudo
or in nagios:
CRITICAL: Error code 1 returned from /usr/bin/mailq
you will need to either comment out the line about requiring the tty (Defaults requiretty), or add a new line not requiring the tty for nagios:
Defaults:nagios !requiretty
Rick Wargo
January 6th, 2010 - 11:33am
Ever since upgrading to Snow Leopard, my MacBook Pro often was unable to see the local network hosts. It turns out the mDNSResponder, now responsible for DNS caching, is rotating the order of the DNS Servers. Since I have my own DNS server that is the authority for my network, this should always be the first one checked. As it is also a home network, it made sense to have a backup DNS server pushed out via DHCP. However, it turns out that having the backup DNS server (my favorite: OpenDNS) in case the local one fails, actually causes the problem on the Snow Leopard machines.
I found a great amount of information regarding this at the Apple Support Discussions list. If this issue plagues you, many of the messages in this thread are a worthwhile read.
Rick Wargo
January 6th, 2010 - 10:31am
The following is useful when the linux machine is not correctly joined to a domain:
I have noticed a number of PROBLEM alerts from my Nagios 3.2.0 implementation on Fedora 12 when checking the available disk space on a WinXP share such as:
- Result from smbclient not suitable
- No Answer from Client
This used to work before upgrading both my Nagios and Fedora implementations.
To get this working once again, I’ve had to do two things – allow Nagios to login and specify the domain name as part of the user name on the check_disk_smb command.
To permit login to nagios, edit the passwd file with sudo vipw and change the shell to /bin/sh for nagios (should have been /sbin/nologin).
Next, in the private configuration file for Nagios, change the USER variable to be DOMAIN\\\\User; note the four backslashes are necessary. If that USER variable is being used elsewhere where the the new value would alter the results from other Nagios checks, add a new USER variable and update the configuration files accordingly.
Rick Wargo
December 28th, 2009 - 12:37pm
Using a freshly installed version of Ubuntu 9.10, I was unable to successfully install zoneminder using the apt-get install zoneminder command. Instead I was getting messages such as:
Unknown database 'zm' at /usr/share/perl5/ZoneMinder/Config.pm
To resolve I did the following (although I am not certain all the following steps were necessary):
- Purged apache2, mysql-client, mysql-server, mysql-core, and zoneminder. I did this using the Synaptic package manager but it just as easily be done using apt-get purge
- I executed
sudo apt-get --purge autoremove to clean all the additional packages
- I installed libdirac0c2a and libdirac-dev
- I installed mysql using
sudo apt-get install mysql-client mysql-server
- I installed apache using
sudo apt-get install apache2
- I removed the startup warning apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName by adding ServerName to the apache2.conf file in /etc/apache2.
- Executed
sudo apt-get install apache2-mpm-prefork to ensure it successfully restarted apache
- Installed nullmailer using
sudo apt-get install nullmailer and went through the configuration, setting my smarthost appropriately
- Installed the additional dependencies for zoneminder to ensure they all were successful using
sudo apt-get install ...
- Finally, I installed zoneminder successfully using
sudo apt-get install zoneminder
I believe the tricks were to install the nullmailer separately and also purge the existing apache, mysql, and zoneminder installations prior to the install.