Mailinglist Archive: opensuse-features (146 mails)

< Previous Next >
[openFATE 313112] Enterprise and Network Standard Desktops and Authority
Feature changed by: Scott Couston (zczc2311)
Feature #313112, revision 6
Title: Enterprise and Network Standard Desktops and Authority

openSUSE Distribution: Unconfirmed
Priority
Requester: Important

Requested by: Scott Couston (zczc2311)
Partner organization: openSUSE.org

Description:
This feature request has a huge SLES/SLED Commercial Application as
well as an OpenSuse application.
Preamble-
The larger a Network gets the more costly it becomes to effectively
administer it and cost of help desk staff fixing up accidental changes
to users desktop. A user having access to the root user and password is
a disturbing failure by Enterprise Technicians. The following is a
little more detailed than a concept however, there are technical issues
yet to overcome outside of this document.
Effectively installing updates and new applications and maintaining
company policy on desktop access and presentation, keeps a small cast
of hundreds of staff roaming an enterprise and large numbers of help-
desk permanently and often on roster 24/7.
Trying to maintain company standards is a nightmare for Help Desk and
Security Managers bad dreams. Currently we have no simple yet effective
way to do this; however we have all the tools and don’t need to buy
any commercial software.
No Net Admin nor Help Desk personnel can ever be expected to maintain
hundreds of users desktops and their configuration so long as users
have both the 'poke it and see' or has this innate type of curiosity to
“Lets change this and see what happens”
This feature request proposes a method of achieving Network-Wide
Desktop Configuration, standardisation, standardisation of user
authority on a workstation and implementing network wide changes with a
minimum of fuss. It does require that ALL outstanding BUGS of NFS be
fixed and verified as working every time, everyday, without fault.
I am NOT proposing we just lock up all workstations, far far from
that. The request does not impede in any way the freedom each user
needs to retain preferences.
Situation -
We can learn a lot about the horrendously difficult task that
Microsoft gives their Netadmin's and Help Desk personnel to standardise
desktop configuration and functionality, Network wide.
M.S calls this 'profiles' or 'wandering profiles' or 'mobile' or
'dynamic profiles'.
To this end I am going to explain the essentially working properties
on how Microsoft achieves this. This will not be a complete technical
discussion, however I can propose a much better and less troublesome
technical answer to this situation by only looking at the basis of an M.
S Network Profile.
The reason we can achieve a more advanced proposition is a tribute to
a more advanced O/S in our Linux and the way we manage network drives.
Current M.S
On an MS NTFS server a permanent system directory exists that holds
shell (profile) information that every MS desktop can use one the
profile file exists. Every workstation that has ever been installed
with ANY version of windows comes with a specific environment variable
set that basically says after login to server, check for system profile
and if present use this as the desktop standard.
If not found or the profile file is incomplete with errors in it, then
ignore and load normal workstation configurations. There are more
complex parts to this, but essentially this is all that happens. An M.S
Windows complete guide devotes a whole chapter, some 80 Pages, on how
this is achieved and it is laborious and unnecessarily complex.
The user can have the right to change their desktop presentation, but
menu items can be greyed out to control access to change important
aspects of say, I.E that need to have company wide settings that a user
cannot change.
Users have the system rights to change their workstation appearance.
The other 2 two files held on the servers file system are Policy
Profile (group or otherwise) and Authority Profile. This one file can
be changed by a netadmin and copied to the system profile file, this
ensures all users take up workstation standardisation and forced user
authority network wide
My Feature Request for Suse Linux. - “Standard Network Desktop”
In concept, after using ONE PC Server to create a standard desktop
look and feel, all users inherit this mater configuration.
Firstly we need a new Application in Yast>Miscellaneous>New
Application> that has the dual ability to either create the Standard
Network Desktop OR to use the Standard Network Desktop. The former
should be used on a Network File Server. I suggest this new application
in yast is in a wizard format.
If CREATE is used the current configuration of the desktop is
copied to every %userername directory which holds the same copy of all
hidden files configuration and directory structure.
The next step in CREATE is to start an NFS Server which only
creates the export of the newly created directory as Read Only.
The next step is to set some environment variables on
$Set Standard_Network_Configuration =(the created name of the new
directory
$Set Standard_Network_Group Configuration = %username Group(users)
$Set Standard_Network_Authority=%username second group membership
If USE Standard Network Configuration is used in
Yast>Miscellaneous>New Application, the exported Network configuration
directory is mounted as all users /home directory as RO.
Next the same three environment variables are set.
$Set Standard_Network_Configuration =(the created name of the new
directory
$Set Standard_Network_Group Configuration = %username Group(users)
$Set Standard_Network_Authority=%username second group membership
The wizard is finalised and then the workstation is rebooted. When the
workstation loads the mounted /home directory that is exported on the
CREATE File Server, become the users /home directories hidden
configuration files which ensures the exact copy that was first
established.
If a change in the default workstation is required, the changes are
made once on the desktop that the File Server uses. Then the create
wizard is then re-executed copying the new configuration files to the
system wide /home directory on the file server with all its .
configuration directories and files and the directory is re-exported.
As soon as any PC that has had the USE function acted upon it; is
rebooted the new appearance from the newly created desktop
configuration is again remounted as the users /home directory which
takes up all the new .hidden files configuration. Up until now this is
a very simple concept and very easy to implement. Now comes the hard
part.
This is where we need to observe the set environment variables on the
workstation and server. I don’t have all the technical answers here,
however I can propose a method of handling these new problems
The Network Standard environment variable is intended to specify that
the user can/cannot write to their % username exported directory on the
Server's own hard disk as well as can/cannot write files and documents
and create new directories; example /home/documents and directories
that are not hidden. This variable also ensures that directories and
file are owned by the correct username, group etc.
The Group environment variable is intended to specify a group standard
that can contradict or reverse or alter ANY of these environment
variables and to what extent. The groups are defined by adding or
removing membership to groups other than 'users', in the user account,
The Authority environment variable is intended to specify the location
of the users encrypted Login account details and where they are stored.
Again the Authority name is taken from specific user login group
membership.
This is about where I finish the concept of yet to be defined use of
the environment variables to overcome the situation where every users
login account needs to be both observed, and its location.
The environment variables are also intended to allow a user to write
changes to their desktop

+ Test Case:
+ Further refinement. The reason why I have opted for a wizard interface
+ for both the CREATE and USE in the new Yast Application is simple. I am
+ not normally a fan of wizards, but in this case the wizard approach
+ must be used. I say this because during development if technical
+ changes or if an additional step is required, the wizard provides an
+ easy platform to cope with change. I have re-evaluated the CREATE part
+ of the wizard. During CREATE, I suggest that 3 directories need to be
+ created. The same copy of configuration files taken from the Host
+ Desktop Server to three complete desktop configurations held in each.
+ The reason is simple. Creating three different desktop directories
+ permits inheriting information from the three environment variables.
+ All three directories are all exported with corresponding descriptive
+ names. Within the three directories that CREATE establishes, changes in
+ file permissions that will be inherited by all the workstations,
+ becomes easily understood. The three environment variables already
+ contain more than enough information to effect their previously
+ documented purpose, but in addition also contain the file permissions
+ ownership and their RWX inherent to Linux. In the USE part of the Yast
+ wizard the mounts of the exported directory as simply mounted as /home
+ , however three different directory structures, each corresponding to
+ the information in the environment variables, are available for
+ selection to be mounted as /home. The USE wizard needs another step to
+ make this selection and subsequent mount becomes more robust in design
+ making the complex far more easy. At this stage in my thoughts I am
+ beginning to be concerned and mindful that many many workstations will
+ be using the same configuration files help on the Desktop Server. The
+ file locks must hold whilst many many workstations read the config
+ mounted as /home. We would need to allocate one of the most highest
+ allocation for directory cache and huge CPU% reserved resources for the
+ creation of the Workstation Server. There are many further technical
+ issues that will arise and I am hopeful many others will contribute
+ with encouragement, realistic functional problems and realistic
+ critical thoughts on the whole concept lest the manner I am proposing.


Business case (Partner benefit):
openSUSE.org: This feature request has a huge SLES/SLED Commercial
Application as well as an OpenSuse application. - See Preamble This
feature needs possible reclassification to benefit both SLES/ELED and
all opensuse

Discussion:
#1: Scott Couston (zczc2311) (2011-12-27 23:42:30)
Much input and technical appraisal/input needs to take place
however, in conception I believe this to be elocutionary simple and
most desirable





--
openSUSE Feature:
https://features.opensuse.org/313112

< Previous Next >
List Navigation
This Thread