아파치에 Access-Control-Allow-Origin 관련 설정하기.

워드프레스 테마들은 font-awesome의 아이콘을 많이 이용 한다. http://fontawesome.io/icons

폰트가 로딩이 안될경우 아래 그림처럼 아이콘이 깨져 보이게 된다 @_@a

그리고 또 다른 상황으로는 하나의 워드프레스에 여러 도메인을 연결해서 쓸때 crossorigin 관련 보안 문제 때문에
폰트나 css 로딩이 되지 않아 깨져보일수도 있다.

때문에 이를 허용해 header 에 이를 허용해주는 값을 삽입해야 한다.
일반적인 경우는 프로그래밍으로 해결 할 수 있지만 js 안에서 외부 폰트파일을 불러오도록 되어 있을경우 순수 서버설정의 헤더가 들어가기 때문에 주로 폰트쪽만 문제가 발생할 수 있다.

이경우 .htaccess 혹은 아파치 내에서 설정을 해야 해결 할 수 있겠다. ‘ㅅ’a
아래는 Access-Control-Allow-Origin를 파일에 따라 모두 허용해 줄수 있도록 설정하는 부분이다.

# CORS-enabled images & webfonts / Access-Control-Allow-Origin 관련 패치

SetEnvIf Origin ":" IS_CORS

Header set Access-Control-Allow-Origin "*" env=IS_CORS

</FilesMatch>

</IfModule>

Header set Access-Control-Allow-Origin "*"

</FilesMatch>

</IfModule>

적용 후 아파치를 재시작 하고 접속 확인을 해본다 ‘ㅅ’a

출처 : 스택오버플로우

No space left on device: Couldn’t create the rewrite-map mutex

아파치 프로세스 정상 시작 못하고 error_log 에서 아래 메세지가 나오는 경우가 있다.

1	[core:emerg] [pid 20663] (28)No space left on device: AH00023: Couldn't create the rewrite-map mutex

아파치 동작 환경에서 각 프로세스간 데이터 공유 및 동기화를 위해서 Semaphore 라는것을 생성한다.
문제는 아파치가 정상적인 종료가 아닌 강제 종료를 하게 된 경우 생성된 Semaphore 가 삭제 되지 못하고 누적이 된다는 것이다

때문에 서버에 한계선 이상까지 생성된 Semaphore 에 의해 새로운 아파치 시작시 Semaphore 를 생성하지 못해서 아파치가 시작이 되지 않는 증상이 나올 수 있다.

때문에 ipcs -s 명령어로 리스트를 뽑고 각 semid 의 연결된 pid 값을 가진 프로세스가 있는지 검사 해서
삭제하는 스크립트를 운용 한다 ‘ㅅ’a

#!/bin/bash

## Semaphore Arrays - pid 검사를 통해 종료된 pid 값을 가진 Semaphore Arrays를 종료 시킨다.

for a in `/usr/bin/ipcs -s|awk '$2~/[0-9]/{print $2}'`

do sem_pid=`ipcs -si $a|sed '/^$/d'|tail -1|awk '$5~/[0-9]/{print $5}'`

if [[ -z `ps -e|awk '$1~/^'$sem_pid'$/{print}'` ]];then /usr/bin/ipcrm -s $a;fi

done

메세지를 보면 이걸 스크립트로 만들어서 실행하고 아파치를 시작하면 된다 ‘ㅅ’a
아니면 서버에서 cron 등록해서 주기적으로 실행해도 된다 ‘ㅅ’a

PS. 세마포어와 뮤텍스는 SMP,SMT(symmetric multiprocessing/Simultaneous multi-threading) 시스템 에서 멀티쓰레드 즉 병렬화 작업을 하는데 필수적으로 사용 되는 요소로 볼수 있다 ‘ㅅ’a 무한히 생성할 순 없으며 ~]# ipcs -ls 명령어로 현재 시스템의 제한 수치를 확인할 수 있다.

리눅스 하드디스크 UUID 변경

DD 명령을 이용하거나 cat 을 이용하여 disk 클론을 뜰 경우 혹은 클라우스 서버에서 스냅샷을 이용하여 볼륨으로 환원한 뒤에 마운트를 한 경우
한 서버에 두개 UUID가 존재하게 되어 가끔 곤란한 상황이 올 수 있다.

기술적인 측면에서 한 서버에서 UUID는 겹치게 발급되어 있으면 안된다.

디스크의 UUID 는 서버내에서 blkid 명령어로 확인할 수 있다.

~]# blkid

/dev/sda1: UUID="4153a527-0921-4243-9966-5754836231d3" TYPE="ext4"

/dev/sdb1: UUID="4153a527-0921-4243-9966-5754836231d3" TYPE="ext4"

위와 같이 완벽히 같다면 부팅 단계에서 부터 꼬여서 문제가 발생 할 수 있다 ‘ㅅ’a

때문에 부득이 하게 Clone 을 사용한 경우 각 파티션의 UUID를 변경 해줘야 한다.
UUID 는 uuidgen 이란 명령어로 쉽게 만들 수 있다.

1 2	~]# uuidgen 08dfe0ac-4b11-4f53-9643-e97e0fac0810

각 파티션에 적용은 tune2fs 명령어의 -U 옵션으로 교체가 가능하다.

1	~]# tune2fs /dev/sdb1 -U `uuidgen`

