예전에 windows에서 경로의 최대 길이(MAX_PATH)가 너무 작아서 고생을 한적이 한번 있다. 실제로 사용할수 있는 최대 길이는 230자가 조금 넘었던 걸로 기억하는데, 그 한계를 극복할 만한 해결책을 결국은 못 찾아서 결국은 꼼수로 피해가고 말았었는데, 그 한계를 피해 가는 방법을 우연히 발견했다.


여기에서 보다시피 경로명의 시작을 "//?/"로 하면, 즉 "\\?\D:\" 처럼 써주면 win32 api level에서는 32,000자까지 받아 들인다고 한다(중간의 shell이 잘라먹지 않는이상).

출처 : http://reply.tistory.com

시작부터 이야기 하면 이것은 /proc 에 관한 이야기이다

mount -t proc proc /mnt/gentoo/proc 명령은 젠투를 설치한 사람이라면 한번씩은 사용하는 명령어인데

이 proc 라는건 현재 실행중인 리눅스 시스템의 각종 상태를 보여주는 가상 파일시스템이다.
(실제로는 파일이 아니라, 상태를 파일화 해서 보여주는 것이라는 뜻)

상태를 보여준다는 측면도 있지만 실제로 이 상태가 커널의 파라미터로써 현재 동작하고 있는 커널의 설정값으로 이해한다면, 이 값을 변경해서 커널의 동작을 변경함으로써 시스템을 조절할 수 있음 역시 알 수 있을 것이다.

예를들면 /proc/sys/net/ip_forward 의 내용을 1 로 변경하여 ip 프로토콜의 포워딩을 가능하게 설정할 수 있다.
(리눅스로 라우터를 만든다면 반드시 패킷포워드가 설정되어야 하므로 필수적인 셋팅이다)

다만 실제 파일이 아니며, 커널이 특정 작업의 결과를 반영하여 보여주는 것 이므로 에디터로 내용을 바꾸는 것은 그다지 좋은 방법이 아니다.

그래서 리다이렉션등을 사용해서 변경해 주는것이 좋음을 잊지 말자.


이정도가 내가 원문에서 가장 기억에 남는 내용이고
더 자세한 정보와 팁은 아래 원문을 참조하길 바란다.

출처 : ibm

-------------------------------------------------------------------------

실행중인 리눅스 관리하기

/proc 파일시스템은 리눅스의 탁월한 특징 중 하나이다. 이를 통해 머신을 끄고 재부팅 하지 않고 OS의 상세한 부분들을 관리할 수 있다.

상업적으로 매우 중요한 시스템을 관리해 본 사람이라면 업타임(uptime)의 가치를 안다. 역으로 말하면 다운타임(downtime)으로 인해 사용자들로부터 듣게될 원성으로 인한 두통을 알 것이다. 기업이 유닉스 서버를 실행하는 이유 중 하나는 유닉스의 신뢰성과 안정성 때문이다. 주의 깊게 관리된다면 한 동안 재부팅 할 필요 없이 지내게 된다. 게다가 서버를 실행상태로 유지하면서 커널 레벨에서 관리 작업도 수행할 수 있다. 하드웨어를 업그레이드하기 위해 시스템을 재시작 해야 하거나 누군가가 전원 코드를 실수로 뺄 수 있다면 서비스에 피해를 주지 않고 관리작업을 수행하는 것을 알아두는 것이 좋다.

이 글에서는 재부팅 없이 다양한 관리 작업을 수행하고 시스템을 변경할 수 있는 방법이 소개되어 있다. 리눅스는 시스템을 실행 상태로 유지 시킨 채 리눅스 기저의 값과 설정을 변경하는 다양한 방법을 제공한다.

Note: 본 자료는 2.4 레벨 커널 기준이다. 일부 옵션과 기능은 다른 커널 버전과 다를 수 있다.

실행중인 커널 매개변수 변경하기

리눅스는 시스템이 실행중인 동안 커널/시스템을 재부팅 할 필요 없이 관리자들이 커널을 변경할 수 있는 깔끔한 방법을 제공한다. 이는 /proc 이라고 하는 가상 파일시스템으로 수행된다. Linux Gazette는 /proc에 관한한 가장 간단하고 쉬운 레퍼런스를 제공한다. (참고자료) 기본적으로 /proc 파일시스템은 실행 커널을 볼 수 있는 시각을 제공한다. 이는 퍼포먼스를 감시하고 시스템 정보를 발견하며 시스템이 어떻게 설정되었는지를 파악하고 그 설정을 변경할 때 유용하다. 이러한 파일시스템을 가상 파일시스템(virtual filesystem)이라고 한다. 실제 파일시스템이 아니기 때문이다. 이것은 일반적인 파일시스템 구조에 어태치된 커널에 의해 제공되어 이에 액세스 할 수 있게 한다.

시스템이 실행중일 때 실행중인 커널 매개변수를 변경하는 몇 가지 방법이 있다는 사실은 커널 설정 변경에 상당한 힘과 유연성을 시스템 관리자들에게 제공해준다고 볼 수 있다. 이러한 유형의 구현은 일부의 리눅스 커널 개발자들에게 영감을 주는 생각이었다. 하지만 힘도 너무 크면 오히려 나쁠 수도 될 수 있지 않은가? 가끔 그렇다. /proc 파일시스템에 있는 무엇인가를 변경한다면 변경하려는 것이 무엇이고 시스템에 미칠 영향에 대해 반드시 알아야한다. 이들은 실제로 유용한 기술이지만 잘못된 행동은 원치 않는 결과를 가져다 줄 수 있다. 이런 작업이 처음이거나 변경으로 인한 결과를 확신하지 못한다면 중요하지 않는 머신에 연습을 먼저 하기 바란다.

어떻게 변경 할 것인가?

우선 커널에 변경을 가하지 않는 방법을 생각해보자. /proc 파일시스템으로 곧바로 뛰어들어 텍스트 에디터에 있는 파일을 열고 변경을 수행하고 파일을 저장하면 안될 두 가지 중요한 이유가 있다:

• 데이터 무결성: 모든 파일들은 실행 시스템을 나타내고 있고 커널이 언제라도 이들 파일 중 어떤 것이라도 변경할 수 있기 때문에 시스템이 데이터를 실행중일 때 에디터를 열고 데이터를 변경한다면 저장을 한다고 해도 커널이 기대하는 것과 다를 수 있다.
• 가상 파일: 모든 파일들은 실제로 존재하는 것이 아니다. 저장된 데이터가 어떻게 동기화 될 수 있겠는가?

따라서 이러한 파일들을 변경할 때의 답은 에디터를 사용하지 않는 것이다. /proc 파일시스템에 있는 모든 것을 변경할 때 echo 명령어를 사용하고 명령행에서 온 아웃풋을 /proc 밑의 선택된 파일에 리다이렉트 해야한다:

echo "Your-New-Kernel-Value" > /proc/your/file

이와 비슷하게 /proc 에서 정보를 보고싶다면 그 목적에 맞게 설계된 명령어를 사용하거나 cat 명령어를 사용한다.

무엇을 변경 할 것인가?

/proc을 잘 사용하기 위해 커널 해커가 될 필요가 없다. 이 파일시스템의 구조에 대한 기본적인 이해만으로도 충분히 도움이 된다.

/proc에 있는 각각의 파일들은 매우 특별한 파일 권한들을 할당받았고 특별한 사용자 아이디에 의해 소유된다. 이는 매우 신중하게 수행되어 정확한 기능이 관리자와 사용자들에게 보일 수 있도록 한다. 특별한 권한이 개별 파일에 어떤 일을 수행하는지를 다음과 같이 요약했다:

• Read-only: 사용자가 변경할 수 없는 파일: 시스템 정보를 나타내는데 사용됨.
• Root-write: 파일이 /proc에서 쓰기가 가능하다면, 루트(root) 사용자만 쓸 수 있음.
• Root-read: 일반적인 시스템 사용자는 볼 수 없고 루트 사용자만 볼 수 있는 파일.
• Other: 여러가지 이유로 위 세 개의 경우가 섞인 것도 있다.

/proc에 대한 매우 광범위한 일반화는 /proc/sys 디렉토리를 제외하고 대부분 읽기 전용이라는 것을 알게 될 것이다. 이 디렉토리는 대부분의 커널 매개변수를 갖고 있으며 시스템이 실행되는 동안 변경되도록 설계되었다.

Making changes

/proc의 각 파일에 대한 정확한 정보와 사용법을 이 글에서는 다루지 않겠다. 이 글에서 다루어지지 않은 /proc 파일에 대한 자세한 정보의 경우, 최상의 소스는 리눅스 커널 소스 그 자체일 것이다. 매우 훌륭한 문서까지 포함되어 있다. /proc에 있는 다음 파일들은 시스템 관리자들에게 유용하다.

/proc/scsi

시스템 관리자로서 배워두면 가장 유용할 것 중 하나이다. 사용가능한 핫스왑(hot-swap) 드라이브가 있을 때 시스템을 재부팅하지 않고 더 많은 디스크 공간을 추가하는 방법이다. /proc을 사용하지 않고, 드라이브를 삽입할 수 있으나 시스템이 새로운 디스크를 인식하도록 하려면 재부팅해야 한다. 다음과 같은 명령어로 새로운 드라이브를 시스템이 인식하도록 할 수 있다:

echo "scsi add-single-device w x y z" > /proc/scsi/scsi

이 명령어가 올바르게 작동하도록 하려면 매개변수 값인 w, x, y, z를 정확히 해야한다:

• w는 첫 번째 어댑터가 0 인 호스트 어댑터 ID 이다.
• x는 첫 번째 채널이 0 인 호스트 어댑터 상의 SCSI 채널이다.
• y는 디바이스의 SCSI ID 이다.
• z는 첫 번째 LUN이 0 인 LUN 넘버이다.

디스크가 시스템에 추가되면 이전에 포맷된 파일시스템들을 마운트하거나 포맷을 시작할 수 있다. 디스크가 어떤 디바이스가 도리지 불확실하거나 기존에 존재하는 파티션을 점검하고 싶다면 fdisk -l 같은 명령어를 사용하면 된다.

바꿔 말하면 재부팅 필요 없이 시스템에서 디바이스를 제거하는 명령어는 다음과 같다:

echo "scsi remove-single-device w x y z" > /proc/scsi/scsi

이 명령어를 입력하고 시스템에서 핫스왑 SCSI 디스크를 제거하기 전에 디스크에서 파일시스템을 먼저 언마운트한다.

/proc/sys/fs/

/proc/sys/fs/file-max
이것은 할당받을 수 있는 최대 파일 핸들 수를 지정한다. 열린 파일의 최대 수가 다 되었기 때문에 더 이상의 파일을 열 수 없다는 에러 메시지를 사용자가 받는다면 이 값을 늘려야한다. 수는 제한 없이 설정될 수 있고 파일에 새로운 숫자 값을 작성하여 변경할 수 있다.

기본 설정: 4096

/proc/sys/fs/file-nr
이 파일은 file-max와 관련이 있고 세 개의 값을 보유하고 있다:

• 할당받은 파일 핸들의 수
• 사용된 파일 핸들의 수
• 최대 파일 핸들의 수

이 파일은 읽기 전용이며 정보 전달만을 목적으로 한다.

/proc/sys/fs/inode-*
"inode"라는 이름으로 시작하는 모든 파일은 "file"로 시작하는 파일과 같은 작동을 수행하지만, 파일 핸들 대신 inode와 관련된 작동을 수행한다.

/proc/sys/fs/overflowuid & /proc/sys/fs/overflowgid
이것은 16 비트 사용자와 그룹 ID를 지원하는 모든 파일시스템용 User ID (UID)와 Group ID (GID)를 갖고있다. 이 값들은 변경될 수 있지만 원하면 그룹과 패스워드 파일 엔트리를 변경하는 것이 더 쉽다.

기본 설정: 65534

/proc/sys/fs/super-max
이것은 수퍼 블록 핸들러의 최대 수를 지정한다. 마운트 한 모든 파일시스템은 수퍼 블록을 사용하여 많은 파일시스템들을 마운트하더라도 실행 될 수 있도록 할 수 있다.

기본 설정: 256

/proc/sys/fs/super-nr
현재 할당된 수퍼 블록의 수 이다. 이 파일은 읽기 전용이며 정보 전달만을 목적으로 한다.

/proc/sys/kernel

/proc/sys/kernel/acct
프로세스 어카운딩이 로그를 포함하고 있는 파일시스템 상의 빈 공간의 양을 기반을 해서 발생할 경우를 제어하는 세 개의 설정 가능한 값을 갖고있다:

1. 빈 공간이 이 비율 이하가 되면 프로세스 어카운팅은 멈춘다.
2. 빈 공간이 이 비율 이상이 되면 프로세스 어카운딩이 시작된다.
3. 다른 두 개의 값이 검사되는 (초당) 빈도수.

이 파일에서 값을 변경하려면 스페이스로 분리된 숫자 리스트로 echo 해야한다.

기본 설정: 2 4 30

이 값들은 로그를 포함하고 있는 파일시스템의 빈 공간이 2% 미만이라면 어카운팅을 멈춘다. 그리고 빈 공간이 4% 이상 이라면 다시 시작한다. 검사는 30초 마다 이루어진다.

/proc/sys/kernel/ctrl-alt-del
이 파일은 시스템이 ctrl+alt+delete 키 조합을 받을 때 어떻게 반응하는지를 제어하는 바이너리 값을 갖고 있다. 두 개의 값은 다음과 같은 것을 나타낸다:

1. 0 값은 ctrl+alt+delete가 트랩(trap)되어 init 프로그램으로 보내지는 것을 의미한다. 셧다운 명령어를 입력한 것 처럼 시스템이 정지하고 재시작하도록 한다.
2. 1 값은 ctrl+alt+delete 트랩되지 않고 어떤 깨끗한 셧다운도 수행되지 않을 것을 의미한다. 전원을 끈 것과 같은 이치이다.

기본 설정: 0

/proc/sys/kernel/domainname
이를 사용하여 네트워크 도메인 이름을 설정할 수 있다. 기본 값이 없으며 이미 설정되었을 수도 아닐 수도 있다.

/proc/sys/kernel/hostname
기본 값이 없으며 이미 설정되었을 수도 아닐 수도 있다. 네트워크 호스트 이름을 설정할 수 있다.

/proc/sys/kernel/msgmax
이것은 하나의 프로세스에서 다른 프로세스로 보내질 수 있는 최대 메시지 사이즈를 지정한다.

기본 설정: 8192

/proc/sys/kernel/msgmnb
하나의 메시지 큐에서의 최대 바이트 수를 지정한다.

기본 설정: 16384

/proc/sys/kernel/msgmni
최대 메시지 큐 식별자의 수를 지정한다.

기본 설정: 16

/proc/sys/kernel/panic
"커널 패닉"으로 인해 재부팅 되기 전에 커널이 기다려야 할 시간을 나타낸다. 0초 설정은 커널 패닉 시 재부팅 할 수 없다.

기본 설정: 0

/proc/sys/kernel/printk
중요성을 기준으로 해서 로깅 메시지가 전송될 곳을 지정하는 숫자 값을 갖고 있다:

1. Console Log Level: 이 값보다 높은 우선순위를 지닌 메시지들은 콘솔에 프린트된다.
2. Default Message Log Level: 우선순위가 없는 메시지들은 이 우선순위로 프린트된다.
3. Minimum Console Log Level: Console Log Level이 설정될 수 있는 최소(가장 높은 우선순위) 값.
4. Default Console Log Level: Console Log Level 용 기본 값.

기본 설정: 6 4 1 7

/proc/sys/kernel/shmall
주어진 지점의 시스템에서 사용될 수 있는 총 공유 메모리 (바이트) 양.

기본 설정: 2097152

/proc/sys/kernel/shmax
커널에 허용된 최대 공유 메모리 세그먼트 사이즈 (바이트)를 지정한다.

기본 설정: 33554432

/proc/sys/kernel/shmmni
전체 시스템을 위한 최대 공유 메모리 세그먼트의 수.

기본 설정: 4096

/proc/sys/kernel/sysrq
0이 아닐 때 System Request Key를 활성화한다.

기본 설정: 0

/proc/sys/kernel/threads-max
커널에서 사용할 수 있는 최대 쓰레드의 수.

기본 설정: 2048

/proc/sys/net

/proc/sys/net/core/message_burst
새로운 경고 메시지를 작성하는데 필요한 시간 (1/10 초); 이 시간동안 받은 다른 경고 메시지들은 누락된다. 시스템을 메시지로 넘쳐나게 하려는 사람들의 "Denial of Service" 공격을 방지하는데 사용된다.

기본 설정: 50 (5초)

/proc/sys/net/core/message_cost
모든 경고 메시지와 관련된 비용의 값을 보유하고 있다. 값이 높을 수록 경고 메시지가 더욱 무시된다.

기본 설정: 5

/proc/sys/net/core/netdev_max_backlog
인터페이스가 커널이 처리할 수 있는 것보다 빠른 패킷을 받았을 때 큐에 허용된 최대 패킷 수를 제공한다.

기본 설정: 300

/proc/sys/net/core/optmem_max
소켓 당 할당된 최대 버퍼 사이즈를 지정한다.

/proc/sys/net/core/rmem_default
수신 소켓 버퍼의 기본 사이즈(바이트) 이다.

/proc/sys/net/core/rmem_max
수신 소켓 버퍼의 최대 사이즈(바이트) 이다.

/proc/sys/net/core/wmem_default
송신 소켓 버퍼의 기본 사이즈(바이트) 이다.

/proc/sys/net/core/wmem_max
송신 소켓 버퍼의 최대 사이즈(바이트) 이다.

/proc/sys/net/ipv4
모든 IPv4와 IPv6 매개변수는 커널 소스 문서에 모두 문서화되었다. /usr/src/linux/Documentation/networking/ip-sysctl.txt 파일을 참조하기 바란다.

/proc/sys/net/ipv6
IPv4와 같다.

