The Lazy Sys Admin » Jon Smith

Fixed: Location Based Reminders Not Available in iOS 5

Jon Smith — Sun, 09 Oct 2011 21:36:26 +0000

If you are having troubles finding location based reminders on your iOS 5 device you are probably using an Exchange based email account. If you have an Exchange account setup on your iPhone or iPad the new reminders app in iOS 5 will be using your Exchange Tasks List. It seems that the Exchange Tasks don’t support the metadata required to have a location based reminder.

To fix this issue you need to add a new Reminder List to your device. This can be easily done by tapping the Edit List button on the main reminders screen (this button has three horizontal lines on it).

Click Edit in the top right corner.

Under the On My iPhone section in the list, tap on Create New List…

Give it a name.

Click Done, and then Done again.

If you swipe sideways you will notice you have a new Reminder List called whatever you named it above. If you now add a reminder in your new list, then go into that reminder and tap “Show More…” you will now have to option to tap on Remind Me, At a Location.

Commvault Simpana 9.0 with Granular File Recovery for Linux under VMWare

Jon Smith — Thu, 07 Jul 2011 05:28:27 +0000

I am currently going through the process of installing a brand new Commvault installation. One thing I am evaluating is doing most of my backups via the Virtual Server iDataAgent, this will give me “bare metal” recovery of my VM’s as well as cover my individual file restore requirements. As at Simpana 8 granular file level recovery was only supported for NTFS volumes but with the release of Simpana 9 the documentation has been updated to remove the NTFS requirement. Also a nice little line that also says “Granular file-level recoveries are now supported for Linux-based VMware virtual machines.” under the new features in the documentation for Simpana 9.

So testing begins, and you would imagine given the above information that file-level recoveries for Linux would just work. Problem is it just doesn’t work out of the box, after hours of playing with settings and tick boxes and reading forum posts I finally found the solution I needed to get file-level recovery working.

Ok, so to get Linux backup working you need to add a registry entry on the Virtual Server iDataAgent proxy server (the documentation for which can be found here).

HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance001\VirtualServer

Then add the following DWORD value

LinuxMetadataSupport    REG_DWORD    0x00000001

Restart the Commvault agent on the VMWare server for good measure and now take your backup.

As for file system support it seems very limited. I have tested the following setups:

Ubuntu Host
sda1 /boot ext3
sda3 / reiserfs
sda4 /data ext4

Centos Host
LVM2 with partition formatted in ext3

The only file systems that backed up were the EXT3 file systems, LVM appears to be supported as well. One can only assume that EXT2 would be supported, but I haven’t tested this.

Overall this solution can only get better, as more file systems are supported and the option to backup the linux systems on a file level are brought into the GUI it can only get easier from here. Personally I plan on moving forward using the Virtual Server iDataAgent to backup all my VM’s that don’t have special applications on them (ie, database, AD, and Exchange).

Targeting User Group Policy Settings to a Specific Machine

Jon Smith — Wed, 02 Mar 2011 01:14:29 +0000

Have you ever tried to set User Group Policies that you only want to work on a single machine or a set of machines? You will find that if you apply the group policy to a specific OU/Group of computers then unless the user accounts are in the same OU you will find that the User policies don’t get applied.

