June 2012 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 309614] Activator application for SUSE Studio created appliances
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Christian Hueller (chuller) Feature #309614, revision 1 Title: Activator application for SUSE Studio created appliances Requested by: Christian Hueller (chuller) Partner organization: openSUSE.org Description: Basically the idea is simple: Create an application (GUI would be nice) that can 'activate' a previously SUSE Studio built appliance. 'Activate' stands here for things like o register appliance with Novell or ISV o create users and set passwords o do other security relevant things like creating keys or add own proprietary material After the activation it would be awesome to also integrate some deployment functionality to burn isos directly to CD after activation or copy disk images to a usb stick How it might work: Basically the appliance filesystem needs to be accessed in order to modify the appliance accordingly. This could be done through either loop mounting the image or by booting it inside some hypervisor. Loop mounting requires root access, so booting might be the better solution, we only need to take care the kiwi firstboot processes do net get triggered in this activation boot. Possible features: o interaction with studio itself using its API (no manual download of the appliance e.g.) Use Case: The use case is pretty clear as this would cover the gap between the simple creation of an appliance and the frist booting of it on your hardware: The user downloads a SLES11 appliance with the 'activator', then sets the root password and enters the SLES11 registration key. Now the update repositories get added to the appliance and the password is changed without being accessible on the online server. Business case (Partner benefit): openSUSE.org: This would be a great usability improvement to the whole stusio experienc -- openSUSE Feature: https://features.opensuse.org/309614

1 2

[New: openFATE 313426] Allow vendor changes in suse studio
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Paolo Zavarise (bicchiere) Feature #313426, revision 1 Title: Allow vendor changes in suse studio SUSE Studio: Unconfirmed Priority Requester: Desirable Requested by: Paolo Zavarise (bicchiere) Partner organization: openSUSE.org Description: If you create a kde appliance based on opensuse 12.1 and then you add the kde 4.8 repository, you will find kde 4.7 in the appliance, because the suse studio system lack the option "allow vendor changes" that you can find in zypper.conf. Actually, you need to select kde 4.8 files manually. I think that an option "allow vendor changes" should be a good idea in the suse studio build system. -- openSUSE Feature: https://features.opensuse.org/313426

1 1

[New: openFATE 313197] Allow VMDK and OVF builds with *no* guest additions / VM tools
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: M. Edward Ed Borasky (znmeb) Feature #313197, revision 1 Title: Allow VMDK and OVF builds with *no* guest additions / VM tools SUSE Studio: Unconfirmed Priority Requester: Mandatory Requested by: M. Edward Ed Borasky (znmeb) Partner organization: openSUSE.org Description: I build desktop appliances in OVF and VMDK format and run them in either VirtualBox, VMware Player or VMware Workstation. During the build process, SUSE Studio forces installation of the VMware library libvmtools0 if I select either OVF or VMDK, and it generates a conflict if I try to ban that library. When a user runs a desktop appliance, they have to *remove* any installed VMware or VirtualBox guest additions / tools and install the *matching* toools provided by their desktop virtualizer. If they don't, the appliance won't function correctly. So SUSE Studio should allow the appliance maker to remove any guest tool / addition libraries in the creation process. -- openSUSE Feature: https://features.opensuse.org/313197

1 1

[New: openFATE 313162] Update VMware version in VMX files
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: M. Edward Ed Borasky (znmeb) Feature #313162, revision 1 Title: Update VMware version in VMX files SUSE Studio: Unconfirmed Priority Requester: Important Requested by: M. Edward Ed Borasky (znmeb) Partner organization: openSUSE.org Description: The current version of SUSE Studio creates VMware virtual machines that are many versions behind where VMware is. I believe they're currently being generated as version 4, while VMware has versions 5, 6, 6.5, 7 and 8. I would say generate them at version 7 - VMware Workstation 8 just came out a few months ago and I don't know how many people have upgraded that far yet. But just about everyone who's *active* on VMware should be at least on 7. Test Case: Create a virtual machine in SUSE Studio. Download it and open it in VMware Workstation. You'll get a dialog asking if you want to upgrade it. Use Case: The current version of VMware machines won't play with the "Unity" option. Business case (Partner benefit): openSUSE.org: Mostly it's because of Unity in VMware Player. Player doesn't have the upgrade option, and I don't want my users to have to buy Workstation to use Unity. -- openSUSE Feature: https://features.opensuse.org/313162

1 1

[New: openFATE 313112] Enterprise and Network Standard Desktops and Authority
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Scott Couston (zczc2311) Feature #313112, revision 1 Title: Enterprise and Network Standard Desktops and Authority 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 -- openSUSE Feature: https://features.opensuse.org/313112

