| Date Of Receipt: 13-JUL-1994 16:07:34.10
From: SEAN::davidson "D. Sean Davidson"
To: [email protected], [email protected]
CC:
Subj: Re: Using srequest for shared sandbox submits
Andy,
Yes this is possible and I needed to write it up anywere for others to use.
Here is what you need to do to make srequest work for your sandbox using a
alpha system as your server. Just replace mips_ULTRIX or vax_ULTRIX where
appropriate for your type of server.
This is a real quick pass at writing up what needs to be done so I may have
missed something. Let me know what problems you run into.
Right now the srequest utility is slanted to being used for only os and x11
submits, so for single type projects now you must pretend you are an os submit.
Sean
1. Get a local copy of the /usr/sde area from a USG backing tree server
on the system that will be the submit request server.
2. Determine what system will be your submit request server and edit
the /etc/inetd.conf and /etc/services adding the following lines:
/etc/inetd.conf
srequest stream tcp nowait root /usr/sde/osf1/bin/alpha_OSF1/srequest srequest
/etc/services
srequest 12001/tcp
and then do a 'kill -HUP' of the inetd process to cause it to reread
the inetd.conf file.
3. Determine a unique name for what you are working on and edit the
/usr/sde/osf1/bin/share/data/releasedata file in your local /usr/sde
area using a previous release as an example and add the following
subfields:
your_unique_name.submit_request_server: your_host_name_here
your_unique_name.submit_request_cc: none
your_unique_name.protected_files_alias: arw
your_unique_name.os_submit_tree: top_location_name_of_your_shared_sandbox
your_unique_name.x11_submit_tree: none
4. Create in your shared sandbox in the logs directory a srequest
directory and in this srequest directory create a file
your_unique_name.id with a single line of '00000000' (thats 8 zeroes).
5. Create in your shared sandbox in the src directory an
admin/data_files/srequest directory and in this directory you need
to place your submit request form with the name of
your_unique_name_submit_request_form and an aliases file with the
possible functional areas, and in your case it will probably be
subfunctional areas, aliases.your_unique_name.
6. Now anyone that wants to use srequest against this shared sandbox
must mount this /usr/sde area on their workstations or maintain
a copy of the releasedata file in their local /usr/sde area.
|
| Date Of Receipt: 13-JUL-1994 17:56:39.84
From: FLAMBE::jmf "Joshua M. Friedman OSF/UNIX SDE"
To: [email protected], davidson@DEC:.zko.flambe
CC: odehelp@DEC:.zko.flambe
Subj: Re: Using srequest for shared sandbox submits
Sean/Andy, there's only on major problem I see with this, which I
belive we can accomodate:
> Get a local copy of the /usr/sde area
> ...
> edit /usr/sde/osf1/bin/share/data/releasedata file in your local /usr/sde
> ...
> anyone that wants to use srequest against this shared sandbox
> must mount this /usr/sde area on their workstations or maintain
> a copy of the releasedata file in their local /usr/sde area
This is unacceptable for any project which is also working on DEC OSF/1,
since they will need things we and UNX put in /usr/sde, including updates
to the releasedata file.
The only alternative, currently, is to allow external groups to give
us additions to submit into the releasedata file.
Perhaps you can add to the future development wishlist for srequest (or
maybe it's releaseinfo) an opportunity to consult a local releasedata
file in the submit tree first before looking in the central one.
Thanks......
-josh
---------
From davidson Wed Jul 13 16:06:40 1994
Delivery-Date: Wed, 13 Jul 94 16:06:43 -0400
Return-Path: davidson
Received: from sean.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM)
id AA19187; Wed, 13 Jul 1994 16:06:40 -0400
Received: by sean.zk3.dec.com; id AA24547; Wed, 13 Jul 1994 16:06:02 -0400
Date: Wed, 13 Jul 1994 16:06:02 -0400
From: D. Sean Davidson <davidson>
Message-Id: <[email protected]>
To: [email protected], [email protected]
Subject: Re: Using srequest for shared sandbox submits
Andy,
Yes this is possible and I needed to write it up anywere for others to use.
Here is what you need to do to make srequest work for your sandbox using a
alpha system as your server. Just replace mips_ULTRIX or vax_ULTRIX where
appropriate for your type of server.
This is a real quick pass at writing up what needs to be done so I may have
missed something. Let me know what problems you run into.
Right now the srequest utility is slanted to being used for only os and x11
submits, so for single type projects now you must pretend you are an os submit.
Sean
1. Get a local copy of the /usr/sde area from a USG backing tree server
on the system that will be the submit request server.
2. Determine what system will be your submit request server and edit
the /etc/inetd.conf and /etc/services adding the following lines:
/etc/inetd.conf
srequest stream tcp nowait root /usr/sde/osf1/bin/alpha_OSF1/srequest srequest
/etc/services
srequest 12001/tcp
and then do a 'kill -HUP' of the inetd process to cause it to reread
the inetd.conf file.
3. Determine a unique name for what you are working on and edit the
/usr/sde/osf1/bin/share/data/releasedata file in your local /usr/sde
area using a previous release as an example and add the following
subfields:
your_unique_name.submit_request_server: your_host_name_here
your_unique_name.submit_request_cc: none
your_unique_name.protected_files_alias: arw
your_unique_name.os_submit_tree: top_location_name_of_your_shared_sandbox
your_unique_name.x11_submit_tree: none
4. Create in your shared sandbox in the logs directory a srequest
directory and in this srequest directory create a file
your_unique_name.id with a single line of '00000000' (thats 8 zeroes).
5. Create in your shared sandbox in the src directory an
admin/data_files/srequest directory and in this directory you need
to place your submit request form with the name of
your_unique_name_submit_request_form and an aliases file with the
possible functional areas, and in your case it will probably be
subfunctional areas, aliases.your_unique_name.
6. Now anyone that wants to use srequest against this shared sandbox
must mount this /usr/sde area on their workstations or maintain
a copy of the releasedata file in their local /usr/sde area.
|