See here: http://lonesysadmin.net/2013/10/17/notes-on-upgrading-the-vmware-vcenter-server-appliance-5-1-to-5-5/
cpio unix *
Monday, 9 December 2013
Tuesday, 19 November 2013
Shared storage in VMware workstation
Create an independent, persistent drive as a single file.
shut down your hosts / VMware workstation and edit the appropriate vmx file for each host, here are examples to work from:
# Amend, change these:
scsi1.present = "TRUE"
scsi1.virtualDev = "lsilogic"
scsi1:1.present = "TRUE"
scsi1:1.fileName = "E:\vmware\sharedds\sharedds1.vmdk"
scsi1:1.mode = "independent-persistent"
# Add these:
disk.locking = "false"
diskLib.dataCacheMaxSize = "0"
Do this on both (or more!) hosts vmx file and you should be able to boot them without locking issues.
Monday, 18 November 2013
Importing other VMs into VMware
The solution is easy: Manually load the multiextent module by running
Thursday, 14 November 2013
Puppet basic requirements notes
- Ruby 1.8.7, 1.9.3 or 2.0.0 (from http://docs.puppetlabs.com/guides/platforms.html#ruby-versions )
Firewall ports:
- Puppet Master needs 8140 incoming open, agents connect to this port
Linux:
- RHEL 5 (requires drop-in Ruby version available from puppet labs)
- RHEL 6
- Debian 6 Squeeze
- Debian 7 Wheezy
- Debian Sid
- Ubuntu 12.04 LTS
- Ubuntu 10.04 LTS
- Ubuntu 12.10
- Ubuntu 13.04
- Fedora 17, 18, 19
- SuSE 11
- Others (see http://docs.puppetlabs.com/guides/platforms.html )
Unix:
- OS X 10.5, 10.6, 10.7, 10.8, 10.9
- Solaris 10, 11
- AIX 5.3, 6.1, 7.1
- HP-UX
Windows:
- Server 2012
- Server 2008 and Server 2008 R2
- Server 2003 and Server 2003 R2
- 7 and 8
- Vista
Packages:
- Factor, Hiera, rgen
- base64
- cgi
- digest/md5
- etc
- fileutils
- ipaddr
- openssl (>= 0.9.8o if using a 3.x Puppet master or newer)
- strscan
- syslog
- uri
- webrick
- webrick/https
- xmlrpc
On Puppet
Here’s what I know so far:
Puppet is a tool for managing the configuration of large sets of hosts. It can be used for software provisioning, enforcing configuration, automating repetitive tasks, user management, etc.
Puppetlabs tries to describe its process as “Define, Simulate, Enforce, Report”: PL_howpuppetworks_notitle.png
Each managed system has a Puppet agent installed, reporting to the Puppet Master, this reporting is referred to as ‘facts’. The Puppet master compiles the facts into the ‘catalog’. This ‘catalog’ data is compiled and returned to the agent about what state it should be in. Any required changes are made to bring the system into the required state (in ‘no-op’ mode it just simulates the actions). Then a ‘report’ is sent back to the master. This report is available via open API for integration into other systems (CMDB I guess? Also monitoring solutions, Xymon, Nagios etc.).
Next step: grab the learning VM: http://docs.puppetlabs.com/learning/ The Learning Puppet series
Change of tack
Clearly the original idea wasn't something that drew me back to writing about it so how could I expect anyone else to care about reading about it?
I've decided to change tack and turn this into a public notebook of my learnings about Redhat Enterprise Linux, VMware, Puppet Enterprise and Amazon’s Cloud technologies.
Although I’ve been working with Unix and Linux for nearly 20 years now, it’s startling how diverse the field has got and I’ve completely missed out on what Redhat and VMware have been up to, simply through working with competing technologies that are now somewhat falling by the wayside.
So I don’t anticipate this being useful as a reference for most, but perhaps some of it may be of use.
;&)