VMware fusion

March 23, 2013 Leave a comment

DHCP configuration : /Library/Preferences/VMware Fusion/vmnet8/dhcpd.conf

restart networking : 

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli –stop

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli –start


Sample dhcp config :


###### VMNET DHCP Configuration. Start of “DO NOT MODIFY SECTION” #####
# Modification Instructions: This section of the configuration file contains
# information generated by the configuration program. Do not modify this
# section.
# You are free to modify everything else. Also, this section must start
# on a new line
# This file will get backed up with a different name in the same directory
# if this section is edited and you try to configure DHCP again.

# Written at: 03/21/2013 23:16:47
allow unknown-clients;
default-lease-time 1800; # default is 30 minutes
max-lease-time 7200; # default is 2 hours

subnet netmask {
option broadcast-address;
option domain-name-servers;
option domain-name localdomain;
default-lease-time 1800; # default is 30 minutes
max-lease-time 7200; # default is 2 hours
option netbios-name-servers;
option routers;
host vmnet8 {
hardware ethernet 00:50:56:C0:00:08;
option domain-name-servers;
option domain-name “”;
option routers;
####### VMNET DHCP Configuration. End of “DO NOT MODIFY SECTION” #######

host arbs {
hardware ethernet 00:0C:29:21:38:14; ## <– MAC addr of VM

host ubox {
hardware ethernet 00:0C:29:16:50:02;

Categories: Uncategorized

Use DNS 323 to intall Ubuntu using TFTP Boot

May 22, 2011 Leave a comment

I got this all working on my dns 323. Here’s what I did :

  1. Install ipkg following instructions from here : http://wiki.dns323.info/howto:optware
  2. Do a ipkg list.
  3. You will need two packages, xinetd and tftpd.
    # ipkg list |grep xinetd
    xinetd - 2.3.14-9 - Highly configurable, modular and secure inetd
    # ipkg list |grep tftp
    atftp - 0.7-9 - Advanced TFTP server and client
    linksys-tftp - 1.2.1-1 - TFTP Client customized for a non-standard tftp authentication process.
    tftp-hpa - 5.0-1 - A tftp package

    Install tftp-hpa and xinetd using ipkg install
  4. Create or modify /opt/etc/xinetd.d/tftp file like this :

    # ftp://ftp.kernel.org/pub/software/network/tftp/
    service tftp
    flags = REUSE
    socket_type = dgram
    protocol = udp
    instances = 30
    wait = yes
    user = root
    server = /opt/sbin/in.tftpd
    server_args = -s /mnt/HD_a2/tftpboot
    cps = 100 2
    log_on_success = HOST PID
    log_on_failure = HOST
    disable = no
  5. Start xinetd daemon
  6. Download the Ubuntu boot image from here : http://archive.ubuntu.com/ubuntu/dists/natty/main/installer-amd64/current/images/netboot/. Copy the contents to /mnt/HD_a2/tftpboot or where ever your config file points to. This will install Ubuntu Natty 64 bit on your system.
    If you want anything else, install the corresponding tftp boot image from the ubuntu server. For example, for Maverick 32 bit, this will be the location : http://archive.ubuntu.com/ubuntu/dists/maverick/main/installer-i386/current/images/netboot

    At this time, you should test your tftp server.

    From any machine with a tftp client, do this :

    tftp X.X.X.X
    tftp> get pxelinux.0
    Received 14928 bytes in 0.4 seconds

    where X.X.X.X is the IP of the tftp server. This should work. If it fails, you know you did something wrong.
  7. Modify the udhcpd config file. If the IP address of your dhcp server is X.X.X.X then, add the following lines in /etc/udhcpd.conf :

    boot_file pxelinux.0            #default: (none)
    siaddr X.X.X.X #default:
    option tftp X.X.X.X

    Then restart udhcpd process:

    #killall udhcpd
    # udhcpd

At this point you have done two things :

  • Installed and configured a tftp server that serves the boot kernel image and initializes the ubuntu setup.
  • Configured the native dhcp server in DNS 323 so that it tells the client what the name of the PXE boot kernel image name is.

Note that upon reboot, your customizations to /etc/dhcpd.conf will be lost.DNS 323 installs pristine copies of config scripts every time it reboots (see /etc/rc.sh). You can automate installation  by scripting the steps in funplug.sh.

Also note that you need to disable any other dhcp servers that you might have in the network so that when your machine boots, it only gets dhcp response from your configured server.

Categories: Uncategorized

Mount LVM based volumes from a loopback device (disk image)

December 15, 2010 Leave a comment

Recently I needed to extract some files from the root partition in a full disk backup image taken with dd. I didn’t notice when I took the disk image, but the disk only contained two primary partitions: /boot and an LVM physical volume containing the rest of the partitions as LVM logical volumes. I don’t work with LVM much manually, so I had to look up the commands to get it to find physical volumes and activate volume groups. Here’s the full process of mounting LVM logical volumes from a full disk image:

There are two ways to get to the LVM partition on this disk, and I’ll cover both: 1) the manual offset finding way and 2) the easy way.
First, the easy way: make sure the loopback module is inserted with the max_part parameter, which causes the automatic creation of loopback subdevices for individual partitions. An easy way to make sure is to remove it and re-insert with the right parameter: modprobe -r loop && modprobe loop max_part=63
Next, mount the whole disk image loopback: losetup /dev/loop0 sda.img. Now you should see /dev/loop0p1,/dev/loop0p2, etc. for all of the individual partitions. Now you’re already done — you can go directly to the next section to deal with LVM directly.
If you can’t do the easy method, mount the whole disk image loopback to look at the partition offsets: losetup /dev/loop0 sda.img
Now that /dev/loop0 looks just like the block device image, so check out the partition table sector offsets with fdisk: fdisk -u -l /dev/loop0. I use sector offsets (-u flag) rather than cylinders because they are easier to work with and some partitions may not fall on cylinder boundaries. My image shows something like this:
Disk /dev/loop0: 250 GB, 250056737280 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488392065 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/loop0p1 * 63 401624 200781 83 Linux
/dev/loop0p2 401625 488392064 243987187 8e Linux LVM
Now, remove the whole disk image from /dev/loop0: losetup -d /dev/loop0 and set /dev/loop0 to just the LVM partition by adding the partition offset. Here, the second partition starts at sector 401625, and each sector is 512 bytes, so the offset is 205632000. Run losetup /dev/loop0 sda.img -o205632000
Now whichever method you used, you have a loopback device with the LVM physical volume partition: /dev/loop0p? (2 in my case) if you used the easy way, or /dev/loop0 if you used the manual offset method. Get LVM to recognize the physical volume and activate the volume groups:

Tell LVM to scan for new physical volumes: lvm pvscan
Activate the volume groups: lvm vgchange -ay (it will print something like 2 logical volume(s) in volume group “VolGroup00” now active).
Now you can finally mount the LVM logical volumes. Run lvm lvs to list the logical volumes. Each should appear in /dev/mapper, typically with the device name (volume group name)-(logical volume name), like VolGroup00-LogVol00.
When you are done, unmount all logical volumes and deactivate the volume groups with lvm vgchange -an. Now you can reclaim the loopback device by using losetup -d /dev/loop0.

Copied from : http://www.thegibson.org/blog/archives/467

Categories: Linux/Linux kernel

Issues with building Xen from source

December 7, 2010 Leave a comment

Folks, I am back working on Xen and once again, I am bumping into issues getting xen up and running on various distros. I will enumerate some of the issues that I am facing in this blog as I go along :

  • Ubuntu python is weird. The site.py library does not import modules from /usr/lib/pythonx.y/site-packages ! Instead it imports from /usr/lib/pythonx.y/dist-packages ! Check the site.py module and you can see it yourself! The workaround is to create a symlink or install custom packages in /home/localuser/.local/lib/pythonx.y/site-packages and have site.ENABLE_USER_SITE set to True.
  • Categories: Uncategorized

    Why you should save SHSH blobs for 3GS/iPhone 4

    August 18, 2010 Leave a comment
    Image representing iPhone as depicted in Crunc...
    Image via CrunchBase

    Avid iPhone hackers know that in order to be safe, they need to store their SHSH blobs for their jailbreaked phone so that if something goes wrong, they can restore their phone. However, even if you do not plan to jailbreak your phone, you should still save your SHSH blobs. Here’s why:

    When Apple releases a new firmware for their iPhone/iPod touches, Apple encourages everyone to update their firmware to their latest and greatest release. Old firmwares have vulnerabilities that hackers and jailbreakers effectively use to customize/install non-approved applications into the device. Eventually Apple comes up with a fix and plugs the holes. When you upgrade to the latest firmware from Apple, iTunes goes through a process known as signature verification. It is similar to public key exchange. What it does is that it creates a hash value based on the ECID value of your device (more on this later) and your installed firmware. iTunes then sends a request for the SHSH blob to the iTunes server. The response from the server which has the SHSH blob itself which is then used to authenticate the firmware installation (iOS 4.0 and above has an embedded ECID blob and in other cases, they are generated locally).  iTunes can then activate your newly installed firmware. Unfortunately, there is a signing period for each new firmware. When a new firmware is released, the signing period for the old firmware is terminated within a few days of the release. What this means is that once you have upgraded your device to the new firmware,  you can no longer ‘restore’ your device to an old firmware once it’s signing period has closed. Thus, you are stuck and can no longer go back.

    You might ask why would one like to go back? One common issue I have seen people often discussing is that how their old Apple 3G iPhone became irritatingly slow once they installed iOS 4. This will always be an issue with old hardware. As operating systems are being written more and more in consideration with the capabilities of the newer hardware, installing the same OS on an old hardware will make it crawl. We all had this same experience in the PC world. Recall what happened when you installed Windows XP on a PC that once had plenty of horse power for Windows 95! In such situations, often it is best to go back and install an old (and possibly unsupported) operating system on your old hardware or, if you have money, upgrade to newer hardware. The same goes true in the mobile world too.  Therefore, as much as Apple would love you to install their shiny new release, it might be a better idea to go back and downgrade. Unfortunately, once they have closed the signature window, you have no way to go back. Jailbreakers have the same problem too – when they want to go back to an old firmware that had a known vulnerability that they could take advantage of for jailbreaking, they can’t without storing a copy of their SHSH blob against their old firmware (the one that they want to downgrade to).

    So how can you save the SHSH blob for your device. Simple. There’s a small utility known as tiny-umbrella (http://thefirmwareumbrella.blogspot.com/). You can download the utility for Mac or Windows or Linux. Download and run the utility (you might have to provide administrator’s username and password). Now connect your iPhone or iPod touch to your computer, first making sure iTunes has been installed). tiny-umbrella will detect your device and correctly decode it’s firmware revision and build, ECID:

    8/18/2010 20:08:45.187 Device Detected -
    Device: iPhone3GS 4.0.1 (8A306)
    Model: XXXX
    Name: Ani’s iPhone
    Baseband: 05.13.04XXX

    Select the server as ‘cydia’. If cydia does not have the SHSH blob, it will automatically contact Apple server and send the reply back to you (and cache it at the same time). Click  ‘save SHSH’. Now tiny-umbrella will contact cydia and get back to you with the following messages:

    08/18/2010 20:14:53.221 Processing SHSH Request...

    08/18/2010 20:14:53.241 Asking CYDIA for SHSH blobs for iPhone3GS 4.0.1(8A306)...

    08/18/2010 20:14:57.965 SHSH SUCCESSFULLY saved! [Click Here to Open]

    08/18/2010 20:14:58.004 You have saved your SHSH locally and the request was sent to CYDIA. This means that CYDIA DOES have your SHSH. Do NOT bug semaphore about the Cydia home page showing this version.

    08/18/2010 20:14:58.029 Caching shsh files...

    08/18/2010 20:14:58.070 Found [1] shsh files to cache...

    08/18/2010 20:14:58.140 Cached [1] shsh files

    08/18/2010 20:15:32.709 TSS Server has cached the following files:

    08/18/2010 20:15:32.729 iPhone3GS 4.0.1 (8A306)-

    08/18/201020:15:32.739 Devices with ECIDs matching the above AND restoring to the exact firmware version listed above will succeed!

    08/18/2010 20:15:32.752 *Please note that iPad and iPad3G share the exact same SHSH. If you see iPad above and you have an iPad3G THEY WILL WORK JUST FINE. There is just no way for me to tell the difference between iPad and iPad3G from the SHSH alone.

    Now click on the ‘click here to open’ link. It will open the file in Finder/Explorer and the file will have a .shsh extension. It’s just an xml file with the requisite blobs.

    Now the downgrading part. Once you have saved the blobs locally, you can start a local TSS server using the same tiny-umbrella tool. It starts a local server that iTunes can be made to talk to. Modify your /etc/hosts so that the domain gs.apple.com points to your localhost ( This way, when iTunes connects to gs.apple.com, it will actually connect to your local tiny-umbrella server. Now when iTunes asks for the signatures, the responses can be easily faked using the cached value of your blobs. You can then safely downgrade your firmware at a later time when you need it.

    Alternative way to find your ECID:

    Reboot your device in DFU mode and connect it to your Mac. From apple-menu->About this mac->more info navigate to Hardware-> USB section on your left. Find the entry corresponding to your USB device. It should read something like this:

    Product ID: 0x1227
    Vendor ID: 0x05ac (Apple Inc.)
    Version: 0.00
    Serial Number: CPID:8920 CPRV:15 CPFM:03 SCEP:03 BDID:00 ECID:000000XXXXXXXXXX SRTG:[iBoot-359.3.2]
    Speed: Up to 480 Mb/sec
    Manufacturer: Apple Inc.
    Location ID: 0xABCD
    Current Available (mA): 500
    Current Required (mA): 100

    As you can see, the ECID value can be found in HEX (obfuscated due to privacy here).

    Note: You can read more about SHSH blob from Wikipedia: http://en.wikipedia.org/wiki/SHSH_blob

    More info about iPhone 3G:

    According to what I have read, you can always downgrade your iPhone 3G (not 3GS) firmware from 4.x to 3.x.x without requiring to save SHSH blobs. I do not have a 3G phone, so I can’t manually test it out. In other words:

    iPhone 3G and older: downgrade from iOS 4.x.x  to 3.x.x => SHSH blobs not required (there is no embedded SHSH blobs in the 3.x firmware and the device has no ECID).

    iPhone 3G and older: downgrade from iOS 4.x.x to 4.0.0 => SHSH blobs required (from iOS 4.0 onwards, apple has included soft SHSH blobs in the firmware itself).

    iPhone 3GS and above: Downgrade from 4.x to any => SHSH blobs required (3GS and iPhone 4 has ECID that can be used for the RSA challenge).

    Categories: iPhone

    How to find out which package a file belongs to

    August 6, 2010 Leave a comment

    If you want to figure out which package a file belongs to you can use rpm to find out (On a system that uses rpm). Which package does /bin/bash belong to?

    [root@host ~]# rpm -qf /bin/bash

    So /bin/bash belongs to bash-3.0-19.3

    The -q option lets rpm know that you want to do a query of the database. The f lets you query the package containing the file you specify.

    Here’s another query:

    [root@host ~]# rpm -qf /usr/bin/xargs
    [root@host ~]#

    yum lets you get info on the findutils package:

    [root@host ~]# yum info findutils
    Setting up repositories
    update 100% |=========================| 951 B 00:00
    rpmforge 100% |=========================| 1.1 kB 00:00
    base 100% |=========================| 1.1 kB 00:00
    addons 100% |=========================| 951 B 00:00
    extras 100% |=========================| 1.1 kB 00:00
    Reading repository metadata in from local files
    Installed Packages
    Name : findutils
    Arch : i386
    Epoch : 1
    Version: 4.1.20
    Release: 7.el4.1
    Size : 231 k
    Repo : installed
    Summary: The GNU versions of find utilities (find and xargs).

    The findutils package contains programs which will help you locate
    files on your system. The find utility searches through a hierarchy
    of directories looking for files which match a certain set of criteria
    (such as a filename pattern). The xargs utility builds and executes
    command lines from standard input arguments (usually lists of file
    names generated by the find command).

    You should install findutils because it includes tools that are very
    useful for finding things on your system.

    So, if you are using a system that uses RPM/YUM, you can easily find out the packages that files on your filesystem belong to

    Categories: Linux/Linux kernel

    Enable time machine backup to network drive (DNS 323)

    July 19, 2010 6 comments

    First, enable Time Machine to use network drives:

    defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

    Follow instructions here:

    I created a “sparse bundle disk image” which I saved as chimera.sparsebundle with the following options:

    Volume Name: “Time Machine Backups”
    Filesystem: MAC OS Extended  (Case Sensitive Journaled).
    Encryption : None
    Partition : Single Partition GUID
    Initial Size: 1 GB.
    Later I resized it to my final backup disk size : 500 GB

    However, for Snow Leopard, following changes apply:

    (a) Name of the sparsebundle is <computer_name>.sparsebundle. eg.

    [anirbans@chimera:/Users/anirbans]$ hostname

    so the file name should be chimera.sparsebundle

    (b) The sparse bundle image must contain a plist file: com.apple.TimeMachine.MachineID.plist

    DO NOT mount the image to create the file. If your sparsebundle file is in /Volume /Backups then,

    #> cd /Volumes/Backups/chimera.sparsebundle
    #> vi com.apple.TimeMachine.MachineID.plist


    Right click the sparsebundle image and select “Show Package Contents”. In the finder window that opens, create the file using any text editor.

    Contents of the file should be something like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">

    Get the UUID from apple menu -> About this Mac -> More Info . In the hardware tab, see Hardware UUID on the bottom right pane.
    The Machine Address is the MAC address of “en0” interface.

    For Snow Leopard 10.6.3 and 10.6.4 (as of this writing, 10.6.4 is the latest version of Mac OS X Snow Leopard), Apple changed the way Time Machine treats the sparse bundle files for backups. It automatically resizes the file to occupy the entire space in the hard drive partition. If you do a grep over /var/log/system.log, you’d see the following lines:

    Resizing backup disk image from 476.8 GB to 1831.7 GB

    As of writing this blog, there has been numerous discussions and feature enhancement posted by various people to have an option to either limit the amount of space Time Machine can use for backups or have an option to disable Time Machine from resizing the sparse image file. No “official” resolution exists as of writing.

    See :


    You might think that you can hack around this problem by revoking write permissions on Info.plist file present inside the sparsebundle disk image:

    # chmod a-w Info.plist
    # ls -l
    -rwxrwxrwx    1 anirbans anihome       499 Jul 18 13:02 Info.bckup
    -r-xr-xr-x    1 anirbans anihome       499 Jul 18 13:02 Info.plist
    drwxrwxrwx    2 anirbans anihome      4096 Jul 18 13:03 bands
    -rwxrwxrwx    1 anirbans anihome       532 Jul 18 12:02 com.apple.TimeMachine.MachineID.plist
    -rwxrwxrwx    1 anirbans anihome         0 Jul 18 13:00 token

    However, you need to change the ownership of the file to some user other than the one Time Machine uses to log in to your NAS. Otherwise, Time Machine intelligently reinstates the write permissions for the file.

    In my case, Time Machine uses the user name anirbans to log in. Hence, I changed the ownership of the file to root and revoked write permissions for all others.

    # chown root Info.plist
    # chgrp root Info.plist
    # chmod o-w Info.plist
    # ls -l
    -rwxrwxrwx 1 anirbans anihome 499 Jul 18 13:02 Info.bckup
    -rwxrwxr-x 1 root root 499 Jul 18 13:02 Info.plist
    drwxrwxrwx 3 anirbans anihome 4096 Jul 19 18:35 bands
    -rwxrwxrwx 1 anirbans anihome 532 Jul 19 18:35 com.apple.TimeMachine.MachineID.plist
    -rwxrwxrwx 1 anirbans anihome 0 Jul 18 13:00 token

    Check the logs:

    Jul 18 20:05:26 chimera com.apple.backupd[2788]: Resizing backup disk image from 476.8 GB to 1831.7 GB
    Jul 18 20:05:45 chimera com.apple.backupd[2788]: Could not resize backup disk image (DIHLResizeImage returned 13)
    Jul 18 20:05:48 chimera com.apple.backupd[2788]: QUICKCHECK ONLY; FILESYSTEM CLEAN
    Jul 18 20:05:50 chimera com.apple.backupd[2788]: Disk image /Volumes/FileServerVolume-1/chimera.sparsebundle mounted at: /Volumes/Time Machine Backups
    Jul 18 20:05:50 chimera com.apple.backupd[2788]: Backing up to: /Volumes/Time Machine Backups/Backups.backupdb
    Jul 18 20:05:52 chimera com.apple.backupd[2788]: Backup content size: 112.4 GB excluded items size: 7.8 GB for volume My Mac Disk
    Jul 18 20:05:52 chimera com.apple.backupd[2788]: No pre-backup thinning needed: 125.43 GB requested (including padding), 476.10 GB available

    As you can see, Time Machine uses just the amount of disk space allocated for the sparse bundle.


    1. As a side note, the following does not work:
      defaults write /Library/Preferences/com.apple.TimeMachine MaxSize nnn
    2. Locking the file using something like this:
      SetFile -a L Info.plist
      might work. But somehow it did not work for me and I did not spend any time digging on it.
    3. I did enable AFP (http://en.wikipedia.org/wiki/Apple_Filing_Protocol) in my DNS323, so it backs up over AFP. Instructions on how to enable AFP is here: http://wiki.dns323.info/howto:appletalk
    Categories: Miscellaneous