|
|
Posted by Kenneth Downs on 06/30/05 01:16
Google Mike wrote:
> 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.
In my system it's called the "node manager"
>
> 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.
done.
>
> 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.
done. Though actually we use db security, not *nix security.
>
> 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.
>
done.
> 5. It's up to the developer to flesh this out into an application.
Well, really this and any number of other apps. The spec for specifying
those apps is here:
http://www.secdat.com/dev/androspec.html
>
> === 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.)
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.
>
> 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.
This stuff is a bitch.
>
> 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.
Yup. Kind of a bummer.
>
> 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.
Again, security is tied to a database, at least in my world.
>
> 5. The install copies out the PHP pages and does the proper chmod and
> chown on them as necessary.
Everyone will have different directory schemes.
>
> 6. The install creates the database and tables necessary.
Not so easy. Took me a few years to completely work this out.
>
> 7. The install performs a short test of read/write to the admin tables.
Nope, testing is a completely different operation.
>
> 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.
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)
Navigation:
[Reply to this message]
|