September 2014 - openSUSE Features - openSUSE Mailing Lists

[openFATE 303793] Mount /var/run as tmpfs
by fate_noreply＠suse.de 15 Sep '14

15 Sep '14

Feature changed by: Karl Eichwalder (keichwa) Feature #303793, revision 74 Title: Mount /var/run as tmpfs openSUSE-11.2: Rejected by Matthias Eckermann (mge1512) reject date: 2009-07-16 11:42:53 reject reason: Rejected on request of Engineering. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2010-10-06 16:02:09 reject reason: not done. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.4: Done Priority Requester: Mandatory Requested by: Kay Sievers (kay_sievers) Technical Contact: Kay Sievers (kay_sievers) Partner organization: openSUSE.org Description: /var/run should be mounted as tmpfs. This would avoid the cleaning of stale files or sockets on bootup and avoid atime updates of any mounted filesystems. This is required for eg powermanagement, which currently wakes up the system from any idle states for a socket operation. Services must be modified not to depend on a preexisting content in /var/run upon startup. RPMs must be modified to not place anything there. Documentation Impact: Administration guide. RN Discussion: #2: Federico Lucifredi (flucifredi) (2008-07-08 19:30:23) somehow SLES/SLED got out of sync here. Matching. #4: Duncan Mac-Vicar (dmacvicar) (2008-07-14 15:30:03) There are no resources for this feature. Please postpone, (as agreed with MgE) #5: Duncan Mac-Vicar (dmacvicar) (2008-07-14 15:46:55) Just as a side note this feature will require an effort of aprox. 1 week, together with #303810 (they averlap about 95%) #10: Arvin Schnell (aschnell) (2009-02-04 10:50:32) Any requirements on the size for the tmpfs or should the default of tmpfs be used? #11: Arvin Schnell (aschnell) (2009-02-05 19:27:03) (reply to #10) Kay replied by personal mail: Size doesn't matter. /var/lock should also be on tmpfs. #12: Duncan Mac-Vicar (dmacvicar) (2009-06-02 11:22:49) Christoph, please reject with openSUSE 11.2, because disk encryption we can't promise this feature for 11.2. It may get done as bonus if encryption gets done earlier than expected, but we can't commit to it (which is what rejection means, which does not mean we may work on it). It is the next thing we will work on after encryption support. #32: Dirk Mueller (dirkmueller) (2010-04-26 12:08:04) rpmlint check implemented (badness 900) #35: Duncan Mac-Vicar (dmacvicar) (2010-11-03 15:50:03) Kay, is this still feature desired now with relatime as default? or can be closed forever? #36: Kay Sievers (kay_sievers) (2010-11-03 18:52:22) (reply to #35) It is a good feature to have, because we don't want to cleanup the dir on bootup. Systemd has this mandatory and you can't even disable it. #37: Andreas Jaeger (a_jaeger) (2010-11-04 09:24:36) (reply to #35) This feature is done with using systemd. The scripts mount /var/run already and packages get fixed. I don't think any changes in YaST are needed, so I guess this can be marked as done. Duncan, please check for YaST work - and if none is needed, mark as done. #38: Arvin Schnell (aschnell) (2010-11-04 12:02:02) (reply to #37) When systemd mounts it and no entry in fstab is desired the feature is done from my side. I'm sure the mounting happens after potentially mounting /var. #39: Duncan Mac-Vicar (dmacvicar) (2013-03-05 11:29:23) Jiri, assuming SLE12 uses systemd, this feature can be marked as done. - Release Notes: /run mounted as tmpfs + Release Notes: Mounting /run as tmpfs Solution: The directory /run, also sym-linked as /var/run, is mounted as tmpfs - and thus is not persistent across reboots. Anything stored in this + and thus not persistent across reboots. Anything stored in this directory will be removed when the machine is shut down. -- openSUSE Feature: https://features.opensuse.org/303793

1 0

[openFATE 309448] Clean temporary data in SUSE
by fate_noreply＠suse.de 12 Sep '14

12 Sep '14

