Older blog entries for amits (starting at number 42)

Auto-login to web proxies using NetworkManager

My ISP uses a web proxy that one has to log into to access the Internet. This logging in is a manual, repetitive process, which is easily automatable. So I embarked on a few hour-long project to get to the proxy, supply login credentials and configure NetworkManager to auto-login via running the script each time a connection goes up.

It's not just ISPs -- hotel wifi networks, airport wifis, all use such web-based proxies that one has to login to first before the 'net becomes accessible. So the steps I followed can be easily followed by others to add support for auto-logging into such web proxies.

I'll get to the details in a bit, but I'll first point to the code (licensed under the GPL, v2). It's written in Python, a language that's relatively new for me. I've written a couple of small programs earlier, but those were just enough to remind me of the syntax; I had to frequently look up the Python docs to get a lot of the details, like interacting with http servers, cookie management, config file management and so on. My C-style writing of the Python script might be evident: it should be possible for someone with more experience in Python to shorten or optimise the script.

My ISP, Tikona Digital Networks, uses a somewhat roundabout way to bring up the login page: for any URL accessed before the proxy login, it first displays an http page that has a redirect URL and a 'Please wait while login page is loaded' message. The page to be redirected to is then loaded. This page shows another 'Please wait' message, sets a cookie and does a POST action to the real login page after a 5-second timeout. The real login page asks for the username and password. After providing that info, one has to click on the Login button, which translates to a javascript-based POST request, and if the username/password provided match the ones in their database, we're authenticated to the web proxy. The web proxy doesn't interfere with any further 'net access.

Now that I've gone through the rough overview of the approach to take, I'll detail the steps I took to get this script ready:

Step 1: Follow the redirect URL

Open a browser, type in some URL -- say 'www.google.com'. This always resulted in a page that asked me to wait while it went to the login page.

OK, so time for a short python script to check what's happening:

import urllib

f = urllib.urlopen("http://www.google.com")
s = f.read()

print s

This snippet accesses the google.com website and dumps on the screen the result of the http request.

Here's the dump that I get before the login.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<title>Please wait while the login page is loaded...</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<META HTTP-EQUIV="Refresh" CONTENT="2;URL=https://login.tikona.in/userportal/?requesturi=http%3a%2f%2fgoogle%2ecom%2f&ip=113%2e193%2e150%2e95&nas=tikonapune&requestip=google%2ecom&sc=5a54aa1fd2de7a9c2b92a865de55b943">
<p align="center">Please wait...<p>
Please wait while the login page is loaded...


This shows there's a redirect that'll happen after the timeout (the META HTTP-EQUIV="Refresh" line). The redirect is to the link shown.

Step 2: Get the redirect link

So now our task is to get the link from the http-equiv header and open that later. Using regular expressions, we can remove the text around the link and just obtain the link:

refresh_url_pattern = "HTTP-EQUIV=\"Refresh\" CONTENT=\"2;URL=(.*)\">"
refresh_url = search(refresh_url_pattern, s)

The URL to access is then available in refresh_url.group(1). group(1) contains the matched string in parentheses above in the pattern searched.

Now open the page obtained in the refresh URL:

f = urllib.urlopen(refresh_url.group(1))
s = f.read()

s now contains:

<title>Powered by Inventum</title>
function moveToLogin() {
function loadForm(){
<body onload="moveToLogin();">
Loading the login page...
Step 3: Get the base URL, open login page

So this page does an HTTP POST request. The URL of the new page being loaded is relative to the current one, so we have to extract the base URL from the previous redirect URL obtained.

base_url_pattern = "(http.*/)(\?.*)$"
base_url = search(base_url_pattern, refresh_url.group(0))

The baseurl is then available via base_url.group(1). This regular expression pattern isolates the text before the first '?', as is found in the refresh URL above.

So now we have to load the page login.do which is at address 'https://login.tikona.in' and which is to be passed the parameters '?requesturi=http%3A%2F%2Fgoogle.com%2F&act=null'. This calls for another regular expression by which we can isolate the 'login.do...' part from the 'action' part of the POST request above.

load_form_pattern = ".*action=\"(.*)\";"
load_form_id = search(load_form_pattern, s)
load_form_url = base_url.group(1) + load_form_id.group(1)

load_form_url is now the URL we need to access to get to the login page:

f = urllib.urlopen(load_form_url)
s = f.read()

This should get our login page.

But it's not. After spending some time checking and double-checking what's happening I couldn't see anything going wrong. There was just one more thing to try: cookies. I disabled cookies in firefox and tried accessing the page. Voila, no login page.

Step 4: Enable cookie handling

So we now have to enable cookies in our python script to be able to enter login information. The urllib2 and cookielib libraries do that for us, so a slight re-write of the code gets us to this:

import urllib, urllib2, cookielib, ConfigParser, os
from re import search

cj = cookielib.CookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))

