Given openssh wasn’t going to be replaced I researched about dropbear and if there was a newer version perhaps with sftp, unfortunately not. Eventually I came across notes on a blog mentioning that dropbear “supports” openssh sftp. After restoring ESXi back to its default filesystem settings (ssh enabled) it appears the attempting to sftp to esxi returns the following error.

After compiling a slightly older version of openssh (static) I found a release of sftp-server that will once placed in /sbin on ESXi allows full usage of sftp (including sshfs mounting) binary below.

sftp-server.tar.gz

I should say at this point, the goal of all this was to allow me to keep all my ISOs on one server and be able to access them from everywhere also, I wanted a PXE server to be able to access the ISOs and loopback mount them and then present the contents via NFS to the installers started by PXE.

So looking around I found some ftp binaries that should work on ESXi, given that the console access for ESXi is done with busybox there is no file command to determine what binary type the files are so I was unaware of what binaries I could run inside ESXi. This all worked fine following the instructions located on the vm-help.com website here however a few of the instructions are a little bit incorrect such as the path to tcpd is incorrect in inetd, however i’ll leave you to fix that. So on the PXE server using FUSE again and curlftpfs to mount the filesystem and this revealed a glaring bug as soon as I loop back mounted the first ISO. Unfortunately the problem lies in the fact that curlftpfs will use memory to store the file as it downloads it for access by FUSE, so trying to open a 4GB DVD ISO quickly exhausted my PXE servers memory and then it became unresponsive, great.

Further research turned up a blog post about some guy trying to use unfs to enable nfs sharing between two ESXi boxes, more specifically it was mentioned that linux binaries would work fine in the ESXi service console. One thing that was slightly confusing was that ESXi is x86_64 (64bit) however binaries that you need for the service console have to be 32bit otherwise you’ll get a confusing error that the binaries can’t be found when you try and run them due to busybox’s odd handling of errors. I present below the binaries required for nfs in ESXi :-

nfs binaries for x86

These are pretty easy to use, scp the file over to ESXi and untar it in /tmp al that’s left is to place the files in /tmp/sbin into /sbin and the files in /tmp/etc into /etc. The /etc/exports contains one entry to give access to /vmfs/volumes, which means that accessing the nfs share will give you the UUID paths for the disks containing VM’s and ISOs. To start the nfs server, start portmap first and then start unfsd which should be started the following way (unfsd -d &), this is due to unfsd not being able to disconnect from console on start up (something to do with busybox I assume).

One final note, is that once another machine connect to the nfs share portmap will go start using 50%-70% cpu and will need stopping and starting for other nfs clients. I’m still looking into this, however having a cron job to restart the process every few minutes should do the job.

Writing to a USB stick:

Now the iso contains a simple file called imagedd.bz2 that is found in the root of the iso, which just need bunzip to decompress it and the dd’ing to a USB stick as documented before.

Password complexity:

At the moment there is nothing about this on the internet so it was a case of going through a few files to find it, but previously /etc/pam.d/common-password contained all of the password complexity requirements as documented on the VMware KB. However now all of the password requirements are located in the file /etc/pam.d/system-auth, so this file will need editing if you don’t want insane password requirements for all users.

To break it down this example consists of,

- Creating a blank project in Xcode

- Using the default Delegate class and adding our own method (interface)

- Linking the GUI to our class

- Adding code to our method (implementation)

- Drinking tea

Creating a project in Xcode

This is pretty straight forward, open Xcode and Select Cocoa Application as the template to your new project. I’d recommend having a folder to contain all of your development projects in, however file management is your own business. To keep within the naming used by this example I would recommend calling your project HelloWorld though.

Once the project and it’s associated files have been created you’ll be presented with Xcodes main interface, which will have references to numerous frameworks and contain the files that we are really interested in (MainMenu.xib, HelloWorldAppDelegate .h/.m)

Using the default delegate class

It is possible to either create your own class or use the one that is now created by Xcode, given there is one created it makes it easier just to use it. In the main Xcode if we open the tree under HelloWorld and open the ‘Classes’ folder we’ll see two files that are the HelloWorldAppDelegate files. If we open the header we’ll be presented with the interface, which contains the declaration of the class HelloWorldAppDelegate. We can see that this object inherits from the NSObject class and comes with one variable declared, along with the @property declaration (can be ignored for now).

We will modify this class declaration by adding a method to it, this method will be called ButtonPressed (it will be called, when a button is pressed….) and should be written as followed:

This needs to be written after your variables have been declared but before your @end declaration, otherwise it will be out of scope for your class. The next step is to write the code that will be run (implemented?) when this method is called. As mentioned previously code that is to be run needs to be part of the @implementation declaration, which is in the other file that makes up your class. In this file you should find a method that is inherited from the parent class NSObject and we can ignore this method as we’ve no code to add to this being called. Under this method we’ll be adding our own method, which for the time being will look as followed:

I would recommend compiling your modified source code, just to ensure that you’ve not made any syntax errors and also as it will save your changes that we’ve made so far. Should everything compile fine, it’s time to add a button on our blank GUI and link it to the class allowing it to call our method ButtonPressed.

Linking the GUI to our class

To link our code and our interface we’ll need to open the MainMenu.xib in interface builder and set up the various links between the GUI and the code. In Xcode clicking on the HelloWorld project tree object (above the Classes tree object) will again present us with all of the files that are part of our project and in here you’ll fine the .xib file. Double clicking on this file will start up the Interface Builder application and present us with the default window and menu bar that make up the GUI, along with the Interface project window containing the elements that make up the interface.

You should see that a class has been added to the interface builders window (presented as a blue cube), the class Hello Wold App Delegate is added automatically by the Xcode project creator(in future posts we’ll be adding our own classes). From the library window find the Push Button Object and drag that onto the blank window and then control+click on the button and drag down to the Hello World App Delegate Class.

This will present you with a little drop down showing all methods available to the button and here you will see ButtonPressed, which you should select. This button is now linked to the Method ButtonPressed and we can now save our changes and quit from the Interface builder.

Adding code to our method (implementation)

At this point everything is linked up and declared, so compiling this code will actually call the method in our code when the button is pressed however at present there is no code in the method and therefore nothing will actually happen. So for our example we will use the NSLog function which allows us to print out messages to the system log (usually for debug purposes) however we will be printing out “Hello World”. The implementation of the ButtonPressed method will need the following adding:

Once this code is added open the Debugger console in Xcode by going to the Run menu item and finding Console (also by pressing Shift+Apple Key+R), and then selecting the ‘Build and Run’ option.

Drinking tea

Enjoy a nice cup of tea whilst repeatedly pressing the Button and watching “Hello Wold” appear in the debug log.

This is pretty straightforward task to do and can be accomplished in two methods of either botching the install halfway through or pulling the image from the install CD and doing a raw write to the USB device. I opted for pulling the image from the CD and dd’ing this image onto my USB key by doing the following methods:

1. Acquire VMware ESXi 4.0 from vmware

2. Mount the CD (in linux by mount -o loop <path to ISO> <mount point>, or double clicking in OSX )

3. Copy install.tgz from the CD and extract in a working location, which should eventually give you a directory structure.

4. bunzip /usr/lib/Vmware/install/VMware-VMvisor-big-164009-x86_64.dd.bz2 (or equivalent file)

5. dd if=<path to .dd file> of=<path to USB device>

6. Change BIOS settings to boot from USB and boot up.

7. Set IP address, download VSphere client and off you go.

Refer to http://www.vm-help.com for any issues

I’m writing up the steps i’m following to learn, so that I can follow them when I have forgotten something (which I frequently do) and so that anyone else can follow them if they wish. I don’t intend to ever go too far with Xcode development, so don’t expect to find a how-to to developing a game or a photoshop alternative.

Introduction

