DaemonZone

With the release of VMware vSphere 5.1 some additional components are required when deploying a vCenter server: the vCenter Single Sign On and the vCenter Inventory Service.

If you decide to install everything, database included, in one Windows system you should fix the services start-up order or, sooner or later, your vCenter won't automatically start after a reboot because of a race condition.

Previous VMware instructions must be a little bit modified to include the new components. The right start-up order is the same as the installation order:

1. SQL Database (MSSQLSERVER)
2. vCenter Single Sign On (ssotomcat)
3. vCenter Inventory Service (vimQueryService)
4. vCenter Server (vpxd)

To achieve that on Windows 2003 (but it is probably the same on newer Windows versions) you need to modify the windows registry.

Using regedit go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ssotomcat, create a new Multi-String Value called DependOnService and add MSSQLSERVER (or the name of your MSSQL Server instance) as a value data. This ensure that the vCenter SSO service will start after the MSSQL instance.

For the vCenter Inventory Service go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vimQueryService and add ssotomcat as a service dependence.

For the vCenter Server itself go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vpxd and ensure that the DependOnService key contains the following entries:

ProtectedStorage
lanmanworkstation
MSSQLSERVER
ADAM_VMwareVCMSDS
ssotomcat
vimQueryService

Additionally, if you have the "VMware USB Arbitration Service service hung on starting" error go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VMUSBArbService and add the MSSQLSERVER string to the DependOnService key.

To verify that the dependencies were added go to the services.msc snap-in, click on the corresponding service and check the dependencies tab.

This should be enough to fix the dependencies problem of the vCenter 5.1 until VMware will release a patch for that.

By the way, if you are wondering why the start-up is so slow read vCenter Server 5.1 start up may take longer than previous versions.

References: VMware KB 2035933, VMware KB 1007669, VMware KB 2034975

This morning I faced this error when starting Luci (luci-0.26.0-13.el6.centos.x86_64) after a clean installation on a CentOS 6.3:

# service luci start
Unable to create the luci base configuration file (`/var/lib/luci/etc/luci.ini').
Start luci...                                              [FAILED]

Googling I found this bug. The problem seems to be the conflict with some EPEL packages so to prevent it just disable the EPEL repo when installing Luci:

# yum install --disablerepo=epel* luci

and it will now work without any problem.

Then, as suggested on comment #5 of the related bug 741324, exclude the conflicting package python-repoze-who-friendlyform to prevent problems during upgrades. To accomplish that add to the /etc/yum.repos.d/epel.repo file the line exclude=python-repoze-who-friendlyform on the [epel] section:

[epel]
name=Extra Packages for Enterprise Linux 6 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
exclude=python-repoze-who-friendlyform

As an alternative you can setup the yum priorities plugin and assign an higher priority (so a lower numerical priority) to the CentOS Base and CR repositories.

...or at least this is what they think.
You should read Troy Hunt's article about Tesco's approach to web security and some common security mistakes that a web developer should learn in order to avoid them.

If you are a developer or a pen tester, the OWASP website has tons of information that will be useful to you.

I'm noticing that a lot of people use a syntax like:

for f in $(ls *.cfg); do    # Wrong!

in Bash scripts. Even if it works in most cases, it will fail when a file contains a space in its name.
According to Bash Pitfalls this is one of the most common mistakes in Bash scripting. You should avoid it and instead use something like:

for f in *.cfg; do
  some_command "$f"
done

I migrated my media center from Ubuntu 11.10 to Fedora 17 and when I was trying to puppetize it I faced this error when starting the puppet daemon for the first time:

Could not request certificate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed.  This is often because the time is out of sync on the server or client

First thing I did of course was to check the time on both server and client but they where synchronized so the problem was somewhere else.

Googling I found this bug that matches exactly my case.
My puppet server is a CentOS 6.3 x86_64 with the following ruby, openssl and puppet-server versions:

# rpm -q {ruby,openssl,puppet-server}
ruby-1.8.7.352-7.el6_2.x86_64
openssl-1.0.0-20.el6_2.5.x86_64
puppet-server-2.7.18-1.el6.noarch

Puppet client is a Fedora 17 x86_64:

# rpm -q {ruby,openssl,puppet}
ruby-1.9.3.194-13.fc17.x86_64
openssl-1.0.0j-2.fc17.x86_64
puppet-2.7.13-1.fc17.noarch

The bug is not fixed yet but the workaround suggested in the comment #8 worked for me.
So I copied the ca.pem from the server to the client (if you use the official puppet rpm it is in /var/lib/puppet/ssl/certs/ca.pem) and then I ran the command that fixed my problem:

# ln -s /var/lib/puppet/ssl/certs/ca.pem $(openssl version -d|cut -d\" -f2)/certs/$(openssl x509 -hash -noout -in /var/lib/puppet/ssl/certs/ca.pem).0