April 2011 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 312216] deprecate /var/lock
by fate_noreply＠suse.de 06 Apr '11

06 Apr '11

Feature added by: Ludwig Nussel (lnussel) Feature #312216, revision 1 Title: deprecate /var/lock openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: /var/lock should be deprecated - it never was really used properly on SUSE Linux - using lockdev didn't really help either as only few programs actually use it and it's not bug free (should be setuid instead of setgid lock) The suggestion would be to patch programs to use flock() on the device fd instead which would solve all problem wrt permissions ans stale lock files. https://bugzilla.redhat.com/show_bug.cgi?id=581884 http://0pointer.de/blog/projects/locking http://0pointer.de/blog/projects/locking2 -- openSUSE Feature: https://features.opensuse.org/312216

1 2

[openFATE 308626] Snapshot/Rollback interface to the ZYpp stack
by fate_noreply＠suse.de 05 Apr '11

05 Apr '11

Feature changed by: Matthias Eckermann (mge1512) Feature #308626, revision 40 Title: Snapshot/Rollback interface to the ZYpp stack openSUSE-11.3: Rejected by Gerald Pfeifer (geraldpfeifer) reject date: 2010-11-17 00:53:34 reject reason: openSUSE 11.3 has been released months ago. Priority Requester: Mandatory openSUSE-11.4: Evaluation by project manager Priority Requester: Important Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) - Info Provider: (Novell) Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Engineering Manager: (Novell) Developer: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Partner organization: openSUSE.org Description: Ability for libzypp and exposed via zypper to snapshot either automatically or explicitly the system before commit happens, plus an interface to revert the system. The interface should be generic and allow for different possible implementations which should be offered depending on the context: * btrfs based if /root is btrfs * simple based on package list before commit, plus package history and current package list to determine diff last transaction * two root partitions, where the interface would clone root filesystem before commit and switch them at rollback time. The feature includes the concept, and a working implementation with one or more of the strategies described before. References: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autou… http://wiki.rpath.com/wiki/Conary:conary_rollback Relations: - grub1 patch for btrfs boot (url: ) Documentation Impact: Requires description of the functionality in zypper options Test Case: zypper install foo bar zypper rollback System should be as before the installation. Corner cases are not important. Use Case: Administrator installs a bunch of updates, which leaves the system in an an unworkable state. He types zypper rollback to undo the changes. Business case (Partner benefit): openSUSE.org: * Customer asked about snapshoting during our last meeting. * Feature parity with Solaris which is implementing package rollback based on ZFS * RHEL goes the same route, announced btrfs rollbacks in yum * We can do better, offering something more flexible and not btrfs dependent to support different scenarios: SLES (btrfs), Appliances (dual system partition), openSUSE (simple package list) Discussion: #1: Federico Lucifredi (flucifredi) (2010-03-05 07:29:41) PM: Important for 11.3. (sorry, on web client). #3: Joachim Werner (joachimwerner) (2010-04-28 18:10:50) I have SLEPOS-specific use cases for this feature, too. IBM implemented a similar rollback feature in IRES2, based on tripwire AFAIK. Some techical considerations we need to understand: Rolling back the right things What customers really want is not a dumb rollback of everything on the system to the old state, but just the changes done by the update. So it may be necessary to make sure the snapshot only applies to the configuration directories (usually /etc) and the code directories (/usr) affected by the update, but not things like logfiles (which should be continuous) or application data (nobody wants to get their database files rolled back by accident, or data a user has saved in /home/username in the meantime). Another potential issue with some applications is that they can be in an inconsistent state if they aren't stopped during a snapshot. This is a more generic problem with snapshots as such. For this Windows has mechanisms to inform an application that it's going to do a shadow copy now. In Linux there is no single interface to trigger that, although some databases and other applications have there own way of switching into a read-only snapshotting-safe mode. So, this is all doable, but just applying a system-wide snapshot seems to be too simple. Maybe we can just copy what Red Hat is doing here (if it's good enough). Red Hat has finished this feature in Fedora, and it's probably going to be in RHEL6 at some point, too. https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs (https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs) contains a few considerations on this. Avoiding situations that can't be recovered zypper rollback sounds like a good plan at first, but it is not in all cases. If you apply an update that breaks the system, this could mean that a kernel update went wrong and you can't even boot beyond a certain stage. So there needs to be a way of entering the recovery from the earliest possible level, the boot prompt. There needs to be an option to boot into the snapshotted system, and from there eliminate the changes made after the snapshot and declare the snapshot to be the current state. For the worst case (a broken grub package or so kills the bootloader configuration) we need to have a recovery workflow (from CD or so) that can still bring back the old working state. Do one thing right, not three things that solve the same problem If we decide to go down the btrfs route (which I like) we should not also solve the same problem using several other approaches. Why use dual system partitions if you can have snapshots? #7: Duncan Mac-Vicar (dmacvicar) (2010-10-21 10:43:26) I would like to clarify some issues: For rollbacks, it would be the ideal situation to have the root filesystem completely under btrfs, otherwise you run into the problem that kernels are not affected by the rollback and this increases complexity. * a) For this we need to boot with btrfs. Matthias told me we should ignore this problem because under EFI you have to put the kernel under /efi in a FAT partition, but my own research tells me that what is in FAT /efi is the grub EFI program, and therefore the kernel could be in btrfs if the grub EFI program supports finding the kernel with btrfs. Can anyone confirm this? * b) For booting with btrfs we need either grub2, or syslinux or a patch for grub1 (added as a reference to the feature). Which route will we follow here? Do we have anyone empowered to make this decision soon? * c) if b) is solved with grub1 patch I suggest we open a feature entry to track that one. #9: Olaf Kirch (okir) (2010-10-22 12:56:49) (reply to #7) My preferred solution would be to enable grub1 for btrfs; it seems to pose the least risk - assuming the btrfs code is stable enough. (BTW either my fate client is too old, or the link you added is broken). #13: Gerald Pfeifer (geraldpfeifer) (2010-11-17 00:53:01) One further idea that came up is adding a bootloader entry (or several) that, when chosen, would revert the system into an old state as represented/described by that entry and boot into it. This is more involved than the more basic scenarios here and might be suitable for another, linked FATE? #15: Federico Lucifredi (flucifredi) (2011-03-25 21:02:37) (reply to #13) I like that. If at all possible, we should provide a boot item into the previous snapshot. #14: Jörg Schmela (herz-von-hessen) (2011-02-25 18:42:40) therefore my full Consent -- openSUSE Feature: https://features.opensuse.org/308626

1 0

[openFATE 308626] Snapshot/Rollback interface to the ZYpp stack
by fate_noreply＠suse.de 05 Apr '11

05 Apr '11

Feature changed by: Lukas Ocilka (locilka) Feature #308626, revision 39 Title: Snapshot/Rollback interface to the ZYpp stack openSUSE-11.3: Rejected by Gerald Pfeifer (geraldpfeifer) reject date: 2010-11-17 00:53:34 reject reason: openSUSE 11.3 has been released months ago. Priority Requester: Mandatory openSUSE-11.4: Evaluation by project manager Priority Requester: Important Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Engineering Manager: (Novell) - Engineering Manager: (Novell) Developer: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Partner organization: openSUSE.org Description: Ability for libzypp and exposed via zypper to snapshot either automatically or explicitly the system before commit happens, plus an interface to revert the system. The interface should be generic and allow for different possible implementations which should be offered depending on the context: * btrfs based if /root is btrfs * simple based on package list before commit, plus package history and current package list to determine diff last transaction * two root partitions, where the interface would clone root filesystem before commit and switch them at rollback time. The feature includes the concept, and a working implementation with one or more of the strategies described before. References: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autou… http://wiki.rpath.com/wiki/Conary:conary_rollback Relations: - grub1 patch for btrfs boot (url: ) Documentation Impact: Requires description of the functionality in zypper options Test Case: zypper install foo bar zypper rollback System should be as before the installation. Corner cases are not important. Use Case: Administrator installs a bunch of updates, which leaves the system in an an unworkable state. He types zypper rollback to undo the changes. Business case (Partner benefit): openSUSE.org: * Customer asked about snapshoting during our last meeting. * Feature parity with Solaris which is implementing package rollback based on ZFS * RHEL goes the same route, announced btrfs rollbacks in yum * We can do better, offering something more flexible and not btrfs dependent to support different scenarios: SLES (btrfs), Appliances (dual system partition), openSUSE (simple package list) Discussion: #1: Federico Lucifredi (flucifredi) (2010-03-05 07:29:41) PM: Important for 11.3. (sorry, on web client). #3: Joachim Werner (joachimwerner) (2010-04-28 18:10:50) I have SLEPOS-specific use cases for this feature, too. IBM implemented a similar rollback feature in IRES2, based on tripwire AFAIK. Some techical considerations we need to understand: Rolling back the right things What customers really want is not a dumb rollback of everything on the system to the old state, but just the changes done by the update. So it may be necessary to make sure the snapshot only applies to the configuration directories (usually /etc) and the code directories (/usr) affected by the update, but not things like logfiles (which should be continuous) or application data (nobody wants to get their database files rolled back by accident, or data a user has saved in /home/username in the meantime). Another potential issue with some applications is that they can be in an inconsistent state if they aren't stopped during a snapshot. This is a more generic problem with snapshots as such. For this Windows has mechanisms to inform an application that it's going to do a shadow copy now. In Linux there is no single interface to trigger that, although some databases and other applications have there own way of switching into a read-only snapshotting-safe mode. So, this is all doable, but just applying a system-wide snapshot seems to be too simple. Maybe we can just copy what Red Hat is doing here (if it's good enough). Red Hat has finished this feature in Fedora, and it's probably going to be in RHEL6 at some point, too. https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs (https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs) contains a few considerations on this. Avoiding situations that can't be recovered zypper rollback sounds like a good plan at first, but it is not in all cases. If you apply an update that breaks the system, this could mean that a kernel update went wrong and you can't even boot beyond a certain stage. So there needs to be a way of entering the recovery from the earliest possible level, the boot prompt. There needs to be an option to boot into the snapshotted system, and from there eliminate the changes made after the snapshot and declare the snapshot to be the current state. For the worst case (a broken grub package or so kills the bootloader configuration) we need to have a recovery workflow (from CD or so) that can still bring back the old working state. Do one thing right, not three things that solve the same problem If we decide to go down the btrfs route (which I like) we should not also solve the same problem using several other approaches. Why use dual system partitions if you can have snapshots? #7: Duncan Mac-Vicar (dmacvicar) (2010-10-21 10:43:26) I would like to clarify some issues: For rollbacks, it would be the ideal situation to have the root filesystem completely under btrfs, otherwise you run into the problem that kernels are not affected by the rollback and this increases complexity. * a) For this we need to boot with btrfs. Matthias told me we should ignore this problem because under EFI you have to put the kernel under /efi in a FAT partition, but my own research tells me that what is in FAT /efi is the grub EFI program, and therefore the kernel could be in btrfs if the grub EFI program supports finding the kernel with btrfs. Can anyone confirm this? * b) For booting with btrfs we need either grub2, or syslinux or a patch for grub1 (added as a reference to the feature). Which route will we follow here? Do we have anyone empowered to make this decision soon? * c) if b) is solved with grub1 patch I suggest we open a feature entry to track that one. #9: Olaf Kirch (okir) (2010-10-22 12:56:49) (reply to #7) My preferred solution would be to enable grub1 for btrfs; it seems to pose the least risk - assuming the btrfs code is stable enough. (BTW either my fate client is too old, or the link you added is broken). #13: Gerald Pfeifer (geraldpfeifer) (2010-11-17 00:53:01) One further idea that came up is adding a bootloader entry (or several) that, when chosen, would revert the system into an old state as represented/described by that entry and boot into it. This is more involved than the more basic scenarios here and might be suitable for another, linked FATE? #15: Federico Lucifredi (flucifredi) (2011-03-25 21:02:37) (reply to #13) I like that. If at all possible, we should provide a boot item into the previous snapshot. #14: Jörg Schmela (herz-von-hessen) (2011-02-25 18:42:40) therefore my full Consent -- openSUSE Feature: https://features.opensuse.org/308626

