Thread: Re: [PMVAdmin-devel] Progress update

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

My feeling on the function thing is still the same; rather than have all of
these piles of arbitrarily named functions for each different type of actio=
n
the management console creates, why not just provide a single function like
"PMVAdmin_Auto" which is created by the management console and stores all o=
f
the management console created code. You seem to be very much concerntratin=
g
on certain options like the ability to disable the managment console
generate script, but are missing the true point of what makes the program
more flexible and elegant; like the ease to add new features, or how best t=
o
handle the UI->login script conversion.

Inside this function you would put all of the management console code for
the "object" (i.e. user)

<function name=3D"PMVAdmin_Auto">
        //"Settings" (better term than Policies; more generic and
applicable)
        ...

        //Network file resources (or a nicer term)
        ...

        //Network printers
        ...

        //Etcetera
</function>

This is far more tidy than putting everything into separate functions in th=
e
script (and then trying to indicate to the management console to look in
that function).

The order is not important; but it is no harder for the management console
to put stuff into a sensible order, and separate it with linebreaks and
comments to improve the readability of the scripts.

Reading it back into the managment console is, if anything; easier. You
parse one function in the script:
if (line_is_setting) {
        //This function goes away and adds a setting given the name, and
extracts
        //necessary meta data if possible/implemented
        add_setting (setting_name);
} else if (line_is_network_file) {
        //Same as above
        add_network_file (connection_name);
} ... else if (line_is_sobject) {
        //Add the script object, lookup the object's metadata
        //An script object is pretty much a reusable function, in a script
        //library that is accessible to all scripts.
        add_sobject (sobject_name);
}

Just as an example.

I introduced an important idea there: script libraries. Script libraries ar=
e
a point which David has seemingly wanted to trim from my original designs
for some reason or another, which I am yet to be presented with.