Feature changed by: Sean Watson (Futhorc) Feature #309448, revision 46 Title: Clean temporary data in SUSE openSUSE Distribution: New Priority Requester: Important Requested by: Michal Vyskocil (mvyskocil) Partner organization: openSUSE.org Description: The current default behavior of SUSE is not touch files in /tmp and others to prevent an unwanted data lost. There are at least two requests willing to change it somehow: * FATE#307510: Cron: set MAX_DAYS_IN_TMP different from 0 * bug#594778 - RN: include tmpwatch in a pattern The pros: * The common meaining of /tmp is that is for temporary data. FHS says - "Programs must not assume that any files or directories in /tmp are preserved between invocations of the program". FHS also allows the removal of a content of /var/tmp and /var/cache , even if those directories should be more persistent as /tmp . * As SUSE places the /tmp and /var on root partition by default and not remove the content of it, the free space should be simply eaten. There are a lot of applications in SUSE distribution that stores a lot of data inside those dirs, but because of the common meaning - they not removed them. For instance - Mozilla Firefox, ssh, gpg, kde, mc, Adobe Flash, and many others. The other way is to fix all of those programs to safely remove all content they store in /tmp after it's not needed. The cons: * Strictly speaking the not removal of /tmp and others is not againts FHS. * Change of the default is dangerous, especially if we are talking about files removal, because long time SUSE users might rely on this specific behavior of SUSE. * The default should be SAFE and not removing of files is considered as a safe default. Please note this FATE is not about concrete technical solution (existing scron script, tmwatch, tmpfs, /dev/shm, or something else). The question is - change the default behavior to remove temporary files, or not ? And if so, which ones and how often. Discussion: #1: Per Jessen (pjessen) (2010-05-04 11:31:51) I'm not really sure how this differs from feature 307510, but never mind - the only advantage of this change is to save disk space. Disk space is becoming cheaper by the minute and Terabyte is no longer an exotic amount reserved for large datacentres. I say we keep the safe default in openSUSE, and leave it to the sysadmin to do the one-line change if he or she wants to automatically purge temporary files. #3: Michal Vyskocil (mvyskocil) (2010-05-04 12:00:54) (reply to #1) The biggest reason is that this FATE does not recommend the technical solution. You're not right, the advantage is to prevent the filling of the disc on a running system. Your argument about cheaper disc space is true only if you consider new and new hardware. The existing one has typically fixed amount of disc space, should not be wasted by having a lot of unwanted data in /tmp . For instance my five year old laptop has 40GB HDD and 7GB root partition, so it is very sensitive on available space - not all SUSE are in datacenters :-). #5: Per Jessen (pjessen) (2010-05-05 13:25:22) (reply to #3) So for five years you have (presumably) managed quite well without this default setting. My argument about cheaper disk space has held true since around 2000 when disk sizes started doubling about once a year due to GMR. Not having temporary files purged was not an issue then, I see no reason why it is likely to become an issue now or later (with disk sizes continuing to grow). Neither openSUSE nor SuSE Linux have ever done such an automatic purge by default, so I maintain it is not a safe change as people may well have gotten used to keeping non- temporary data in /tmp. Given the minimal advantage, the risk of deleting non-temporary data and that changing the retention time is a matter of five seconds with vi, this is really not much of a feature. IMHO. #2: Guido Berhörster (gberh) (2010-05-04 11:41:11) Cleaning /tmp on bootup and/or periodically through a cronjob is also common practice on all other major Linux distros (e.g. Debian, Ubuntu, RHEL/Fedora, Mandriva) and UNIX(-like) OS (e.g. Solaris/Opensolaris, OpenBSD). I'd also really like to hear any use cases and reasons why users would put any valuable data in /tmp (rather than /var/tmp or their homedir) and expect it to persist indefinitely. #4: Gerald Pfeifer (geraldpfeifer) (2010-05-04 13:25:25) It's not necessarily (just) about disk size, there is also the aspect of partitioning and /tmp may not be all that large. It's also not primarily about data centers (which is not the key focus of openSUSE), but more individual users or wide spread use not necessarily governed by professional admins, and there this just reduces risk assuming we go for a somewhat conservative default (not just 24 hours). The use case is my significant other's machine (or mine), not some data center. For what it's worth, I, for one, don't want to keep all the crap that tends to pile up under /tmp for years. And non-expert users, of which we have many, will be surprised what kind of staff remains under /tmp, leaving behind a trail many won't be aware of, remaining even after months or years. #6: Per Jessen (pjessen) (2010-05-05 13:35:35) (reply to #4) Well, the non-expert user is exactly who I am worried about and why I think this feature is unsafe The non-expert user won't be aware of how the professional sysadmins would like to run things, and might just (intentionally or not) store or have stored valuable data in /tmp. Oops. Besides, I disagree about the use case - my use case is my datacentre run by professional sysadmins. (who decided what the primary target audience for openSUSE is? I thought we were still aiming to be everything for everyone.) #7: Guido Berhörster (gberh) (2010-05-05 13:51:08) (reply to #6) The non-expert user will store his data in /home/non-expert where these neatly named folders Documents, Music, Pictures etc. are. But he will fill slowly fill up his 10G rootfs by opening lots of pdfs, mp3s, archives etc. from Firefox (which are put into /tmp and never get deleted) without being aware of it , let alone how to avoid this in the first place. #8: Per Jessen (pjessen) (2010-05-05 14:07:39) (reply to #7) I'm less concerned about the new non-expert user, more about the OLD ditto who had already been using e.g. /tmp for storing non-temp data. For him this would not be a safe change, even if it was bent in neon in the Changelog. (as for Firefox using /tmp - my FF3.6 doesn't seem to store anything there?) #9: Michal Vyskocil (mvyskocil) (2010-05-06 11:20:21) (reply to #8) > I'm less concerned about the new non-expert user, more about the OLD ditto who had already been using e.g. /tmp for storing non-temp data. Are there any serious reasons why those data needs to be stored in /tmp and should not be placed elsewhere in system? I'm sure that expert you mention is fully able to understand the meaning of /tmp and place his files to other safe location. Or at least disable this behavior. As I understood your arguments - there is a bug (or rather an uncommon behavior of SUSE, if you'd preffer it), but because some people rely on that, so it might be not fixed/changed. And sorry, but that's not seems to me as a right argumentation. #11: Per Jessen (pjessen) (2010-05-06 19:41:02) (reply to #9) No, there are no real reasons why data needs to be stored in /tmp (unless they are genuinely temporary). My arguments against this are: * it is unsafe. openSUSE/SuSE Linux has not been purging /tmp at least since 4.4.1 (my first SuSE Linux).Some innocent non-expert user might very well end up having valuable data purged. * the change is so easily made that it's difficult to imagine why we are even discussing it here. * the change brings no real world benefits. #14: Guido Berhörster (gberh) (2010-05-07 00:15:20) (reply to #11) >* it is unsafe. openSUSE/SuSE Linux has not been purging /tmp at least since 4.4.1 (my first SuSE Linux).Some innocent non-expert user might very well end up having valuable data purged. That really sounds a bit far fetched. tmp is short for temporary. tem·po·rary: lasting for a limited time (in this case 10 days) >* the change is so easily made that it's difficult to imagine why we are even discussing it here. Not to the innocent non-expert user who doesn't even know that this option exists, that it is not turned on by default, and why he actually wants it changed. >* the change brings no real world benefits. It has been pointed out that several times that it prevents filling up the root patition. And not everyone has a multi-terabyte rootfs, IIRC by default the installer creates a relatively small rootfs and assigns the rest of the available space to a partition which gets mounted on /home. In effect the default setting is more likely to cause harm which is why it should be changed and why e.g. FATE#307510 was requested in the first place. #15: Per Jessen (pjessen) (2010-05-07 10:46:09) (reply to #14) Last entry on my part - in my opinion, it is not a safe change and it brings little or no real-life benefits. The default setting has caused little or no harm in the last 15 years, and it is difficult to imagine why it should become more likely to cause harm in the future. #10: Ricardo Gabriel Berlasso (rgbsuse) (2010-05-06 14:23:55) Can, please, the people who are against this provide a clear user case in which retaining these files is desirable? I really can't imagine such scenario... In the 10+ years I'm using Linux I've never see anyone using /tmp as storage folder: in fact, most people I know simply ignore the content of /tmp and /var/tmp folders. Some time ago a friend of mine had a problem with a print job which went crazy: in a few seconds a log file of several GB was created without his knowledge and afterwards he had problems to log-in in his system because the disk was full: cleaning /var/tmp was the solution. #12: Per Jessen (pjessen) (2010-05-06 20:25:36) (reply to #10) Use case: Retaining files stored in /tmp in desirable when they meant to be kept. #13: Per Jessen (pjessen) (2010-05-06 21:00:10) (reply to #12) Use case: Retaining files stored in /tmp is desirable when they were meant to be kept. #16: Ricardo Gabriel Berlasso (rgbsuse) (2010-05-07 15:38:40) (reply to #13) My first reaction to your "answer" was a mixture of "are you kidding?" with a "Wait, what?", but I will try to maintain the conversation in the right track. After all, we are here exchanging ideas. Articulated and complete ideas. Files that enters automatically in the tmp folder have no value per se in the long run (youtube videos, partial downloads, temporary image files... in /var/tmp you can also find log files which only show interesting information when something goes wrong, temporary information from kde sessions...). Some of those files are erased by the app that generated them, but some not, specially when the app crash. And as I pointed before, useless and big log files are really common, specially when there is a crash. Log files are useful only immediately after a crash, and if you set a reasonably default you will not lost them. Point is: If there is some valuable information there that needs to be kept forever it is because the user puts it on purpose ... and I cannot imagine why someone should put valuable information on a temporary directory on purpose... So, again, why we should need to keep those directories without maintenance? Or if you prefers, why there could be on those directories files meant to be kept? And which are those important files? #18: Robert Davies (robopensuse) (2010-12-19 18:53:49) (reply to #12) As per FHS, I have used files in /tmp for the Use case, that I did not care about them, and wanted them automatically deleted. /tmp is expected to be a local filesystem with fast access, and not expected to be accessible from other hosts in network or backed up. The user Home Directory or administrator project data directories, are the sane locations for "retaining files". As /tmp is a special case and well documented, the automatic purging of temporary files, which are not wanted for retention, should as a "Use Case" over turn a poorly chosen historical default in SuSE Linux. #17: Sascha Peilicke (saschpe) (2010-05-28 16:33:05) Another pro here is performance, when /tmp is kept in RAM via tmpfs, access is blazingly fast (good for large compile jobs, etc.). One issue might be a lack of sufficient physical RAM, but if /tmp needs more than what is available swap is gonna be used anyways, so /tmp ends up on disc again and should have the same performance as before. Nonetheless on a netbook or a computer with only small physical RAM available, a tmpfs solution should avoid swapping. So a /tmp size limit might be necessary. #19: Robert Davies (robopensuse) (2010-12-19 19:08:49) (reply to #17) Non-temporary /tmp files, would be the ones most likely to end up as disk pages, freed from RAM. True temporary files, probably won't (with ext3 & ext4 anyway) actually be saved onto disk before being deleted. Actually with small RAM, you WANT pages evicted (contrary to received wisdom), all the little used pages, are better in swap partition. The draw back using TMPFS is the pressure it puts the Linux VM under, and file size limits don't work as well as they used to with huge media flash files (FLV) getting saved there. I switched back to using a disk filesystem for /tmp, which makes purging MORE (not less) important, because re-boots don't automatically clean it up. #20: Satoru Matsumoto (heliosreds) (2010-12-20 09:36:52) Since 11.3 has been already released, I've changed the product from 11.3 to distribution. Please continue further discussions. #21: Malvern Star (solaris444) (2011-01-18 07:40:22) The default partition-based layout for SuSE restricts the root partition to only 20GB and uses the rest for /home (excluding swap). I have had most customers' systems become unable to reach runlevel 5 at one time or another due to their root partition being full. On new installs, I now do not allow a separate home partition to be created during install for this very reason. Plus, we still should not be too assured that lots of disk space will always be available. Some programs create temporary files of size 4GB or more. This would quickly fill /tmp if in constant use. This really should be changed to support the FHS recommendation. #24: Robert Davies (robopensuse) (2011-06-28 14:50:02) (reply to #21) Why don't you just turn on the clean up yourself, it's couple of variables in 'cron' section of sysconfig. Depriving your customers of upgrade advantages of a seperate /home, seems a drastic choice, when /tmp can be cleaned by changing '0' to '7' in 1 textfile! #22: J. Daniel Schmidt (jdsn) (2011-02-04 12:46:27) Withing one week I had two different openSUSE 11.3 machines preventing me from logging in because GBs of garbage in /tmp filled up / to 100%. This definitely needs some kind of automatic cleanup, at least in 11.4. #23: Per Jessen (pjessen) (2011-02-04 14:14:19) (reply to #22) Sounds like bug, did you report this in bugzilla? It sounds a lot like bug 633106. #25: Robert Davies (robopensuse) (2011-06-28 15:03:14) Does an "alternative" default package satisfy everyone, as sanity & reason to respect FHS is not rapidly prevailing? cron_config_SuSE_legacy - "SuSE Legacy - Eventually Fill /tmp; select to increase Support costs" cron_config_FHS_clean_tmp - "FHS - Automatic /tmp Cleanup, like real traditional UNIX" At least then selection of alternative is a simple package selection choice. #26: Philippe Baril Lecavalier (p_barill) (2012-07-30 03:10:04) A default which would purge /tmp upon each restart? As long as there's a nice way to turn that off, it should make everyone happy. I don't know of any simple one-click trick to purge the system of it's temp stuff. /var/log and /var/tmp can have some build up too. If you really insist to clean /tmp upon boot, you can always add this line to your /etc/fstab as I did some time ago: tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0 Not a sexy solution to the layman (to me it is!!). My friend, new to Linux, replied boldly "this is nuts!". #27: Peter Gumbrell (gumb) (2012-07-30 13:22:02) I've run into the problem of the temp directories filling up the root partition on older machines with smaller hard drives. I've tried to fix it by setting the retention time of /tmp to 30 days and added /var/tmp with a setting of 90 days to sysconfig via YaST. However, these settings don't always seem to be obeyed. On my previous 11.x installations the settings seemed to be ignored completely, whilst on a fresh 12.1 install I can see that although the directories are relatively clean size-wise, there are many small files well over those 30- or 90-day limits. I've also sometimes resorted to flushing the temp directories on boot via the sysconfig setting but this still leaves many old files untouched. #28: Marc Schütz (marc_schuetz) (2013-12-02 11:34:49) Same for me - in the past I had root partitions filling up several times. As the automatic clean up used to work on 12.3 and 12.2, I thought this was intentional. Indeed I believe I've seen the decision to change that on one of the numerous FATE/BNC entries, although I don't remember where exactly. But after the upgrade to openSUSE 13.3, I was quite surprised that this functionality is gone again. At first I suspected a bug, only to find out that it has been disabled explicitly: /usr/lib/tmpfiles.d/tmp.conf says "SUSE policy: we don't clean those directories" So a strong +1 from me to reenable cleaning, especially after this already has been the default for two releases. #29: Rajesh Ganesan (ganesanrajesh) (2013-12-02 11:46:29) Does not setting this feature in 'Yast2>/etc/sysconfig/cron' does this work? I regularly set this; but, had not checked whether it is really cleaned up :) #30: Bart Otten (bartotten) (2014-01-30 14:59:23) This is truly insane. Once I had lots of free space on a 20GB root partition so I decided to go for 16GB this time. After a few month KDE starts dropping out, Yast Updates start failing (pulling KDE down too : /) etc etc. /tmp was 5 Gigabyte! If I was a novice user, I would have never found a quick solution enabling me to start the GUI again and openSUSE would just be considered 'stupid cause it crashes so much'. For goodness sake, experts changes values but novice people don't. Set defaults for them and let experts script their own preferences. #31: Bart Otten (bartotten) (2014-01-30 15:18:35) @Per Jessen: Let's get personal. You are the only one here that rejects cleaning the directory. Setting the values in Yast2>/etc/sysconfig/cron does not work anymore and if you go to edit the alternative you get # SUSE policy: we don't clean those directories If people decided once to store data in a trashcan, that is up to them. Making systems crash in respect to legacy is just beyond words. Or do you never empty the trashcan at house as people might have stored something in it and you get a bigger house every 10 years anyways......? + #32: Sean Watson (futhorc) (2014-09-12 17:03:04) + For anyone who wants to know how to fix this personally, installing + tmpwatch automatically adds it to cron.daily, and the old SUSE method + was removed in Factory. -- openSUSE Feature: https://features.opensuse.org/309448