f = opener.open("http://google.com")
s = f.read()

All other open calls (urllib.urlopen) are now replaced by opener.open. This way cookies are handled for the session and the login page appears after accessing the load_form_url:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Tikona Digital Networks</title>
<link rel="stylesheet" type="text/css" href="/userportal/pages/css/style.css" />
<script language="JavaScript" src="/userportal/pages/js/cookie.js"></script>
<script language="JavaScript" src="/userportal/pages/js/common.js"></script>


<form name="form1">
<div id="wrap">
<div class="background_login">
<div class="logo_header">
<div class="logoimg"><img src="/userportal/pages/images/logo.jpg" alt="Tikona Digital Networks" /></div>
<div class="sitelink"><a href="http://www.tikona.in" target="_blank">www.tikona.in</a></div>

<div class="clear"></div>
<div class="login_box">
<div id="right_curved_block">
<div class="blue_head">
<div class="blue_head_right">
<div class="blue_head_left">&nbsp;</div>
<div class="hdng">Login</div>

<div class="clear"></div>
<div class="block_content">
<div class="form">
<table height="100%" border="0" cellpadding="0" cellspacing="0">


<td width="126"><label>Service Type</label></td>
<td width="200" align="left" valign="middle">
<select name="type"><option value="1">Check Account Details</option>

<option value="2" selected="selected">Internet Access</option></select>

<td width="126"><label>User Name</label></td>
<td width="200" align="left" valign="middle"><input type="text" name="username" value="" class="logintext">

<td width="126"><label>Password</label></td>
<td width="200" align="left" valign="middle"><input type="password" name="password" value="" class="loginpassword"></td>
<td width="126"><label>Remember me</label></td>

<td width="200" align="left" valign="middle"><div style=" width:30%; float:left;"><input name="remeberme" id="rememberme" type="checkbox" class="checkbox"/></div>
<div style=" width:70%; float:right;"><a href="javascript:savesettings()"><img src="/userportal/pages/images/login.gif" alt="" width="117" height="30" hspace="0" vspace="0" border="0" align="right" /></a></div></td>
<div class="clear"> </div>
<div class="white_bottom">

<div class="tips_box">
<div class="v_box">
<div id="tips_block">
<div class="white_head_v">
<div class="blue_head_right">
<div class="white_head_left_v">&nbsp;</div>
<div class="wbs_version">&nbsp;</div>
<div class="clear"></div>
<div class="block_content">
<div class="scrol">
<h1>Importance of Billing Account Number</h1>
<br />

<font size="2">
<li>Billing Account Number (BAN) is a 9 digit unique identification number of your Tikona Wi-Bro service bill
account. It is mentioned below your name and address in the bill.</li>
<li>Bill payments done through cheque or demand draft should mandatorily have BAN mentioned on them. <br />
<span style="color:#558ed5">Example:</span> Cheque or demand draft should be drawn in the name of &lsquo;
Tikona Digital Networks Pvt. Ltd. a/c xxx xxx xxx&rsquo;. Here &lsquo;xxx xxx xxx&rsquo; denotes your BAN.
<li>If the BAN is not mentioned or incorrectly mentioned on the cheque or demand draft, the bill amount does 
not get credited against your Tikona Wi-Bro service account.</li>
<li>In case you have paid bill through cheque or demand draft without mentioning BAN on it and the amount is 
not credited to your Tikona billing account, then please contact TikonaCare at 1800 20 94276. Kindly furnish 
your cheque number, service ID, BAN and bank statement for payment verification.</li>
</font><br />
<div class="clear"> </div>
<div class="white_bottom">&nbsp;</div>

<div style="padding:110px 0 0 0; float:left; width:100%;">
<div class="helpline">
Tikona Care: 1800 20 94276  | <a href="mailto:customercare@tikona.in">customercare@tikona.in</a></div>

