Saturday, January 8, 2011

Coupling together DC and SSH: Management Issues

These are a few issues relating to the IITGDC++ project.

First, the people involved. We would require:
  • 1 Account Arbitrator
  • Lots of volunteers who have a CSE lab machine.
Responsibility of Account Arbitrator:
  • He/She would be required to attend to all requests pertaining to user accounts by the junta.
  • On receiving a request, allocate the account to one of the volunteer machines in the project.
Responsibility of volunteers:
  • Install Ubuntu 10.10 Maverick Meerkat on their lab machines.
  • Install the following software on their lab machines:
    • ssh
    • openssh-server
    • sshfs
    • eiskaltdcpp-gtk (Relevant packages can be found at http://jatinga.iitg.ernet.in/~k.pranav)
  • Create a user group called "iitgdcpp" on their machines.
  • Upon receiving a user account request, create a user account on their machines and add the account to the "iitgdcpp" group.
  • Download the file 'iitgdcpp_server.zip' from http://jatinga.iitg.ernet.in/~k.pranav/ and unzip it in the home directory of all iitgdcpp user accounts.
  • Configure the eiskaltdcpp-gtk installation for each user account according to the instructions in the README file.
  • Finally, send the user account password to the user who sent the request.

Monday, January 3, 2011

Coupling together DC and SSH: Detailed Procedure

This post will detail the procedure to connect to your DC client via SSH. I am publishing this because even though the automation has not been set up, Linux users having access to CSE lab machines can use them for accessing DC by following this procedure.

OK, first of all, you need 2 computers for this. One in the CSE labs, and the other your personal computer at your hostel. Ensure that both the machines are running Linux. Now make sure that the following packages are installed in these machines:

For the CSE lab machine:
  • ssh
  • openssh-server
  • sshfs
  • eiskaltdcpp-gtk
For your personal computer:
  • ssh
  • openssh-server
Now follow these steps:
  1. From your personal computer, establish an SSH connection to the lab machine. You know how to do this.
    $ ssh -Y username@lab_comp
    Enter your password and log in.
  2. Now this is a one time step only. "cd" to the directory ~/.ssh and open the file "config" in your favorite editor. If it does not exist create it. Add the following lines to it.
    Host *
    ServerAliveInterval 240
  3. Setup the downloads and shared folders using sshfs.
    $ sshfs username@personal_comp: personal_comp_dir lab_comp_mount_point
  4. Now run eiskaltdcpp-gtk.
    $ eiskaltdcpp-gtk
    Now remember that eiskaltdcpp comes with 2 frontends: GTK and QT. I recommend GTK as it is lighter and faster over SSH connection.
  5. Go to preferences and setup shared and download folders according to the mount points you used in step 3. Also, setup the "Incomplete Downloads" directory to be the same as the Downloads directory.
  6. Now, enjoy the normal use of EiskaltDC++.
Now that this is explained, I am still looking for volunteers who would like to help me with the shell scripting.

    Saturday, January 1, 2011

    Coupling together DC and SSH: Initial Tests and Breakthrough

    Hello folks. I am pleased to announce that it works. \m/
    I did some test runs today and was able to run DC from my linux machine without any glitches.

    This is a pretty serious breakthrough. Now, if we can automate the process, we can run this mechanism on an institute scale. And the poor authorities would only be able to look and sigh at our ingenuity.

    Now, the process I followed is pretty simple. It requires a 2-way SSH connection with a computer in the broadcast domain of the DC server.

    Now, to explain this, there are 3 machines involved here: the machine running the DC hub, the user's machine, and an intermediate machine in the broadcast domain of the machine running the hub. Let us name them A, B and C respectively.
    The process, then, goes something like this:
    1. Using 'ssh -Y' establish a connection from B to C.
    2. After logging in, use 'sshfs' to connect back from C to B.
    3. Mount the shared and download directories in B to specific mount points in C using 'sshfs'.
    4. Now run your favorite DC client on C. Enter the shared and download directories as the mount points where B's directories are mounted.
    5. Operate your DC client normally.
    And voila, you have successfully converted all DC traffic going through the routers to SSH traffic, which cannot ever be banned by the authorities.

    OK, now this is the basic idea. What remains is the automation part of it. And for that we need people with extensive knowledge of shell scripts. Interested people, please get in touch. Thank you.

    Coupling together DC and SSH: Initial thoughts

    DC has been the main medium for file sharing in my institute. Now the authorities have begun a covert operation to ban the DC and ADC protocols. As you can imagine, this will hit the student community really hard as DC is a medium we have relied upon since the inception of the institute network itself.

    As the authorities tighten the noose around the 2 protocols, it is high time we did something about this.

    The idea is to hide DC behind a protocol that they can never think of banning. One of the key protocols used at our institute is SSH. If we can use SSH such that the DC traffic converts to SSH traffic, then no one will ever be able to lay a hand on our beloved DC.

    Now, we must understand that DC traffic cannot be restricted inside a single broadcast domain. The restriction comes from the routers, which filter off the packets pertaining to the DC and ADC protocols.

    Now my initial thoughts are that we run DC inside a single broadcast domain, for example, the B.Tech 4th year lab, and then we provide an interface to each student implemented via SSH such that it feels that a person is running the DC application on his own machine.

    In this case, there are 4 mechanisms relevant to us:
    • GUI
    • File Sharing
    • File Uploading
    • File Downloading
    GUI will be taken care of by SSH, the rest has to be implemented. This requires a lot of knowledge on shell scripting, and will require hours of planning and coding. I am willing to do that. Any one else, if interested, is invited to join me in this endeavor. For the end of DC will surely mark a historic calamity in the history of IITG.