There are times when I wonder why I am so involved with computers ... this is clearly one of those times.

कर्मण्यैवाधिकरस्ते मा फलेशु कदाचन

karmaNyaivaadhikaraste maa faleshu kadaachana

This is a phrase from the भगवद गीत (bhagavad giit) which has been stuck in my head for the last 30 odd years. It roughly paraphrases into

Do something because you think it is worth doing not because of what you hope to achieve by doing it.¹

The above maxim is a good one but is sometimes a cop-out. Moreover, it provides no basis for actually making ethical choices.

Ethics comes from one's interactions with the communities one is a part of. There are (roughly) two communities that I am a part of in the context of computers:

• the FOSS community; specifically, the Debian community.
• the IMSc computer community

I take these in turn below.

Debian and FOSS communities

By its own standards, the Debian community has suffered a massive failure ... and by these same standards it has reacted extremely well to this failure.

I feel shame and blame. Why have I been ignoring RFH#332498 all these days when it shows up in the output of wnpp-alert? Here I am, a mathematician with some understanding of the issues, not helping out! Three years ago I even gave a short course of lectures on implementations of crypto; the source of openssl and openssh were used as examples. Excuses like, "I don't know anything about library packaging" and "I need more time!" (who doesn't) seem too weak now.

At the same time, I feel a sense of solidarity with the Debian (and more widely FOSS) community as it tries to pull out of the resulting mess. The resilience that allows us to laugh wryly at ourselves is IMHO admirable.

As Steve Kemp wrote: "[When we look back we will see that] we did good".

IMSc computer community

The IMSc computer setup was built by volunteers and was genuinely a community when I joined this institute in 1996. It has since then broken into users, system administrators and the computer committee. As Indira Gandhi would have said: "This is a world-wide phenomenon", and as was the case when she said it, my response is: "That doesn't make it a good thing!"

When I speak about this fractured IMSc community below it is in generalities. There are certainly individuals who rise above the shards.

I have been promoting the use of FOSS and more specifically Debian at IMSc ever since I got here. While explaining the pragmatic aspects like cost and security, I have also tried to emphasize the freedom and community aspects of FOSS use. When the latter are not understood or accepted, the former are easily blown away.

This year I made an attempt to get the Computer Committee to invite users to choose² their own computers and the software that ran on it, but it turned out that no one really wanted this. Users just wanted to buy "fancy toys", the administrators just wanted to make their life simple and CC members just wanted the power to dictate what people bought.³

I also made an attempt to get our users to educate each other on the use of computers for their work --- first through the establishment of a wiki and then through the "No-Excuse" mailing list.⁴

Unfortunately, the fractured IMSc computer community sees computers and software as expensive commodities --- with some combination of fear, greed and irritation. In any case, there is no feeling of being part of a larger community that is trying to solve (certain types of) problems.

A wise man once said:

With great freedom comes even greater responsibility.

This may explain why we prefer being dictated to by proprietary vendors and computer committees that "buy stuff for us". We are afraid of the responsibility that comes with freedom.

Another much quoted quote is:

If you are not part of the solution then you are part of the problem.

