Feature changed by: Scott Couston (zczc2311) Feature #313112, revision 2 Title: Enterprise and Network Standard Desktops and Authority Requested by: Scott Couston (zczc2311) Partner organization: openSUSE.org Description: <!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } TT.cjk { font- family: "Droid Sans Fallback", monospace } --> 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 + Business case (Partner benefit): + openSUSE.org: This feature request has a huge SLES/SLED Commercial + Application as well as an OpenSuse application. - See Preamble -- openSUSE Feature: https://features.opensuse.org/313112

Feature changed by: Scott Couston (zczc2311) Feature #313112, revision 4 Title: Enterprise and Network Standard Desktops and Authority Requested by: Scott Couston (zczc2311) Partner organization: openSUSE.org Description: <!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } TT.cjk { font- family: "Droid Sans Fallback", monospace } --> 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 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

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

Feature changed by: Scott Couston (zczc2311) Feature #313112, revision 8 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 + Relations: + - Enterprise and Network Standard Desktops and Authority (feature/id: + Novell Netware and SLED) 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 #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: https://features.opensuse.org/313112

Feature changed by: Scott Couston (zczc2311) Feature #313112, revision 10 Title: Enterprise and Network Standard Desktops and Authority openSUSE.org: Unconfirmed Priority Requester: Important - 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 Relations: - Enterprise and Network Standard Desktops and Authority (feature/id: Novell Netware and SLED) 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 #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: https://features.opensuse.org/313112

Feature changed by: Scott Couston (zczc2311) Feature #313112, revision 12 Title: Enterprise and Network Standard Desktops and Authority openSUSE.org: 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 Relations: - Enterprise and Network Standard Desktops and Authority (feature/id: - Novell Netware and SLED) + Novell Netware File Server NLM and SLED) - Enterprise and Network Standard Desktops and Authority (feature/id: SLED/SLES) + - 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. 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 #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: https://features.opensuse.org/313112

Feature changed by: Scott Couston (zczc2311) Feature #313112, revision 14 Title: Enterprise and Network Standard Desktops and Authority openSUSE.org: 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 Relations: - 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: SLED/SLES) - 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): - 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 + 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. + 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! 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 #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: https://features.opensuse.org/313112

Feature changed by: Scott Couston (zczc2311) Feature #313112, revision 20 Title: Enterprise and Network Standard Desktops and Authority Buildservice: Unconfirmed Priority Requester: Important openSUSE.org: Unconfirmed Priority Requester: Important openSUSE Distribution: Unconfirmed Priority Requester: Important - Package Wishlist: Unconfirmed - Priority - Requester: Desirable 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 Relations: - 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: SLED/SLES) - 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): 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. 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! 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 #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: https://features.opensuse.org/313112

Feature changed by: Scott Couston (zczc2311) Feature #313112, revision 23 Title: Enterprise and Network Standard Desktops and Authority Buildservice: Unconfirmed Priority Requester: Important openSUSE Distribution: Unconfirmed Priority Requester: Important + SUSE Studio: Unconfirmed + Priority + Requester: Desirable 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 Relations: - 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: SLED/SLES) - 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): 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. 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! 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 #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: https://features.opensuse.org/313112

Feature changed by: Scott Couston (zczc2311) Feature #313112, revision 26 Title: Enterprise and Network Standard Desktops and Authority Buildservice: Unconfirmed Priority Requester: Important openSUSE.org: Unconfirmed Priority Requester: Important + Package Wishlist: Unconfirmed + Priority + Requester: Important SUSE Studio: Unconfirmed Priority Requester: Desirable 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 Relations: - 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: SLED/SLES) - 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): 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. 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! 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 #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: https://features.opensuse.org/313112

Feature changed by: Andreas Jaeger (a_jaeger) Feature #313112, revision 28 Title: Enterprise and Network Standard Desktops and Authority - Buildservice: Unconfirmed + openSUSE.org: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2013-08-12 15:45:25 Priority Requester: Important - openSUSE.org: Unconfirmed + SUSE Studio: Rejected Priority - Requester: Important - Package Wishlist: Unconfirmed - Priority - Requester: Important - SUSE Studio: Unconfirmed - Priority Requester: Desirable - Requested by: Scott Couston (zczc2311) + Requested by: Andreas Jaeger (a_jaeger) 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 Relations: - 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: SLED/SLES) 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): 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. 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! 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 #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 + #4: Andreas Jaeger (a_jaeger) (2013-08-12 15:47:41) + This is an interesting idea but nothing we will drive at the moment. + This needs a lot of scripting - using kiwi directly or Studio via the + API - and packaging. I'm not taking this on for Studio right now. + #5: Andreas Jaeger (a_jaeger) (2013-08-12 15:49:09) + Original requester account is not working anymore, adding myself as + requester. -- openSUSE Feature: https://features.opensuse.org/313112