/proc/sys/vm

/proc/sys/vm/buffermem
버퍼 메모리에 사용될 총 시스템 메모리(퍼센트) 양을 제어한다. 파일에 공간 분리 리스트를 작성하여 설정될 수 있는 세 개의 값을 갖고 있다:

1. 버퍼에 사용될 최소 메모리 비율.
2. 남아있는 시스템 메모리가 적을 경우 시스템 메모리가 없어질 때 시스템은 이 정도의 버퍼 메모리를 유지하려고 한다.
3. 버퍼에 사용될 최대 메모리 비율.

기본 설정: 2 10 60

/proc/sys/vm/freepages
시스템이 다른 레벨의 빈 메모리에 어떻게 반응할 것인지를 제어한다. 공간 분리 리스트를 파일에 작성하여 설정할 수 있는 세 개의 값이 있다:

1. 시스템에서 비어있는 페이지의 수가 최소 한계에 다다랐다면 커널에만 더 많은 메모리를 할당하도록 허용된다.
2. 시스템에서 비어있는 페이지의 수가 이 한계 밑으로 떨어지면 커널은 공격적으로 빈 메모리로 스와핑을 시작하며 시스템 퍼포먼스를 유지한다.
3. 커널은 이 정도의 시스템 메모리를 빈 상태로 유지할 것이다. 이 밑으로 떨어지면 커널 스와핑이 시작된다.

기본 설정: 512 768 1024

/proc/sys/vm/kswapd
커널이 메모리를 스와핑하도록 어떻게 허용할 지를 제어한다. 공간 분리 리스트를 파일에 작성하여 설정할 수 있는 세 개의 값이 있다:

1. 커널이 한번에 빈 공간으로 둘 최대 페이지의 수. 스왑으로 대역폭을 늘리려면 이 숫자를 늘린다.
2. 각 스왑에 대해 커널이 페이지를 빈 곳으로 유지하는 최대 시간.
3. 한 스왑에서 커널이 작성할 수 있는 페이지의 수. 이것은 시스템 퍼포먼스에 가장 큰 영향을 미친다. 값이 클수록 스와핑 될 데이터는 많아지고 디스크 검색에 사용되는 시간은 줄어든다. 하지만 값이 너무 크면 시스템 퍼포먼스에 역효과를 가져온다.

기본 설정: 512 32 8

/proc/sys/vm/pagecache
/proc/sys/vm/buffermem과 같은 작업을 수행하지만 메모리 매핑과 일반적인 파일 캐싱을 위해 작동한다.

위로

영속적인 커널 설정

/proc/sys 디렉토리에는 어떤 커널 매개변수라도 변경할 수 있도록 편리한 유틸리티가 있다. 이를 사용하여 실행 커널을 변경할 수 있지만 시스템 부트에서 실행되는 설정 파일 또한 있다. 이것은 실행 커널을 변경하고 그들을 설정 파일에 추가시켜 시스템 재부팅 후에도 어떤 변경이라도 남아있게 된다.

이 유틸리티는 sysctl 이라고 하며 sysctl(8)의 맨페이지에 모두 문서화 되어 있다. sysctl용 설정 파일은 /etc/sysctl.conf이며 편집 될 수 있다. sysctl.conf(8)에 문서화되어 있다. Sysctl은 /proc/sys 밑에 있는 파일들을 변경될 수 있는 개별 변수들로 취급한다. 따라서, 예를 들어, 시스템에 허용된 최대 파일 핸들의 수를 나타내는 /proc/sys 밑의 파일인 /proc/sys/fs/file-max는 fs.file-max로 나타난다.

이 예제는 sysctl 표기에서 몇 가지 이상한 점을 드러낸다. sysctl은 can only change variables under the /proc/sys 디렉토리 밑에 있는 변수들을 변경할 수 있기 때문에 변수 이름의 일부는 이 디렉토리 밑에 있는 것으로 가정되는 변수로서 무시된다. 디렉토리 분리자(슬래시, /)는 마침표(.)로 변경되었다.

/proc/sys 에 있는 파일들과 sysctl의 변수들 간 변환에 적용되는 두 개의 간단한 규칙이 있다:

• 시작부터 /proc/sys를 누락한다.
• 파일이름에서 슬래시를 마침표로 바꾼다.

이 두 개의 규칙으로 /proc/sys에 있는 모든 파일 이름을 sysctl의 모든 변수 이름으로 바꿀 수 있다. 변수 변환에 대한 일반적인 파일은 다음과 같다:

/proc/sys/dir/file --> dir.file
dir1.dir2.file --> /proc/sys/dir1/dir2/file

변경될 수 있는 모든 변수들을 볼수 있고 이에 더하여 sysctl -a 명령어를 사용하여 그들의 현재 설정을 볼 수 있다.

sysctl를 사용하여 변수들이 변경될 수 있는데 이는 위에 사용된 echo 메소드와 같은 작업을 수행한다:

sysctl -w dir.file="value"

file-max 예제를 다시 사용하여, 다음과 같이 두 개의 메소드 중 하나를 사용하여 이 값을 16384로 변경할 수 있다:

sysctl -w fs.file-max="16384"

또는:

echo "16384" > /proc/sys/fs/file-max

sysctl은 설정 파일을 변경하지 않음을 기억하라. 수동으로 하도록 남겨두었다. 재부팅 후에도 변경을 영속성있게 유지하려면 이 파일을 유지하라.

Note: 모든 배포판이 sysctl을 지원하는 것은 아니다. 이는 특정 시스템의 경우이며, 시스템 부팅 시 실행되도록 하려면 위에 설명된 에코와 리다이렉트 메소드를 사용하여 시작 스크립트에 이 명령어를 추가한다.

위로

시스템 설정을 위한 명령어

시스템이 실행되는 동안 다른 비커널 시스템 매개변수를 변경하고 또한 재부팅 필요 없이 설정을 발효시킬 수 있다. 이들은 주로 서비스, 데몬, 서버로 분류되며 /etc/init.d 디렉토리에 있다. 이 디렉토리에 리스팅될 수 있는 스크립트가 점점 광범위해지기 때문에 여기에서 모든 다양한 설정을 다루기엔 불가능하다. 아래 몇 가지의 예제는 /etc/init.d 스크립트가 다양한 리눅스 배포판에서 어떻게 조작될 수 있는지를 설명하고 있다. 재부팅 필요 없이 설정 데몬과 리로드를 변경하는 것은 유용한 예제이다:

• 웹 서버 설정 변경과 Apache 리로딩
• 원하지 않는 inetd 로그인 서비스 제거
• 네트워크 설정 조작
• NFS를 통한 새로운 파일시스템 반출
• 방화벽 시작/중지

우선, 시스템 서비스를 조직하는 일반적인 방법은 직접 /etc/init.d에 있는 스크립트를 통해서이다. 이 스크립트들은 매개변수를 취하여 그들이 제어할 서비스를 조작한다. 유효한 작동이 무엇인지 보기위해 매개변수 없이 스크립트 이름을 입력할 수 있다. 일반적인 매개변수들은 다음과 같다:

• start: 중지된 서비스 시작
• stop: 실행되는 서비스 중지
• restart: 멈춘 후 실행 서비스 시작. 또는 중지된 서비스 시작
• reload: 연결을 끊지 않은 채 서비스 설정 리로드
• status: 서비스의 실행 여부를 나타내는 아웃풋

예를 들어 다음의 명령어는 연결된 사용자 세션을 종료하지 않고 xinetd 설정을 리로드 한다:

/etc/init.d/xinetd reload

Red Hat은 service 명령어를 제공하는데 이는 서비스를 조작한다. service 명령어는 스크립트 이름을 타이핑할 때와 같은 기능을 제공한다. 신택스는 다음과 같다:

service script-name [parameter]

예를 들어:

service xinetd reload

SuSE 역시 rc 라는 명령어를 제공한다. 이는 서비스 명령어와 비슷하다. 하지만 명령어와 스크립트 이름 사이에 공간이 없다:

rc{script-name} parameter

예:

rcapache start

위로

참고자료

• developerWorks worldwide 사이트에서 이 기사에 관한 영어원문.
  
  
• Download.
  
  
• /proc virtual filesystem : Linux Gazette.
  
  
• sysctl(8) & sysctl.conf(8) 맨페이지.
  
  
• Linux Documentation Project 홈페이지.
  
  
• "Linux hardware stability guide, Part 1" (developerWorks, 2001년 3월) & "Linux hardware stability guide, Part 2" (developerWorks, 2001년 7월).
  
  
• "Understanding Linux configuration files" (developerWorks, 2001년 12월).
  
  
• "Configuring and compiling the kernel" (developerWorks, 2002년 5월).
  
  
• "Linux on IBM zSeries and S/390: High Availability for z/VM and Linux."
  
  
• developerWorks Linux zone.
  

위로

출처 : http://www-128.ibm.com/developerworks/kr/library/l-adfly.html

2월28일에 모든 system 패키지를 모두 설치하여 Stage2 로 진입했었다.
이날 Stage2를 백업한 다음, 네트워크 관리도구와 기타 유틸리티, 설정을 잡고 커널다운로드까지 마쳤다

3월1일 어제 커널 컴파일과 삼바, sshd, iptables 설정을 마쳤다.
커널컴파일은 프레임버퍼를 분명 넣었는데도 인식하지 못하고 현재 일반모드로 동작하고 있다.
나머지 모든 셋팅은 성공적이다.

iptables 셋팅을 백업해 둔 것이 너무나 기쁘고 감사했다.

여기에 stage3까지 잡은 셋팅 내역을 잠시 적어둔다

1. ntp-client
2. ntop
3. samba
4. syslog-ng
5. iptables

이 정도이고 /etc/make.profile 은 2006.1의 server 프로필을 가리키도록 했다.


여튼 현재는 데이터 복원중.

지금까지 했던 서버 구축작업 중 (젠투로만!) 가장 빨리 끝났다 ^-^


하나님 감사합니다 (_ _)

시스템 이미지 백업본을 믿고 있던 나는, 데이터 파티션을 마운트 해 놓은것을 깜빡 하고

rm -rf / 

.......하는 만행을 저질렀다.. (터얼써억) oTL


뭐 어쩔 수 없지 재설치 하지 뭐. 하고 툭툭 털고 일어났던 것도 잠시.

분명 2006.1 의 stage1 타르볼인데. /usr/portage/scripts/bootstrap.sh 하는 중 다음과 같은 에러를 내며 뻗어버렸다!!

an't locate ExtUtils/MakeMaker/Config.pm in @INC (@INC contains: /etc/perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux /usr/lib64/perl5/vendor_perl/5.8.8 /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux /usr/lib64/perl5/site_perl/5.8.8 /usr/lib64/perl5/site_perl /usr/lib64/perl5/5.8.8/x86_64-linux /usr/lib64/perl5/5.8.8 /usr/local/lib/site_perl .) at /usr/lib64/perl5/5.8.8/ExtUtils/MakeMaker.pm line 7.
BEGIN failed--compilation aborted at /usr/lib64/perl5/5.8.8/ExtUtils/MakeMaker.pm line 7.
Compilation failed in require at Makefile.PL line 11.
BEGIN failed--compilation aborted at Makefile.PL line 11.

!!! ERROR: perl-core/Test-Simple-0.64 failed.
Call stack:
ebuild.sh, line 1546: Called dyn_compile
ebuild.sh, line 937: Called src_compile
ebuild.sh, line 1255: Called perl-module_src_compile
perl-module.eclass, line 136: Called perl-module_src_prep
perl-module.eclass, line 125: Called die

!!! Unable to build! (are you using USE="build"?)
!!! If you need support, post the topmost build error, and the call stack if relevant.

정확하게 말하면 서버를 깨먹었다기 보다도, 하드웨어 이주에 실패했다는 표현이 더 정확하겠다.

내가 패키지 설치에 실패했거나, 설정 오류나 명령어 실패로 OS 를 날린건 아니니까..
(한편으로는 그렇기도 하다 ;ㅅ; )


원래 내 개인 서버는 Pentium 3 Coopermine 에서 돌던 녀석이다 보드는 i815 고 부두 그래픽 카드에 Realtek NIC가 탑재된 녀석.

그런데 문제는 보드의 USB가 인식되지 않아 프린터 설치가 불가능했다.

/dev/lp0 로 (일반 패러렐) 어떻게든 해 보려고 했지만 USB 인터페이스가 아니면 드라이버는 소용이 없을 것이란 구글 형님의 훈수가 결국 Duron 850 으로의 이주를 결정하게 했다.

문제는 여기서 발생했다.

/etc/make.conf 에서 CFLAGS 를 march=pentium3 로 -fomit-frame-pointer 루프 어레이인가를 4까지 최적화 하고 -O3 로 설정했었다.

설마 했는데 CPU가 Duron (AMD)로 바뀌었다고 부팅이 안되는 것이다.

결국 커널 중 2.6.18 대를 버리고 2.6.14 로 부팅하니 어떻게든 부팅은 되었다.

문제는 ntop 이나 gcc, python 이 동작하질 않았고 당연하게도 portage 마저 동작하지 않았다.

(illegal instuction 에러를 냄)

소프트웨어를 하드웨어에 꼭 맞게 최적화 하는것이 양날의 검이라는 사실을 이때서야 깨달았다.
나중에 하드웨어를 새로 구성할 것을 고려하지 않았고 좋지 않은 사양이기에 최적화를 위해 한 일이 이렇게 발목을 잡을줄은 생각하지 못했다.


결국 Gentoo LiveCD 로 부팅해서 system 패키지와 glibc 를 재 컴파일/설치 하기로 방향을 잡았다.

그.러.나





chroot로 진입한 환경에서 아까 동작하지도 않던 gcc 가 동작할 리 없지 않은가.. [털썩]


이럴때는  gcc만 새로 설치해서 작업하면 좋은데,  얽히고 섥힌 라이브러리의 의존성과 해당 파일의 목록을 외워둔 것도 아니고.


프로그램 목록(파일목록) 은 그렇다 치더라도, 그것을 배치해야 할 디렉토리 위치조차 모른다는게 결정적이다.

젠투 리눅스 개발자들과 LFS로 수많은 삽질에 삽질을 거듭하시는 분들은 잘 아시겠지만.


결국 gcc를 사용하기 위해 stage1 타르볼을 덮어 써 보았다.
무슨일이 일어날지 궁금하기도 했고, 어차피 시스템 전체 백업은 되어 있으니 망가뜨리면서 공부해 보는것도 나쁜일은 아니라고 생각했다.


그 결과, 당연하게도 gcc 기동은 성공. 하지만 하나라도 emerge 시도를 하면  glibc 와 호환이 안되는 건지 /lib 디렉토리의 pthread 동적 라이브러리에서 에러를 뿜어냈다.

그 이후에는 어떤 프로그램을 실행해도, 심지어 ls 따위를 실행해도 동일한 반응.

하는 수 없이 타르볼을 다시 덮어쓰고 glibc 를 재 컴파일 했다.

이후 bootstrap 시 perl 모듈 중  (dev-perl/Locale-gettext-1.05)

* Using ExtUtils::MakeMaker
Can't locate ExtUtils/MakeMaker/Config.pm in @INC (@INC contains: /etc/perl /usr/lib/perl5/vendor_perl/5.8.8/i686-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl/5.8.8/i686-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/5.8.8/i686-linux-thread-multi /usr/lib/perl5/5.8.8 /usr/local/lib/site_perl .) at /usr/lib/perl5/5.8.8/ExtUtils/MakeMaker.pm line 7.
BEGIN failed--compilation aborted at /usr/lib/perl5/5.8.8/ExtUtils/MakeMaker.pm line 7.
Compilation failed in require at Makefile.PL line 2.
BEGIN failed--compilation aborted at Makefile.PL line 2.

!!! ERROR: dev-perl/extutils-pkgconfig-1.07 failed.
Call stack:
ebuild.sh, line 1568: Called dyn_compile
ebuild.sh, line 937: Called src_compile
ebuild.sh, line 1261: Called perl-module_src_compile
perl-module.eclass, line 136: Called perl-module_src_prep
perl-module.eclass, line 125: Called die

!!! Unable to build! (are you using USE="build"?)
!!! If you need support, post the topmost build error, and the call stack if relevan

이런 오류가 나는데 일단 관련 링크 첨부

http://www.gentoo.ro/forum_viewtopic.php?19.8292


하아.. 루마니아 어다.. ㅠ ㅠ

이후 하드디스크를 초기화 하고 재 셋팅에 들어갔지만, 역시 bootstrap 시 오류 발생..

대체 뭐란 말인가..

일단 오늘의 삽질 일기는 여기까지..

나머지는 내일 불타오르도록 하자!!

이미 많은 분들이 성공하셨고, 지금도 그 성능을 만끽하고 계신 그것!

미국 IT업계의 떠오르는 큰형님 "구글" 과 이곳 저곳에서 화제가 되고 있는 "오픈소스" 그들이 힘을 합쳤다!

이름하야 MacFUSE 와 ntfs-3g 를 여러분들께 소개합니다!!

MacFUSE 는 http://code.google.com/p/macfuse/ 에서
ntfs-3g 는 http://files.lifehack.org/download/macfuse/NTFS-3G%2020070116-r3.dmg 에서 다운로드 할 수 있습니다.

MacFUSE 먼저 설치하시고 ntfs-3g 를 후에 설치합니다. 그럼 끝.  That's all. >_<


----------------------------
혹시 설치가 안돼신다고요?!


ntfs-3g 설치시 macfuse_required 메세지와 함께 설치 안될 때가 있습니다.
그럴경우 ntfs-3g.pkg 디렉토리(패키지 내용보기) 의  Info.plist 에서 다음 구문을 삭제해 주세요

<key>IFRequirementDicts</key>
<array>
<dict>
<key>Level</key>
<string>requires</string>
<key>MessageKey</key>
<string>macfuse_required</string>
<key>SpecArgument</key>
<string>/Library/Receipts/MacFUSE.pkg</string>
<key>SpecType</key>
<string>file</string>
<key>TestObject</key>
<true/>
<key>TestOperator</key>
<string>eq</string>
<key>TitleKey</key>
<string>macfuse_package</string>
</dict>
</array>

