[user1@testserver ~]$ openssl s_client -connect mail.google.com:443

CONNECTED(00000003)
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDIjCCAougAwIBAgIQHxn23jXdY6FCkYrVLMCrEjANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x
MTEyMTgyMzU5NTlaMGkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRgw
FgYDVQQDFA9tYWlsLmdvb2dsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBANknyBHye+RFyUa2Y3WDsXd+F0GJgDjxRSegPNnoqABL2QfQut7t9CymrNwn
E+wMwaaZF0LmjSfSgRSwS4L6ssXQuyBZYiijlrVh9nbBbUbS/brGDz3RyXeaWDP2
BnYyrVFfKV9u+BKLrebFCDmzQ0OpW5Ed1+PPUd91WY6NgKtTAgMBAAGjgecwgeQw
DAYDVR0TAQH/BAIwADA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnRoYXd0
ZS5jb20vVGhhd3RlU0dDQ0EuY3JsMCgGA1UdJQQhMB8GCCsGAQUFBwMBBggrBgEF
BQcDAgYJYIZIAYb4QgQBMHIGCCsGAQUFBwEBBGYwZDAiBggrBgEFBQcwAYYWaHR0
cDovL29jc3AudGhhd3RlLmNvbTA+BggrBgEFBQcwAoYyaHR0cDovL3d3dy50aGF3
dGUuY29tL3JlcG9zaXRvcnkvVGhhd3RlX1NHQ19DQS5jcnQwDQYJKoZIhvcNAQEF
BQADgYEAicju7fexy+yRP2drx57Tcqo+BElR1CiHNZ1nhPmS9QSZaudDA8jy25IP
VWvjEgaq13Hro0Hg32ZNVK53qcXwjWtnCAReojvNwj6/x1Ciq5B6D7E6eiYDSfXJ
8/a2vR5IbgY89nq+wuHaA6vspH6vNR848xO3z1PQ7BrIjnYQ1A0=
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 1778 bytes and written 316 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: DEB23CF699255054E08F69181B2342E9F6D6DF0D02B399C36034E0D8BE18AC0C
    Session-ID-ctx:
    Master-Key: D696A99CEC2FDD9535FE2EC936531AD129FD97E56441E37AE7A143C40304E395EA7DA039797B948B009B42DA5377E668
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1267560715
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
HTTP/1.0 400 Bad Request
Content-Type: text/html; charset=UTF-8
Content-Length: 1350
Date: Tue, 02 Mar 2010 20:11:57 GMT
Server: GFE/2.0
X-XSS-Protection: 0

First, go into the VMware console and right-click on the VM (Virtual Machine) that you are going to install VMware tools on.  Select “Install/Upgrade VMware Tools” option from the list.  Below is a screen shot of the menu.

VMware Tools Menu

By default, most CDROM devices are symbolically linked to /dev/cdrom by the operating system.

Just in case, you can search the messages file to see the actual device. This is needed only if /dev/cdrom is not automatically linked or you have setup multiple cdrom devices on the VM (Virtual Machine).

[root@RHserver01 media]# cat /var/log/messages | grep CDROM
Jan 10 10:59:03 RHserver01 kernel: hda: VMware Virtual IDE CDROM Drive, ATAPI CD/DVD-ROM drive

From above, you can see that the actual device is hda, specifically /dev/hda. If you are just curious you can do an “ll” on the /dev/cdrom device to see where is it linked to. In this case again, it’s going to hda.

[root@RHserver01 ~]# ll /dev/cdrom
lrwxrwxrwx 1 root root 3 Jan 12 13:18 /dev/cdrom -> hda

Mount the cdrom device to an empty or non-mounted point on the filesystem. Here I use the defaultly present /media location.

[root@RHserver01 /]# mount /dev/cdrom /media/
mount: block device /dev/cdrom is write-protected, mounting read-only

Below we move into the /media location using “cd”.

[root@RHserver01 /]# cd /media/

“ls” is used to display what files are present. Here we see both an RPM (native RedHat based OS package) and a gzip archive. If you were installing VMware Tools on a non-RedHat derived distribution, you would use the .gz package.

