421

(1개의 댓글, PunBB 맛보기 글에 작성됨)

Attachment Mod test

422

(0개의 댓글, Mac OS 글에 작성됨)

sudo (superuser do) 명령은 OS X unix 기저에 깔려있는 매우 유용하고 강력한 기능입니다. 이것은 특정 사용자들에게 root에서 실행될 수 있는 몇몇 혹은 모든 명령들을 실행할 수 있게 하는 동시에, 여기서 실행되는 모든 명령들은 따로 기록되어지게 됨으로, 관리 차원의 참고 자료가 될 수 있는, 누가 어떤 명령을 실행했는지의 명확한 일지를 담은 기록을 제공합니다.

기본적으로 OS X에서는 시스템 관리자만이 sudo 명령을 사용할 수 있지만, sudoers 파일을 약간 수정만 하면, 특정 컴퓨터와 사용자들에게 몇몇 혹은 전체의 sudo  명령들에 접근해서 사용할 수 있도록 만들 수 있답니다.

이런, 강력한 기능을 특정 사용자들에게도 나줘주기 위해서 sudoers 파일을 수정하기 전에, 먼저 다음과 같은 명령으로 원본 파일을 따로 보관해 놓으실 것을 강조하는 바입니다:

sudo cp /etc/sudoers /etc/sudoers.bak

sudores 파일을 수정하는데는 visudo를 씁니다. 이름에서도 알 수 있듯이, 이것은 vi 편집기를 사용하는데, 파일의 동시 다중 편집을 제한하는 잠금 기능과 문법 오류 검사 기능도 같이 제공합니다.

visudo의 설명서를 살펴보면 자세한 사용법이 나와 있는데, 여러 선택자들 중에서, 우리가 사용할 항목은 -c-f 선택자들입니다. visudo -c 명령은 오로지 검사 목적으로만 실행되며, 다음과 같이 사용됩니다:

$ sudo visudo -c
/private/etc/sudoers file parsed OK

-f 선택자는 다른 sudoers 파일의 위치를 지정하는데 사용되며, 시스템에서 사용되는 실제 파일은 놔두고 다른 수정 목적의 파일을 따로 열어서 편집할 경우에 사용될 수 있습니다:

$ sudo visudo -f /etc/sudoers.working

우선, 수정을 시작하기 전에 이미 존재하는 sudoers 파일을 열어서 찬찬히 살펴보시길 바라고, 다음에는 아래에 설명되어 있는 변수들이 어떤 식으로 사용되었는지를 참고해서, 파일을 수정하는데 있을지도 모를 어떠한 오해나 오류를 미연에 방지하시기 바랍니다.

아래에 설명될 내용은, 아주 간단하 예로, 특정 사용자에게 암호를 입력할 필요없이 몇몇 mail 명령들을 실행할 수 있는 sudo 명령을 사용할 수 있도록 sudoers 파일을 수정하는 법을 보여드립니다.

사용자 집단 정의하기
여기에는 user, 혹은 system/LDAP 집단이 포함될 수 있습니다 (사용자 이름 앞의 %는 집단을 나타냄):

User_Alias    <name> =  < %LDAP GROUP> and/or < %SYSTEM GROUP > and/or < USER >

사용 예:

User_Alias     ADMIN =  %admin, %root, andrina

Runas_Alias는 명령이 실행되어질 daemon 혹은 user를 정의하는 것으로, 이것은 group 혹은 특정 user가 될 수 있습니다:

Runas_Alias    <name> = < %GROUP>

사용 예:

MAILERS = %mailman, %postfix, cyrus

machine 집단 정의하기
이것은 호스트(hosts)의 집단을 정의하는 것으로, 이름, IP 그리고 특정 형태와 일치하는 형식을 포함하고 있습니다:

Host_Alias    <name> = < MACHINE or *Pattern*>

사용 예:

Host_Alias SERVERS = 192.168.1.1, server*

(여기서는 컴퓨터의 이름이 server1, server2, server3 형식으로 되어 있다면, server*를 쓰면 이들 모두를 포함하게 됩니다.)

명령들 정의하기
집단에 소속되어질 명령들을 정의하는 것으로, 명령의 경로에는 전체 경로가 지정되어야 합니다:

Cmnd_Alias     <name> = <full path to command/script>

사용 예:

Cmnd_Alias MAIL = /usr/bin/cyrus/tools/amsmailtool, /usr/bin/cyrus/tools/mkimap, \
            /usr/sbin/postfix-watch, /usr/sbin/postfix, \
            /usr/bin/cyrus/bin/ctl_cyrusdb

줄 마지막에 있는 \는 다음 줄에도 명령이 계속 이어진다는 표시이며, 혹 이것을 빼먹는다면 sudoers 파일은 문법의 오류를 갖게 됩니다.

접근 권한 정의하기
이 곳이 실제 작업이 이루어지는 곳입니다. 이제까지 위에서 해왔던 작업은 이 순간을 위한 준비작업과도 같습니다. 이곳에 설명되어 있는 작업은 비교적 알아보기 쉬운 형태인데, 여기에는 우리가 지정해둔 사용자들로 이루어져 있는 집단이, 특정 컴퓨터에서 몇몇 배정된 명령들을 실행할 수 있도록 허용된 특정 집단에 소속되어 있는 것처럼, sudo 명령들을 실행할 수 있도록 해줍니다.

<user_alias>     <host_alias> = (<runas_alias>) <cmnd_alias>

사용 예:

ADMIN     SERVERS = (MAILERS) NOPASSWD: MAIL

위의 것은 sudoers 파일을 사용하는데 있어서 약간 억지로 고안해 낸 사용예로 보일 수도 있습니다만, 특정 상황에서는 이것이 매우 유용하게 사용될 수도 있답니다. 예를 들어, 만약 컴퓨터를 재시동할 수 있는 권한만을 특정 사용자에게 주기를 원할 때는 다음과 같이 설정해 줄 수 있습니다:

User_Alias        SUPPORT = %support_staff

Host_Alias        LABS = lab1-*, lab2-*, lab3-*, \
                lab4-*, lab5-*
                        
Cmnd_Alias        REBOOT = /sbin/reboot

SUPPORT            LABS = (root) NOPASSWD: REBOOT

위의 예에서는, 보시다시피 Runas_Alias를 지정해 주지 않았습니다. 여기서는 다른 사용자/집단/daemon 말고, 특정 사용자에게만 root 권한의 sudo 명령을 사용할 수 있도록 하기 위해서, root의 짧은 이름을 지정해 주었습니다. 이 곳에는 사용자의 짧은 이름 혹은 "ALL"이 지정될 수 있습니다. 그리고 ALL은 어떠한 설정 항목들에서도 사용될 수 있으며, 원래 파일의 root 사용자에는 다음과 같이 설정되어 있습니다:

root            ALL=(ALL) ALL

sudoers 파일에 있는 이 줄은 super-user로서의 root가 갖게 되는 모든 권한을 나태냅니다.

앞의 설명에서는 NOPASSWD 신호에 대한 언급을 아직 안했습니다만, 이름에서 알 수 있듯이 이것은 sudoers 파일에 지정되어 있는 사용자가 sudo 명령을 실행할 때, 암호 입력의 요구를 받지 않게 됩니다. 물론, 이것이 간편할 때도 있지만 각별히 유의해서 사용되어져야 할 것입니다. 특히 어떤 사용자에게 막강한 명령의 권한이 주어졌을 때, 암호를 입력하게 함으로써 지금 실행하는 명령이 정말로 실행하고자 하는 것인지를 확인해서 일깨워주는 구실도 하게 됩니다.

이제, 이렇게 해서 sudoers 파일의 편집을 마무리 했다면, 다음과 같이 원래의 파일을 따로 보관해 놓고, 새로운 파일의 권한과 소유권을 적당한 값으로 지정한 후 원래 파일을 새로운 파일로 대치합니다:

#!/bin/bash

sudo cp -i /etc/sudoers /etc/sudoers.`date +%Y%m%d_%H%M%S`
sudo cp /path/to/remote/sudoers.new /etc
sudo chmod 440 /etc/sudoers.new
sudo chown root:wheel /etc/sudoers.new
sudo mv /etc/sudoers.new /etc/sudoers

이것으로 sudoers 파일이 얼마나 유용하고 강력한지를 잘 보여주는 본보기가 되었으면 좋겠습니다. 특히, 이 파일이 잘 못 설정되어 있으면, 모든 사용자들에게 sudo 권한을 빼앗아 버릴 수도 있으므로, 지헤롭게 잘 간수하시고 수정할 때는 각별한 주의를 기울이시기 바랍니다.

따옴 - AFP548 - Essential Sudoers

423

