Liebert part #IS-WEBCARD
Agent App Firmware Version: 5.300.0
username: Liebert password: Liebert
Note that the the letter ‘l’ is capitalized.
2013-04-24 | 0 comments
Liebert part #IS-WEBCARD
Agent App Firmware Version: 5.300.0
username: Liebert password: Liebert
Note that the the letter ‘l’ is capitalized.
2013-04-23
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 →
2013-04-04 | 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 →
2013-04-03 | 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:
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
2013-03-26 | 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.