1 0

[New: openFATE 317700] Drop GRUB1 support from yast2-bootloader
by fate_noreply＠suse.de 08 Sep '14

08 Sep '14

Feature added by: Josef Reidinger (jreidinger) Feature #317700, revision 1 Title: Drop GRUB1 support from yast2-bootloader Requested by: Josef Reidinger (jreidinger) Partner organization: openSUSE.org Description: Drop grub1 support from yast2-bootloader. It will still allow to manually use grub1. Just it will drop support from installer and also configuration using yast2 bootloader module. Business case (Partner benefit): openSUSE.org: GRUB1 and GRUB2 is configured completely differently and result is that to allow yast2-bootloader support both, code contain many work-arounds and nasty code. It also allows us to focus on one supported bootloader that works for newbies. Expert can use what they need, but yast2 bootloader is focused to help new users to not be scared by bootloader and have their machine boot without problems. -- openSUSE Feature: https://features.opensuse.org/317700

1 1

[openFATE 303793] Mount /var/run as tmpfs
by fate_noreply＠suse.de 08 Sep '14

08 Sep '14

Feature changed by: Jiri Srain (jsrain) Feature #303793, revision 72 Title: Mount /var/run as tmpfs openSUSE-11.2: Rejected by Matthias Eckermann (mge1512) reject date: 2009-07-16 11:42:53 reject reason: Rejected on request of Engineering. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2010-10-06 16:02:09 reject reason: not done. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.4: Done Priority Requester: Mandatory Requested by: Kay Sievers (kay_sievers) Technical Contact: Kay Sievers (kay_sievers) Partner organization: openSUSE.org Description: /var/run should be mounted as tmpfs. This would avoid the cleaning of stale files or sockets on bootup and avoid atime updates of any mounted filesystems. This is required for eg powermanagement, which currently wakes up the system from any idle states for a socket operation. Services must be modified not to depend on a preexisting content in /var/run upon startup. RPMs must be modified to not place anything there. Documentation Impact: Administration guide. RN Discussion: #2: Federico Lucifredi (flucifredi) (2008-07-08 19:30:23) somehow SLES/SLED got out of sync here. Matching. #4: Duncan Mac-Vicar (dmacvicar) (2008-07-14 15:30:03) There are no resources for this feature. Please postpone, (as agreed with MgE) #5: Duncan Mac-Vicar (dmacvicar) (2008-07-14 15:46:55) Just as a side note this feature will require an effort of aprox. 1 week, together with #303810 (they averlap about 95%) #10: Arvin Schnell (aschnell) (2009-02-04 10:50:32) Any requirements on the size for the tmpfs or should the default of tmpfs be used? #11: Arvin Schnell (aschnell) (2009-02-05 19:27:03) (reply to #10) Kay replied by personal mail: Size doesn't matter. /var/lock should also be on tmpfs. #12: Duncan Mac-Vicar (dmacvicar) (2009-06-02 11:22:49) Christoph, please reject with openSUSE 11.2, because disk encryption we can't promise this feature for 11.2. It may get done as bonus if encryption gets done earlier than expected, but we can't commit to it (which is what rejection means, which does not mean we may work on it). It is the next thing we will work on after encryption support. #32: Dirk Mueller (dirkmueller) (2010-04-26 12:08:04) rpmlint check implemented (badness 900) #35: Duncan Mac-Vicar (dmacvicar) (2010-11-03 15:50:03) Kay, is this still feature desired now with relatime as default? or can be closed forever? #36: Kay Sievers (kay_sievers) (2010-11-03 18:52:22) (reply to #35) It is a good feature to have, because we don't want to cleanup the dir on bootup. Systemd has this mandatory and you can't even disable it. #37: Andreas Jaeger (a_jaeger) (2010-11-04 09:24:36) (reply to #35) This feature is done with using systemd. The scripts mount /var/run already and packages get fixed. I don't think any changes in YaST are needed, so I guess this can be marked as done. Duncan, please check for YaST work - and if none is needed, mark as done. #38: Arvin Schnell (aschnell) (2010-11-04 12:02:02) (reply to #37) When systemd mounts it and no entry in fstab is desired the feature is done from my side. I'm sure the mounting happens after potentially mounting /var. #39: Duncan Mac-Vicar (dmacvicar) (2013-03-05 11:29:23) Jiri, assuming SLE12 uses systemd, this feature can be marked as done. + Release Notes: /run mounted as tmpfs + Solution: + The directory /run, also sym-linked as /var/run, is mounted as tmpfs + and thus is not persistent across reboots. Anything stored in this + directory will be removed when the machine is shut down. -- openSUSE Feature: https://features.opensuse.org/303793

