• “hosted” hypervisor or type 2 hypervisor where as a “bare-metal” or “type 1″ hypervisor would run directly on the hardware
• open virtualization format (OVF)
• VirtualBox Remote Desktop Extension (VRDE) – also support for full client USB Support
• Extensible RDP authentication
• USB Over RDP
• Extension packs available
  • the virtual USB 2.0 (EHCI) device
  • virtual boc remote desktop protocol
  • Intel PXE boot RPM with support for E1000 network card
• fixed sized hard disk image is faster and has less overheads compared to an expanding overhead
• different kinds of disks:
  • VDI
  • VMDK
  • VHD
  • HDD
• Two importable formats:
  • VMDK with a file in an XML Dialect with an .ovf extension. These files must reside in the same directory for the VirtualBox to be able to import them.
  • Everything in a single archive called the .ova extension. its an archive file with a variant of the TAR archive format)
• Commmands in the virtualbox package
  • VirtualBox – virtualbox manager
  • VBoxManage is a command line manager fro very detailed control
  • VBoxSDL for simple graphical frontend
  • VBoxHeadLess is yet another frontend to produce no visible output on the host at all.
• Dynamic Kernal Module Support requires to be installed, this framework helps with building and upgrading kernel modules.
• if the kernel of your linux host was updated and DKMS is not installed, in that case the kernel module will need to be reinstalled by executing (as root)

  $ /etc/init.d/vboxdrv setup
  

• virtualbox now not only supports PIIX3 but also the ICH9 chipset for latest operating systems like macosx
• Auto mounting: linux guests automounted shared folders are mounted into /media directory align with the prefix sf_. for example, the shared folder mayflies would be mounted to /media/sf_myfiles on linux. The sf_ is controlled by the property /VirtualBox/GuestAdd/SharedFolders/MountPrefix
• access to the automounted folders is only granted to members of the user vboxsf
• listing the virtualbox guest property

  $ VBoxManage guestproperty enumerate "Windows Vista" 

  or listing a specific property

  $VBoxManage guestproperty get "windows vita" "/VirtualBox/GuestInfo/OS/Product"

• to change values use $ VBoxControl guestproperty enumerate
• VBoxManage guest-control to run commands inside the guest from the host machine
• Memory ballooning is used to share memory associated with a vm with another vm. This is used for memory over commitment.
• VBoxManage controlvm “VM Name? guestmemoryballoon where n is the memory the memory to allocate the guest vm. the guest additions software must be installed for this to run.
• Virtual box dedups the page duplication by using PageFusion you can only turn it on when a vm is turned off
• VBoxManage modifyvm "VM Name" --pagefusion on
  you can observe page fusion operation using metrics RAM/VMM/Shared shows the total amount of fused pages, whereas the per-vm metric guest/RAM/Usage/Shared will return the amount of fused memory for a given VM.
• Virtualbox allows you to manage the size of the disk even after the disk creation, even after data has been written to it.
• Virtualbox disk format:
  • normally by default for a new image, the format it uses is called Virtual Disk Image (VDI).
  • VirtualBox also fully supports the popular and open VMDK contrainer format that is used by many popular virtualization softwares like VMWare.
  • Alsofully supports the VHD format from microsoft.
  • Image files from Parallers version 2 (HDD format) also supported. newer formats 3, and 4 are not supported however you can convert them into older format (version 2) by using tools provided by parallels.
• Do not simply make copies of virtual disk images. if you import such a second copy into a virtual machine, virtualbox will complain with an error, since VirtualBox assigns a unique identifier (UUID) to each disk image to make sure it is only used once.
• Disk modes:
  • normal mode, allows you to take snapshots and restore from it.
  • write-through hard disks: are completely unaffected by snapshots. their states are not taken and not restores when snapshots are restored.
  • shareable hard disks: works the same as write-though hard disks however they can be used to be shared across multiple VMS writing to it directly. standard filesystem is not setup to be written by multiple file systems at the same time.only fixed size images can be used in this way, and dynamically growing images are rejected.
  • immutable images only remember write access temporarily while virtual machines are running. so the approach is create a new ‘normal’ image and once you are happy with the setup and deem its contents useful then mark it ‘immutable’;
  • if you take a snapshot of a machine with immutable images, then on every machine power-up those images are reset to the state of the last (current) snapshot (instead of the state of the original immutable image)
  • As a result the same immutable image can be used by several virtual machines without restrictions. (Also looking at the ‘enabling the differencing disks’ that with auto-reset turned to off so that the vm’s sharing the immutable disk don’t forget the settings.
• An image in ‘multi-attach mode’ an be attached to more than one virtual machine at the same time, even if these machines are running simultaneously. For each virtual m aching to which an image is attached, a differencing image is c reared. As a result data that is written to such a virtual disk by one machine is not seen by the other machines to which the image is attached. each machine creates its own history of the multi-attach image.
• The standard approach would be ‘one immutable disk for the operating system’ and one ‘write-though’ for your data files.
• Networking: virtualbox providers up to eight virtual PCI ethernet cards for each virtual machine. for each such card, you can individually select:
  • The hardware that will be virtualised as well as
  • The virtualization mode that the virtual card will be operating in with respect to your physical networking hardware on the host.
• Networking modes:
  • Not attached: in this mode the virtualbox reports to the guest that a network card is present but there is no connection, as if no ethernet cable was plugged into the card.
  • NAT: default mode, only required to browse the web, download files and view email inside the guests. certain limitations when windows file sharing.
  • Bridged network: more advanced needs such as network simulations and running servers in a guest. when enabled virtual box connects to on our installed network cards and exchanges network packets directly, circumventing your host operating system’s network stack.
  • Internal networking: visible to only certain software based networking (selected virtual machine) but not to applications running on the host or the outside world. Internal networking is the same as bridged networking as that it lets the vm speak to the outside world except that the outside world is the other vm’s on the same host.
  • Host-only networking: create a networking containing the host and a set of virtual machines without the need of the host’s physical network interface. instead a virtual network interface (similar to loopback interface) is created on the host, providing connectivity among virtual machines and the host.
  • VDE (virtual distributed ethernet) networking:
• port forwarding

  VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,,2222,,22"
  natpf1 denotes the network card
  2222 is the port on the host
  22 is the port on the guest
  guestssh is purely description and will be auto-generated if not present
  

• to remove the same rule:
  VBoxManage modifyvm "VM name" --natpf1 delete "guestssh"

  NOTE: it is not possible to configure incoming NAT connections while the VM is running. However, you can change the settings for a VM which is currently saved (or powered off at a snapshot)

• bridged networking: with bridged networking, virtualbox uses a device driver on your host system that filters data from your physical network adapter. this driver is therefore called ‘net filter’ driver. this allows virtualbox to intercept data from the physical network and inject data into it, effectively creating a new network interface in software. When a guest is using such a new software interface, it looks to the host system to the host system as though the guest were physically connected to the interface using a network cable. the host can send data to the guest though that interface and receive data from it. thismeans that yo can setup routing and bridging between the guest and the rest of your network.
• running virtualbox as headless

  VBoxManage startvm "VM Name" --type headless

  the extra –type option causes VirtualBox to use VBoxHeadless as the front-end to the internal virtualization engine instead of the qt-front-end
  the alternate syntax is:

  VBoxHeadless --startvm <uuid|name>

Steps to install a vm headless server

create a new virtual machine

VBoxManage creative --name "Windows XP" --ostype WindowsXP --register

--registervm is optional, doing it now saves you from having to do that manually later.
--ostype is also optional but selecting this upfront results in some default options to be selected.
[/cpde]

To get the complete list

<code>VBoxManage list ostypes</code>
<ul>
<li>make sure that the vm is configured the guest operating system.
	1VBoxManage modifyvm "Windows XP" --memory 256 --acpi on --boot1 dvd --nic1 nat

VBoxManage createhd --filename "WinXP.vdi" --size 10000

VBoxManage storagectl "Windows XP" --name "IDE Controller" --add ide --controller PIIX4

VBoxManage storageattach "Windows XP" --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium "WinXP.vdi"

VBoxManage storageattach "Windows XP" --storagectl "IDE Controller" --port 0 --device 1 

dvddrive --medium /full/path/to/iso.iso

VBoxHeadless --startvm "Windows XP"

Structure of a resource
user {'dave':
	ensure => present,
	uid => '507',
	gid => 'admin',
	home => '/home/admin',
	managehome => true,
}
# details about current resource instance
$ puppet resource user root
# reading up documentation about a resource type
$ puppet describe -s user

# resource declaration and application to test snippet
#/root/training-manifests/1.file.pp
file {'testfile':
	path => '/tmp/testfile',
	ensure => present,
	mode => 0640,
	content > 'i am a test file',
}
#and call apply
$puppet apply 1.file.pp

# notify user
notify {"this is a notice message"}

# Controlling order of execution
file {'/tmp/test1':
	ensrue => present,
	content => 'hi',
}
notify {'/tmp/test1 ahs already been synced':
	require => File['/tmp/test1']
}

#but along from require there are:
#- before
#- require
#- notify
#- subscribe

# Chaining:
file {"/tmp/test1":
	ensure => present,
	content => 'h1',
}
notify {'after':
	message => '/tmp/tesst1'
}
File['/tmp/test1'] -> Notify['after']

ssh example:
# /root/learning-manifests/break_ssh.pp, again
file { '/etc/ssh/sshd_config':
	ensure => file,
	mode => 600,
	source => '/root/learning-manifests/sshd_config',
}
service { 'sshd':
	ensure => running,
	enable => true,
	hasrestart => true,
	hasstatus => true,
	# FYI, those last two attributes default to false, since
	# bad init scripts are more or less endemic.
	subscribe => File['/etc/ssh/sshd_config'],
}

# /root/learning-manifests/break_ssh.pp
package { 'openssh-server':
	ensure => present,
	before => File['/etc/ssh/sshd_config'],
}
file { '/etc/ssh/sshd_config':
	ensure => file,
	mode => 600,
	source => '/root/learning-manifests/sshd_config',
}
service { 'sshd':
	ensure => running,
	enable => true,
	hasrestart => true,
	hasstatus => true,
	subscribe => File['/etc/ssh/sshd_config'],
}

Variables:
$variables always start with a dollar sign
can hold strings, numbers, value like undef etc
fully qualified variables look like $scope::variable top level variables are the same, but their scope is nameless $::top_scope_variable
you can only assign a variable once in a given scope

if condition {
    block of code
} elsif condition {
    block of code
} else {
    block of code
}

if $is_virtual {
    service {'ntpd':
    ensure => stopped,
    enable => false,
  }
} else {
    service { 'ntpd':
    name => 'ntpd',
    ensure => running,
    enable => true,
    hasrestart => true,
    require => Package['ntp'],
  }
}

case $operatingsystem {
    centos: { $apache = "httpd" }
    # Note that these matches are case-insensitive.
        redhat: { $apache = "httpd" }
        debian: { $apache = "apache2" }
        ubuntu: { $apache = "apache2" }
        default: { fail("Unrecognized operating system for webserver")
    }
    # "fail" is a function. We'll get to those later.
}
package {'apache':
    name => $apache,
    ensure => latest,
}

Modules and Classes
class {'security_base': }
class {'webserver_base': }
class {'appserver': }

Classes are singleton collections of resources that puppet can apply as a unie. you can think of them as blocks of code that can be turned on or off. 

class ntp {
	package {'ntp':
		ensure => installed,
	}
}

But to use the class you need to define the class then declare it
class {'ntp': }

# puppet apply --verbose ntp-class.pp
there's there way to declare classes, but it behaves a little bit differently

include ntp
include ntp
include ntp

The include function will declare a classs if it hasn't already been declared, and will do nothing if it has. This means that we can use it safely multiple times, whereas the resource syntax can be used only once. The drawback is that include can't currently be used with parameterized classes, on which more later.

Module Structure:
{module}/
	files/
	lib/
	manifests/
		init.pp
		{class}.pp
		{defined type}.pp
		{namespace}/
			{class}.pp
			{class}.pp
		{templates}/
		{tests}/

- the main directory should be named after the module
- all of the manifests go in the manifests directory
- init.pp that holds the modules main class.
- modules are very useful as they allow for namespacing and grouping of classes

foo/
	manifests/
		init.pp
		bar.pp
		bar/
			baz.pp
init.pp would contain class foo {}
bar.pp would contain class foo::bar {}
baz.pp should contain class foo:bar::baz {}

puppet:///module/testing/test.txt
	will go in {puppet}/modules/{$module}/files

~/.bashrc file
mkmod() {
	mkdir "$1"
	mkdir "$1/files" "$1/lib" "$1/manifests" "$1/templates" "$1/tests"
}

rendering from a template:
file {'/etc/foo.conf':
	ensure => file,
	require => Package['foo'],
	content => template('foo/foo.conf.erb'),
}

if you pass more than one template then it will evaluate both of them and concat the output

template('foo/one.erb', 'foo/two.erb');

Parameterized classes:

class mysql($user, $port) {}
class paramclassexample($value, $value2 = 'default value') {
	notify {'value 1 is ${value1: }
}

More examples/details available here http://docs.puppetlabs.com/guides/language_guide.html

[root@localhost ~]# yum install createrepo
[root@localhost ~]# mkdir -p /opt/acc/repo
[root@localhost ~]# createrepo /opt/acc/repo/

Saving Primary metadata
Saving file lists metadata
Saving other metadata

[root@localhost ~]# tree /opt/acc/repo/
/opt/acc/repo/
`-- repodata
    |-- filelists.xml.gz
    |-- other.xml.gz
    |-- primary.xml.gz
    `-- repomd.xml

Now adding this repo details to the repo-register.

[localrepo]
name=Fedora Core $releasever - My Local Repo
baseurl=file:///mnt/fc_local_repo/
enabled=1
gpgcheck=0
#gpgkey=file:///path/to/you/RPM-GPG-KEY

You can also serve the base url over http in which case the protocol would change from file:/// to http:// or https:///

• You can have your product backlog, sprint backlog and tasks all in one place
• Agilo manage your backlogs and provide fancy metrics of how your sprint is doing
• SVN ties well into trac which means you can tie commits back into sprint tasks, which means you have a traceability matrix of the tasks/defects and the code changes made to close it
• Trac also helps you manage a milestone so you can have a high-level view of how you are doing against your deadlines to meet a milestone

You can read more about them here Agilo and Trac

You first need to enable repoforge for your RHEL install and then install the required packages

[root@localhost ~]# rpm -Uhv http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS//rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm
[root@localhost ~]# yum -y install subversion trac mod_dav_svn mod_python

Now you need to create the directories for svn repos, trac project and auth directory. I choose /var/www/ but you can choose anything else you want.

[root@localhost ~]# mkdir -p /var/www/svn/svnrepos #holds the svn repos
[root@localhost ~]# mkdir -p /var/www/trac #trac base folder
[root@localhost ~]# mkdir -p /var/www/svn/auth #holds the htaccess files
[root@localhost ~]# htpasswd -c /var/www/svn/auth/svn.htpasswd svnuser
[root@localhost ~]# svnadmin create /var/www/svn/svnrepos/secret-project #create svn repo

Now create the initial svn folders/files in the repo

[root@localhost ~]# svn mkdir file:///var/www/svn/svnrepos/secret-project/branches  \
file:///var/www/svn/svnrepos/secret-project/tags  \
file:///var/www/svn/svnrepos/secret-project/trunk  \
-m 'creating directories for initial import'

Committed revision 1.

Now create your first trac project

[root@localhost ~]# trac-admin /var/www/trac/secret-project \
permission add tracuser TRAC_ADMIN

You will need then require to go the settings of trac to give it the svn repo patch and then using trac-admin to call resync.

[root@localhost ~]# trac-admin $ENV repository resync "secret-project"

You would also require a post commit hook to ensure that trac gets updated every time a new commit is made. There is plenty of information available on http://trac.edgewall.org/wiki/CommitTicketUpdater, but basically you need is an svn post commit hook which calls trac-admin $ENV changeset added 'secret-project'.

Installing Agilo can be done using a plugin. If you have easy_install installed even better. Just follow the instructions as follows

[root@localhost ~]# easy_install <agilo>.egg
[root@localhost ~]# cd /var/www/trac/britebill-holepunch/conf
[root@localhost conf]# trac-admin /var/www/trac/secret-project/ upgrade #upgrade trac post plugin install
Creating Product Backlog...
Creating Sprint Backlog...
Upgrade done.
[root@localhost conf]# trac-admin /var/www/trac/britebill-holepunch/ wiki upgrade #upgrade trac wiki as well

Now you can use the web interface to configure the project even more, adding your backlogs, tickets etc. Agilo also allows you to import your backlog from an xls sheet which is great as most product managers are still stuck in the xls era and refuse to let it go.

Note: This post assumes you are working on an ubuntu instance but the same rules applies for any other unix variant as long as you have the right tools installed. The method of installing the tools might vary based on the distribution available

You need to have the following available before you start:

• An EC2 public key (public part of the keypair) to access your instance
• A X.509 cert and private key (see previous post for more details)
• Your aws access id/key and secret key
• Packages ec2-api-tools and ec2-ami-tools installed in the customized ami

In case you don’t have the ec2 installed, you need to enable the repos by uncommenting the following lines in /etc/apt/sources.list

#deb http://gb.archive.ubuntu.com/ubuntu/ maverick multiverse
#deb-src http://gb.archive.ubuntu.com/ubuntu/ maverick multiverse
#deb http://gb.archive.ubuntu.com/ubuntu/ maverick-updates multiverse
#deb-src http://gb.archive.ubuntu.com/ubuntu/ maverick-updates multiverse

On the ec2 instance, run the following command to ensure that its fully updated and have the required packages installed. This assumes that the required customization have been done at this stage.

ubuntu@ip-20-56-39-198:~$ sudo apt-get update && sudo apt-get install ec2-ami-tools ec2-api-tools

SCP you x.509 and private key to the ec2 instance at this stage and move it to /mnt/certs you would need to create the directory as its not already present.

rp@localhost$ scp -i ec2-keypair-key.pem aws-x509-cert.pem private-key.pem ubuntu@ec2-20-56-39-198.compute-1.amazonaws.com:~/

Just so that you know /mnt is a mounted block device which means that anything you put it in isn’t part of the AMI (unless of-course you explicitly ask for it). This is the reason why we would store the bundled image in the /mnt directory instead. You can also verify this by running $ sudo fdisk -l to see the list of all block devices and their partitions.

Before you start bundling your images there are a couple of things that would be worth looking into to ensure that your AMI is safe and you are not inadvertently giving anyone access to the ec2 instances that would be launched using the AMI.

• Disable password based logins for root (or for accounts in the admin group if using ubuntu). Modify /etc/ssh/sshd_config.

  #PermitRootLogin yes
  PermitRootLogin without-password
  

• Randomize the root password at boot time to ensure the password can’t be guessed (additional security following the previous point. A script in rc.local can do the trick
• Remove ssh host key pairs to ensure new ones get generated for each instance of the AMI. Especially useful when using with puppet. Delete all ssh_host_* files in /etc/ssh/.
• Disable sshd dns checks. This doesn’t make it any more safe, just ensures that even if the DNS isn’t working the ssh server can still let you connect. It would otherwise try and do a reverse lookup before establishing connection. Disabling it also speeds up the process of connecting.
  Modify /etc/ssh/sshd_config


  #UseDNS yes
  UseDNS no
  

• Remove all entries in the ~/.ssh/authorized_keys and for other user accounts that were configured to work in that manner as well. This would ensure that the instances from the AMI don’t give access to users who had the orig. keypair when creating the customized AMI
• Clear the following files .bash_history, .viminfo and any other files that store information about your current session of usage.
• Remove passwords for all user accounts that are allowed login

   ssh passwd -l
  

• Modify sshd to allow only public key authentication, modify /etc/ssh/sshd_config

  PubKeyAuthentication yes
  PasswordAuthentication no
  

• Delete all shell history, system lot etc that might contain sensitive information

To bundle the AMI, run the following command

$sudo ec2-bundle-vol -k /mnt/certs/private-key.pem \
 -c /mnt/certs/aws-x509-cert.pem \
 -u  \
 -d /mnt/instance-store/ \
 -r i386

You need to create a s3 bucket to store this for future use. Lets say that bucket is called my-ami
Now upload the bundle to the s3 bucket

$ ec2-upload-bundle -b my-ami \
  -m instance-store/image.manifest.xml \
  -a your-account-access-key \
  -s your-account-secret-key
  --region us-west-1

The --region is optional and is sometimes required if your bucket is in a different region.

and then the last part is to register the AMI, this process will give you an AMI id which you can then use to launch instances that are a copy of the AMI.

$ ec2-register my-ami/my-prefix.manifest.xml \
  --name my-ami \
  --description 'Describe the type of server here'  \
  -K  /mnt/certs/private-key.pem\
  -C /mnt/certs/aws-x509-cert.pem \
  -a i386

This command would return back an AMI id.

• Create an account alias using IAM even if you are the only single user using the aws account. Helps scale out to bigger teams when you need to with better granular access controls. You can read more about it here http://aws.amazon.com/documentation/iam/
• The process of creating the user will generate Access Id, Secret and also the password that will be used to login to the new Alias url
• Login via the newly created account on the account alias url and start a new project
• IAM doesn’t create your x.509 certificates for you, so you would need to do that yourself and upload it
• Use the following commands to generate a key for yourself

  $ openssl genrsa 1024 > private-key.pem #generate private key
  $ openssl req -new -key private-key.pem -out cert.pem #generate csr
  $ openssl x509 -req -days 365 -in cert.pem -signkey private-key.pem -out project-cert.crt #generate the final certificate
  

  

  From the definition in the documentation:

  • Access keys: symmetric key encryption. These are for making requests to AWS product REST or Query API. Can be obtained/regenerated from the access keys tab on the was security credentials page
  • X.509 certificates: public key encryption. use x.509 certificates to make secure SOAP protocol requests to AWS service API. These are the credentials you will use when using the command-line ec2 API tools. can be obtained/regenerated from the x.509 certificates tab on the AWS Security credentials page.
  • Key pairs: SSH key pairs when you create an intense amazon inserts the public key of your ssh key pairs into your new instance so that you can log in using your private key. you can add new ssh key-pairs though the AWS management console by clicking on Key Pairs.
• Upload the content of the crt in the popup that shows up when you click on ‘Managing Signing Certificates’. When finished it will give you a certificate id that can be used to reference certificates if you have more than one.
• Update the .bash_profile with the new variables that the tools would use.

  export EC2_KEYPAIR=$HOME/.ec2/sa/sa-aws-keypair.pem #this is the keypair you generate/download
  export EC2_PRIVATE_KEY=$HOME/.ec2/sa/private-key.pem #this is the private key used to generate the cert
  export EC2_CERT=$HOME/.ec2/sa/aws-sa.crt #this is the cert you generated and uploaded
  export JAVA_HOME=/usr/lib/jvm/java-6-sun
  

  and then update your shell with the new shell variables

  $source ~/.bash_profile
  

• Obviously then you need to install the tools if you don’t have it installed already. In you are using ubuntu you need to enable some repositories. Edit /etc/apt/sources.list and uncomment the following lines:

  #deb http://gb.archive.ubuntu.com/ubuntu/ maverick multiverse
  #deb-src http://gb.archive.ubuntu.com/ubuntu/ maverick multiverse
  #deb http://gb.archive.ubuntu.com/ubuntu/ maverick-updates multiverse
  #deb-src http://gb.archive.ubuntu.com/ubuntu/ maverick-updates multiverse
  

  and then update and install

  rp@supernova:~$ sudo apt-get update && sudo apt-get install ec2-ami-tools ec2-api-tools
  

• Now test the configuration

  $ ec2-describe-images -o amazon
  

  if you see some results come back you are pretty much setup.

In order to use the phing script you would require to do the following:

• Clone/download the code from git@github.com:rajatpandit/phing-website-packaging.git
• Copy the debian folder across to your project
• Tweak the files in there to match your projects requirements
• The file names ending in .in are the template files that the phing script will take and modify before actually building the package for you
• The phing script modifies the files based on two arguments that you provide build.project and build.version
• The other file you need to look out for for is the install.in which contains the “from” and “to” locations of the files which will get deployed when the package is installed
• The other files would required to be tweaked accordingly
• Once you are happy with the changes, copy the package.xml file at the same level as the debian folder and ensure that the required packages are installed (refer to my previous post to know about the names of the packages
• Execute the phing script as follows e.g.

  $phing -f package.xml -Dbuild.version=1.0 -Dbuild.project=top-secret-project
  

In addition to the basic targets, it also has some additional target to rebuild the meta-information about your local repo. In case you don’t need one or use one, feel free to take the targets out.

Any questions, suggestions recommendations etc, as always please leave a comment.