VMWorld 2014

As you may know, VMworld 2014 is going on with some big announcements. I didn’t have a chance to take part but fortunately we can find more information from a couple of active bloggers writing about new features, products and visions in VMware. So far, the interesting things to me are:

  • VMware Integration with OpenStack : Apparently, VMware is less flexible for developers comparing to public clouds and VMware is trying to mitigate this gap by OpenStack.
  • EVO: Rail – VMware converged Hardware : While there are some other smaller companies (VMware partners like Nutanix) who provide VMware appliances, I guess VMware sees a demand for this and wants to positively increase competition in converged hardware based on VMware. It’s also getting closer to a Software Defined Data Center. In EVO:RAIL there is a software layer which facilitates deployment of VMware ESXi’s and vCenter and managing VM’s. The interesting thing in EVO:RAIL is the use of VSAN. It’s more suitable for small to medium deployments I would say.
Advertisements

Key authentication with SSH Secure Shell

Non-commercial version of SSH Secure Shell (can be obtained here) from SSH Communications Security is a decent ssh client that I have used for many years in my experiments and academic works. It lacks PKI and PKCS functionality, but still safe for experiments! However; when it comes to public key authentication, it needs some tweaks to work. Here are the steps required to enable key authentication over a Linux host; given that Linux host settings allow public/private key authentication:

  1. Connect to the host using SSH Secure Shell (by password)
  2. In Secure Shell client, go to: Edit -> Settings -> User Authentication -> Keys and click on ‘Generate New’
    ssh1
  3. When generation is done, it will ask you to upload the public key to the host. Let it upload to ‘.ssh ‘ as destination folder.
    ssh2
  4. It assumes that the host has the appropriate SSH server for this client (the company has SSH server too) but since standard Linux servers use OpenSSH as SSH server, uploading the public key to the host is not enough and needs some modifications that follows.
  5. In Linux host, you will see that a public key (KeyAuthTest.pub in this case) is uploaded in ‘.ssh’ directory. For this to work, there are 2 ways:
    • Edit ‘KeyAuthTest.pub’ manually! and give it the right format. Remove these lines (or something like this) in the beginning:
      —- BEGIN SSH2 PUBLIC KEY —-
      Comment: “[3072-bit rsa, yyyy@xxxx, Thu Oct 04 2012 21:33:49]”
      And this at the end:
      —- END SSH2 PUBLIC KEY —-
      Also, you need to remove all the carriage returns (CR) in this file. Then add ‘ssh-rsa’ in the beginning of the file. The file would be something like:
      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+…
      Finally, in shell append this file to the ‘authorized_keys’ file :
      cat ~/.ssh/KeyAuthTest.pub >> ~/.ssh/authorized_keys
    • Second approach: convert the key to proper OpenSSH format automatically and append it to the file:
      ssh-keygen -i -f ~/.ssh/KeyAuthTest.pub  >>  ~/.ssh/authorized_keys

Now, you will be able to connect to the host, using this public key.

MS SQL Server Clone in VMware

Having templates and cloning VM’s can be very handy for fast deployment. Suppose that you want to deploy an instance of a sophisticated Web application consisting of different functional servers like database, web, mail, messaging, etc. It is desirable to clone the whole application, saving lots of time to configure each server and establish connectivity between them. VMware enables us to do this by using vApp templates. vApp templates are also available in vCloud Director.

However, when it comes to Microsoft SQL Server, an issue is raised when you rename the server during cloning or customize operating system in vCloud! It’s because SQL server contains some internal databases (like master) and metadata that store system name and working with SQL server in this situation will cause problems. To prevent this issue, you can do the following:

1) Enable a sysadmin SQL account (like ‘sa’) before cloning.

2) After clone, login to new SQL Server using a non-Windows sysadmin (like ‘sa’)

3) issue the following commands in a Query window:
exec sp_dropserver ‘OldserverName’
go
exec sp_addserver ‘NewServerName’, ‘LOCAL’
go

4) Restart SQL Server services