유닉스 서버 파티셔닝 및 파일 시스템 레이아웃

인터넷에서 유닉스 서버 파티셔닝에 대한 모순되는 정보가 많이 있으므로 진행 방법에 대한 조언이 필요합니다.

지금까지 테스트 환경의 서버에서는 실제로 파티셔닝에 신경 쓰지 않았고 단일 모 놀리 /식과 스왑 파티션을 구성했습니다 . 이 파티셔닝 구성표는 프로덕션 서버에는 좋은 생각이 아닙니다. 여기서 좋은 출발점을 찾았 지만 세부 사항에 대해서는 매우 모호한 것 같습니다.

기본적으로 기본 LAMP 스택 (Apache, PHP 및 MySQL)을 실행할 서버가 있습니다. 파일 업로드를 처리해야합니다 (최대 2GB). 시스템에는 2TB RAID 1 어레이가 있습니다.

나는 설정할 계획이다 :

/         100GB 
/var     1000GB (apache files and mysql files will be here), 
/tmp      800GB (handles the php tmp file)
/home      96GB
swap        4GB

이 소리가 제정신입니까, 아니면 너무 복잡한 것입니까?

파티션을 배치 할 때 명심해야 할 것은 실패 모드입니다. 일반적으로이 질문은 "파티션 x 가 가득 차면 어떻게됩니까 ?" 가장 귀중한 voretaq7은 /문제를 진단하기 어려운 수많은 원인으로 상황을 일으켰습니다 . 좀 더 구체적인 상황을 봅시다.

로그를 저장하는 파티션이 가득 차면 어떻게됩니까? 감사 /보고 데이터가 손실되고 공격자가 때때로 자신의 활동을 숨기는 데 사용됩니다. 로그인 이벤트를 기록 할 수없는 경우 시스템에서 새 사용자를 인증하지 않는 경우도 있습니다.

/var가득 차면 RPM 기반 시스템에서 어떻게됩니까 ? 패키지 관리자는 패키지를 설치 또는 업데이트하지 않으며 구성에 따라 자동으로 실패 할 수 있습니다.

특히 사용자가 쓸 수있는 파티션을 채우는 것이 쉽습니다. 재미있게이 명령을 실행하여 얼마나 큰 파일을 얼마나 빨리 만들 수 있는지 확인하십시오 cat /dev/zero > zerofile.

파티션을 채울뿐만 아니라 다른 마운트 지점에 위치를 배치 할 때 마운트 옵션을 사용자 정의 할 수도 있습니다.

로 /dev/마운트되지 않은 경우 어떻게됩니까 noexec? 일반적으로 OS에 의해 유지 관리되고 악성 프로그램을 숨기는 데 자주 사용되는 장치 만 포함되는 것으로 간주 되기 때문 /dev입니다. 그대로두면 noexec저장된 바이너리를 실행할 수 있습니다.

이러한 모든 이유와 그 이상으로 인해 많은 강화 안내서에서 수행 할 첫 번째 단계 중 하나로 분할을 설명합니다. 사실, 당신은 어떻게 디스크를 분할하는 새 서버를 구축하는 경우는 매우 거의 정확히입니다 첫째 는 일 이 에 결정하고, 나중에 변화에 종종 가장 어려운. 읽기 쉬운 구성 안내서를 제공하는 인터넷 보안 센터 라는 그룹이 있습니다 . 특정 운영 체제에 대한 가이드를 찾고 그들이 말할 수있는 세부 사항을 볼 수 있습니다.

RedHat Enterprise Linux 6을 살펴보면 권장되는 파티션 구성표는 다음과 같습니다.

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

이러한 모든 변경의 기본 원리는 서로에 대한 영향을 방지하고 특정 파티션에서 수행 할 수있는 작업을 제한하는 것입니다. /tmp예를 들어 옵션을 사용하십시오 . 즉, 거기에 장치 노드를 만들 수 없으며 거기에서 프로그램을 실행할 수 없으며 set-uid 비트를 설정할 수 없습니다. 본질적 /tmp으로 거의 항상 쓰기 가능하며 종종 메모리에만 존재하는 특별한 유형의 파일 시스템입니다. 이는 공격자가 악의적 인 코드를 삭제하고 실행하기위한 쉬운 준비 지점으로이를 사용하여 시스템을 중단 (또는 단순히 재부팅)하여 모든 증거를 정리할 수 있음을 의미합니다. 의 기능에는 해당 기능이 /tmp필요하지 않으므로 기능을 쉽게 비활성화하고 상황을 방지 할 수 있습니다.