(3개의 댓글, PunBB 맛보기 글에 작성됨)

Windows의 PATH에 정상적으로 php 디렉토리가 등록되었다면, php.ini 파일과 확장 모듈들이 자동적으로 읽히게 됩니다만, 혹시 등록이 제대로 되어 있는지 다시 확인해 보세요.
관련 PHP 참고 문서 - PHP 디렉토리를 Windows의 PATH에 등록하기
설정을 마치고 나면 꼭 재시동을 해줘야 한답니다.

이미 아시겠지만, Apache, PHP, MySQL을 같이 사용할 때, 하나라도 설정이 잘 못 되어 있다면 실타래가 엉켜있는 것처럼 문제의 원인을 찾아내기가 무척 힘들답니다.
물론 문제들을 해결하면서 얻게되는 세세한 지식들도 있겠지만, 만약 설정하는데 계속 어려움을 겪으신다면, WAMP 설치를 한 번 고려해 보세요.
설치가 간단하고 설치 파일들이 한 곳에 모여 있어서 나중에 관리도 손쉬울 듯 합니다.

저도, Windows 시스템에 설치되어 있는 APM은 생소해서, 관련 설명서들을 매달아 놓는 것 밖에는 큰 도움을 못 드리네요. roll

424

(3개의 댓글, PunBB 맛보기 글에 작성됨)

경고 상자만 보고 대충 짐작하기로는, 아마 이전에 설치되어 있던 php 관련 모듈과 새로 설치한 php 5 모듈이 중복되어서 생기는 문제 같습니다.

새로 설치한 php5 디렉토리에 있는 핵심 PHP 모듈인 php5ts.dll 파일을 포함한 .dll 모듈들이 Windows의 System32 디렉토리 속의 것들과 중복되는지 확인해 보세요.
그래서, 중복되는 것이 있으면 새것을 System32 디렉토리 속으로 복사해 놓으시면 될 것 같습니다.

나중에, 또 PHP5를 갱신할 경우를 생각해서, 아예 php가 설치되어 있는 c:\php 디렉토리를 PATH에 등록시켜 놓는 것이 관리하기에 더 편하다는군요.

나중을 위한 참고로 설치 설명서를 붙여 놓습니다.
PHP Windows 설치 설명서

그리고, 덕분에 kiwi 테마 구경 잘 했습니다. wink

425

(10개의 댓글, Mac OS 글에 작성됨)

Tiger에서 Pico를 대신하는 새로운 Nano 소개

pico는 예전부터 Unix 세계에서는 가장 널리 쓰이던 글자 편집기입니다만, 검색과 치환 기능에서 상당한 제약을 가지고 있다는 약점이 있습니다. 이것이 Tiger에 와서는, GNU 기반인 nano 편집기로 대체되었답니다. Nano는 pico와 호환성을 갖고 있으면서도 여러가지 추가 기능들을 제공합니다.

Nano의 공식 홈 페이지인 www.nano-editor.org 에 가면 nano에 관한 많은 정보를 얻을 수 있으며, Mac OS X 10.4 이전 버전의 사용자들은 공식 홈 페이지에서 nano를 무료로 내려받을 수 있습니다.

설치는 내려받은 파일의 압축을 풀고, 터미널에서 다음과 같은 일반적인 설치 명령을 수행합니다. (여기서 버전 숫자는 다를 수 있습니다):

$ tar xzf nano-1.2.5.tar.gz
$ cd nano-1.2.5/
$ ./configure
  # ...much output here....
$ make
$ sudo make install
Password:
  # ...output here...

그러면, 실행자는 /usr/local/bin/nano에 위치하게 되고, 설명서는 /usr/local/man/에 더해집니다.

Nano의 기능들 중에는 문법 표시 기능(syntax highlighting)이 있는데, <head>와 같은 HTML 꼬리표들(tags)의 색깔을 파란색으로 표시하거나 &와 같은 열외 특수 문자들(escaped characters)을 빨간색으로 표시해 줄 수 있답니다.

꼬리표들의 색깔 지정은 사용자 홈(Home) 디렉토리에 위치하는 .nanorc 파일에 다음과 같이 설정해 줍니다:

#HTML Syntax Highlighting
syntax "HTML" "\.html$"
color blue start="<" end=">"
color red "&[^;       ]*;"

두 번째 줄은 HTML 문법이 이름이 .html로 끝나는 모든 파일들에 적용되도록 지시하는 부분이고, 세 번째 줄은 <와 > 사이에 있는 모든 글자들을 파란색으로 표시하라는 지시입니다. 그리고 네 번째 줄은 &와 ; 사이에 있는 것들(공백과 ;으로 분리되어 있는 것들은 제외)은 빨간색으로 표시하게 합니다. ([와 ] 사이에 있는 글자들은 하나의 공백과 탭(tab) 글자들을 포함하고 있습니다.)

이 곳에 지정해 줄 수 있는 색깔들로는 white, black, red, blue, green, yellow, magenta, cyan 그리고 앞에 제시된 색깔들의 이름 앞에 bright이 붙은 색깔들이 있습니다. 여기서 색깔이 적용될 글자들의 적합성을 판단하는 데는 확장 정규식(extended regular expression)을 사용하게 됩니다.

자세한 .nanorc 파일 설정법은 nano 소스 파일에 포함되어 있는 nanorc.sample 파일을 살펴보면 많은 참고가 되고, 여기에는 여러 설정 가능 항목들과 문법 표시 기능 사용법을 확인하실 수 있습니다.

426

(1개의 댓글, PunBB 맛보기 글에 작성됨)

안녕하세요.

제가 Windows에 설치되어 있는 PHP 환경을 잘 모르지만, 위의 경고 문구가 나오는 문제는 아마도 PHP 컴파일시 GD library 선택설정을 안해서 나오는 것 같습니다. GD library는 PHP가 그림 파일들을 처리할 때 꼭 있어야 합니다. 그래서 미리 컴파일된 형태로 배포되는 PHP 바이너리에는 거이 GD library를 지원하는 것으로 알고 있습니다. 혹시, 직접 PHP를 컴파일 하셨다면, --with-gd 설정도 추가해 주셔야 합니다.
그리고, Windows에서는 php.ini 파일에서 php_gd2.dll도 추가해 주라는 군요. 이것은 extension_dir가 올바르게 지정되어 있다면, 주석 처리되어 있는 extension=php_gd2.dll 부분의 주석을 지워주면 되겠네요. (더불어서, JPEG 및 PNG 형태의 그림을 지원하려면 추가로 해당 library를 설치해야 한답니다.)

참고가 되실만한 PHP 설명서의 GD library 관련 내용입니다: http://kr2.php.net/manual/en/ref.image.php

문제 해결에 도움이 되었으면 좋겠네요.

덧) PunBB 맛보기에서는 원래 손님분들도 글쓰기가 가능한데, 등록까지 하셨네요. 아무튼, 포럼 열고 처음으로 등록하신 회원이 되셨군요. yyymin님 반갑습니다.
PunBB가 웹 표준을 잘 따르면서 코드 실행 속도가 빠르고, 개발도 활발한 편이라 여러 포럼들 중에 참 마음에 드는 놈이랍니다. 설치를 잘 마치시면 운영중이신 포럼 주소도 알려주세요. smile

427

(0개의 댓글, 어플리케이션 글에 작성됨)

이기종간 GUI 원거리 접속 도구들 총집합

타기종의 서버를 관리할 때, 시각적 원격 접속 도구들은 아주 유용할 때가 있습니다. 이 글은 Windows, Mac OS X, 그리고 Unix 컴퓨터들이 섞여 있는 네트워크 환경에서 사용될 수 있는 이기종간 GUI 원격 접속 도구들을 살펴보도록 하겠습니다.

Windows가 원격 서버일 때

Windows 컴퓨터를 원격으로 접속할 때는, Windows Remote Desktop(Terminal Services)을 사용할 수 있습니다. VNC 서버도 Windows에서 잘 작동합니다만, 이 분야 만큼은 Microsoft에서 제공하고 있는 것이 open source의 것들 보다는 더 많은 장점들을 가지고 있는데, Windows Remote Desktop은 VNC보다 더 빠르고, 안전하며, 더욱 많은 기능들을 제공하고 있습니다. 여기에는, 원격 화면, 키보드, 마우스 조종과 더불어, 클라이언트와 서버간의 드라이브 매핑(mapping), 소리와 프린터의 재전송(redirection), 그리고 전체 원격 송수신 간의 암호화된 통신을 제공합니다. 비록, 원격으로 접속되어 있는 컴퓨터의 프린터를 사용해서 인쇄할 일은 드믈겠지만, 일시적으로 원격 컴퓨터들의 드라이브를 마운트 할 수 있는 기능은 유용할 때가 많을 것입니다.

