HOME
In Our Opinion
Writing Code
How To
The Command Line
Hack It Yourself
Security Everything
Linux Distributions
Mr-Oss's Store
News Feeds
News
Links
Blog
HOME
Freedom vs. Control PDF Print E-mail
Written by Mr-Oss   
Sunday, 08 March 2009


Image Freedom vs. Control

The lack of Linux tools which can modify enterprise wide linux deployments is helping to slow it's adoption.  Linux philosophy is based around freedom from the control.  Honestly, that is one of the most appealing features about using Linux for your operating system.  Nobody has the ability to manipulate your system without your approval.  The control is in the hands of the user and the enterprise administer is left out in the cold.  The microsoft administration philosophy is control everything you can regarding the end users computing experience.  This ever present  mindset of needing to control users to extreme levels is somewhat rediculous to the savvy Linux user.  The lack of a mechanism which can be used to take things away from users makes Linux adoption a very non-attractive idea.  If however, there was a way for enterprises to control linux systems down to the level of rediculousness, Linux desktops would be much more appealing when seen through the eyes of the windows admin.  Unfortunately, the only way to convince some of these people that linux is ready for the enterprise would be the creation of something like the Linux Realm Director.  Here are 10 things that should be considered when developing the platform.

I was talking about this very subject with a fellow linux user friend of mine.  There isn't any easy way to control vast amounts of linux clients or provide profile based services to different users.

1.  linux needs a customized active directory replacement option which could control user authentication and information.  This would be similar to AD but in my mind would go beyond LDAP and have software application objects.  It would also have the ability to store other entities as objects such as printers and network shares.

2.   The linux directory would have the ability to deploy software packages based on user account.  For example with the user and the software packages registered into the linux directory administrators could then create a group and apply a software application to that profile.  For example john in accounting would be in the accountants group.  The accountants group contains software application objects for openoffice calc, scientific calculators, etc.  The users home directory is mounted based on the network share object contained within the accounting group.  The appropriate printers are also activated based on hardware object attributes.

3.   The software packages would be served to the network through the use of a centralized update server.  All other automated package repositories would be disabled and versions for the enterprise would be controlled on the deployment server.  The client machine would fetch this information upon user login and install/remove directory objects automatically based on profile attributes.

4.     an enterprise linux base image would be created that would contain the initial modifications to join the client machine to the enterprise realm.  This image would be available via pxe boot and could be automatically loaded over the network.  Once the image was deployed the rest of the machine configuration would take place upon the users first login.  Depending on objects for the user you would have entirely different installations.

5.    upon successful login the users machine would render up specific information about itself such as hostname user hardware info etc and send it back to the directory server.  After the initial check-in with the directory server it could then report periodically if needed.  The hardest part of this design would be keeping machine hostnames persistent across reimaging.  This could be controlled through dhcp automatic hostname assignment and tied back to the user account through the initial check-in with the directory server.  another option that might not be as practical would be pulling the computer name from the bios or based on mac address.

6.  The linux directory server would be easy to administer from both a graphical interface and the command line.  The directory server should also have the ability to present or unpresent objects based on timespans.  This would allow organizations to schedule hardware switchovers and other various tasks that would normally cause unneeded downtime to happen automatically behind the scenes.  The server should have the ability to send the client machines a message that would force them to check for updates.  The updates would then take effect at the same time for everyone based on what the server says.  The server should also stagger the sending of the message to update in advance so that all the clients don't create a ddos situation.  The server should possess the logic which would check what objects would be effected and only inform client machines that would be impacted directly.  

7.  The directory servers should store the information in some kind of database.  The directory servers should have the ability to scale seamlessly.  There should be an easy method for adding another directory server and replicating all the objects from within the enterprises realm.  It would update other peer directory servers of it's presence and also inform clients depending on how the high availiablity is setup to work.

8.  This system should only use free and opensource software and have the ability to adapt to use various package management systems such as debian and redhat.  It should also provide extended management outside the linux realm for mac and windows client authentication.

9.   The system should trackk all kinds of statistics for users, software usages, hardware performance etc.  This information gathering process should be handled mainly on the client and sent to the server periodically for analysis and archiving.  

10.   extensive checksum validations should run in the background periodically and would report any discrepancies on client machines when varified against the enterprise realms list of what it should be.  This would be stored as extended attributes for various programs and a seperate list for the base image.  Other features such as rkhunter, clamscan, & chkrootkit should have the ability to run behind the scenes.  These extended security features should have the ability to be enabled disabled from the directory server on a per machine or per user basis.


Theres a quick list of what linux needs for enterprise management.  With a mechanism like a enterprise realm server for linux then every aspect of software management can be controlled from a single location.  That is the real reason linux has not caught on as fast as it could have.  It is a difference in philosophy.  The linux user / administrator loves the freedom provided by the linux system.  The windows administration mindset is based on control which is the opposite of freedom.  The lack of a mechanism that allows an administrator to control everything that takes place on your linux desktop is very non-appealing.  Once there is a way for windows administrators to limit your freedom then adoption for linux systems will definitely skyrocket.

 

This article could go either way.  If it happens then linux adoption will grow exponentially.  on the other hand, if it happens, the freedom you enjoy when using linux will be removed.

 Image

This was also posted over at the Linux Journal  

-

MrOss 

 
< Prev   Next >