May 2010 - openSUSE Features - openSUSE Mailing Lists

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

06 May '10

Feature changed by: Per Jessen (pjessen) Feature #309448, revision 17 Title: Clean temporary data in SUSE openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Michal Vyskocil (mvyskocil) 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. + #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. -- openSUSE Feature: https://features.opensuse.org/309448

1 0

[New: openFATE 308759] New Request Type: add or change user list
by fate_noreply＠suse.de 06 May '10

06 May '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #308759, revision 1 Title: New Request Type: add or change user list Buildservice: New Priority Requester: Desirable Requested by: Adrian Schröter (adriansuse) Description: OBS shall support a request to get added with a defined role in a project or package. In bugowner case this must replace the existing entry. -- openSUSE Feature: https://features.opensuse.org/308759

1 3

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

06 May '10

Feature changed by: Ricardo Gabriel Berlasso (RGBsuse) Feature #309448, revision 16 Title: Clean temporary data in SUSE openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Michal Vyskocil (mvyskocil) 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. + #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. -- openSUSE Feature: https://features.opensuse.org/309448

1 0

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

06 May '10

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

1 0

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

05 May '10

Feature changed by: Per Jessen (pjessen) Feature #309448, revision 14 Title: Clean temporary data in SUSE openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Michal Vyskocil (mvyskocil) 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?) -- openSUSE Feature: https://features.opensuse.org/309448

1 0

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

05 May '10

Feature changed by: Guido Berhörster (gberh) Feature #309448, revision 13 Title: Clean temporary data in SUSE openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Michal Vyskocil (mvyskocil) 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. -- openSUSE Feature: https://features.opensuse.org/309448

1 0

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

05 May '10

Feature changed by: Per Jessen (pjessen) Feature #309448, revision 12 Title: Clean temporary data in SUSE openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Michal Vyskocil (mvyskocil) 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.) -- openSUSE Feature: https://features.opensuse.org/309448

1 0

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

05 May '10

Feature changed by: Per Jessen (pjessen) Feature #309448, revision 11 Title: Clean temporary data in SUSE openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Michal Vyskocil (mvyskocil) 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. -- openSUSE Feature: https://features.opensuse.org/309448

1 0

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

04 May '10

Feature changed by: Gerald Pfeifer (GeraldPfeifer) Feature #309448, revision 9 Title: Clean temporary data in SUSE openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Michal Vyskocil (mvyskocil) 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 :-). #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. -- openSUSE Feature: https://features.opensuse.org/309448

1 0

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

04 May '10

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

1 0

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

04 May '10

Feature changed by: Guido Berhörster (gberh) Feature #309448, revision 5 Title: Clean temporary data in SUSE openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Michal Vyskocil (mvyskocil) 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. + #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. -- openSUSE Feature: https://features.opensuse.org/309448

1 0

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

04 May '10

Feature changed by: Per Jessen (pjessen) Feature #309448, revision 4 Title: Clean temporary data in SUSE openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Michal Vyskocil (mvyskocil) 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. -- openSUSE Feature: https://features.opensuse.org/309448

1 0

[New: openFATE 309327] Make scheduling strategies configurable
by fate_noreply＠suse.de 03 May '10

03 May '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #309327, revision 1 Title: Make scheduling strategies configurable Buildservice: New Priority Requester: Desirable Requested by: Adrian Schröter (adriansuse) Description: Scheduling strategies shall be configurable by project / repository via build flag attributes. * only source changes * direct dependencies only * full dependencies -- openSUSE Feature: https://features.opensuse.org/309327

1 3

[openFATE 307915] Project source link (forwarder)
by fate_noreply＠suse.de 03 May '10

03 May '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #307915, revision 1 Title: Project source link (forwarder) Buildservice: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Adrian Schröter (adriansuse) Description: For preparing maintenance updates we need a way to allow references to the :Update projects, even if a certain package does not exist there yet. This need to work for source check outs and source links. However, not for building (:Update shall not build all packages by default). A proposal to support this would be via a so called "project source link" with additional flags. Something like this for the project xml meta data: <link project="$PROJECT" /> This could be later extended to enable entire shadow builds (aka our former BETA distributions: <link project="$PROJECT"> <build repository="$REPOSITORY" arch="$ARCH"> </link> -- openSUSE Feature: https://features.opensuse.org/307915

1 5

[New: openFATE 309444] missing vncconfig app within vncserver package
by fate_noreply＠suse.de 03 May '10

03 May '10

Feature added by: Daniel Pecka (dpecka) Feature #309444, revision 1 Title: missing vncconfig app within vncserver package openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Daniel Pecka (dpecka) Description: hi suse developers, as described here in this bug https://bugzilla.novell.com/show_bug.cgi?id=591834 , i think that to change default vncserver would be rasonable if tightvnc doesn't contain vncconfig tool .. regards and have a nice day, daniel -- openSUSE Feature: https://features.opensuse.org/309444

1 0

[New: openFATE 309443] Domain Controlling Support
by fate_noreply＠suse.de 02 May '10

02 May '10

Feature added by: C F (ibm_new) Feature #309443, revision 1 Title: Domain Controlling Support openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: C F (ibm_new) Description:  Hi there! OpenSUSE has some good ways to build a small network. What I really miss is a Domain Controller Functionality Like you do have with Novell's NDS or MS Active Directory or Domain Controller functionality like in the MS 4.0 time. To have such functionality and maintain several computers centrally there are also missing several features as print sharing, users controlling, on domain level. You can build up a Domain-like infra with LDAP, but you are forced to install LDAP, configure it way to complicated if you like to have win machines added and install other stuff like kerberos. Anyway, to make a long story short. Having a way to add win-machines to a domain controller running Linux, it would outrun some major players here...and trust me, Linux will find a whole new market here! Lets face it, if you are able to build a domain infrastructure with easy handling, you will have probably lot's of people consider a new way of having administration on an alternative operating systems, which is much more reliable and faster... So the actual wish is to have an administration interface and add win machines, without hacking an configuring files and read blogs on how to. I will think about in depth if there is some interest in thinking about changing some big issues in infra here. But keep in mind that MS-AD is having a really nice interfaces on the bases of LDAP which was not MS invented! Hope to have some thoughts here, Cheers, Chris -- openSUSE Feature: https://features.opensuse.org/309443

1 0

[openFATE 300758] Show unneeded packages
by fate_noreply＠suse.de 02 May '10

02 May '10

Feature changed by: Rémy Marquis (Spyhawk) Feature #300758, revision 127 Title: Show unneeded packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Rejected by Stanislav Visnovsky (jkupec) reject date: 2009-11-30 14:20:26 reject reason: Marked as done by mistake. The feature is not done. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Desirable Projectmanager: Important Info Provider: (Novell) Requested by: JP Rosevear (jproseve) Description: The package manager should learn to show unneeded packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. #20: Vladimirs Kuzmins (vovachaka) (2009-10-26 16:27:51) This feature is a specially important, now when we have distro upgrade, which changes a lot of dependencies and a lot of obsolete packages remain installed. Please, someone implement it! #21: Thomas Göttlicher (tgoettlicher) (2009-10-26 16:41:29) I've added a view for orphaned packages in yast2-qt-pkg. There is a package group "orphaned packages" similar to "suggested packages" and "recommended packages" in yast2-qt-pkg version 2.18.17. #22: Atri Bhattacharya (badshah400) (2009-10-31 14:55:26) (reply to #21) Thanks for implementing this much needed feature. But this feature does not work with the gtk interface in 11.2 RC2; please have this added for the final release of 11.2. #23: Kornél Jahn (cornail) (2009-11-02 07:48:05) (reply to #21) Tried to test this but didn't seem to work on RC2: Orphaned packages view is empty. E.g. installed blender, which pulled yafray. After uninstalling blender, yafray remained installed but didn't show up as an orphaned package. Also installing audacity or inkscape pulled a lot of dependencies which were not showed as orphaned after uninstalling them. #24: Kornél Jahn (cornail) (2009-11-02 08:06:38) (reply to #23) Since it is marked as done, I filed a bug for it: https://bugzilla.novell.com/show_bug.cgi?id=551771 (https://bugzilla.novell.com/show_bug.cgi?id=551771) #25: Ján Kupec (jkupec) (2009-11-30 14:18:55) (reply to #21) There has been a misunderstanding here. What Thomas implemented is a view of packages that no longer have update candidates (those which are probably no longer maintained, thus 'orphaned'). This very fate request (IMO) incorrectly uses the word 'orphaned' for what is better described as "unused packages" or "no longer needed packages", or "unnecessary packages". Definitely not orphans (deborphan/rpmorphan is also a misfortunate name IMO). Anyway, whether orphan or unused, this feature is not implemented yet, thus i'm reopening it for 11.3. #26: Ján Kupec (jkupec) (2009-11-30 14:21:27) reopening for 11.3 (see comment #25) #27: Ján Kupec (jkupec) (2009-11-30 14:30:44) I suggest to call these packages unused instead of orphaned . I don't want to decide this by myself, so please speak up. Here are my arguments: 1) the word 'orphan' describes something that has lost its parent(s). In this case, it is actually the child that was lost - a package that depended on other package has been removed. The parent package is still installed, but there's no more use for it - it's unused . 2) we (and a few other distros and communities as well) already use orphaned to describe packages that are no longer cared for - unmaintained packages, packages dropped from distros. #28: Ján Kupec (jkupec) (2009-11-30 15:05:21) (reply to #27) Thomas suggests that perhaps not needed (or no longer needed ) would be better than unused since 'unused' can be confused with 'not used by user' rather than 'not used by other packages'. #29: Roberto Mannai (robermann79) (2009-11-30 15:40:37) Undependent packages : packages which don't have any(more) dependency. #30: Kornél Jahn (cornail) (2009-11-30 16:15:08) I also support the not needed / no longer needed version. Orphaned is bad since it can be misunderstood, just like "undependent package", if Roberto meant to suggest it as a description for this phenomenon. Case A: If I install manually package X, which doesn't have any dependencies nor is it referred to by any other package, it is not a "not needed" one. 'Cause it was manually installed by the user. Case B: Package X is installed automatically as a dependency while installing package Y. Package Y is then removed, but X stays, with no other package referring to it as a dependency. X is then a "not needed" package. #31: Roberto Mannai (robermann79) (2009-11-30 17:00:02) (reply to #30) +1 Kornél Regarding Case A: of course "not needed package" is a subset "undependent package" - "not needed" catches the user's point of view and it is more precise. Nevertheless, determining that "not needed" packages is a hard job, so it could be a good starting point just knowing which are the "undependent" ones (at least as a first step). #32: Roberto Mannai (robermann79) (2009-11-30 17:47:05) (reply to #31) The user could have a graphical list of "undependent packages", which then he could mark each of them as "used/not used". The GUI then could suggest the "unused packages" for removal (this being a temporary but useful use case). #33: Ken Schneider (kensch) (2009-12-15 18:15:55) When you install a package using package management it checks to make sure all dependencies are also installed or adds them to the install list via the "Requires" feature. When de-installing the package check the list of "Requires" packages and see which ones can also be de- installed. That way there are no left over packages. If one of the "Requires" packages are also needed by other packages they are left installed. I am no where near being a programmer but that would seem to be simple to do. #34: Ján Kupec (jkupec) (2009-12-15 18:47:57) (reply to #33) Such procedure would also wipe out packages that you still want to use. E.g. you have nagios-plugins-zypper, which requires zypper. Now, 'zypper remove nagios-plugins-zypper' would realize that after removing nagios-plugins-zypper nothing requires zypper, and would want to remove zypper as well. So what your idea lacks is a list of packages that were installed in the past based on explicit request by user. The procedure must avoid removing these. See also c#12 #36: Ján Kupec (jkupec) (2009-12-15 18:47:02) So i'm renaming this fate request to 'Show unneeded packages' (to make it shorter) to avoid further confustion. #37: Don Hughes (dehughes) (2009-12-15 19:10:53) I also would like to see this feature. I currently use rpmorphan with a list of things that it will mark that I know that I need. I also occationally go through yast2 and try to uninstall things that I do not recognize and see if they are flagged as being needed by something else. Both time consuming and error prone. And, a lot of packages seem to be some what careless in what the require for prereqs - pulling in KDE,gnome, and X11 packages on text- only machines for example; which then triggers a flood of KDE, gnome, and X11 library installations which I then have to mannually uninstall and mark as taboo. On my external facing servers I do not like to have any extra/unneeded/unwanted packages to provide possible attack vectors. #39: Rafael Belmonte (eaglescreen) (2010-01-10 22:43:40) Hello, this is one of the main causes of I use more Debian/Ubuntu than OpenSuse. Debian & Ubuntu already have this implemented. I think this is a fundamental aspect to work in OpenSuse. Debian & Ubuntu can distinguish packages that were manually installed and packages that were installed just to satisfy dependencies. OpenSuse needs to do this too. #40: Tim Edwards (tk83) (2010-01-27 15:46:00) I'd also like to see this, Mandriva added it in a couple of releases ago and it's great. It's really missing in Opensuse #41: Eduard Huguet (eduardhc) (2010-03-02 15:55:43) (reply to #40) Agreed. Being a long time user of both Gentoo and Ubuntu, I was really shocked to discover that zypper was lacking this feature. Even more: when talking about Linux with friends I always make mention of this kind of "autoremove unneeded" option as one of the strong points of Linux package managing systems, as I was really taking for granted that any package manager out there had this feature included... Regards. + #42: Rémy Marquis (spyhawk) (2010-05-02 17:13:32) + Michael Andres started to implement this feature in Libzypp 7.4, + see http://lists.opensuse.org/zypp-devel/2010-04/msg00033.html -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[New: openFATE 309441] GTK look more Qt-ish under KDE
by fate_noreply＠suse.de 02 May '10

02 May '10

Feature added by: Drew Adams (Druonysus) Feature #309441, revision 1 Title: GTK look more Qt-ish under KDE openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Drew Adams (druonysus) Description: When installing Banshee(or other gtk packages) under KDE I would like to see Banshee(or others) intergrate with KDE better. I quess what I am trying to say is that I would like to see GTK programs look and feel more native under KDE environment. -- openSUSE Feature: https://features.opensuse.org/309441

1 1