Call for LAMP Standardization -- Installations/User-Group Admin

[Google Mike]

You know, while working on my moonlight corporation's LAMP project at
home this weekend, I couldn't help but wonder if people writing similar
projects are solving similar problems with having to complete the
project by building an installer and building the user/group
administration piece of it.

The thought came to me that it would be great if LAMP developers,
whether they used MySQL or PostgreSQL, could just simply write the
project to a certain specification. Then, they could run the project
through a wizard and it would automatically generate the user/group
administration piece of it as well as build the install.

I mean, with every app I build, I have a handful of tables that almost
look the same, storing usernames and other properties about the users
-- including fullname, shadow password, and default group, a table for
groups, a table for user memberships in those groups, and a table for
which group can route work to which other group.

For things that are kind of outside the box on the user/group
specification, one could write a generic reference table editor (a
table that is short and is commonly linked by foreign keys from other
tables) and then customize with a short list of business rules.

All of this could likely be standardized someday. It would be a huge
boost to all of us LAMP developers.

Imagine a world where we just write the app, run it through this
wizard, and then all the operations analyst has to do that installs
this app is run the short installer, then connect to a common interface
to administer it and set it up for the company departments.

The only thing I caution about is making this too heavy and too steep
on requirements.

[Kenneth Downs]

Re: Call for LAMP Standardization -- Installations/User-Group Admin

Google Mike wrote:
[color=blue]
> You know, while working on my moonlight corporation's LAMP project at
> home this weekend, I couldn't help but wonder if people writing similar
> projects are solving similar problems with having to complete the
> project by building an installer and building the user/group
> administration piece of it.[/color]

Mike, there is a story, I know not if it is true, that whenever a kid sent a
letter to NASA inquiring about the space program, they would send back a
coolly-worded reply warning of all of the dangers and problems, so as not
to glamourize it overmuch. The story goes the Werner Von Braun took one of
these form letters one time and scribbled at the bottom, "We are going to
the moon. Come with us!"

When I read your post I thought, "We are going to the moon! Come with us!"

Why such a dramatic reply? Well it so happens that tonight at a PHP users
group is the public debut of my product, 1 year in the making. Read about
it here:

http://www.secdat.com/dev

....and tell me if you want to come along.

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )

[Google Mike]

Re: Call for LAMP Standardization -- Installations/User-Group Admin

<snip>
Well it so happens that tonight at a PHP users
group is the public debut of my product, 1 year in the making. Read
about
it here:

http://www.secdat.com/dev

....and tell me if you want to come along.
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )
</snip>

I guess I'm confused when I visited the site you mentioned. Got a
shorter pitch? You do have my interest, however.

[Google Mike]

Re: Call for LAMP Standardization -- Installations/User-Group Admin

BTW, Ken, your thinking and mine are pretty close when, on your site,
you talked about PHP vs. Java and MySQL vs. PostgreSQL. Java, to me,
was frustrating and everyone had their own version of it and you had to
keep rewriting apps if you moved to another version. Also, the Java
devs in forums would lecture me on the minutae of OOP and I just wanted
to get my work done. Many Java devs I work with sit in countless
meetings never getting anywhere. Also, for me, feature by feature,
PostgreSQL was better in more ways than MySQL, so I moved to LAPP
instead. About 10 years ago when I first looked at PHP, I didn't want
to even touch it. But now, holy cow, it's way cool. And with Windows
getting more and more insecure and frustrating to use, and more and
more frustrating to write software for, and with orgs like Red Hat and
Ubuntu making a super-slick Linux, it's no wonder I made the switch.

[Kenneth Downs]

Re: Call for LAMP Standardization -- Installations/User-Group Admin

Google Mike wrote:
[color=blue]
> <snip>
> Well it so happens that tonight at a PHP users
> group is the public debut of my product, 1 year in the making. Read
> about
> it here:
> http://www.secdat.com/dev
> ...and tell me if you want to come along.
> Kenneth Downs
> Secure Data Software, Inc.
> (Ken)nneth@(Sec )ure(Dat)a(.com )
> </snip>
>
> I guess I'm confused when I visited the site you mentioned. Got a
> shorter pitch? You do have my interest, however.[/color]

