이번 시간에는 제가 사용해본 몇몇가지 PHP 기반 웹 스토리지 프로그램을 소개하고 비교하는 시간을 가져보도록 하겠습니다.
이미 블로그 초반에 개인서버를 구축하는데 있어 목표중에 하나인 개인 스토리지 입니다. 그리고 가족이나 지인들에게 일정 공간을 제공하기 위해 아이디가 발급 가능하도록 하는 것을 위주로 비교하였습니다.
제가 비교 사용할 후기는 네 가지 입니다.
1. Own Cloud
2. Pydio (구 AjaXplorer)
3. h5ai
4. elfinder
각각의 장점과 단점에 대해서 적어보도록 하겠습니다. 위의 네가지 모두 사용을 해봤으며, 아직도 사용을 하고 있습니다. 모두 소개를 하지만 실제로 사용하실 때, 이중에 하나만 사용하는 것을 추천합니다. 먼저 모두 설치후 비교사용하는 것도 괜찮겠네요.
먼저, OwnCloud 입니다.
<실사용 화면>
로그인 화면
개인 계정 접속후 관리 화면
#장점
1. 개인 서버에서 구축한 웹하드로 보기에는 속도가 빠른 편입니다.
2. 다양한 어플들을 지원해서 잘 구성하면 대형 포털과 맘먹는 편의를 구성 할 수 있습니다.
3. 인터페이스가 아주 깔끔합니다. (제가 이런 스타일 좋아합니다.)
4. 모바일 기기 전용 앱을 지원합니다. (아이폰, 안드로이드, 태블릿 등등)
5. 드래그 앤 드롭 인터페이스를 지원합니다.
#단점
1. 한글 파일이 지원이 되지 않습니다.
2. 모바일 기기 전용 앱이 유료(!) 입니다.
3. 관리자 계정으로 설정하는 부분이 자세하지는 않습니다. (좀 더 상세한 설정을 하려면 config 파일을 수정해야 합니다.)
개인적으로는 뭔가 고급스러워 보이는 것 같아보입니다. 개인이 구축한 웹하드이지만 뭔가 전문적인것 같고, 전체적인 분위기가 무료 같아보이지 않아 좋아합니다만, 한글파일 및 폴더 생성시 생성안되는 문제는 아직 해결중에 있습니다. UTF-8로 변환하면 될 듯한데, 아직 관련된 부분을 못 찾겠네요.
3. 갖가지 기능들을 모두 사용하기 위해서는 PHP Extension을 추가로 활용해야 합니다.
4. 보안이 아주 꽝입니다. 설정을 제대로 하지 않고 일반적인 설정만 진행하면 서버의 루트까지도 진입할 수 있습니다. (안그래도 이전버전은 암호없이 접속을 하였는데!)
전체적으로 엄청 깔끔하고 가벼워서 속도가 빠른, 속도가 가장 큰 장점인 이 h5ai 는 MIT에서 만들어졌습니다. 머리좋은 양반들이 편의성을 위해 만든것 같은데, 아직도 문제가 되는 부분이 있습니다. 인줄 알았는데 MIT 라이센스를 따라가고 있는 거군요. MIT만 보고 착각했습니다. 버전을 보아하면 아직도 0. 대이기 때문에 정식 버전은 아직 멀어보입니다.
본 설치 가이드는 공개SW 역량프라자에서 클라우드 컴퓨팅 기반 기술 중 가상화(Virtualization)에 대한 테스트 결과 보고서 외에 테스트 환경에 대한 이해를 돕고자 작성되었습니다.
모든 테스트 환경 구성에 대한 내용을 포함되어 있지 않으며, 주의가 필요하거나 참고해야 할 내용을 기반으로 작성되었습니다.
1. 설치환경
□ KVM 환경
모듈
Version
KVM
2.6.32 (Linux Kernel)
qemu-kvm
0.12.1
Virt-Manager
0.9.0.7
□ Stack 환경
구성
Host OS
Guest OS
A Stack
Ubuntu 10.04 Desktop LTS (64bit)
CentOS 6.2
Windows 7
B Stack
CentOS 6.2 (64bit)
Ubuntu 12.04
Windows 7
□ HW 환경
제조사
모델명
CPU
MEM
Disk
NIC
IBM
X3850M2
Intel Xeon(R)CPU 2.40GHz * 4
8GB
320G
Gigabit 1Port
2. CentOS 기반 KVM 설치
□ CentOS 설치 및 환경
o 패키지 선택
CentOS 설치 과정 중 아래의 그림과 같이 서버 용도에 맞는 패키지를 선택할 수 있는데 이번 테스트의 경우 가상화 관리 도구(Virt-Manager)이 GUI(Graphic User Interface)로 구성되어 Desktop을 선택하여 설치하였으며, 나머지 진행은 기본 설정을 기준으로 진행하였음
□ CentOS 설정
o SELinux 해제
vi /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
#SELINUX=enforcing
# 아래의 내용으로 변경함
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
reboot;
□ 가상화 지원 여부 확인
최근에 출시하는 Intel(VT-x), AMD(AMD-v) 계열의 프로세서는 대부분 하드웨어 가상화를 지원하며, 지원되지 않은 CPU일 경우 가상화를 원활히 사용할 수 없음
# intel cpu : vmx(Intel-VT), AMD cpu : svm(AMD-V)
egrep '(vmx|svm)' --color=always /proc/cpuinfo
o 아래 결과 중 빨간색(vmx)로 표시되면, CPU가 가상화 지원
□ KVM 환경 구성
o 참고사항
CentOS 6.2 버전의 경우 커널에 KVM이 기본적으로 포함되어 배포되어 별도의 설치가 필요 없이 사용 가능함
# KVM 설치 여부 확인
lsmod | grep kvm
#아래와 같이 표시되면 KVM이 설치되어 있음
kvm_intel 50380 0
kvm 305081 1 kvm_intel
o KVM 관련 패키지 설치
yum groupinstall "Virtualization*"
o KVM 관련 패키지 설치
- qemu-kvm
- qemu-img
- libvirt Library
- virt-manager
o 설치 확인
- 프로그램->시스템도구->가상 머신 관리자 선택
o 설치 확인
- 가상 머신 관리자(Virt-Manager) 구동 확인
※ 실제 처음 설치할 경우 등록된 가상 머신은 없음
3. Ubuntu 기반 KVM 설치
□ Ubuntu 설치
가상화 관리 도구(Virt-Manager)를 활용하기 위하여, Ubuntu 10.04 Desktop LTS 버전을 설치하였으며, 기본 설치 과정을 준수하여 설치하였음
□ 가상화 지원 여부 확인
최근에 출시하는 Intel(VT-x), AMD(AMD-v) 계열의 프로세서는 대부분 하드웨어 가상화를 지원하며, 지원되지 않은 CPU일 경우 가상화를 원활히 사용할 수 없음
Docker는 반가상화보다 좀더 경량화된 방식입니다. 그림에서 보는 것과 같이 Geust OS를 설치하지 않습니다. Docker 이미지에 서버 운영에 필요한 프로그램과 라이브러리만 격리해서 설치할 수 있고, OS 자원은 호스트와 공유합니다. 이렇게 되면서 이미지 용량이 크게 줄어들었습니다. 그리고 가상화 레이어가 없기 때문에 파일시스템, 네트워크 속도도 가상 머신에 비해 월등히 빠릅니다(호스트와 거의 동일한 속도).
최근까지 Docker는 lxc(Linux Container) 드라이버 기반으로 동작했지만 0.9x 버전부터는libcontainer를 사용합니다.
Docker는 가상 머신과는 달리 이미지 생성과 배포에 특화된 기능을 제공합니다.
Git에서 소스를 관리하는 것처럼 이미지 버전 관리 기능을 제공합니다. 그리고 중앙 관리를 위해 저장소에 이미지를 올리고, 받을 수 있습니다(Push/Pull). 게다가 GitHub처럼 Docker 이미지를 공유할 수 있는 Docker Hub도 제공합니다(GitHub처럼 개인 저장소도 제공합니다).
다양한 API를 제공하기 때문에 원하는 만큼 자동화를 할 수 있어 개발과 서버 운영에 매우 유용합니다.
이미지는 필요한 프로그램과 라이브러리, 소스를 설치한 뒤 파일로 만든 것입니다. 이 이미지를 저장소에 올리고, 받을 수 있습니다.
컨테이너는 이미지를 실행한 상태입니다. 이미지로 여러개의 컨테이너를 만들 수 있습니다. 운영체제로 보면 이미지는 실행파일이고 컨테이너는 프로세스입니다.
Docker는 특정 실행파일 또는 스크립트를 위한 실행 환경이라 보면 됩니다. 리눅스/유닉스 계열은 파일 실행에 필요한 모든 구성요소가 잘게 쪼개어져 있습니다. 시스템 구조가 단순해지고 명확해지는 장점이 있지만 의존성 관계를 해결하기가 어려워지는 단점이 있습니다. 그래서 리눅스 배포판 별로 미리 컴파일된 패키지(rpm, deb 등)라는 시스템이 나왔습니다. 하지만 서버를 실행할 때마다 일일이 소스를 컴파일하거나 패키지를 설치하고, 설정하려면 상당히 귀찮습니다.
서버가 한 두대라면 큰 어려움이 없겠지만 클라우드 환경에서는 서버를 몇 십, 몇 백개를 생성해야 합니다. 서버 구성을 미리 해놓은 Docker 이미지를 사용하면 실행할 서버가 몇개가 되든 손쉽게 해결할 수 있습니다.
자동 설치 스크립트를 사용하지 않고, 레드햇 엔터프라이즈 리눅스(RHEL)와 CentOS에서 패키지로 직접 설치하는 방법입니다. RHEL과 CentOS 패키지 저장소에는 docker-io가 없으므로 EPEL(Fedora Extra Packages For Enterprise Linux) 저장소를 사용할 수 있도록 설정합니다.
$ sudo docker run -i -t --name hello ubuntu /bin/bash
docker run <옵션> <이미지 이름> <실행할 파일>형식입니다. 여기서는ubunbu이미지를 컨테이너로 생성한 뒤 ubuntu 이미지 안의/bin/bash를 실행합니다. 이미지 이름 대신 이미지 ID를 사용해도 됩니다.
-i(interactive), -t(Pseudo-tty) 옵션을 사용하면 실행된 Bash Shell에 입력 및 출력을 할 수 있습니다. 그리고--name옵션으로 컨테이너의 이름을 지정할 수 있습니다. 이름을 지정하지 않으면 Docker가 자동으로 이름을 생성하여 지정합니다.
이제 호스트 OS와 완전히 격리된 공간이 생성되었습니다. cd, ls명령으로 컨테이너 내부를 한번 둘러봅니다. 호스트 OS와는 다르다는 것을 알 수 있습니다. exit를 입력하여 Bash Shell에서 빠져나옵니다. 우분투 이미지에서 /bin/bash 실행 파일을 직접 실행했기 때문에 여기서 빠져나오면 컨테이너가 정지(stop)됩니다.
참고
CentOS에서 아래와 같은 에러가 발생하면
unable to remount sys readonly: unable to mount sys as readonly max retries reached
/etc/sysconfig/docker 파일에서 아래와 같이--exec-driver=lxc를 추가합니다.
/etc/sysconfig/docker
# /etc/sysconfig/docker
#
# Other arguments to pass to the docker daemon process
# These will be parsed by the sysv initscript and appended
/etc/hosts에 도메인을 추가하고, 인증서 파일을 설치했으면 Docker 서비스를 재시작합니다. Docker 서비스를 재시작해야 추가된 도메인과 설치된 인증서가 적용됩니다.
$ sudo service docker restart
Docker 레지스트리에 접속할 다른 시스템에도server.crt인증서 파일을 복사하여 같은 방식으로 설치를 하고 Docker 서비스를 재시작합니다. 그리고 도메인을 구입하지 않았다면/etc/hosts에 레지스트리 서버(registry.example.com)의 IP 주소를 설정합니다.
--insecure-registry 옵션
server.crt 인증서 파일을 시스템에 설치하지 않으려면 Docker 데몬을 실행할 때--insecure-registry옵션을 사용해야 합니다.
auth_basic: 인증 설정입니다. "Restricted"를 설정하여 기본 인증을 사용합니다.
auth_basic_user_file: 사용자 정보가 저장된.htpasswd파일을 설정합니다.
daemon off; 옵션
Nginx 공식 이미지 1.7.5 버전부터는 다음과 같이 Nginx 실행 파일을 실행할 때 옵션에 직접 daemon off;를 설정해줍니다. 따라서 nginx.conf 파일에는 daemon off; 옵션을 넣지 않아도 됩니다.
CMD ["nginx", "-g", "daemon off;"]
다음 명령을 실행하여 Docker 레지스트리 컨테이너를 먼저 생성합니다. 컨테이너의 이름은 nginx.conf 파일에서 설정한 대로docker-registry로 지정합니다.
$ sudo docker run -d --name docker-registry \
-v /tmp/registry:/tmp/registry \
registry:0.8.1
Nginx를 통해서 사용자 인증을 하고 이미지를 주고 받을 것이기 때문에 Docker 레지스트리는 5000번 포트를 외부에 노출하지 않습니다.
Nginx 공식 이미지 1.7.5 버전으로 컨테이너를 생성하고docker-registry컨테이너와 연결합니다.
$ sudo docker run -d --name nginx-registry \
-v ~/nginx.conf:/etc/nginx/nginx.conf \
-v ~/.htpasswd:/etc/nginx/.htpasswd \
-v ~/server.key:/etc/server.key \
-v ~/server.crt:/etc/server.crt \
--link docker-registry:docker-registry \
-p 443:443 \
nginx:1.7.5
-v옵션으로nginx.conf파일은 컨테이너의 /etc/nginx/nginx.conf로 연결합니다. 마찬가지로.htpasswd파일도 /etc/nginx/.htpasswd로 연결합니다. server.key, server.crt파일은 앞에서 설정한 것처럼 /etc 디렉터리 아래에 연결합니다.
--link docker-registry:docker-registry옵션으로 앞에서 생성한docker-registry컨테이너를docker-registry별칭으로 연결합니다. 이렇게하면 nginx.conf의proxy_pass설정으로 Docker 레지스트리에 트래픽을 보낼 수 있습니다.
-p 443:443옵션으로 443번 포트를 외부에 노출합니다.
docker login명령으로https://registry.example.com에 로그인합니다. Username과 Password에는 htpasswd 명령으로 생성한 사용자와 비밀번호를 입력합니다. 이메일은 입력하지 않아도 됩니다.
도메인 설정이 귀찮다고 그냥 건너뛰고 IP 주소만 사용하면 로그인이 안됩니다. 인증서에 설정한 도메인과docker login명령에 입력한 도메인이 반드시 일치해야 합니다. HTTPS 프로토콜은 IP 주소 접속을 허용하지 않으므로 구입하지 않은 도메인은 /etc/hosts 파일에 등록하여 사용합니다.
이제 앞에서 만든hello:0.1이미지를 개인 저장소에 올려보겠습니다.
$ sudo docker tag hello:0.1 registry.example.com/hello:0.1
$ sudo docker push registry.example.com/hello:0.1
The push refers to a repository [registry.example.com/hello] (len: 1)
개념 잡기 Docker는 Linux 기반의 Container RunTime 오픈소스이다. 처음 개념을 잡기가 조금 어려운데, Virtual Machine과 상당히 유사한 기능을 가지면서, Virtual Machine보다 훨씬 가벼운 형태로 배포가 가능하다. 정확한 이해를 돕기 위해서, VM 과 Docker Container의 차이를 살펴보자. 아래는 VM 에 대한 컨셉이다. Host OS가 깔리고, 그 위에 Hypervisor (VMWare,KVM,Xen etc)가 깔린 후에, 그위에, Virtual Machine이 만들어진다. Virtual Machine은 일종의 x86 하드웨어를 가상화 한 것이라고 보면된다. 그래서 VM위에 다양한 종류의 Linux나, Windows등의 OS를 설치할 수 있다.
Docker의Container 컨셉은 비슷하지만 약간 다르다. Docker도 VM 처럼 Docker Engine이 Host위에서 수행된다. 그리고, Container는 Linux 기반의 OS만 수행이 가능하다. Docker는 VM처럼 Hardware를 가상화 해주는 것이 아니라, Guest OS (Container)를 Isolation해준다.무슨 말인가 하면, Container의 OS는 기본적으로 Linux OS만 지원하는데, Container 자체에는 Kernel등의 OS 이미지가 들어가 있지 않다. Kernel은 Host OS를 그대로 사용하되, Host OS와 Container의 OS의 다른 부분만 Container 내에 같이 Packing된다. 예를 들어 Host OS가 Ubuntu version X이고, Container의 OS가CentOS version Y라고 했을때, Container에는 CentOS version Y의 full image가 들어가 있는 것이 아니라, Ubuntu version X와 CentOS version Y의 차이가 되는 부분만 패키징이 된다. Container 내에서 명령어를 수행하면 실제로는 Host OS에서 그 명령어가 수행된다. 즉 Host OS의 Process 공간을 공유한다.
실제로 Container에서 App을 수행하고 ps –ef 를 이용하여 process를 보면, “lxc”라는 이름으로 해당 App이 수행됨을 확인할 수 있다. 아래는docker를 이용해서 container에서 bash 를 수행했을때는 ps 정보이다. lxc 프로세스로 bash 명령어가 수행되었음을 확인할 수 있다. root 4641 954 0 15:07 pts/1 00:00:00 lxc-start -n 161c56b9284ffbad0477bd04875c4277be976e2032f3ffa35395950ea05f9bd6 -f /var/lib/docker/containers/161c56b9284ffbad0477bd04875c4277be976e2032f3ffa35395950ea05f9bd6/config.lxc -- /.dockerinit -g 172.17.42.1 -e TERM=xterm -e HOME=/ -e PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin -e container=lxc -e HOSTNAME=161c56b9284f -- /bin/bash LXC는 (LinuX Container)로, 자세한 정보는 http://linuxcontainers.org/ 에서 얻을 수 있다. lxc는 container를 실행시켜주는 runtime으로, 앞에서 설명한것과 같이 VM과 비슷한 기능을 제공하지만, 실제 수행에 있어서, guest os (container)를 마치 VM처럼 isolate해서 수행해주는 기능을 제공한다. 이와 같이 Docker는 LXC라는 Linux에 특화된 feature를 사용하기 때문에, 제약 사항을 가지고 있는데, 현재까지 Docker는 Ubuntu 12.04 이상(Host OS)에서만 사용이 가능하다. Performance에 대해서는 당연히 Host OS에서 직접 application 을 돌리는 것보다 performance 감소가 있는데, 아래 표와 같이 performance 감소가 매우 적은 것을 볼 수 있다.
출처: http://www.slideshare.net/modestjude/dockerat-deview-2013 Repository 연계 다음으로 Docker의 특징중의 하나는 repository 연계이다.Container Image를 중앙의 Repository에 저장했다가, 다른 환경에서 가져다가 사용할 수 있다. 마치 git와 같은 VCS (Version Control System)과 같은 개념인데, 이를 통해서 Application들을 Container로 패키징해서 다른 환경으로 쉽게 옮길 수 있다는 이야기다.
예를 들어 local pc에서 mysql, apache, tomcat등을 각 컨테이너에 넣어서 개발을 한 후에, 테스트 환경등으로 옮길때, Container를 repository에 저장했다가 테스트환경에서 pulling(당겨서) 똑같은 테스트환경을 꾸밀 수 있다는 것이다. Container에는 모든 application과 설치 파일, 환경 설정 정보 등이 들어 있기 때문에, 손쉽게 패키징 및 설치가 가능하다는 장점을 가지고 있다. 여기서 고려해야할점은 Docker는 아쉽게도 아직까지 개발중이고, 정식 릴리즈 버전이 아니다. 그래서, 아직까지는 production(운영환경)에 배포를 권장하고 있지 않다. 단 개발환경에서는 모든 개발자가 동일한 개발환경을 사용할 수 있게 할 수 있고, 또한 VM 보다 가볍기 때문에, 개발환경을 세팅하는데 적절하다고 볼 수 있다. Base Image vs Dockerfile Docker의 Container Image를 packing하기 위해서, Docker는 Base Image와 Docker file이라는 두가지 컨셉을 이용한다. 쉽게 설명하면, Base Image는 기본적인 인스톨 이미지, Docker file은 기본적인 인스톨 이미지와 그 위에 추가로 설치되는 스크립트를 정의한다. 예를 들어 Base Image가 Ubuntu OS 이미지라면, Docker File은 Ubuntu OS + Apache, MySQL을 인스톨하는 스크립트라고 보면 된다. 일반적으로 Docker Base Image는 기본 OS 인스톨 이미지라고 보면 된다. 만약에 직접 Base Image를 만들고 싶으면 http://docs.docker.io/en/latest/use/baseimages/ 를 참고하면 된다. docker에서는 미리 prebuilt in image들을 제공하는데,https://index.docker.io/ 를 보면 public repository를 통해서 제공되는 이미지들을 확인할 수 있다. 아직까지는 Ubuntu 많이 공식적으로 제공되고, 일반 contributor들이 배포한 centos 등의 이미지들을 검색할 수 있다. (2013.10.22 현재 redhat 등의 이미지는 없다.) 아래는 docker file 샘플이다. (출처 : http://docs.docker.io/en/latest/use/builder/) # Nginx # # VERSION 0.0.1
FROM ubuntu MAINTAINER Guillaume J. Charmes <guillaume@dotcloud.com>
# make sure the package repository is up to date RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list RUN apt-get update
RUN apt-get install -y inotify-tools nginx apache2 openssh-server 위의 이미지는 Ubuntu OS 베이스 이미지에 apt-get을 이용해서, inotify-tools nginx apache2 openssh-serverf 를 인스톨하는 스크립트이다. Docker 실행해보기 그럼 간단하게 docker를 테스트해보자, 윈도우즈 환경을 가정한다. 앞서 말한바와 같이 Docker는 Unbuntu 위에서만 작동한다. (참고 :http://docs.docker.io/en/latest/installation/windows/) 그래서, 윈도우즈 위에서 Ubuntu VM을 설치한후, Ubuntu VM에서 Docker를 실행할 것이다. 이를 위해서 VM을 수행하기 위한 환경을 설치한다. Hypervisor인 Virtual Box를 설치한다. https://www.virtualbox.org VM을 실행하기 위한 vagrant를 설치한다. http://www.vagrantup.com Docker 코드를 다운받기 위해서 git 클라이언트를 설치한다. http://git-scm.com/downloads 여기까지 설치했으면, docker를 실행하기 위한 준비가 되었다. 다음 명령어를 수행해서, docker 코드를 git hub에서 다운로드 받은 후에, vagrant를 이용해서 Ubuntu host os를 구동한다.
그러면, 기동된 Ubuntu OS로 SSH를 이용해서 log in을 해보자. Putty를 이용해서 127.0.0.1:2222 포트로, SSH를 통해서 로그인한다. (기본id,passwd는 vagrant/vagrant 이다.) 이제 Docker를 이용해서, public repository에서 “busybox”라는 Ubuntu OS를 Container로 설치하고, 그 Container에서 “echo hello world” 명령어를 수행해보자 sudo su docker run busybox echo hello world Docker가 public repository에서 busybox image를 다운로드 받아서 설치하고, 아래와 같이 명령어를 수행했음을 확인할 수 있다.
※ 참고 : 현재 docker에 설치된 이미지 리스트 docker images, 설치된 이미지를 삭제할려면 docker rmi {image id}. {image id}는 docker images에서 hexa로 나온 id를 사용하면 된다.
Location of custom alert scripts (depends on compile-time installation variable datadir).
AllowRoot
no
0
Allow the server to run as 'root'. If disabled and the server is started by 'root', the server will try to switch to the 'zabbix' user instead. Has no effect if started under a regular user. 0 - do not allow 1 - allow This parameter is supported since Zabbix 2.2.0.
CacheSize
no
128K-8G
8M
Size of configuration cache, in bytes. Shared memory size for storing host, item and trigger data. Upper limit used to be 2GB before Zabbix 2.2.3.
CacheUpdateFrequency
no
1-3600
60
How often Zabbix will perform update of configuration cache, in seconds. See also runtime control options.
DBHost
no
localhost
Database host name. In case of MySQL localhost or empty string results in using a socket. In case of PostgreSQL only empty string results in attempt to use socket.
Database password. Ignored for SQLite. Comment this line if no password is used.
DBPort
no
1024-65535
3306
Database port when not using local socket. Ignored for SQLite.
DBSchema
no
Schema name. Used for IBM DB2 and PostgreSQL.
DBSocket
no
/tmp/mysql.sock
Path to MySQL socket.
DBUser
no
Database user. Ignored for SQLite.
DebugLevel
no
0-5
3
Specifies debug level: 0 - basic information about starting and stopping of Zabbix processes 1 - critical information 2 - error information 3 - warnings 4 - for debugging (produces lots of information) 5 - extended debugging (produces even more information) See also runtime control options.
ExternalScripts
no
/usr/local/share/zabbix/externalscripts
Location of external scripts (depends on compile-time installation variable datadir).
Fping6Location
no
/usr/sbin/fping6
Location of fping6. Make sure that fping6 binary has root ownership and SUID flag set. Make empty (“Fping6Location=”) if your fping utility is capable to process IPv6 addresses.
FpingLocation
no
/usr/sbin/fping
Location of fping. Make sure that fping binary has root ownership and SUID flag set!
HistoryCacheSize
no
128K-2G
16M
Size of history cache, in bytes. Shared memory size for storing history data.
HistoryIndexCacheSize
no
128K-2G
4M
Size of history index cache, in bytes. Shared memory size for indexing history data stored in history cache. The index cache size needs roughly 100 bytes to cache one item. This parameter is supported since Zabbix 3.0.0.
HousekeepingFrequency
no
0-24
1
How often Zabbix will perform housekeeping procedure (in hours). Housekeeping is removing outdated information from the database. Note: To prevent housekeeper from being overloaded (for example, when history and trend periods are greatly reduced), no more than 4 times HousekeepingFrequency hours of outdated information are deleted in one housekeeping cycle, for each item. Thus, if HousekeepingFrequency is 1, no more than 4 hours of outdated information (starting from the oldest entry) will be deleted per cycle. Note: To lower load on server startup housekeeping is postponed for 30 minutes after server start. Thus, if HousekeepingFrequency is 1, the very first housekeeping procedure after server start will run after 30 minutes, and will repeat with one hour delay thereafter. This postponing behavior is in place since Zabbix 2.4.0. Since Zabbix 3.0.0 it is possible to disable automatic housekeeping by setting HousekeepingFrequency to 0. In this case the housekeeping procedure can only be started by housekeeper_execute runtime control option and the period of outdated information deleted in one housekeeping cycle is 4 times the period since the last housekeeping cycle, but not less than 4 hours and not greater than 4 days. See also runtime control options.
Include
no
You may include individual files or all files in a directory in the configuration file. To only include relevant files in the specified directory, the asterisk wildcard character is supported for pattern matching. For example: /absolute/path/to/config/files/*.conf. Pattern matching is supported since Zabbix 2.4.0. See special notes about limitations.
JavaGateway
no
IP address (or hostname) of Zabbix Java gateway. Only required if Java pollers are started. This parameter is supported since Zabbix 2.0.0.
JavaGatewayPort
no
1024-32767
10052
Port that Zabbix Java gateway listens on. This parameter is supported since Zabbix 2.0.0.
ListenIP
no
0.0.0.0
List of comma delimited IP addresses that the trapper should listen on. Trapper will listen on all network interfaces if this parameter is missing. Multiple IP addresses are supported since Zabbix 1.8.3.
ListenPort
no
1024-32767
10051
Listen port for trapper.
LoadModule
no
Module to load at server startup. Modules are used to extend functionality of the server. Format: LoadModule=<module.so> The modules must be located in directory specified by LoadModulePath. It is allowed to include multiple LoadModule parameters.
LoadModulePath
no
Full path to location of server modules. Default depends on compilation options.
LogFile
yes, if LogType is set to file, otherwise no
Name of log file.
LogFileSize
no
0-1024
1
Maximum size of log file in MB. 0 - disable automatic log rotation. Note: If the log file size limit is reached and file rotation fails, for whatever reason, the existing log file is truncated and started anew.
LogType
no
file
Log output type: file - write log to file specified by LogFile parameter, system - write log to syslog, console - write log to standard output. This parameter is supported since Zabbix 3.0.0.
LogSlowQueries
no
0-3600000
0
How long a database query may take before being logged (in milliseconds). 0 - don't log slow queries. This option becomes enabled starting with DebugLevel=3. This parameter is supported since Zabbix 1.8.2.
MaxHousekeeperDelete
no
0-1000000
5000
No more than 'MaxHousekeeperDelete' rows (corresponding to [tablename], [field], [value]) will be deleted per one task in one housekeeping cycle. SQLite3 does not use this parameter, deletes all corresponding rows without a limit. If set to 0 then no limit is used at all. In this case you must know what you are doing! This parameter is supported since Zabbix 1.8.2 and applies only to deleting history and trends of already deleted items.
PidFile
no
/tmp/zabbix_server.pid
Name of PID file.
ProxyConfigFrequency
no
1-604800
3600
How often Zabbix server sends configuration data to a Zabbix proxy in seconds. Used only for proxies in a passive mode. This parameter is supported since Zabbix 1.8.3.
ProxyDataFrequency
no
1-3600
1
How often Zabbix server requests history data from a Zabbix proxy in seconds. Used only for proxies in a passive mode. This parameter is supported since Zabbix 1.8.3.
SenderFrequency
no
5-3600
30
How often Zabbix will try to send unsent alerts (in seconds).
SNMPTrapperFile
no
/tmp/zabbix_traps.tmp
Temporary file used for passing data from SNMP trap daemon to the server. Must be the same as in zabbix_trap_receiver.pl or SNMPTT configuration file. This parameter is supported since Zabbix 2.0.0.
SourceIP
no
Source IP address for outgoing connections.
SSHKeyLocation
no
Location of public and private keys for SSH checks and actions
SSLCertLocation
no
Location of SSL client certificate files for client authentication. This parameter is used in web monitoring only and is supported since Zabbix 2.4.
SSLKeyLocation
no
Location of SSL private key files for client authentication. This parameter is used in web monitoring only and is supported since Zabbix 2.4.
SSLCALocation
no
Override the location of certificate authority (CA) files for SSL server certificate verification. If not set, system-wide directory will be used. Note that the value of this parameter will be set as libcurl option CURLOPT_CAPATH. For libcurl versions before 7.42.0, this only has effect if libcurl was compiled to use OpenSSL. For more information see cURL web page. This parameter is used in web monitoring since Zabbix 2.4.0 and in SMTP authentication since Zabbix 3.0.0.
StartDBSyncers
no
1-100
4
Number of pre-forked instances of DB Syncers. The upper limit used to be 64 before version 1.8.5. This parameter is supported since Zabbix 1.8.3.
StartDiscoverers
no
0-250
1
Number of pre-forked instances of discoverers. The upper limit used to be 255 before version 1.8.5.
StartEscalators
no
1-100
1
Number of pre-forked instances of escalators. This parameter is supported since Zabbix 3.0.0.
StartHTTPPollers
no
0-1000
1
Number of pre-forked instances of HTTP pollers. The upper limit used to be 255 before version 1.8.5.
StartIPMIPollers
no
0-1000
0
Number of pre-forked instances of IPMI pollers. The upper limit used to be 255 before version 1.8.5.
StartJavaPollers
no
0-1000
0
Number of pre-forked instances of Java pollers. This parameter is supported since Zabbix 2.0.0.
StartPingers
no
0-1000
1
Number of pre-forked instances of ICMP pingers. The upper limit used to be 255 before version 1.8.5.
StartPollersUnreachable
no
0-1000
1
Number of pre-forked instances of pollers for unreachable hosts (including IPMI and Java). Since Zabbix 2.4.0, at least one poller for unreachable hosts must be running if regular, IPMI or Java pollers are started. The upper limit used to be 255 before version 1.8.5. This option is missing in version 1.8.3.
StartPollers
no
0-1000
5
Number of pre-forked instances of pollers. Note that a non-zero value is required for internal, aggregated and calculated items to work.
StartProxyPollers
no
0-250
1
Number of pre-forked instances of pollers for passive proxies. The upper limit used to be 255 before version 1.8.5. This parameter is supported since Zabbix 1.8.3.
StartSNMPTrapper
no
0-1
0
If set to 1, SNMP trapper process will be started. This parameter is supported since Zabbix 2.0.0.
StartTimers
no
1-1000
1
Number of pre-forked instances of timers. Timers process time-based trigger functions and maintenance periods. Only the first timer process handles the maintenance periods. This parameter is supported since Zabbix 2.2.0.
StartTrappers
no
0-1000
5
Number of pre-forked instances of trappers. Trappers accept incoming connections from Zabbix sender, active agents and active proxies. At least one trapper process must be running to display server availability and view queue in the frontend. The upper limit used to be 255 before version 1.8.5.
StartVMwareCollectors
no
0-250
0
Number of pre-forked vmware collector instances. This parameter is supported since Zabbix 2.2.0.
Timeout
no
1-30
3
Specifies how long we wait for agent, SNMP device or external check (in seconds).
TLSCAFile
no
Full pathname of a file containing the top-level CA(s) certificates for peer certificate verification, used for encrypted communications between Zabbix components. This parameter is supported since Zabbix 3.0.0.
TLSCertFile
no
Full pathname of a file containing the server certificate or certificate chain, used for encrypted communications between Zabbix components. This parameter is supported since Zabbix 3.0.0.
TLSCRLFile
no
Full pathname of a file containing revoked certificates. This parameter is used for encrypted communications between Zabbix components. This parameter is supported since Zabbix 3.0.0.
TLSKeyFile
no
Full pathname of a file containing the server private key, used for encrypted communications between Zabbix components. This parameter is supported since Zabbix 3.0.0.
TmpDir
no
/tmp
Temporary directory.
TrapperTimeout
no
1-300
300
Specifies how many seconds trapper may spend processing new data.
TrendCacheSize
no
128K-2G
4M
Size of trend cache, in bytes. Shared memory size for storing trends data.
UnavailableDelay
no
1-3600
60
How often host is checked for availability during the unavailability period, in seconds.
UnreachableDelay
no
1-3600
15
How often host is checked for availability during the unreachability period, in seconds.
UnreachablePeriod
no
1-3600
45
After how many seconds of unreachability treat a host as unavailable.
User
no
zabbix
Drop privileges to a specific, existing user on the system. Only has effect if run as 'root' and AllowRoot is disabled. This parameter is supported since Zabbix 2.4.0.
ValueCacheSize
no
0,128K-64G
8M
Size of history value cache, in bytes. Shared memory size for caching item history data requests. Setting to 0 disables value cache (not recommended). When value cache runs out of the shared memory a warning message is written to the server log every 5 minutes. This parameter is supported since Zabbix 2.2.0.
VMwareCacheSize
no
256K-2G
8M
Shared memory size for storing VMware data. A VMware internal check zabbix[vmware,buffer,…] can be used to monitor the VMware cache usage (see Internal checks). Note that shared memory is not allocated if there are no vmware collector instances configured to start. This parameter is supported since Zabbix 2.2.0.
VMwareFrequency
no
10-86400
60
Delay in seconds between data gathering from a single VMware service. This delay should be set to the least update interval of any VMware monitoring item. This parameter is supported since Zabbix 2.2.0.
VMwarePerfFrequency
no
10-86400
60
Delay in seconds between performance counter statistics retrieval from a single VMware service. This delay should be set to the least update interval of any VMware monitoring item that uses VMware performance counters. This parameter is supported since Zabbix 2.2.9, 2.4.4
VMwareTimeout
no
1-300
10
The maximum number of seconds vmware collector will wait for a response from VMware service (vCenter or ESX hypervisor). This parameter is supported since Zabbix 2.2.9, 2.4.4
