카테고리 Archives: Apache

GEOIP database 파일 업데이트

기존 GeoIP 스크립트에서 GeoIP.dat 파일이 0 으로 생성을 하게 되어서 Apache에 에러가 발생 하였다.

에러 메세지는 아래와 같이 /var/log/httpd/error_log 파일과 /var/log/messages 파일 에서 확인 되었다.

 

내용 확인 결과 maxmind 에서 배포 되는 csv 파일이 2024년 5월 1일 부로 S3 presigned 를 이용하여 배포 하는 형태로 바뀐것으로 확인이 되었다.

오랜만에 maxmind 사이트에 로그인을 해보니 라이선스 키 길이도 바뀌어서 같이 바꾸는게 좋겠다. 🙂

중간에 주석 처리된 3줄은 python2를 사용하는 서버(centos 7 이하)에서는 주석을 제거 하고 사용해야  한다.

 

몇가지 로직 개선 및 mmdb 파일까지 갱신 하도록 geoipupdate 명령을 중간에 실행 하도록 하였다.

때문에 /etc/GeoIP.conf 파일에 자신의 어카운트 및 라이선스키를 넣어줘야 한다.

그냥 사용 할경우 www.enteroa.com 에서 생성하고 재배포 하는 파일을 다운 받아 사용 한다.

자신의 서버에서 스스로 dat파일을 생성 하고 싶을 경우 Maxmind_Licensekey 부분과 PRIMARY_SERVER_HOSTNAME 부분 또 PRIMARY_DEPLOY_URL 부분을 수정 해서 사용해야 한다.

 

라이선스키 발급 방법은 같기 때문에 maxmind 에서 라이선스 발급을 원하면 아래 역인글을 확인 한다.

역인글 : GEOIP database …

OCI arm 인스턴스에서 docker로 web, was 사용

OCI 에서 제공되는 무료 서버를 이용하여 nginx(x86) – was(arm64) – DB(arm64) 으로 잘 사용하고 있었다. (물론 앞으로도 잘 사용할 예정…)

기존엔 snapd(certbot) 도 arm64에서 정상 동작지 않았고 http3를 구현한 nginx도 베타 였으나 현재는 mainline-quic 으로 되었기 때문에
native-arm64 환경으로 이행을 통해 메모리가 적어서 상대적으로 속도가 느렸던 x86서버를 버리기 위해서 아래와 같은 목표를 구현하는 것을 목표로 잡았다.

  • Docker – Was(http,php-fpm) 의 OS를 amazonlinux2 -> rockylinux9 으로 변경 및 php-8.3 사용
  • Docker – rockylinux9 – nginx-quic(http3) 구축
  • Docker x86_64(amd64), arm64(aarch64) 을 지원

2024-09-24_102141

 


 

 

  • Docker 설치

베이스 OS는 rockylinux 9 (aarch64)이며, 서버에 docker 를 설치하고 활성화 한다. (Install Docker Desktop on RHEL)

 

Was 컨테이너 안에서 웹서비스가 apache:apache 권한 으로 동작 되기 때문에 아래와 같이 베이스 os에 같은 유져를 생성 한다.
(바깥에서 단순 UID 48으로 지정해 운영 해도 된다.)

 


 

  • 배포된 Docker 이미지를 이용한 apache, php 사용

https://hub.docker.com/r/san0123/rocky9-http-php

웹서버 또는 개발자 PC (windows)에서 공통으로 사용할 수 있도록 생성한 Docker 이미지 이다.

 

도커는 pull 을 별도로 하지 않더라도 정확한 주소를 사용할 경우 자동으로 pull 하는 기능이 있으므로 바로 run 을 실행 한다.
nginx 가 80,443 을 사용할 예정이기 때문에 9000번 포트를 이용해 run 한다.

 

웹소스를 호스트os의 /var/www/html에 넣으면 호출을 할수 있다.
파일을 복사해 넣거나 압축을 해제한 후에는 chown -R apache:apache 파일명or폴더 을 잊지 말자…

 

배포된 rocky8-httpd-php, rocky9-httpd-php 에서 CI4(code igniter 4) 사용법

 

일반적인 CMS테스트를 위할 경우 여기 까지만 진행 하고 웹서버를 서비스 하고자 할때 아래 부분까지 진행 한다.

 


 

  • 배포된 Docker 이미지를 이용한 Nginx 사용

https://hub.docker.com/r/san0123/rocky9-nginx

웹서버에서 http3 를 구현하기 위해서 apache 앞에 nginx를 사용하고 Let’s encrypt(certbot) 을 사용하기 위한 Docker 이미지 이다.

 

Nginx 도커를 이용한 http2를 위해 80/tcp, 443/tcp 그리고 http3를 위해 443/udp 을 파이어월에서 허용 한다.

 

웹용 도커는 베이스OS에서 virtualhost 설정 파일 을 저장해서 버전 업데이트시 설정 파일을 새로 설정 하지 않기 위해 mount 하기 때문에 먼저 생성을 한뒤 docker run 을 해야 한다.

 

Nginx용 도커를 실행 한다. 컨테이너를 재 생성 할때마다 인증서나 가상호스트 파일을 수정하지 않도록 두개의 마운트 포인트를 추가해서 실행한다.

 

도메인을 서버에 연결 한 뒤에 Let‘s encrypt 를 생성하는 명령어는 다음과 같다. (email, domain 은 자신에 맞게 수정해서 사용한다.)

 

베이스OS 에서 /var/www/conf/virtual.conf 를 자신의 url에 맞게 수정하고 발급된 인증서가 동작할 수 있도록 수정을 한다.

 

nginx를 재시작 하기 위해서 컨테이너를 재시작 한다.

 

