8. Instructions for Running Calendar and File Access Applications


8.1 File Access Application

8.1.1 FAQ and Trouble Shooting for the File Access Application
8.1.2 Help on the File Access Application's GUI
8.2 Calendar Applications



8.1 File Access Application:
 

This application is a File Access system that supports different primitives like Fetch, Deposit, Transfer ,
search , File status and Web Search.

Please follow the following steps to run this App. It is assumed that you have ran "userSetup" script to
setup the configuration files needed by this app. If you have not, please run "userSetup".
 

Step 1: Start Rmi Registry

To start agent-servers,the user needs to run a RMI Registry in a user-defined port.
We provided the script "startRmi" for this.

For example if you decided to run agent-servers on machine "Machine1", "Machine2" and "Machine3",
you need to run the script "startRmi" in all these machines as below:

    Machine1>perl {$AJANTA_HOME}/setup/startRmi
    Machine2>perl {$AJANTA_HOME}/setup/startRmi
    Machine3>perl {$AJANTA_HOME}/setup/startRmi

The script will start a RMI Registry in the current machine, it is running. It will also keep the port information
in the configaration file "$HOME/.ajanta/servers/serverConfig". Any consequent run of the script will kill
the previous RMI Registry and run a new one.
 

Step 2a: Create Root Directory

Create a directory called "root" under your $HOME directory.

Step 2b: Create the .acl files for file access control

To give appropriate access permissions to all the files and directories under your root directory, you will need to create a .acl file under root (to give permissions to files directly under root) and under each subdirectory in root (to give permissions to files in subdirectories). The name of this file will be just .acl

       An example .acl file:
        For a directory structure that looks like the following tree:

        root/
        -> A/ (subdirectory)
            -> somefile
        -> hello
        -> tasklist
        -> questions

        The .acl file under root will look as follows:

       root rwi urn:ans:plato.cs.umn.edu/pathak     root directory has read, write and inherit permissions
        A rw urn:ans:plato.cs.umn.edu/pathak       subdirectory A has RW permissions, should have it's own .acl file for the files in it
        hello rw  urn:ans:plato.cs.umn.edu/pathak   files under root: hello, tasklist have RW and questions has only R permissions
       tasklist rw urn:ans:plato.cs.umn.edu/pathak
        questions r urn:ans:plato.cs.umn.edu/pathak

        This .acl gives the user urn:ans:plato.cs.umn.edu/pathak read(r), write(w) and inherit(i) permissions on the root directory and read(r) and write(w) permissions on the subdirectory A and the files hello and tasklist. It also gives only read(r) permissions on the file questions to the same user.
        The inherit(i) permission on the root directory means that any file under root that is not mentioned in the .acl file can inherit the read and write permissions from its parent (root).

        If you want to allow access to the file A/somefile, you will need either

                somefile rw urn:ans:plato.cs.umn.edu/pathak
          OR We recommend that you give explicit permissions to all the files you want to expose in the approriate .acl files as opposed to allowing the files to inherit their permissions from the parent directory using the inherit(i) facility. This technique is more reliable, specially when using the file access system's Deposit operation.

       The meanings of the allowed permissions are:
        r: read permission
        w: write permission
        i: The inherit permission on a directory allows a file in that directory to inherit the permissions of it's parent directory if there isn't an entry for it in the .acl.

        Example: If the directory A does not contain a .acl file giving permissions to the file somefile, then the application checks the .acl under the root directory to see if the directory A has inherit(i) permissions. If it does, it will apply the  permissions of the directory A to the file somefile under this directory A.

You need to create the .acl file in the root directory to give read (r),  write(w), or inherit(i) perimissions on files or directories.
Note: The .acl should not contain any blank lines, they will cause an exception when the file server is started

If  you wish another user's agent  to visit your file access system and deposit a file, you should give
a write permission for that file  to that  user.

Step 2c: Run File Server

   A user runs a FileServer  (for hosting file access agents) by executing:
 

    Machine1>java ajanta.apps.afs.FileServer    $HOME/root

The argument to the FileServer is the directory which is to be shared. You have to have a root directory
where the files to be fetched or transferred are to be stored.

Theserver would be assigned  a URN  which will be "UserURN"/afsServer.

For example if a user running this server has URN    urn:ans:cs.umn.edu/rsingh, then the URN
of the file server  will be:

         urn:ans:cs.umn.edu/rsingh/afsServer
 

Step 2d: Run FileClient from one/both of the machines
 

You have to run the FileClient by executing the following command
 

   Machine1>java ajanta.apps.afs.FileClient

When the GUI pops up, select the primitives and enter the parameters. Then click "Send Agent" to launch the
agent.

Use the menu to select "fetch", "deposit", or  "transfer" operations.

For additional help on using the AFS GUI, see the section Help for the File Access Application's GUI.

Using this GUI you can create an itinerary and then send an agent. You can maintain a list of users and their
URNs, and select from this list to create an itinerary for a file agent.
 

8.1.1  FAQ for the File Access Application:

1. Using the Ajanta File Access System's Web Search Facility