로그를 저장하는 장소, /var/log및 /var/log/audit자원 고갈에서 그 버퍼 도움말을 해제 새겨 져 있습니다. 또한 감사는 로그 저장소가 가득 차기 시작하면 일반적으로 보안 수준이 높은 일부 특별한 작업을 수행 할 수 있습니다. 파티션에 배치하면이 리소스 감지 성능이 향상됩니다.

더 자세하고 인용하기 mount(8)위해, 위의 사용 된 옵션은 다음과 같습니다.

noexec 마운트 된 파일 시스템에서 바이너리를 직접 실행할 수 없습니다. (최근까지는 /lib/ld*.so / mnt / binary와 같은 명령을 사용하여 바이너리를 실행할 수있었습니다.이 기법은 Linux 2.4.25 / 2.6.0부터 실패합니다.)

nodev 파일 시스템에서 문자를 해석하거나 특수 장치를 차단하지 마십시오.

nosuid set-user-identifier 또는 set-group-identifier 비트가 적용되지 않도록합니다. (이것은 안전 해 보이지만 suidperl (1)을 설치 한 경우 실제로 안전하지 않습니다.)

보안 측면에서 파일 시스템 자체에 보호 기능을 제공 할 수 있기 때문에 알 수있는 매우 좋은 옵션입니다. 매우 안전한 환경에서는에 noexec옵션을 추가 할 수도 있습니다 /home. 표준 사용자가 로그 파일 분석과 같이 데이터를 처리하기위한 쉘 스크립트를 작성하는 것이 더 어려워 지지만 권한을 상승시키는 바이너리를 실행하지 못하게됩니다.

또한 루트 사용자의 기본 홈 디렉토리는 /root입니다. 이 방법은이 될 것 /파일 시스템, 하지 에 /home.

각 파티션에 제공하는 금액은 시스템 워크로드에 따라 크게 달라질 수 있습니다. 내가 관리하는 일반적인 서버는 사람의 상호 작용이 거의 필요 /home하지 않으므로 파티션이 크지 않아도됩니다. /var자주 생성되고 삭제되는 임시 데이터를 저장하는 경향이 있으므로 동일하게 적용됩니다 . 그러나 웹 서버는 일반적으로 /var/www놀이터로 사용 되므로 별도의 파티션에 있거나 /var/크기가 커야합니다.

과거에는 다음을 기준으로 추천했습니다.

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

시스템의 목적과 환경 작동 방식에 따라이를 검토하고 조정해야합니다. 또한 LVM을 사용하고 전체 디스크를 할당하지 않는 것이 좋습니다. 이를 통해 필요한 경우 파티션을 쉽게 늘리거나 추가 할 수 있습니다.

기본 RAID 배열을 무시하고 ( RAID 배열 레벨 및 사용시기에 대한 자세한 내용은이 질문을 참조하십시오 ) "유닉스 서버의 파일 시스템을 어떻게 배치해야합니까?"라는 핵심 질문에 집중합시다.

하나의 거대한 /파티션에 어떤 문제가 있습니까?

당신이 당신의 질문에서 언급 한 바와 같이, 리눅스 배포판의 많은 (특히 우분투 같은 "바탕 화면"배포판은) 매우 간단한 파일 시스템 레이아웃을 사용 /하고 [swap].

이 구성표는 단순성 의 장점을 가지고 있습니다. 집에 PC에 익숙한 DOS / Windows 사용자에게는 "하드 드라이브"를 C:\물건을 버리는 하나의 큰 모 놀리 식 컨테이너 ( )로 사용하는 것이 좋습니다. 걱정할 필요가 없습니다. 파일 시스템의 공간 부족에 대한 정보-디스크 용량을 유지하고 모든 것이 (이론적으로 이론적으로는) 괜찮은지 확인하십시오.