역 따옴표 안의 명령어거 먼저 실행되기 때문에 위명령어로 즉시 바꿀수 있다.
변경후 blkid 명령어로 변경이 정상적으로 되었는지 재 확인 한다 ‘ㅅ’a

swap 파티션의 경우 tune2fs 가 아닌 mkswap 명령어로 변경한다.

~]# mkswap /dev/sdb8 -U `uuidgen`

~]# swapoff

~]# swapon /dev/sdb8

swap 파티션이 이미 마운트 된 상황에서는 UUID변경이 되지 않기 때문에 swapom, swapoff 명령어로 마운트를 해제하고 진행한 뒤에 재 마운트를 한다.

PS. tune2fs 명령어는 ext2~4 의 uuid 를 변경 할 수 있다.
xfs 파일 시스템은 아래의 명령어로 uuid 변경을 진행한다.

~]# xfs_admin -U `uuidgen` /dev/sdd1

Clearing log and setting UUID

writing all SBs

new UUID = e1c599ea-43b7-4423-a4ef-2747ebbd8993

Centos 5 – coreutils 최신 버전 설치.

CentOS 5 에는 coreutils-5.97 이 포함 되어 있다. – CentOS 6 에는 8.4 / CentOS 7에는 8.22 버전을 가지고 있다.

다만 좀더 최신 CentOS 에는 포함된 명령어가 없는경우가 있다.
( timeout 이라던가… 혹은 timeout 같은 거라든가.. 그것도 아니면 timeout 같은거? )
이럴 경우에는 coreutils 최신버전은 서버에 별도 설치하여 복사해서 이용하는 방법을 사용한다 ‘ㅅ’a

~]# wget ftp.gnu.org/gnu/coreutils/coreutils-8.13.tar.gz

~]# tar xvfzp coreutils-8.13.tar.gz

~]# cd coreutils-8.13/

~]# ./configure --prefix=/usr/share/coreutils-8.13

~]# make && make install

~]# cd /usr/share/coreutils-8.13/bin && ls

(8.13버전을 사용하는 이유는 ftp://ftp.gnu.org/gnu/coreutils/에 접속해보면 알지만 8.13이후 버전부터는 tar.gz 이 아닌 tar.xz 형식으로 배포해서… 64bit OS에서 압축 배포하는건 32bit OS에서는 압축해제하기 어렵다.)

설치후 prefix 폴더의 bin 으로 들어가면 linux에서 기본명령어로 많이 사용하던 명령어들을 볼 수 있다.

base64, basename, cat, chcon, chgrp, chmod, chown, chroot, cksum, comm, cp, csplit, cut, date, dd, df, dir, dircolors, dirname, du, echo, env, expand, expr, factor, false, fmt, fold, groups, head, hostid, id, install, join, kill, link, ln, logname, ls, md5sum, mkdir, mkfifo, mknod, mktemp, mv, nice, nl, nohup, nproc, od, paste, pathchk, pinky, pr, printenv, printf, ptx, pwd, readlink, rm, rmdir, runcon, seq, sha1sum, sha224sum, sha256sum, sha384sum, sha512sum, shred, shuf, sleep, sort, split, stat, stdbuf, stty, sum, sync, tac, tail, tee, test, timeout, touch, tr, true, truncate, tsort, tty, uname, unexpand, uniq, unlink, uptime, users, vdir, wc, who, whoami, yes

필요한게 있다면 /usr/bin 으로 복사해서 사용을 한다 ‘ㅅ’a

timeout 명령어 설명.

~]# timeout 3 curl -f -s –url httpd://xxxxx.com/index.php
와같이 사용함으로서 쉘로 웹이 죽었나 안죽었나 테스트 할때 쓰며 3초안에 반응을 하는 조건을 건다.
curl 의 경우max-time 옵션을 가지고 있다. 때문에 굳이 curl 에서는 쓸일이 없겠다.

php.ini 에서 업로드 파일 사이즈를 지정하는 옵션

post_max_size 는 upload_max_filesize 보다 20% 크게 지정해야 한다.
통신 비트는 일반적으로 8bit 후 2bit의 별도의 패리티비트(오류정정)가 포함된다

upload_max_filesize / post_max_size
.              10M                     12M
.              20M                     24M
.              40M                     48M
.              60M                     72M
.              80M                     96M
.             100M                    120M

post_max_size 사이즈가 만약 100M 를 넘어 간다면 memory_limit(기본값 128M)를 최소 40M 가량 더해 적용한다.
이외에도 업로드 되는 파일의 사이즈가 매우 크다면 네트워크 속도를 고려하여 max_execution_time, max_input_time 을 늘려 PHP 실행시간 제한을 늘려야 한다.

memory_limit, max_execution_time, 는 PHP_INI_ALL 이기 때문에 php함수인 ini_set() 혹은 .htaccess 에서 php_value 로 설정이 가능하다.
post_max_size, upload_max_filesize, max_input_time 의 경우 PHP_INI_PERDIR, PHP_INI_SYSTEM 의 가변성을 가지기 때문에 php함수인 ini_set() 혹은 .htaccess 에서 php_value 로 선언할 수 없다.

각 php.ini 설정값의 가변성 여부는 http://php.net/manual/kr/ini.list.php 에서 확인할 수 있다.