Before we start writing any code it’s probably best to go over some of the basics of Xcode and in particular Objective-C that is used to build cocoa apps and iPhone apps. It’s possible to develop your application without using Xcode and compiling with the gcc compiler but thats well beyond what I have the inclination to do and the Xcode UI comes with numerous benefits (along with some problems).

Xcode

Xcode consists of numerous peices:

- Xcode.app: the IDE used for coding, and a wrapper for the debugger and compiler for your applications.

- Interface Builder.app: The UI used to craft the GUI for your application and tie the actions of GUI to your code and receive it’s outcomes.

- Developer Tools Library: This has to be subscribed to and downloaded(free), and is the source code documentation.

The Xcode.app, works pretty well and will attempt to autocomplete your function names or class names, and points out build errors pretty well. The Interface Builder.app on the other hand is terribly buggy and will often leave you frustrated it can lose class information leaving you without the correct actions when you try and link your GUI to the code. The other problem that is common is it’s lack of getting focus when switching back from another application. If you’re in safari reading something and switch back to the Interface builder you’ll be interacting with it, however the app in focus is still safari meaning functionality doesn’t work (minimize safari and then try using Interface builder).

Objective-C

I’m not going to go into too much detail here as this isn’t a University training course, and if you’ve got no real programming experience (Java/C/C++) then you’ll possibly struggle here. I’d suggest getting your head around the basics of C++ before working with Objective-C as there is overlap, it’s just that the syntax is noticeably different.

Declaring a class in objective-C

An Objective-C class depends on two pieces, which are the ‘interface’ and the ‘implementation’.

The interface consists of the declaration or ‘design’ of a class, ranging from:

- it’s name

- classes it inherits from

- and it’s instance variables and methods that it has.

The implementation the consists of ‘fleshing out’ the class, such as providing the code for the methods declared in the interface.

Linking it all together

The next step is linking together a GUI to your classes and enabling your buttons and various other elements access to the methods and variables declared in the code. This sadly has to be done using the Interface Builder and can lead to a bit of confusion as ‘bugs’ can appear, however the concept is as follows.

1. Open your default interface created by the project builder in Xcode (default it will be MainMenu.xib)

2. Numerous windows will be open, however the one to focus on is the main project window containing the elements that make up the GUI not the GUI designer itself (more detail and screenshots will be shown in the next post)

3. From the library you’ll want to drag the parent class to this window (usually we will inherit from NSObject), and then from the inspector window we can find the identity tab, and change the class to the ours (DeclaredClassName, from our example).

4. GUI elements can now use the methods that are declared in this class, so for example a button would have access to the method ClassMethod.

Next Step will have to be hello world.

Getting the tram to the bottom of the path was pretty straight forward, however that pretty much was the limit of the planning for the walk. So after a broken German conversation with a nearby gentleman we were pointed in a direction and told the walk would take 2 to 3 hours (I nearly went straight home at this point). We pressed on walking following random numbers painted on trees and trying to keep sense of direction that our German tour guide had pointed us in.

After walking aimlessly in the direction we assumed was correct we spotted what appeared to be the top of a castle, which still appeared quite away in the distance. After stumbling through a stables and being attacked by numerous crazy dogs, we started the ascent up the hill again vaguely in the direction of the castle. We managed the walk in one hour and twenty minutes, which beats the time given to us early quite respectably and includes fifteen minutes walking in the wrong direction at the top of one of the hills. I enabled the GPS application I have on my iPhone to give us an idea of what we were dealing with ascending/speed/distance etc.. This spat out a Google maps file that overlays the over the top route we took, which can be viewed here.

The full Gallery can be found here and if you are bored there is a wikipedia page too.

Step 1.

Create a basic hvm scenario:

1.5Gb LVM or disk image for the ESX install, other disks can be added for use as a datastore.

You’ll need an esx cd image, which can be downloaded along with a licence from vmware.com

I allocated about 80% of the memory of my server, along with 3 of the 4 cpus.