1 0

[New: openFATE 312205] Provide anonymous web surfing
by fate_noreply＠suse.de 04 Apr '11

04 Apr '11

Feature added by: Klaas Freitag (kfreitag) Feature #312205, revision 1 Title: Provide anonymous web surfing openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Klaas Freitag (kfreitag) Partner organization: openSUSE.org Description: Anonymous web surfing should be only one, I mean one, click away on a default installation of openSUSE. I would love to see a little desktop applet or browser plugin which enables anonymous surfing for the logged in user. There are various projects out there to help protecting our privacy such as Tor https://www.torproject.org/ and others like proxies and such. These should be nicely integrated into the system, ie. when setting up network there could be a swith "enable anonymous browsing by default" and such. All parts for such an solution are there, just investigation, planning and integration is needed. Please note that anonymous internet usage is not illegal. Its like sending a letter in an envelope instead of without. Use Case: Protected privacy for data, also for unexperienced users. Business case (Partner benefit): openSUSE.org: AFAIK no other distribution provides this well integrated into the system and at the fingertip of the user. -- openSUSE Feature: https://features.opensuse.org/312205

1 0

[New: openFATE 311184] Create Maintenace Update request
by fate_noreply＠suse.de 04 Apr '11

04 Apr '11

Feature added by: Adrian Schröter (adrianSuSE) Feature #311184, revision 1 Title: Create Maintenace Update request Buildservice: Evaluation by project manager Milestone: 2.3 Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Adrian Schröter (adriansuse) Project Manager: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Partner organization: openSUSE.org Description: OBS needs to support to open a Maintenance project on request. This project is used to prepare, test and document and contain all sources and binaires for a maintenance incident. The project should get a unique ID to identify the incident. The request may also include an entire project used as source for the maintenance incident. The following xml layout is suggested (for example): action type="maintenance" source project="home:adrian:OBS_Maintenance:libqt4" optional, take this project as source target project="openSUSE:Maintenance" required target sourceupdate cleanup sourceupdate optional, will remove source project on update action On accept, the project openSUSE:Maintenance:$ID will get created and the sources from source project will get copied in. Binaries will get rebuild. Having the source project optional makes sense if the maintenance project owner wants to build up a maintenance project manually or for a later feature, when maintenance creates such a project to request to some maintainers to fix a certain issue (basically maintenance would start the process, not the user). -- openSUSE Feature: https://features.opensuse.org/311184

