|
|
|
 |
Amalgam
def: a mixture of different elements |
|
Managing multiple Operating Systems under a single administrative umbrella
|
|
|
 05/17/05
|
Yesterday
I got all the parts working together. I concede it only does a
directory listing of /tmp, but it works on any server from the
admin client. I will have the new source posted today.
Grab it here: [download]
Screenshots: [screenshots] |
Amalgam,
the idea
behind the technology |
During my Master's work in which I majored in Network Security I learned a great deal more about security than I ever imagined. There are a near infinite number of hacks, software and techniques that help evil doers thwart network security and the forensics' that seek to find who, what, when and where. It was during the last couple of semesters that I starting thinking of ways to prevent these attacks. Since I'm an avid supported Linux I thought it might be possible to write an API that would, at minimal, prevent some of the misfortunes that befall
system administrators. Any admin will tell you it is quite impossible, regardless of how much you harden your systems, to prevent an internal attack. I went on to find a couple of statistics that show nearly 80% of backdoors and
root-kits attacks are installed by people who work within a company. Armed with this information I came to the conclusion that if you could keep people off of your machines, a great many mischievous opportunities could be prevented. As I began designing an API that could securely, remote administer a Linux server I had the epiphany that it should not stop at Linux. Windows, Mac, IBM, Solaris or any machine that supported
SUN's Java development kit should be capable of fitting the requirements. I went back to the drawing board to revise my thinking. With the second stage of design and analysis out of the way the software is slowing making it's way into the beta stage.
It is the intent of this software to allow a single system administrator to have the ability to simultaneously administer multiple servers of any flavor, at any location, so long as they meet these two requirements:
1) They must be capable of supporting the Java API of 1.4.2 of greater.
2) Have the ability to keep a persistent connection open to the repository.
Please note that this application is under development in
both design and software. Input and/or suggestions would be
greatly appreciated. |
| Purpose |
To bring any given number of OS's together under a
single administrative umbrella. This application will support any
OS that is Java compliant with network capability. |
| How does it work? |
Amalgam works in three tiers. 1) Client tier.
Machines that are to be managed by the Amalgam remote admin. 2)
Client Repository. Clients register with the repository and remain
in a 'listen' mode for incoming commands. The clients can be
configured to report errors or send reports based on pre-set
configurations. 3) Remote Admin. This client (not yet decided if
it is to be application based or web-based) will allow
administrators to view log files, see processor information,
stop/start applications, push or pull files (binaries .. etc).
Each of these features can be done on a single server, group or
global scale. |
| Basic Flow |
1) Install the client on any java enabled platform. Bring up
the config UI, or manually edit the amalgam.client.xml.
Enable/disable the modules that will be available for the
client. Modules can be written
externally and manually added to the xml config. The
config file is passed to the repository when it connects so it
knows what modules are available.
2) The Repository keeps a list of all client connections and
stores a list of each module that is available per client.
Client modules are not stored in the repository, they remain at
all times client side. [however...these
can be auto-configured to download new versions by making use of
the 'JAUUS' utility when a client initializes (Home)
(Download)]
3) The Remote Client connects to the repository and can view
all active client sessions and issue commands based on each
clients permissions settings.
Examples of Client Modules: push/pull file, start/stop service,
view statistics, restart system, send fax, print (remote).
Development will be quit lean in the beginning until I get all the
bugs worked out.
|
| Database |
I have stood by a single, open source, java
database for around 7 years now. This tiny database is fast,
effective and has not once failed me in any of my open source projects.
Hypersonic Database [hsqldb]
will be the engine which will control and maintain all of the
configuration settings and control information for each
client. The DDL has been developed in such a way as to allow
for -ANY- database to be used. Basic SQL will be taken advantage
to keep the application portable.
|
| Design Flow |
|
|
| |
Author
 |
I presently work as a Sr.
Application Architect for an ATM transaction processing
company. I received my B.S. in Computer Science and a
Masters in Information Technology specializing in Network
Security/Computer Forensics. Linux is my operating system of
choice and I work hard to keep on top of the new and exciting changes
that Java brings to the development table. I am a strong advocate
of the Open Source movement and remain very thankful to the SourceForge
community. |
|
| |
|
Copyright 2005 Steve Gee, All Rights Reserved
|
|