I'm guessing from your 2nd post that you've since read through it some more,
but here is the elevator pitch:

An entire application, all of it, can be described entirely in terms of what
must go into the database. That description (of the database) can be
turned into a purely descriptive configuration file. The spec for the
config file is this link:

http://www.secdat.com/dev/androspec.html

That descriptive file is fed into a builder that creates the database,
including tables, groups, constraints and automations. The builder also
generates client code.

So what attracted me to your OP was your suggestion for the standardization
of installs and user/group admin. We go way beyond groups into tables,
columns, formulas, and anything in fact required to specify the app. The
builder then makes the app for you. Without claiming it is any kind of
standard, it is a definitely an application configurator available now.


--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )

[Colin McKinnon]

Re: Call for LAMP Standardization -- Installations/User-Group Admin

Google Mike wrote:
[color=blue]
>
> The thought came to me that it would be great if LAMP developers,
> whether they used MySQL or PostgreSQL, could just simply write the
> project to a certain specification. Then, they could run the project
> through a wizard and it would automatically generate the user/group
> administration piece of it as well as build the install.
>[/color]

Hmmm.

I don't like to be discouraging but...

Look at what's happenning with Java. There are so many specifications,
protocols and APIs that it's quite tricky to install an off-the-shelf
application onto an existing system. Compare that with PHP where there is a
wealth of third-party application which will happily live side-by-side.

I suppose it *could* be because despite its aspirations Java does not adhere
well to standards.
[color=blue]
> I mean, with every app I build, I have a handful of tables that almost
> look the same, storing usernames and other properties about the users
> -- including fullname, shadow password, and default group, a table for
> groups, a table for user memberships in those groups, and a table for
> which group can route work to which other group.
>[/color]

<snip>
OK, so what if I want to use an LDAP system for authentication? Or PAM? Or
let the webserver handle it? Leaving aside the issue of authentication,
what about access control? RBAC? ACL?

In a perfect world, I could download a blog package, a wiki package and plug
them into my PHP application, using the same authentication and template
system I already installed. And I think it is a worthwhile goal. But this
kind of integration requires a specification of interfaces.

For PfP Studio (a visual PHP programming tool I am developing - see
http://pfp-studio.sourceforge.net) I chose to allow the user to specify
their own function for implementing authentication and access control which
gives great flexibility. OTOH it has proved rather difficult to incorporate
a PfP form with an off-the-shelf template system.
[color=blue]
> For things that are kind of outside the box on the user/group
> specification, one could write a generic reference table editor (a
> table that is short and is commonly linked by foreign keys from other
> tables)[/color]

Yes there are tools to do this - but IME none are really suitable for
exposing applications to end users because they don't allow much scope for
development (PHPPeanuts comes close though).
[color=blue]
> and then customize with a short list of business rules.
>[/color]
Hence PfP Studio. Acutally a different approach might be to extend the
PHPPeanuts MVC type approach but tie the business rules into the data
supplier.
[color=blue]
>
> The only thing I caution about is making this too heavy and too steep
> on requirements.[/color]

I think other people have tried. Horde comes quite close - but as you'll see
- it's not easy to balance functionality with flexibility with simplicity.

C.

[Google Mike]

Re: Call for LAMP Standardization -- Installations/User-Group Admin

<snip>
In a perfect world, I could download a blog package, a wiki package and
plug
them into my PHP application, using the same authentication and
template
system I already installed. And I think it is a worthwhile goal. But
this
kind of integration requires a specification of interfaces.
-Colin McKinnon
</snip>

I agree with your judgment. I believe in the KISS method. If some
SourceForge community org could standardize on a simple PostgreSQL (as
well as MySQL) database format for users, groups, group memberships,
and group routing rights, it's a first start. Sure, the dev that takes
this may want to migrate their app to LDAP, RACF, NT-PAM, or whatever,
but at least with a simple table design they can migrate easily because
they can understand what we're doing.

Second, if we could standardize on an installer that works great at
command line, and another that works great in a browser GUI (because
you never know if they have GNOME or KDE and don't want to raise the
requirements too high), giving the solution user/customer the ability
to choose either install option, and yet permit someone to customize
the installer a little for this or that nuance, then I think that would
be another boost to LAMP/LAPP development, worldwide.

Third, if we could create a web-based admin interface that includes an
application's reference table* editor and editor for users, groups,
group memberships, and group routing rights, then that would be another
boost. Sure, the interface not fit 100%, but if it's kept simple, then
others can customize it easily.

* reference table = A table that is small in nature, usually containing
just a few columns and a few rows, and which is often referenced via
foreign keys from other, far larger tables. A good example could be a
list of status indicators with their primary keys and their labels, or
a list of manufacturing tool options.

Although I think Mr. Down's idea is great for a certain kind of
developer, as well as someone used to FoxPro (which he appears to have
been), I'm trying to think far more KISS here.

[Google Mike]

Re: Call for LAMP Standardization -- Installations/User-Group Admin

Here's someone who was thinking along the same lines as me:

http://thebrainroom.com/opensource/php/installer.php

Although I was only focused on Linux distros. (I have fantasies where I
pretend that Microsoft does not exist.)

[Kenneth Downs]

Re: Call for LAMP Standardization -- Installations/User-Group Admin

Google Mike wrote:
[color=blue]
> Here's someone who was thinking along the same lines as me:
>
> http://thebrainroom.com/opensource/php/installer.php
>
> Although I was only focused on Linux distros. (I have fantasies where I
> pretend that Microsoft does not exist.)[/color]

Yeah, he's only hitting the issues of installation, which is fine, but I've
already defined most of what he states is in planning.

Also, I'm going beyond "mere" installation into kind of a peer-to-peer model
of application sharing across Andromeda nodes.

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )

[Google Mike]

Re: Call for LAMP Standardization -- Installations/User-Group Admin

Okay, for me, the idea has shored up in my mind. My idea of LAMP/LAPP
Standardization comes in the form of a template app and template
installer that follow KISS principles and which can work on most Linux
systems. (Other ports can be made after that.)

=== TEMPLATE APP ===
1. Think extremely simplistic here. The less is better because so many
people have different ways of doing things and sometimes don't want to
read a book in order to get started.

2. The template app comes with a simplistic (but slightly attractive)
login page that, if one authenticates properly, takes them to a blank
"main" page. The authentication is checked against the user, group, and
group membership tables.

3. The template app comes with either MySQL and equivalent PostgreSQL
tables for users, groups, and members (group memberships). It contains
the most basic things one would think of using. It also uses shadow
passwords, rather than real passwords, in the users table.

4. The template app comes with admin pages that an admin can pull up to
administer users, groups, and members. It also comes with a table
editor to edit any record in any other kind of table, and can be
changed so that foreign keys pull what they lookup (in a listbox)
rather than pulling the foreign key's ID code.

5. It's up to the developer to flesh this out into an application.

=== TEMPLATE INSTALLER ===
1. The operations analyst downloads your PHP app as a tar.gz file,
expands it, then doubleclicks a "setup" Bash script on Linux.

2. It's browser-based but with a twist -- because we don't know if
Apache is running or not, it uses its own "web server" temporarily. The
operations analyst applying the final PHP app in production
doubleclicks a Bash script called "setup" that brings up a micro "web
server" that also displays a message in a console window about how to
connect to install the application. (BTW, I got the idea for this from
a BMC Software install for Linux that I had to do, even though I'm not
a fan of anything (besides the install) that is made by that company.)

3. The operations analyst reads the console window and sees that he
must connect his browser to something like http://127.0.0.1:60840. Once
there, he sees a friendly GUI that checks out the system to see the
following things. BTW, the community group should use a really slick
GUI team to draw this up, such as the folks on the GNOME icon teams.

- If Apache is installed and is running.
- If MySQL or PostgreSQL is installed and is running.
- If PHP is installed.
- If PHP-mysql or PHP-pgsql mods are installed.
- If the current account has the permissions to install a new MySQL or
PostgreSQL database.
- Anything custom can be checked here, including install of sendmail,
Mambo, PEAR, versions, etc.