http3가 잘 활성화 되어있는지 확인 한다. ( https://http3check.net/)

2024-04-27 17 14 57

 

인증서가 약 2-3개월 마다 갱신해야 하기 때문에 cronatb에 아래와 같이 등록해서 주기적인(주1회) 인증서 업데이트 및 적용을 위한 재시작을 한다. (매주 월요일 오전 8시)

 


 

데이터베이스 사용법 까지 필요 하면 아래 포스트를 확인 하자 ‘ㅅ’a

Docker 를 이용한 데이터베이스 사용법

php-fpm 서버에서의 php_value 를 선언하는 방법.

기존에 mod_php를 사용하는 php 4.x ~ 7.2 까지의 버전에서는 .htaccess 파일에서 php_value 를 설정해서 쓰는 경우가 많았다.

다만 php-fpm의 경우 별도의 데몬으로 작동을 하기 때문에 해당 값을 입력할 경우 500 에러가 발생한다.

아울러서 Apache 의 디렉토리 보안설정의 AllowOverride 설정이 All 또는 Options 으로 설정 되어 있어야 했다.
주: AllowOverride All 은 하위에서 위험한 값들을 변조 가능성을 열어 주기 때문에 보안상 매우 좋지 않으니 되도록이면 하지 말아야 한다.

 

기술적으로 php 5.6의 경우에도 php-fpm 을 사용 할 수 있기 때문에 버전으로 나누기 보다 phpinfo() 에 선언된 값을 보고 php-fpm 인지 판단해야 한다.

20240326_140656

위 캡춰 이미지와 같이 php-fpm 으로 구성된 서버에서는 php 코드 안에서의 ini_set 을 선언하거나 .htaccess 에서 php_value 선언을 해도 무시되거나 500 에러가 발생 한다고 생각 하면 쉽다.

권고 되는 방법은 apache 웹서버내에서 선언되거나 php-fpm 에서 선언 되거나 user.ini 를 불러오도록 설정해서 하는 방법이다. 다만 이경우 서버 설정을 건들이기 때문에 직접 수정이 불가능한 경우가 많겠다.

 

먼저 php.net 에서 공개해둔 메뉴얼 https://www.php.net/manual/en/ini.core.php을 보게 되면 아래와 같이 Changeable 이 공개 되어 있다.

20240326_141221

php_value 으로 변경 할 수 있는 값은 INI_PERDIR 또는 INI_ALL 이다.

INI_SYSTEM 의 경우 PHP_ADMIN_VALUE 으로 선언이 가능하지만.. 일반 계정에서의 선언은 되지 않고 웹서버(apache conf 파일) 에서 선언해야만 인식 한다.

설정 방법은 아래와 같다.

주의 할점은 $_SERVER 으로 전달 하는 부분이기 때문에 하나의 SetEnv만 인식 한다는 부분이다. 여러 가지의 PHP_VALUE 를 선언 하기 위해서는 vi 에디터로 수정을 해야 한다.

Ctrl + v 를 누르면 ^ 부분이 vi 에디터에 입력이 되는데 이후 Enter 를 입력하면 파란색의 ^M 표시기를 입력할 수 있다.
ftp를 이용하려 전송할때 ascii 파일을 binary로 전송했을때 칸 구분에 붙은 그 표기가 맞다.

이를 아래와 같이 입력하면 여러개의 PHP_VALUE 를 사용할 수 있다.

20240326_154447

Oracle Linux 8 (arm64) 서버에 httpd, php 설치

아래 글은 오래 되어 도커 이미지 등이 삭제 되었으니 공부 차원이 아니라 이용을 하려면 아래 확인 하세요 ‘ㅅ’a

OCI arm 인스턴스에서 docker로 web, was 사용

 


오라클 클라우드의 무료 서버중 x86 서버인 VM.Standard.E2.1.Micro 의 경우 1/8 OCPU 및 1GB 메모리를 제공 한다.

2022-05-04_150958

1/8 OCPU 이는 cpu중 12% 점유율 사용량을 허용 한다는 말이다.

서버 내부에서는 2 논리 core 으로 확인 되기 때문에 각각의 cpu당 25% 의 점유율을 사용할 수 있다고 본다.

초과해서 사용할경우 과금 이 되거나 사용이 제한될 수 있는 요소이다.

 

메모리의 경우에는 dmesg 명령어로 아래와 같이 확인이 되었다.

즉 전체 용량 1018MB 에서 커널 보호를 위해 280MB 를 제외한 678MB를 쓸수 있다.

linux 커널에서 일반적으로 약 500MB정도를 사용한다고 보면 가용 메모리가 278MB 정도 밖에 되지 않는다.

쓰다보면 메모리가 swap 처리 되어서 WEB/WAS 사용가능한 메모리는 약 270~500MB 사이 정도가 될 것이다.

현재 블로그와 같이 구글 애드센스가 도입된 wordpress 사이트는 약 1.2초 대의 로딩 속도가 나오는 정도의 성능으로 확인되었다.

 

다만 방문객이 일정량 이상 늘어날 경우 급격히 느려지고, php-fpm이 메모리 과점으로 php-fpm 장애가 발생하는등의 문제가 발생 하였다.

그래서 ARM cpu 를 사용하는 VM.Standard.A1.Flex 를 이용해 was 서버를 운영하는 방법으로 구성을 해보았다.

아래는 OCI의 oracle linux 를 설치 했을때 기본적으로 진행해야 하는 명령어 모음 이다.

 

aarch64(ARM64) CPU를 사용 하는 경우 다음과 같은 문제가 있다.

  1. ARM64용 서드 파티 레포지토리는 거의 없는 편이다. (최신 php 버전을 제공 하는 remi 레포 또는 webtatic 등등)
  2. OS공식 레포지토리에서 제공 되는 httpd 버전은 2.4.37 버전 php 버전은 7.4.19 버전 이다.
  3. Let’s encrypt 에서 제공 되는 snapd(certbot) 이 동작을 하지 않는다. (x86_64 에서는 동작한다.)

 

위와 같은 사유로 3 티어 방식으로 운영이 되도록 구성 한다.

WAS 서버에 docker 에 amazon linux 2 (aarch64)를 이용 해서 apache + php-fpm 구성을 할 경우 최신 버전의 php 를 사용할 수 있고,

.htaccess 를 apache 문법으로 사용이 가능 하다는 장점이 있고, was 의 빠른 처리를 위한 갯수를 늘리거나 php 버전 교체도 쉬울 예정이기 때문에 채택 하였다.

 

3tier_20220511

tier 1 = x86_64 – oracle linux 8 – nginx (Let’s encrypt SSL 구성 및 리버스프록시 설정)

tier 2 = arm64 – oracle linux 8 – memcache (session 적재 용도), docker – amazon linux – httpd, phpfpm(amazon linux 가 arm64 에서 최신 php 버전을 지원한다.)

tier 3 = arm64 – oracle linux 8 – mariadb

 


 

티어2 의 구성을 위해 ARM 인스턴스에 docker 레포지토리를 추가 하고, docker 와 memcache 를 설치 하고 활성화 한다.

 

위에서 언급 했지만 ARM64 cpu는 지원 하는 서드 파티 레포지토리가 없다.

AWS 에서 사용하는 Amazon Linux 2 의경우 내장된 명령어(repo) amazon-linux-extras 를 이용하여 최신 버전의 php 7.4 및 8.0 을 사용할 수 있다.

Amazon Linux 2 는 RHEL 또는 Fedora 와 같은 계열 이라고 볼 수 있다.

 

ARM64 서버에서 http 및 php를 구동하는 도커 이미지는 기존과 같은 방법으로 생성 하였다.

 

docker 내부에서 apache 및 php-fpm 은 apache:apache 권한으로 작동을 하게 되어 있다.

아래와 같이 docker 호스트 서버에 apache 그룹 및 apache 유져를 생성 해두면 권한 문제가 맞추어 지기 때문에 퍼미션 지정이 필요 없어 진다.

 

도커 프록시로 처리되어 http 포트를 firewall-cmd 명령어로 방화벽에 열 필요는 없지만 컨테이너 안에서 ARM 호스트 서버쪽으로 session 적재를 위해 접근 하기 때문에 방화벽을 허용 처리 한다.

 

도커 명령어를 이용해 컨테이너를 생성 한다.

 

포트 매칭(:80) 및 볼륨 매칭(/var/www/html)을 해서 컨테이너는 생성 했기 때문에

docker 내부가 아닌 Oracle Linux 상의 /var/www/html 폴더로 이동 하여 아래의 내용과 같이 index.php 를 만들고 http(:80) 포트로 접속하여 확인 한다.

2022-05-04_144251

 

다음은 x86_64 인스턴스에 nginx 으로 Lets’encrypt 으로 보안서버 SSL 을 구현 하고

reverse proxy 를 해서 현재 was 서버 쪽으로 접속 시키는 부분이 남았다. (Tier 1)

하지만 was 서버도 apache를 가지고 있기 때문에 사이트를 단순히 구동 시키는건 가능 하다 ‘ㅅ’a

 

docker 를 만들때 httpd 가 생성 하는 로그는 stdout/stderr 으로 연결 해두었다.

이는 json 형태로 저장 되며 /var/lib/docker/containers/컨테이너풀아이디/컨테이너풀아이디-json.log 경로에 json 형태로 존재 한다.

명령어로 확인 하는 방법은 아래 방법으로 확인할 수 있다. [apache(httpd), php-fpm]


아래는 위에서 pull 받은 도커이미지를 구축할때 사용된 Dockerfile  이다.

 

AWS 서버 발생 로그의 분리 보관 (amazon-cloudwatch-agent)

서버내 dbus -> rsyslogd 에 의해 수집된 시스템 로그는 /var/log 아래에 파일 형태로 저장 된다.

이는 /etc/logrotate.conf 설정에 따라 서버내에 보관이 된다.

 

다만 보관된 파일의 파일 형태로 저장되어 있기 때문에 구조만 알고 있다면 파일을 삭제 하거나 변조 할 수 있으므로

추후 추적을 용의 하게 하기 위해, 데이터 무결성을 보장하기 위해, 혹은 다중의 서버의 데이터를 모아서 보관 하기위해 log 콜렉팅을 하는것이 일반적인 보안 방법 이다.

 

단순한 rsyslogd 를 이용한 udp 푸시 및 graylog collecting 은 기존에 설명을 했지만

AWS 상에서는 CloudWatch Log 라는 기능을 제공 한다 이를 통해 지표 형태로 보거나 알람 설정등을 할 수 있다.

 

서버에서는 CloudWatch log 쪽으로 데이터를 넣어주는 프로그램을 설치해서 운용 하며 이후

Log 파일의 안전한 분리 보관, 보관 주기 설정, 알람 설정 등을 웹 콘솔상에서 편하게 진행할 수 있다.

 

기존에 centos 7 에서는 yum 을 이용하여 awslogs 라는 프로그램을 설치하여 같은 기능을 사용하고 있었으나

Rockylinux 8 에서는 dnf 패키지가 없는 관계로 RPM 설치를 필요로 한다.


AWS 웹콘솔 에서 IAM 메뉴의 Role (역할) 을 생성 하고 권한을 부여 한다. (중간에 권한은 지정하지 않고 생성 하고 추후 인라인 정책으로 생성 한다.)

2022-04-08_161452 2022-04-08_161613 2022-04-08_162326

 

인라인 정책을 생성 한다. (생성한 정책이 다른 계정 이나 역할에 공통으로 부여할 필요하 있으면 일반 정책 생성 후 연결 한다.)

2022-04-08_162608 2022-04-08_163101 2022-04-08_163232

위 json 정책은 ap-northeast-2 (서울) 리전에 로그 를 쌓는 기능만 허용 하는것으로 제한 하였다.

 

생성된 Role (역할) 을 필요한 EC2에 연결 한다.

2022-04-08_164417 2022-04-08_164648

 

위에서 이야기 했지만 yum(dnf) 설치가 RockyLinux 8 에서 되지 않는다. 때문에 AWS 에서 배포 하는 rpm 파일을 가지고 설치를 진행 한다. (amazon-cloudwatch-agent  설치 메뉴얼)

 

편리하게 사용하라고 대화식 명령어를 실행 하도록 되어 있다.
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

하지만 문답 형식의 영어를 읽기도 귀찮고(어렵고) Role (정책)을 부여하여 키없이 로그를 쌓게 하고자 했으나

스크립트에서는 필수적으로 Access Key/Secret Key 를 입력 해야 하는 부분이 있기 때문에 스크립트로 진행이 어렵다.

때문에 /opt/aws/amazon-cloudwatch-agent/bin/config.json 파일을 직접 수정 해 준다. (amazon-cloudwatch-agent 설정 메뉴얼)

위 예제는 apache, php, nginx 등을 dnf(yum) 설치를 한경우 일반 적인 log 포멧의 timestamp를 인식 하도록 정리한 것이다. (secure, message 로그 및 apache, nginx, php-fpm 로그)

필요에 따라 수정을 해서 사용 하도록 한다.

 

이후 다음 명령어로 설정된 config.json 을 점검 하고 문제가 없다면 자동으로 서비스가 시작된다.

 

웹 콘솔 에서 Cloudwatch > 로그 그룹에서 보관 기간 을 설정 하고 로그 데이터가 잘 적재 되고 있는지 확인 한다.

2022-04-08_1810182022-04-08_1649512022-04-08_181557