Set it up to output to a VNC session.

Add a nic and ensure it has the following set:

model=e1000

Step 2.

Start the domU up and ensure it’s booting from CD, connect to the VNC session and watch it load up the VMkernel and e1000 module etc.. Eventually you’ll get to the install steps which you can quickly go through until it errors with the issue of no devices to deploy the install to. Once at this point it’s a simple alt-F1 to the console prompt to access the ‘support’ features. At the console log in with the username root and a <blank> password, check your IDE disk is shown using fdisk -l and then cd to /usr/lib/vmware/installer/Core/ and edit with vi the file TargetFilter.py. This file is used to determine whether there is a device that can be used to deploy the ESX system to, and contains the line that we can change to allow our IDE device to be used.

Change

return interface.GetInterfaceType() == ScsiInterface.SCSI_IFACE_TYPE_IDE

to

return interface.GetInterfaceType() == ScsiInterface.SCSI_IFACE_TYPE_ISCSI

Once this change has been made, the installer will be given an iSCSI device in place of in IDE device and the install will proceed to use it, this should then be kicked off by starting install from the command line. You’ll need to change back to the correct console prompt as the installer will move the terminal back, so pressing alt-F1 will return you to the correct terminal. The installer will not list your disks and the installation can begin, once completed the system will want to reboot and will come up with a DHCP address for it’s first e1000 adapter.

Regular ESX service can continue from here (i.e. get the Infrastructure Client / set [credentials,network address]  / build some VMs).

[PHYS_A [VM_A:5901]]  <–/–>  [PHYS_B [VM_B]]

VM_A needs to run a VNC Server that will bind to VM_A:5901, however will no access to the firewall etc.. there is no way that there can be any port forwarding to this internal VM. We could use IPtables on the VM_A and then again use IPtables on PHYS_A to bind 5901 from VM_A’s IP to PHYS_A, however we are still behind a firewall.

To accomplish this sharing a server running SSH is required, the location of this server is completely irrelevant as long as it’s accessible with a standard user account. This server will be called SSH and both machines can access it through the firewall.

[PHYS_A [VM_A:5901]]  <—> [SSH] <—>  [PHYS_B [VM_B]]

The next step is to push the port on VM_A to the SSH server using the following command:

[user@VM_A]$ ssh -R5901:127.0.0.1:5901 -C user@SSH

This will open a session that will create the port 5901 on the server SSH, this can be confirmed by running a netstat -a on the server SSH and seeing that 5901 is now listed as a TCP4 listening port.

[PHYS_A [VM_A:5901]]  <—> [SSH:5901] <—>  [PHYS_B [VM_B]]

The next step is to pull the port on SSH to VM_B where we have the client software (vncviwer). The following command is used to pull the port from an IP address and bind it to a local port in VM_B.

[user@VM_B]$ ssh -L5901:127.0.0.1:5901 -C user@SSH

There will now be the port created on VM_B that tunnels through SSH to VM_A.

[PHYS_A [VM_A:5901]]  <—> [SSH:5901] <—>  [PHYS_B [VM_B:5901]]

The user on VM_B can now use the service as if it was actually running on the host itself.

[user@VM_B] vncviewer localhost:5901

Notes for SSH flags:

-R   [port to bind to on remote host] : [local host IP] : [localhost port]

-L   [local port to use] : [remote IP] : [remote port]

-C (adds compression)

For all those people that need a sun cluster on their macbook. This is a small how-to of sorts, I’ll not go into full detail regarding everything as if you can’t manage the simpler steps then I find it unlikely you’ll manage to handle the later tasks of configuring sun cluster.

So..

Step #1.

Create a Virtual Machine and install Solaris 10. (Basic configuration, it will want one disk, and one network interface) For the Filesystem layout, the default set up will be an 8Gb disk this needs to be split something like

512 swap

512 /globaldevices

7gb /

In the installation provide a hostname along the lines of node-a and give the network interface a useable IP address, VMware uses 172.16.190.X so use this range for your IP address. Install the default packages and complete the installation. Once rebooted:

#svcadm disable sendmail

#svcadm disable cde-login

Once these services are disabled create a user and shut the vm down.

Step #2

Open finder and locate the virtual machine on your mac, right click and select duplicate. Rename the Virtual Machine to node-b or at least make it match up to your naming system. Boot up the duplicate system (node-b) and once logged in edit the following files:

/etc/nodename

/etc/hostname.e1000g0

/etc/hosts

Give the system a different IP address and alter the naming so that it follows on from the previous virtual machine. Also ensure that in the hosts file you keep the record for the other system otherwise this will need adding later on. Reboot the system and ensure that it’s networking information is correct, you can try pinging between the two machines and ensure the hosts file entries are correct otherwise the Sun Cluster will fail later. Once tested ensure that both machines are switched off.

Step #3

Open Terminal from /Applications/Utilites on the mac and change directory to where the Virtual machines are located. Change directory to the first node and locate the .vmx file that is in there, this will need opening in vim and the following line will need adding to it:

disk.locking = "FALSE"

In VMware fusion open the settings of the second node and rename it to node-b to make it easier to differentiate between the nodes in VMware. Open the settings of the first node, and go to the hard disks setting. Add 3 or more hard disks to the first node, and apply the changes, these disks will be used as our shared storage for the cluster. Open the hard disk settings for the second node and add a disk to the virtual machine, under the filename drop down menu select Choose existing disk… and add the disks from node-a, whilst ensuring that ‘Share this virtual disk …’ is selected. Also add another two network adapters to each virtual machine, these will be used for the cluster interconnects.

Step #4

Start the nodes up that are part of the cluster, you should test the disks are visible by using the format command. Copy the sun cluster installer over to both nodes and either using X forwarding or just use the console start the installer. Once the installer starts ensure that the following components are installed:

Sun Cluster

Sun Cluster Agentts

Quorum Server

The installer will patch a few packages and then confirm that the system requirements are met. Select ‘Configure Now’ and ensure that Support for Remote configuration is enabled, then start the installer.

Step #5

Once the installer has finished, you’ll be returned to the prompt and its not the point to actually ‘install’ the cluster. On the first node (node-a), change to the cluster binaries directory /usr/cluster/bin and start scinstall. Select the Create a new cluster node and follow the actions below, ensure that you select Custom cluster install.

What is the name of the cluster you want to establish?  vmcluster

Node name (Control-D to finish):  node-a

Node name (Control-D to finish):  node-b

Node name (Control-D to finish):  ^D

Do you need to use DES authentication (yes/no) [no]?  no

Should this cluster use at least two private networks (yes/no) [yes]?  yes

Does this two-node cluster use switches (yes/no) [yes]?  no 

Then for the cluster interconnects ensure that e1000g1 connects to e1000g1 and e1000g2 connects to e1000g2.

Is it okay to accept the default network address (yes/no) [yes]?  yes

Is it okay to accept the default netmask (yes/no) [yes]?  yes

Do you want to turn off global fencing (yes/no) [no]?  no

Do you want to disable automatic quorum device selection (yes/no) [no]?  no

The Globaldevices set up should use /globaldevices by default, it will check the existence on both nodes.

Is it okay to create the new cluster (yes/no) [yes]?  yes

Interrupt cluster creation for cluster check errors (yes/no) [no]?  no

{cluster installs and nodes reboot}

Step #6

If you wish to use the Solaris webconsole plugin for Sun Cluster, it helps to bind the console listening port to an external IP as it’s bound to localhost by default:

# smcwebserver stop
 # svccfg -s svc:/system/webconsole setprop options/tcp_listen = true
 # svcadm refresh svc:/system/webconsole
 # /usr/share/webconsole/private/bin/wcremove -i console
 # svcadm clear system/webconsole:console
 # smcwebserver start

This can then be accessed on http://VM_IP:6789/ .

Job done.