SAN with iSCSI

One-Click Access to ConsoleOne in Linux

Running ConsoleOne directly from the server is helpful and often necessary, especially if you are using SLES as the server OS. With OES, you have the NSS file system that lets you easily connect a Windows workstation to your domain (assuming that workstation has a Novell Client). If you're using a Linux desktop that is capable of running the Novell Client for Linux, ConsoleOne can still be run locally while connecting to the domain database on the OES server. Using a SLES server further limits your options.

Instead of installing and configuring Samba or NFS (which I'm not sure is recommended anyway), using SSH to run ConsoleOne allows you to use a common protocol.

I most often use the Linux desktop and have been able to make one-click ConsoleOne access via SSH work. While Putty, a Windows SSH client, can provide similar functionality, I do not know of a way to generate the necessary SSH key with Putty in order to make this work in a one-click way.

For the remainder of this article, I'll call the server running the domain and from where we want to run ConsoleOne 'gwdom1'. I will assume that ConsoleOne with the current snapins is installed, executable, and fully functional from the domain server console for the purposes of administering GroupWise. I will also assume that we want to connect to this server as 'root'.

Running ConsoleOne via SSH

This is the easy part. First, SSH to the server where the domain is running as the root user using the following command. The '-X' is crucial as it enables X11 forwarding:

ssh -X root@gwdom1

After entering the root password, execute this command:

/usr/ConsoleOne/bin/ConsoleOne

At this point, ConsoleOne should appear on your Linux desktop (running from gwdom1) and you can login and connect to gwdom1's domain database. This will verify that ConsoleOne can be run in the way it needs for this process to ultimately work.

This part should be possible using Putty for Windows. However, providing the specific steps of doing so is not the intent of this article.

Your Very Own Script

You can easily combine the above two commands into one script file. First, go to your home folder using the console and switch to a folder called /bin. For non-root users, it will be /home/username/. For root, it's /root.

Once in the /bin folder of your home folder, create a file called 'c1_gwdom1' (or whatever you want to use as the command that calls this) using your favorite text editor. The file should contain the following:

#/bin/bash 

ssh -X root@gwdom1 "/usr/ConsoleOne/bin/ConsoleOne &"

The '#/bin/bash' part is probably unnecessary, but I've gotten in the habit of putting this in my scripts. Nevertheless, save the file and exit your editor. Now, from the console, make your script executable. Use the command:

chmod 755 c1_gwdom1

Because your /bin folder in your home folder is, by default, in the path, you should be able to type 'c1_gwdom1' from any folder and it will start. Try it out. You will have to enter the root password for gwdom1 to have it connect (more on removing this later). ConsoleOne should start on your local workstation. If you want to have it start in the background, use 'c1_gwdom1 &' and you won't have to keep your console window open.

No Password Required

Here it gets more complicated. However, this is also the key to one-click access. This is also the part that I am unsure how to duplicate in Windows. It may be there, but my limited use of Windows for administration of GroupWise has kept me from researching this further.

What we have to do is to first generate an SSH key, then enter the key info into gwdom1's authorized list. This tells gwdom1 to trust connections from this machine. So keep in mind that if you have multiple machines from which you want to use one-click ConsoleOne, you will have to repeat this step for each.

From a console on your Linux desktop, enter 'ssh-keygen -t rsa' and you should get a prompt for a path. Use the default path and leave the passphrase blank. Once you've finished that command, you should have a file in your Linux desktop's /home/username/.ssh/ folder called 'id_rsa.pub'. View the contents of this file by typing:

cat /home/username/.ssh/id_rsa.pub

Highlight and copy the contents of that file to the clipboard using the GUI. Now open another console and SSH over to gwdom1 as root.

In the /root/.ssh/ folder of gwdom1 you should find a file called authorized_keys2. Make a quick backup copy of this file before you start editing it. Edit the file and go the bottom. Add another line, then Paste the contents of your local id_rsa.pub file into it. Save the file and exit out of the SSH session.

Test this by re-SSHing to gwdom1. If it worked, then you should be able to SSH without getting a password prompt.

Click Me!

To make it all nice, neat, and easily accessible you can now create yourself a shortcut. The steps for doing this will depend on whether you use GNOME or KDE (or another Desktop Environment). Chances are that you know how to do this so I will not go into specific steps to create a shortcut.

The application/command that you want the shortcut to run is:

/home/username/bin/c1_gwdom1 &

Create it and click to test.

What should happen is that ConsoleOne should now appear, having been run over SSH from the server running/hosting your domain.

In this scenario I will be setting up Novell High Availability Extension (HAE) on SLES 11. I will also demonstrate how to setup dlm, o2cb and SSH stonith.

Some items that I have pre-configured are as follows.

1. 1 SMT server
2. 3 server installed with SLES 11 and HAE as a add-on product.

   Please see the following link:
   http://www.novell.com/documentation/sle_ha/book_sleha/data/part_install.html

3. Each SLES 11 HAE server is fully patched with the latest code from my SMT server(2/24/10)
4. Networking is setup as demonstrated in the following picture.

Click to view.

Assumptions:

In this document I assume the reader has some basic knowledge of quorm, fencing, and resource attributes. That said I will show each step with a screen shot during resource configuration. Although this document could be adopted into a production environment; I assume that this document will only be used in a test environment and for learning purposes only.

Warning:

During resource configuration I setup a ssh-stonith resource. As noted in the documentation this resource should not be used in production. Please also note that Novell will not support the resource except in a test situation where a real stonith resource, such as ilo, DRAC card, external power supply or other such stonith resource is not available.

DRAC card:

ilo card:

Setup of the previous environment:

Edit the /etc/hosts and put entries into the hosts file for each node.

Create a ssh-key for every node.

For example:

#:~> ssh-keygen 
Generating public/private rsa key pair. 
Enter file in which to save the key (/root/.ssh/id_rsa): 
/root/.ssh/id_rsa already exists. 
Overwrite (y/n)? y 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa. 
Your public key has been saved in /root/.ssh/id_rsa.pub. 
The key fingerprint is: 
9e:92:9c:01:9e:fd:fb:12:73:7d:a7:cc:e1:11:ad:7f root@hae1 
The key's randomart image is: 
+--[ RSA 2048]----+ 
|                 | 
|                 | 
|    .          . | 
|   . +        . .| 
|    o o S  .   o | 
|     . *o.. . = .| 
|      = ++   = * | 
|       ...    = E| 
|        .o.     .| 
+-----------------+ 

Now copy that key to every node. You will need to repeat this process on each node so that all nodes trust each other.

Example:

#:~$ cd .ssh/
#:~/.ssh$ ls
authorized_keys  id_rsa  id_rsa.keystore  id_rsa.pub  id_work  known_hosts
#:~/.ssh$

#: scp id_rsa.pub root@hae2:/root/.ssh/id.rsa.hae1.pub

Now go to HAE2 and type the following:

HAE2 /root/home/.ssh/: cat id.rsa.hae1.pub >> authorized_keys

Repeat this for each node. When you are finished you should be able to ssh to any node from any node without entering a password or pass-phrase.

I will be following these instructions from the HAE documentation:
http://www.novell.com/documentation/sle_ha/book_sleha/data/cha_ha_installation_yast.html

1. Open yast > cluster and configure it as the following:

   Communication Channels

   Note: Each node will have its own Node ID: For HAE1 – 1, HAE2 - it will be 2 and HAE3 - 3

   

   Click to view.

   Security

   Note: When you enable security you add protection to the cluster. When you generate the Authentication file you will need to copy it over to each node in the cluster.

   

   Click to view.

   Service

   

   Click to view.

2. Copy the /etc/ais/authkey and /etc/ais/openais.conf to the other nodes in the server.

   For example:

   #: scp /etc/ais/openais.conf  root@HAE2:/etc/ais/openais.conf
   #: scp /etc/ais/openais.conf  root@HAE2:/etc/ais/openais.conf
   
   

   Note: Do this for each node.

   !Remember: Make sure to edit the openais.conf and match up the node id for the node you are on. For example. HAE1 will be 1 and HAE2 will be 2 and HAE3 will be 3. You can also do this via yast > cluster.

   Your cluster can now be started.

   #: rcopenais start
   
   

   Before you login to the cluster you will need to set hacluster's password on each node.

   #: passwd hacluster
   enter new password:
   
   

   Now you are set to login.

   #: crm_gui

   

   Click to view.

Creating a dlm resource:

Under Resources click Add and choose Clone and then Ok.

Click to view.

Click to view.

Click to view.

Click to view.

Click to view.

Click to view.

Click to view.

Click to view.

Click to view.

Once you have passed through to this point you will want to click "ok, ok, apply or ok". You will now have a dlm resource. We will now configure o2cb and then a stonith resource before starting dlm.

configuring O2CB:

Click to view.

Click to view.

Click to view.

Click to view.

Click to view.

Click to view.

Configuring ssh:

Click to view.

Click to view.

Click to view.

Click to view.

Click to view.

Click to view.

Click to view.

Click to view.

Configuring resource order:

Click to view.

Click to view.

Once you are all done you can apply the changes. You will now want to start you resources starting with your ssh-stonith then dlm and finally O2CB.

Final results:

Click to view.

Have you heard about the REMUS project? It's a fantastic piece of code maintaining an exact copy of your XEN virtual machines on a backup host.

Better yet: it's now incorporated into the XEN hypervisor and expected in the next major release!

"The Remus project has just been incorporated into the Xen hypervisor. Developed at the University of British Columbia, Remus provides a thin layer that continuously replicates a running virtual machine onto a second physical host. Remus requires no modifications to the OS or applications within the protected VM: on failure, Remus activates the replica on the second host, and the VM simply picks up where the original system died. Open TCP connections remain intact, and applications continue to run unaware of the failure. It's pretty fun to yank the plug out on your web server and see everything continue to tick along. This sort of HA has traditionally required either really expensive hardware, or very complex and invasive modifications to applications and OSes."

http://dsg.cs.ubc.ca/remus

From the moment we introduced SUSE Linux Enterprise Server for the mainframe more than ten years ago, our commitment to helping you optimize on IBM System z has never wavered. Together, with our valued partner IBM, we’ve developed more Linux-for-mainframe innovations than any other provider, delivering the simplest, most cost-effective alternative server consolidation platform to x86 platforms available today. So, as the only distributor that’s been delivering an enterprise-class and fully supported Linux operating system since the very start of Linux on the mainframe, we can safely say that if history often repeats itself, the future looks even brighter.

View the timeline today at: http://bit.ly/a8dW44<

Mainframes are about 40 years old. And as you probably know, several years ago mainframes were written off as expensive, dated computers that were capable of running only large business applications. Mainframe go south, many said. Not anymore - thanks to Linux!

Linux on mainframes has evolved rapidly during the past 10 years - yes - 2010 is the 10th anniversary of Linux on the mainframe. The more, there has been shifting of dynamics with the System z10. IBM has done an excellent job with the price/performance ratio, and many companies that have gone through a cost per transaction analysis have determined that the z10 can process their transactions at half the cost of a distributed environment. And the new IBM System z Solution Edition for Enterprise Linux and the Enterprise Linux Server is an additional catalyst for bringing new workloads to Linux on the mainframe.

Today, in general we see many companies taking a critical look at their existing and new workloads, and asking hard business questions to determine the best platform. These companies are recognizing they need outstanding RAS to manage their mission-critical workloads, and the mainframe uniquely fulfills this business requirement. And these companies are realizing that investing in a first move turns back in consequence - even more if they run Linux on their mainframes.

SUSE Linux Enterprise Server for System z has been available since the very start of Linux on the mainframe - yes - 2010 it has its 10th anniversary, too. If you want to hear from happy customers running SUSE Linux Enterprise Server for System z on their mainframes why and how they do so, and learn more from our experts, you should consider to drop over at one of the upcoming conferences for System z.

SHARE in Seattle
March 14-18 2010, Washington State Convention and Trade Center, Washington

Recommended sessions:

• Linux System Management for the Mainframe System Programmer - Part 1&2 (Mark Post, Novell), Mar 15 1:30-4:00 PM Room 608
• Using Logical Volume Manager (LVM) to Reduce the Hassle Managing Disk Space on Linux (Mark Post, Novell), Tue Mar 16 9:30-10:30 AM Room 609
• Linux Installation Planning (Mark Post, Novell), Mar 16 3:00-4:00 PM, Room 609
• What's New with SLES 11 on System z (Mark Post, Novell), Mar 18 9:30-10:30AM, Room 609
• Linux on System z at Wells Fargo: Penguins Board the Stagecoach (Marcy Cortes, Wells Fargo Bank), Mar 17 1:30-2:30 PM, Room 611
• Success with Linux on System z at Nationwide - Lessons Learned (Jim Vincent, Nationwide Insurance), Mar 17 3:00-4:00PM, Room 611
• Linux Servers on System z: Benefits and Features of Virtualization in the Enterprise Data Center (Rick Barlow, Nationwide Insurance), Mar 17 4:30-5:30PM, Room 611

For more information, see
http://www.share.org/Events/UpcomingConference/tabid/349/Default.aspx<

Novell BrainShare Salt Lake City
March 22-25 2010, Salt Palace Convention Center in Salt Lake City, Utah

• ELS208 German Pension Fund Goes Linux: Legacy Application Migration to z/Linux with Minimal Risk (Falk-Oliver Bischoff, German Pension Fund/Florian Delonge, Clerity/Olaf Senger, IBM), Mar 22 11:30AM, Room 150 D/E
• ELS206 Hands-on Workshop: Install SUSE Linux Enterprise Server on IBM System z (Richard Lewis, IBM), Mar 23 9AM-1PM and Mar 25 9AM-1PM, Room 255B
• ELS310 What's New with Linux on System z (Richard Lewis, IBM/Ihno Krumreich, Novell), Mar 24, Room 251 F

For more information, see: http://www.novell.com/brainshare/<

WAVV - World Alliance of VSE VM Linux
April 9-13, 2010 Covington, Kentucky, Embassy Suites Cincinnati - River Center

• Linux Installation Planning (Mark Post, Novell), Apr 10 3:00PM
• Using Logical Volume Manager (Mark Post, Novell), Apr 12 11:45AM
• What’s new with SLES 11 on System z (Mark Post, Novell), Apr 12 4:15PM

For more information, see: http://www.wavv.org/