Colocation to Virtualization » Linux

Cisco, VMware: Cisco UCS B250-M1 VMware Consolidation Ratio (Oracle DBs)

Kevin Goodman — Tue, 01 Jun 2010 14:54:59 +0000

So a few days ago, I put out a post on the VMware Virtual Machine consolidation ratio I saw on our Cisco B200-M1 blades. This post will go over the same for full width B250-M1 blades.

The server itself is running mainly Oracle database VMs. Blade specs are as follows:

Dual – Quad core Intel Xeon X5570 2.93 GHZ CPUs

98 gigs of RAMSince the Oracle VMs are running semi-intensive databases, the RAM allocated to the heavy hitters are between 8-10 gigs.

B250m1 Stats From UCS

B250m1 Stats From Virtual Center

Now for the actual utilization statistics. The following is from Virtual Center showing the physical B250-M1 database server. You can see that the CPUs are more highly used in this environment.

B250m1 VC Utilization

Again, this is a mix between Windows Remote desktop and Oracle (RedHat Linux) database servers. The following shows utilization information perm VM.

B250m1_2 VM Utilization

Hopefully this gives you a little more information concerning Oracle, VMware, Cisco UCS, and consolidation ratios for the full-width blades. Again, this server is running 98gigs of RAM. Next purchase cycle, we will be upgrading the amount of RAM in all of our blades to get better consolidation.

Filed under: Colocation, Linux, VMWare

Storage, SAN, Linux: EMC PowerPath Configuration On Cisco UCS

Kevin Goodman — Tue, 04 May 2010 14:39:42 +0000

The following is a walk through of installing EMC PowerPath software on RedHat based Linux hosts (CentOS/Fedora). This is required to fully utilize multiple paths to EMC SANs. The test server used here is a Cisco UCS B250-M1 blade running FCOE over 10gb Ethernet. The configuration steps work for ISCSI, Fiber Channel, and FCOE connectivity to Clariion systems.

First, copy the RPM installation package over to the server. Below shows the package to be installed.

[root@test_server01 user01]# ll
total 7036
-rw-r--r-- 1 user01 user01 7191661 Apr 27 09:24 EMCpower.LINUX-5.3.1.00.00-111.rhel5.x86_64.rpm

Install the package via “rpm -i”.

[root@test_server01 user01]# rpm -i EMCpower.LINUX-5.3.1.00.00-111.rhel5.x86_64.rpm
All trademarks used herein are the property of their respective owners.
NOTE:License registration is not required to manage the CLARiiON AX series array.

Before powerpath can be used, a license key must be installed.

[root@test_server01 user01]# emcpreg -list
unable to open license key file: No such file or directory

Overview of the “emcpreg -add” syntax.

[root@test_server01 user01]# emcpreg -add
Missing option parameter.
Usage:
    emcpreg [opts] -add key [key ...]
    emcpreg [opts] -remove key [key ...]
    emcpreg [opts] -check key [key ...]
    emcpreg [opts] -list
    emcpreg [opts] -edit
    emcpreg [opts] -install
Options:
    -f file     license file

Now we add the license key to powerpath. The following key is fake! You must obtain yours from EMC.

[root@test_server01 user01]# emcpreg -add AGE4-DFD3-89842-DSAF-JIJ0-WKG50
1 key(s) successfully added.

Make sure the license was installed correctly.
[root@test_server01 user01]# emcpreg -list

Key AGE4-DFD3-89842-DSAF-JIJ0-WKG50
  Product: PowerPath
  Capabilities: All
[root@test_server01 user01]#

Next, start the Power Path service.

[root@test_server01 user01]# /etc/init.d/PowerPath start
Starting PowerPath:  done

Display the current paths to storage via “powermt”. Since this server is booting from SAN and just being installed, there is currently only one path to storage.

