Re: [Fed-Talk] Put /var on a separate partition?
Re: [Fed-Talk] Put /var on a separate partition?
- Subject: Re: [Fed-Talk] Put /var on a separate partition?
- From: "Miller, Timothy J." <email@hidden>
- Date: Thu, 18 Sep 2014 12:38:06 +0000
- Thread-topic: [Fed-Talk] Put /var on a separate partition?
If a misbehaving app is spewing into syslog, you should be able to throttle or redirect that particular facility and level in syslog.conf.
-- T
>-----Original Message-----
>From: fed-talk-bounces+tmiller=email@hidden [mailto:fed-talk-
>bounces+tmiller=email@hidden] On Behalf Of John Oliver
>Sent: Wednesday, September 17, 2014 5:42 PM
>To: Apple Fed-Talk
>Subject: Re: [Fed-Talk] Put /var on a separate partition?
>
>I’m really surprised at the responses this has received.
>
>I’ve already seen one case where a version of iPhoto (which can’t be
>updated without the Ap Store, which is problematic on a network that does
>not and cannot access the Internet) starts spewing out logs at the rate of
>a gig per day or so.
>
>Having /var on it’s own partition is a layer in the onion, not an
>end-all-be-all solution for anything. And it’s still a STIG requirement.
>
>And it comes down to one of the biggest problems I have with Apple… “You
>will not use your computer your way. You’ll use it our way, and you’ll
>like it.”
>
>How long until Apple decides that something that’s useful or important to
>you is no longer to be allowed, or is to be replaced with something they
>think is better, even if it doesn’t work?
>
>Combined with their unpredictable support model, the downsides of dealing
>with Macs are rapidly overcoming the benefits. And no, we won’t be moving
>to Windows, although enterprise management would be easier. Linux or
>even
>BSD is simply far more manageable than OS X, and we don’t need to provide
>a “user experience”… we provide a platform that runs our application.
>
>
>
>
>On 9/17/14, 5:23 AM, "Miller, Timothy J." <email@hidden> wrote:
>
>>In ancient days of time sharing UNIX, we used a separate filesystem for
>>/var because /var/spool had a tendency to balloon unexpectedly (sendmail
>>and lpd, I'm looking at you), and it was safer to lose data in /var than
>>to lose work for every user currently logged in. :)
>>
>>These days of single-user UNIX with no local MTA and an infrequently used
>>print spooler, there's really no longer a point (even without a multi-TB
>>drive).
>>
>>-- T
>>
>>>-----Original Message-----
>>>From: fed-talk-bounces+tmiller=email@hidden
>>>[mailto:fed-talk-
>>>bounces+tmiller=email@hidden] On Behalf Of Marcus, Allan B
>>>Sent: Tuesday, September 16, 2014 2:19 PM
>>>To: John Oliver; Apple Fed-Talk
>>>Subject: Re: [Fed-Talk] Put /var on a separate partition?
>>>
>>>In the age of 10 TB hard drives, the need to partition out file systems
>>>is
>>>pretty unnecessary, and might only be needed for a very small group of
>>>situations. The most likely situation are poorly managed machines. You
>>>know, the ones where the admins let the hard drive get 95% full! :-)
>>>
>>>Don¹t be too quick to encourage your Chief to switch away from Mac. The
>>>probably choice will be the ³industry standard² - read Windoz.
>>>
>>>BTW, even RedHat doesn¹t recommend partitioning var
>>><https://access.redhat.com/documentation/en-
>>>US/Red_Hat_Enterprise_Linux/6/h
>>>tml/Installation_Guide/s2-diskpartrecommend-x86.html>
>>>
>>>
>>>
>>>--
>>>Thanks,
>>>
>>>Allan Marcus
>>>Chief IT Architect
>>>Los Alamos National Laboratory
>>>505-667-5666
>>>email@hidden
>>>
>>>If you always do what you always did, you will always get what you always
>>>got. [Albert Einstein]
>>>
>>>
>>>
>>>
>>>
>>>On 7/18/14, 3:34 PM, "John Oliver" <email@hidden> wrote:
>>>
>>>>Just because I could technically get around their brain-deadness with
>>>>the
>>>>hack of a symlink doesn¹t mean tearing out basic functionality that has
>>>>existed in UNIX for decades was a good idea. I want to do this the
>>>>RIGHT
>>>>way, not implement a cheesy hack.
>>>>
>>>>Sorry if I sound frustrated, but that¹s because I am. I keep finding
>>>>more
>>>>and more brain-deadness in OS X, and I jumped for joy when I heard our
>>>>ChEng wants to look at getting rid of Macs and go to something else.
>>>>
>>>>
>>>>
>>>>
>>>>On 7/18/14, 10:27 AM, "Bryan Harris" <email@hidden> wrote:
>>>>
>>>>>
>>>>>
>>>>>> On Jul 17, 2014, at 9:53 PM, "Shawn A. Geddis" <email@hidden>
>>>>>>wrote:
>>>>>>
>>>>>>> On Jul 17, 2014, at 2:40 PM, John Oliver
>>>>>>><email@hidden>
>>>>>>>wrote:
>>>>>>
>>>>>>> This seems like it should be a pretty straightforward thingŠ
>>>>>>> except, of course, Apple has to be Apple and abandon every industry
>>>>>>>standard in favor of their own silly hodgepodge.
>>>>>>
>>>>>> Specific references ?
>>>>>
>>>>>They don't separate /var file system. At least I think that's what he
>>>>>meant.
>>>>>
>>>>>Sent from my iPhone
>>>>>
>>>>>>
>>>>>>
>>>>>>> Has anyone done this, or given up in frustration?
>>>>>>
>>>>>>
>>>>>> Have you tried using links from your main storage to alternate
>>>>>>storage
>>>>>>?
>>>>>>
>>>>>> NAME
>>>>>> link, ln -- make links
>>>>>>
>>>>>> SYNOPSIS
>>>>>> ln [-Ffhinsv] source_file [target_file]
>>>>>> ln [-Ffhinsv] source_file ... target_dir
>>>>>> link source_file target_file
>>>>>>
>>>>>> DESCRIPTION
>>>>>> The ln utility creates a new directory entry (linked file) which
>>>>>>has the same modes as the original file.
>>>>>> It is useful for maintaining multiple copies of a file in many
>>>>>>places at once without using up storage for
>>>>>> the ``copies''; instead, a link ``points'' to the original copy.
>>>>>>There are two types of links; hard links
>>>>>> and symbolic links. How a link ``points'' to a file is one of
>>>>>>the
>>>>>>differences between a hard and symbolic
>>>>>> link.
>>>>>>
>>>>>> This is standard POSIX and as noted in the man page for link, ln:
>>>>>>
>>>>>> STANDARDS
>>>>>> The ln utility conforms to IEEE Std 1003.2-1992 (``POSIX.2'').
>>>>>>
>>>>>> The simplified link command conforms to Version 2 of the Single
>>>>>>UNIX Specification (``SUSv2'').
>>>>>>
>>>>>>
>>>>>> - Shawn
>>>>>> _______________________
>>>>>> Shawn Geddis
>>>>>> Security Consulting Engineer
>>>>>> Apple, Inc.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Fed-talk mailing list (email@hidden)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>talk/email@hidden
>>>>>>
>>>>>> This email sent to email@hidden
>>>
>>>
>>> _______________________________________________
>>>Do not post admin requests to the list. They will be ignored.
>>>Fed-talk mailing list (email@hidden)
>>>Help/Unsubscribe/Update your Subscription:
>>>
>>>This email sent to email@hidden
>>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden