vCloud Director 5.1.1 properly signed certificates - step-by-step

First, have an own root certificate :) - see my old post on this.
Then, generate a branch of new certs with signing requests on the vCloud Director.
The trick is: there are at least 2 "keytool" commands on a vCD server, one from the OS default (God knows what version) and one from the vCD installation, that should be used by us. Please note, that the "keystore" command version changes with vCD versions (as JRE version changes with it too), and of course the command syntaxes change too...
So, generate 2 certificates and their signing requests on the vCD node:

• /etc/init.d/vmware-vcd stop
• cd /opt/vmware/vcloud-director
• jre/bin/keytool -keystore certificates.ks -storetype JCEKS -storepass mypasswd -genkey -keyalg RSA -alias http -validity 3650
• jre/bin/keytool -certreq -keystore certificates.ks -storetype JCEKS -storepass mypasswd -alias http -file http.csr
• jre/bin/keytool -keystore certificates.ks -storetype JCEKS -storepass mypasswd -genkey -keyalg RSA -alias consoleproxy -validity 3650
• jre/bin/keytool -certreq -keystore certificates.ks -storetype JCEKS -storepass mypasswd -alias consoleproxy -file consoleproxy.csr

The "alias" names are mandatory to the 2 vCD IPs. When keystore asks "What is your first and last name?" the answer should be the IP addresses resolvable FQDN - 2 different FQDNs for the 2 IPs.

Now, copy the 2 .csr files over your signing machine, where the root certificate AND it's key file resides.

Sign the 2 signing requests, thus generating signed certificates.

• openssl x509 -req -in http.csr -CA myroot.crt -CAkey rui.key -CAcreateserial -out http.crt -days 3650
• openssl x509 -req -in consoleproxy.csr -CA myroot.crt -CAkey rui.key -CAcreateserial -out consoleproxy.crt -days 3650

