December 2010 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 310858] add apache2-mod_wsgi
by fate_noreply＠suse.de 20 Dec '10

20 Dec '10

Feature added by: Christopher Yeleighton (yecril71pl) Feature #310858, revision 1 Title: add apache2-mod_wsgi openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Christopher Yeleighton (yecril71pl) Partner organization: openSUSE.org Description: The package apache2-mod_python is discontinued. Please add apache2-mod_wsgi instead. Please add it to patterns-openSUSE-lamp_server. Use Case: This package is increases the efficiency of Web applications written in Python. Business case (Partner benefit): openSUSE.org: apache2-mod_python is discontinued but it is still installed with patterns-openSUSE-lamp_server. -- openSUSE Feature: https://features.opensuse.org/310858

1 2

[New: openFATE 308440] Official Screensaver
by fate_noreply＠suse.de 20 Dec '10

20 Dec '10

Feature added by: Quentin Denis (queden) Feature #308440, revision 1 Title: Official Screensaver openFATE: Unconfirmed Priority Requester: Desirable Requested by: Quentin Denis (queden) Description: What about an official screensaver for openSUSE? Like Windows always has had, something humble and soft, but stylish! Currently there is no useful screensaver, either they're to crappy or to agressive. Regards, Quentin -- openSUSE Feature: https://features.opensuse.org/308440

1 7

[New: openFATE 310162] BeOS like menu for OpenSUSE
by fate_noreply＠suse.de 20 Dec '10

20 Dec '10

Feature added by: Andres Silva (anditosan) Feature #310162, revision 1 Title: BeOS like menu for OpenSUSE openSUSE-11.4: Unconfirmed Priority Requester: Desirable Requested by: Andres Silva (anditosan) Description: Well, I am not much of a historian when it comes to computers. I do study history though, but of the Middle East in college. This is the thing though. There used to be a very nice operating system back in the 2000s called BeOS. I got to download the iso image (about 50 MB) and installed it on an old Compaq computer and booted it with a diskette. This small operating system had many bugs but it was at the same time very capable. I really enjoyed playing with it. The system was then not too popular and PALM bought it. That was the end of it as a free operating system and then other projects came out of it, like HAIKU and Zeta. Just imitations of the original system but this time based on Linux. One of the things that impressed me the most about this system was its revolutionary System Menu. Unlike Windows, it was located at the top right of the screen. It was not a panel styled menu, it was rather like a box that expanded and contracted depending on the applications that you were running. If you right-clicked it, then you would be able to get the actual menu with all the applications installed on your computer... anditosan.blogspot.com -- openSUSE Feature: https://features.opensuse.org/310162

1 4

[New: openFATE 310159] Create the YaST2 modules, so you can make the complete inst. and conf. of Neatx.
by fate_noreply＠suse.de 20 Dec '10

20 Dec '10

Feature added by: Genix Info (genixinfo) Feature #310159, revision 1 Title: Create the YaST2 modules, so you can make the complete inst. and conf. of Neatx. openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Genix Info (genixinfo) Description: Create the YaST2 modules, so you can make the complete installation and configuration of Neatx (NX server). About Neatx (NX server): http://en.wikipedia.org/wiki/Neatx http://code.google.com/p/neatx/ -- openSUSE Feature: https://features.opensuse.org/310159

1 2

[New: openFATE 310158] Add the FISH (SSH) in Konqueror and also in other file managers.
by fate_noreply＠suse.de 20 Dec '10

20 Dec '10

Feature added by: Genix Info (genixinfo) Feature #310158, revision 1 Title: Add the FISH (SSH) in Konqueror and also in other file managers. openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Genix Info (genixinfo) Description: Add the FISH (SSH) in Konqueror and also in other file managers. About FISH (SSH) in Konqueror: Can act as a Konqueror file manager for local files But also, through FTP, WebDAV or other protocols, as a file manager for files on remote machines. The FISH ("fish: / / user @ host") protocol Can Be Used to manipulate files through SSH, Allowing you to use the Konqueror the file manager for almost any machine Can you connect to on the internet. Add this and other features of Konqueror, Konqueror in itself and also in other file managers. Source and more details: http://www.konqueror.org/features/ -- openSUSE Feature: https://features.opensuse.org/310158

1 4

[New: openFATE 309644] Novell Client for Linux (for openSUSE)
by fate_noreply＠suse.de 20 Dec '10

20 Dec '10

Feature added by: Dominique Leuenberger (dimstar) Feature #309644, revision 1 Title: Novell Client for Linux (for openSUSE) openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Dominique Leuenberger (dimstar) Partner organization: openSUSE.org Description: I can't specify openSUSE 11.3(+1), thus selecting 11.3, even though I know this will not happen (time constraints). There are several openSUSE users that depend on having access to their Novell File Servers (NetWare, OES2) running NCP/NSS. At least in our company, CIFS is not enabled on any of those servers, thus novfs is the only solution. Typically with some hacking it is possible to get the latest released NCL (currently 2.0 as per download.novell.com, even though SLE11SP1 contains NCL3.0!) to work, but it is hackisch and far from optimal. I would appreciate if NCL could be provided in the NON-Free repo and up-to-date (or even better: if NCL could be opened up and put in OSS repo *dreaming* ) If there is a pure question of packaging effort, I already offered, and offer again, to provide such packages based on an NDA, built in my personal instance of an OBS and publishing them wherever Novell sees a fit for them). Use Case: A company running Novell Servers might want to access them from within an openSUSE desktop Business case (Partner benefit): openSUSE.org: It would be great if a Novell sponsored distribution would be the easiest one out there to talk to a Novell Server platform. -- openSUSE Feature: https://features.opensuse.org/309644

1 8

[New: openFATE 311001] create a build-essential metapackage
by fate_noreply＠suse.de 20 Dec '10

20 Dec '10

Feature added by: Bernhard Wiedemann (bmwiedemann) Feature #311001, revision 1 Title: create a build-essential metapackage Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Bernhard Wiedemann (bmwiedemann) Partner organization: openSUSE.org Description: This feature is a continuation of https://bugzilla.novell.com/show_bug.cgi?id=657607 I agreed with J.W. that there should be a "build-essential" meta-package that depends on things like gcc, make, automake. Those are always pre-installed in OSB and thus missing from the explicit BuildRequires list of packages. Currently, the exact list of implicit BuildRequires might only be known in the osc build script. This build-essential could then be fetched by "zypper si PACKAGENAME" and also be used in OBS to not have to maintain the list of packages in two places. Test Case: # using cucumber notation - see http://cukes.info Scenario: compiling with rpmbuild When I run "zypper -n si freetype2" Then it should have "build-essential gcc make automake" installed afterwards When I run "rpmbuild -bb /path/to/freetype2.spec" Then it should produce files in "/usr/src/packages/RPMS/*/freetype*.rpm Use Case: Michael is a software developer who wants to compile a single rpm from source just for his system, but can not use "osc build" because he has only limited disk-space or no root-access. -- openSUSE Feature: https://features.opensuse.org/311001

1 1

[openFATE 309448] Clean temporary data in SUSE
by fate_noreply＠suse.de 20 Dec '10

20 Dec '10

Feature changed by: Satoru Matsumoto (HeliosReds) Feature #309448, revision 27 Title: Clean temporary data in SUSE - openSUSE-11.3: Unconfirmed + openSUSE Distribution: New Priority - Requester: Mandatory + 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. -- openSUSE Feature: https://features.opensuse.org/309448

1 0

[openFATE 309448] Clean temporary data in SUSE
by fate_noreply＠suse.de 19 Dec '10

19 Dec '10

Feature changed by: Robert Davies (robopensuse) Feature #309448, revision 26 Title: Clean temporary data in SUSE openSUSE-11.3: Unconfirmed Priority Requester: Mandatory 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. -- openSUSE Feature: https://features.opensuse.org/309448

1 0

[openFATE 309448] Clean temporary data in SUSE
by fate_noreply＠suse.de 19 Dec '10

19 Dec '10

Feature changed by: Robert Davies (robopensuse) Feature #309448, revision 25 Title: Clean temporary data in SUSE openSUSE-11.3: Unconfirmed Priority Requester: Mandatory 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. -- openSUSE Feature: https://features.opensuse.org/309448

1 0