What you need is Loopback processing (See here for more details http://support.microsoft.com/kb/231287). Loopback processing is most often needed for kiosk type machine or common use computer lab scenarios.

Open up the Group Policy Object and navigate to “Computer Configuration -> Policies -> Administrative Templates -> System -> Group Policy“.

Open the “User Group Policy loopback processing mode” policy and set it to “Enabled“.

The next option is the “Mode” to use. Set the mode to “Replace” if you want no other User Policies to be in effect on the particular machines you are targeting, or “Merge” if you want all other User Policy settings to apply as well as the settings specified in the loopback policy.

I have been around Group Policy for a while and have never needed this setting before (the need for user targeted policies to a set of machines has never come up), so going through all the motions of setting policy security restrictions and changing the OU location of both the policy, the machines and the users in testing chewed up well over an hour of fiddling time. Setting a policy for loopback processing is easy, the hard part is realising that loopback processing is what you need to do in the first place.

FOG: Deleting all current active tasks

Jon Smith — Thu, 20 Jan 2011 22:12:00 +0000

FOG is “a free computer cloning solution” found at http://www.fogproject.org/. If your a seasoned user you will no doubt have groups setup so you may run commands on multiple machine without loading each one individually. In my scenario we have 1000 machines that need to be imaged, easy, I just created a group with those particular machines (luckily most computers will have a common part of their MAC address so I could search for machines based on manufacturer). Once the group was created I then setup a task for that group to deploy an image.

OK, whoops, this is when you realise that the machines has the wrong image id assigned to them. Easy you think, you created the task as a group you can just as easily delete the active task as a group. No such luck here, what FOG will do to a group of computers is simply setup an individual task for each and every machine in the group. So your only option now is to click delete on each active task, now multiply this out to 1000 machines you have an annoying problem.

There is a simple solution, although a word of warning here “PLEASE MAKE SURE YOU HAVE A BACKUP”. All the tasks are contained within the “tasks” table within MySQL. So if you feel comfortable crack open a console connection and open up a console to MySQL.

root@fog:/# mysql -u root
Welcome to the MySQL monitor.  Commands end with ; or g.
Server version: 5.0.67-0ubuntu6.1 (Ubuntu)

Type 'help;' or 'h' for help. Type 'c' to clear the buffer.

mysql> use fog;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> delete from tasks where taskState = 0;
Query OK, 8 rows affected (0.23 sec)

mysql>

This will delete all the active tasks running on the fog server. However the command files will still exist in the TFTPROOT folder. Exit out from MySQL and change directory into your TFTPROOT folder. Once inside change into the pxelinux.cfg folder.

You will notice several files in this directory, these are the files that control what a machine will do once it is PXE booted. To delete the command files you ONLY have to delete the files starting with “01-”, this is import as the other files will tell the machines what to do when they don’t have any active tasks.

root@fog:/tftpboot/pxelinux.cfg# rm 01-*

This will have completely removed all the active tasks.

Updated snapadm.pl file for ZFS Snapshots

Jon Smith — Mon, 07 Jun 2010 22:24:09 +0000

In my post OpenSolaris Backup Solution with Rsync and ZFS Snapshots I provided a link to a script from Sun – snapadm.pl. I found a bug where if you were using the recursive function then the old snapshots would never be destroyed as they were incorrectly named.

I have updated the snapadm.pl file contained in my post and have also provided a download link here.

Download:

snapadm.pl

Read on for more details:

diff snapadm.pl_.txt snapadm.pl_1.txt
181c181
<               my $result = `/sbin/zfs snapshot -r $SnapFS@_$class_name_$ztimestamp`;
---
>               my $result = `/sbin/zfs snapshot -r $SnapFS@$class_name_$ztimestamp`;

The snapshot being taken for the recursive option was incorrectly adding an _ (underscore) to the classname. This meant that when the isExpired method performs a regex search on the snapshot name then no match returns and therefore no snapshot gets destroyed.

OpenSolaris Backup Solution with Rsync and ZFS Snapshots

Jon Smith — Wed, 02 Jun 2010 10:37:32 +0000

I have recently been forced to learn how to admin an OpenSolaris machine with ZFS filesystems. After doing some reading on ZFS, I realised how using snapshots with an rsync server would make an excellent backup solution.

Using several scripts to control rsync and the snapshots has allowed me to setup a system that has data retention periods applied and only uses the space on disk required to keep the changed files. Cloning a ZFS snapshot from a week ago (or even six months ago) allows you to create a synthetic full backup from the point in time the backup was taken.

To create my backup solution I had a spare Sun Thor x4540 storage system (the next model in line released after the Thumper storage systems). This system has 48 * 500gb SATA harddrives (with a fairly conservative disk setup gives about 16TB of usable disk space), the following solution could easily be implemented with any system that will support OpenSolaris as well as have enough disk space to fullfil the requirements.

I have created a Backup ZFS pool using all of the Thor’s 48 disks. This pools root ZFS system is mounted at /backup on the filesystem. Within this ZFS filesystem I created another filesystem /backup/rsync this will be where we will create all of the individual filesystems as our backup targets. You can do this with any pool, the important fact is having a ZFS filesystem called rsync (or whatever you wish really) and have ZFS filesystems under this point for each backup target.

root@backup-01:/# zpool list
NAME     SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
backup  19.0T  6.81T  12.2T    35%  ONLINE  -
rpool   14.9G  5.49G  9.38G    36%  ONLINE  -
root@backup-01:/#
root@backup-01:/#
root@backup-01:/#
root@backup-01:/# zfs list
NAME                                 USED  AVAIL  REFER  MOUNTPOINT
backup                              5.65T  9.90T  36.5K  /backup
backup/rsync                        3.29T  9.90T  53.1K  /backup/rsync
backup/rsync/dvc                    2.23T  9.90T  1.97T  /backup/rsync/dvc
backup/rsync/library                3.04G  9.90T   392M  /backup/rsync/library
backup/rsync/grp-core-cifs           451G  9.90T   436G  /backup/rsync/grp-core-cifs
backup/rsync/grp-web-frontend       7.56G  9.90T  7.50G  /backup/rsync/grp-web-frontend
backup/rsync/grp-web-mysql           632M  9.90T   254M  /backup/rsync/grp-web-mysql
rpool                               9.83G  4.82G  81.5K  /rpool
rpool/ROOT                          3.06G  4.82G    19K  legacy
rpool/ROOT/opensolaris              8.79M  4.82G  2.87G  /
rpool/ROOT/opensolaris-20100520-01  3.05G  4.82G  2.89G  /
rpool/dump                          2.22G  4.82G  2.22G  -
rpool/export                         122M  4.82G    21K  /export
rpool/export/home                    122M  4.82G    21K  /export/home
rpool/export/home/smithj             122M  4.82G   122M  /export/home/smithj
rpool/swap                          4.43G  9.15G   101M  -
root@backup-01:/#

Next step is creating the rsyncd.conf file for rsync and import the manifest for running the rsync service under OpenSolaris.

The rsyncd.conf file needs to be placed in /etc for rsync to automatically pickup the settings. You may use the following as a sample for your own rsyncd.conf

read only = yes
list = yes
uid = root
gid = root

[host-one]
path = /backup/rsync/host-one
read only = no
hosts allow = <>
hosts deny = *

[host-two]
path = /backup/rsync/host-two
read only = no
hosts allow = <>
hosts deny = *

I found the original manifest for rsync at http://hub.opensolaris.org/bin/view/Community+Group+smf/manifests, then made minor modifications to work out of the box. Download the modified rsync.xml file from the end of this article and put it in the /var/svc/manifests/network folder on your OpenSolaris server. Once you have done this you need to run a service import.

root@backup-01:/# svccfg import /var/svc/manifest/network/rsync.xml
root@backup-01:/# svcadm enable svc:/network/rsync:default

Then run the following to ensure there are no issues with the service

root@backup-01:/# svcs -x

When you want to add a new target for a host to backup remember to create a ZFS filesystem for that host and also add an entry into the rsyncd.conf file. Once you have updated your rsyncd.conf file you need to restart the service

root@backup-01:/# svcadm restart svc:/network/rsync:default

You can now rsync anything to your backup targets, a basic backup script for linux could be as simple as

rsync -a -v -v --progress --stats --delete --exclude "/proc" --exclude "/dev" --exclude "/sys" / backup-01::host-one

The final step is to implement a rotation/retention scheme using ZFS snapshots. The original download of snapadm.pl script came from Sun. I found a bug in this version of the script, the fixed version can be downloaded from the bottom of this article. Copy the snapadm.pl file to /usr/sbin and make the file executable.

The retention policy I have put into place is keep:

14 Daily Backups
4 Weekly Backups
6 Monthly Backups

To do this add the following to your root crontab

# Daily Backup - Keep 14 Days
0 12 * * * /usr/sbin/snapadm.pl -ret=14:0:0 -filesystem=backup/rsync -rec -cl=daily

# Weekly Backup - Keep 4 Weeks
0 13 * * 0 /usr/sbin/snapadm.pl -ret=28:0:0 -filesystem=backup/rsync -rec -cl=weekly

# Monthly Backup - Keep 6 Months
0 14 1 * * /usr/sbin/snapadm.pl -ret=182:0:0 -filesystem=backup/rsync -rec -cl=monthly

Each line contains a different backup type. Daily with a retention of 14 days. Weekly each Sunday with a retention of 28 days (4 weeks). Monthly on the first of the month with a retention of 182 days (half a year).

The Options for snapadm.pl used for the script

-ret=Days:Hours:Minutes
-filesystem=ZFS File System Path
-rec – Recursively snapshot down the tree
-cl – Class, just a way to label the backup type

The end result is the following list of snapshots

root@backup-01:~# zfs list -t snapshot
NAME                                                        USED  AVAIL  REFER  MOUNTPOINT
backup/rsync@daily_Thu_20100520_1445                      26.6K      -  33.2K  -
backup/rsync@daily_Fri_20100521_1200                          0      -  41.5K  -
backup/rsync@daily_Sat_20100522_1200                          0      -  41.5K  -
backup/rsync@daily_Sun_20100523_1200                          0      -  41.5K  -
backup/rsync@weekly_Sun_20100523_1300                         0      -  41.5K  -
backup/rsync@daily_Mon_20100524_1200                      28.2K      -  46.5K  -
backup/rsync@daily_Tue_20100525_1200                      26.6K      -  48.1K  -
backup/rsync@daily_Wed_20100526_1200                      26.6K      -  48.1K  -
backup/rsync@daily_Thu_20100527_1200                          0      -  48.1K  -
backup/rsync@daily_Fri_20100528_1200                          0      -  48.1K  -
backup/rsync@daily_Sat_20100529_1200                          0      -  53.1K  -
backup/rsync@daily_Sun_20100530_1200                          0      -  53.1K  -
backup/rsync@weekly_Sun_20100530_1300                         0      -  53.1K  -
backup/rsync@daily_Mon_20100531_1200                          0      -  53.1K  -
backup/rsync@daily_Tue_20100601_1200                          0      -  53.1K  -
backup/rsync@monthly_Tue_20100601_1400                        0      -  53.1K  -
backup/rsync@daily_Wed_20100602_1200                          0      -  53.1K  -
backup/rsync/dvc@daily_Tue_20100525_1200                   287K      -  2.06T  -
backup/rsync/dvc@daily_Wed_20100526_1200                  5.75G      -  2.07T  -
backup/rsync/dvc@daily_Thu_20100527_1200                  26.5G      -  2.02T  -
backup/rsync/dvc@daily_Fri_20100528_1200                  17.2G      -  2.00T  -
backup/rsync/dvc@daily_Sat_20100529_1200                  3.72M      -  1.97T  -
backup/rsync/dvc@daily_Sun_20100530_1200                      0      -  2.00T  -
backup/rsync/dvc@weekly_Sun_20100530_1300                     0      -  2.00T  -
backup/rsync/dvc@daily_Mon_20100531_1200                  27.3G      -  2.03T  -
backup/rsync/dvc@daily_Tue_20100601_1200                      0      -  1.97T  -
backup/rsync/dvc@monthly_Tue_20100601_1400                    0      -  1.97T  -
backup/rsync/dvc@daily_Wed_20100602_1200                   184K      -  1.96T  -
backup/rsync/library@daily_Fri_20100521_1200                  0      -  31.5K  -
backup/rsync/library@daily_Sat_20100522_1200                  0      -  31.5K  -
backup/rsync/library@daily_Sun_20100523_1200                  0      -  31.5K  -
backup/rsync/library@weekly_Sun_20100523_1300                 0      -  31.5K  -
backup/rsync/library@daily_Mon_20100524_1200              24.9K      -  31.5K  -
backup/rsync/library@daily_Tue_20100525_1200               390M      -   390M  -
backup/rsync/library@daily_Wed_20100526_1200               389M      -   389M  -
backup/rsync/library@daily_Thu_20100527_1200               384M      -   384M  -
backup/rsync/library@daily_Fri_20100528_1200               388M      -   388M  -
backup/rsync/library@daily_Sat_20100529_1200               388M      -   388M  -
backup/rsync/library@daily_Sun_20100530_1200                  0      -   389M  -
backup/rsync/library@weekly_Sun_20100530_1300                 0      -   389M  -
backup/rsync/library@daily_Mon_20100531_1200               391M      -   391M  -
backup/rsync/library@daily_Tue_20100601_1200                  0      -   392M  -
backup/rsync/library@monthly_Tue_20100601_1400                0      -   392M  -
backup/rsync/library@daily_Wed_20100602_1200              24.9K      -   391M  -
backup/rsync/grp-core-cifs@daily_Fri_20100521_1200        13.7M      -   301G  -
backup/rsync/grp-core-cifs@daily_Sat_20100522_1200         278M      -   435G  -
backup/rsync/grp-core-cifs@daily_Sun_20100523_1200            0      -   436G  -
backup/rsync/grp-core-cifs@weekly_Sun_20100523_1300           0      -   436G  -
backup/rsync/grp-core-cifs@daily_Mon_20100524_1200         373M      -   435G  -
backup/rsync/grp-core-cifs@daily_Tue_20100525_1200         501M      -   434G  -
backup/rsync/grp-core-cifs@daily_Wed_20100526_1200         486M      -   434G  -
backup/rsync/grp-core-cifs@daily_Thu_20100527_1200         492M      -   434G  -
backup/rsync/grp-core-cifs@daily_Fri_20100528_1200         439M      -   436G  -
backup/rsync/grp-core-cifs@daily_Sat_20100529_1200         500M      -   436G  -
backup/rsync/grp-core-cifs@daily_Sun_20100530_1200            0      -   436G  -
backup/rsync/grp-core-cifs@weekly_Sun_20100530_1300           0      -   436G  -
backup/rsync/grp-core-cifs@daily_Mon_20100531_1200         381M      -   436G  -
backup/rsync/grp-core-cifs@daily_Tue_20100601_1200            0      -   436G  -
backup/rsync/grp-core-cifs@monthly_Tue_20100601_1400          0      -   436G  -
backup/rsync/grp-core-cifs@daily_Wed_20100602_1200        38.1M      -   437G  -
backup/rsync/grp-web-frontend@daily_Fri_20100521_1200     4.57M      -  7.49G  -
backup/rsync/grp-web-frontend@daily_Sat_20100522_1200     4.95M      -  7.49G  -
backup/rsync/grp-web-frontend@daily_Sun_20100523_1200         0      -  7.49G  -
backup/rsync/grp-web-frontend@weekly_Sun_20100523_1300        0      -  7.49G  -
backup/rsync/grp-web-frontend@daily_Mon_20100524_1200     5.44M      -  7.49G  -
backup/rsync/grp-web-frontend@daily_Tue_20100525_1200     5.59M      -  7.49G  -
backup/rsync/grp-web-frontend@daily_Wed_20100526_1200     5.45M      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Thu_20100527_1200     5.43M      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Fri_20100528_1200     5.57M      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Sat_20100529_1200     5.56M      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Sun_20100530_1200         0      -  7.50G  -
backup/rsync/grp-web-frontend@weekly_Sun_20100530_1300        0      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Mon_20100531_1200     5.56M      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Tue_20100601_1200         0      -  7.50G  -
backup/rsync/grp-web-frontend@monthly_Tue_20100601_1400       0      -  7.50G  -
backup/rsync/grp-web-frontend@daily_Wed_20100602_1200      179K      -  7.50G  -
backup/rsync/grp-web-mysql@daily_Thu_20100520_1445        35.7M      -   257M  -
backup/rsync/grp-web-mysql@daily_Fri_20100521_1200        29.4M      -   251M  -
backup/rsync/grp-web-mysql@daily_Sat_20100522_1200        29.6M      -   251M  -
backup/rsync/grp-web-mysql@daily_Sun_20100523_1200            0      -   251M  -
backup/rsync/grp-web-mysql@weekly_Sun_20100523_1300           0      -   251M  -
backup/rsync/grp-web-mysql@daily_Mon_20100524_1200        29.8M      -   251M  -
backup/rsync/grp-web-mysql@daily_Tue_20100525_1200        30.1M      -   251M  -
backup/rsync/grp-web-mysql@daily_Wed_20100526_1200        30.4M      -   252M  -
backup/rsync/grp-web-mysql@daily_Thu_20100527_1200        30.6M      -   252M  -
backup/rsync/grp-web-mysql@daily_Fri_20100528_1200        32.9M      -   254M  -
backup/rsync/grp-web-mysql@daily_Sat_20100529_1200        33.1M      -   254M  -
backup/rsync/grp-web-mysql@daily_Sun_20100530_1200            0      -   254M  -
backup/rsync/grp-web-mysql@weekly_Sun_20100530_1300           0      -   254M  -
backup/rsync/grp-web-mysql@daily_Mon_20100531_1200        33.3M      -   254M  -
backup/rsync/grp-web-mysql@daily_Tue_20100601_1200            0      -   254M  -
backup/rsync/grp-web-mysql@monthly_Tue_20100601_1400          0      -   254M  -
backup/rsync/grp-web-mysql@daily_Wed_20100602_1200        79.7K      -   254M  -
rpool/ROOT/opensolaris-20100520-01@install                  148M      -  2.82G  -
rpool/ROOT/opensolaris-20100520-01@2010-05-19-21:49:46     13.8M      -  2.87G  -
root@backup-01:~#

To do a file restore you need to make a ZFS Clone of the snapshot, this will allow you to copy the files required. The most important thing is that you MUST destroy the clone once you have finished the restore, failure to do so will result in the snapshot being unable to be deleted by the retention policy.

I certainly recommend reading the Solaris ZFS Administrators Guide and the ZFS Best Practices Guide. Both these guide certainly helped me understand ZFS and how to manage it.

Download:

Rsync Manifest – rsync.xml
Snapshot Admin Script – snapadm.pl

EPIC FAIL – Winner of the Hottest 100 of 2009 leaked

Jon Smith — Fri, 22 Jan 2010 03:41:41 +0000

And the winner of the Hottest 100 of 2009 is….. well you need to look at the picture if you really want to know.

I’m a little bit sad that I saw this. Australia day is always about listening all day to find out what hits number one (then being outraged when it isn’t a song you like, having said that I like this song)

BTW i take no credit for the image or finding the leak, I am just sharing it, original at http://i49.tinypic.com/ab2zrk.jpg

Exchange System Manager Tools on Windows 7 – The Easy Way

Jon Smith — Mon, 18 Jan 2010 23:27:36 +0000

Since my migration to Windows 7 there have still been a few things missing that would be nice to have. One of those is the Exchange System Manager tools. There are ways and methods out there to getting this to work but most will involve uninstalling outlook and reinstalling after you have installed ESM tools.

I have been waiting for the ESM tools for Exchange 2010 to hopefully work with Exchange 2003 but that hasn’t happened either. Although I did find a really quick and easy solution this morning after reading the following posts on TechNet (Exchange System Manager for exchange 2003)

You will need to download the Exchange System Manager for Windows Vista then use something like WinRAR to extract the contents.

You will also need to make sure you already have the RSAT tools installed (Remote Server Admin Tools)

Finally open up a Command Prompt as Administrator. Browse to the directory that contains the ESMVISTA.MSI file. Run the following:

ESMVISTA.MSI /q

Once this is done you should be able to open the “Active Directory and Computers” and edit an Exchange User with all the required email tabs.

Mythtv MPlayer Playback Issue with Ubuntu Karmic Koala

Jon Smith — Sat, 16 Jan 2010 07:08:29 +0000

I have just finished upgrading my Mythtv setup to Ubuntu 9.10 and mostly everything still works (I upgraded from 8.10). Luckily the only thing that broke was lirc and it was the old config pointing at the incorrect /dev entry. The biggest problem was when I played video from inside mythtv using mplayer the video locked up. It acted like it was paused, you could seek and the video would advance but it would never play.

After searching through forums and mailing lists I was unable to find an answer so I started looking into mplayer itself. If i used mplayer on it’s own while Mythtv was running the same problem would occur. If I exited Mythtv then mplayer functioned perfectly. I found a possible idea from the Ubuntu forums whereby someone else was having slight playback issues (no mention of Mythtv though).

The problem appears to be with the audio driver mplayer tries to use. On my system it comes up with an error about pulse (that is something to fix some other time). To fix this I told mplayer to use ALSA instead, and it worked!!

So to fix with MythTV go into the Setup -> Media Settings -> Video Settings -> Player Settings then set Default Video Player to

mplayer -fs -zoom -ontop -ao alsa %s

Alternatively you could just add

-ao alsa

before the %s.

VMWare ESX 4.0 Update 1 Supports Windows 7!

Jon Smith — Wed, 25 Nov 2009 03:25:30 +0000

Good news! VMWare have decided to finally add support for Windows 7. I would say a little too late given the general availability of the RTM for the last couple of months.

The upgrade the VMWare ESX 4.0 Update 1 ran smoothly and all hosts came back to life after the upgrade as they should. Installation of the client on Windows 7 was also painless, and best of all it actually worked.

To anyone from VMWare who may be watching, it would be nice if you had some form of announcements mailing list so we could be informed of these updates being made available.