이 전체를 삭제합니다.

아마 MacFUSE를 설치하면 MacFUSE.pkg 가 /Library/Receipts 로 복사되어야 하는데 그렇지 않기 때문에 저 요구사항 설정값에 위배되어 설치가 안되는 듯 합니다. ^-^

-----------------------------

더 자세한 이야기

FUSE 란?

Filesystem in USErspace 의 약자입니다. 각종 파일시스템을 Userspace 의 프로그램으로 사용할 수 있게 하는 라이브러리로 보입니다.


위 그림처럼 커널단에 모듈(또는 커널의 일부)로 존재해서 Userspace 의 특정 처리를 파일 시스템화 하는 것입니다

원래는 linux를 위한 이것을  Mac OS X 에 포팅한 것이 MacFUSE 이고요

이것을 응용하여  Spotlight FS 나 sshFS  같은 것을 구현할 수 있다고 합니다.

위의 MacFUSE 다운로드 사이트에 가시면 자세한 비디오 시연을 보실 수 있고 완성된 SpotlightFS를 다운로드 하실 수 있습니다.

속도는 생각보다 좋지 않습니다. 8기가 분량의 데이터를 외장 USB2.0 하드디스크에 복사할 때 약 9~10시간 정도 걸리더군요 (30기가 분량의 원격 데이터와 같이 복사했는데 그것은 예상시간이 37시간 찍혀서 나오더군요. 30기가 단독복사 예상시간은 약 34시간.)

그래도 쓸 수 있다는게 어딥니까!! ;ㅅ;


그럼 ext2 는?!

ext2 파일 시스템을 MacFUSE를 이용하여 읽는 녀석은 아직 없고, 이미 이전에 출시된 다른 패키지가 있습니다.

http://sourceforge.net/projects/ext2fsx/ 이녀석인데요.

자세한 사용법은 동봉된 README.rtf 를 참조하시면 되겠습니다 ^-^




새해 복 많이 받으시고 올 해는 각자 계획하셨던 일들 다 이루는 한해가 되시기를 ^-^

계획대로라면 오늘 데이터백업과, ERD작업 그리고 적절하게 JSP연습을 했어야 했다.

하지만 외장하드디스크 파티셔닝이 생각보다 잘 되지 않았다.

기존의 파티셔닝은 하드디스크의 50%도 활용하지 않게 해 두고 데이터의 종류에 맞게 3개로 분할해 두었었다.

문제는 그 용량이 거의 다 차버렸기 때문에, 파티셔닝을 동적으로 늘릴 방법이 필요했다.


맥에서는 iPartition, 리눅스에서는 GParted, 그리고 지금 당장 윈도우가 없기 때문에 사용할 수 없는 파티션매직.


iPartition은 인식은 성공, 파티셔닝 불가
GParted 는 라이브시디가 있다는 걸 모르고 있었다.

결국 디스크 유틸리티로 파티션을 전부 지우고 파티셔닝을 통짜로 하기로 마음먹었다.

여기서 문제가 발생했다. -_-


파티션을 지우는것까지는 좋았다. 하지만 파티션을 새로 입히는것이 안된다.

결국 터미널에서 fdisk 로 파티션을 잡았다.
MacOS가 유닉스 기반이라는 점이 뿌듯한 순간이었다. 

리눅스용 fdisk 는 시작 실린더를 입력 후 용량을 입력하면 자동으로 실린더 번호를 잡아주는데 MacOS의 fdisk 는 첫 실린더 번호를 입력 후 "블록수" 를 입력해야 했다.


어쨌든 이렇게 파티셔닝은 성공했으나, MacOS 에서는 파일시스템을 HFS+ 로도 HFS로도, UFS 로도 절대 입힐 수 없었다.

결국 Gparted 라이브시디와  PE를 동원하고  ext2 까지 입혀본 결과 가장 사용할 만한 파일시스템은 NTFS  였고, MacFUSE 와 ntfs-3g 를 설치한 후 서버 데이터를 복사하기 시작했다.

여기까지 성공인듯 했다. 완료 예상시간이 37시간 뜬것을 빼면.


결국 PE로 부팅, 네트워크 셋업 후 직접 USB 하드를 연결해서, 서버의 데이터를 복사중이다.


여튼 성공했다.
그렇지만 이런 삽질들이 너무 비 생산적인 일이 아닌가 싶어 씁쓸하다..

적용범위: ntpupdate 또는 rdate 가 설치되어 있는 모든 운영체제

ntpupdate -u time.nuri.net 또는 rdate -p -s timeservername

-u 스위치는 방화벽으로 시간동기화 포트가 막혀있을 때 사용한다.

아래는  시간서버 목록이다.

**** Time Servername
time.kriss.re.kr
time.bora.net
time.nuri.net
www.hanyang.ac.kr
www.hongik.ac.kr
www.korea.ac.kr
www.skku.ac.kr
www.snu.ac.kr 



----------------------------------------

위의 것은 운영체제에서의 시각만 맞출 뿐 하드웨어 시각에는 적용되지 않는다.
다음 명령을 통해 BIOS의 시각을 맞춰주자.

hwclock --systohc

그냥 hwclock 를 하면 현재 BIOS가 갖고 있는 시각을 출력하고, 올바른 시간과의 차이를 출력한다.

---------------------------------------

One more thing

아래는 coffeenix 의 좋은진호 님께서 체계적으로 정리하신 글.
출처 : http://www.coffeenix.net/board_view.php?cata_code=0&bd_code=19&bpage=&bd_search_type=all&bd_search=%BD%C3%B0%A3%20%B5%BF%B1%E2%C8%AD


전에는 rdate time.nuri.net 또는 ntpdate -b time.kriss.re.kr
로 동기화만 했는데, 좀더 체계적으로(?) 정리할 필요가 있어서 적어봤다.