Now, copy over the 2 newly generated certificates and the root certificate (not it's key!) to the vCD node.

Then, we should import the root certificate and the 2 signed certificated into the keystore:

• cd /opt/vmware/vcloud-director
• jre/bin/keytool -importcert -storetype JCEKS -storepass mypasswd -keystore certificates.ks -file myroot.crt -alias root
• jre/bin/keytool -importcert -storetype JCEKS -storepass mypasswd -keystore certificates.ks -file http.crt -alias http
• jre/bin/keytool -importcert -storetype JCEKS -storepass mypasswd -keystore certificates.ks -file consoleproxy.crt -alias consoleproxy
• You can check if the keystore is all right (should be) with: jre/bin/keytool -storetype JCEKS -storepass mypasswd -keystore certificates.ks -list
• Then, reconfigure vCD: /opt/vmware/vcloud-director/bin/configure - the store now should be at /opt/vmware/vcloud-director/certificates.ks
• And finally, start the service: /etc/init.d/vmware-vcd start

This should be all!

Axis P3343 IP Cam

The same thing as in 225FD works. This time I modified /etc/init.d/zzz script...

Embedded linux on the Axis 225FD IP Camera

Now this post has nothing to do with VMware.
I managed to get hold on an Axis 225FD IP camera (EOL already) powered by the Axis made ETRAX 100LX CPU, which is a simplified 32 RISC CPU (see http://kernel.org/doc/Documentation/cris/README).
First I flashed the latest firmware (and probably the last released one) on the device, 4.49.
The output was promising:

Preparing system for upgrade ...
Starting run level 4 (stop most daemons) ...
Waiting for run level 4 to start ...
Run level 4 started.
Waiting for run level 4 to finish ...
... waiting ...
... waiting ...
... waiting ...
... waiting ...
... waiting ...
Run level 4 finished.
Stopping some remaining processes.
sending TERM signal ...
Most processes stopped.
The file system will be upgraded after reboot.
Unmounting file system /var ...
Unmounting file system /mnt/flash ...
File systems successfully shut down.
found magic
Receiving new firmware ...
Receiving new firmware ...
Receiving new firmware ...
Erasing old file system ...
/dev/part/kernel
1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 11% 12%
13% 14% 15% 16% 17% 18% 19% 20% 21% 22% 23% 24%
25% 26% 27% 28% 29% 30% 31% 32% 33% 34% 35% 36%
37% 38% 39% 40% 41% 42% 43% 44% 45% 46% 47% 48%
49% 50% 51% 52% 53% 54% 55% 56% 57% 58% 59% 60%
61% 62% 63% 64% 65% 66% 67% 68% 69% 70% 71% 72%
73% 74% 75% 76% 77% 78% 79% 80% 81% 82% 83% 84%
85% 86% 87% 88% 89% 90% 91% 92% 93% 94% 95% 96%
97% 98% 99% 100%
Loading new file system ...
/dev/part/kernel
1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 11% 12%
13% 14% 15% 16% 17% 18% 19% 20% 21% 22% 23% 24%
25% 26% 27% 28% 29% 30% 31% 32% 33% 34% 35% 36%
37% 38% 39% 40% 41% 42% 43% 44% 45% 46% 47% 48%
49% 50% 51% 52% 53% 54% 55% 56% 57% 58% 59% 60%
61% 62% 63% 64% 65% 66% 67% 68% 69% 70% 71% 72%
73% 74% 75% 76% 77% 78% 79% 80% 81% 82% 83% 84%
85% 86% 87% 88% 89% 90% 91% 92% 93% 94% 95% 96%
97% 98% 99% 100%
The system upgrade completed successfully.
The unit will now reboot.
To continue, please connect to the unit again.
There may be a short delay before the new connection is accepted.
This connection will now close.

 So it does run Linux :)
Next, I enabled the ftp feature on the system. After logging on with the meaningful "root" account, I saw this:

Connected to 192.168.0.90 (192.168.0.90).
220 AXIS 225FD Network Fixed Dome Camera 4.49 (Mar 15 2010) ready.
Name (192.168.0.90:root): root
503 Bad sequence of commands.
SSL not available
331 User name okay, need password.
Password:
230 User logged in, proceed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 Command okay.
150 Opening data connection.
-rw-r--r-- 1 root root 30720 Mar 15 2010 .var.tar
drwxr-xr-x 1 root root 2444 Mar 15 2010 bin
drwxr-xr-x 1 root root 2020 Mar 15 2010 dev
lrwxrwxrwx 1 root root 13 Mar 15 2010 etc -> mnt/flash/etc/
drwxr-xr-x 1 root root 1228 Mar 15 2010 lib
-rwxr-xr-x 1 root root 1555 Mar 15 2010 linuxrc
drwxr-xr-x 1 root root 104 Mar 15 2010 mnt
dr-xr-xr-x 78 root root 0 Oct 18 11:08 proc
drwx------ 1 root root 0 Mar 15 2010 root
drwxr-xr-x 1 root root 588 Mar 15 2010 sbin
drwxr-xr-x 1 root root 16 Mar 15 2010 share
drwxr-xr-x 11 root root 0 Oct 18 11:08 sys
lrwxrwxrwx 1 root root 7 Mar 15 2010 tmp -> var/tmp/
drwxr-xr-x 1 root root 120 Mar 15 2010 usr
drwxr-xr-x 10 root root 200 Oct 18 11:08 var
226 Transfer complete.
ftp>

LOL, I got into the root directory of the device filesystem over the factory ftp server just using the root account. And yes, everything is writable.
Next stop, start looking at the filesystem with some more visual tool (I prefer mc :). It looks like an industry standard embedded linux, with busybox and such. And voilà! There IS a /usr/sbin/telnetd symlink, which points to the busybox binary. Now I just had to start it.
Looking at /etc/init.d/ there is a start script called http - the boa web server, which is mandatory starting with the device. Adding one line (/usr/sbin/telnetd)" into the start section does the trick.
After a reset of the device i just do a telnet and do the victory dance.

root@sysresccd /root % telnet 192.168.0.90
Trying 192.168.0.90...
Connected to 192.168.0.90.
Escape character is '^]'.


4.49
Linux 2.6.27 on a cris (12:37:54)
axis-00408c957432 login: root
Password:
[root@axis-00408c957432 /]659#

Remember the hacker movies of the 90's? I'm in :)
Some more goodies:

[root@axis-00408c957432 /]659# uname -a
Linux axis-00408c957432 2.6.27 #1 Mon Mar 15 11:24:43 CET 2010 cris unknown
[root@axis-00408c957432 /]659# dmesg
Linux version 2.6.27 (bogw@eater-1) (gcc version 3.2.1 Axis release R64/1.64) #1 Mon Mar 15 11:24:43 CET 2010