If you want to use the File Access System's Web Search facility, you will first need to create a glimpse index on the directory that you want to expose. See the instructions given below to create a glimpse index, in this case on the .www directory:

      There are a few requirements for the working of the File Access system.

        For example, in our case, it will be

        >> "glimpseindex -H /path/root/.webindex  .www"

        See manpage for further details.

Trouble Shooting:

1. The Date field in the Web Search GUI does not have a default value and if no value is entered, it will dump. Please always enter some date in this field. Currently, the search facility only searches over the years 1998 and 1999.

2. The search for abstract option in the web search facility does not work.

3. You may have to kill the File Client and restart it after each web search for updated, valid results.

4. If you are unable to start the File Client and the error you get is "Class not found", run the makefile in the directory $AJANTA_HOME/ajanta/apps/afs to compile the .java files

        You can also just use the following command at the UNIX prompt:

            % javac *.java

8.1.2  Help on the Application's GUI:

1. The main GUI window

This is the GUI window that pops up when the file client is started. It has a drop down menu in the center at the top with the following options: Fetch, Deposit, Transfer, Search and Web Search. When one of the options is selected, the next task-specific window will pop up.

2. The Different Operations


 


 

Depending on the operation you choose from the main GUI in Step 1, the next operation-specific window will pop up. The above images show the GUI that pops up for the following four tasks: Fetch, Deposit, Transfer and WebSearch. The user should input the information required (local and/or remote file names). Use the CHOOSE FILE option, if provided.

In the FETCH task, enter the file name of the remote file that is to be fetched and then select the users

In the DEPOSIT task, enter the file name of the source (the local file that is to be deposited on the remote server) followed by the destination file name (the name to be used for the file at the remote server) and then select the users.

In the TRANSFER task, select the name of the remote file (file on the remote server) that is to be transfered to your server. Also, enter the name of the file to be used locally and then select the users.

In the WEB SEARCH task, enter the word that you are searching for as the KEYWORD and fill in the details like frequency of this keyword, case sensitivity and abstract fetching.  Enter the date since last modification (If the date field is left blank, the program will throw an exception) and then select the users.

Use SELECT USER to choose the user(s) to whose file access server(s) the agent will travel to, as shown in Step 3.

3. Select User

Use this GUI to select the one or more file servers that the agent will visit for the chosen task. Click on the users name and click SELECT. When you have selected all the users needed, CLOSE the window and return to the operation-specific GUI window from Step 2. Click on ADD and then CLOSE, to return to the window in Step 1. Then click on SEND AGENT to send the agent to perform the task with the chosen tasklist.
The File Client will print success/error messages on system.out
 

8.2 Calendar Application

This application allows different user to maintain their calendar
and to allow them to schedule events by sending agents. Each user
starts a CalendarServer which support agent migration and hosting.
CalendarServer maintains a Calendar Database as a serialized hash
table in the file ./ajanta/server/CalendarServer/HashTableDB.

Running the calendar manager.

1. Start an rmiregistry on every m/c that u want to run the
   CalendarServer using startRmi script in setup directory.
   Then start the CalendarServer.

   > cd .ajanta/servers/calendarServer
   > java ajanta.apps.calendar.CalendarServer
 

2. Using the graphical user interface one can modify the database
   either locally or by sending agents to different servers. To
   start the GUI execute the following commands.

   If a rmiregistry is not running on this machine then start one
   before executing these commands.

   > cd .ajanta/servers/calendarServer
   > java ajanta.apps.calendar.CalendarUI
 
 

   It will pop up a window using which one can modify the calendar
   database locally by using "ADD", "EDIT" and "DELETE" options.
   When one press "ADD" button it will pop up a Dialog box with a
   number of fields described below.
                           format                      Compulsory
    Date               Month:Day:year (5:25:1999)    Yes
    Start Time         Hour:Min 14:20                Yes
    Duration           Min       45                  Yes
    Description        Text                          NO
    Participants       URNs of Users                 NO

   ADD will use the above information to insert the new event in local
   calendar database. After selecting a calendar event from the
   main window if one press the "EDIT" button it will show a similar
   dialog box as in ADD. It display all the data of the event in their
   corresponding fields. It is used to modify the events in local
   database. Similarly by selecting a event in the main window and
   pressing "DELETE" will delete the event from the database.

   "SCHEDULE" is used to schedule a new event by sending agent to
    all the user's CalendarServer in the participants  list. When
    one press the "SCHEDULE" button it will pop a window similar
    to "ADD" but in this case participants list can not be empty.
    To select a user one can press "SELECT USER" button to pop
    up a list of user and their URNs. Using poped window one can
    maintain a list of user. Beside selecting a name from the window
    one can also write the name of the user's URN in the text area of
    the participants. When one press "OK" button it will start schedule
    process by launching agents" and pop the result as a Dialog box.

    For more detail about Calendar implementation please see papers
    published on our web sites.
 
 

I


GO  TO Top of this page    Previous Chapter       Next  Chapter       Table of Contents of this Guide