1. 우리나라의 NTP(Network Time Protocol) 서버

 1) Stratum 1 서버 :
    GPS 위성으로 부터 표준시각정보를 받는 타임 서버를
    NTP Primary Time Server 혹은 Stratum 1(one) 라고 부름

    데이콤 (gps.bora.net), 코넷 (ntp.kornet.net), GNGIDC,
    부산대학교 (ntp1.cs.pusan.ac.kr / ntp2.cs.pusan.ac.kr),
    한국 표준과학 연구원 시간 · 주파수 연구실 (time.kriss.re.kr)

 2) Stratum 2 서버 :
    Stratum 1 서버로 부터 표준시간을 받는 타임서버를
    TP Secondary Time Server 혹은 Stratum 2 서버라고 부름

    PSINet Korea (time.nuri.net),
    GNGIDC (ntp1.gngidc.net / ntp2.gngidc.net),
    이대부속 초등학교 (ntp.ewha.net / ticktock.ewha.net)


2. rdate를 이용한 시간 동기화

 지정한 타임서버로 부터 시간을 확인하거나 동기화 시킨다.

 1) 타임서버의 표준시간을 확인한다.

    rdate time.nuri.net
    rdate: [time.nuri.net]  Tue Mar 18 16:38:47 2003

 2) 시스템 시간을 타임서버 시간에 동기화 시킨다.

    rdate -s time.nuri.net

3. ntpdate를 이용한 시간 동기화

 1) 동기화

     ntpdate -b -s time.kriss.re.kr

    -s : 결과를 화면이 아닌 syslog로 보냄

 2) 다음과 같은 오류가 발생한 경우

[root@truefeel root]# ntpdate -b time.kriss.re.kr  17 Mar 21:03:25 ntpdate[8244]: no server suitable for synchronization found

 ->  NTP 프로토콜은 UDP port 123 을 사용하는데, 이 포트가 방화벽 등으로
      막혀있는 경우에는

      ntpdate -u time.kriss.re.kr

      처럼 -u 를 옵션을 사용해서 다른 포트 사용하도록 한다.

 3) 사용 예

[root@truefeel root]# date  월  3월 17 21:40:35 KST 2003  [root@truefeel root]# date 03172150 <- 강제로 시간을 3.17일 21:50 으로 변경함  월  3월 17 21:50:00 KST 2003  [root@truefeel root]#  [root@truefeel root]# ntpdate -u time.nuri.net <- 시간을 동기화 함  17 Mar 21:40:44 ntpdate[8835]: step time server 203.255.112.96 offset -557.336058 sec  [root@truefeel root]#  [root@truefeel root]# date  월  3월 17 21:40:46 KST 2003  <- 시간이 동기화 됨

 위에서 'offset -557.336058 sec'은 타임서버의 시간(reference time)과 로컬 서버와의
 시간 차이를 나타냄

 4) ntpdate의 2가지 시스템 콜

 ntpdate는 settimeofday(), adjtime()의  2가지 시스템 콜로 시간을 설정한다.
 settimeofday()은 timezone과 시간을 설정하고,
 adjtime()은 점근적 시각 보정 방식으로 커널 클럭을 조정한다. 주로 시간 동기화에 사용한다.

 ntpdate는 옵션(-b, -B)을 지정하지 않으면 현재 시스템 시간과 차이가 128ms 이상이면
 settimeofday()을, 이내이면 adjtime()을 사용한다.
 또한 강제적으로 ntpdate -b 로 settimeofday()를, ntpdate -B로 adjtime()를 사용할 수 있다.

 ntpdate 실행 결과 메시지에 'step time server...'로 표시되면 setimeofday()가 사용되었고,
 'adjust time server...' 로 표시되면 adjtime()가 사용되었다.

[root@truefeel root]# ntpdate time.nuri.net  14 Mar 01:09:31 ntpdate[3127]: step time server 203.255.112.96 offset 82.763348 sec  [root@truefeel root]# ntpdate time.nuri.net  14 Mar 01:22:30 ntpdate[3182]: adjust time server 203.255.112.96 offset -0.064531 sec

 부팅할 때는 ntpdate -b 로, cron등으로 정기적으로 시간조절을 할 때는 옵션없이 ntpdate
 사용하기를 하기 바란다.

 5) 디버깅 모드

    - 디버깅 모드는 local 서버의 시간을 변경하지는 않는다.

[root@truefeel root]# ntpdate -d time.nuri.net 18 Mar 17:33:23 ntpdate[2169]: ntpdate 4.1.1a@1.791 Sat Aug 31 18:27:31 EDT 2002 (1) transmit(203.255.112.96) receive(203.255.112.96) transmit(203.255.112.96) receive(203.255.112.96) transmit(203.255.112.96) receive(203.255.112.96) transmit(203.255.112.96) receive(203.255.112.96) transmit(203.255.112.96) server 203.255.112.96, port 123 stratum 2, precision -18, leap 00, trust 000 refid [192.6.38.127], delay 0.04927, dispersion 0.00092 transmitted 4, in filter 4 reference time:    c2215828.4ea9e000  Tue, Mar 18 2003 17:32:40.307 originate timestamp: c2215853.6ad1b000  Tue, Mar 18 2003 17:33:23.417 transmit timestamp:  c2215853.a19695d9  Tue, Mar 18 2003 17:33:23.631 filter delay:  0.05023  0.05008  0.04927  0.06329         0.00000  0.00000  0.00000  0.00000 filter offset: -0.22637 -0.22621 -0.22640 -0.23302         0.000000 0.000000 0.000000 0.000000 delay 0.04927, dispersion 0.00092 offset -0.226409 18 Mar 17:33:23 ntpdate[2169]: adjust time server 203.255.112.96 offset -0.226409 sec

4. 주의 사항

 1) time.kriss.re.kr 서버는 1초내에 여러번 접속을 시도할 경우 해당 IP를 차단 시키므로
    테스트를 하더라도, 시간 간격을 두고 하도록


-------------------------------


제가 쓴 글 내용의 지적/퍼온 글에 대한 문제제기는 답글로 해주세요.
만일 문제가 된다면 자삭 예정입니다.
마지막으로 체계적으로 정리하여 공개해 주신 좋은진호님께 감사드립니다 ~_~