Ahoy there! This is my personal blog which I use as my memory extension and a medium to share stuff that could be useful to others.

At times, you may not be able to open a KVM session with a CISCO UCS Blade because somebody has left an active KVM session and is no longer around to accept your request to share the session or disconnect his/her session. In such situations, you will have to disconnect the active KVM session and here’s how you do it. For the instructions below, let’s assume you wish to disconnect an active KVM session on Blade 1 in Chassis 1.

  • Login into the UCS Manager Web UI.
  • Go to the Equipment tab in the left pane.
  • Navigate the hierarchy to Equipment (+) –> Chassis (+) –> Chassis1 (+) –> Servers (+) –> Server1
  • Click on "Recover Server" in the main window for Server1 (right) and you will see the following window pop up
    CiscoUCS_ResetKVM
  • Click Reset KVM Server and confirm that you want to continue.

NOTE: The above instructions have been tested with CISCO UCS Manager 2.0 (1s)

VN:F [1.9.22_1171]
Rating: +4 (from 4 votes)

Problem:

The logrotate process caused high CPU utilization, ran for about 5-6 hours and finally exited with a non-zero (failure) exit code.

Background & Analysis:

Observed this problem on one of our RHEL 3 hosts. A new daily job was added and this job specified log rotation for all files in a directory (rather than a file or specific patterns to match files) and used the compress option. Consequently, logrotate compressed files that were already compressed and so on and files in the directory started having very long filenames (e.g. test.dmp.gz.gz.1.gz.1.gz…) and a huge number of files were present in the directory, making logrotate’s job more and more difficult, thereby causing logrotate to consume high CPU (system cpu utilization %) and take longer to complete. Also, logrotate’s state file (/var/lib/logrotate.status) ended up being about 58 MB.

Solution:

  • Modify the daily job to rotate only files matching a specific pattern (in my case, I removed the daily job as it was redundant. The files were created with timestamp prefixes and so rotation wasn’t required).
  • Remove logrotate’s state file (/var/lib/logrotate.status). When done, logrotate will generate a new state file.

NOTE: The removal of logrotate’s state file is akin to running logrotate for the first time. So, you can modify the dates in the state file to reflect the previous day or the previous week before running a daily or weekly job to ensure logrotate rotates the files on its first run. ALternatively, use the logrotate –f option.

Root Cause:

Improper configuration of logrotate for a daily job.

(1) The solution above describes a successful problem-solving experience and may not be applicable to other problems with similar symptoms.

(2) Your rating of this post will be much appreciated as it gives me and others who read this article, an indication of whether this solution has worked for people other than me. Also, feel free to leave comments.

 

VN:F [1.9.22_1171]
Rating: +2 (from 2 votes)

Problem:

When trying to connect to a server via SSH, the authentication is slow (takes a few seconds), but the server seems normally responsive after authentication.

Background & Analysis:

I’ve experienced this problem when trying to connect to Linux hosts using SSH. Som of my Linux hosts use OpenSSH and some use Reflection for Secure IT Server.

When authenticating via SSH, the SSH server will perform a reverse domain lookup of the client’s IP address and this delays the authentication process.

SSH servers have options in their configurations to disable the reverse domain lookup of clients’ IP addresses.

Solution:

Disable reverse domain lookup of the client’s IP address in the SSH Server Configuration. Given below are examples of how this is done in two SSH servers:

OpenSSH: Edit /etc/ssh/sshd_config (or wherever your config file is) and set

UseDNS=no

RSIT: Edit /etc/ssh2/sshd2_config and set

ResolveClientHostname=no

Root Cause:

Slow Reverse Domain Lookup of clients’ IP addresses.

 

(1) The solution above describes a successful problem-solving experience and may not be applicable to other problems with similar symptoms.

(2) Your rating of this post will be much appreciated as it gives me and others who read this article, an indication of whether this solution has worked for people other than me. Also, feel free to leave comments.

 

VN:F [1.9.22_1171]
Rating: +5 (from 5 votes)

In trying to make my team aware of what’s in our team’s wiki (based on Mediawiki), I wanted a simple notification to go out to the team daily listing the new wiki pages created on the previous day. This may be achieved with a simple shell script that queries the Mediawiki recentchanges table.

STEP 1: Deploy Shell Script

The following script queries the recentchanges table and fetches data for pages created (rc_type = 1) the previous day in the Main namespace (rc_namespace = 0).

#!/bin/bash
# Author         :       Cybergavin (http://www.cybergav.in)
# Date Created   :       31st March 2012
# Description    :       This simple script queries the Wiki database and sends a notification to specific users regarding page creation. Reminds users about the existence of the wiki and what's in there.
#####################################################################################
#
# Variables
#
EMAIL_RECIPIENTS="wikiusers@abc.com"
REPORT_DATE=$(date '+%Y%m%d' --date="yesterday")
REPORT_DATE_FORMAIL=$(date '+%d-%b-%Y' --date="yesterday")
WIKI_BASEURL="http://wiki.abc.com/wiki/index.php/"
#
# Functions
#
getDBdata()
{
mysql -u wiki -p'xxxxx' --skip-column-names wiki <<EOSQL
connect wiki;
select rc_title, rc_user_text from recentchanges
where rc_timestamp like '$REPORT_DATE%'
and rc_type = 1
and rc_namespace=0;
quit
EOSQL
}
#
# Main
#
mail -s "Tech Ops Wiki : New Page Notification For $REPORT_DATE_FORMAIL" $EMAIL_RECIPIENTS <<EOMAIL
Hi

Given below are Pages created on the ABC Wiki ( http://wiki.abc.com ) yesterday ($REPORT_DATE_FORMAIL) along with their authors:

`getDBdata | awk -v a="$WIKI_BASEURL" '{printf "%-70s %s %s\n", a$1,"-", $2}'`

EOMAIL
#
##################################### T H E     E N D ###############################

NOTE:
(1) You must change certain variables and the body of the email as per your requirements.
(2) If your wiki isn’t updated with new pages very often, you may send this notification weekly. To do so, simply replace “yesterday” by “last week” on lines 11 and 12 and replace “where rc_timestamp like ‘$REPORT_DATE%'” by “where rc_timestamp > $REPORT_DATE0000”

STEP 2: Cron the Shell Script

Set up a cron job to send a daily notification. The example below executes the script daily at 9 AM.

0 9 * * * /opt/support/wikiPCnotify.sh > /opt/support/wikiPCnotify.out 2> /opt/support/wikiPCnotify.err 
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Unknown groups in SLES

Problem:

On SLES 11 SP 1, while trying to add users with the useradd command, the following is displayed:

useradd: Unknown group `video’.
useradd: Unknown group `dialout’.

Background & Analysis:

The “video” and “dialout” groups are default groups in SLES. This is configured in /etc/default/useradd.

These groups were removed from /etc/group using the groupadd command although the useradd command uses them as default groups.

Solution:

STEP 1: Modify /etc/default/useradd

Edit /etc/default/useradd and remove video and dialout from the GROUPS directive. After doing so, my /etc/default/useradd looks like this (I have removed the GROUPS directive as I do not want default groups):

GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes

 

 

VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)
 Page 6 of 33  « First  ... « 4  5  6  7  8 » ...  Last »