<div class="footer_line">&nbsp;</div>
<div class="footer_blueline"></div>

<div class="footer">
Copyright &copy; 2009. Tikona Digital Networks. All right Reserved.
<input type="hidden" name="act" value="null">
Step 5: Login

OK, this page doesn't say what exactly to do after the username/password is entered. There's no POST action. Instead, what they do is call the saveettings() function on clicking of the login.gif image. saveettings() is in the cookie.js file:

function savesettings()

if (document.forms[0].rememberme.checked)

document.forms[0].action = "newlogin.do?phone=0";
document.forms[0].method = "post";
return true;      

OK, so the page 'newlogin.do' is to be opened as a response to the clicking of the login button. And the username and password info has to be passed along, of course.

We already have the base url for the login page that we just used. Now we have to combine the base url with the 'newlogin.do' page instead of the 'login.do' page that we accessed earlier:

login_form_id = "newlogin.do?phone=0"
type = "2"

login_form_url = base_url.group(1) + login_form_id

login_data = urllib.urlencode({'username': username, 'password': password,
'type': type})

f = opener.open(login_form_url, login_data)

... and success! This is enough to get the login done. I added config file handling to the final code so that the username/password are stored in a config file. The final code also ensures that we're on a Tikona network before proceeding with the steps of logging in (by checking if the redirect URL is obtained in Step 1). See the latest code here.

Step 6: Auto-login on successful connection

Just one last step remains: a NetworkManager dispatcher script that will invoke this login program each time a network becomes ready:


if [ "$2" = "up" ]; then
/home/amit/bin/tikona-auto-login || :

Put this in /etc/NetworkManager/dispatcher.d with the appropriate permissions (744) and we're good to go!

Next steps:
The project surely isn't complete: a lot of support has to be added to NetworkManager itself to present a good UI to enable/disable these dispatcher scripts and also to prompt for a username/password instead of storing in a config file. This and several other TODO items are listed in the README file. If you plan on adding new networks that can be auto-logged in to, it's easy to follow these steps or feel free to email me for guidance.

Syndicated 2010-09-28 13:55:00 (Updated 2010-09-28 13:55:59) from Amit Shah

14 Sep 2010 (updated 16 Feb 2011 at 07:16 UTC) »

Communication between Guests and Hosts

Guest and Host communication should be a simple affair -- the venerable TCP/IP sockets should be the first answer to any remote communication.  However, it's not so simple once some special virtualisation-related constraints are added to the mix:

  • the guest and host are different machines, managed differently
  • the guest administrator and the host administrator may be different people
  • the guest administrator might inadvertently block IP-based communication channels to the host via firewall rules, rendering the TCP/IP-based communication channels unusable
The last point needs some elaboration: system administrators want to be really conservative in what they "open" to the outside world.  In this sense, the guest and host administrators are actively hostile to each other.  Also, rightly, neither should trust each other, given that a lot of the data stored in operating systems are now stored within clouds and any leak of the data could prove disastrous to the administrators and their employers.

So what's really needed is a special communication channel between guests and hosts that are not susceptible to being blocked out by guests or hosts as well as being a very special-purpose low-bandwidth channel that doesn't look to re-implement TCP/IP.  Some other requirements are mentioned on this page.

After several iterations, we settled on one particular implementation: virtio-serial.  The virtio-serial infrastructure rides on top of virtio, a generic para-virtual bus that enables exposing custom devices to guests.  virtio devices are abstracted enough so that guest drivers need not know what kind of bus they're actually riding on: they are PCI devices on x86 and native devices on s390 under the hood.  What this means is the same guest driver can be used to communicate with a virtio-serial device under x86 as well as s390.  Behind the scenes, the virtio layer, depending on the guest architecture type, works with the host virtio-pci device or virtio-s390 device.

The host device is coded in qemu.  One host virtio-serial device is capable of hosting multiple channels or ports on the same device.  The number of ports that can ride on top of a virtio-serial device is currently arbitrarily limited to 31, but one device can very well support 2^31 ports.  The device is available since upstream qemu release 0.13 as well as in Fedora from release 13 onwards.