[root@RHserver01 media]# ls
VMwareTools-3.5.0-143128.i386.rpm  VMwareTools-3.5.0-143128.tar.gz

Since we are on RedHat, this is simple. Pass “-i” to the rpm command then the package name to be installed.

[root@RHserver01 media]# rpm -i VMwareTools-3.5.0-143128.i386.rpm

Immediately after installing the RPM, you might see the following errors to your console, or in /var/log/messages.

Jan 12 13:15:07 RHserver01 kernel: VFS: busy inodes on changed media or resized disk hda
Jan 12 13:15:07 RHserver01 kernel: VFS: busy inodes on changed media or resized disk hda

If you are getting these to the console, it makes it hard to continue working form the command line. This is easy to stop. First, cd out of the /media/ mount point

[root@RHserver01 ~]# cd ..

Next, unmount the cdrom device. After doing so, the messages will stop

[root@RHserver01 ~]# umount /dev/cdrom

The “vmware-config-tools.pl” command must be ran from the VMware console. Below is the output you would get if it was tried through a remote session (SSH).

[root@RHserver01 ~]# vmware-config-tools.pl

It looks like you are trying to run this program in a remote session. This
program will temporarily shut down your network connection, so you should only
run it from a local console session. Are you SURE you want to continue?
[no]
Please re-run this program from a local console shell.
Execution aborted.

There is a good reason for this. vmware-config-tools.pl drops networking on the server to install the VMware network drives. In doing so, you loose remote connectivity.

Below shows the actual output from vmware-config-tools.pl on the console

[root@RHserver01 ~]# vmware-config-tools.pl
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Stopping VMware Tools services in the virtual machine:
   Guest operating system daemon:                          [  OK  ]
   Unmounting HGFS shares:                                 [  OK  ]
   Guest filesystem driver:                                [  OK  ]
   Guest memory manager:                                   [  OK  ]
Trying to find a suitable vmmemctl module for your running kernel.

The module bld-2.6.18-8.el5-i686smp-RHEL5 loads perfectly in the running
kernel.

Trying to find a suitable vmhgfs module for your running kernel.

The module bld-2.6.18-8.el5-i686smp-RHEL5 loads perfectly in the running
kernel.

Trying to find a suitable vmxnet module for your running kernel.

The module bld-2.6.18-8.el5-i686smp-RHEL5 loads perfectly in the running
kernel.

Trying to find a suitable vmblock module for your running kernel.

The module bld-2.6.18-8.el5-i686smp-RHEL5 loads perfectly in the running
kernel.

No X install found.

Starting VMware Tools services in the virtual machine:
   Switching to guest configuration:                       [  OK  ]
   Guest memory manager:                                   [  OK  ]
   Guest vmxnet fast network device:                       [  OK  ]
   DMA setup:                                              [  OK  ]
   Guest operating system daemon:                          [  OK  ]

The configuration of VMware Tools 3.5.0 build-143128 for Linux for this running
kernel completed successfully.

You must restart your X session before any mouse or graphics changes take
effect.

You can now run VMware Tools by invoking the following command:
"/usr/bin/vmware-toolbox" during an X server session.

To use the vmxnet driver, restart networking using the following commands:
/etc/rc.d/init.d/network stop
rmmod pcnet32
rmmod vmxnet
depmod -a
modprobe vmxnet
/etc/rc.d/init.d/network start

If you wish to configure any experimental features, please run the following
command: "vmware-config-tools.pl --experimental".

Enjoy,

--the VMware team

Notes: From my experience, restart of networking via init.d scripts or rebooting the server is always needed. I personally always reboot the server to be safe.

testuser@workstation4-l:~$ ssh test123@ldapclientsrv
Connection closed by 172.16.0.192

To begin, lets look at a typical error that you would get on the system if LDAP communication was down.