[root@test_server01 ~]# powermt display dev=all
Pseudo name=emcpowera
CLARiiON ID=AXE00515480482 [test_server01_ucs]
Logical device ID=15618646804648SDSDFW84FW4894949 [test_server01_ucs_boot]
state=alive; policy=CLAROpt; priority=0; queued-IOs=0
Owner: default=Unknown, current=SP A    Array failover mode: 1
==============================================================================
---------------- Host ---------------   - Stor -   -- I/O Path -  -- Stats ---
###  HW Path                I/O Paths    Interf.   Mode    State  Q-IOs Errors
==============================================================================
   0 fnic                      sda       SP A0     active  alive      0      0

Now that powerpath is installed, we need to edit fstab to boot off of the Power Path device.

Origional fstab using labels for “/boot”.

/dev/lvm/root           /                       ext3    defaults        1 1
/dev/lvm/usr            /usr                    ext3    defaults        1 2
/dev/lvm/app            /app                    ext3    defaults        1 2
/dev/lvm/home           /home                   ext3    defaults        1 2
/dev/lvm/var            /var                    ext3    defaults        1 2
/dev/lvm/vartmp         /var/tmp                ext3    defaults        1 2
/dev/lvm/UsrLocal       /usr/local              ext3    defaults        1 2
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SWAP-sda3         swap                    swap    defaults        0 0

Below is the edited fstab with “LABEL=/boot” commented out and /boot changed to use “/dev/emcpowera1″

[root@test_server01 ~]# vi /etc/fstab
/dev/lvm/root           /                       ext3    defaults        1 1
/dev/lvm/usr            /usr                    ext3    defaults        1 2
/dev/lvm/app            /app                    ext3    defaults        1 2
/dev/lvm/home           /home                   ext3    defaults        1 2
/dev/lvm/var            /var                    ext3    defaults        1 2
/dev/lvm/vartmp         /var/tmp                ext3    defaults        1 2
/dev/lvm/UsrLocal       /usr/local              ext3    defaults        1 2
/dev/emcpowera1         /boot                   ext3    defaults        0 0
#LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SWAP-sda3         swap                    swap    defaults        0 0

Filesystem options were changed to “0 0″ on emcpowera due to RedHat trying to do filesystem scans before the Power Path driver is started.

All paths now need to be zoned in the fiber switch, initiators registered in Navisphere, and paths added to the host in it’s storage group. This will not be covered here.

After zoning both paths on one switch, “powermt” now shows a path to both Clariion SPA and SPB. If not, try either stopping and restartaring “/etc/init.d/PowerPath” or restarting the server.

[root@test_server01 ~]# powermt display dev=all
Pseudo name=emcpowera
CLARiiON ID=AXE00515480482 [test_server01_ucs]
Logical device ID=15618646804648SDSDFW84FW4894949 [test_server01_ucs_boot]
state=alive; policy=CLAROpt; priority=0; queued-IOs=0
Owner: default=SP B, current=SP A       Array failover mode: 1
==============================================================================
---------------- Host ---------------   - Stor -   -- I/O Path -  -- Stats ---
###  HW Path                I/O Paths    Interf.   Mode    State  Q-IOs Errors
==============================================================================
   0 fnic                      sdc       SP B1     active  alive      0      0
   0 fnic                      sdd       SP A0     active  alive      0      0

Configuration has now been completed on fiber switch 2 and both SPA and SPB in the Clariion. Reboot the server. Again, “powermt” is used to list the paths.

[root@test_server01 ~]# powermt display dev=all
Pseudo name=emcpowera
CLARiiON ID=AXE00515480482 [test_server01_ucs]
Logical device ID=15618646804648SDSDFW84FW4894949 [test_server01_ucs_boot]
state=alive; policy=CLAROpt; priority=0; queued-IOs=0
Owner: default=SP B, current=SP B       Array failover mode: 1
==============================================================================
---------------- Host ---------------   - Stor -   -- I/O Path -  -- Stats ---
###  HW Path                I/O Paths    Interf.   Mode    State  Q-IOs Errors
==============================================================================
   0 fnic                      sdc       SP B1     active  alive      0      0
   0 fnic                      sdd       SP A0     active  alive      0      0
   1 fnic                      sde       SP B0     active  alive      0      0
   1 fnic                      sdf       SP A1     active  alive      0      0

