<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: /tmp &amp;amp; /var/tmp Questions in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095973#M806845</link>
    <description>Thanks so much for the various answers and inputs. It look like we will need to turn world sticky bitting so only the creator/owners can remove files/dirs in those 2 directories. We have an 8 GB /var and 2GB /tmp (fpr those rougue apps..) as this a very heavily used development system with about 200 users active at anyone time using about a dozen variations of VI and 3 versions of Emacs plus all the compilers known to man!&lt;BR /&gt;.&lt;BR /&gt;BTW, on this rp8400 that I've been building (coming out of an ersthwhile all-Solaris shop) - I am just following configuring instructions -- one of which is "mv /var/tmp to /var/tmp.orig, and create a link /var/tmp to /tmp.." -- which I am questioning..&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
    <pubDate>Fri, 17 Oct 2003 09:00:51 GMT</pubDate>
    <dc:creator>Alzhy</dc:creator>
    <dc:date>2003-10-17T09:00:51Z</dc:date>
    <item>
      <title>/tmp &amp; /var/tmp Questions</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095966#M806838</link>
      <description>1.\ What should be the proper permissions of /tmp on 11i systems? On Solaris it is drwxrwxrwt.&lt;BR /&gt;2.\ Same question for /var/tmp. On Solaris it is as well drwsrwxrwt.&lt;BR /&gt;3.\ Which should be bigger /tmp or /var/tmp?&lt;BR /&gt;4.\ How are you managing/cleaning up /tmp&amp;amp; /var/tmp.&lt;BR /&gt;5.\ Any reason why /var/tmp should be a link to /tmp?&lt;BR /&gt;.&lt;BR /&gt;Thanks!&lt;BR /&gt;</description>
      <pubDate>Fri, 17 Oct 2003 08:30:15 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095966#M806838</guid>
      <dc:creator>Alzhy</dc:creator>
      <dc:date>2003-10-17T08:30:15Z</dc:date>
    </item>
    <item>
      <title>Re: /tmp &amp; /var/tmp Questions</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095967#M806839</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;1 &amp;amp; 2 ) Normally there both drwxrwxrxw but i should go for the sticky bit turned on, like on Solaris.&lt;BR /&gt;&lt;BR /&gt;3) It depents on the size of the server and the need for temp files. &lt;BR /&gt;I would make &lt;BR /&gt;/tmp &amp;gt;1GB&lt;BR /&gt;/var/tmp   = in the var filesystemen depents on internal memory and the need for /var/adm/crash&lt;BR /&gt;&lt;BR /&gt;4) cron script. find /tmp -ctime +7 -exec rm {}/;&lt;BR /&gt;&lt;BR /&gt;Gideon&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 17 Oct 2003 08:40:10 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095967#M806839</guid>
      <dc:creator>G. Vrijhoeven</dc:creator>
      <dc:date>2003-10-17T08:40:10Z</dc:date>
    </item>
    <item>
      <title>Re: /tmp &amp; /var/tmp Questions</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095968#M806840</link>
      <description>Nelson,&lt;BR /&gt;&lt;BR /&gt;Permissions:&lt;BR /&gt;&lt;BR /&gt;ll -d /tmp /var/tmp&lt;BR /&gt;drwxrwxrwx   3 bin        bin           6144 Oct 17 08:39 /tmp&lt;BR /&gt;drwxrwxrwx   3 bin        bin           1024 Oct 17 09:34 /var/tmp&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Size:  /tmp can be small - like 64MB, /var (and therefore /var/tmp) I make fairly large, like 1GB&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Cleaning:  Hose them during bootup or via cron, there's no reason the retain anything - or, if there is something that needs to be retained, it needs to be placed somewhere else.&lt;BR /&gt;&lt;BR /&gt;Link:  No reason that I can think of.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Pete&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 17 Oct 2003 08:40:44 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095968#M806840</guid>
      <dc:creator>Pete Randall</dc:creator>
      <dc:date>2003-10-17T08:40:44Z</dc:date>
    </item>
    <item>
      <title>Re: /tmp &amp; /var/tmp Questions</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095969#M806841</link>
      <description>1.)  777 is right.&lt;BR /&gt; &lt;BR /&gt;2.)  &lt;BR /&gt; &lt;BR /&gt;3.)  Up to you.  I will make /tmp no smaller than 512 mb if there's a /work file system.  But I'll also go up to 4 gb also.&lt;BR /&gt; &lt;BR /&gt;4.) /etc/rc.config.d/clean_tmps&lt;BR /&gt;4B)  /sbin/init.d/clean_ex start/stop&lt;BR /&gt; &lt;BR /&gt;5) Any recursive navigation becomes dangerous since /var/tmp belongs to a critical O/S file system.  What would happen if someone issued a 'chmod -R 777' in /tmp and /var/tmp was soft linked?&lt;BR /&gt; &lt;BR /&gt;Remember, /tmp is world writeable.</description>
      <pubDate>Fri, 17 Oct 2003 08:41:39 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095969#M806841</guid>
      <dc:creator>Michael Steele_2</dc:creator>
      <dc:date>2003-10-17T08:41:39Z</dc:date>
    </item>
    <item>
      <title>Re: /tmp &amp; /var/tmp Questions</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095970#M806842</link>
      <description>1,2. All my systems have drwxrwxrwx with bin:bin as owner for both /tmp and /var/tmp.&lt;BR /&gt;3,5. Strange questions, since /var/tmp is neither a separate filesystem nor a link.&lt;BR /&gt;4. Under normal circumstances these directories don'r require special cleaning routines.</description>
      <pubDate>Fri, 17 Oct 2003 08:44:28 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095970#M806842</guid>
      <dc:creator>Vitek Pepas</dc:creator>
      <dc:date>2003-10-17T08:44:28Z</dc:date>
    </item>
    <item>
      <title>Re: /tmp &amp; /var/tmp Questions</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095971#M806843</link>
      <description>1. This is sysadmin's choice. By setting the t permission, only file owners are allowed to move or remove a file. Most security experts will recommend setting the t bit (sticky bit) to ensure some degree of sanity with temp directories. Of course /tmp (and /var/tmp) are temporary...&lt;BR /&gt; &lt;BR /&gt;2. Same answer as #1. chmod 1777 /tmp /var/tmp&lt;BR /&gt; &lt;BR /&gt;3. /var should be gigabytes (/var/tmp is a subset of /var) and /tmp should be just a few hundred megs. /var is the most critical directory in Unix and can affect many different subsystems when it gets full. That's one of the reasons to split /var into separate mountpoints for certain subsystems (ie, mail, spooling, software distributor, craash dumps, etc)&lt;BR /&gt; &lt;BR /&gt;4. NEVER! /tmp (based on the decade-old V.4 filesystem layout rules is ONLY for system ua\sage and never to be used as temp storage for scripts and user junk. Of course, this isn't what typical Unix newbies do and there are still plenty of applications and old scripts that use /tmp. By keeping /tmp separate, you can find rogue files and directories and fix the cause (including user education). Unfortunately, even HP instructions for some apps and packages will say something like: ftp the files into /tmp...without regard to the V.4 recommendations or the possibly small /tmp.&lt;BR /&gt; &lt;BR /&gt;The correct location for temp files and directories is /var/tmp. As always, regular cron cleanup of these directories is required.</description>
      <pubDate>Fri, 17 Oct 2003 08:48:37 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095971#M806843</guid>
      <dc:creator>Bill Hassell</dc:creator>
      <dc:date>2003-10-17T08:48:37Z</dc:date>
    </item>
    <item>
      <title>Re: /tmp &amp; /var/tmp Questions</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095972#M806844</link>
      <description>1. 1777 (rwxrwxrwt) is the best way for /tmp&lt;BR /&gt;2. I have no clue what the 's' bit for user does on a directory, but on my solaris 8 systems it is the same as for /tmp&lt;BR /&gt;3. Depends on your applications.&lt;BR /&gt;4. cleaning by cron is a good way. Cleaning at boottime only works if your system is booted regularly. But at the sites I've worked systems ran for multiple years without reboot...&lt;BR /&gt;5. if the usage of /tmp and /var/tmp are not the same during the day, you can use 1 filesystem for both to make more efficient use of the filesystem. But remember that it is good practice to have a /tmp on vg00 to have it available as soon as possible, so this only works with enough diskspace in vg00.</description>
      <pubDate>Fri, 17 Oct 2003 08:53:33 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095972#M806844</guid>
      <dc:creator>Elmar P. Kolkman</dc:creator>
      <dc:date>2003-10-17T08:53:33Z</dc:date>
    </item>
    <item>
      <title>Re: /tmp &amp; /var/tmp Questions</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095973#M806845</link>
      <description>Thanks so much for the various answers and inputs. It look like we will need to turn world sticky bitting so only the creator/owners can remove files/dirs in those 2 directories. We have an 8 GB /var and 2GB /tmp (fpr those rougue apps..) as this a very heavily used development system with about 200 users active at anyone time using about a dozen variations of VI and 3 versions of Emacs plus all the compilers known to man!&lt;BR /&gt;.&lt;BR /&gt;BTW, on this rp8400 that I've been building (coming out of an ersthwhile all-Solaris shop) - I am just following configuring instructions -- one of which is "mv /var/tmp to /var/tmp.orig, and create a link /var/tmp to /tmp.." -- which I am questioning..&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 17 Oct 2003 09:00:51 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095973#M806845</guid>
      <dc:creator>Alzhy</dc:creator>
      <dc:date>2003-10-17T09:00:51Z</dc:date>
    </item>
    <item>
      <title>Re: /tmp &amp; /var/tmp Questions</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095974#M806846</link>
      <description>1) proper permissions? I suppose "proper" would have to be dependant on what is necessary for your organization.&lt;BR /&gt;&lt;BR /&gt;we use world read/write, 777.  setting the sticky bit can be nice.  Then, only the user that owns the file can remove it.  This leads to a couple of issues.  1)what happens when it fills up.  If only the user can remove his files and, of course, root, guess who gets call when a user fills the file system up. I don't like getting called. 2) the user thinks his files are going to remain.  Guess who gets called when the user files get removed.  I don't like getting called because a user's temporary files turn out to be temporary.&lt;BR /&gt;&lt;BR /&gt;So, are policy is 777.  anyone with a problem with not enough space can do their own clean up without needing to call someone (or me).  And, if users need space to keep files on a non-temporary basis that only they can remove, that is what their home directory is for.&lt;BR /&gt;&lt;BR /&gt;which should be bigger?  &lt;BR /&gt;&lt;BR /&gt;make /var/temp being a seperate file system and make it big, at least a gig. Have all users/application use this for temporary files. Make it more then big enough so they stay out of /tmp.  keep /tmp small.  upgrades to the OS use /tmp.  I've been required to have over 128M on earlier releases and 11i's release notes says your should have at least 256M.  Being disk space is cheap, I'd make /tmp 512M.&lt;BR /&gt;&lt;BR /&gt;clean up?&lt;BR /&gt;we try to keep files around for 30 days before removing them.  But, if the file systems reach 90% they get cleaned. But, once again, users know these are just temporary files and there isn't any garantee on how long they will stay.  &lt;BR /&gt;&lt;BR /&gt;link?&lt;BR /&gt;&lt;BR /&gt;I suppose, if /var/temp is a seperate file system, /tmp could be a link.  I prefer to keep /tmp seperate and reserved only for the OS's use. users/applications have their space (/var/temp), root/OS has their space (/tmp).  no one gets stepped on and everyone stays happy.</description>
      <pubDate>Fri, 17 Oct 2003 09:25:58 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095974#M806846</guid>
      <dc:creator>curt larson_1</dc:creator>
      <dc:date>2003-10-17T09:25:58Z</dc:date>
    </item>
    <item>
      <title>Re: /tmp &amp; /var/tmp Questions</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095975#M806847</link>
      <description>Here is a clean command that is fairly secure (probably not completely though):&lt;BR /&gt;&lt;BR /&gt;It won't cross mount points, won't delete anything owned by root, and will only delete files. All of this is done to mitigate the risk of someone trying to introduce a trojan link pointing to /etc/passwd or some other critical file.&lt;BR /&gt;&lt;BR /&gt;#!/bin/sh&lt;BR /&gt;set -u&lt;BR /&gt;&lt;BR /&gt;PATH=/bin:/usr/bin:/sbin:/usr/sbin&lt;BR /&gt;&lt;BR /&gt;for i in /tmp /var/tmp&lt;BR /&gt;do&lt;BR /&gt;find $i ! -user root \( -atime +21 -a -mtime +21 \) -xdev -type f | xargs -L300 rm -f&lt;BR /&gt;done&lt;BR /&gt;&lt;BR /&gt;Also, I agree with everyone else. Change /var/tmp and /tmp to 1777. Better yet, run Bastille as it will do this and lot more to secure your system.&lt;BR /&gt;&lt;BR /&gt;HTH.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 17 Oct 2003 09:37:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095975#M806847</guid>
      <dc:creator>Brian Bergstrand</dc:creator>
      <dc:date>2003-10-17T09:37:00Z</dc:date>
    </item>
    <item>
      <title>Re: /tmp &amp; /var/tmp Questions</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095976#M806848</link>
      <description>Nelson,&lt;BR /&gt;&lt;BR /&gt;Where did you run into this configuration instruction?&lt;BR /&gt;&lt;BR /&gt;"mv /var/tmp to /var/tmp.orig, and create a link /var/tmp to /tmp.." &lt;BR /&gt;&lt;BR /&gt;I've never heard of such a thing!&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Pete&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 17 Oct 2003 09:40:42 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095976#M806848</guid>
      <dc:creator>Pete Randall</dc:creator>
      <dc:date>2003-10-17T09:40:42Z</dc:date>
    </item>
    <item>
      <title>Re: /tmp &amp; /var/tmp Questions</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095977#M806849</link>
      <description>1) Permissions are rwxrwxrwxt&lt;BR /&gt; &lt;BR /&gt;2) Linked to /tmp&lt;BR /&gt; &lt;BR /&gt;3) Linked to /tmp&lt;BR /&gt; &lt;BR /&gt;4) 10 day cleanup script from cron...&lt;BR /&gt; &lt;BR /&gt;5) My boxes all have /var/tmp linked to /tmp... b/c some Applications are hard coded to put temp data to /var/tmp instead of /tmp.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 17 Oct 2003 10:36:41 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tmp-amp-var-tmp-questions/m-p/3095977#M806849</guid>
      <dc:creator>Todd McDaniel_1</dc:creator>
      <dc:date>2003-10-17T10:36:41Z</dc:date>
    </item>
  </channel>
</rss>