Mac의 Remote Desktop 클라이언트로 재전송되어 보여지는 원격 드라이브들:
http://appletree.or.kr/forum/files/remote/RDCMappedDrives.jpg

모든 Windows Remote Desktop 통신은 암호화되며 단일 TCP 포트(기본 3389)로 전송됩니다. 그래서, VNC처럼 방화벽을 통과해서 라우트(route)/NAT 하기가 수월합니다. Remote Desktop 서버는 Windows XP Pro와 Windows NT 4.0 Terminal Server Edition 그리고 이후의 모든 서버 버전에 포함되어 있습니다. XP의 경우에는 한 번에 하나의 원격 클라이언트의 접속만 허용되지만, Windows Server의 경우는 동시에 두 개의 원격 관리 세션까지 지원합니다.

Unix에서 Windows로

Unix/Linux에서 Windows로 접속할 때는, rdesktop이나 tsclient가 사용될 수 있습니다. rdesktop은 Windows Remote Desktop Protocol (RDP)을 사용하는 Remote Desktop 클라이언트입니다. tsclient는 Gnome 기반으로 rdesktop에다 그래픽 인터페이스를 씌워놓은 것으로 Windows Remote Desktop 클라이언트와도 매우 비슷합니다. tsclient는 또 VNC와 X 서버들에도 접속할 수 있답니다. rdesktop과 tsclient는 모두 GPL 아래에서 배포됩니다.

rdesktop:
http://www.rdesktop.org/
tsclient:
http://www.gnomepro.com/tsclient/

tsclient의 창 그림:
http://appletree.or.kr/forum/files/remote/tsclient.png

Mac OS에서 Windows로

Mac OS X에서 Windows 컴퓨터로 접속할 때는, Microsoft에서 무료로 내려받을 수 있는 Microsoft의 Remote Desktop Connection for Mac을 사용하십시오. Windows와 Unix를 위한 Remote Desktop 클라이언트들과는 달리, Mac용은 오직 동시에 단 하나의 원격 접속만 허용됩니다.

Remote Desktop Connection Client for Mac:
http://www.microsoft.com/mac/otherprodu … ktopclient

Remote Desktop Connection Client for Mac 창 그림
http://appletree.or.kr/forum/files/remote/RDCMac.jpg

Mac OS X가 원격 서버일 때

Mac으로 원격 접속하려면, Mac에서 VNC 서버를 돌리면 됩니다. Mac OS X를 위한 무료 VNC 서버로는 두 가지가 있는데, 가장 쉬운 방법으로는 VNC 서버 기능이 포함된 Apple Remote Desktop (ARD) 클라이언트를 사용하는 것입니다. ARD 클라이언트는 Tiger 10.4에 포함되어 있으며, 이전 OS X 버전들의 사용자들은 무료로 내려받을 수도 있습니다. 원래는 ARD 서버와 함께 동작하도록 설계되었으나, ARD 클라이언트는 기타 다른 OS에서 VNC 서버처럼 접속될 수 있습니다. ARD 클라이언트의 VNC 서버 기능은 약간 느릴 수도 있지만, LAN 접속과 같은 빠른 속도로 원격 접속하면 별 불편없이 사용하는데 충분할 겁니다. 또한 기타 다른 VNC 서버들과는 달리, 여러 개의 모니터 공유 기능도 지원합니다.

ARD 클라이언트 설정에서 VNC 기능 켜기:
http://appletree.or.kr/forum/files/remote/ARDVNC.jpg

아마도, 가장 좋은 Mac OS VNC 서버로는 Redstone software에서 개발된 GPL 하에서 배포되는 VNC 서버인 OSXvnc일 겁니다. 이것은 가장 빠르고필요한 거이 모든 기능들을 갖춘 VNC 서버랍니다. 유용한 기능들로는 오직 내부 VNC 접속만을 허용하는 기능을 들 수 있는데, 이것은 ssh로 감싼 VNC 접속만을 구현하고자 할 때 아주 유용합니다.

OSXvnc:
http://www.redstonesoftware.com/vnc.html

OSXvnc를 위한 또 다른 간편한 도구로 Mike Bombich의 Share My Desktop이 있답니다. 이것은 간단한 설치와 단추 하나로 구성된 창으로 일반 사용자에게 아주 간단한 사용법을 제공하며, ARD 클라이언트의 VNC 서버 보다 빠른 속도를 보여 줍니다.

Share My Desktop:
http://www.bombich.com/software/smd.html

Share My Desktop의 창 그림
http://appletree.or.kr/forum/files/remote/ShareMyDesktop.jpg

Windows에서 Mac으로

Windows에서 Mac으로 접속할 때는, VNC viewer라고도 불리우는 VNC 클라이언트를 사용하면 됩니다. RealVNC와 TightVNC는 모두 Windows VNC 클라이언트들을 포함하고 있는 무료 VNC 도구입니다. 이번 경우에는 Windows에서 서버를 돌릴 필요가 없기 때문에 client/viewer를 내려받으면 됩니다. 사용은 그냥 실행 파일을 돌리면 되고 추가 설치 작업은 필요가 없답니다.

RealVNC:
http://www.realvnc.com/download.html
TightVNC:
http://www.tightvnc.com/download.html

TightVNC 화면:
http://appletree.or.kr/forum/files/remote/TightVNC.gif

Unix에서 Mac으로

대부분의 Unix/Linux에는 VNC 클라이언트와 서버가 포함되어 있기 때문에, shell에서 VNC 클라이언트를 실행하거나, GUI로 된 tsclient를 사용하면 되겠습니다.

Unix를 원격 서버로

Unix 서버로 원격에서 접속하고자 할 때는, 설치되어 있는 VNC 서버(xvnc)를 실행하면 됩니다. 기본적으로, Unix는 사용자의 VNC 동시 접속을 Mac OS 혹은 Windows 경우와는 다르게 처리합니다. Unix에서는, 만약 내부에서도 접속되어 있는 사용자로 원격 접속을 한다면, 원격 사용자에게는 또 다른 사용자 세션이 시작됩니다. 그래서, 내부에서 접속되어 있는 사용자는 원격 사용자 세션을 볼 필요가 없게 되어 영향을 받지 않습니다. Mac OS에서 실행되는 VNC 서버로 이미 내부에서 접속되어 있는 사용자로 원격 접속을 했을 경우에는, 원격 컴퓨터의 사용자가 바탕 화면을 차지하게 되면서 내부 사용자는 원격 사용자의 마우스 움직임을 화면에서 볼 수가 있게 됩니다. Windows XP의 경우는, Remote Desktop 세션이 시작되면 내부 세션은 잠기게 됩니다. Windows 서버에서는, 내부 콘솔(console) 사용자로 접속하거나 다른 접속 세션을 시작할 수 있도록 선택할 수 있습니다.

Windows에서 Unix로

Windows에서 Unix로 접속할 때는 Mac에서처럼 VNC 클라이언트를 쓰면 되겠습니다.

Mac OS에서 Unix로

Mac OS 용 VNC 클라이언트로는, Chicken of the VNC를 사용하시면 됩니다. 이것은 빠르고 가벼우며, 이름 또한 재미있답니다.

Chicken of the VNC:
http://www.geekspiff.com/software/cotvnc/

Chicken of the VNC 화면
http://appletree.or.kr/forum/files/remote/ChickenOfTheVNC.jpg

VNC 보안 관련 정보

VNC의 접속 정보는 암호화 되지만, VNC 세션 자체는 그렇지를 못 합니다. 원격 서버 관리 관점에서 보면, VNC 세션들은 항상 ssh로 감싸주어야 합니다. Windows에서는, VNC 서버로 보내는 VNC 통신을 shh로 감싸주기 위한 ssh 세션을 열려면 PuTTY를 사용하면 됩니다.

PuTTY:
http://www.chiark.greenend.org.uk/~sgtatham/putty/

글자 방식의 접속은 원격 관리를 위한 도구로도 아직 유용하지만, 그래픽 지원 원격 접속 도구들 또한 이기종간 네트워크 관리 도구로 아주 유용하게 사용될 수 있을 겁니다.

따옴 - Big Nerd Ranch Weblog - Cross-Platform GUI Remote Login Roundup

428

(8개의 댓글, 어플리케이션 글에 작성됨)

Complete Apache 2에 Apache 2.0.55를 심어넣어 갱신해 주기

현재, 많은 사용자들을 가지고 있는 Complete Apache는 2.0.52를 마지막으로 갱신된 지가 오래되었지만, 아래와 같은 방법을 사용하면, Apache 2.0.55 버전으로 갱신해서 계속 사용할 수 있답니다.

먼저, Apache HTTP Server 2.0.55 source를 내려받습니다.

압축을 풀고, 폴더 속에 있는 config.layout 파일을 열어서 끝에 다음과 같은 내용을 추가합니다.

<Layout ServLog> 
prefix: /Library/Apache2 
exec_prefix: ${prefix} 
bindir: ${exec_prefix}/bin 
sbindir: ${exec_prefix}/bin 
libdir: ${exec_prefix}/lib 
libexecdir: ${exec_prefix}/modules 
mandir: ${prefix}/man 
sysconfdir: ${prefix}/conf 
datadir: ${prefix} 
installbuilddir: ${datadir}/build 
errordir: ${datadir}/error 
iconsdir: ${datadir}/icons 
htdocsdir: ${datadir}/htdocs 
manualdir: ${datadir}/manual 
cgidir: ${datadir}/cgi-bin 
includedir: ${prefix}/include 
localstatedir: ${prefix} 
runtimedir: ${localstatedir}/logs 
logfiledir: ${localstatedir}/logs 
proxycachedir: ${localstatedir}/proxy 
</Layout>

저장한 후에, 터미널을 열고 httpd-2.0.54 디렉토리로 이동하고 다음과 같이 컴파일(compile)합니다.(물론, 실행 전에 꼭 Apache 서버를 꺼주어야 합니다):

./configure --enable-layout=ServLog --enable-mods-shared=all --with-ssl=/usr --with-mpm=prefork --enable-ssl --enable-dav --enable-cache --enable-proxy --enable-shared --disable-static --disable-unique-id --disable-ipv6 --enable-logio --enable-deflate --with-ldap --with-ldap-include=/usr/include --with-ldap-lib=/usr/lib --enable-ldap --enable-auth-ldap --enable-cgi --enable-cgid --enable-suexec

설정이 끝나면, 다음을 입력:

make

이렇게 해서, 정상적으로 컴파일이 완료되면, 다음 명령으로 Apache를 설치합니다:

sudo make install

이렇게 해서, 2.0.55버전으로 갱신된 Apache 서버를 정상적으로 계속 사용하실 수 있답니다.

Apache의 이후 버전들도 비슷하게 적용될 수 있습니다만, Apache 2.2 버전의 새로운 기능들을 맛보기 위해 갱신하려면 PHP의 경우도 PHP 5.1.1로 갱신해 주어야 합니다.

덧붙여, Complete Apache 2를 위한 PHP 5 설치 요령은 이곳을 참고.

429

(1개의 댓글, Mac OS 글에 작성됨)

Tiger에서는 화면 포착을 위해 모두 여섯 가지의 단축키들을 사용하실 수 있습니다.

  • Cmd+Shit+3: 전체 화면을 포착해서 그림 파일로 저장

  • Command+Control+Shift+3: 전체 화면을 포착해서 클립 보드(clipboard)에 저장

  • Cmd+Shift+4: 화면의 선택된 부분을 그림 파일로 저장

  • Command+Control+Shift+4: 화면의 선택된 부분을 클립 보드(clipboard)에 저장

  • Command+Shift+4 그리고 나서 Space bar: 창, 메뉴, 바탕화면 아이콘, 혹은 메뉴 막대를 포착해서 그림 파일로 저장

  • Command+Control+Shift+4 그리고 나서 Space bar: 창, 메뉴, 바탕화면 아이콘, 혹은 메뉴 막대를 포착해서 클립 보드(clipboard)에 저장

보통, 이렇게 포착해서 저장된 그림은 기본 형식인 .png 확장자를 가지게 됩니다.

이렇게 저장되는 그림 파일의 형식을 바꾸려면 터미널에서 다음과 같이 입력합니다:

defaults write com.apple.screencapture type 그림_형식

위의 그림_형식은 원하는 그림 형식(tiff, jpg, pdf등의 QuickTime이 지원 가능한 형식들)으로 대치해서 입력하시면 됩니다.

변경된 효과를 보려면, 다시 로그 인 하거나, 간단하게 터미널에서 다음과 같이 입력하면 바로 변경된 그림 형식으로 화면 포착 그림을 저장할 수 있답니다:

killall SystemUIServer

또 한 가지, 손쉽게 바꿀 수 있는 설정으로, 화면을 찍으면 생기는 그림 파일이 생성될 위치는 다음과 같이 바꿉니다.

우선, 화면 포착 그림이 생성되서 보관될 폴더를 새로 만들고, 터미널에서 다음과 같이 입력합니다:

defaults write com.apple.screencapture location /폴더의/전체/경로

/폴더의/전체/경로는 하드 드라이브의 맨 꼭대기(root)에서 시작되는 폴더의 경로를 입력해야 하며, 자기(home) 폴더를 나타내는 물결무늬(~)는 사용하실 수 없습니다. 폴더의 전체 경로를 입력하는 손쉬운 방법은 해당 폴더를 터미널 창 위에 떨어뜨리면 그 경로가 자동으로 입력됩니다.

마지막으로, 먼저 번의 요령에서처럼 SystemUIServer를 다시 실행시키면 바로 효과를 볼 수 있게 됩니다.

430

(10개의 댓글, Mac OS 글에 작성됨)

ls 결과를 색깔로 구분해서 표시하기

Mac OS X 10.4 Tiger에 설치되어 있는 ls 명령은 -G 설정 혹은 CLICOLOR 환경 변수와 함께 사용되면, 결과들을 색깔별로 구분해서 나열할 수 있습니다. 여기에 표시되는 색깔들의 구분은 LSCOLORS 환경 변수를 따로 지정해서 사용자의 입맛에 맞게 변경할 수도 있답니다.

그래서, 예를 들어 만약 디렉토리 표시 색깔을 기본 파란색에서 노란색(원래 d값은 갈색을 나타내지만, 실제로는 노란색과 비슷하게 표시됩니다)으로 바꾸려면 터미널 초기 설정 파일(tcsh: ~/.cshrc, bash: ~/.profile)에 다음과 같이 설정해 줍니다.

tcsh shell일 경우:

setenv CLICOLOR 1
# use yellow for directories listing
setenv LSCOLORS dxfxcxdxbxegedabagacad

bash shell일 경우:

export CLICOLOR=1
# use yellow for directories listing
export LSCOLORS=dxfxcxdxbxegedabagacad

여기에 더해서, alias인 alias ls="ls -G" 설정을 추가해 주면 매번 ls 명령을 입력할 때마다, -G 설정을 입력할 필요가 없게 됩니다.

참고로, 기본 LSCOLORS의 설정값은 "exfxcxdxbxegedabagacad"이며, 변수의 속성들은 각기 쌍을 이루며 글자색배경색으로 묶여 있습니다. 여러 속성들의 순서는, 다음과 같습니다:

1. directory  2. symbolic link  3. socket  4. pipe  5. executable  6. block special  7. character special 
8. executable with setuid bit set  9. executable with setgid bit set 
10. directory writable to others, with sticky bit  11. directory writable to others, without sticky bit

그리고, 색깔을 나타내는 지시자들은 다음과 같습니다:

a     black
b     red
c     green
d     brown
e     blue
f     magenta
g     cyan
h     light grey
A     bold black, usually shows up as dark grey
B     bold red
C     bold green
D     bold brown, usually shows up as yellow
E     bold blue
F     bold magenta
G     bold cyan
H     bold light grey
x     bdefault foreground or background

그래서, 예를 들어 기본 설정값인 "exfxcxdxbxegedabagacad"는 일반 디렉토리의 경우, 파란색 글자(e)로 기본 배경색(x)을 바탕으로 표시되고, 심볼릭 링크(symbolic link)는 심홍색 글자(f-magenta)에 기본 배경색(x)을 바탕으로 표시되며, 뒤의 기타 속성들도 이러한 형식을 취합니다.
자세한 ls 관련 설명은 man ls로 설명서를 불러내어 읽어보시기 바랍니다.

431

(1개의 댓글, 어플리케이션 글에 작성됨)

iPod에서 재생할 동영상 변환하기

많은 소문들과 추측들을 뒤로 하고, 드디어 Apple에서 동영상 재생이 가능한 iPod를 내놓았습니다. 그래서, 이제는 새로 갱신된 iTunes를 사용해서 여러 동영상들을 구매/내려받아 iPod에서 재생할 수 있게 되었지요.

그렇다면, 이미 컴퓨터에 저장되어 있거나 소유하고 있는 동영상들도 iPod에서 재생시킬 수 있을까 궁금해 하실겁니다. 물론, 다음에 소개될 방법을 쓰면 간단하게 동영상을 iPod에 담아서 이동 중에도 언제든 즐겨보실 수 있답니다.

DVD 동영상 뽑아 담기

DVD 내용을 뽑을 때 가장 손쉬운 방법으로는 HandBrake라는 이름의 도구를 사용하는 것입니다.
DVD 동영상을 뽑아 내기 위해서, 먼저 DVD 디스크를 넣고 HandBrake를 실행시켜서 Open 단추를 누르면 삽입된 디스크를 검사하게 됩니다. 이때, 만약 DVD 디스크가 복사방지기술로 보호되어 있어서 "no valid title found."라는 경고문을 보여주게 된다면, DVD 복사 방지 기술을 피해갈 수 있는 MacTheRipper가 필요할 겁니다. MacTheRipper를 사용해서 DVD 내용물을 추출해 낸 후에, HandBrake에서 DVD Folder/Image를 선택하고 VIDEO_TS 폴더로 이동합니다. 이렇게 하면 보여지는 여러 title들 중에서 변환하고자 하는 title을 고릅니다. 이때, 동영상의 재생 길이를 살펴보면 원하는 동영상을 고르는데 도움이 될 겁니다.
이제, 변환될 동영상의 여러 설정사항들을 설정해야 합니다. 동영상 형식(File Format)으로는 MP4 File로 하고, Codecs 항목에서 AVC/H.264 Video / ACC Audio를 선택합니다. MPEG-4를 사용해도 되겠지만, H.264를 사용하면 더 작은 파일 크기로 더 좋은 영상을 얻으실 수 있답니다. 다음으로 중요한 설정사항으로는 동영상 크기를 들 수 있습니다. iPod가 지원하는 동영상 크기(최대 320x240 pixels)에 맞게 줄이려면, Picture Settings... 단추를 누른 후, 동영상 넓이(width)320으로 설정하고 Keep Aspect Ratio는 선택되어진 상태로 그냥 놓아둡니다.
다른 설정들은 그대로 놓아두어도 됩니다만, Average Bitrate (Kbps)의 설정은  기본 1,000에서 500~750 사이로 낮추어 설정해 줍니다. 또한, Encoder 설정을 x264 (baseline Profile)로 맞추십시오. 그리고, 가장 좋은 질의 영상을 얻으시려면, 2-Pass Encoding을 선택해 주는 것이 좋습니다. 마지막으로, Destination 항목에서 파일 이름을 넣어주고, Rip 단추를 누르면 되겠습니다.

하드 드라이브에 저장되어 있는 파일 변환

QuickTime Pro 등록 사용자들은 내보내기(Export)... 메뉴에 새로 추가된 Movie To iPod (320x240) 기능을 사용하실 수 있습니다. 그래서, QuickTime에서 열 수 있는 동영상은 iPod 재생용 동영상으로의 쉽게 변환이 가능합니다. 하지만 이렇게 하면, 훌륭한 양질의 동영상을 얻을 수는 있겠지만, 가장 빠른 Mac에서도 보통 동영상 재생시간의 네 다섯 배 정도의 상당한 변환 시간이 필요합니다.
그래서, 더 빠르고 효율적인 방법을 찾는다면, QuickTime Pro의 Movie To MPEG-4 export 기능을 이용한 single-pass H.264 인코딩 방식이 추천됩니다. 우선, 변환하고자 하는 동영상을 QuickTime으로 열고 파일 메뉴의 내보내기(Export)...를 선택합니다. 그리고, 파일 형식으로 MP4를 선택하고, 동영상 포멧은 H.264로 합니다. 여기서, Data Rate256에서 500 Kbps 사이로 하는 것이 좋습니다.
영상 크기(Image Size)는 기본적으로 설정된 320x240으로 하는 것이 좋습니다만, 넓은 비율의 영상일 경우,  원래 영상의 비율에 맞게 설정해 주면 되겠습니다. (원래 영상의 비율은 윈도우(Window) 메뉴에 있는 동영상 정보 보기(Show Movie Info)를 선택하면 보이는 창에서 확인하실 수 있습니다. 일반적인, 16:9 비율의 영상은 320x180 pixels 정도로 축소될 수 있습니다.) 그리고, Frame Rate은 기본적으로 30으로 설정되어 있습니다만, 원래 영상의 것과 일치되게 하기 위해서는 Current 값을 주어야 합니다. 마지막으로, 동영상 선택사항(Video Option)..." 단추를 누르고 [b]Restrict Profile(s) to 값에 Baseline도 선택합니다. 이 baselin 값이 선택되지 않으면 동영상을 iPod에서 재생시킬 수 없답니다.

http://appletree.or.kr/forum/files/quicktime_export_settings_for_ipod.gif

이러한 설정으로 변환하면 빠른 Mac에서는 동영상 재생 시간과 거이 비슷한 시간 안에 변환된 영상을 얻을 수 있답니다.

마지막으로 덧붙여서, iPod에서 재샹 가능한 동영상으로 변환하는데 유용하게 사용될 수 있는 도구들을 소개하자면 무료로 배포되고 있는 iSquint 그리고 상용(US $9.95)인 Podner가 있답니다.
iSquint는 MPEG-1/2 동영상을 single-pass H.264 iPod 동영상으로 쉽게 변환할 수 있고, Podner는 codec이 설치되어 있다면 AVI/DivX 형식을 포함한 MPEG 동영상을 iPod 호환 H.264 (single-pass 혹은 multipass) 혹은 MPEG-4 동영상으로의 변환이 가능하며, 동영상의 미리 보기 창도 함께 제공되어서 변환 결과물의 상태를 바로 확인할 수도 있답니다.

MacWorld 기사에서 발췌.

432

(10개의 댓글, Mac OS 글에 작성됨)

stdin 내용을 Safari로 전달(pipe)하기

터미널 명령인 open에는 -f 선택사항이 있습니다. 이 놈의 기능은 standard input의 내용을 읽어 들여서 그 결과를 기본적으로 설정되어 있는 글자 편집기를 열어서 보여주는 것입니다. 여기서, input 내용은 EOF(End Of File) 글자를 읽어들일 때까지 계속되거나 혹은 Control-D를 입력해서 멈출 수도 있습니다.

이것과 더불어서, 열리는 어플리케이션을 지정해 주는 -a 선택사항을 사용하면, standard input의 내용을 Safari로 열어서 확인해 볼 수 있답니다.

예를 들어,

echo "<html><body>Hello</body></html>" | open -a /Applications/Safari.app -f

위와 같이 입력하면 standard input의 웹 페이지의 내용을, Safari에서 확일할 수 있게 됩니다.

이와 같은 요령은 HTML 결과를 생성하는 코드를 작성할 때 아주 유용하게 사용될 수 있을 겁니다.

한 가지 문제점이라면,

echo "<?xml version='1.0'?><html><body>Hello</body></html>" | open -a /Applications/Safari.app -f

위의 코드에서와 같이 XHTML 코드를 읽어들일 때, Safari에 표시되는 내용은 간단한 text파일(text/plain 형식)로 읽어들이게 되는데, 이는 open 명령이 -f 선택사항과 함께 사용될 때 output을 .txt의 확장자를 가진 임시 파일에 저장하고 이 파일을 읽어드리면서 생기는 문제입니다.

그래서, Safari가 XHTML 내용을 제대로 표시하게 하려면, 추가로 -m 선택사항과 함께 다음과 같이 올바른 mimi-type(text/html)을 지정해 주면 되겠습니다.

echo '<!-- hello --><html><body>Hello</body></html>' | open -a /Applications/Safari.app -f -m text/html

따옴 - Mac OS X Hints

이번에 소개할 BBEdit용 (혹은 AppleScript 지원 글자 편집기) Apple Script는 웹 페이지를 설계할 때, 유연한 배치 기술(elastic layout techniques)을 적용할 경우 아주 유용하게 사용될 수 있는 것들입니다.

여기서, 유연한 배치 기술이란 간단하게 CSS style sheet에서 측정 단위로 pixel 대신에 em 단위를 사용하는 기술이라 말할 수 있습니다. 이러한 기술의 장점이라면, 사용자가 웹 페이지의 글꼴 크기를 바꿀 때, 전체 페이지 구조도 글꼴 크기에 따라 자동 축소/확대 되는 효과를 구현할 수 있다는 것입니다. 이런 효과를 구현하는 데 사용될 수 있는 좋은 한 방법으로는, 페이지에 기본적으로 정해져 있는 글꼴 크기에 따라 모든 pixel 측정 단위를 대응하는 em 단위로 변환해 주는 방법이 있습니다. 간단한 예로, 기본 글꼴 크기를 다음과 같이 설정해 줄 수도 있을 겁니다:

body    {font-size    : 75%; ... }
body    *    {    font-size    : 1em;}

여기에 사용된 글꼴 크기의 % 값은 페이지의 기본 글꼴 크기를 'medium(16px)', 'small(14px)' 그리고 'smallest(12px)'로 설정되어 있을 경우, 각각 100%, 87.5%, 75%로 설정될 수 있습니다.

그래서, pixel 측정 값인 Xpx을 em 측정 값인 Xem으로 변환하기 위해선, 기본 글꼴 크기에 따른 비율을 다음과 같이 곱해 주면 됩니다:

[uli]75%일 경우: Xem = 0.083333 * Xpx[/uli]
[uli]87.5%일 경우: Xem = 0.0715 * Xpx[/uli]
[uli]100%일 경우: Xem = 0.0625 * Xpx[/uli]

예를 들어, 만약 기본 글꼴 크기가 75%로 설정되어 있다면, margin : 10px;margin : 0.8333em;가 되겠지요. 참고로, 비율 값으로 사용될 숫자는 모든 브라우져들에서도 똑같은 측정 크기를 나타내게 하기 위해서 적어도 소수점 이하 네 자리의 값이 필요합니다.

script: 여기에 소개될 스크립트는 커서의 왼 쪽에 위치하는 숫자를 해당 em 단위 값으로 변환하고, 뒤에다가 em 글자를 추가해 주는 아주 간단한 기능을 가지고 있습니다. 세 가지의 스크립트가 있으며, 앞의 각기 다른 세 가지 비율 값을 제외하고는 모두 똑 같답니다:

설치는, 위의 스크립트들을 ~/Library/Application Support/BBEdit/Scripts 폴더로 복사한 후, BBEdit의 Window 메뉴에 있는 Palettes>Script를 선택하면 나타나는 창에서 원하는 스크립트를 선택하고, 'Set Key...' 단추를 눌러서 해당 스크립트를 위한 축약키(에:ctrl-E)를 설정해 놓습니다.
이렇게 하면, 예를 들어 BBEdit에서 width : 25[control]-E라고 입력하면 width : 2.0833em으로 자동적으로 변환이 되서 아주 유용하게 사용될 수 있답니다.

따옴 - Mac OS X Hints

434

(2개의 댓글, Mac OS 글에 작성됨)

앞에서도 이미 소개해 드렸던 Launchd Property List 파일의 생성/편집 도구인 Launchd Editor와 비슷한 기능을 가진 도구로 Lingon이 새로 배포되고 있답니다.

Lingon만의 장점은 Property List 파일들의 생성/편집 기능 뿐만이 아니라, 위의 그림에서처럼 Launchd에 등록되어(Loaded) 있는 작업들의 목록을 유형별로 쉽게 확인할 수 있으며, 또한 Mac OS X의 launchctl을 통해 작업들의 등록 및 해제를 간편하게 수행할 수도 있답니다.

http://appletree.or.kr/forum/files/lingon.png먹음직스러워 보이는 Lingon(스웨덴 산 lingonberry)의 아이콘을 보고 있으면 떠오르는 아이콘들이 있지요. roll

http://appletree.or.kr/forum/files/smultron.png http://appletree.or.kr/forum/files/hallon.png SmultronHallon의 아이콘들로 각각 스웨덴 어로 산딸기와 나무딸기를 뜻한답니다.
알고 보니, 모두 같은 농사꾼의 솜씨로군요. smile

435

(0개의 댓글, Mac OS 글에 작성됨)

OS X의 메모리 사용 방식에 관하여

다음은 Apple의 Discussion Board에 올려진 OS X의 메모리 관리에 대해서 자세하게 설명해 놓은 글을 간추린 것입니다. 원래는 Barry Sharp씨가 MacFixit에 있는 Ted Landau씨에게 보낸 전자우편들의 내용 중에서 가져왔으며, 시스템의 메모리 사용 원리를 이해하는 데 큰 도움이 되리라 생각됩니다.

전자우편 하나

Ted씨에게:

가상 메모리(VM)는 말 그대로 "가상"의 것이라서 실제로는 존재하지 않는답니다. 이 말은 가상 메모리가 디스크 공간을 조금이라도 차지하고 있지는 않다는 뜻입니다.

그래서, 시스템이 바꿔치기(swapping) 작업을 행하지 않았다면, 사용자로서는 스왑(swap) 파일의 크기나 그 위치에 대해서는 걱정할 필요가 전혀 없습니다. 바꿔치기 작업은 터미널의 top 명령으로 보이는 결과 중, 윗부분 마지막 줄에 있는 "0(0) pageouts" 값으로 확인할 수 있습니다. 또 다른 쓸만한 터미널 명령으로 vm_stat이 있습니다. 이 명령은 Pageout(실제 메모리에서 디스크로 떨어져 나간) 횟수도 보여주는데, 이 pageout 값은 실제로 메모리가 스왑 파일로 대치된 것을 나타냅니다. 바꿔치기 작업으로 들어오고 나가는 것은 page 덩어리(chunk)로 계산되는데, page 한 덩어리는 크기가 4096바이트입니다.

실제 메모리가 스왑 파일로 대치되었다면 이것은 실제 메모리가 용량을 초과해서 점유되었다는 뜻입니다. 빈번한 실제 메모리의 초과 점유를 방지하기 위한 가장 좋은 해법은 동시에 실행되는 애플리케이션들의 수를 줄이거나 더 많은 메모리를 설치하는 것일 겁니다. 실제 메모리가 용량을 초과해서 점유될 때, OS는 사용할 수 있는 메모리 공간을 마련하기 위해 현재 사용되는 않는(inactive) 메모리 공간을 찾아서 스왑 파일로 복사해놓게 되며, 이는 나중에 다시 스왑 파일에서 실제 메모리로 복사가 이루어지게 됩니다.

이러한 Unix 시스템 가상 메모리의 지속적이고 과도한 바꿔치기 작업은 결코 좋은 현상이 아니고 모든 수단을 마련해서 피해야 하겠지만, 여의치 않을 때에는 메모리 과 점유 현상에 의한 스왑 파일의 생성은 피할 수 없을 것입니다.

만약 pageout의 횟수가 0이 아니면서 또한 급격하게 늘어난다면, 메모리를 추가하거나 동시에 실행되는 애플리케이션들의 숫자를 줄여야 할 것입니다.

그리고 스왑 파일을 따로 위치시키고 설정하는데 드는 시간과 노력은 쓸데없는 짓이며, 이것은 과 점유로 말미암은 메모리의 근본 문제를 그냥 덮어두려는 것과도 같습니다.

또한, 다중 CPU 시스템에서는 바꿔치기 작업이 진행되는 동안 CPU가 다른 작업으로 바쁜 경우라도 바꿔치기 작업으로 인한 성능저하는 없답니다. 바꿔치기 작업과 CPU 작업은 동시에 진행될 수 있으며, 오로지 CPU가 바꿔치기 작업으로 디스크에서 읽고 쓰는 작업이 끝마치기를 기다리면서 대기하는 상황이 생길 때에만 바꿔치기 작업으로 말미암은 성능의 저하 문제를 보일 것입니다. 이 경우에는, 스왑 파일을 아주 빠른 장치에 위치시키는 것으로 득을 볼 수도 있을 것입니다.

대부분의 OS X 사용자들을 위해 제가 해 드릴 수 있는 충고는 스왑 파일의 위치와 설정은 그대로 내버려두고 컴퓨터에 항상 사용 가능한 충분한 실제 메모리가 설치되어 있도록 하시라는 겁니다.

전자우편 둘

Ted씨에게:

저의 "가상 메모리의 스왑파일과 그와 관련한 OS X 성능"에 관한 글을 읽은 후에 많은 분이 덧붙이신 글들에 대한 저의 생각들을 여기에 옮겨 봅니다.

의견 1: 얼마나 많은 RAM을 설치했든 간에 OS X는 모든 RAM을 소비해 버리는 것 같다.
의견 2: 사용 시간이 증가하면서 시스템의 성능도 함께 향상되는 것 같다.

비록 제가 X 커널 소스 코드를 살펴보지는 않았습니다만, 왜 이런 의견들이 돌고 있는지, 그리고 의견들이 어째서 옳은 얘기인지도 쉽게 짐작할 수 있을 것 같습니다.

먼저, 주제에서 약간 벗어난 얘기로 9.1 시절로 돌아가 봅시다. 9.1에서는 현재 OS X에서 이루어지고 있는 것과 관련해서 두 가지의 설정 선택사항들이 있었습니다.

이것은 바로 디스크 캐쉬와 RAM 디스크 기능이었습니다.

디스크 캐쉬는 기본값으로 설정되거나 변경될 수도 있었습니다. 이 캐쉬에는 자주 사용되는 디스크 데이터 혹은 그냥 디스크에 쓰여지는 데이터를 위해 사용되었습니다. 이것은 애플리케이션들이 필요하면 데이터를 바로 읽어들일 수 있도록 해서 디스크에서 읽어들이는 작업을 단축하고자 한 것입니다. 물론, 메모리 대 메모리 전송은 디스크 대 메모리의 속도 보다는 빠를 것입니다. 여기서 주지해 둘 것은, 바로 이 디스크 캐쉬는 고정된 것이라는 점입니다. 그 크기는 절대로 변하지 않습니다. 만약 이것을 더 크게 한다면, 자동 애플리케이션들을 위한 메모리의 공간은 줄어들게 됩니다. 반면, 너무나 작게 설정되어 있다면, 별로 큰 이득을 얻을 수 없을 겁니다. 그리고 데이터를 메모리에 담아두는 것은 약간의 문제를 안고 있어서, 만약 시스템이 오류로 멈춰버린다면 RAM에 담아두었던 데이터는 잃어버리게 되고, 재시동 후에도 복구할 수 없게 됩니다.

RAM 디스크 기능도 디스크 캐쉬와 그 성격이 비슷해서, 그 크기가 고정되어 있고, 또 애플리케이션들이 사용하게 될 소중한 메모리의 공간을 사용하게 됩니다. 이것의 용도는 몇몇 애플리케이션들이 데이터 파일들을 반복적으로 재사용 해야 할 때 유용하게 사용될 수 있습니다. 만약 이 데이터 파일들이 RAM 디스크에 모두 얹어서 사용할 수 있다면 느린 디스크의 데이터 전송 속도를 피할 수도 있어서 커다란 이점을 얻을 수 있었습니다.

OS X에서는 앞의 두 가지 기능들이 표면상으로는 존재하지 않습니다.

하지만, X의 기저(UNIX kernel)에서는 사용자에 의한 어떠한 간섭 없이도 두 가지 기능 모두를 제공하고 있습니다. 이것이 바로 파일 시스템 버퍼 캐쉬(file system buffer cache)입니다. 가장 큰 차이점은 이 버퍼 캐쉬의 크기는 유동적이라는 것입니다. 그래서, 처음에는 약간의 작은 크기로 시작해서 I/O 요구에 따라 증가하고 감소할 수 있으며 애플리케이션들의 메모리 요구량도 시간에 따라 변하게 됩니다.

이것은 I/O 데이터를 디스크로 저장하고 읽어들이면서 완충 기억해 놓는 연유로 해서 '버퍼 캐쉬(buffer cache)'라 불립니다. 애플리케이션이 데이터를 쓸 때, 처음에는 애플리케이션의 버퍼 메모리 구역에 저장되고 나중에는 라이브러리의 정해진 과정에 따라 OS 커널(kernel)에 의해 애플리케이션의 버퍼 내용을 디스크에 복사하도록 요청됩니다. 커널은 처음에는 무조건 파일 시스템 버퍼 캐쉬에 복사하게 되어 있답니다. 만약 버퍼 캐쉬의 공간이 더 필요하게 되면 사용되지 않는 빈(free) 메모리에서 모자란 부분을 채우게 됩니다. 이렇게 되면, 터미널의 top 명령에서 보이는 쓰이지 않는(free) 메모리의 값은 줄어들게 됩니다. 시간이 지나감에 따라 나중에 커널은 이 데이터를 - 더러운 버퍼(dirty buffer)라 말해지는 - 적당한 디스크 위치에 복사하게 됩니다. 제가 일기로는 이것의 주기는 대략 30초 간격을 두고 일어나며 이 작업은 디스크로 동기화(sync-ing) 한다고 불립니다.

한동안 재시동 없이 OS X를 계속 사용하게 되면 커널의 파일 시스템 버퍼 캐쉬에는 가장 많이 필요하거나 혹은 자주 사용되는 데이터들로 채워지게 됩니다. 이것은 왜 시스템을 오래 사용하면 할수록 더 향상된 성능을 갖는 것처럼 보이는지를 설명하는 데 도움이 될 것입니다. 이제는 작업에 필요한 대부분의 데이터들은 커널의 버퍼 캐쉬인 메모리에 자리하게 되고 이는 디스크에서 일일이 데이타를 읽어들일 필요가 없게 된다는 의미입니다. 물론 이것은 성능의 향상에 큰 도움이 됩니다.

앞에서도 말했듯이, 커널은 버퍼 캐쉬를 필요에 따라서 사용되지 않는 메모리에서 가져와서 사용하게 됩니다. 이것은 시스템의 작업량에 따라 단시간 혹은 긴 시간 동안에 터미널의 top 명령에서 보이는 사용 가능한 모든 RAM이 시스템에 의해 사용되고 있는 것처럼 보이게 되는 이유이기도 합니다.

또 한 가지 말해두고 싶은 것은, 커널 버퍼 캐쉬가 아주 많이 증가해서 설치된 RAM 대부분을 잠식했다고 해서 성능상의 큰 피해는 없다는 것입니다. 만약 새로운 애플리케이션이 실행되면 커널은 필요한 만큼의 버퍼 캐쉬를 내어주게 됩니다. 처음에는 새로운 애플리케이션의 메모리 요구량을 받아들일 수 있는지를 확인하기 전에 '더럽혀지지 않은' 버퍼 캐쉬 중 일부분을 내놓습니다. 모든 더럽혀지지 않은 버퍼 조각들을 다 내놓은 후에도 어플리케이션을 위한 더 많은 메모리가 필요하다면, 버퍼 캐쉬 중 더럽혀진 부분을 디스크에 복사해 놓으면서 얻어진 메모리 공간을 새로운 애플리케이션에 내어줍니다. 이 작업은 새로운 애플리케이션에 의해 요청된 모든 메모리가 충당되어서야 비로소 멈추게 됩니다. 이런 식으로 해서 커널 버퍼 캐쉬의 크기는 줄어들게 되며, 나중에는 어떤 정해진 최소의 크기까지 줄어들 겁니다. 이 경우, 커널은 다른 사용되지 않는(inactive) 메모리를 찿게 됩니다. 여기에는 놀고 있는 애플리케이션의 메모리도 포함되는데, 이 경우에는 커널은 새로운 애플리케이션의 메모리 요구량을 충족시키기 위해 놀고 있는 애플리케이션의 메모리를 디스크로 그대로 복사해 놓기(page out) 시작합니다. 이런 커널 활동을 페이징(paging) 혹은 바꿔치기(swapping)라고 부릅니다.

커널이 바꿔치기를 실행하면 이것은 컴퓨터에 설치된 실제 메모리가 과 점유된 상태라는 뜻입니다. 이러한 지속적인 바꿔치기는 시스템 전체의 성능에 부하를 주어서 작업 반응 속도가 더디게 만들고 과도한 디스크 I/O(읽고/쓰기) 탐색 작업들을 수행하게 됩니다. 이러한 형태의 작업은 터미널의 top 명령으로 볼 수 있는 "pageouts" 값에 바로 표시가 됩니다. 만약 이 값이 0이 아니고 짧은 시간 안에 급격하게 늘어난다면 과도한 바꿔치기가 일어나고 있다는 뜻이며, 결코 바람직한 현상은 아니랍니다.

만약 과도한 바꿔치기가 일어난다면 더 많은 RAM을 설치하거나 혹은 컴퓨터의 작업량을 줄여야 합니다. 물론 시스템은 계속 작업을 수행하겠지만, 최적의 성능을 보여주지는 않게 됩니다.

이것으로 왜 OS X 시스템이 재시동 없이 시간이 지남에 따라 더 좋은 성능을 보여주는 것처럼 보이는지 그리고 왜 충분할 것 같은 RAM을 설치하였어도 시스템이 모든 메모리를 소비하고 있는 것처럼 보이는지를 잘 설명해 주리라 생각됩니다.

좋은 한 예로 터미널 애플리케이션을 사용해서 커널 버퍼 캐쉬가 실제로 사용되는 것을 확인할 수도 있습니다. 방법은 터미널에서 커다란 크기의 파일 복사 작업을 수행하면 됩니다. 큰 파일로는 스왑파일이 적당할 것입니다. (이 작업을 수행하기 위해서는 root 권한이 필요합니다.) 또한 top 명령이 실행되는 동안 제2의 터미널 창을 열어 놓으면 편리합니다.

cp /var/vm/swapfile0 ./bigfile

만약 top 명령으로 이 복사 작업 전에 비어 있는(free) 메모리 용량이 100MB 정도로 표시되어 있었다면, 이 작업으로 빈 메모리 용량이 4~5MB 정도로 급격하게 줄어드는 것을 확인하실 수 있을 겁니다. 이것은 커널이 버퍼 캐쉬를 위해 거의 모든 사용 가능한 빈 메모리를 소비하였기 때문입니다.