From above, you can see that we now have 4 paths definied. Both fnic interfaces can see SPA and SPB. Each fnic is attached to a seperage fiber switch, so we have redundant paths to both Clariion heads (SP’s). Once rebooted, the server should load fine with no issues and see all paths via powermt.

Notes: “/boot” is the storage label used in this example. If your mount point is different, modify it’s entry instead. “/dev/emcpowera1″ is used since there is only one LUN mapped to this host. Like anything else, if there are more than one, each would have it’s own device.

Filed under: EMC, Filesystems, Linux, SAN (Storage Area Network)

Hardware, Linux, Networking: Cisco UCS Time Problem

Kevin Goodman — Wed, 28 Apr 2010 14:12:55 +0000

So we have our new Cisco UCS system installed and a weird problem is showing up. The Cisco UCS Manager console shows the correct date (2010), but when setting up a new server, the date is incorrect. Also, an NTP server (working correctly) is set. Since we mainly run Linux here, the NTP service will not update the date/time from the NTP server because of how long the difference is between the system clock and NTP. Also, on a Windows 2008 install we had to manually adjust the time/date as well

This is not a major issue, just an annoyance. We also use RedHat Satellite server and can not join to the patch management system with the incorrect date. So my question is where does the OS get it’s bad time from? I figure that the OS gets the time from the bios and that the bios would obtaion the information from UCS Manger. That does not appear to be the case.

Below is an example of the issue:

Cisco UCS Time

Above in the bottom right corner shows the correct time and date in the Cisco UCS Manager.

Below you can see that the date shows 2009 on a freshly installed server in UCS. The difference of the time and day are due to screen shots taking a day apart, but you get the idea. It’s not 2009.

Cisco UCS Bios Time

Server has just been installed and booted. The command “date” is issued to see the current time.

[root@test-server02 build]# date
Sat Aug 15 02:37:24 EDT 2009

As seen from above, the date is incorrect (2009). NTP needs to be updated, but the service must be stopped first, or else it will not accept the new time.

[root@test-server02 build]# /etc/init.d/ntpd stop
Shutting down ntpd:                                        [  OK  ]

Once stopped, “ntpdate” is used to query an NTP server and adjust the local server time.

[root@test-server02 build]# ntpdate pool.ntp.org
27 Apr 14:36:23 ntpdate[5214]: step time server 70.86.250.6 offset 22075095.967480 sec

Now that the system time is correct, NTP service is restarted to

[root@test-server02 build]# /etc/init.d/ntpd start
Starting ntpd:                                             [  OK  ]

From here on out, the time will be correct and sync with the NTP service withouth issue.

[root@test-server02 build]# date
Tue Apr 27 14:36:40 EDT 2010

Filed under: Hardware, Linux, Networking

Linux: Cat And Tac – Reverse File Browsing

Kevin Goodman — Thu, 22 Apr 2010 14:49:22 +0000

I always wind up forgetting the “tac” command, but it is definitely useful! Normally when I am trying to track down issues, the command usually winds up looking like

[root@tsthost01 log]# tail -50 /var/log/messages | more
Apr 21 14:27:58 t1ps-db01 snmpd[2936]: Received SNMP packet(s) from UDP: [127.0.10.77]
Apr 21 14:28:13 127.0.10.99 last message repeated 9 times
Apr 21 14:28:13 127.0.10.99 snmpd[2291]: Connection from UDP: [127.0.10.77]
Apr 21 14:28:13 127.0.10.99 snmpd[2291]: Received SNMP packet(s) from UDP: [127.0.10.77]
Apr 21 14:28:13 127.0.10.99 snmpd[2291]: Connection from UDP: [127.0.10.77]
Apr 21 14:28:13 127.0.10.99 snmpd[2291]: Received SNMP packet(s) from UDP: [127.0.10.77]
Apr 21 14:28:13 127.0.10.99 snmpd[2291]: Connection from UDP: [127.0.10.77]
Apr 21 14:28:19 127.0.10.81 last message repeated 18 times
Apr 21 14:28:25 127.0.10.26 MultiModemiSMS last message repeated 2 time(s)
... truncated
--More--

