next message in archive
no next message in thread
previous message in archive
previous message in thread
Index of Subjects
<a href="../ind
Hi;
"
ACTION ITEMS:
- IP response letter edited to reflect this interim process
or disabled altogether (WHO'S RESPONSIBILITY?)
"
3 days ago I inquired about where this is stored and how to change it's
contents. Guess I have a "Official" Reason now. I'll look into this.
Mike
-----Original Message-----
From: editors-owner@chebucto.ns.ca
[mailto:editors-owner@chebucto.ns.ca]On Behalf Of Mark Rushton
Sent: Thursday, August 10, 2000 10:10 AM
To: Edward Dyer; CCN Editorial Collective
Cc: ccn-tech@chebucto.ns.ca; office@chebucto.ns.ca;
ljdeveau@chebucto.ns.ca
Subject: Re: Interim IP registration proposal
Everyone,
Thank-you all for quick and helpful feedback. It appears that this
will indeed work without too much difficulty.
One item I did forget to include, is the automated IP-response
letter, which no longer fits the situation and requires editing or
disabling for the interim.
To follow up with Ed and Chris' comments:
>> We have two options: Create identically-named entries in both
<SNIP>
>> (?), or the NameDB entry could be "NSCUBA-webmaster" to
>> differentiate but still create a relationship that is obvious.
<SNIP>
ED: if the eight-character limit does indeed apply, then may I
suggest we go with, to continue the example, "NSCUBA-1" as the
NameDB record entry.
>> The process:
>><SNIP>
>> 2. The office undertakes the steps that IPs in the past had to
>>perform, namely:
>> - enters the information in the online IP registration form
>> - creates a new user via the online registration form, using
>> the same name as the IP. (i.e., if NSCUBA is the new IP coming
>> aboard, then NSCUBA is entered as a new user also)
ED: The office creates the IP record via the online form, not
directly within the IPDB, thereby maintaining the original automated
processes that notify the EIC and generate the IP response letter.
The former is a Good Thing, the latter needs to be addressed *today*.
>There may be a slight delay in processing, as
>the "user" entry will probably need to be processed (by the cron
>scripts) before the id will be accepted by the IP registration
>process. This may not necessarily happen if the "user" account is
>created by the office admin process directly. Once this is tried by
>the office, it would be useful to report the results.
ANDREW: can you follow through on Ed's note above, reporting the results
ASAP ?
>Chris Majka reports that if the registration form is used, the
>automatic report goes to the ip-admin mailing list. If you create a
>new entry directly in the IPDB scripts, there is no report, so an
>e-mail to ip-admin would be helpful to keep the editors on track.
Right. So by going through the online IP registration form, this is
automated and we need not worry more about it. Good!
>> 4. The IPDB record is updated to reflect TRAINED, even though we do not
>> require this for the new organizational websites.
>
>Anyone who has editing privileges in the IPDB script can update
>this, as Chris reported.
I need to revisit this myself - I went into the IPDB last night at
the meeting to test whether any of the Editors with privileges could
indeed mark Trained, and for the life of me I couldn't get that kind
of access. Guess I need a refresher on the IPDB ;-)
>> 5. The Office deletes the PUBLIC_HTML directory from the "user"
>> account associated with the IPDB account (to clarify the FTP
>> destination directory, which is accessible via the "00ip" directory
>> in the NameDB user directory)
>
>(shhh ... remember that ftp is the only access we want them using
>for file management. Text access would result in that directory
>being automatically recreated if it were deleted. If we just want
>to stop it from being used, then a read-only Profile.html of zero
>bytes, and an index.html containing a redirect to the actual IP
>directory would be useful.) Note that there will also be a mail
>directory created if there is any sent mail or mail folders created
>on the system, e.g. by Webmail or IMAP4 access.)
ED: good points. How would this affect FTP? Since by using the IPDB
method, the organization will give their webmaster the NSCUBA-1
account name and password, which is the NameDB entry. When they FTP
to CCN and login, they will be automatically taken to that directory,
which holds the Public_HTML (which office will delete), and there
will be Mail directories (which we should NOT delete, if they are to
make use of WebMail).
SUGGESTION: Can we not inform them only of the FTP path that goes
through the directory tree, i.e.
FTP://chebucto.ns.ca/info/var/csuite/csuite1.0/CommunitySupport/NSCUBA/
rather than FTP://chebucto.ns.ca/~nscuba-1/
or whatever it is? (My recollection of directory paths should NOT be
taken as correct!)
That way they would never look at their "user" or NameDB-created
directory, but ONLY FTP directly to their directory within the
structured information tree.
>Note that the effective path seems to vary depending on which
>software is used for uploading - conventional ftp is straight
>forward of course, but some of the editing packages with "built in
>file transfer" require a customized setup which we should document.
Document? ;-) Wouldn't *that* be an innovative move on our part ;-)
GREAT! A workable solution (at least until the bugs pop up).
Can we get this done today?
ACTION ITEMS:
- IP response letter edited to reflect this interim process
or disabled altogether (WHO'S RESPONSIBILITY?)
- OFFICE does a test-run of this process to identify the
steps and real-world workability. PLEASE DOCUMENT
EACH STEP SO WE CAN PUBLISH IT.
- TECH/OFFICE: Ed thinks there should be no problem
with having identical names for the IPDB and NameDB
entry. They are, after all, two separate field names.
It would seem to be logical that identical names in each
database would make it easier to run a script or something
that reconciles the two in the future "merged" modified
IPDB. I would appreciate someone from TECH making the
call on whether to go with IDENTICAL names, or to go
with a NameDB entry that is distinguished with the
suffix "-1" (that's dash-one)
- SERVICES PAGE may NOT need to be modified, as this process
will be invisible to the organization coming aboard. We are
just doing more of the work on the Office side. Please do
keep in mind as we go through this anything that MIGHT
necessitate a change to the info on that page.
If anyone else has action items related to this matter, please let us
know ASAP. Otherwise - let's proceed and hope for the best.
This seems to be a good solution for the interim (and has all the
elements of a longer-term solution for the modified IPDB, with
certain steps to be eliminated and / or automated).
Now, go forth and issue the call to all web-less community
organizations: CCN Wants You!
ciao,
Mark
--
----------------------------------------
Mark Rushton, Editor
Community Support & Development
Chebucto Community Network (CCN)
<Mark@chebucto.ns.ca>
<http://www.chebucto.ns.ca>
----------------------------------------
next message in archive
no next message in thread
previous message in archive
previous message in thread
Index of Subjects