And of course:

[root@axis-00408c957432 /]659# ps
PID Uid VmSize Stat Command
1 root 232 S init
2 root SW< [kthreadd]
3 root SW< [ksoftirqd/0]
4 root SW< [events/0]
5 root SW< [khelper]
20 root SW< [kblockd/0]
37 root SW [pdflush]
38 root SW [pdflush]
39 root SW< [kswapd0]
40 root SW< [aio/0]
78 root SW< [mtdblockd]
103 root SWN [jffs2_gcd_mtd2]
166 root 440 S /bin/sh
171 root 248 S /sbin/respawnd
175 root 264 S /bin/log_combiner -o40000
184 root 304 S /usr/sbin/syslogd -m 0 -o 40000
188 root 264 S /usr/sbin/klogd -x
194 root 248 S /sbin/ipchanged -e /etc/ipchanged.script
279 root 272 S /sbin/zeroconf-ip -i eth0
290 root 256 S /usr/bin/bw --directory /var/cache/bw --text-file bw
314 root 312 S /bin/time_handler
321 root 336 S /bin/vftpd -r -q 0 -Q 0
326 root 240 S /bin/client_counter -d
332 root 608 S /bin/parhand /dev/null 50011 -d /usr/etc/param -d /et
347 root 304 S /bin/axisns add -w -d
360 root 520 S /bin/infod
363 root 520 S /bin/infod
364 root 520 S /bin/infod
372 root 520 S /bin/infod
374 root 520 S /bin/infod
376 root 336 S /bin/vcd
390 root 656 S N /bin/image_viewer -q 0 -N 10
392 root 656 S N /bin/image_viewer -q 0 -N 10
393 root 656 S N /bin/image_viewer -q 0 -N 10
395 root 656 S N /bin/image_viewer -q 0 -N 10
397 root 656 S N /bin/image_viewer -q 0 -N 10
398 root 656 S N /bin/image_viewer -q 0 -N 10
400 root 656 S N /bin/image_viewer -q 0 -N 10
401 root 656 S N /bin/image_viewer -q 0 -N 10
402 root 656 S N /bin/image_viewer -q 0 -N 10
403 root 656 S N /bin/image_viewer -q 0 -N 10
404 root 656 S N /bin/image_viewer -q 0 -N 10
405 root 656 S N /bin/image_viewer -q 0 -N 10
407 root 656 S N /bin/image_viewer -q 0 -N 10
409 root 656 S N /bin/image_viewer -q 0 -N 10
411 root 656 S N /bin/image_viewer -q 0 -N 10
414 root 656 S N /bin/image_viewer -q 0 -N 10
415 root 656 S N /bin/image_viewer -q 0 -N 10
418 root 656 S N /bin/image_viewer -q 0 -N 10
421 root 656 S N /bin/image_viewer -q 0 -N 10
423 root 656 S N /bin/image_viewer -q 0 -N 10
426 root 656 S N /bin/image_viewer -q 0 -N 10
429 root 656 S N /bin/image_viewer -q 0 -N 10
432 root 656 S N /bin/image_viewer -q 0 -N 10
440 root 392 S /bin/recorder --backend /lib/recorder/artpec2-jpg.so
441 root 184 S /bin/recorder_cache_manager
463 root 552 S < /bin/media_server -R --nice -1 -r 3
497 root 280 S /bin/utask -f /etc/task.list -f /etc/user.task.list -
513 root 232 S /bin/mld /var/log/crit_mld_pipe -w /var/log/warning_m
531 root 752 S /usr/bin/motion -c /etc/emotiond.conf
541 root 368 S /bin/iod
547 root 560 S /bin/ssid
553 root 256 S /bin/ird /dev/cam0
559 root 600 S /usr/bin/tampering -c /etc/tampering.conf
571 root 272 S /bin/lang_handler
577 root 416 S /usr/sbin/telnetd
579 root 760 S /bin/boa -c /etc/httpd/conf
585 root 264 S /bin/sersrvd -d
605 root 280 S /usr/sbin/debugar.cgi
659 root 448 S -sh
668 root 376 R ps

On terms of security (as this is a security product)... we shall not speak again about the possibility of logging in as root.

