zfs discuss - Dec 2008 - To separate /var or not separate /var, that is the question....

Whether tis nobler.....

Just wondering if (excepting the existing zones thread) there are any compelling
arguments to keep /var as it''s own filesystem for your typical Solaris
server.  Web servers and the like.

Or arguments against it.
-- 
This message posted from opensolaris.org

vincent_b_fox at yahoo.com said:
> Just wondering if (excepting the existing zones thread) there are any
> compelling arguments to keep /var as it''s own filesystem for your
typical
> Solaris server.  Web servers and the like. 
Well, it''s been considered a "best practice" for servers for
a lot of
years to keep /var/ as a separate fileystem:

(1) You can use special mount options, such as "nosuid", which
improves
    security.  E.g. world-writable areas (/var/tmp) cannot be seeded with
    a trojan or other privilege-escalating attack.

(2) You can limit the size, preventing a non-privileged process from
    using up all the system''s disk space.

If you don''t believe me, go read Sun''s own Blueprints
books/articles.

Personally, I''d like to place a limit on /var/core/;  That''s
the only
consistent "out of disk space" cause I''ve seen on our
Solaris-10 systems,
and that happens whether /var/ is separate or not.  Maybe /var/crash/
as well.

Regards,

Marion

Vincent Fox wrote:
> Whether tis nobler.....
>
> Just wondering if (excepting the existing zones thread) there are any
compelling arguments to keep /var as it''s own filesystem for your
typical Solaris server.  Web servers and the like.
>   
IMHO, the *only* good reason to create a new file system is if you
wish to implement a different policy.  For your convenience, policies
knobs can be seen via "zfs get all file_system"
> Or arguments against it.
>   
That is easy... it is more work and therefore more costly.
 -- richard

Vincent Fox wrote:
> Whether tis nobler.....
> 
> Just wondering if (excepting the existing zones thread) there are any
compelling arguments to keep /var as it''s own filesystem for your
typical Solaris server.  Web servers and the like.
> 
> Or arguments against 
with zfs it''s easy to set quotas so not really necessary, in ufs world,
it was just easier to keep var on a seperate disk slice etc, so that the 
  root FS would not fill with log files, patch data and or core dumps etc

Enda

Marion Hakanson wrote:
>
> Personally, I''d like to place a limit on /var/core/; 
That''s the only
> consistent "out of disk space" cause I''ve seen on our
Solaris-10 systems,
> and that happens whether /var/ is separate or not.  Maybe /var/crash/
> as well.
>
>   
You can specify the volsize on /rpool/dump on a zfs boot system.

-- 
Ian.

It just seems like in a typical ZFS root install the need for a separate /var is
difficult for me to justify now.  By default there are no quotas or reservations
set on /var.   Okay I set them.

I have a monitoring system able to tell me when "disks" are getting
full.  It seems easier to say just warn me when slash approaches 80% than to
monitor slash and var and that and that.....

For that matter I''ve thought perhaps monitoring just space free in the
pool instead of filesystems.
Just look for zpool list rpool above 80% in the CAP column.
-- 
This message posted from opensolaris.org

>>>>> "vf" == Vincent Fox <vincent_b_fox at
yahoo.com> writes:
    vf> the need for a separate /var is difficult for me to justify
    vf> now.

so long as you keep the word ``me'''' in there!  great that you
don''t
need it, but it''s not difficult to justify.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20081211/d357c24a/attachment.bin>

Miles Nordin wrote:
>>>>>> "ic" == Ian Collins <ian at
ianshome.com> writes:
>>>>>>             
>
>       >  Personally, I''d like to place a limit on /var/core/;
>
>     ic> You can specify the volsize on /rpool/dump on a zfs boot
>     ic> system.
>
> so what?  so you can truncate each core dump to make it useless before
> they are all copied one after another into /var/core each time the
> machine reboots, filling up / with truncated core dumps instead of
> full ones?
>   
I was simply pointing out that there is a limit on /var/crash/, nothing
more.

/rpool/dump is a volume, so it has a fixed size.  I normally increase this size
because the default tends to be too small, leaving truncated crash dumps.

-- 
Ian.

Hello,

Slightly off-topic, but only slightly.
With ZFS I tend to configure /var/cores as a separate zfs file system
with a quota set on it + coreadm configured that way so all cores go
to /var/cores.

This is especially useful with in-house applications running on
servers.



-- 
Best regards,
 Robert Milkowski                           mailto:milek at task.gda.pl
                                       http://milek.blogspot.com

On Fri, Dec 12, 2008 at 12:04:39AM +0000, Robert Milkowski
wrote:
> Slightly off-topic, but only slightly.
> With ZFS I tend to configure /var/cores as a separate zfs file system
> with a quota set on it + coreadm configured that way so all cores go
> to /var/cores.
> 
> This is especially useful with in-house applications running on
> servers.
Indeed.

Having /var itself as a separate dataset is not worthwhile and serves
only to complicate BE management (since you want to pair /var/svc with
/, no?).  But for specific sub-directories of /var using common datasets
can be very useful.

BTW, it''s been useful to have separate /var/adm/messages too: it helps
track which BE was last booted :)

Robert Milkowski wrote:
> Hello,
>
> Slightly off-topic, but only slightly.
> With ZFS I tend to configure /var/cores as a separate zfs file system
> with a quota set on it + coreadm configured that way so all cores go
> to /var/cores.
>   
While this might cause some issues with programs that expect or don''t
expect separate file systems under /var, there is no real reason to put it
in /var.  You could just as easily put the file system in /xzy/acb and
make the appropriate change via coreadm.
> This is especially useful with in-house applications running on
> servers.
>   
Not a bad idea.  You might also consider having a centralized core
saving machine --  /xzy/acb above could be NFS mounted.

NB. In OpenSolaris, savecore is disabled by default so /var/crash should
not collect cores, by default.  You can always dump the last kernel core
by running savecore at your leisure.  You can also send savecore''s
output
to another directory somewhere.
 -- richard