카테고리 Archives: Server engineering

Cron 을 활용한 SSD 강제 trim

background trim이 활성화 된 경우 성능 저하에 별다른 대비를 할 필요성이 없어지기 때문에 시스템 관리가 편해진다.

물론 평상시 파일 삭제시 trim 활성화가 되어 있다면 그만큼 성능 저하가 발생한다.

 

시스템 목적에 따라 최대한의 IO 성능을 확보하기 위해서 cron 과 스크립트를 활용하여 주말등 한가한 시간대에 trim 이 될수 있도록 한다.

목표 시간이 없이 단순 주말에 하는것을 원한다면 /etc/cron.weekly 폴더안에 생성한다.

 

sudo 보안 취약점 CVS-2017-1000367

sudo 명령을 이용하여 root 권한을 탈취 할 수 있는 보안 취약점이 공개 되었습니다.

일반적인 보안 권고 사항인 그룹 지정(wheel 과 같은)을 한 경우에는 관련이 없습니다.

또한 selinux 를 활성화 하고 그룹 지정이 없이 운영 할 경우에는 아래 메뉴얼에 따라 sudo 명령어를 업데이트 하시기 바랍니다.

다만 업데이트가 쉽기 때문에 진행을 하는것이 좋습니다 🙂

[참고 사이트]

Ubuntu https://www.ubuntu.com/usn/usn-3304-1/
CentOS https://lists.centos.org/pipermail/centos-announce/2017-May/022450.html

주의 사항 : 업데이트를 할 경우 명령어의 소유권 및 퍼미션이 초기화가 되어 권한이 -rwsr-xr-xr   소유권 및 그룹이 root:root 가 되므로 기존에 쓰던 정보를 확인 하고 나서 sudo 업데이트 후에 재 지정 해야 합니다.

 

CentOS

 

Ubuntu

 

mod_pagespeed with apache 2.4.x

구글이 공개한 mod_pagespeed를 컴파일된  apache 2.4 에 설치하는 방법을 설명 한다.
구글의 경우 nginx 의 경우 컴파일 버전을 apache 버전은 rpm 버전으로 제공 하고 있으며
일반적으로 yum 설치되어 /etc/http 안에 위치한경우 rpm 설치만으로 활성화가 가능 하다.

 

다만 컴파일을 해서 prefix 가 다른곳에 있을경우 rpm을 설치한다면 dependency 때문에 yum 으로 httpd 가 설치되어 시스템이 꼬이게 되므로 설치할 수 없는게 일반적인 상식 ‘ㅅ’..

하지만 yum 으로 설치가능한 httpd 의 경우 버전이 매우 낮아 새로운 기술을 전혀 활용하지 못한다… SNI 라던가 HTTP/2 라던가..
때문에 구글이 배포한 rpm을 분해하여 서버에 맞게 편집한뒤에 적용을 한다 ‘ㅅ’b
1. mod_pagespeed 배포 는 https://developers.google.com/speed/pagespeed/module 에서 다운받아서 rpm2cpio 명령어를 이용해 rpm을 분해 한다.

 

2. 압축해제된 파일을 경로에 맞게 수정 이동 시킨다 ‘ㅅ’a  ( 예제 에서 컴파일된 위치는 /usr/local/apache 이다. )

 

3. httpd.conf 에서 pagespeed.conf 파일을 불러오도록 설정 한다.

 

4. 아래는 개인적으로 편집한 pagespeed.conf 파일이다 ‘ㅅ’a

memcache 를 쓴다면 중간에 주석처리된 ModPagespeedMemcached 관련 옵션을 활성화 한다. ‘ㅅ’a

 

외부에서 js 를 가져오는 부분의 속도가 빨라지기 때문에 js를 많이 쓰는 복잡하고 느린 사이트일수록 사이트 가속된것을 체감할수 있는것으로 확인됨 ‘ㅅ’b
그리고 또 js minify 기능이 있기 때문에 별도로 개발자가 신경을 쓰지 않아도 되기 때문에 매우 편한 mod 인듯…

설치를 추천합니다 ‘ㅅ’ b

