카테고리 Archives: linux

yum에 대해서…

CentOS 및 redhat 계열을 쓰면서 안써본사람은 없은 yum
기본적으로 yum은 배포 패키지를 설치하는 명령어 이다 ‘ㅅ’a

/etc/yum.repos.d/ 폴더에 위치하는 레포지트리에 입려된 주소를 참조하여
패키지를 검색하고 검색된 패키지를 설계도에 맞게 설치하는 역할을 한다.

그럼 레포지트리는 무엇이냐 ‘ㅅ’a
A레포지트리에서 ccc 라는 패키지를 설치 할때 서버에 설치되는 위치와
B레포지트리에서 ccc 라는 패키지를 설치할때의 위치가 틀리다.

각 레포지트리에 따라서 설치되는 패키지의 버전역시 틀려진다.
A 레포지트리에서는 버전 1.0.0 을 /usr/share/ 폴더에 설치 하지만
B 레포지트리에서는 버전 2.0.0 을 /usr/include/ 폴더에 설치 할 수 있다.

즉 레포지트리라는 것은 설계도면을 배포하는 곳 정도로 인식을 하면 비교적 정확하다고 생각된다.

 

구글신은 많은것을 알려주지만 각각의 엔지니어 특성에 따라 주로 쓰는 레포지트리는 틀릴 수 있다.
때문에 하나의 메뉴얼을 따라 하다가 안된다고 다른 메뉴얼을 따라하다가는 시스템이 엉망으로 꼬일 수 도 있다.
( 물론 두 메뉴얼이 같은 레포지트리를 이용한 메뉴얼이라면 좀 덜꼬이겠다.. )

 

yum 은 아래와 같은 사용방법으로 일반적인 사용을 한다.

 

또한 설치된 패키지의 새 설계도면에 따른 업데이트도 할수 있다.

 

또는 아래 명령어로 모든 설치패키지를 업데이트 할수도 있다 ( 심지어 커널업데이트 까지 )

 

그리고 뭔가 설치해야할 명령어(ex ftpwho)가 있다면 아래와 같은 방법으로 명령어를 포함하는 패키지를 검색을 할수도 있다.

 

최종적으로 귀찬이즘이 극에 달한 엔지니어는 yum 업데이트를 주기적으로 하는게 싫어서
아래와 같은 방법으로 자동 업데이트 데몬을 운영할수도 있다. ( 이건 아직 나도 안해봤음… )

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

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

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

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

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

 

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

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

리눅스 하드디스크 UUID 변경

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

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

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

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

 

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

 

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

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

 

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

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

 

 

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

 

Centos 5 – coreutils 최신 버전 설치.

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

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

(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 에서 확인할 수 있다.