이제 ./bigfile을 지웁니다.

rm ./bigfile

이렇게 하면 top 명령으로 보인 결과에는 어떤 일이 일어날까요? 여기서는 갑자기 사라져 버렸던 빈 메모리가 다시 채워진 것을 확인하실 수 있을 겁니다. 이것은 복사해 두었던 ./bigfile을 지웠기 때문에 커널이 더는 ./bigfile을 담아두었던 버퍼 캐쉬의 공간이 필요하지 않아서 디스크에 기록해 둘 필요가 없어졌기 때문입니다.

그러므로 저의 충고는

가) top 명령으로 보이는 빈(free) 메모리가 너무 작아서 걱정하실 필요는 없으며

나) pageouts 값에 주의를 기울이시고, 만약 이 값이 시간이 지나면서 급격하게 증가한다면 컴퓨터의 작업하중을 줄이거나 혹은 작업하중을 줄이는 것이 불가피하다면 추가 RAM을 설치해 주십시오.

다) 스왑파일의 크기를 줄이거나 다른 곳으로 옮겨두는 작업에 시간을 낭비하지 마십시오 -- 어쩌면 흥미로운 작업이 될 수도 있습니다만 일반 사용자에게는 어쩌면 쓸데없는 짓이랍니다. 그냥 간단하게 과도한 바꿔치기 작업만 피하시면 됩니다.

마지막으로 -- 제가 생각하기에는 OS X는 최소한도로 적은 양의 빈 메모리를 항상 유지하려 한다는 점입니다. 제 경우에는 3MB 이하로 내려간 것을 본 적은 없습니다. 제가 일기로, 이것은 메모리가 꼼짝달싹할 수도 없는 상황을 피하기 위한 것으로 아주 위급한 명령을 실행하는 데 필요한 메모리를 따로 저장해 놓은 것이라고 볼 수 있습니다.

아래는 제가 OS X 커널 소스 코드를 가지고 있지도 않고 직접 자세하게 실험해 본 적도 없지만 아는 한도 내에서 저의 의견들을 몇 가지 적어 놓은 것이랍니다.

1. (사실) 매번 OS X가 시동할 때마다 시스템은 스왑 파일의 조각들을 제거합니다 -- 예) swapfile0, swapfile1, swapfile2, ..., swapfileN

2. (사실) 매번 OS X가 시동할 때마다 시스템은 /var/vm/swapfile0 파일을 생성하며 제가 알기에는 그 크기는 80MB입니다.

3. (추측) OS X가 swapfile0 파일을 생성할 때 디스크에 연속적인 한 묶음으로 생성되도록 강제되지는 않을 것이며, 하드 디스크의 분절도에 따라 여기저기 흩어져서 기록될 것입니다.

4. (추측) OS X가 메모리를 바꿔치기(pages/swaps)할 때, 일정한 형태의 I/O를 사용해서 한 묶음(page라 불림)에 4096바이트 크기로 데이터가 전송됩니다. 이것은 아마도 HFS+ 형태의 최소 할당 크기가 4096바이트인 연유일 겁니다. 한 건의 I/O 요청으로 OS X가 다중의 4096 =바이트 묶음들로 바꿔치기 되는지는 불분명하지만, 만약 아니라면 바꿔치기는 하나의 4096바이트 묶음들로 전송될 겁니다.

5. (사실) 만약 커널 버퍼 캐쉬가 하나의 연속된 디스크 주소 영역에 있는 여러 4096바이트 묶음들로 구성되어 있으며, 이 여러 묶음들을 바꿔치기할 때 만약 커널이 여러 묶음들을 적당한 순서로 구성하고 단 하나의 I/O 요청을 실행하게 되면 훨씬 빠른 속도를 보여주게 될 것입니다.

6. (사실) 애플리케이션의 메모리는 RAM 전반에 흩어져서 있으며, 연속되어서 기록될 필요는 없습니다.

7. (사실) 대부분의 애플리케이션들은 메모리 영역 재진입 코드 부분들을 다른 애플리케이션들과 공유하고 있으며, 일반적으로 이런 코드 부분들은 자주 사용되기 때문에 절대로 바꿔치기 되어서 디스크에 기록되지는 않습니다.

8. (사실) 만약 OS X가 사용자의 메모리 요구에 부응하기 위해 계속하여 바꿔치기 작업을 하게 된다면 시스템의 반응 속도는 한때 밑바닥으로 처박힐 수도 있습니다.

이러한 현상은 top 화면에서 pageouts 값을 확인하면 알 수 있습니다.

계속적인 바꿔치기의 들락거림은 결코 좋은 현상이 아니며 메모리가 과 점유된 상태를 나타냅니다. 어떤 이유로 이것이 불가피해서, OS X가 각각의 4096바이트 묶음들이 아닌 연속된 4096바이트 묶음들로 바꿔치기해서 디스크에 기록한다는 가정하에 분절되지 않은 스왑파일은 어느 정도 이점이 있을 수도 있습니다만, 그렇지 않다면 분절되었든 아니든 간의 차이점은 전혀 없답니다. 어떤 경우이든, 이 상황은 스왑파일의 위치를 변경하는 것보다는 더 많은 RAM을 추가해 줌으로써 해결할 수 있습니다.

이것은 고속도로의 차량 정체 현상과 비슷해서, 만약 고속도로가 지속적으로 정체된다면 해결책은 고속도로로 진입하는 차들의 숫자를 제한하거나(작업량을 축소하거나) 혹은 길을 넓히거나 더 많은 고속도로를 건설하는 것(더 많은 RAM을 추가하는 것)뿐이라는 사실과 같겠지요.

제 추측에는 OS X가 스왑파일을 하드 디스크에 생성할 때 연속적으로 기록할 것으로 생각합니다만, 만약 이것이 맞는다면 스왑파일을 다른 곳에 있는 것은 아무런 이득도 없을 겁니다.

OS X 스왑파일들의 기본 배치와 관련해서 추가 정보를 찾게 되면 나중에 다시 연락드리겠습니다.

그럼, 어쩌면 장황할지도 모르는 저의 설명이 도움되셨으면 좋겠습니다.

이 글은 저의 UNIX OS 경험에 비추어 설명해 드렸음을 알려 드립니다.

Barry Sharp 씀.

다음은 터미널에서 top 명령을 실행하면 보이는 용어들에 대한 간단한 설명입니다.

PhysMem은 그냥 컴퓨터에 설치된 실제 메모리인 RAM을 뜻합니다.

1. Wired = 메모리를 점유하고 있으면서 절대로 바꿔치기 작업으로 디스크에 옮겨질 수 없는 영역 (메모리에 고정된 부분으로 예를 들어 OS 코드의 일부분이 될 수도 있습니다.)

2. Active = 최근 N 초 동안 읽힌 메모리 영역

3. Inactive = 최근 N 초 동안 읽힌 적이 없었던 메모리 공간으로 추가 메모리 요구 상황이 있을 시에는 가장 먼저 바꿔치기 될 수 있는 영역입니다.

4. Used = Wired + Active + Inactive

5. Free = 어떤 작업 혹은 커널에 의해 점유되지 않은 메모리 영역

6. VM = 가상 메모리 (실제 존재하지 않는 메모리 양으로 작업들이 잠재적으로 사용 점유할 수 있는 메모리 영역의 최대치로 실제로는 거의 요청되지 않습니다.)

top 명령으로 보이는 수치들은 실시간 결과과거 기록들을 같이 보여주게 됨을 기억해 두시기 바랍니다. PhysMem 항목에는 top 명령이 커널에게 요청했을 당시의 실제 값들을 보여주게 됩니다만 pageins과 pageouts 값은 컴퓨터가 시동했을 때부터 측정된 값들을 보여주게 됩니다.

따옴 - Mac OS X Hints

다른 글타래에도 올려두었던 메모리 관련 유용한 터미널 명령들을 덧붙입니다.

- 메모리 사용량 확인

sm=$(top -ocpu -Otime -R -l1 | grep 'PhysMem' | cut -c 11-75);
vm=$(top -ocpu -Otime -R -l1 | grep 'VM' | cut -c 5-9);
echo "SM Usage: $sm VM Size: $vm"

- 스왑 파일들(swap files)의 전체 크기 확인

size=$(/usr/bin/du -hc /var/vm/swap* | grep 'total' | awk {'print $1'});
echo "Total size of swap files: $size"

- Page out된 메모리 용량 확인

po=$(vm_stat | grep 'Pageouts' | awk '{print $2"*4096/1048576"}' | bc);
echo "Size of Page outs: $po MB"

위 명령들은 GeekTool에 등록해 놓고 주기적으로 확인하면 더 간편하답니다. wink