간혹 캐시 적용으로 사이트가 특정 경로상에 문제가 발생하는 경우 아래와 같이 특정 경로에서 기능을 끄거나
사이트 전제 pagespeed 적용을 해제 할 수 있다.

 

데이터베이스 마이그레이션

EUC-KR 에서 UTF-8 로 DB마이그레이션을 진행할때 캐릭터셋 전환에 따라 일부 문자가 유실 되거나 깨지게 되어 dump된 파일의 복구가 곤란한 경우가 발생하였다.

sql은 복원중 에러가 발생을 할경우 하위 내용을 복구를 하지 않기 때문에..
이러한 경우 보통 sql 파일을 하나하나 수정해가면서 다시 부어넣는 짓을 해야한다 =_=a

DB용량이 작다면 하나하나 수정해줄수 있지만 100M단위를 넘어가는 파일을 변경하긴 어렵다.
때문에 테이블 생성정보와 데이터를 따로 따로 백업을 하고 먼저 테이블을 생성한뒤에 복구하는 방법을 쓰기로 하고 스크립트를 작성하였다.

 

위와 같이 원본서버에서 백업을 할때 데이터를 분리 한뒤에 iconv를 이용해서 캐릭터셋 치환을 하고 캐릭터셋 선언을 바꾸어 준다.

이중 -c 옵션은 에러가 나는 문자열을 제외하고 치환하는 옵션이다.
가급적 에러가 나지 않는게 좋겠지만 ‘ㅅ’…

 

새로운 데이터 베이스에 먼저 테이블 복원을 한다.

아래와 같은 스크립트작성을 한 뒤에 실행한다.

IFS 를 통해 구분자를 엔터(\n) 으로 지정한뒤 for 문을 돌려 한줄한줄 복원을 시도 하고
에러가나는 구분은 error_query.sql 파일로 별도 저장을 한다.

추후 error_query.sql 파일을 분석하여 쿼리문을 완성 시켜 재 복원을 하거나… 버리거나.. 할수 있겠다.

 

테이블 복원중 VARCHAR(255) UTF8 is too long for key, but max length is 1000 bytes 가 나오는 경우가 발생할수 있다.
key로 사용되는 컬럼의 길이가 1000byte를 넘어가면 안된다는 메세지 이다.
(Mysql에서 UTF8의 경우 문자당 3byte 를 사용한다 – utf8mb4 = 4Byte 를 쓴다..)

이경우 key로 사용되는 컬럼의 varchar 값을 최대치인 333이하를 쓰도록 한다.
일반적으로 2개 이상의 컬럼은 하나의 키로 사용하는 부분에서 에러가 난다. 그때는 사용된 컬럼의 합이 333 이하여야 하겠다.

utf8mb4의 경우에는 200 이하로 해야겠고.. 그래서 대략 아래와 같이… 큰 varchar 컬럼을 앞95자까지 인식하도록 하게 한다.
컬럼A varchar(255)
컬럼B varchar(255)
KEY 키명 (컬럼A(95),컬럼B(95)),

 

mariaDB yum을 이용한 설치 ( CentOS 7 )

https://downloads.mariadb.org/mariadb/repositories

위 주소에서 먼저 맞는 OS 버전 및 설치할 mariaDB 선택한다 ‘ㅅ’a
20161114_picpick_161119

 

그후 나오는 내용을 레포지트리에 추가를한다.

 

그담 yum 으로 설치 고고싱.

 

초기 mysql 데이터폴더는 /var/lib/mysql 에 있다.
그래서 data 폴더를 이동하게 되는 경우에는 저 폴더를 다른 위치 및 이름으로 변경을 한다.
물론 /etc/my.cnf 에서 아래 부분을 찾아 고치는것도 병행해야 한다.
운영하려는 캐릭터셋에 맞게 설정을 추가하는것도 잊지 말자 (latin1 으로 깔리기 때문에….)

 

datadir에 selinux 설정을 한다

 

이후에 데몬 자동시작 등록 및 시작을 한다.

 

mysql 명령어로 mysql 에 로그인을 한뒤에 root 패스워드를 지정하고
보안을 고려하여 user 등이 비어있는 로그인정보 및 test 데이터베이스를 삭제해야 한다.