Mailinglist Archive: opensuse-features (159 mails)

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

Buildservice: Unconfirmed
Requester: Important Unconfirmed
Requester: Important

openSUSE Distribution: Unconfirmed
Requester: Important

- Package Wishlist: Unconfirmed
- Priority
- Requester: Desirable

Requested by: Scott Couston (zczc2311)
Partner organization:

This feature request has a huge SLES/SLED Commercial Application as
well as an OpenSuse application.
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
$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
$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
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
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
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

- Enterprise and Network Standard Desktops and Authority (feature/id:
Novell Netware File Server NLM and SLED)
- Enterprise and Network Standard Desktops and Authority (feature/id:
- Z Systems and Network Standard Desktops and Authority
(feature/duplicate: SUSE for Z'Systems)

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.

Use Case:
I have said this concept relies heavily of the Desktop Servers File
locks as every Workstation would be using 1 or three total
configuration files at one time. This is where the benefits of having a
Novell Netware File Server come in to this relationship. The role of
the Desktop Server in CREATE mode could be written for an NLM to do
much the same type of concept but do it with technical dazel and
performance! The NLM Modulde, when loaded, could interrogate the list
of users in an Enterprise and also permit and determine further
privileges of what users further down the object in the NDS. Here the
NLM could Interrogate the user list and create a %username directory
held in any object of the NLM. Once the userlist is determined and been
made available the NLM could browse for the MASTER /home directory
configuration files from the Master Workstation configuration,and then
copy to every %username /home directory which would then be MAP ROOT to
%username directory. Hence to make any Enterprise change all that is
required is that the Master Workstation be changed or modified to the
new more desirable nature then once that has been done we command the
NLM to perform another global copy of the Master Workstation's new
configuration to every %usernames /home configuration directories and
files. The user logs in and up comes the exact copy of the New Desktop
to every user of the Enterprise. The further use of the environment
variables that get established by using the Yast USE application, as
described above, carry the workstations /home direction mount point.
Further more the environment variables carry the SET %Map Root to the
users /home and total configuration files on the Netware File Server.
The major technical issue I find here is that we can have single sign
on between Netware File Servers to SLED and SLES to SLED, without too
much trouble, however the storage of the user credentials, especially
between SLES and SLED; be thought well through. The aspect where a
workstation can have multiple user logins per workstation makes this
theory suddenly more difficult, but not impossible, to work out. The
root login on all Workstations is always the savior of the day if
something goes wrong with the access to the common configuration files
as its config is held on the local PC.
I need to stress that during the standard execution of the Suse Linux
login script boot; there must be an IF network config exist then do and
if not exist then use locally held /home and configuration files.

Business case (Partner benefit):
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.
The user benifit when the relationship is with a Novell Netware File
Server, is a dream run.
The painfully small change to make this concept be applied to IBM
Z'Series is deleriously a happy one!

#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

#3: Scott Couston (zczc2311) (2011-12-30 00:23:01) (reply to #1)
Reply to myself - I am not sure how I get noticed by anyone in openFATE
so I'm just going to set a few user names at openSUSE Yast! If no one
finds me to tell me I'm either an idiot or this is not worthwhile I'll
do that in a week or so

#2: Scott Couston (zczc2311) (2011-12-29 00:50:43)
O.T God I hate the ritchtext editor,,, whee are the options for font
and size. Character effects, bold etc. I can see and all the rest I
understand, but the font and point size? Can someone help me out here

openSUSE Feature:

< Previous Next >
List Navigation
This Thread