1 3

[New: openFATE 312196] Create Incident Command
by fate_noreply＠suse.de 04 Apr '11

04 Apr '11

Feature added by: Adrian Schröter (adrianSuSE) Feature #312196, revision 1 Title: Create Incident Command Buildservice: New Milestone: 2.3 Priority Requester: Mandatory Requested by: Adrian Schröter (adriansuse) Project Manager: (Novell) Engineering Manager: (Novell) Developer: (Novell) Partner organization: openSUSE.org Description: The maintenance team needs a command to create a maintenance incident directly, without to do missuse a request for it. This can either be done via attribute lookup or via target project: * /source?cmd=createmaintenanceincident&attribute=$ATTRIBUTE * /source/$PROJECT?cmd=createmaintenanceincident The attribute is optional, default is OBS:MaintenanceProject -- openSUSE Feature: https://features.opensuse.org/312196

1 1

[openFATE 306517] Read access control to obs projects
by fate_noreply＠suse.de 04 Apr '11

04 Apr '11

Feature changed by: Adrian Schröter (adrianSuSE) Feature #306517, revision 16 Title: Read access control to obs projects - Buildservice: Implementation + Buildservice: Done Milestone: 2.3 Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Scott Bahling (sbahling) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Developer: (Novell) Partner organization: openSUSE.org Description: A project owner defines which other projects are granted read access to this project. Let's call the projects with read access the 'reader list' of the project. Only other projects on the reader list are allowed to use sources or build results from this project; repositories share the permissions of their respective projects. Individual users act on behalf of projects. Thus they gain read access either by being member of the project or by being mamber of a project on the reader list. This is needed to manually build packages locally. When a project or a user has no read access, the project will not be visible. Any links seem to be broken, pointing to an inexistent object. Any read access control failures must pretend this, because project names already can reveal upcoming product properties. For the same reason, the reader list must only be accessible to project members. If read access is withdrawn from a project, already built results must no longer be accessible to the now unauthorized projects and their members. So semantically, a cached expanded source link or a built binary 'knows' which other projects have been used for its creation; read access is only granted to the intersection of the reader lists of all these projects at the time of the access. Obviously this can be cached, too, until the read access is updated. The read access is discretionary. This means, if a user has gotten hold of a source or a binary while she had access to it, she has the data on her disk and the obs will not provide means to take it back if read access should be withdrawn. For that reason, a 'which users and projects dos this reader list expand to' function must be provided, to make things obvious and to allow for what-if probes before changing the reader list. For reliable testing of build results, it's desirable to have the result of publishing available even for read access restricted projects. This would simplify and harden testing, giving testers a most end user like experience. For the record, it has been discussed to introduce 'real ACLs', allowing to withdraw access from some individuals or projects before granting access to a superset. It also has been proposed to optionally 'include' the acl from another project. And it has been proposed to add user groups in addition to projects. These three proposals at frist glance seem to simplify administration, but they also increase complexity of the read access and make it quickly obscure and non- obvious. This proposal here tries to keep it short and simple. References: http://wiki.opensuse.org/openSUSE:Build_Service_Concept_ACL#Adding_code_for… Business case (Partner benefit): openSUSE.org: Component vendors and system vendors consider it a significant competitive advantage to hide technical details about upcoming products until the product is publicly released. Thus privacy control is crucial for a self serviced operation of a driver build. Discussion: #1: Adrian Schröter (adriansuse) (2010-02-19 10:56:40) Diserable for our 2.0 release. Mandatory for ISV build. #2: Adrian Schröter (adriansuse) (2010-04-19 09:44:40) (reply to #1) k, LF want to do an extra release just for this feature (1.8). This feature is currently implemented by Martin Moring and Jan-Simon Möller from LinuxFoundation. #3: Adrian Schröter (adriansuse) (2010-04-21 17:22:15) EngManager and Developer is actual "Martin Mohring", but fate does not know him. #4: Adrian Schröter (adriansuse) (2010-09-17 14:47:32) OBS 2.1 will just have the control to protect sources, but not entire projects or binaries. OBS 2.2 is planned to focus on complete read permission handling only. #5: Martin Mohring (martinmohring) (2010-09-20 17:27:12) I am known to openFATE as login martinmohring #6: Martin Mohring (martinmohring) (2010-09-20 17:29:29) Am update on the implementation is available on http://en.opensuse.org/openSUSE:Build_Service_Concept_ACL + #7: Adrian Schröter (adriansuse) (2011-04-04 13:32:20) + Implementation looks to be complete, except for some last fixme's. -- openSUSE Feature: https://features.opensuse.org/306517

1 0

[New: openFATE 311185] Release packages via merge request
by fate_noreply＠suse.de 04 Apr '11

04 Apr '11

Feature added by: Adrian Schröter (adrianSuSE) Feature #311185, revision 1 Title: Release packages via merge request Buildservice: Evaluation by project manager Milestone: 2.3 Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Adrian Schröter (adriansuse) Project Manager: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Partner organization: openSUSE.org Description: To release binaries and sources without changes from one project to another one, we need a request for this. The binaries needs to be merged into an existing repository, but they must not be rebuild in any case. The merge request can be used in multiple ways action type="merge" source project="..." package="..." repository="..." target project="..." package="..." repository="..." /action The only hard required information of this request is the source project. It would lead to merge all sources and binaries to the source linked package sources and all binaries to the repos linked via path. All other attributes may be used to filter the merge sources or targets. Using no filters may have a disadvantage in using the request search later on. -- openSUSE Feature: https://features.opensuse.org/311185

1 1

[New: openFATE 311189] handheld optimized webui
by fate_noreply＠suse.de 04 Apr '11

04 Apr '11

Feature added by: Adrian Schröter (adrianSuSE) Feature #311189, revision 1 Title: handheld optimized webui Buildservice: Evaluation by project manager Milestone: 2.3 Priority Requester: Desirable Requested by: Roland Haidl (rhaidl) Project Manager: (Novell) Partner organization: openSUSE.org Description: The webui is not fully usable on cell phones and other handhelds. Tom works on an optimized interface for Smartphones. -- openSUSE Feature: https://features.opensuse.org/311189

1 3

[New: openFATE 312191] Driver management YaST module
by fate_noreply＠suse.de 02 Apr '11

02 Apr '11

Feature added by: Roger Luedecke (Shadowolf7) Feature #312191, revision 1 Title: Driver management YaST module openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Roger Luedecke (shadowolf7) Partner organization: openSUSE.org Description: Allow removing, inserting, and blacklisting of drivers via simple YaST module. -- openSUSE Feature: https://features.opensuse.org/312191

1 1