1 0

[New: openFATE 314594] Drop ISDN support
by fate_noreply＠suse.de 03 Sep '14

03 Sep '14

Feature added by: Thorsten Kukuk (kukuk) Feature #314594, revision 1 Title: Drop ISDN support Requested by: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: ISDN package still depends on SuSEconfig, there is nobody who is able to adjust the code, ISDN is getting less and less important. -- openSUSE Feature: https://features.opensuse.org/314594

1 14

[New: openFATE 314945] No ABI extension in glibc
by fate_noreply＠suse.de 03 Sep '14

03 Sep '14

Feature added by: Andreas Jaeger (a_jaeger) Feature #314945, revision 1 Title: No ABI extension in glibc openSUSE Distribution: New Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: Currently we have the crypt-blowfish patches in glibc that add new symbol versions to it. I consider that addition wrong and propose to find a solution (might be getting the support in upstream, or using a separate library,...) that does not extend the ABI at all. The goal should be that our glibc exports exactly the same symbols as upstream glibc does. -- openSUSE Feature: https://features.opensuse.org/314945

1 8

[openFATE 315090] Upgrade to Bluez 5
by fate_noreply＠suse.de 03 Sep '14

03 Sep '14

Feature changed by: Antoine Ginies (aginies) Feature #315090, revision 58 Title: Upgrade to Bluez 5 Requested by: Jeffrey Cheung (jeffreycheung) Partner organization: openSUSE.org Description: BlueZ 5 come with numerous new features, API simplifications and other improvements. With this release BlueZ only supports the new Bluetooth Management kernel interface that was introduced in Linux 3.4, so essentially this is the minimum kernel requirement for BlueZ 5. For Low Energy support at least kernel version 3.5 is needed. The new major version indicates that the API is not backwards compatible with BlueZ 4, which means that any applications, agents, etc will need to be updated. The BlueZ internal test scripts and tools have naturally already been updated to support the new API. The BlueZ version in SLE11 SP3 is BlueZ 4.99 which mean that regardless of new features, and improvements, we have to upgrade definitely. References: Packages: ?ofono,bluez,obex-data-server,openobex,-obexd,-obexftp - Documentation Impact: - RN Discussion: #1: Frederic Crozat (fcrozat) (2013-06-25 16:26:22) Bluez 5 can be installed in parallel with Bluez4, allowing applications not ported to BlueZ 5 API to work properly #2: Frederic Crozat (fcrozat) (2013-07-02 16:53:42) (reply to #1) it looks like I was a bit optimistic. You can only have one BlueZ installed (4 or 5) and they aren't API compatible, which requires having all BT applications moved to BlueZ 5.. #3: Jeffrey Cheung (jeffreycheung) (2013-08-05 12:06:33) So, can this fate proceed ? #4: Ludwig Nussel (lnussel) (2013-08-07 10:34:47) (reply to #3) We are past feature freeze with Milestone 4 now. I suppose this will affect the desktops so please evaluate the potential fallout and discuss on the Factory mailinglist whether it's still possible to fix the affected packages. #5: Jeffrey Cheung (jeffreycheung) (2013-08-07 11:15:59) (reply to #4) Hi Ludwig Nussel, Thanks of reminder. I already send email to factory mailing list. The current status is that RD finished the x86-64 part but i386 not yet. #6: Stefan Seyfried (seife) (2013-08-07 17:00:41) Also note that the bluez library is deprecated with bluez5, so if we want to do it "right", we should not pass --enable-library to configure. The consequence if this is that almost everything that uses bluez will break, though :-) #7: Jeffrey Cheung (jeffreycheung) (2013-08-08 15:39:18) (reply to #6) Thanks and RD acknowledged your comment. We may miss upgrade at openSUSE 13.1 and wait for 13.2 next year. However, we will keep working for SLE12. #12: Petr Tesařík (ptesarik) (2013-08-20 14:03:06) FWIW the Bluetooth stack is currently broken in Factory. At least I cannot get my BT headset to work. We would have to make our own patch to fix this bug (backporting from upstream is hard because of API changes). I'm afraid the maintenance cost in SLE12 lifetime is prohibitively high, not even daring to think about security monitoring. #16: Al Cho (acho-novell) (2013-08-21 15:02:41) (reply to #12) Hi Petr, Thanks for your comment. and Would you file a bug to me about your headset doesn't work ? ( or the bug is already there? ) I would fix it. Thanks, AL #20: Petr Tesařík (ptesarik) (2013-08-23 12:46:13) (reply to #16) The failure seems to be somewhat related to the HCI hardware, not to the bluez version. I only wanted to mention it as an example, but it wasn't a good one after all. Nevertheless, I still believe that providing L3 support for an outdated bluez version for years is too much effort. Moreover, this would be wasted effort, while helping to update dependent packages (in upstream) pays off. #13: Ondrej Holecek (oholecek) (2013-08-20 15:05:24) Note that current PulseAudio (4.0) does not support Bluez5. PulseAudio 5.0 with initial Bluez5 support was planned to release around upcoming GNOME 3.10 (end of September AFAIK) but freeze was postponed so this target was missed. #14: Petr Tesařík (ptesarik) (2013-08-21 11:50:56) (reply to #13) This is sweet. So, the same Lennart who repeatedly introduced incompatible changes in the infrastructure and asked everybody to adapt, has been unable for over a year to adapt his fine software to a similar change in the infrastructure he's using... Why am I surprized? *sigh* #18: Joey Lee (joeyli) (2013-08-23 07:06:48) Thanks for the comments from Petr, Ondrej and Scott. Per Scott's comment, looks Gnome will move to support BlueZ 5. If there doesn't have KDE in SLE-12, then I think move to BlueZ 5 in SLE-12 is make sense. This FATE highly dependent to the development progress of desktop UI(e. g. Gname, KDE) but not just replace the BlueZ package and take care the bluetooth driver in kernel. So, I suggest add desktop engineering leader and Gnome experts to this FATE to collaborative work. #19: Jeffrey Cheung (jeffreycheung) (2013-08-23 15:42:17) Very well, AL, please watch closely the gnome development. Hi Scott, can you provide your member which AL can cowork with. #25: Scott Reeves (sreeves1) (2013-08-30 17:26:23) (reply to #19) For now just directly to me. #21: Jeffrey Cheung (jeffreycheung) (2013-08-25 23:28:54) Add Some current mail thread from openSUSE factory mailing list (1) From Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org> Jeffrey, looking at where GNOME 3.10 is heading, we discuss as much as there is need for: but in the end, GNOME 3.10 will depend on BlueZ5; As such, it's much better for us to switch sooner than later; and Raymond is doing the best job there is to get KDE in line with these requirements as well. So, I would really recommend that we bite the bullet and push BlueZ5 to Factory ASAP! The good thing: we won't be alone with this: Fedora 20 will have the same setup. So we can surely profit from each other there. If we stay with Bluez4, then we have to be aware that for GNOME this might or might not work; surely, upstream support will not be given in this case. If you're planning to such tricks for SLE, I urge you to rethink such a plan. Again, for openSUSE: BlueZ5 is mainly ready, the 'legacy API' needs to be enabled (which is done by Seife) and the stuff relying on the DBUS interface needs to be made aware of the new interface (not backwards compatible). It's a one-time pain we have to take now; or we split the pain over two releases. Cheers, Dominique -- Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org> -------------------------------------------------------------------------------- (2) From Stefan Seyfried <stefan.seyfried(a)googlemail.com> Hi Jeffrey, I was the one objecting the update. But then I did not know that there is already software using (even depending on) bluez5. My impression was that there is "no need to rush" for 13.1. And when I had looked last, there was no sign of fedora using bluez5 "soon". Now that these things have changed (GNOME 3.10 depends on bluez5, KDE will most likely be able to use it) and we won't be the first and only users of bluez5, I agree with Dominique's assessment that it probably is best to switch to the newer version and not mess around with the old stuff. If only GNOME would have kept the standalone bluetooth-applet, this would be a total non-brainer since everyone could use it, but they are really trying to create vendor lock-in to their platform :-( For SLES12 anything less than bluez5 is probably a bad ide :-) Best regards, and sorry for any confusion I might have caused with my previous rejection. Stefan -- Stefan Seyfried Linux Consultant & Developer -- GPG Key: 0x731B665B #22: Al Cho (acho-novell) (2013-08-28 10:26:11) Hi All, we also need a new package "ofono" (https://ofono.org/about) if we choose move to bluez 5. Because bluez remove internal support for telephony (HFP and HSP) profiles. They should be implemented using the new Profile interface preferably by the telephony subsystem of choice ( oFono which already supports this). Cheers, AL #23: Jeffrey Cheung (jeffreycheung) (2013-08-29 11:14:27) (reply to #22) Hi Stefan, per Al, we need the new package "ofono", can we just add the package directly ? #24: Stefan Behlert (sbehlert) (2013-08-29 08:48:19) (reply to #23) Sure, if the license is ok (seems to be GPL2 if I did not misread) and there's a maintainer. I assume it will be in Factory soon? Iexpect we will notice it is required due to dependencies when we start with the SLE 12 images? #34: Al Cho (acho-novell) (2014-01-24 10:26:47) Done. Already supported on Factory. Release Notes: Bluetooth Implementation BlueZ 5 Challenge: BlueZ 4 is no longer maintained upstream. Thus upgrading to BlueZ 5 ensures that you will get all the latest upstream bug fixes and enhancements. Solution: BlueZ 5 comes with numerous new features, API simplification and other improvements such as Low Energy support. It is new major version of the Bluetooth handling daemon and utilities. Note: The new major version indicates that the API is not backwards compatible with BlueZ 4, which means that all applications, agents, etc. must be updated. -- openSUSE Feature: https://features.opensuse.org/315090

1 0

[New: openFATE 315589] Deprecate bind-mount configuration with NFSv4 export
by fate_noreply＠suse.de 02 Sep '14

02 Sep '14

Feature added by: Neil Brown (neilbrown) Feature #315589, revision 1 Title: Deprecate bind-mount configuration with NFSv4 export Requested by: Neil Brown (neilbrown) Partner organization: openSUSE.org Description: When NFSv4 was introduced it was not possible to export filesystems to NFSv4 the same way as for NFSv3. The "bind=" syntax was added to /etc/exports to help bridge the gaps. With current kernel and nfs-utils this is no longer an issue. By default any filesystem that is exported is exported equally to NFSv2, v3, and v4. So we should deprecate the "bind=" syntax and eventually remove it. This means: 1) yasts nfs-server module should remove knowledge of "Bindmount targets". The "bind=..." option should just be treated like any other option. 2) yasts nfs-server module should not encourage the "fsid=0" export option. Like "bind=" it must still be permitted, but it should be considered and exception rather than normal. 3) Yasts nfs-server help screens should remove mention of "bind=" and "fsid=0". 4) Any documentation that mentioned nfs export, such as http://doc.opensuse.org/documentation/html/openSUSE/opensuse-reference/cha.… should be changed to remove mention of bind= and fsid=, and should not make any distinciton between NFSv4 and NFSv3. Business case (Partner benefit): openSUSE.org: Simplifies administration, reduces possible confusion, remove unnecessary difference between SUSE and other distros. -- openSUSE Feature: https://features.opensuse.org/315589