The FOSS community (actively) invites people to join-in in solving problems. This participation (which can be at a level of one's own choosing) is the source of one's freedom in free software. The IMSc community just wants मा-बाप सर्कार (maa-baap sarkaar) to fix their toys.

A decision

The IMSc computer community was tied to Debian and FOSS after the break-ins into our system in the early 2000's. At that point, I was instrumental in installing a security infrastructure based mainly on Debian. This led to my greater involvement with FOSS and Debian and also to the greater "infiltration" of Debian and FOSS into IMSc computers.

From the "commodity" point of view at IMSc we have come a full circle since most users will have to "do a lot" so that the IMSc computer LAN emerges unscathed from the crisis created by the Debian openssl flaw.

From the "community" point of view at Debian we have spiralled out and even this major whirlpool will not drag us back in.

It is no longer possible (for me) to straddle the circle and the spiral in an attempt to widen the former; I'm taking the "outward radial vector"!

User web pages moved to the new server "people".
Please ssh/scp to "people" if you need to change your
your personal web pages.

Executive Summary

If you do not maintain a "web page" visible at

http://www.imsc.res.in/~your_user_name

and you do not ever want to have one ...
... then you need to read no further!

Otherwise it is best if you read through to the end even though this document is a bit long!

All existing user home pages have been moved to a new server called "people". From now on it will be these pages which will be visible from the URL given above.

You can log-in to "people" using "ssh" to make changes to your web pages which are in the subdirectory "public_html/" of your account there.

The new web server on "people" has many more features; the idea is that each user gets something very much like their own web server.

Some problems that may arise with the new setup are outlined in a separate section below.

Web Services on "people"

The web pages under ~user/public_html on "people" can be fully configured by the user.

For those who understand these terms, this directory is served by the "apache2" web server with the directive: AllowOverride All and the "suexec" feature has also been enabled.

Combined with the additional disk space available, this should give users a lot of room for creatively putting content on the web. In particular, you can have your own blogs, wikis, collaborative development sites, password protected pages and so on.

At this point, it is worth recalling that the Acceptable Usage Policy underlines the fact that the IMSc does not permit the use of its Computer facilities for illegal activity. Specifically, users are required to ensure that they have a clear copyright and license to distribute the contents of the pages that they maintain.

More generally, the files that are maintained by users on "people" should be the result of their own creative efforts rather than material downloaded from elsewhere.

(A larger backup area is being provided on a different machine for each user so "people" need not be used for backup.)

Possible Problems

Each user should ensure that links in their web pages which refer to names outside their web space should use absolute URLs and not relative ones. The latter will not work as expected.

Links that use absolute URLs like "http://pp3.imsc.res.in/~someuser" should be replaced by "http://people.imsc.res.in/~someuser".

In the new setup, "~someuser" will only work if "someuser" is a login name on the IMSc system. In all other cases you should contact the system administrators for alternate remedies.

The best way to test your web pages is to create a copy on your desktop and check it with a local web server on your desktop. Anything that does not work in that context is unlikely to work when transferred to "people". Once you are satisfied with your desktop version you can "rsync" or "scp" it to "people".

Additional Requirements

It may be possible that you need some software installed on "people" for your web pages. Such additional software could be installed if it satisfies the following criteria:

1. It is likely to be used by a number of user web pages.
2. It is required in order to display these web pages.
3. It is available as a package for the Debian GNU/Linux distribution.

Specifically, point (b) means that software needed to develop web pages will not be installed on "people". As mentioned above, web pages should be developed on your desktop machine and synchronised with the server on "people" when they are in publishable form. (Since these web pages are available to the general public, putting them up constitutes publication!)

Enjoy!

• Using centralised spam filtering (since many users still do not filter their mail at all).
• Long term archival
• Giving users the choice of how to read bulk mail:
  • normal delivery
  • digest delivery
  • only read the web archives
  • (Need to figure out swaml to provide yet another option!)
• Subscribing/unsubscribing users is easier than maintaining
  • alias databases (since switch over to LDAP has been put off indefinitely).

1. The CC has acquired a new server to be our web server.
2. This is a good time to re-organise our website.
3. We should use a version control system to keep track
   of changes.

Current Problems

Our website (like the IMSc network) has grown organically rather than logically. While there is nothing wrong with that per se, an examination of our web site shows that:

1. Our apache config file is messy and hence difficult to read and/or modify.
2. Web pages are edited, added, discarded without any clear logs of who did what and why and when.
3. A number of our web pages fail to comply with W3C standards for HTML.
4. A number of our web pages/images have no clear copyright. In particular, it is not clear that we can legally distribute them.
5. There are broken links. Conversely, there are files in the web directories which are never referenced.
6. There is a lot of out-of-date information in our web pages. We have no system to keep track of short-term info.

Since we are planning to install a new web server on the new server, this is a good time to organise things better.

Transition

We will set up the configuration on the new web server to have two parts (at least): "legacy" and "new". The "legacy" configuration will consist of all those pages which will remain on the current web server (pp3). The (shiny) "new" configuration will consist of more organised web pages on the new web server (which will have a head server and a number of tails; one of which will be the legacy server). In particular, we can transfer sub-site by sub-site according to when the relevant people are free to do the work. (In order to prevent this becoming "forever" we must agree that "pp3" will not survive beyond the life of the machine that it is on!)

New Server Organisation

The new configuration will need to be discussed (a lot!) before and during its implementation. Primarily, I would like the management of this server to be divided according to the following classes:

1. Server Configuration.
2. Server Organisation.
3. Web page styles.
4. Web page content.

Orthogonal to this classification, I would like to see a division according to the following criteria (in brackets we have further possible divisions):

A. IMSc (semi-) static web pages (Main, Phys, TCS, Math, CC, Office, Library). B. IMSc dynamic content web site (Webmail, Calendar, Annual Report, Applications, IMSc E-print server). C. Personal Web pages (~user) D. Hosted Web sites. (whepp.org, iarcs, rms, ...) E. Personal Web sites (a new feature which is possible).

It will be organisationally very simple if each of the services A, B, C, D, E will be managed on separate (one or more) software servers which will function entirely independently.

The "head" server may just be a content-less proxy server (server 0) that remains visible on the internet as it currently is at www.imsc.res.in.

In the discussion below I want to concentrate on (aA), (bA) and (aC). If we continue to have a separate "head" server then the discussion applies to (a0) as well. To be absolutely clear, I am not discussing the style of the website or its content.

Version Control

Version control is a layer that is added on top of basic file editing that allows one to:

1. Keep track of why, when and by who the changes were made.
2. Allow for testing of the changes before they are made "live".
3. Quickly revert changes in case of bugs. In particular, recover accidental file deletions with older versions.
4. Keep "old tricks" in the system without keeping old files around for "reference".
5. Allow many people to work simultaneously on different parts of the system independently.

Of course, all this comes at a price --- people have to learn some commands and learn to use them in a certain way.

I would like to see (aA), (bA), (aC) and (a0) managed using version control. In particular, this means that we will do away with "live" editing of files for all these aspects of the web server.

Disk space and copies

Disk space is no longer at a premium so it is quite easy for each of the people involved in (aA), (bA), (aC) and (a0) to have a working copy of the relevant web service. All editing and testing can be done with this working copy. Once this is satisfactory, it can be "pushed" to the real web server with a "commit message" which will summarise the changes made.

Remaining Services

A number of the remaining services could also be managed similarly, but I would leave that option to the person responsible. The common repository system can be used for all these. The Web commitee may want to organise a seminar series on how to create and manage content for the web.

On Thursday I wrote:

If so required I can provide examples where the CCM has justified the purchase of equipment which our users subsequently did not use (or used insufficiently to justify the expense).

1. The Power Challenge (darth). This heavily under-utilised computational machine was even off for a while without anyone noticing. The difficulty of installing useful software on this machine was one of the “power challenges” to making long term use of it.

2. We recently paid more than double the basic desktop price for higher-end desktop machines based on the idea that we will use them for distributed computing. That has not happened. This is not the first time that IMSc has paid in excess of 50% above the cheapest desktop price for desktop machines. In most cases this has also meant additional lost man-hours spent on installing useful software on these machines. Bleeding-edge hardware means that the user of such hardware bleeds time debugging it.

3. We bought gigabit network infrastructure (switches and cabling). This was never really justified except that it is “the wave of the future”. Since we do not do any internal video/audio conferencing, these speeds have never been really used. In fact, I am not sure we know how to make use of all the software features of these switches.

4. We have bought a number of SUN/Solaris machines based on the idea that some people need to use them for computation. As far as I know the number of people who actually do this is less than the number of SUN/Solaris machines. The machines have also contributed to the eating up of man-hours spent installing useful software on it. Equivalent commodity hardware would have cost about 1/2 of what we paid.

5. We originally bought proprietary hardware for the LANL mirror. Other than the negative value caused delays in disk expansion due to unavailability of the (proprietary) disk, no value was added to our use by this expensive proprietary hardware. (After we moved to commodity hardware we have added disk entirely seemlessly.)

6. We bought extra hardware like a laptop with a docking station, an Iomega ZIP drive, a graphics tablet, a MacMini. Most of these have not been used by even a handful of users.

7. We spent a lot on special sofware like compiler kits for SGI, SUN, extra licenses for Matlab, Mathematica. There are very few users of most of these licenses (perhaps Mathematica is an exception). On the other hand we have not paid any money to the TeX User’s Group, the Free Software Foundation, the Apache Foundation or the Software in Public Interest—all of whose software we use on a regular basis.

8. The lack of utilisation of the Apple PowerMacs has recently been discussed in the CCM. Part of the reason is that the machines were not properly installed. Another part of the reason is that none of our computational users had enough of a need of this additional hardware to ensure its proper installation.

9. About 4 years ago, we spent a lot on (what was) high-end graphics hardware for a number of workstations saying that 3-D/GL was required to do interesting work with simulations. This (graphics hardware) was not used. If only we had waited until we were ready to make use of this hardware! Nowadays similar quality 3-D/GL is supported on commodity hardware—to the extent that we use it.