서버란 무엇인가요?

우리가 어떠한 정보를 얻기 위해서 정보가 위치한 장치로 요청을 보내고 결과적으로 원하는 데이터를 받아오게 되는데, 여기서 데이터가 저장된 장치를 서버(Server)라고 부릅니다. 다시 말해 우리는 인터넷 통신으로 서버에서 원하는 정보(데이터)를 받아오게 됩니다.

서버의 역할은 굉장히 광범위합니다. 누구든지 접속할 수 있는 웹 사이트를 운영하기 위해서 사용되기도 할 뿐만 아니라, 이미지나 동영상을 빠르게 스트리밍하기 위한 서버, 데이터베이스 전용으로 운영되는 서버, 데이터를 백업하고자 내부적으로 구성된 서버와 같이 다양한 목적의 서버들이 존재합니다.

이름으로 보면 무척 대단해 보이지만, 사실 우리가 사용하는 PC와 동일하다고 봐도 좋습니다. 집에 설치된 데스크톱 PC만으로도 네트워크만 연결되어 있다면 누구나 서버를 구축할 수 있기 때문입니다. 물론 실제로 서비스되는 서버 장치는 안정적인 서비스를 위해서 일반 데스크톱 수준의 PC를 사용하지 않습니다. 하드웨어는 물론 소프트웨어상으로도 일반 PC와는 다른 모습을 띕니다. 케이스의 경우 보통 랙 마운트(Rackmount)라는 규격화된 케이스를 사용하는데, 이는 여러 대가 될 수 있는 서버를 공간 효율 및 관리상에 있어서 겹쳐놓기 쉬워서이기도 하고, 부품 교체가 용이하기 때문이기도 합니다.

서버에 사용되는 운영체제 역시 일반 소비자가 사용하는 Windows나 macOS같은 운영체제 보다 오랜 시간 운용에 있어 더 안정적이고 지원 기간이 긴 운영체제를 사용합니다. 대개 Unix/Linux 계열의 운영체제(RedHat, Debian, Ubuntu, CentOS 등이 있다)나 Windows Server 운영체제 등을 사용합니다.

정보와 데이터를 실시간으로 주고 받아야 하는 서버 특성 상 지속적으로 사용 가능한 상태가 되어야 하기 때문에 가정에서 서버를 운용한다는 것은 여간 쉬운 일이 아닙니다. 서비스 마다 다르겠지만 대부분 언제 어디서 얼마나 들어올지 모르는 사용자 특성 상 서버는 24시간 동안 서비스되어야 하기 때문에 전기비 감당은 물론 지속적인 하드웨어 관리가 필요할 것입니다. 접속자가 갑자기 많아진다면 어떨까요? 아파트나 일반 가정에서 사용되는 인터넷망은 애초에 수많은 사용자의 동시 접속에 최적화 되어있지 않기 때문에 망 제공 업체에서 사용량에 제한을 둘 수도 있습니다. 또한 별도의 서비스를 신청하지 않는 한 IP(자신의 네트워크에 할당된 주소)는 매번 유동적으로 바뀌기 때문에 다른 사용자가 해당 네트워크로 진입하는 데 어려움을 겪을 수도 있습니다. 서버가 계속 켜져있다면 그만큼 팬 소음은 장난 아닐 것이고, 발생하는 열로 인해 냉방 시설이 필요할 정도로 신경 써야 할 항목들이 많습니다.

그래서 서버는 회사 내부에 독립적인 공간에 설치되거나, 아니면 수십, 수백 대의 서버가 몰려있는 하나의 장소에 설치하기도 합니다. (아무래도 모아두면 중앙 집중화된 관리가 가능해지겠죠?) 보통 여러 대의 서버를 통합 관리, 운영할 수 있도록 공간을 임대해주는데, 이를 IDC(Internet Data Center) 또는 데이터 센터(Data Center)라고 부릅니다.

서버는 어떻게 구축하나요?

서버를 구축하려면 먼저 IDC에 설치할 서버 PC를 구매하거나 임대해야 하는데, 이러한 서버 구매와 임대를 대행해주는 업체가 바로 호스팅 업체입니다. 대표적으로 국내에는 카페24, 가비아 등이 있고 해외에는 고대디, 블루호스트 등의 업체가 있습니다.

IDC 서버 호스팅은 기업 사용자가 아니라면 비용이 만만치 않습니다. 여기에는 일반적인 하드웨어 구매 비용을 포함하여 매달 빠져나갈 수 있는 운영비 또한 고려해봐야 합니다. IDC에 설치하는 서버는 적어도 대규모 트래픽을 처리해야 하는 수준이라면 모르지만, 만약 동시 접속자가 100명도 채 안되는 사이트를 운영한다면 어떨까요? 소규모 웹 사이트를 운영하는 것에 비해 사양 높은 서버를 구성할 필요는 없을 것입니다.

다행히도 소규모 서버를 저렴하게 구축하기 위한 방법은 아주 많습니다. 앞서 말씀드린 방법은 서버 장비 자체를 구매하고 임대하여 모든 자원을 사용하는 방법입니다. 이를 단독 서버 호스팅이라고 합니다. 하지만 대부분의 호스팅 업체에서는 소규모 운영자를 위해 한 대의 서버를 여러 대의 서버로 활용 가능하도록 가상의 영역을 할당시켜줍니다. 쉽게 말해 한 대의 서버의 자원을 다른 사용자와 공유하여 사용하는 것입니다. (물론 각 사용자의 영역은 안전하게 보호됩니다.) 이렇게 되면 서버 성능은 낮아지더라도 최소한 운영 가능한 수준의 서버를 저렴한 가격에 이용할 수 있게 됩니다. 이러한 호스팅을 가상 사설 서버 호스팅 또는 VPS 호스팅(Virtual Private Server)이라고 부릅니다. (이는 클라우드 서버 호스팅과 비슷하면서도 다릅니다. 클라우드 호스팅은 별도의 포스트에서 설명드리겠습니다.)

위에서 언급한 호스팅 방법을 통틀어 서버 호스팅(Server Hosting)이라고 부르는데요, 공통점으로는 서버 자원을 할당받았다는 것과, 자신의 서버에 직접 접속할 수 있어 운영 가능한 모든 것을 자유롭게 작업할 수 있다는 점을 들 수 있습니다.

웹사이트 운영을 위한 전용 호스팅 서비스 또한 존재합니다. 서버 호스팅 역시 적지않은 운영 비용이 요구되기 때문에 소규모 웹사이트를 운영하는 데에는 웹 서비스에 최적화된 웹호스팅 서비스를 사용하는 경우도 있습니다. 이를 웹 호스팅(Web Hosting)이라고 합니다. 단, 이 서비스는 데이터베이스 운영이나 파일 서버, 게임 서버와 같은 목적으로는 사용되지 못합니다.

웹 호스팅은 다른 호스팅 서비스에 비해 가장 저렴하다는 장점이 있지만, 일반적으로 트래픽(일정 시간 동안 서버에서 처리되는 데이터의 양)에 제한을 두어 트래픽 초과 시 추가 비용을 요구하기도 하고, 제공되는 서버 사양이 영 좋지 못하여 웹 페이지 처리 속도가 다른 호스팅에 비해 느립니다. (물론 서비스 가격대에 따라 제한되는 수준이 달라지기도 합니다.) 또 하나의 특징은 서버 관리자가 서버 운영의 전체 권한을 가질 수 없어서 자유롭게 서버를 커스터마이징 할 수 없다는 점이 있습니다. 전체적으로 보면 단점이 많아보이지만 서버 운영(웹 서비스 설치, 보안 관리 등)과 같은 복잡한 관리는 호스팅 업체가 대신해주기 때문에 서비스 형식에 따라 웹 호스팅을 선호하는 경우도 있습니다.

여기서는 일반적으로 사용되는 서버 호스팅과 웹 호스팅에 대해서만 알아봤습니다. 간략히 정리해보자면 다음과 같습니다.

이외에도 목적과 규모에 따라 여러가지 호스팅 방법이 존재합니다. 자세히 알아보려면 각 호스팅 업체의 상품 소개를 읽어보고 판단하시는 것이 좋습니다.

