Tuesday, 30 April 2013

How IE8 catagorises Top Level Domains

Found an interesting issue between IE7 and IE8 (and above) to do with how IE categorises Top Level Domains (TLD).

Why does this list matter? Because it controls what domains you can use with wildcards in site to zone assignments within group policy.

If your domain is on the list - You can't use it with a wildcard.

You can see what the list is by using the following URL in IE8 or IE9:
res://urlmon.dll/ietldlist.xml

Does anyone know what it is in IE10?

Thanks to the following article for helping us along the road of discovery:
http://blog.gerv.net/2009/11/ie_8_and_the_public_suffix_list/


Friday, 15 February 2013

Reason for un-mountability: the original volume has some extents online


I've raised a support request, but thought I'd post this here to see if anyone else has seen the same issue on ESXi 5.1,914609.

We are implementing an HP Cloud Matrix system with ESXi 5.1 as one of the supported Hypervisors. Part of the delivered solution is HP Matrix Recovery Management which allows us to failover services to a DR site that has the VMFS volume synched across two 3Par V400 SANS.

As we understand it, the HP official guide to passing changes from the primary to DR site is to export the configuration, failover the storage, and then import the conifguration at the remote site. There is another way of doing this through the use of storage snapshots (we have tested this fine with Hyper-V):


  1. Create a RW Virtual Volume copy of the RO LUN at the remote site
  2. Unexport the RO LUN from the remote VMWare hosts
  3. Export the RW LUN to the remote VMware hosts
  4. Mount this RW LUN
  5. Import the configuration
  6. Unexport the remote RW LUN
  7. Export the remote RO LUN
  8. Delete the RW LUN


This process works fine on Hyper-V using CSV disks, but has the following problem on ESXi 5.1; When the LUN is changed, it is detected as a snapshot (as expected), but the snapshot is not mountable because the VMHost thinks it is already online:

~ # esxcli storage vmfs snapshot list
51128c21-f07c4a24-4e24-00215a9b20f7
   Volume Name: Vv_prim_vmfs_cloud_repl.02
   VMFS UUID: 51128c21-f07c4a24-4e24-00215a9b20f7
   Can mount: false
   Reason for un-mountability: the original volume has some extents online
   Can resignature: true
   Reason for non-resignaturability:
   Unresolved Extent Count: 1
~ # esxcli storage vmfs snapshot mount -l "Vv_prim_vmfs_cloud_repl.02"
Unable to mount this VMFS volume due to the original volume has some extents online


The only solution we have found is to reboot ALL the VM hosts in the remote cluster. They ALL then report the following, and can mount the volume:

~ # esxcli storage vmfs snapshot list
51128c21-f07c4a24-4e24-00215a9b20f7
   Volume Name: Vv_prim_vmfs_cloud_repl.02
   VMFS UUID: 51128c21-f07c4a24-4e24-00215a9b20f7
   Can mount: true
   Reason for un-mountability:
   Can resignature: true
   Reason for non-resignaturability:
   Unresolved Extent Count: 1
~ # esxcli storage vmfs snapshot mount -l "Vv_prim_vmfs_cloud_repl.02"
~#

We have tried various vmkfstools commands to release the LUN etc, but they don't seem able to see the LUN even though we can see the device for the volume.

Is this something you have seen before?

Is there anything you can suggest?

Saturday, 24 November 2012

chown root:root boinc *

Spot the deliberate mistake!
  • cd /usr/bin
  • sudo chown root:root boinc *
Probably not a good idea to try updating boinc on your Linux Ubuntu 12.04 LTS server when you can't sleep but are so very tired. Good one to know that chown also removes all setuid and setgid bits. :(

I booted a Live CD, and from what I can see, these are the default permissions and owners in /usr/bin:


Please let me know if anything is wrong.

Tuesday, 9 October 2012