The guest driver is written for Linux and Windows guests.  The API exposed includes open, read, write, poll, close calls.  For the Linux guest, ports can be opened in blocking as well as non-blocking modes.  The driver is included upstream from Linux kernel version 2.6.35.  Kernel 2.6.37 will also have asynchronous IO support -- ie, SIGIO will be delivered to interested userspace apps whenever the host-side connection is established or closed, or when a port gets hot-unplugged.

Using the ports is simple: when using qemu from the command line directly, add:

-chardev socket,path=/tmp/port0,server,nowait,id=port0-char
-device virtio-serial \
-device virtserialport,id=port1,name=org.fedoraproject.port.0,chardev=port0-char

this creates one device with one port and exposes to the guest the name 'org.fedoraproject.port.0'.  Guest apps can then open /dev/virtio-ports/org.fedoraproject.port.0 and start communicating with the host.  Host apps can open the /tmp/port0 unix domain socket to communicate with the guest.  Of course, there are other qemu chardev backends that can be used other than unix domain sockets.  There also is an in-qemu API that can be used.

More invocation options and examples are given in the invocation and how to test sections. 

There is sample C code for the guest as well as sample python code from the test suites.  The original test suite, written to verify the functionality of the user-kernel interface, will in the near future be moved to autotest, enabling faster addition of more tests and tests that not just check for correctness, but also regressions and bugs.

virtio-serial is already in use by the Matahari, Spice, libguestfs and Anaconda projects.  I'll briefly mention how Anaconda is going to use virtio-serial: starting Fedora 14, guest installs of Fedora will automatically send Anaconda logs to the host if a virtio-serial port with the name of 'org.fedoraproject.anaconda.log.0' is found.  virt-install is modified to create such a virtio-serial port.  This means debugging early anaconda output will be easier with the logs available on the host (and not worrying about guest file system corruptions during install or network drivers not available before a crash).

Further use: There are many more uses of virtio-serial, which should be pretty easy to code:
  • shutting down or suspending VMs when a host is shut down
  • clipboard copy/paste between hosts and guests (this is under progress  by the Spice team)
  • lock a desktop session in the guest when a vnc/spice connection is closed
  • fetch cpu/memory/power usage rates at regular intervals for monitoring

Syndicated 2010-09-14 10:49:00 (Updated 2011-02-16 06:48:14) from Amit Shah

Upgrading from Fedora 11 to Fedora 13

Having already installed (what would be) F13 on my work and personal laptops the traditional way -- by installing a fresh copy (since I wanted to modify the partition layout), I tried an upgrade on my desktop.