1 21

[New: openFATE 312942] Clone 32bit image to 64 bits
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Richard Bos (rbos) Feature #312942, revision 1 Title: Clone 32bit image to 64 bits SUSE Studio: Unconfirmed Priority Requester: Desirable Requested by: Richard Bos (rbos) Partner organization: openSUSE.org Description: Although it is possible to clone an appliance, it does not seem possible to clone or perhaps better brance a 32bit appliance and alter the artchitecture to 64 bit. Right the same appliance has to made and configured for the 64 bit architecture. Business case (Partner benefit): openSUSE.org: Sometimes an appliance is available is 32bit version, but a 64bit is desired so it can run natively on a 64bit system. -- openSUSE Feature: https://features.opensuse.org/312942

1 1

[New: openFATE 312642] Timeframe for building
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Kim Leyendecker (openLHAG) Feature #312642, revision 1 Title: Timeframe for building SUSE Studio: Unconfirmed Priority Requester: Important Requested by: Kim Leyendecker (openlhag) Partner organization: openSUSE.org Description: IÂ´m currently maintain openSUSE remastered 11.1. ItÂ´s build for keeping an openSUSE 11.1 image up to date using the evergreen repos. IÂ´m doing Service Packs in a fix schedule. Upgrading the packages and rebuild the system is kinda pain for me. So, a feature which you can use to give Studio a time schedule for updating the appliance would be nice. *How it works?* Well, the best way would be to choose a GUI where the following is included: Automatic build all: * 6 weeks * every month * every week * 6 months * (type in your desired timeframe) New build if: * an package get updated in the repository * just do it on time, donÂ´t care about packages Which number should be counted higher: * the major number * the minor number * the release number Using Hermes, the maintainer would get the latest build information in a changelog: Appliance name: xxx Based on: openSUSE /SUSE Linux Enterprise Current version: mm.ii.rr new packages: Firefox 3.6.19 -> Firefox 5.0.1 Thunderbird 3.1.0 -> Thunderbird 5.0 Linux 2.6.32 -> Linux 3.0rc7 ... comments: -- Use Case: doing releases on time, like I do. Business case (Partner benefit): openSUSE.org: Because so we can automatically create releases on a time based model. This becomes important when we want to ship Service Packs. -- openSUSE Feature: https://features.opensuse.org/312642

1 2

[New: openFATE 312082] Updating SUSE images on Studio
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Shashank Sondhi (dreamtrip) Feature #312082, revision 1 Title: Updating SUSE images on Studio SUSE Studio: Unconfirmed Priority Requester: Mandatory Requested by: Shashank Sondhi (dreamtrip) Partner organization: openSUSE.org Description: So as to ensure that SUSE studio images do not face trouble regarding upgrades it would be great if the images could be updated if the option is selected for the image or version. -- openSUSE Feature: https://features.opensuse.org/312082

1 3

[New: openFATE 311013] Adding Beta and RC status
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Kim Leyendecker (openLHAG) Feature #311013, revision 1 Title: Adding Beta and RC status SUSE Studio: Unconfirmed Priority Requester: Neutral Requested by: Kim Leyendecker (openlhag) Partner organization: openSUSE.org Description: A nice feature in SUSE Studio is to add a Beta or RC status on your own appliance. If you build a Server and you know it's unstable but you want to publish it to get feedback, you can add a status, so that it's on the iso Image too. Business case (Partner benefit): openSUSE.org: Because the user can see how far the developing status is. -- openSUSE Feature: https://features.opensuse.org/311013

1 1

[New: openFATE 310898] integrate BuildService and SUSE Studio better
by fate_noreply＠suse.de 12 Aug '13

12 Aug '13

Feature added by: Jos Poortvliet (jospoortvliet) Feature #310898, revision 1 Title: integrate BuildService and SUSE Studio better Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Jos Poortvliet (jospoortvliet) Partner organization: openSUSE.org Description: SUSE Studio and BuildService have very limited integration right now, still making them separate worlds. Howver there is a lot of room for doing better. Which could bring users from the one to the other - there seems rather little overlap between the two userbases, and SUSE Studio could thus profit from the OBS users AND bring new users to OBS/openSUSE. An example of integration would be to have a one-click-make-an-appliance-of-this-package. Or in SUSE Studio - offer the user to build a package in OBS out of a tarball he/she uploads. Business case (Partner benefit): openSUSE.org: We want this because it can bring new users to OBS/openSUSE/SUSE Studio. And it offers additional value for both STUDIO and OBS users as well. -- openSUSE Feature: https://features.opensuse.org/310898

1 3