서버를 단순히 구축했다고 해서 원하는 서비스를 바로 시작할 수 있는 것은 아닙니다. 운영체제 또는 각종 서버 소프트웨어의 설치가 필요할 수 있습니다. 그리고 서비스해야 할 데이터나 프로그램이 필요하겠죠. 호스팅은 시작에 불과할 뿐입니다. 다행히 웹 서비스를 구축하는 데에는 수많은 문서와 솔루션들이 존재하니

서버와 호스팅 서비스에 대해 이해하는 데 많은 도움이 되었길 바랍니다. 읽어주셔서 감사합니다.

The post 서버란 무엇인가요? 그리고 어떻게 구축하나요? appeared first on JooTC.

Red Hat Enterprise Linux 8 (이하 RHEL8)이 정식 출시되었습니다.

레드햇(Red Hat)은 이번 5월 7일 Red Hat Summit 2019 행사를 개최하고 새로운 레드햇 계열 엔터프라이즈 서버 운영체제인 RHEL 8을 공개했습니다.

레드햇 계열의 리눅스 배포판은 서버용으로 적합할 뿐만 아니라 높은 안정성, 보안성, 쉬운 패키지 관리 등의 다양한 솔루션을 제공하는 운영체제로서 서버 운영체제 계열에서 상당한 점유율을 차지하고 있습니다.

무엇이 달라졌을까요?

2014년 RHEL 7을 배포한지 5년 만에 새로운 버전으로 찾아오면서 지능형 OS (Intelligent Operating System)를 기반으로 한 다양한 기능이 추가되었습니다.

RHEL 8은 Fedora 28, 리눅스 커널 버전 4.18.0-80와 GNOME 3.28을 기반으로 하였습니다. 작년인 2018년 11월 14일 부터 베타 버전이 배포되었으며, RHEL 7과 마찬가지로 Systemd 기반의 init 시스템을 사용합니다.

향상된 명령줄과 웹 콘솔 기능으로 브라우저 기반 인터페이스를 통해 원격으로 가상 머신을 관리할 수 있도록 합니다. 또한 머신 러닝, 예측 분석, 엣지 컴퓨팅 등의 기능으로 이머징 기술을 실현할 수 있도록 하였습니다.

또한 Open SSL 1.1.1과 TLS 1.3 암호화를 지원하고 한 번의 설정으로 암호화 정책을 구성할 수 있도록 보안적인 기능 또한 개선시켰습니다.

자바, 파이썬과 같은 응용 프로그램의 특정 버전 지원 문제를 개선하기 위해 3년 주기의 메이저 릴리스와 6개월 주기의 마이너 릴리스 계획도 발표했습니다. 어플리케이션 스트림 기능을 통해 응용 프로그램을 OS와 분리함으로서 운영체제의 업데이트를 기다리지 않고 응용 프로그램의 다음 버전으로 업그레이드하기에 좋은 환경을 만들어 낼 수 있게 됩니다.

앞으로의 행보는?

RHEL의 배포 형식인 레드햇 엔터프라이즈 리눅스 코어OS(Red Hat Enterprise Linux CoreOS) 또한 출시 될 예정입니다.