My desktop was running Fedora11 and I moved it to Fedora13. I wanted to test how the upgrade functionality works, does it run into any errors (esp. since it's from 11 -> 13, skipping 12 entirely), if the experience is smooth, etc.

I started out by downloading the RC compose from http://alt.fedoraproject.org/. Since all my installs are for the x86-64 architecture, I downloaded the DVD.iso. I then loopback-mounted the DVD on my laptop:

# mount -o loop /home/amit/Downloads/Fedora-13-x86_64-DVD.iso /mnt/F13

I then exported the contents of the mount via NFS; edit /etc/exports and put the following line:

/mnt/F13 172.31.10.*

This ensures the mount is only available to users on my local network.

Then, ensure the nfs services are running:

# service nfs start
# service nfslock start

On my desktop which was to be upgraded, I mounted the NFS export:

# mount -t nfs /mnt

And copied the kernel and initrd images to boot into:

# cp /mnt/isolinux/vmlinuz /boot
# cp /mnt/isolinux/initrd.img /boot

Then update the grub config with this new kernel that we'll boot into for the upgrade. Edit /boot/grub.conf and add:

title Fedora 13 install
    root (hd0,0)
    kernel /vmlinuz
    initrd /initrd.img

Once that's done, reboot and select the entry we just put in the grub.conf file. The install process starts and asks where the files are located for the install. Select NFS and provide the details: Server and directory /mnt/F13.

The first surprise for me was to see the updated graphics for the Anaconda installer. They got changed in the time I installed F13 (beta) on my laptops. The new artwork certainly looks very good and smooth. More white, less blue is a departure from the usual Fedora artwork, but it does look nice.

I then proceeded to select 'upgrade', it found my old F11 install and everything after that 'just worked'. I was skeptical about this while it was running: I had some rpmfusion.org repositories enabled and some packages installed from those repositories. I was wondering if those packages would be upgraded as well, or would they be left at the current state, which could create dependency problems, or if they would be completely removed. I had to wait for the install to finish, which took a while. The post-install process took more than half an hour, and when it was done, I selected 'Reboot'. Half-expecting something to have broken or to not work, I logged in, and voila, I was presented the shiny new GNOME 2.30 desktop. The temporary install kernel that I had put in as the default boot kernel was also removed. Small thing in itself, but great for usability.

Everything looked and felt right, no sign of breakage, no error messages, no warnings, just some good seamless upgrade.

I can't say really expected this. Coming from a die-hard Debian fan, distribution upgrades are something that was the forte of just Debian. For now. The Fedora developers have done a really good job of getting this process extremely easy to use and extremely reliable. Kudos to them!

While the Fedora 13 release has been pushed back a week for a install-over-NFS bug, it needs a certain combination of misfortunes to trigger, and luckily, I didn't hit that bug. However, when trying the F13 beta install on my laptop, I had hit a couple of Anaconda bugs, one of which is now resolved for F14 (crash when upgrading without a bootloader configuration) and the other one (no UI refresh if I switch between virtual consoles until a package finishes install -- really felt while installing over a slow network link) is a known problem with the design of Anaconda, and hopefully the devs get to it.

Overall, a really nice experience and I can now comfortably say Fedora has really rocketed ahead (all puns intended) since the old times when even installing packages used to be a nightmare. This is good progress indeed, and I'm glad to note that the future of the Linux desktop is in very good hands.

Cheers to the entire team!

Syndicated 2010-05-13 07:19:00 (Updated 2010-05-13 07:19:24) from Amit Shah

Summercamp artwork

Thanks to Nicu's excellent step-by-step howto on creating artwork with inkscape and the Open Clip Art Library, I managed to create this today:

This is for a couple of friends who are planning to organise a summer camp for kids in the locality.

Thanks Nicu!

Syndicated 2010-04-15 14:26:00 (Updated 2010-04-15 14:26:23) from Amit Shah

7 Apr 2010 (updated 15 Apr 2010 at 15:11 UTC) »

Virtualisation (on Fedora)

A few volunteers from India associated with the Fedora Project wrote articles for Linux For You's March 2010 Virtualisation Special. Those articles, and a few others, are put up on the Fedora wiki space at Magazine Articles on Virtualization. Thanks to LFY for letting us upload the pdfs!

We're always looking for more content, in the form of how-tos, articles, experiences, tips, etc., so feel free to upload content to the wiki or blog about it.

We also have contact with some magazine publishers so if you're interested in writing for online or print magazines, let the marketing folks know!

Syndicated 2010-04-07 15:11:00 (Updated 2010-04-15 14:28:50) from Amit Shah


An outing after quite some time. While thinking of overnight / day-long trips, I felt some nearby destinations for the overnight trips might be overflowing with people on account of a long weekend (Fri-Sat-Sun, on account of Gandhi Jayanti on the Friday). So it was decided we'd go for a day-long trip. It could start with a visit to some fort -- there are plenty around Pune -- and then proceed to other places from there.

From the list of forts that we shortlisted which were within a radius of 80 kms from Pune, Vichitragarh sounded very interesting. Weird Fort. Who wouldn't be intrigued? Its description mentioned it's hidden behind clouds most of time so that added some curiosity as well. So it was decided we'd start at about 7:30 towards Vichitragarh.

Vichitragarh, or Rohida fort, as it's also known, is just off Bhor near Bajarwadi. From NH4, pass the first toll gate towards Bangalore, pass the Narsapur phata that goes towards Baneshwar and look out for a turn to the right towards Bhor village. From Bhor, it's about 10 kms towards Bajarwadi. The total distance would be about 50-60 kms from Pune.

View from the car while going towards the fort

Entering Bajarwadi makes you feel Pune isn't so a bad place after all. Here is a place that's removed from population and the city chaos. A very clean-looking school is the first sight of any building in Bajarwadi. For us, it was also the last. We parked the car in the open near the school and began the trek fort-wards.

View from the place we parked the car - top of the school and the hills covered with clouds

A helpful local mentioned the fort is easily-reachable and is 30 minutes away. I thought 30 minutes of climb isn't too bad for a site that's below clouds most the time. And an easy climb, that too.

We began our march towards the fort, with no visibility of it. There were clouds covering a lot of the landscape in front of us, but surely the beauty of the place wasn't lost on us. I've spent a really long time in Pune but I've never seen a place more likeable than the one I was standing at that moment. It was full of greenery on either side of us. Small, nicely marked farms towards the slopes of the wide hills which we were now climbing. The hills themselves were full of life. Shrubs, and goats and cows and oxen grazing on them.

Bambi mentioned the view you get here is the view you get everywhere in Kerala. I agree. Beautiful slopes, Extremely green hills staring at us and clouds to welcome us to our summit.

What started as a gentle walk towards the clouds soon started morphing into negotiating a ghat section on foot. As we walked further, we realised we were going atop not directly, but via a series of curvy paths. Perhaps that explains the 'easy' part of the climb. Whenever we looked back, we could see we were gradually passing small hills. We were going farther away from the school -- and also leaving it way below under us.

Some helpful people have marked rocks and trees with arrows to guide people to the fort from what we guessed would be the path of least hardship. Without the arrows, one would soon be lost in the winds and the trees. Not to mention all the hills that dot the landscape.

It looked like a perfect day to go on such a trek, too. Cloudy -- no sunshine to sap our energy and not rainy -- to ensure we didn't slip while negotiating the ghats.

But it was windy. Wind strong enough to make a person sway. However, sitting on lush grass and watching the grass dance away is a delight. A delight that can make one think of not going back and be provided with a laptop and broadband connection. The farms below would provide for the food and a small hut some shelter. Funny how the basic necessities of life have been so accommodating to indulge in the new additions.

Our "trek" was more of a leisurely stroll with a few hardships. Hardships hard enough to make some wonder if we should leave the fort alone (which, after one and a half hours of climbing, was no where to be seen) and just return from whatever percentage of our journey had so far been. The clouds have a way of obscuring details. No wonder the met department finds it difficult to predict what they claim they can predict. Anyhow, not wanting to think of the retreat, I was adamant on reaching "there" and also explaining to the troupe, by way of reason, that it couldn't be much farther away if we went by the gent's estimate of 30 minutes to the top.

It finally seemed we were getting somewhere -- or at least someone else was getting at where we were -- for we heard some voices. In about 2 minutes' time, we could also see the people. They mentioned the fort must be 10 minutes away so there was some added sense of relief. Advice to not look at the climbing-down or rather slipping-down party was good indeed and we continued onward. Everyone had a general feeling of the descent not being as easy because of the water on the rocks and the party's efforts to stay upright weren't encouraging visuals.

We could by now see the faint outline of the fort walls and it was but natural to have experienced a sense of an achievement.

The majestic doors of the fort welcomed us in. A few steps further up and we were in front of an informative board confirming that we were at Vichitragarh.

The board says

The fort's entrance is shaped like a cow's face and a picture of Ganesh at its head is unrecognisable now.

To the right of the second entrance is an eye-catching 3x3m. water tank.

The third entrance, made of stones and which is closed forever, has impressions to either side of it. To the left is some text in the Devnagari script and to the right is the text in Persian. (Some words in the Devnagri script read 'Hazrat Sultana... Mudpakshala...')

To the west of the temple are a few water tanks... of which 3 are connected...

The Fort's history
This ancient fort...

Bandal refused Shivaji's offer to fight for Swaraj.. and hence Shivaji attacked Rohida.

Some of the text is illegible because of the rust.

A map shows some of the other forts that are visible from Vichitragarh (or Vichitragad). Sinhagad to the North, Purandhar to the East, Raireshwar to the South, Kenjavgad and Kamalgad
to the South-West and Rajgad and Torna to the North-West.

As for us, we couldn't even see 10 ft in front of us thanks to the heavy fog / cloud cover.

There's also a mention of the expanse of the fort: 5 hectares.

Once safely up at the fort, we sighted a nice semi-circular sitting area and immediately took to the throne. I was pretty impressed seeing a solar panel assembly which fed energy into a lamp. The government does do some good some of the time, I thought.

A while later, we heard sounds of a bell. Anticipating a person selling kulfis would have been unwise but one can't stop thinking of such possibilities when the bell rings such. A man casually strolled towards us a short while after and explained it was him offering prayers at the temple, instantly melting any more thoughts of kulfis.

He mentioned he's the keeper of the fort, with the authorities having felt the need of appointing someone to guard the fort at day time after a heist of Rs. 50,000 solar energy equipment. Night times are guarded by closing the doors to the fort. Robbing equipment -- I thought that certainly wouldn't figure in tourists' lists of getting tick-marks against when visiting the fort. It had to be an inside job, a job carried out by locals. The guard started getting over-friendly what with questions about where we stayed, repercussions of swine flu and taunting people who couldn't speak Marathi. We felt that should be enough chit-chat and thought of taking a stroll around the fort.

All we could was knee-length grass swishing away and clouds obscuring any other view. It certainly is some experience watching such tall grass being shaped into contours by persistent winds.

The track we were walking on soon disappeared and for any further progress, we would've had to walk amidst the grass, that was depositing all its dew on our clothes. The prospect of getting introduced to snakes taking their siesta wasn't a particularly inviting one so we thought we'd skip the rest of the fort and also the temple, by way of which we'll skip another friendly encounter with the guard, who didn't fail to mention he'd jot down our details on a register as is the custom for tourists visiting the fort.

So off we went by the solar panel assembly; whatever remained of it, out the door, and back amidst the wet rocks and the friendly flora around. With some aprehension, we started the descent. It wasn't raining, thankfully, but now we were well aware we'll have to pass steep declines as well as rocks with thin films of water on them, making the descent slippery and slow.

Add to that, the arrows weren't visible everywhere to guide us back, and when having to choose between multiple routes we went by the looks of the terrain rather than memory. A few "interesting" slopes later we were on the plains with the grass swaying exactly the way we had left it.

The blowing wind made walking down difficult too. Slight imbalance and the wind would made its effect felt.

Nevertheless, the climb down clocked at 1:30 hrs compared to the 2:00 hrs walk up. A total of 5 hours were spent for the extremely enjoyable journey up and down the Vichitragarh fort. I'm already thinking of going back with a few friends who I know will enjoy going to such an outing.

On the way back, we stopped for a short while at the Baneshwar water fall, entirely giving the temple a miss. Not much to talk about the waterfall itself, but the place around it looks like a good jungle and a separate trip there might turn up some interesting memories as well.

I've tried some GIMPing with these pics -- the first time I'm trying that.


Syndicated 2009-10-12 13:48:00 (Updated 2009-10-12 13:48:28) from Amit Shah

RHEV-M demo

Navin gives a small demo of RHEV-M, the management platform for the Red Hat Enterprise Virtualization product:



Syndicated 2009-09-11 07:30:00 (Updated 2009-09-11 07:33:47) from Amit Shah

Debian moving to time-based releases


I have used Debian since several years now and have always been either on the 'testing' or the 'sid' releases on my desktops / laptops. I never felt the need to switch to 'stable' as even sid was stable enough for me for my regular usage (with a few scripts to keep out buggy new debs).

I've seen, over time, people move to Ubuntu though. That means people really like Debian but they also wanted 'stable' releases at predictable times. If one stayed on a Debian stable release, 'bleeding edge' or 'new software' was never possible. When a new Debian release would be out, upstreams would've moved one or two major releases ahead.

So Ubuntu captured the desktop share away from Debian. The server folks wouldn't complain for lack of new features. So would this really make any difference?

Will the folks who migrated to Ubuntu go back to Debian?

(I've since moved majority of my machines to Fedora though -- but that's a different topic)

Syndicated 2009-07-29 12:38:00 (Updated 2009-07-29 12:48:17) from Amit Shah

We open if we die

I wrote a few comments about introducing "guarantees" in software -- how do you assure your customers that they won't be left in the lurch if you go down. It generated a healthy discussion and that gave me an opportunity to fine-tune the definition of "insurance" in software. Openness is such an advantage to foster great discussions and free dialogue.

So reading this piece of news this morning via phoronix about a company called pogoplug has me really excited. I'd feel vindicated if they could increase their customer base by that announcement. I hope they don't go down; but I'd also like to see them go open regardless of their financial health; if an idea is out in the market, there'll be people copying it and implementing it in different ways anyway. If, instead, they open up their code right away, they can engage a much wider community in enhancing their software and prevent variants from springing up which might even offer competing features.

Syndicated 2009-05-13 05:03:00 (Updated 2009-07-28 17:44:00) from Amit Shah

33 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!