Basically, they encourage reusable scripts by creating an abstract way to
reference external scripts. Obvious candidates to be put into script
libraries are lockdown settings for the various desktop environments that
PMVAdmin supports (i.e. a library for Windows Lockdown settings which
contains functions to add and remove policies without directly putting the
code into the login script); and user made script libraries (such as a
library containing functions to map each of the printers on the site. This
makes it a lot harder to screw up your setup, and a lot easier to code
PMVAdmin. If you say, changed the printer, rather than go through and
re-edit *every* single script that uses it, you could change it once in the
code library, and then all users/groups/etc that reference the code has now
been changed.

The same thing can be done for mapped file connections. It is really f'ing
stupid to hard code all of the mapped drives (etc) for every
user/group/whatever that uses them. Most of the time, you have a collection
of common drive mappings, or drive mappings that follow a consistent patter=
n
(i.e. P to \\server\(username_here)$ for mapping personal directories). It
is stupid, utterly stupid to have every user contain their own code to map
their personal directories; if for some reason (e.g hard disk failure) the
personal directories had to be moved onto a different server, then *EVERY*
user, group, etc would need to be changed. With a script library, you just
replace the one function call, and magic, everyone's home directory is used=
.

I don't know what rock you have just crawled out from under; but don't get
the impression that libraries are my idea; they have been around for years
and are used extensively in computers. Qt is a library; it does a similar
thing to putting login scripts into script libraries; the operating system
can be changed, without the code itself being changed; likewise, the librar=
y
can be changed, without programs that use it having to be changed.

If a bug in Qt (or GTK, or gdi.dll or crypto.dll (i.e left debugging symbol=
s
in and someone finds your secret NSA backdoors :)) is deployed, then
applications that dynamically link to it (i.e. just reference the Qt
function calls) can be easily fixed by patching the library; one change, on=
e
recompile. Programs which statically link the library are still affected.
Static linking is when the library code is put into the program - i.e. hard
coded - by the compiler(linker). Hard coding has the benefit of letting dum=
b
people/systems work on your program without having to worry about the
library; but when it comes time to make changes to the system the whole
thing falls over.

The exact same thing applies to PMVAdmin. David: remember how long the setu=
p
account was broken at HHS because of problems creating the login script in
PSE?** Those kind of problems can be avoided if you can avoid trying to mak=
e
another "me-too" program like all of the other ones available. Just because
every other program forces everything to be nice and hard to adjust, doesn'=
t
mean that it is a likable feature and that PMVAdmin should try to replicate
it.

**For people who are not David; when we were employed by Hillcrest High
School a few years ago, the setup account we used for doing some basic admi=
n
tasks was broken for a very long time, due to a confusing system for settin=
g
up login scripts and mapped drives and groups.

Chance of ever wanting to disable the management console code (manually) fo=
r
a login script object? Slim to nill. A "user" that has a custom script that
needs to override the management console generated code is ridiculous; why
waste time cluttering the program with these silly options, all the while
ignoring true problems like "What if I want to run the management console
off an unmapped location (like I would 90% of the time)?"

Anyhow, this is not really intended as a flame...
Just a lump of opinionated e-rag.

Sam Douglas.
The other person who used to be working on PMVAdmin until he undertook a fa=
r
too ambitious project that nobody really wants to help him on, because he i=
s
the only one who knows what he is doing; and is in some respects happy to d=
o
it alone, because some people just have funny ideas about things that
conflict with his own funny ideas.

On 4/17/06, David Goodwin <dgs...@us...> wrote:
> As this is the very first mailing list post I suppose I should quickly
> introduce myself for anyone else who may read this in the archives or is
> secretly listening in on my emails. I am David Goodwin, the project
> administrator, lead developer, etc, on the PMVAdmin project. I am
currently
> doing a BCMS (Computing and Mathematical Sciences) degree at the
university
> of Waikato, New Zealand. As a result development tends to slow down when =
I
> have tests or assignments to do.
>
> Now for the first publicly available progress update on the PMVAdmin
> project.
>
> PMVAdmin Management Console 1.0
>  Currently work is being done to try and get the PMVAdmin Management
Console
> to a state where it could be considered an alpha version. At that point
> binaries and source will be made available to the public.
> It is possible that version 1.0 will never see a stable release because
> development on the more flexible version 2.0 will begin as soon as versio=
n
> 1.0 is in an alpha state. At this point both versions will be developed
> simultaneously. Bugs will be fixed in 1.0 and new features, etc, will be
> added in 2.0.
>
> Currently version 1.0 is very non-expandable. There is a lot of hard code=
d
> stuff. This will change in version 2.0 which will provide a plugin
> architecture. PMVAdmin Management Console 2.0 will be used in PMVAdmin 2.=
0
> and possibly PMVAdmin 1.0.
>
> The Management Console version 1.0 is currently capable of the following
> things:
>
> Loading/Saving configuration data
> Loading/saving user files
> Loading/saving group files
> Loading/saving workstation files
> Loading/saving zone filesSupport for workstations/zones/groups is fairly
> small at this stage but will be expanded quite a lot over the next month
or
> two depending on how much time I have available. The Management Console
> currently has no knowledge of the scripts that can be embedded into those
> files - this will be added fairly soon.
>
> The Management Console is also incapable of being run off a network
location
> as QFile does not seem to be capable of accessing files addressed using a
> UNC pathname. This means that the management console must be run off a
> mapped network drive or off local storage. According to Sam cstdio's fope=
n
> functions are capable of working with UNC pathnames under windows so this
> has been used in the client. As the management console makes use of Qts
QDir
> classes which probably don't support such UNC paths making use of fopen
> probably wouldn't help the management console run from a network path.
>
> At this stage the management console makes no use of the Win32 API. This
> means that, in theory, it should compile and run fine on Linux.
>
>  PMVAdmin Login Engine 1.0
> About two days ago I started work on the first version of the login
engine.
> This program processes login scripts, applies settings and does other suc=
h
> stuff. After a few hours fighting with the Win32 API the software is now
> capable of detecting the currently logged in user and also the workstatio=
n
> name. I was up until 2AM this morning working on the scripting support an=
d
> the login engine is now capable of the following:
>
> Loading the user file for the logged in user
> Loading the workstation file for the current workstation
> Loading all groups that the user is a member of
> Loading all zones that the workstation is a member of
> Checking if any of the group or zone accounts are disabled and denying th=
e
> user login access if any are found to be disabled
> Checking if the user or workstation is disabled and denying the user logi=
n
> access if one of them are found to be disabled
> Allowing the user login access automatically if the admin flag is set
> regardless of if any of the accounts are set to disabled. This prevents
> administrators from accidentally locking themselves out.As far as
scripting
> support goes, the following has been implemented and is functional:
>
> Automatic processing of management console controlled functions if auto
> attribute is set to true
> Automatic processing of main function
> same-file function calling (calling of other functions within the current
> file) The following scripting commands have been implemented:
>
> call
> print
> msgbox
> clear
> showstat
> hidestatan exit command has also been partially implemented but it doesn'=
t
> work at this stage for some reason.
>
> At this stage there are still a number of major script commands that have
> not yet been implemented. These will probably be implemented sometime ove=
r
> the next week or two.
>
> If Sam is correct about fopen working with UNC pathnames under windows
then
> the login engine should be capable of running off a network location
without
> any problems. I have not yet tested this however as my Pentium 3 isn't
even
> getting as far as POST when turned on and I haven't gotten around to
fixing
> it yet (the CPU has probably just fallen out again).
>
> As I implement parts of the scripting support I am documenting it. I have
> attached a copy of the current documentation in PDF format which you can
> look at for more information on what the currently implemented commands d=
o
> provided that sourceforge doesn't filter it out. This documentation is
> purely reference for use while implementing stuff. The format will
probably
> remain in any final version but the text on functions and a few other bit=
s
> will likely be rewritten.
>
> On the note of functions, they don't support parameters and they don't
> support returning data. This is currently because the actual scripting
> language doesn't support variables and in version 1.0 it probably never
will
> as it would make it somewhat more complicated to do using nothing more
than
> an XML parser.
>
> PMVAdmin version 2.0 might provide support for a more advanced scripting
> language for those who want it. This scripting language would use QSA
> (QtScript for Applications) which I think supports functions, variables,
> etc. If such scripting support were to be implemented in the future the
old
> one would probably remain for those who just want something simple.
>
> Anyhow, that is about all the progress I can be bothered commenting on. A=
t
> this rate i might have an alpha version ready within a month or two so I
> will probably provide some more progress updates sometime in the near
future
> - probably once I have given the management console some form of support
for
> the scripts.
>
> Now, as usual with long emails which I haven't planned before this email
> might be a bit difficult to understand and might randomly change subjects
> without warning in some places. If anything needs clarification then feel
> free to email me on or off list. If flaming could be avoided that would b=
e
> much appreciated.
>
> --
> -David Goodwin
> Email: dgs...@us...
>

Thread: Re: [PMVAdmin-devel] Progress update

pmsec-devel