Roster: some details on manipulating accounts

[jim@mercury.laney.edu]

Hi Bruno...

> Date:    Sun, 06 Jun 1999 16:28:19 PDT
> To:      seul-edu@seul.org
> From:    Bruno Vernier <vernier@vc.bc.ca>
> Subject: Re: Roster status is unchanged (Re: Updates and summer efforts)
> 
> On Fri, Jun 04, 1999 at 08:37:17PM -0700, jim@mercury.laney.edu wrote:
> 
> > does anyone know Novell4's UIMPORT command well? I need to be able to add
> > accounts, add groups, add student accounts to groups, remove student accounts
> > from groups, remove entire accounts and remove groups, by creating a "batch"
> > file of them, walking the file to the server and running the appropriate 
> > umport command(s). There's about 6 or 7 different operations I need to be 
> > able to do. Any help here?
> 
> The ncpfs package contains several tools to extract or update information to 
> netware's bindary directly from linux (requires the ipx module). Would this be 
> appropriate here?
> 
> note: I know it works for netware v3.1x but have no experience with v4.x

Hi Bruno :) 

Umm, philosophically, my opinion is that it's good to let the server add the 
accounts... An intrusion such as any direct access to internal server files
is bad: unportable, no support, hard to maintain, and tries to access 
undocumented data structures (you can replace undocumented with internal or 
proprietary here).

You should get the source and take a look at what I do. To summarize, I write
text files with commands the individual server knows which cause the server
to do whatever modification of the accounts necessary. This implies a big 
wide separation between my scripts and the internal behavior of the servers,
which is a good thing: Roster does not put its fingers inside the server.

Here's something of a play-by-play: if you get roster-0.7.0.5.tar.gz and 
untar it, cd into roster-0.7.0.5 and then into Roster.

You will see Server.pm, which interfaces my roster stuff to the ServerTypes.
You will also see ServerType.pm which is the parent class of all the classes
in the directory ServerTypes.

If you take a look at Server.pm, you will see that the methods simply re-
arrange the parameters a bit and forward them along to methods in 
ServerType. (an important detail: this interface decodes everything needed
in the main database record, and forwards information in that record without
forwarding the record object instance itself, so that NO ServerType NEEDS ANY 
KNOWLEDGE OF THAT RECORD. Because of that, all the server types (and their 
parent, ServerType) can be used in other projects.)

You will see when you look in the individual ServerType perl modules that
they can: (1) open one or more files, (2) write commands into the files that
manipulate accounts and (3) close the files opened in (1). You will find the
ServerTypes in Roster/ServerTypes. Some examples are NT.pm, Novell3xx.pm.

Once the files are closed, the idea is that you would walk the files over
to the server and ask the server to interpret them.

I bring this up at this level of detail, because one of the major efforts for 
the project is to create new types, and I want it to be easy for anyone to 
create and contribute them. I am afraid that a server type would not be
legal to distribute if it exposes proprietary details.

Now... Here's another request for the group: Does anyone know of a text file
format for the manipulation of accounts on an AppleShare IP server? Maybe
some combination of AppleScript with whatever admin tool for AppleShare?
Ugh, that sounds slow...

-Jim