vCenter appliance 5.0u1 - certificate replacement - OpenSSL

This is just another piece of my OpenSSL headshot. I won't format it better, if you need this you can use it.
Been using this unsatisfactory kb, this forum post for reference.
This blog spot contains some of the information you can find here. Some differences though (he forgets to mention that the password for /usr/lib/vmware-vsphere-client/server/config/keystore is changeit for example)

vcVA stores it's certificates @ many different places:

• /opt/vmware/etc/lighttpd/server.pem - The vami management interface's (port 5480) https certificate
• /etc/vmware-vpx/ssl/ - VPX service's certificate (also TomCat), keys are stored here for SQL communication
• /usr/lib/vmware-vpx/inventoryservice/ssl/ - Inventory service's certificate
• /usr/lib/vmware-vsphere-client/server/config/keystore - Web Client's certificate
• /etc/ssl/certs/ - Root CA PEMs, if needed

You can generate the required (unencrypted) rui.key & rui.crt from the previous article. Rui.pfx is regenerated by the appliance, so not really needed to care for.

It is slightly easier, if you haven't yet initialized the DB - the DB connection is using the rui.crt from vpxd, if it is already initialized it has to be changed in sms.keystore & sms.truststore :( .
That must be something secret, as nobody ever published any howto on it. I should have, but I'm just too lazy...

So, for the fresh install:

1. # cp rui.* /usr/lib/vmware-vpx/inventoryservice/ssl/ - Inv. service's cert has to be replaced manually
2. # vpxd_servicecfg eula accept - Or accept it on GUI, if you haven't
3. Configure the database, for example the embedded can be initialised using:
   # vpxd_servicecfg db write embedded
4. Change the certs for vpxd and vami:
   # vpxd_servicecfg certificate change rui.crt rui.key - This also changes the management GUI cert (concatenates the .key and .crt files into server.pem)
5. Change the cert for Web Client:
   # cd  /usr/lib/vmware-vsphere-client/server/config/
   # mv keystore keystore.orig
   # /usr/lib/vmware-vpx/jre/bin/keytool -keystore keystore -importcert -file rui.crt -alias s2dmk -storetype JKS -storepass changeit - changeit is the default password for the keystore. Don't change it ;)
   # /usr/lib/vmware-vsphere-client/scripts/admin-cmd.sh unregister https://localhost:9443/vsphere-client localhost root vmware - vmware is the assumed root password.
   # /usr/lib/vmware-vsphere-client/scripts/admin-cmd.sh unregister https://FQDN:9443/vsphere-client localhost root vmware - Press A to Accept the certificate. Set FQDN, localhost might not work.
6. (Re)Start the whole thing
   # /etc/init.d/vami-lighttp restart
   # /etc/init.d/vmware-vpxd start
   # /etc/init.d/vsphere-client restart
   Or just reboot.

You can check for any errors in /var/log/vmware/vpx/.
That's all, hope you don't mind...

Get some Jeos!

JeOS is the abbreviation (pronounced "juice") for Just Enough Operating System as it applies to a software appliance (source: Wikipedia).

Jeos is an idea implemented by VMware to create even more compact purpose driven VMs. Although didn't got too mainstream, JeOS is available with VMware Studio since the 2.5 release.
See this VMware blog entry about the idea, or here you can find the not-so-complete documentation...
With this feature, you can create a RedHat or Centos based VM (either 32 or 64 bit) with an unbelievable size of 15 megs!
Okay, so we have space and memory in our servers, why should we create micro-sized VMs? Because wastefulness should be considered a sin in Cloud environments. And you may run hundreds of these if needed in the place of one bloatware VM - the VM that has every single package of it's OS in it, although it's only using Apache for example. Think about a grid computing example with on demand node provisioning...


Jeos is still experimental in Studio, and I'll be honest, I don't think it will develop too rapidly. It's just too complex to use for some peeps - most people won't bother to use it. Basically, after the build you got a stripped down Linux without most of it's daemons. This means you are on your own - you have to hunt down library dependencies one by one for your program, using strace or something. I really loved it all the time, it reminded me on developing embedded systems again...


A few helpful hints for Jeos in Studio 2.6:

• DHCP is enabled by default in every JeOS VM. While I see the point in this, I consider it sometimes a bit unnecessary. To disable it (stop auto-starting it with the VM), you have to manually edit the file /opt/vmware/etc/jeos/default/initrd.xml and comment out line 102 on the Studio VM. Then the line shall look like # /bin/busybox udhcpc -b -s /etc/udhcp/node -i $iface - the # in the front makes it go away :) After this, building a JeOS VM won't imply using DHCP.
• Also, the DHCP client service is bugged - it's name resolution won't work as expected. It has a typo in it's init script. Edit /opt/vmware/etc/jeos/busybox/node file to fix it. Line 68 should look like if [ -n "$RESOLV_CONF" ] instead of RESOLVE.CONF. See this forum post at communities.vmware.com.
• /etc/inittab is generated when the "mkjeosvm" program is run at build time. If you want a custom inittab in your JeOS VM, you will have to edit Studio's /opt/vmware/etc/jeos/default/rootfs.xml. The inittab definition should start at about line 35.
• mkjeosvm is a python script in /opt/vmware/bin. You can still hack it, if you want a different GRUB timeout for example. It's value is at #652.
• Always make a backup before playing around with these files. It can hurt your building process or the built VM may have errors in it.

As always, no warranty, etc. Have fun!

3D in Linux Workstation

The VMware Workstation on Linux does support 3D, however certain distributions (including Slack 13.37) does not ship with the S3 - now who remembers that company? - Texture Compression libraries, because of some licensing issues (see http://dri.freedesktop.org/wiki/S3TC). This occurs as an error message when running the VM "3D graphics acceleration will be disabled. This computer does not have a 3D graphics system supported by VMware Workstation.". In the VM's vmware.log file, in the same directory as the .vmx You should find some lines like "mks| VMGL: Extension missing, GL_EXT_texture_compression_s3tc", and "mks| GLManager: Required extension GL_EXT_texture_compression_s3tc is missing." and "mks| msg.glBackend.initFailed] 3D graphics acceleration will be disabled. This computer does not have a 3D graphics  system supported by VMware Workstation.". This means exactly as stated, You miss a .so file from You /usr/lib or /usr/lib64 respectively. You should just simply download the libtxc from the site above (direct link is http://cgit.freedesktop.org/~mareko/libtxc_dxtn/snapshot/libtxc_dxtn-1.0.1.zip), compile and place the .so in Your libs dir. That's all, next run, Windows 7 should enable Aero effects in Workstation on Linux!

The Linux PCoIP client from HP

There was some hassle about VMware's support for View client on Linux.
The official way to access View from linux is using view open client from http://code.google.com/p/vmware-view-open-client/. Now, this client does NOT support PCoIP, which is a major drawback.
You can access View using PCoIP from your Windows, iPad, or Teradici based device (I prefer Samsung's NC series, but the Wyse P20, the Dell FX100 etc are all the same. A complete list of devices using Teradici's HW is available here).
Android or iOS on the phone are not supported (yet). There is the Wyse PocketCloud, which is a great thing, but for RDP only.
So HP developed it's own version of View client for Linux, the code is probably heavily based on the open client (it uses the same interface, same config files/options...).
This software is for HP's thin clients with a kind of debian based firmware, but luckily it is a simple i386 .deb package.
One can easily download it from HP's site, and use it for his own dark purposes, as stated in this forum thread.
Currently, there is a View 4.5 based client in it, which works as charm with 4.6.
To download the archive, go to HP t5545 Thin Client support (search for the device on HP.com, then choose support), and download the link HP ThinPro Add-On (VMware View Broker) / 4.5.0-293049-1 Rev. A - 12 nov. 2010 - 5.2 Megs. The file is called sp50874.exe. Okay, for lazy people, it is here :) ftp://ftp.hp.com/pub/softpaq/sp50501-51000/sp50874.exe. It will extract a few files to C:\Program Files\Hewlett-Packard\HP ThinPro\3.2\Add-On\View45 by default. We will only need vmware-view-client_4.5.0-293049-1_i386.deb.
If you don't have dpkg (slackware ftw), then simply rename the .deb to whatever.ar, and ar x it. Then in the data.tar.gz you will find the required directory structure.
For 64biters: this will require 32 bit versions of libxml2.so.2 and libpixman-1.so.0, in /usr/lib.
To use USB redirection, there is postinst script in control.tar.gz, that will do the trick.