단일 파일 시스템 체계에는 몇 가지 단점이 있지만 가장 많이 인용되는 단점은 루트 파일 시스템이 가득 찼을 때 (부팅 거부 시점까지) 모든 것이 기록되는 경우 /(루트) Unix 시스템이 매우 심하게 반응하는 경향이 있다는 것입니다. 하나의 길잡이 프로그램이나 사용자가 전체 시스템을 중단시킬 수 있습니다.
하나의 큰 파일 시스템은 시스템 충돌 및 후속 파일 시스템 손상시 전체 손실이 발생하기 쉽습니다.

위의 문제와 강력한 조직 감각으로 인해 Unix 서버에는 일반적으로 여러 파일 시스템이 있습니다.

유닉스 파일 시스템을 어떻게 분해합니까?

여러 파일 시스템을 갖는 것이 의미가 있다고 확신합니다. 이제 문제는 어떻게 시스템을 논리적 덩어리로 나누고 각 공간을 얼마나 확보 할 것인가를 결정하는 것입니다.
정답은 운영 체제의 위치를 ​​알고 이해하는 것입니다. 그 이해의 시작점은 hier맨 페이지입니다. 대부분의 유닉스 시스템은 (함께 man hier리눅스 시스템에서 , 그리고 man hierBSD 시스템에서 ), 그리고 플러스 코드 어떤 지역에 대한 지식 이 설치가 제정신 분할 레이아웃 작성을 안내 할 것입니다.

여기서는 일반적인 파티션 구성표에 대해 설명하지만이 구성표는 항상 특정 요구 사항에 맞게 수정해야합니다.

일반적인 유닉스 파티셔닝 계획

/
    The "root partition", /, does not usually need to be very large.
    It holds the basic items needed to boot the system, mount other filesystems
    and get you to a running, usable, multi-user environment.  It's also what
    is available to you when you bring up the system in single-user ("recovery")
    mode.  
    The contents of / should not change or grow substantially over time.

    NOTE: Anything that doesn't go on one of the other partitions described
          below will wind up taking space on the root partition (/).

/var
    The /var filesystem holds variable data -- log files, email, and on some
    systems databases (like MySQL or Postgres) store their data files here.  
    `/var` should be "Big Enough" to hold all the data you intend to cram into
    it.  I generally advise 10GB for systems that won't have a database or email
    server (just logs).  If you are building a database or mail server you
    should obviously make `/var` larger, or carve out separate filesystems for
    the database/mail data.

/usr
    The /usr filesystem holds "userland" programs, data, manual pages, etc.
    This is where things like the Firefox browser binary live.  On systems that
    will have a lot of large user applications this filesystem may be very large
    (100GB or more), and on stripped-down servers it may be relatively small.  
    A good rule of thumb is that the /usr filesystem should be twice as large
    as you need it to be in order to fit your initial installation of programs.

/home
    The /home filesystem holds user home directories, and on desktop systems is
    the largest and most prone to filling up.  When you download files from the
    internet, create spreadsheets, store a music library, etc. that data is
    stored in your home directory, and it adds up fast.
    It's important to allow enough room under /home for the "accumulated junk"
    you will gather over time, even on servers -- ad-hoc tarball backups, 
    package files you copied over to install, and the like.

특수 파일 시스템

/tmp and /var/tmp
    The temporary scratch space (/tmp) is "special" -- on most Unix systems
    the contents of /tmp are cleared on reboot, and on many modern systems
    /tmp is a special "tmpfs" (RAM) filesystem for better performance.
    /var/tmp is usually "persistent temporary files" (like vi recovery
    files), and is not cleared on reboot
    The same general rule applies as for all other filesystems: Make sure
    your temporary scratch filesystems are big enough to hold the stuff you
    want to put in them.

[swap]
    Swap Space is used by the kernel when you are running low on RAM --
    The old general rule of thumb was to have at least twice as much swap
    as you did RAM, however on modern systems it's usually sufficient to
    have "enough" swap -- 2GB is a practical lower limit, and an amount
    between half the installed RAM and the total installed RAM is usually
    adequate.
    On modern systems with relatively huge RAM pools (12G and up) it is
    probably not practical to use the system if it's swapping heavily
    enough to warrant the old "Twice the installed RAM" rule.