Dec 13 12:52:58 ldapServer sshd[15965]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.16: Can't contact LDAP server
Dec 13 12:52:58 ldapServer sshd[15965]: nss_ldap: reconnecting to LDAP server (sleeping 4 seconds)...
Dec 13 12:53:02 ldapServer sshd[15965]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.16: Can't contact LDAP server
Dec 13 12:53:02 ldapServer sshd[15965]: nss_ldap: reconnecting to LDAP server (sleeping 8 seconds)...
Dec 13 12:53:10 ldapServer sshd[15965]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.16: Can't contact LDAP server
Dec 13 12:53:10 ldapServer sshd[15965]: nss_ldap: reconnecting to LDAP server (sleeping 16 seconds)...

As noted before, I was unable to login with a local account. Turns out that the problem was with the default “bind_policy” in /etc/ldap.conf.  Per the document:

# Reconnect policy: hard (default) will retry connecting to
# the software with exponential backoff, soft will fail
# immediately.
#bind_policy hard

This was changed to:

bind_policy soft

Once this was changed, I brought up the firewall on the LDAP server and refused connections. Ability to login via LDAP was gone, but the server did fail back to local system authentication

Note(s): When failing back to local authentication, there is no error sent back to the client trying to login, only errors go to /var/log/secure file. The server will just keep rejecting the users login until LDAP is back up. At least this gives you the ability to get in with a local system account in an emergency.

Example error to /var/log/secure when LDAP server is down and local authentication is rejecting the LDAP user received from the client:

Dec 13 12:59:59 ldapServer sshd[2588]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.0.22

I am very picky when it comes to my Cisco devices. A lot of information I read on this had the schedule execute “copy running-config startup” and would only backup one configuration. This is not a good thing, especially when there are multiple device managers. Below will go through setting up two jobs that backup both the running and saved configurations to different files daily.

Note: This assumes that you already have a TFTP server running on the network.

After logging into the switch, move into configuration mode

FiberSw01# config terminal
Enter configuration commands, one per line.  End with CNTL/Z.

Enable the scheduler

FiberSw01(config)# scheduler enable

Crate a job named “backup_running”

FiberSw01(config)# scheduler job name backup_running

Enter the syntax used to copy the running configuration to your TFTP server

FiberSw01(config-job)# copy running-config tftp://172.0.0.22:69/config/FiberSw01_running

Exit configuration mode

FiberSw01(config-job)# end

Now that we have a job defined, make sure it is listed with the scheduler

FiberSw01# show scheduler job
Job Name: backup_running
------------------------
   copy running-config tftp://172.0.0.22:69/config/FiberSw01_running
==============================================================================

With the job defined, we can go back in and set when we want it executed

FiberSw01# config terminal
Enter configuration commands, one per line.  End with CNTL/Z.

Define a new schedule name and set execution time(s)

FiberSw01(config)# scheduler schedule name Backup_Running
FiberSw01(config-schedule)# time daily 23:00
FiberSw01(config-schedule)# job name backup_running
FiberSw01(config-schedule)# end

Now the schedule(s) can be listed with names, execution times, and status

FiberSw01# show scheduler schedule
Schedule Name       : Backup_Running
------------------------------------
User Name           : user
Schedule Type       : Run every day at 23 Hrs 0 Mins
Last Execution Time : Yet to be executed
-----------------------------------------------
     Job Name            Last Execution Status
-----------------------------------------------
    backup_running                        -NA-
==============================================================================

Since the running configuration was backed up previously, we can go in configure the startup configuration backup. All commands are close to above except the tftp file name

FiberSw01# config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
FiberSw01(config)# scheduler job name backup_startup
FiberSw01(config-job)# copy startup-config tftp://172.0.0.22:69/config/FiberSw01_startup
FiberSw01(config-job)# end

FiberSw01# config t
Enter configuration commands, one per line.  End with CNTL/Z.
FiberSw01(config)# scheduler schedule name Backup_Startup
FiberSw01(config-schedule)# time daily 23:05
FiberSw01(config-schedule)# job name backup_startup
FiberSw01(config-schedule)# end

Check the schedule once more and both jobs show up

FiberSw01# show scheduler schedule
Schedule Name       : Backup_Running
------------------------------------
User Name           : user
Schedule Type       : Run every day at 23 Hrs 0 Mins
Last Execution Time : Yet to be executed
-----------------------------------------------
     Job Name            Last Execution Status
-----------------------------------------------
    backup_running                        -NA-
==============================================================================
Schedule Name       : Backup_Startup
------------------------------------
User Name           : user
Schedule Type       : Run every day at 23 Hrs 5 Mins
Last Execution Time : Yet to be executed
-----------------------------------------------
     Job Name            Last Execution Status
-----------------------------------------------
    backup_startup                        -NA-
==============================================================================
Now that the configuration is done, save the current (running) configuration so the schedules will not be lost on reboot
FiberSw01# copy running-config startup-config
[########################################] 100%
Notes: The above was done on Cisco MDS Switches but should work on most other Ciso IOS versions.  Also, the Execution Status will change after the job is executed.

All WebSphere services must be stopped to install the WAS updates. On a standard installation, bcguser must be used to stop the service

[bcguser@WPGhost ~]$/opt/IBM/bcghub-simple/bin/./bcgStopServer.sh

We do not use ‘/opt’ for our WebSphere location, so change this if yours is different.

Next, use Update Installer to patch the WebSphere Application Server
[user@WPGhost ~]$ sudo /opt/IBM/WebSphere/UpdateInstaller/./update.sh

There is a gotcha here that had me “chasing my tail” for about 10 minutes. When going to install the WebSphere Partner Gateway fix pack, the Partner Gateway and WAS server must be started. Installation of the update will fail with error “user input validation”.

So before installing the WPG update, re-launch the Application Server and Partner Gateway

[bcguser@WPGhost ~]$ /opt/IBM/bcghub-simple/bin/./bcgStartServer.sh

Once done, launch IBM Update Installer again, passing the customized responce file for your environment. This needs to be executed as the root user, so sudo was used to allow xforwarding from a non-root account

[user@WPGhost ~]$ sudo /opt/IBM/WebSphere/UpdateInstaller/./update.sh -options /opt/IBM/bcghub-simple/responsefiles/bcgupdate_en_US.txt

Those are my miscellaneous notes about the update installation. Everything went fine here and I hope this fixes some of the SFTP issues we have been having.
This brings the WebSphere Partner Gateway Console form version 6.2.0.0.273 to 6.2.0.1.333

Notes: Here is the link to IBM’s website that lists the fixes that are provided in the update.

The main one that got me was integration with Oracle.   An overview of the installation steps are shown below:

So the problem came down to the ‘Database owner name’ and ‘Schema owner login’ being the same.  This typically is not an issue.  The worst part is that the WAS (WebSphere Application Server) and WPG (WebSphere Partner Gateway) installation would both complete successfully. Not only that, they system would run with no errors.

That being said, once I started the patching process, it would always fail.   So as a last resort, I tried changing the ‘Database user name’ and ‘Schema owner login’ to be different.   Thanks to DBA Eric’s recommendation.  This worked!

I decided to put this blog up because I could not find any useful information for this when searching.  The patching process is a pain and I might go into more details on it in more blogs later.  Anyone else ran into this issue?

The program that enables listing and modification on the expiration parameters is ‘chage’. Each individual user can view their account settings as shown below.
testuser@testServer:~$ chage -l testuser

Last password change					: Aug 07, 2009
Password expires					: Nov 05, 2009
Password inactive					: never
Account expires						: Aug 05, 1992
Minimum number of days between password change		: 90
Maximum number of days between password change		: 90
Number of days of warning before password expires	: 7

As you can see above, the last password change date is listed, as well as the expiration date for the current password. When executed from a non-privileged account, the user can only view their own account.

testuser@testServer:~$ chage -l root
chage: Permission denied.

Also, the non-privileged account can not change their settings either.

testuser@testServer:~$ chage -M 99 testuser
chage: Permission denied.

From the root account, you have to ability to modify all the settings for individual users.

root@testServer:~# chage
Usage: chage [options] [LOGIN]

Options:
  -d, --lastday LAST_DAY        set last password change to LAST_DAY
  -E, --expiredate EXPIRE_DATE  set account expiration date to EXPIRE_DATE
  -h, --help                    display this help message and exit
  -I, --inactive INACTIVE       set password inactive after expiration
                                to INACTIVE
  -l, --list                    show account aging information
  -m, --mindays MIN_DAYS        set minimum number of days before password
                                change to MIN_DAYS
  -M, --maxdays MAX_DAYS        set maximim number of days before password
                                change to MAX_DAYS
  -W, --warndays WARN_DAYS      set expiration warning days to WARN_DAYS

Before modification, I am going to turn off all expiration settings on the ‘testuser’ account. This is disabling password expiration on that individual account.

root@testServer:~# chage -E -1 -I -1 -m 0 -M 99999 testuser

No lets configure password aging for the test user. The first example below runs change in interactive mode.

root@testServer:~# chage testuser
Changing the aging information for testuser
Enter the new value, or press ENTER for the default

	Minimum Password Age [0]:
	Maximum Password Age [99999]: 90
	Last Password Change (YYYY-MM-DD) [2009-10-16]:
	Password Expiration Warning [7]:
	Password Inactive [-1]:
	Account Expiration Date (YYYY-MM-DD) [1969-12-31]: 2012-12-31

Verify that the settings took.

root@testServer:~# chage -l testuser
Last password change					: Oct 16, 2009
Password expires					: Jan 14, 2010
Password inactive					: never
Account expires						: Dec 31, 2012
Minimum number of days between password change		: 0
Maximum number of days between password change		: 90
Number of days of warning before password expires	: 7

The same can be accomplished using the command line, non-interactively.

root@testServer:~# chage -E 2012-12-31 -I -1 -m 0 -M 90 -W 7 testuser

With the above settings in place, the user should be warned 7 days before the password expires on their account. If the password is not changed before expiration day, on the next login the user will be forced to change their password.

Per RedHat,

The TLB is a limited hardware resource, so utilising a huge amount of physical memory with the default page size consumes the TLB and adds processing overhead – many pages of size 4096 Bytes equates to many TLB resources consumed.

This is where Huge Pages come in. Pages are created at a larger size than the default 4096 bytes, and each page will consume only one TLB resource. So you can see this is a huge benefit. Using Huge Pages decrease the number of TLB resources required.

Side Affect
This is great, depending on what you are trying to accomplish. Once the physical memory is mapped to a Huge Page, it can no longer be used for “normal” memory allocation. This is because the memory is no longer mapped by the kernel virtual memory manager. The applications that you want to dedicate the Huge Pages to have to have support for them.

Benefit
So here is the best part of Huge Pages. It is dedicated memory to be used by only applications that request them. This dedicated memory is stored in physical RAM and will NEVER be swapped out! Thus, guaranteeing a level of performance. When memory is swapped to disk, it’s a lot slower than RAM and decreases the performance of the process(s)/program(s) gets pushed there.

Now knowing that Huge Pages are stored in RAM, this also means that the allocated RAM is dedicated. This is a little bit redundant to the above, but I want to make sure this point is clear.

Example: If a server has 8gigs of RAM and 5gigs are allocated to Huge Pages, that only leaves 3gigs for all other processes, programs, and underlining operating system to use.

Below shows my Linux desktop that has the default page size of 4096 set

user@workstation:~$ cat /proc/meminfo | grep Huge
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       4096 kB

So as you can see, I have no Huge Pages reserved or in use. The next example is from a production Oracle database server

[root@OracleServer1 ~]# cat /proc/meminfo | grep Huge
HugePages_Total: 12200
HugePages_Free:     85
Hugepagesize:     2048 kB

So to calculate the space dedicated to Huge Pages from above, it is 12,200 x 2048 kB which gives us

24 985 600 kilobytes = 23.828125 gigabytes

In the 2.6x Linux kenel, Huge Pages are enabled using the CONFIG_HUGETLB_PAGE feature when compiling the kernel. Most “Enterprise” Linux OSs by default have this enabled. The ones that I know of are RedHat, CentOS, and possibly Fedora from version 4+.

Notes: Again, applications that you want to dedicate Huge Pages to must have support for them. Most memory intensive ones do, but check for this first.

All of this will not be detailed here but will be split up in 3 blogs. Below just shows the time it takes to use Linux to overwrite the disk device using /dev/urandom. This is done to make it just that much harder for a would be hacker to try and brute force the key on the encrypted partition. If this is not done, the un-used space would just show up as empty, allowing for a more targeted attack against the pseudo random filesystem. Being pseudo-random means that it is not truly random. This being the case, with a lot of time and computing power, an attacker might be able to either brute force or find a pattern in the encryption.

So why not use /dev/random? For me, this would take forever! I do not have any special hardware or scripts pulling information from the environment and adding to the entropy pool. The data on this drive not being national security grade, /dev/random will do the job.

I know that the drive is under /dev/sdb. With that information, it is as simple as using “dd” (built in Linux utility) to overwrite all blocks on the drive with pseudo-random data.

root@tstbox:~# dd if=/dev/urandom of=/dev/sdb
dd: writing to `/dev/sdb': No space left on device
312581810+0 records in
312581809+0 records out
160041886208 bytes (160 GB) copied, 40284.5 s, 4.0 MB/s

From above, it tool 40,284.5 seconds to overwrite the drive with urandom data. This equals ~11 hours and 19 minutes. Definitely still a long time, but a lot faster than if /dev/random was used.

This workstation is not an impressive computer. It is a single CPU dual core machine with 2 gigs of ram. Below is the info on one of the cores.

root@tstbox:~# cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
stepping	: 2
cpu MHz		: 1867.000
cache size	: 2048 KB
physical id	: 0
siblings	: 2

Notes: I wish I could use /dev/random and probably will eventually when I can sit a drive out for a week. Setting up external drives in this fashion is really geared towards data protection. Not only are the drives in a mirrored RAID (one can fail and everything would still run fine), important data is encrypted using a strong key. So who cares is the external enclosure walks away at a conference? I would be out ~190$ but the data will be safe.

First, make sure you put a copy of the license onto a tftp, ftp, or sftp server. The MDS switch supports all of those protocols. Here we will be using tftp.

Copy the license from TFTP server to bootflash (persistent storage)

mds9124# copy tftp://172.0.0.1/MDS20090209112333135513.lic bootflash:
Trying to connect to tftp server......
|
 TFTP get operation was successful

Install the license

mds9124# install license bootflash:MDS20090209112333135513.lic
Installing license .......done

Now that the new port license is installed we need to verify that it is working. Below shows the default licensing that came with the unit.

mds9124# show license default
Feature                               Default License Count
-----------------------------------------------------------------------------
FM_SERVER_PKG                         -
ENTERPRISE_PKG                        -
PORT_ACTIVATION_PKG                   8
10G_PORT_ACTIVATION_PKG               0
-----------------------------------------------------------------------------

The new one contained licensing for an additional 8 ports. Below you can see that now there are 16 ports licensed.

mds9124# show license usage
Feature                      Ins  Lic   Status Expiry Date Comments
                                 Count
--------------------------------------------------------------------------------
FM_SERVER_PKG                 No    -   Unused             -
ENTERPRISE_PKG                No    -   Unused             -
PORT_ACTIVATION_PKG           Yes  16   In use never       -
10G_PORT_ACTIVATION_PKG       No    0   Unused             -
-------------------------------------------------------------------------------

<pre>mds9124# copy tftp://172.0.0.1/MDS20090209112333135513.lic bootflash:
Trying to connect to tftp server......
|
TFTP get operation was successful</pre>
Install the license
<pre>mds9124# install license bootflash:MDS20090209112333135513.lic
Installing license .......done<pre>

<pre>mds9124# show license default
Feature                               Default License Count
-----------------------------------------------------------------------------
FM_SERVER_PKG                         -
ENTERPRISE_PKG                        -
PORT_ACTIVATION_PKG                   8
10G_PORT_ACTIVATION_PKG               0
-----------------------------------------------------------------------------<pre>

<pre>mds9124# show license usage
Feature                      Ins  Lic   Status Expiry Date Comments
Count
--------------------------------------------------------------------------------
FM_SERVER_PKG                 No    -   Unused             -
ENTERPRISE_PKG                No    -   Unused             -
PORT_ACTIVATION_PKG           Yes  16   In use never       -
10G_PORT_ACTIVATION_PKG       No    0   Unused             -
-------------------------------------------------------------------------------</pre>

The big difference when using ‘-s’ are listed below

[root@testServ01 ~]# printenv
HOSTNAME=testServ01.testDomain.com
SHELL=/bin/bash
TERM=xterm
HISTSIZE=1000
USER=root
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
INPUTRC=/etc/inputrc
PWD=/root
LANG=en_US.UTF-8
SHLVL=1
HOME=/root
LOGNAME=root
CVS_RSH=ssh
LESSOPEN=|/usr/bin/lesspipe.sh %s
DISPLAY=localhost:10.0
G_BROKEN_FILENAMES=1
_=/usr/bin/printenv

DISPLAY=localhost:10.0
HISTSIZE=1000
HOME=/home/testuser01
HOSTNAME=testServ01.testDomain.com
INPUTRC=/etc/inputrc
LANG=en_US.UTF-8
LOGNAME=root
MAIL=/var/spool/mail/testuser01
PATH=/usr/bin:/bin
PWD=/home/testuser01
SHELL=/bin/ksh
SUDO_COMMAND=/bin/ksh
SUDO_GID=500
SUDO_UID=500
SUDO_USER=testuser01
TERM=xterm
USER=root
USERNAME=root

# iptables -L
/bin/ksh: iptables: not found [No such file or directory]

# /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Quick way to find your serial number.

tstSwitch01# show license host-id
License hostid: VDH=SOZ115568P9

The following will also get the information that you need. I truncated some of the output. The serial number under the “Common block” is what we need.

tstSwitch01# show sprom backplane 1
DISPLAY backplane sprom contents:
Common block:
 EEPROM Size     : 1024
 Block Count     : 5
 FRU Major Type  : 0x6003
 FRU Minor Type  : 0x0
 OEM String      : Cisco Systems, Inc.
 Product Number  : DS-C9124-K9
 Serial Number   : SOZ115568P9
 Part Number     : 73-10565-03
 Part Revision   : A9
 Mfg Deviation   : 0
 H/W Version     : 1.0
 Mfg Bits        : 0
Chassis specific block:
 Block Signature : 0x5601
 MAC Addresses   : 00-0g-tr-46-n3-u6
 Number of MACs  : 64

This is a little easier to read. Here, an include statement is passed to only return lines including “Serial”. We need the first, not second serial number.

tstSwitch01# show sprom backplane 1 | include Serial
 Serial Number   : SOZ115568P9
Second Serial number specific block:
 Serial Number   : JFH2486G4DR

Notes: All actual serial numbers were changed. This process should be the same for all Cisco MDS 9000 series. If using a chassis based MDS switch, make sure to verify if you need the serial of the unit or the actual blade module for licensing.

http://blog.colovirt.com/2008/10/31/vmware-esx-server-partitioning/

The majority of the partitioning structure is the same what was used for 3.x. The only real changes is the fact that the installation process auto-creates two of the partitions that were to be manually created on 3.x. Those two partitions are:

As in the 3.x structure, again I still maintain that creating a seperate mount point for /var/core should be used. For the reasons stated below:From the 3.x post

“I have had a few servers core dump and drop over 5 gigs of data to /var/core. Before, per “best practices” a vendor recommended around 4 gigs for /var. I upped that to 6 gigs originally, but after 2 servers had /var 100% utilized I and revising that. /var is still 6 gigs but /var/core has been broken out into its own mount point. 15 gigs is a little high, but these servers had raid 1 – 73 gig hard drives. At least now if the servers core dump it will affect only its mount point. I highly recommend doing this!”

Below is how I am partitioning vSphere 4 servers

Notes: Yellow-Bricks (Duncan Epping), as well as VMETC have good articles as well.