Then I scroll through the results and how what I am looking for is in those 50 linues. Unfortunately the information nornally is not and I re-run the command adding “-100″ or “-200″ to replace the “-50″. That is definitely not the best way to do it.

The better way for searching from the end of large files is to use “tac” instead of “cat” or tail. It might be obvious, but “tac” is just “cat” reversed. Bellow are from the man pages of each command

NAME       cat - concatenate files and print on the standard output

NAME       tail - output the last part of files

NAME       tac - concatenate and print files in reverse

Below is an example of cat used to read a file.

root@kdesk-l:~# cat GreenEggs
Do you like
green eggs and ham?
I do not like them, Sam-I-am.
I do not like
green eggs and ham.

Would you like them
here or there?

I would not like them
here or there.
I would not like them anywhere.

Next is tac reading the same file. Notice the content has been read in reverse.

root@kdesk-l:~# tac GreenEggs
I would not like them anywhere.
here or there.
I would not like them

here or there?
Would you like them

green eggs and ham.
I do not like
I do not like them, Sam-I-am.
green eggs and ham?
Do you like

Hopefully you can see some benefit to using this, especially in conjunction with the “more” command.

[root@tsthost01 log]# tac messages | more

Below are some schenarios that tac would be good for
- Going through log files from newest events to old
- Reviewing Java error log files (normally waaayyyyy to much information in those)
- Checking mailserver or DNS server logs
- When needing to go through a file without knowing exactly what you need to use “grep” to search for

Notes: The “tac” command is pretty much standard issue on Linux based systems. I tested this on RedHat, CentOS, and Ubuntu

Filed under: Linux

Linux, Networking, Security: Get Remote SSL Certificate From Command Line

Kevin Goodman — Wed, 03 Mar 2010 20:31:00 +0000

Easy way to get the SSL certificate of a server from the command line in Linux. The nice thing about it is that you get the full certificate chain. Nice for troubleshooting issues. After the “-connect”, specify the host and port you want to connect to. TCP port 443 is the default https port.

[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

Filed under: Linux, Middle Ware, Networking, Security

VMware, Linux: Install VMware Tools On RedHat Based Systems

Kevin Goodman — Tue, 12 Jan 2010 18:58:20 +0000

The following is a quick overview of installing VMware Tools on RedHat, CentOS, and Fedora systems. Specifically for VMware ESX, ESXi, and vSphere systems.

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.

Posted in Linux, Networking, VMWare

Linux, Security, LDAP: Local Authentication Fallback

Kevin Goodman — Wed, 16 Dec 2009 17:49:33 +0000

I have been setting up and integrating an LDAP authentication system into our infrastructure over the past few days. This is just one small “got-cha” that I ran into. The default setting in the OpenLDAP configuration (/etc/ldap.conf) is to continuously try reconnecting to the LDAP server on failure. This is definitely not what I want to happen if we loose LDAP. In this scenario, when connecting to the server via SSH, the session will hang and eventually timeout. This even removes the ability to login with a local system account.
Example of the timeout when LDAP server is down:

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

Posted in Linux, Networking, Security

Linux, Filesystem: GNOME Virtual File System (GVFS) Remote Connectivity CLI

Kevin Goodman — Mon, 07 Dec 2009 17:47:46 +0000

When not using NFS, Linux administrators generally move files from one server to the next via SFTP or FTP. This can sometimes be a headache when needing to move large amounts of files between the systems. This is where I like GVFS (GNOME Virtual File System). This subsystem allows you to mount remote systems via the following protocols to a local directory tree:

SSH

FTP

CIFS (Windows shares)

WebDav (HTTP)

Secure WebDav (HTTPS)

Above are the common protocols supported, but there is support for more. Using GVFS to mount the remote filesystem to yours allows you to create and move files to and from the remote system using typical “cp”, “rm”, and “mv” commands. This makes things even easier if you are working through an X windows console. Just bring up the remote directory structure through a file manager application and work from there. Gnome also uses GVFS to manage USB based storage. The following will go through manually connecting to a server using GVFS.Move into the “.gvfs” filesystem in the users home directory. Unless Gnome has automatically mounted a device, this filesystem should be empty.

user01@LinuxDesk:~$ cd ~/.gvfs

In the below example, a remote servers filesystem will be mounted over an SSH/SFTP session.

user01@LinuxDesk:~/.gvfs$ gvfs-mount ssh://user05@SftpServer02
Enter password
Password:

Verify that the location has been mounted.

user01@LinuxDesk:~/.gvfs$ ls
sftp for user05 on SftpServer02

The SFTP was mounted and we can now traverse the remote servers filesystem as if it were our own.

user01@LinuxDesk:~/.gvfs$ cd sftp\ for\ user05\ on\ SftpServer02/

user01@LinuxDesk:~/.gvfs/sftp for user05 on SftpServer02$ ls
app  boot  etc   hs_err_pid15240.log  lib         media  mnt  opt   relay  sbin     srv  tmp  var
bin  dev   home  hs_err_pid8660.log   lost+found  misc   net  proc  root   selinux  sys  usr

Since we logged into the SSH/SFTP system using user “user05″, we can write to any direcotry that remote user has access to.

user01@LinuxDesk:~/.gvfs/sftp for user05 on SftpServer02$ cd home/user05/

Below creates a new file “asdf” containing the text “asdfasdf”. Here we are just testing write capability to the remote server

user01@LinuxDesk:~/.gvfs/sftp for user05 on SftpServer02/home/user05$ echo "asdfasdf" > asdf
user01@LinuxDesk:~/.gvfs/sftp for user05 on SftpServer02/home/user05$ cat asdf
asdfasdf

“gvfs-mount” can also be used to list all currently mounted gvfs systems. Below shows only the sftp session.

user01@LinuxDesk:~$ gvfs-mount -l
Mount(0): sftp on SftpServer02 -> sftp://SftpServer02/
  Type: GDaemonMount

For reference, the following shows my 4gig USB drive that was automatically mounted when attached to the workstation through Gnome.

user01@LinuxDesk:~$ gvfs-mount -l
Drive(0): USB Drive
  Type: GProxyDrive (GProxyVolumeMonitorHal)
  Volume(0): 4.1 GB Media
    Type: GProxyVolume (GProxyVolumeMonitorHal)
    Mount(0): 4.1 GB Media -> file:///media/disk
      Type: GProxyMount (GProxyVolumeMonitorHal)
Mount(0): sftp on SftpServer02 -> sftp://SftpServer02/
  Type: GDaemonMount

GVFS mount points can be un-mounted using the “-u” argument. Below will un-mount the remote ssh server.

user01@LinuxDesk:~/.gvfs$ gvfs-mount -u ssh://user05@SftpServer02

Notes: GVFS contains one master daemon (gvfsd) which tracks current GVFS mounts. Each mount is created as an individual daemon with it’s own process. Knowing this, we can find the actual gvfsd process ID that the sftp connection is running under.

user01@LinuxDesk:~/.gvfs$  ps -ef | grep gvfsd-sftp
user01  8022     1  0 10:34 ?        00:00:00 /usr/lib/gvfs/gvfsd-sftp --spawner :1.8 /org/gtk/gvfs/exec_spaw/21

Posted in Filesystems, Linux, Networking

Linux, IBM: WebSphere WAS and Partner Gateway Version 6.2 FixPack 1

Kevin Goodman — Tue, 03 Nov 2009 19:28:42 +0000

This is just a brief overview. The installation process is pretty easy on these. Same as with most patches, IBM UpdateInstaller “update.sh” was used to install the service “pak” files. These patches must be done in order. Patch the WAS installation before patching WPG.

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.

Posted in Linux, Middle Ware

Linux / Oracle: IBM WebSphere Partner Gateway Oracle Gotcha

Kevin Goodman — Wed, 21 Oct 2009 08:49:33 +0000

I have been wrestling around with IBM WebSphere Partner Gateway for a few weeks now. There are so many tiny gotcahs out there that can affect the whole installation process.

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

Install Oracle Client

Configure Oracle environment (SID, server)

Install WebSphere Application Server

Patch WebSphere Application Server

Install WebSphere Partner Gateway Application (apps) Database

Install WebSphere Partner Gateway

Patch WebSphere Partner Gateway

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?

Posted in Linux, Middle Ware

Linux / Security: User Account Expiration Management

Kevin Goodman — Tue, 20 Oct 2009 09:00:33 +0000

I am a firm believer in regular password rotation/change and Linux has a built in mechanism that makes it easy. The following is a brief overview of password and account ageing for Linux based systems.

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.

Posted in Linux, Security

Linux / Storage: Memory – Huge Pages Overview

Kevin Goodman — Tue, 13 Oct 2009 14:39:16 +0000

A page is really virtual memory which is managed by the Translation Lookaside Buffers(TLB) in the CPU. The TLB controls the mapping of the virtual memory pages to physical memory addresses. In doing so, it bypasses the kernel virtual memory manager.

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.

Posted in Filesystems, Linux

Linux / Security: Encrypted External Drive Part 1 – Urandom

Kevin Goodman — Fri, 04 Sep 2009 08:34:40 +0000

So I am re-doing my external RAID 1 drive enclosure. I love this little thing. It has two 2.5 inch 160gig SATA drives in it. The enclosure is connected via USB 2.0 but it does have an eSATA interface as well. I will be configuring this to have a 10 gig non-encrypted partition. The remaining ~150 gigs will be an encrypted (LUKS) filesystem to be used on my linux machine.

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.

Posted in Linux, Security

Linux / Security: Sudo ‘sudo su -’ vs ‘sudo -s’

Kevin Goodman — Tue, 18 Aug 2009 19:34:18 +0000

I always use ‘sudo su -’ when I need to get to a root shell. I have seen a few people before, and a new co-worker recently use ‘sudo -s’. Since I could not remember off hand the actual differences between the two, I had to check. The following will run through the actual limitations.

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

This option reads the environment or password file for the shell to be executed. Does not execute root shell!

All environment variables are passed over from the current account to the root accountPer the Linux man page for sudo
-s The -s (shell) option runs the shell specified by the SHELL environment variable if it is set or the shell as specified inpasswd(5).

Below is the typical sudo command when going to root
$ sudo su -

Now that we are root, check the current environment variables. Here we see that we are in the bash shell, which is different from the Korn (ksh) shell that the user was in. Also note, the home directory is ‘/root’, and the ‘PATH’ locations.

[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

When ‘sudo su -’ was executed, we were in the testuser01 home directory (/home/testuser01). After execution, we are now in the root user home directory (/root)
[root@testServ01 ~]# pwd
/root

Now that we have seen what ‘sudo su -’ does, lets check out ‘sudo -s’.
$ sudo -s

Time to check the current environment variables again. Main things to note here are the home directory, PATH definition, and the SUDO_* variables. This is definitely different then what was listed before.
# printenv
_=/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

When ‘sudo -s’ was executed, we were in the testuser01 home directory (/home/testuser01). After execution, you can see that we are still in the same directory.
# pwd
/home/testact

Since the ‘PATH’ variable was passed from the testuers01 shell to the sudo environment, the administrative tools directories (/sbin, /usr/sbin) are not listed. This is not a huge issue, just more of a hassle if there were not passed from the user account.

Since this was the case for the test, I tried to issue ‘iptables’ without the absolute path. Per below, it failed.

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

Since I do actually have root level access, when I issue the command with the absolute path it works fine

# /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

To conclude ‘sudo -s’:

does NOT change the shell

‘PATH’ does not change since root shell is not executed

carries over all environment variables from the non-privileged user

Notes: So to be safe, I will still use ‘sudo su -’ when needing root level access. Seems that the ‘sudo -s’ option would be a little more safe for some users. Mainly due to the sbin locations not being in the ‘PATH’. This would make the user execute most administrative commands using the full path to the executable, unless sbin(s) were exported.

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

This option reads the environment or password file for the shell to be executed. Does not execute root shell!

All environment variables are passed over from the current account to the root account

Per the Linux man page for sudo

-s  The -s (shell) option runs the shell specified by the SHELL environment variable if it is set or the shell as specified in

passwd(5).

Below is the typical sudo command when going to root

$ sudo su -

[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

When ‘sudo su -’ was executed, we were in the testuser01 home directory (/home/testuser01). After execution, we are now in the root user home directory (/root)

[root@testServ01 ~]# pwd

/root

Now that we have seen what ‘sudo su -’ does, lets check out ‘sudo -s’.

$ sudo -s

# printenv

_=/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

When ‘sudo -s’ was executed, we were in the testuser01 home directory (/home/testuser01). After execution, you can see that we are still in the same directory.

# pwd

/home/testact

Since this was the case for the test, I tried to issue ‘iptables’ without the absolute path. Per below, it failed.

# iptables -L

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

Since I do actually have root level access, when I issue the command with the absolute path it works fine

# /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

To conclude ‘sudo -s’:

does NOT change the shell

’PATH’ does not change since root shell is not executed

carries over all environment variables from the non-privileged user

Posted in Linux, Security

Linux / Security: Iptables CLI – List Rules Without DNS Resolution

Kevin Goodman — Tue, 02 Jun 2009 13:13:12 +0000

This is quick and a little basic, but most people do not actually read the “man pages” or documentation. The majority of the time, requests for access comes in specifying IP address instead of hostnames (FQDN). I actually prefer this, but when doing a typical “iptables -L”, the reverse DNS is automatically checked for all IPs.

Most of the time I do not actually know the hostname that is associated and makes it hard to confirm the rule without doing a dns lookup on my own. Below is the typical output of the command.
[root@testserver ~]# iptables -L

Chain Firewall-INPUT
(2 references)
target     prot opt source               destination
ACCEPT     tcp  --  mail.asdf.com        anywhere            tcp dpt:ssh
ACCEPT     tcp  --  static.123.net       anywhere            tcp dpt:ssh
ACCEPT     tcp  --  private.9z.com       anywhere            tcp dpts:ftp-data:ftp
ACCEPT     tcp  --  nto.ntpgr.com        anywhere            tcp dpts:ftp-data:ftp

Iptables has a built in option to disable DNS resolution. This is done by passing “-n” in conjunction with “-L” and shown below.

[root@testserver ~]# iptables -L -n
Chain Firewall-INPUT
(2 references)
target     prot opt source               destination
ACCEPT     tcp  --  10.1.129.119         0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  172.168.22.87        0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  172.33.100.2         0.0.0.0/0           tcp dpts:ftp-data:ftp
ACCEPT     tcp  --  10.90.15.104         0.0.0.0/0           tcp dpts:ftp-data:ftp

Above you can see how easy it would be to verify the rules now without knowing the hostname or performing a lookup on your own.

Notes: The iptables output was edited to remove non-relevant information and all IPs/hostnames were changed.

Posted in Linux, Networking, Security