1 10

[New: openFATE 309036] Add checkbox to yast2-dns-server whether to use NETCONFIG_DNS_FORWARDER="bind" or not
by fate_noreply＠suse.de 02 Sep '14

02 Sep '14

Feature added by: Marius Tomaschewski (mtomaschewski) Feature #309036, revision 1 Title: Add checkbox to yast2-dns-server whether to use NETCONFIG_DNS_FORWARDER="bind" or not openSUSE-11.3: New Priority Requester: Desirable Requested by: Marius Tomaschewski (mtomaschewski) Description: Currently, yast2-dns-server always enables and makes use of the netconfig NETCONFIG_DNS_FORWARDER="bind" feature and writes the recursive forwarder name servers specified by the user to NETCONFIG_DNS_STATIC_SERVERS (same nameserver list as in yast2-dns). This configures, that the locally running bind is used as forwarder for the system (glibc) and the bind is using the specified name servers as forwarders and allows netconfig (by default, but it depends on NETCONFIG_DNS_POLICY) to update the forwarders list via netconfig with dynamic settings, e.g. from DHCP or PPP. This behavior is usually OK, and the user can disable the updates with the DHCP/PPP/... nameservers by NETCONFIG_DNS_POLICY="STATIC" instead of "auto". But currently, yast2-dns-server does not allow to configure forwarders for e.g. non-recursive, (authorative only) name server serving some zones, without to act as forwarder/recursive name server for the local system (glibc, /etc/resolv.conf), that may use another forwarders (netconfig). To allow above configuraion, it would be required to add a checkbox to disable the current behavior and instead: * Set NETCONFIG_DNS_FORWARDER="resolver" * Write the forwardes list directly into the /etc/named.d/forwarders.conf * Call "netconfig update -m dns" (when it fails, ask the user whether to force and call "netconfig update -m dns -f") To enable current behavior again: * Reset/truncate the /etc/named.d/forwarders.conf ("cp /dev/null forwarders.conf") * Set NETCONFIG_DNS_FORWARDER="bind" * Write the forwardes list to NETCONFIG_DNS_STATIC_SERVERS * Call "netconfig update -m dns" (when it fails, ask the user whether to force and call "netconfig update -m dns -f") Relations: - Bug 576759 - yast dns vs. dns-server is poorly designed (feature/id: 576759) -- openSUSE Feature: https://features.opensuse.org/309036

1 17

[New: openFATE 308902] Configure SSSD via Yast
by fate_noreply＠suse.de 02 Sep '14

02 Sep '14

Feature added by: David Alston (dalston) Feature #308902, revision 1 Title: Configure SSSD via Yast openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: David Alston (dalston) Description: It would be great if we could configure the SSSD package (http://fedoraproject.org/wiki/Features/SSSD) for local user/password sync with either LDAP or Kerberos for offline authentication with Yast. This is related to https://features.opensuse.org/308900 This is important if OpenSUSE is interested in being a significant presence in Enterprise environments. -- openSUSE Feature: https://features.opensuse.org/308902

1 35