조만간 동일한 레드햇 계열의 오픈소스 운영체제인 CentOS 8도 공개될 것으로 보입니다. CentOS 8은 다음 타임 테이블(https://wiki.centos.org/About/Building_8)을 통해 곧 CentOS 8 1905 빌드가 릴리스될 것임을 알리고 있습니다.

Red Hat Enterprise Linux 8에 대한 더 많은 소식은 아래 링크에 자세히 나와있습니다.

https://www.redhat.com/ko/enterprise-linux-8

참고 링크

• Red Hat Enterprise Linux – Wikipedia : https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux
• 레드햇, 5년 만에 RHEL 최신 버전 발표…하이브리드 클라우드 지원 강화 – 전자신문 : http://www.etnews.com/20190508000001

The post 레드햇(Red Hat), Red Hat Enterprise Linux 8 (RHEL 8) 정식 출시 appeared first on JooTC.

Error Code: 145. Table './mydatabase/mytable' is marked as crashed and should be repaired

해결 방법

이 문제는 데이터베이스 서버에 예기치 못한 에러가 발생했거나 일부 데이터나 실행 프로세스가 손상되었을 경우에 발생합니다. 에러 메세지에 표시된 내용대로 해당 테이블을 복구해주면 대부분은 문제가 해결될 것입니다.

다음 명령어를 사용하여 테이블 복구를 진행해보는 것을 권장합니다.

USE [Database Name];
REPAIR TABLE [Table Name];

지금은 리눅스 터미널에 있다고 가정하고 위 명령어를 사용해보겠습니다. mysql 명령어를 사용하여 콘솔에 로그인합니다. (데이터베이스 관리자 권한을 가진 사용자로 로그인합니다. 여기서는 root로 진행하겠습니다.)

$ mysql -uroot -p
Enter password:

이후 특정 테이블을 참조하기 위해 USE 문을 사용하여 데이터베이스를 지정합니다. 여기서는 데이터베이스 이름을 mydata로 가정해보겠습니다.

mysql> use mydata;
Database changed

먼저 ANALYZE TABLE [Table Name] 구문을 사용하여 현재 테이블에서 발생하는 문제가 어떤 것인지 파악해볼 수 있습니다. 에러 코드 145로 테이블 조회에 실패했음을 알 수 있습니다.

mysql> analyze table mytable;
+----------------+---------+----------+----------------------------------------------+
| Table          | Op      | Msg_type | Msg_text                                     |
+----------------+---------+----------+----------------------------------------------+
| mydata.mytable | analyze | status   | Can't open file: 'mytable.MYI'. (errno: 145) |
+----------------+---------+----------+----------------------------------------------+
1 row in set (0.00 sec)

쿼리가 실행될 때 에러가 발생한 테이블 이름으로 테이블 복구를 진행해보겠습니다. 테이블명은 mytable이라고 가정합니다.

mysql> repair table mytable;
+----------------+--------+----------+----------+
| Table          | Op     | Msg_type | Msg_text |
+----------------+--------+----------+----------+
| mydata.mytable | repair | status   | OK       |
+----------------+--------+----------+----------+
1 row in set (10 min 23.40 sec);

진행이 모두 완료되면 Msg_text 컬럼의 값이 OK로 표시될 것입니다. 2G 용량의 데이터베이스에 대해 대략 10분 정도 소요되었습니다.

테이블의 실제 크기에 따라 복구에 소요되는 시간이 다소 걸릴 수 있으므로 주의해주세요.

The post Table ‘./db/tbl’ is marked as crashed and should be repaired 문제 appeared first on JooTC.

Gmail SPF NEUTRAL 상태 해결하기

SPF(Sender Policy Framework) 상태가 NEUTRAL 인 경우는 DNS레코드의 SPF 정보가 없거나 잘못될 때 이메일 수신 제공자가 확인하지 못하였을 때 발생합니다. 따라서 스팸 메일로 분류되거나 스푸핑 공격(승인되지 않은 외부 사용자가 호스트 주소를 도용하여 이메일 발신)이 발생될 수 있습니다.

쉽게 말하면 외부 메일 서버에서 특정 도메인 주소를 사용하여 메일을 보내는 것을 해당 도메인이 확인해야 하는 것입니다. 이러한 승인 규칙이 없으면 Gmail은 위조된 이메일로 판단할 수 있습니다.

기존 메일 서버의 설정이 완료되고 메일 전송에 특별한 문제가 없는 경우를 기준으로 아래 내용이 모두 설정되었는지 확인해보세요.

• 메일 서버에 대한 TXT 레코드 설정이 제대로 설정되었는지 확인해야 합니다.
  • 특정 호스팅 업체는 TXT 레코드에 ” 를 포함하지 못하게 할 수 있습니다.
  • TXT 레코드 내용에는 주석을 제외한 따옴표 안의 내용만 포함되어야 합니다.
• 메일 서버에서 사용하는 도메인 주소 및 IP가 sendmail 또는 opendkim의 허용된 호스트 목록에 포함되는지 확인하세요.
  • opendkim : /etc/opendkim/TrustedHosts 파일에 메일 서버와 관련된 호스트 정보가 들어있는지 확인해야 합니다.
  • sendmail : /etc/mail/access 그리고 /etc/mail/local-host-names 파일에 로컬 호스트 정보가 올바르게 표기되어 있는지 확인해야 합니다.

위 내용에 문제가 없음에도 메일 전송 시 확인되지 않은 도메인으로 인식될 경우에는 아래 방법을 시도합니다.

먼저 수신된 메일의 ‘원본 보기’를 클릭합니다.

대략 상세 내용은 아래와 같을 것입니다.

Delivered-To: [My Gmail Address]@gmail.com
Received: by 2002:a4a:bdc:0:0:0:0:0 with SMTP id 89-v6csp275809oou;
        Tue, 12 Jun 2018 23:04:44 -0700 (PDT)
X-Google-Smtp-Source: ADUXVKLT5z9wfKy8UznsYuOljFqD+UH97HMu9insdmjeKKVXm9mE6buGIpD+gstUtup3wFATmQid
X-Received: by 2002:a63:6383:: with SMTP id x125-v6mr2807112pgb.277.1528869884091;
        Tue, 12 Jun 2018 23:04:44 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1528869884; cv=none;
        d=google.com; s=arc-20160816;
        b=YFq5HhoCdHVt/oK[생략]RP2x902CDVS3J+1zPbhl+WC7e9xMMYA8Ul68sBYrxLzTac
         n5jA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=message-id:from:date:arc-authentication-results;
        bh=l5PeLcZlR71AKUdJDlY4kSZ2nqmUIhWxk7ESpIRZXIs=;
        b=LLX0NmkGnPA0mSp61vhK[생략]WaMJsWqVY/DoAl
         1ylA==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=neutral (google.com: [My IP Address] is neither permitted nor denied by best guess record for domain of myuser@mail.[myserver].com) smtp.mailfrom=myuser@mail.[myserver].com
Return-Path: <myuser@mail.[myserver].com>
Received: from mail.[myserver].com ([[My IP Address]])
        by mx.google.com with ESMTPS id a10-v6si2050707pls.480.2018.06.12.23.04.43
        for <[My Gmail Address]@gmail.com>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 12 Jun 2018 23:04:44 -0700 (PDT)
Received-SPF: neutral (google.com: [My IP Address] is neither permitted nor denied by best guess record for domain of myuser@mail.[myserver].com) client-ip=[My IP Address];
Authentication-Results: mx.google.com;
       spf=neutral (google.com: [My IP Address] is neither permitted nor denied by best guess record for domain of myuser@mail.[myserver].com) smtp.mailfrom=myuser@mail.[myserver].com
Received: from mail.[myserver].com (localhost [127.0.0.1]) by mail.[myserver].com (8.14.7/8.14.7) with ESMTP id w5D64gVL019619; Wed, 13 Jun 2018 15:04:42 +0900
Received: (from root@localhost) by mail.[myserver].com (8.14.7/8.14.7/Submit) id w5D64e1Q019618; Wed, 13 Jun 2018 15:04:40 +0900
Date: Wed, 13 Jun 2018 15:04:40 +0900
From: myuser@mail.[myserver].com
Message-Id: <201806130604.w5D64e1Q019618@mail.[myserver].com>

test.

여기서 확인해봐야 하는 에러메세지는 이 부분입니다.

spf=neutral (google.com: [My IP Address] is neither permitted nor denied by best guess record for domain of myuser@mail.[myserver].com) smtp.mailfrom=myuser@mail.[myserver].com

위와 같이 메세지가 표시되었다면 도메인을 제공받고 있는 호스팅 업체의 관리 페이지에 접속하셔서 추가적인 TXT 레코드를 등록해야 합니다.

저같은 경우에는 가비아입니다. 가비아의 DNS 레코드 설정 페이지로 들어가보겠습니다.

이제 아래와 같이 TXT 레코드에 메일 서버에 대한 허용 정보를 추가해주시면 됩니다.

"v=spf1 mx ip4:[메일 서버 IP] ~all" 또는
"v=spf1 a mx ip4:[메일 서버 IP] include:_spf.google.com ~all"

위 두번째 예시처럼 스푸핑 방지를 위해 각 메일 수신 제공자의 spf 서버를 추가하는 것이 좋습니다. 예를 들어 구글은 _spf.google.com 이며 네이버도 spf.naver.com과 같이 사용됩니다. 두 개 이상의 호스트 정보가 있을 때는 공백으로 구분하며 ~all 은 마지막에 한 번만 들어갑니다. ip와 도메인 이름을 사용할 때는 ip4와 a, 릴레이 도메인은 include와 같이 서로 다른 이름을 사용하므로 주의해서 작성해야 합니다.

어렵다면 아래 링크로 SPF 규칙을 쉽게 생성할 수 있습니다.

• SPF 작성 도우미 (국내 KISA) : https://www.kisarbl.or.kr/spf/spfWizard_step1.jsp
• SPF Wizard : https://www.spfwizard.net/

모두 적용되면 아래와 유사할 것입니다. (특정 서버 마다 설정해야 하는 내용이 다를 수 있으며 아래는 예시입니다.)

DNS 서버의 갱신에는 시간이 소요되므로 약 1일 이상이 지나면 수신되는 메일의 SPF 상태가 ‘PASS’가 될 것입니다.

참고 문서

• SPF로 발신자 권한 부여 : https://support.google.com/a/answer/33786?hl=ko
• 가비아 DNS 레코드 설정 : https://customer.gabia.com/manuals/detail.php?seq_no=2805
• Sender Policy Framework : http://www.openspf.org/Project_Overview

The post Gmail SPF NEUTRAL 상태로 수신되는 문제 해결하기 appeared first on JooTC.

PHP 에러 메세지 출력 또는 숨기기

웹사이트에 PHP 에러 메세지가 보이지 않을 경우 아래 대처 방법으로 에러 메세지를 표시할 수 있도록 전환할 수 있습니다. (반대의 경우에도 해당)

주의 : PHP 에러 메세지는 개발 중이 아닐 때는 보안상 가급적 보이지 않도록 하는 것이 좋습니다.

먼저 한 페이지에서만 임시적으로 에러 메세지를 보이게 하는 방법입니다.

아래 코드를 PHP 코드 상단에 붙여넣어보세요.

<?php
    error_reporting(E_ALL);
    ini_set('display_errors', '1');
?>

이 코드가 적용된 페이지에서는 PHP 오류 코드 및 메세지가 나타날 것입니다.

반대로 오류 메세지를 끄고 싶다면 아래와 같이 지정하거나, 위 코드 부분을 지워주시면 됩니다.

<?php
ini_set('display_errors', '0');
?>

에러 메세지를 영구적으로 보이거나 보이지 않게 하려면 서버 내의 php.ini 파일을 수정해야 합니다.

서버 접근 권한이 있을 경우 php.ini 파일을 수정해주세요. 아래는 Linux 서버 기준으로 설명합니다.

# vim /etc/php.ini

php.ini 파일이 열리면 아래 부분을 찾아주세요.

먼저 error_reporting 옵션은 어떤 종류의 에러 메세지를 표시할 것인지에 대한 설정입니다. 각 에러 표시 항목을 ‘&’ 로 구분하고 ‘~’ 기호를 앞에 붙이면 관련된 에러 메세지는 표시하지 않게 됩니다. 기본 값은 ‘E_ALL & ~E_DEPRECATED & ~E_STRICT’ 입니다.

; Error Level Constants:
; E_ALL             - All errors and warnings (includes E_STRICT as of PHP 5.4.0)
; E_ERROR           - fatal run-time errors
; E_RECOVERABLE_ERROR  - almost fatal run-time errors
; E_WARNING         - run-time warnings (non-fatal errors)
; E_PARSE           - compile-time parse errors
; E_NOTICE          - run-time notices (these are warnings which often result
;                     from a bug in your code, but it's possible that it was
;                     intentional (e.g., using an uninitialized variable and
;                     relying on the fact it is automatically initialized to an
;                     empty string)
; E_STRICT          - run-time notices, enable to have PHP suggest changes
;                     to your code which will ensure the best interoperability
;                     and forward compatibility of your code
; E_CORE_ERROR      - fatal errors that occur during PHP's initial startup
; E_CORE_WARNING    - warnings (non-fatal errors) that occur during PHP's
;                     initial startup
; E_COMPILE_ERROR   - fatal compile-time errors
; E_COMPILE_WARNING - compile-time warnings (non-fatal errors)
; E_USER_ERROR      - user-generated error message
; E_USER_WARNING    - user-generated warning message
; E_USER_NOTICE     - user-generated notice message
; E_DEPRECATED      - warn about code that will not work in future versions
;                     of PHP
; E_USER_DEPRECATED - user-generated deprecation warnings
;
; Common Values:
;   E_ALL (Show all errors, warnings and notices including coding standards.)
;   E_ALL & ~E_NOTICE  (Show all errors, except for notices)
;   E_ALL & ~E_NOTICE & ~E_STRICT  (Show all errors, except for notices and coding standards warnings.)
;   E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR  (Show only errors)
; Default Value: E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
; Development Value: E_ALL
; Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT
; http://php.net/error-reporting
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

다음으로 에러 메세지를 켜고 끌 수 있는 옵션입니다.

; This directive controls whether or not and where PHP will output errors,
; notices and warnings too. Error output is very useful during development, but
; it could be very dangerous in production environments. Depending on the code
; which is triggering the error, sensitive information could potentially leak
; out of your application such as database usernames and passwords or worse.
; For production environments, we recommend logging errors rather than
; sending them to STDOUT.
; Possible Values:
;   Off = Do not display any errors
;   stderr = Display errors to STDERR (affects only CGI/CLI binaries!)
;   On or stdout = Display errors to STDOUT
; Default Value: On
; Development Value: On
; Production Value: Off
; http://php.net/display-errors
display_errors = Off

display_errors의 값이 On이면 에러를 표시, Off면 에러를 표시하지 않게 됩니다. 물론 이 값이 Off로 되어있어도 PHP 코드 내에 ini_set으로 에러 메세지 표시를 하게 되면 에러 메세지가 나오게 됩니다.

적용이 완료되면 파일을 저장하고, PHP-FPM 서비스를 재시작해야 합니다.

# service php-fpm restart (또는 systemctl restart php-fpm)

이제 에러 메세지가 정상적으로 표시될 것입니다.

The post [PHP] 에러 메세지 출력 또는 숨기기 설정 방법 appeared first on JooTC.

nginx 504 Gateway Time-out 에러 해결 방법

nginx 504 Gateway Time-out 문제는 리버스 프록시의 응답이 지연되거나 서버 내 프록시 타임아웃으로 지정된 값을 초과할 경우에 발생합니다.

먼저 NginX 설정에서는 아래와 같이 해결하실 수 있습니다.

/etc/nginx/nginx.conf 파일(개별 서버의 config 파일 위치는 서버 마다 다를 수 있습니다.)을 수정합니다. location 블록 내에 아래와 같이 입력합니다.

location / {
    proxy_connect_timeout 300;
    proxy_send_timeout 300;
    proxy_read_timeout 300;
    send_timeout 300;
}

다음으로 php-fpm을 사용 중인 경우 /etc/nginx/fastcgi.conf 파일을 수정합니다. (fastcgi 관련 설정 파일이므로 서버 마다 파일명과 경로가 다를 수 있습니다.)

fastcgi_read_timeout 300;

위와 같이 설정을 적용하고 Nginx 서비스를 재시작해주시면 됩니다.

# service nginx restart (restart 또는 reload)
또는
# systemctl restart nginx (restart 또는 reload)

The post nginx 504 Gateway Time-out 에러 발생 시 대처 방법 appeared first on JooTC.

Nginx 캐시 설정 및 캐시 만료일 기간 설정

서버의 과다 트래픽 발생 방지를 위해 이미지나 웹 콘텐츠에 대해서 서버단에서의 캐시 컨트롤을 활성화하는 것이 좋습니다.

Nginx는 apache와는 다르게 .htaccess 파일보다는 주로 nginx.conf 파일과 같은 서버 config 파일에서 액세스 설정을 하게 됩니다.
(서버에 따라 nginx.conf 라는 파일이 다른 이름으로 사용될 수 있음)

물론 브라우저의 캐시와 관련된 설정 또한 nginx.conf 파일에서 바로 지정할 수 있습니다. 이는 .htaccess에서의 캐시 설정법과 비슷하면서도 다릅니다.

여기서는 일반적인 정적 파일 캐시 설정만 작성하였습니다. 자세한 문서는 아래 링크를 참조해주세요.
https://www.nginx.com/blog/nginx-caching-guide/

아래 nginx.conf 예시를 살펴보겠습니다.

# Enable Cache Control
location ~* \.(?:jpg|jpeg|png|gif|ico|gz|svg|svgz|ogg|mp4|webm|ogv|htc|cur)$ {
    expires 3M;
    access_log off;
    add_header Cache-Control "public";
}   
location ~* \.(?:css|js)$ {
    expires 1M; 
    access_log off;
    add_header Cache-Control "public";
}   
location = /favicon.ico {
    expires max;
    access_log off;
    log_not_found off;
}

먼저 위 구문은 location 블록을 사용하므로, server 블록 내에 들어가야 합니다. 원하는 URL 또는 확장자 경로를 지정하여 어떤 확장자의 파일에 대해 캐시를 지정할 것인지를 나타낼 수 있습니다. 대개 그림이나 음악, 영상 파일 또는 css, js 파일은 컨텐츠가 자주 변하는 일이 없으므로 1~4개월 이상의 캐시 만료일을 지정합니다. 여기에서 html, php 확장자를 가진 웹 페이지를 구성하는 파일들은 페이지가 지속적으로 변하기 때문에 따로 작성하지 않는 것을 권장합니다.

expires를 사용하여 캐시가 만료되는 일자를 설정할 수 있습니다.
예를들어 2개월 동안 캐시를 유지하고자 할 경우 ‘2M’을, 1년동안 유지하고자 할 떄는 ‘1y’와 같이 설정합니다. (d=일/M=월/y=년)

expires는 일/월/년 단위이지만 이 대신에 add_header Cache-Control “public”, max-age=[초];를 사용하면 초 단위로도 표현하실 수 있습니다. 예를 들어 캐시 만료일을 30일로 설정하고 싶다면 아래와 같이 2592000(60*60*24*30 초)로 설정해주시면 됩니다.

add_header Cache-Control "public", max-age=2592000;

access_log는 해당 파일을 읽어들일 때 로그를 남기는가에 대한 여부입니다. 위 컨텐츠에 대해서는 대부분 로그를 남길 필요성이 크지 않으므로 off로 설정하였습니다. 마찬가지로 log_not_found는 해당 파일이 없을 경우에 로그를 남길지에 대한 여부입니다. off인 경우 로그를 남기지 않습니다.

이렇게 기본적으로 브라우저 캐시 만료에 대한 설정을 할 수 있습니다.

해당 내용의 편집이 완료되었다면 nginx 서비스를 재기동해주어 적용을 완료합니다.

서버 종류에 따라 아래 명령어 중 하나로 nginx 서비스를 재기동할 수 있습니다.
$ sudo systemctl restart nginx (재시작)
$ sudo systemctl reload nginx (리로드)
또는
$ sudo service nginx reload (재시작)
$ sudo service nginx restart (리로드)

The post Nginx 캐시 설정 및 만료 기간 지정하기 appeared first on JooTC.

aaa.com으로 세션을 생성할 때, sub.aaa.com과 같은 서브도메인에서는 세션이 공유되지 않아 세션변수가 가져오지 않는 문제가 발생할 수 있습니다.

해결하기

서브도메인간 세션 공유를 위해서는 아래와 같이 php문서의 최상단에 세션 쿠키 설정을 지정해야 합니다.

// sample_name으로 세션명을 반환하게 됩니다. 이 줄이 있어야만 서브도메인간 세션이 공유됩니다.
$sample_name = session_name("sample_name");
// 세션 쿠키의 적용 경로를 설정합니다. (.domainname.com에는 자신의 도메인명 삽입)
session_set_cookie_params(0, "/", ".domainname.com");
// 세션을 시작합니다.
session_start();

유의할 점은 session_start(); 위에 작성해야 하는 것과 session_name 함수를 반드시 사용해야 한다는 것입니다.

// 문제가 해결되지 않는다면, 아래 줄을 추가해보세요.
ini_set("session.cookie_domain", ".domainname.com");

The post [PHP] 서브도메인 주소간의 세션 공유하는 방법 appeared first on JooTC.