파일 시스템을 구성하는 방법은 소프트웨어 습격이없고 디스크 드라이브가 작던 시절부터 시작되었으므로 몇 가지를 사용해야 했으므로 파일 시스템을 분리하는 유일한 방법이었습니다. 다른 드라이브에 다른 디렉토리를 넣습니다. 다른 역사적 이유는 파티션과 마운트를 쉽게 마운트 해제 할 수 있었기 때문에 dump루트로는 수행 할 수 없었습니다. 이 도구는 요즘 많이 사용되지 않았으며 루트에서도 LVM 스냅 샷에서 사용할 수 있습니다.

더 이상 할 이유가 거의 없습니다. 예를 들어, /tmp전체 디스크를 채우지 못하게 하려면 이렇게해야합니다.

일반적인 쉘 액세스 권한을 가진 사용자가 길을 잃고 요즘 서버는 웹 또는 메일 서버와 같은 전용 서비스를 실행하기 때문에 이러한 이유는 요즘 크게 관련이 없습니다. 임의의 사용자가 임의의 명령을 실행할 수 없기 때문에 일반적으로 파일 시스템을 채우려 고하는 것에 대해 걱정할 필요가 없습니다 (그렇더라도 디스크 할당량이 있었기 때문에이를 중지 할 수 있습니다).

어떤 RAID 수준을 사용해야하는지에 대해서는 RAID의 주된 목적은 데이터를 보호하는 것이 아니라 (업데이트 용) 가동 시간을 유지하는 것입니다. 당신이 넣을 경우 /tmpRAID0의에, 당신의 서버는 여전히 아래로 갈 것이다 당신은 디스크 중 하나에 오류가 발생하는 경우 수리에게 그것을 가야 할 것입니다. raid1 대신 raid10을 사용하여 성능을 향상시킬 수도 있습니다.

파일 시스템을 분리하지 않는 매우 좋은 이유는 할당이 잘못되면 다른 공간이 충분하더라도 파일 시스템의 일부가 가득 차게 될 수 있기 때문입니다. LVM을 사용하고 할당되지 않은 공간을 남겨 두지 않으면이 문제를 해결하기 어려울 수 있습니다.

디스크 공간이 부족한 경우 많은 파티션 정보가 생성되었습니다. 결과적으로 여러 경우에 대해 비교적 작은 파티션이 표시됩니다. 필요한 파티션 크기는 서버 사용량에 따라 다릅니다. 가장 변수가되는 경향이 /tmp, /var, home, /opt,와 /srv. /usr합리적이고 안정적인 크기 인 경향이 있습니다. 공간 /은 다른 파티션의 일부 또는 전부와 공간 요구 사항을 포함 할 수 있습니다. 크기 조정은 실제로 시스템에서 수행하는 작업에 따라 다릅니다.

나는 증가 swap하고 마운트 /tmp합니다 tmpfs. 당신은 /tmp다음 가능한 것으로 백업 저장소로 스왑하지만 사용 메모리를 사용합니다. 귀하의 크기 /tmp는 매우 높아 보이지만 정리되지 않은 중단 된 업로드는 처리합니다.

MySQL 파일을로 이동하는 것을 고려할 것 /srv입니다. 이것은 디스크 계층에서 비교적 새로운 수준입니다.

최종 요구 사항을 모르는 경우 LVM을 사용하고 파티션을 채우기로 확장하는 것이 좋습니다.

아키텍처에 따라-재부팅 할 때마다 지워 지므로 실제로 / tmp를 사용하지 않을 수 있습니다. 귀하의 사이트에서 최종 업로드 처리를 처리하는 경우 (php.ini를 통해) 다른 위치로 변경하는 것이 좋습니다. 마운트 지점을 만들 수 있습니다.

앞에서 제안한대로 LVM을 사용하고 필요에 따라 증분하는 것이 좋습니다.

또한 MySQL 데이터 전용 파티션을 강력히 권장합니다 (여전히 / var / lib / mysql에 마운트 할 수 있음).