It *does not* fix these problems because there are so many different
distros out there. Instead, if just reports the problems and lets the
operations analyst resolve them.

4. The install creates a new local Linux account that will be used by
the PHP pages to authenticate to the database, along with password. It
prompts you for the password and recommends that you change this every
so many days.

5. The install copies out the PHP pages and does the proper chmod and
chown on them as necessary.

6. The install creates the database and tables necessary.

7. The install performs a short test of read/write to the admin tables.

8. The install sends the operations analyst to the admin pages to
create new users, groups, and group memberships, and instructs the
analyst to bookmark this page. It also indicates what the default URL
is for the application, which should also be bookmarked.

9. The end user can then connect to the URL for the application and use
it.


The grand benefit of all this? Developers often write the app and then
go back and write the admin piece of it and the installer. With this,
they can customize the super-easy templates and most of the stuff they
have avoided until last has already been done for them.


Now I'll be terribly shocked to find out that no one would care to use
anything like this and want to write all this themselves.

[Kenneth Downs]

Re: Call for LAMP Standardization -- Installations/User-Group Admin

Google Mike wrote:
[color=blue]
> Okay, for me, the idea has shored up in my mind. My idea of LAMP/LAPP
> Standardization comes in the form of a template app and template
> installer that follow KISS principles and which can work on most Linux
> systems. (Other ports can be made after that.)
>
> === TEMPLATE APP ===
> 1. Think extremely simplistic here. The less is better because so many
> people have different ways of doing things and sometimes don't want to
> read a book in order to get started.[/color]

In my system it's called the "node manager"
[color=blue]
>
> 2. The template app comes with a simplistic (but slightly attractive)
> login page that, if one authenticates properly, takes them to a blank
> "main" page. The authentication is checked against the user, group, and
> group membership tables.[/color]

done.
[color=blue]
>
> 3. The template app comes with either MySQL and equivalent PostgreSQL
> tables for users, groups, and members (group memberships). It contains
> the most basic things one would think of using. It also uses shadow
> passwords, rather than real passwords, in the users table.[/color]

done. Though actually we use db security, not *nix security.
[color=blue]
>
> 4. The template app comes with admin pages that an admin can pull up to
> administer users, groups, and members. It also comes with a table
> editor to edit any record in any other kind of table, and can be
> changed so that foreign keys pull what they lookup (in a listbox)
> rather than pulling the foreign key's ID code.
>[/color]

done.
[color=blue]
> 5. It's up to the developer to flesh this out into an application.[/color]

Well, really this and any number of other apps. The spec for specifying
those apps is here:

http://www.secdat.com/dev/androspec.html

[color=blue]
>
> === TEMPLATE INSTALLER ===
> 1. The operations analyst downloads your PHP app as a tar.gz file,
> expands it, then doubleclicks a "setup" Bash script on Linux.
>
> 2. It's browser-based but with a twist -- because we don't know if
> Apache is running or not, it uses its own "web server" temporarily. The
> operations analyst applying the final PHP app in production
> doubleclicks a Bash script called "setup" that brings up a micro "web
> server" that also displays a message in a console window about how to
> connect to install the application. (BTW, I got the idea for this from
> a BMC Software install for Linux that I had to do, even though I'm not
> a fan of anything (besides the install) that is made by that company.)[/color]

But wait. Before you do any of this you have to get the installer
installed. If you can get the installer installed then you have solved all
of these issues. This happens to be what I am workin on this week.
[color=blue]
>
> 3. The operations analyst reads the console window and sees that he
> must connect his browser to something like http://127.0.0.1:60840. Once
> there, he sees a friendly GUI that checks out the system to see the
> following things. BTW, the community group should use a really slick
> GUI team to draw this up, such as the folks on the GNOME icon teams.
>
> - If Apache is installed and is running.
> - If MySQL or PostgreSQL is installed and is running.
> - If PHP is installed.
> - If PHP-mysql or PHP-pgsql mods are installed.
> - If the current account has the permissions to install a new MySQL or
> PostgreSQL database.
> - Anything custom can be checked here, including install of sendmail,
> Mambo, PEAR, versions, etc.[/color]

