RTFM

[Read This Fine Material] from Joshua Hoblitt

PXE booting SystemRescueCd

My friend and colleague Stuart Sheldon has vlogged about the many benefits of SystemRescueCd or sysresccd. Sysresccd has built in support for acting as a PXE server to boot other systems without having to connect local media. There are some instructions on setting this up on the official wiki page titled Sysresccd-manual-en PXE network booting. PXE booting recovery/test tools is really convenient but using the native sysresccd support won’t work in my production server environment as there is a preexisting PXE setup (DHCP/TFTP) managed by a tool called TheForeman.

Here is how I made PXE booting to sysresccd an option in my environment:
Continue Reading →

Finding the closest AWS EC2 region

| 0 comments

I’m considering purchasing an AWS EC2 reserved instance for personal use (for among other things, this blog) instead of continuing to pay the high rate for an on demand instance. Since I’m going to have to live with the region a reserved instance is in for several years, I figured it would be worth the time to see what the latency options are. I sort of expected there to be an in browser javascript program or downloadable script to do this for me but was unable to find one. The best pre-canned solution I could find via google was this project https://github.com/turnkeylinux/aws-datacenters mentioned in this stackoverflow thread. However, it’s not really what I was looking for.

The quick and dirty test I decided on was to run ping tests to three m1.small on demand instances, one in each of the US regions.

region-az min/avg/max/mdev
us-east-1d 71.314/74.161/133.174/6.575
us-west-1c 39.912/45.806/61.717/3.820
us-west-2c 67.426/73.756/91.390/3.274

As I’m currently located in Tucson, AZ, I expected us-west-1/N. California to have the lowest latency but was surprised by the fact that us-west-2/Oregon had much higher ping times than us-west-1. It’s also a bit surprising that us-west-2 & use-east-1/N. Virginia were so similar since geographically us-east-1 is much further away. Once again confirming the axiom that physical distance != network distance (latency). While there is additional cost associated with us-west-1 the latency reduction looks fairly appealing.
Continue Reading →

How to fix “X11 forwarding request failed on channel 0”

| 8 Comments

Much to my surprise, I encountered this error message when connecting to a RHEL6.3 server in order to remote display a RAID controller management app.

jhoblitt@foo ~ $ ssh -X foo2
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
X11 forwarding request failed on channel 0

It seems that an update to OpenSSH changed the semantics of X11 forwarding. A bit of googling turned up the answer in this thread:

https://www.linuxquestions.org/questions/linux-software-2/ssh-x11-forwarding-request-failed-on-channel-0-a-945709/

The fix is to add this line to your /etc/ssh/sshd_config:

X11UseLocalhost no

In previous version just X11Forwarding yes was needed but it seems that both directives are now required.

I’m not sure when this change was introduced but it’s definitely present in this version of sshd:

[jhoblitt@pfoo2 ~]$ ssh -V
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
[jhoblitt@foo2 ~]$ rpm -qa | grep openssh
openssh-clients-5.3p1-81.el6.x86_64
openssh-5.3p1-81.el6.x86_64
openssh-server-5.3p1-81.el6.x86_64

How to disable GPFS’ cNFS feature

| 0 comments

Check to see the current status of cNFS:

[root@foonsd1 ~]# mmlscluster --cnfs

GPFS cluster information
========================
  GPFS cluster name:         fooamcp.example.org
  GPFS cluster id:           10159024612008204251

Cluster NFS global parameters
-----------------------------
  Shared root directory:                /net/foodata1/cnfsSharedRoot
  Virtual IP address:                   foonfs.example.org
  rpc.mountd port number:               892
  nfsd threads:                         128
  Reboot on failure enabled:            yes
  CNFS monitor enabled:                 yes

 Node  Daemon node name            IP address       CNFS state  group  CNFS IP address list
-------------------------------------------------------------------------------------------
  16   foonsd1.example.org        140.252.27.15    enabled        0   140.252.27.10,140.252.27.12
  17   foonsd2.example.org        140.252.27.16    disabled       0   140.252.27.11,140.252.27.13

We can either just disable the one active cNFS node like this:

[root@foonsd1 ~]# mmchnode --cnfs-disable -N  foonsd1,foonsd2
Mon Mar 25 17:16:15 MST 2013: mmchnode: Processing node foonsd1.example.org
Mon Mar 25 17:16:15 MST 2013: mmchnode: Processing node foonsd2.example.org
mmchnode: Propagating the cluster configuration data to all
  affected nodes.  This is an asynchronous process.

Or disable cNFS permanently but deleting it’s configuration. Note that when your permanently removing the cNFS configuration it’s not necessary to first disabled it.

[root@foonsd1 ~]# mmchnode --cnfs-interface=DELETE -N foonsd1,foonsd2
Mon Mar 25 17:16:43 MST 2013: mmchnode: Processing node foonsd1.example.org
Mon Mar 25 17:16:43 MST 2013: mmchnode: Processing node foonsd2.example.org
mmchnode: Propagating the cluster configuration data to all
  affected nodes.  This is an asynchronous process.

Verifying that cNFS is now disabled:

[root@foonsd1 ~]# mmlscluster --cnfs

GPFS cluster information
========================
  GPFS cluster name:         fooamcp.example.org
  GPFS cluster id:           10159024612008204251

mmlscluster:  CNFS is not defined in this cluster.