This stuff is a bitch.
[color=blue]
>
> It *does not* fix these problems because there are so many different
> distros out there. Instead, if just reports the problems and lets the
> operations analyst resolve them.[/color]

Yup. Kind of a bummer.
[color=blue]
>
> 4. The install creates a new local Linux account that will be used by
> the PHP pages to authenticate to the database, along with password. It
> prompts you for the password and recommends that you change this every
> so many days.[/color]

Again, security is tied to a database, at least in my world.
[color=blue]
>
> 5. The install copies out the PHP pages and does the proper chmod and
> chown on them as necessary.[/color]

Everyone will have different directory schemes.
[color=blue]
>
> 6. The install creates the database and tables necessary.[/color]

Not so easy. Took me a few years to completely work this out.
[color=blue]
>
> 7. The install performs a short test of read/write to the admin tables.[/color]

Nope, testing is a completely different operation.
[color=blue]
>
> 8. The install sends the operations analyst to the admin pages to
> create new users, groups, and group memberships, and instructs the
> analyst to bookmark this page. It also indicates what the default URL
> is for the application, which should also be bookmarked.
>
> 9. The end user can then connect to the URL for the application and use
> it.
>
>
> The grand benefit of all this? Developers often write the app and then
> go back and write the admin piece of it and the installer. With this,
> they can customize the super-easy templates and most of the stuff they
> have avoided until last has already been done for them.
>
>
> Now I'll be terribly shocked to find out that no one would care to use
> anything like this and want to write all this themselves.[/color]

Most people don't try to tackle so much of the problem in one shot, that's
why it's not out there.


--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )

[Google Mike]

Re: Call for LAMP Standardization -- Installations/User-Group Admin

<snip>[color=blue]
> 3. The template app comes with either MySQL and equivalent PostgreSQL
> tables for users, groups, and members (group memberships). It contains
> the most basic things one would think of using. It also uses shadow
> passwords, rather than real passwords, in the users table.[/color]

Done. Though actually we use db security, not *nix security....

....[color=blue]
> 4. The install creates a new local Linux account that will be used by
> the PHP pages to authenticate to the database, along with password. It
> prompts you for the password and recommends that you change this every
> so many days.[/color]

Again, security is tied to a database, at least in my world.
- Kenneth Downs
</snip>

Uh, yeah, you are right. I do prefer DB security -- no sense giving
people an account to login to the server that way. So the users and
groups thing -- that's in the tables in the db.

However, that aside, the PHP pages have to have something to pass to
pg_connect(), and often big corporations don't like the db account of
"root" or "postgres" to use that. So, instead, one has to create an
account (often this account is named something similar to the app name)
in the database.

[Kenneth Downs]

Re: Call for LAMP Standardization -- Installations/User-Group Admin

Google Mike wrote:
[color=blue]
> <snip>[color=green]
>> 3. The template app comes with either MySQL and equivalent PostgreSQL
>> tables for users, groups, and members (group memberships). It contains
>> the most basic things one would think of using. It also uses shadow
>> passwords, rather than real passwords, in the users table.[/color]
>
> Done. Though actually we use db security, not *nix security....
>
> ...[color=green]
>> 4. The install creates a new local Linux account that will be used by
>> the PHP pages to authenticate to the database, along with password. It
>> prompts you for the password and recommends that you change this every
>> so many days.[/color]
>
> Again, security is tied to a database, at least in my world.
> - Kenneth Downs
> </snip>
>
> Uh, yeah, you are right. I do prefer DB security -- no sense giving
> people an account to login to the server that way. So the users and
> groups thing -- that's in the tables in the db.
>
> However, that aside, the PHP pages have to have something to pass to
> pg_connect(), and often big corporations don't like the db account of
> "root" or "postgres" to use that. So, instead, one has to create an
> account (often this account is named something similar to the app name)
> in the database.[/color]

Which is as it should be. The database is full of groups that have certain
security rights, and you make a person real by creating their account and
putting them into their groups.

The anti-technique of having all connections going through a bogus account
leads to no end of trouble, not the least of which is the complete lack of
ability to use real server-side security, and the horrible dangers
associated with the fact that this bogus account must carry the highest
possible priveleges.

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )