MINZKN의 블로그

이 내용은 설치하면서 생각나는것을 메모로 적었기 때문에 두서가 없다.

오늘 그동안 우리회사에서 열심히 실행되어온 Fedora기반 개발서버가 파일시스템이 깨져버렸다.

물론 재부팅하고 파일시스템 강제로 체크시도하여 복구는 되었으나
이미 한번 맞이 간 상태는 다시 그러지 말라는 법이 없다.

다시 파일시스템이 깨지는 사태를 겪을우려를 안고 있을바에는
이 기회에 백업할건 다 하고 새로 젠투리눅스로 설치하자는데
팀원 모두 의견을 같이했다.

물론 젠투리눅스는 나의 입김이 좀 많이 작용하기는 했지만
대신 관리는 내가 하게 됐다. ㅡㅡ;
젠투리눅스를 관리할수 있는 사람이 나밖에 없으니 선택의 여지는 없었다.
그래도 젠투리눅스는 설치만 오래걸리는것이지 관리가 용이하기 때문에
바로 백업하고 설치들어갔다.

난 젠투리눅스를 왜 좋아하냐는 질문에 답변한다면 아래와 같은 답변을 한다.

1. 개발환경구축에 이만한게 없다.
  - Cross compiler 를 multislot으로 설치하기가 매우 쉽다. (Cross 개발환경 구축에 대해서는 젠투가 다른 어떤 배보판보다 월등하다고 생각한다.)
  - 특정 라이브러리의 버젼을 선택적으로 설치가 가능하다.
  - 특정 참고할만한 패키지의 소스를 따로 검색할 필요없이 받을수 있다. (emerge -f "패키지명")
2. 내가 원하는 패키지 버젼을 선택할수 있다.
3. 젠투를 사용하면 사용할수록 리눅스를 깊이있게 알아간다. (다른말로 하면 삽질을 효율적으로 한다.)
4. 용량이 큰 설치시디는 젠투세계에서는 필요없다. 그냥 아무거나 부팅되서 프롬프트만 뜰수 있으면 시디가 아니라도 젠투를 설치가 가능하다.
5. 설치에 관련된 문서들과 커뮤니티가 매우 활발하다. (http://www.gentoo.org, http://gentoo-wiki.com )
6. 특정 아키텍쳐에 설치하는것이 binutils, gcc가 포팅가능한 시스템이면 거의 대부분 설치가 가능하다. (Embedded쪽 rootfs구축하는것에 매우 요긴한 방법을 제공한다.)
7. Local portage를 지원하므로써 나 자신만의 별도 패키지를 구성하여 사용하거나 배포가 가능하다.
8. 새로운 배포판 버젼이 나왔을때 다시 설치해야될 이유가 없다. 그만큼 업데이트 시스템의 의존성 해결능력이 굉장히 탁월하고 장기적인 유지보수면에서 다른 배포판보다 적은 비용을 유발한다. 한번 설치하면 제대로 관리만 하면 결코 재설치할 일이 발생하지 않는다. (2004 profile에서 2008 profile까지 쭉~ 업데이트 관리해온 내 PC가 그 증거다. 벌써 4년째 사용중이지만 군더더기 파일들이 거의 없다.)

 
장점이 있다면 단점도 있는법! 단점은 아래와 같이 꼽을수 있겠다.

1. 설치과정이 대부분 컴파일하는 시간으로 소요되므로 다른 배포판보다 초기 설치시간이 오래걸린다.
2. 개발자들에게는 유용한 삽질일수 있으나 일반 사용자들에게는 고문일수 있는 삽질요소들이 있다.
3. 네트웍이 없는 시스템에서는 설치가 불가능한것은 아니지만 설치가 매우 피곤해진다.


뭐 대충 장단점 열거해봤다.
내가 이래서 젠투 매니아가 됐다.
분명 일반 사용자들에게는 결코 좋은 배포판이 아니다.
개발자들이나 전문가들을 위한 배포판으로 최고다.

어찌되었건 개발서버에 이러한 이유로 젠투설치를 주장했고
현재 열심히 2008 profile기반으로 설치중이다.


이제 2008 profile을 설치하면서 간간히 발생한 사소한 문제점에 열거하고 추가적으로 몇가지 생각나는 팁들도 덤으로 붙여서 적어본다.

1. gamin, glib 패키지는 상호 의존관계를 가지고 있다. glib에 USE flag가 fam이 걸려있는 경우에 그렇다. 이 경우 임시로 USE flag에서 fam을 제거하고 glib설치후에 다시 fam을 준후 업데이트 하면 해결이 가능해졌다.

2. stage1부터 설치하는 경우 중간에 openldap 에서 빌드문제가 발생할수 있다. 이 경우 침착하게 gentoolkit을 설치후에 revdev-rebuild한번 실행해주고 다시 설치 시도하면 설치가 된다.

3. 32bit 로 기존에 사용하던 젠투 profile을 이용해서 64bit 커널을 빌드하려면 우선 crossdev 패키지를 설치하고 이걸 이용하여 x86_64-pc-linux-gnu 등과 같이 cross compiler 를 설치한다. 그리고 menuconfig 할때 "make ARCH=x86_64 menuconfig" 와 같이 ARCH 환경을 강제하고 설정한후에 빌드할때 비슷한 맥락으로 "make ARCH=x86_64 CROSS_COMPILE=x86_64-pc-linux-gnu-  clean modules modules_install bzImage install" 과 같이 CROSS_COMPILE을 함께 지정하여 빌드하면 32bit 젠투 profile에서 64bit 젠투 profile로 넘어가기 위한 64bit 커널을 빌드할수 있게 된다.

4. local time zone 문제로 시간이 꼬여서 파일 의존시간에 의한 경고를 볼때가 있다. 이런경우 "/etc" 하위 파일들을 모두 touch 로 건드려주면 된다. 하지만 꺼림직한 방법이기 때문에 애초에 설치할때부터 "/etc/localtime", "/etc/conf.d/clock"을 자신이 원하는 시간대로 수정후에 설치하는것이 좋다. 예전 LiveCd에서는 rdate가 없어서 시간동기 맞추기 불편했는데 2008 LiveCd에는 rdate가 들어있다.

5. stage3에서 "emerge -e system" 한후에 되도록이면 "gentoolkit"을 먼저 설치하고 revdev-rebuild 명령을 수행해주는것이 좋다. 그 밖에도 update 하거나 추가 패키지 설치후에는 "etc-update && env-update && revdev-rebuild" 와 같은 식으로 해주면 패키지중에 역 의존성 파일들이 깨지지 않은 상태로 유지될수 있다.

6. 젠투 홈페이지 보니까 최근에 KAIST 미러만 있었는데 새로 국내 미러가 추가됐다. 전부 속도가 만족스럽다. 굳이 외국 미러쓰지 않는게 좋다. 국산을 이용하자.

7. 젠투는 부팅된 자신으로부터 다시 자신과 비슷한 또 다른 rootfs을 만들어낼수 있도록 고안되어 있다. 때문에 파티션은 이렇게 나눌것을 내 개인적인 생각으로 권장한다.

   PART1과 PART2는 16Gbytes씩 나누고 PART4는 swap으로 2GBytes를 잡는다. 나머지 용량은 PART3에 할당한다.
   PART1은 첫 젠투 설치할때의 root 가 된다.
   PART2는 새롭게 젠투를 설치할때 새로운 root가 된다.
   PART3는 보통 "/home"이 된다.
 
  이렇게 파티션을 나누면 원격에서 관리하는 경우에 매우 요긴하다. boot 파티션은 안하는게   내 경험상 더 좋다. 처음에 PART1에 root로 설치해서 잘 쓰다가 한번 확 밀어버리고 싶을때 원격에서 그냥 PART2에 설치해서 재부팅만 하면 된다는게 이 파티션 구성의 취지이다. 서버 관리할때 이런 파티션 구성이 매우 편하다.

8. Embedded 개발자라면 crossdev, mtd-utils, genromfs 같은 패키지를 활용하게 될거다. 난 이 패키지들이 없었으면 젠투를 사용할 의미가 많이 상실된다. 그 정도로 내게는 매우 고마운 패키지다.

9. 젠투를 처음 설치하는 사람들에게 가장 어려운 부분은 아마도 커널설치일거다. 젠투랑 담쌓고 사는 사람들은 대부분 커널설치에서 포기했던 사람이 아닐까 싶다. 하지만 좋은 방법은 없다. 그냥 커널에 대해서 잘 이해하고 설정할수 밖에 없다.
  - 최신 Intel 보드중에 ICH어쩌구 하는 보드를 사용중이고 SATA HDD가 10MB/s이하로 나온다면 AHCI 지원을 BIOS에서 활성화하고 (아마도 SATA관련 Enhanced로 선택하면 AHCI enable 하는 옵션이 나올거다.) 커널에서도 AHCI를 활성화 해주면 쾌적한 HDD속도를 볼수 있을거다. 이게 Intel이 고집하는 ICH 때문에 좋던 싫던 ICH 최신 보드는 AHCI를 받아들여야 한다.
  - 방화벽(iptables, ip6tabls) 을 사용하려면 커널 옵션에서 netfilter 하위 옵션들을 모두 활성화(y 또는 m) 해주면 된다.
  - VESA frame buffer는 되도록이면 활성화해주는게 좋다.



현재 개발서버에 두가지 rootfs으로 빌드중이다. 하나는 x86_64로 빌드중이고 동시에 i686용도 빌드중이다. x86_64는 PART1에 설치중이고 i686은 PART2에 설치 진행중이다. 64bit가 당연히 우선이고 개발과정에서 불가피하게 32bit환경이 필요한 경우를 대비한것이다.

아직 Xwindows를 설치하지 않았다. 요게 사실 제일 오래걸리니까...
gnome, kde등 full xwindows로 설치할 계획이다.

IPv6 는 freenet6 패키지를 이용하여 커널링으로 사용가능하게 할 계획이다.

"/etc/sysctl.conf"에서 "vm.swappiness = 5" 항목을 추가하여 swap을 최대한 미루도록 하여 오랜동안 잠들었다가 깨어나는 프로세스의 응답을 향상시키도록 한다.

apache + php + mysql 설치는 그냥 한다. 그리고 MoniWiki로 개발관련 팀원들끼리 문서화를 주도한다. 이 3가지 피키지는 과거 젠투에서는 문제가 종종 있었으나 요즘에는 너무 깔끔해져서 왠만해서는 문제없이 잘 설치될거다. Moniwiki는 나에게 없으면 안되는 유용한 정리도우미로 소중한 위키시스템이다.

bind 를 설치하고 내부 호스트 DNS서버로 사용한다.

dhcp서버는 설치하지만 사용하지 않는다.

로그시스템은 syslog-ng를 사용한다.

cron은 atd, vixie-cron을 사용한다.

시간 동기화는 ntp 를 이용한다. 일부 시스템에서는 RTC에 문제가 있는것처럼 보이는데 커널설정 잘하면 된다.

Qmail을 설치는 하는데 사용할지는 미지수. smtpd 와 충돌관계이므로 smtpd제거하고 qmail을 설치한다. vpopmail은 사용하지 않고 직접 mysql 에 DB잡고 설정한다. 복잡하긴 되게 복잡해서 아마도 이거 설차할때 짜증 엄청 낼거란 예상이 든다. ㅋㅋ

cpufreqd, cpufreq-utils 를 설치하고 SpeedStep을 적용한다. 전기절약도 되고 불필요한 서버온도상승을 막는다. HDD도 hdparm을 통해 "-S120" 옵션으로 10분동안 사용하지 않으면 StandBy로 전환되도록 한다.

FTP 서버는 proftpd 를 사용한다. IPv6를 제대로 지원하고 다양한 설정이 가능한것이 proftpd가 사용하기 좋다. 물론 심플한 사용은 netkit-ftpd 가 있지만 이건 실험결과 아직 IPv6를 지원하지 않고 있다.

stunnel 은 설치하지 않는다. 왜냐하면 최근 버젼은 데몬 종료시에 syslog를 과도하게 채우는 쓰레기 메세지를 남긴다. init script를 stop부분만 좀 바꾸면 해결할수 있지만 안쓴다.

Cross 개발환경은 mipsel, armel, i586, i686, x86_64, ppc, sh4 를 우선 glibc, uclinc 환경으로 설치하고 추가적으로 i586의 경우 gcc 3.3.6-r1으로도 설치한다.

subversion, cvs, rcs 설치한다. subversion은 apache와 연동하지 않는다. 그냥 websvn으로 표시만 하도록 한다. cvs는 server설정은 하지 않는다.

samba는 xinetd 방식으로 설치하고 설정한다.

tftp는 netkit-tftp를 설치한다. tftp-hpa는 현재  IPv6를 지원하지 못해서 netkit-ftp를 사용한다.

telnetd는 netkit-telnet 을 설치한다. IPv6지원한다. xinetd방식은 모두 IPv6지원을 위해서 "flags = IPV6" 옵션을 추가해줘야 지원이 된다.

Raid 콘트롤러가 있지만 사용하지 않는다. 솔직히 디스크 하나 나가면 복구할수 있을지 모르지만 분명한건 내 경험상 복구할수 있는 경우는 거의 없었다.
왜냐하면 디스크에 배드섹터가 나는 문제보다 파일시스템 오류로 있는 문제가 많았고 이런 경우 Raid 미러 방식은 전혀 도움이 되지 못한다.
파일시스템이 깨지면 깨진 정보도 미러링 되버려서 아무짝에 쓸모가 없어진다. 차라리 용량을 크게 쓰고 백업을 제 3의 서버에서 rsync로 백업하는게 훨씬 안전하다.
내 경험상 RAID는 Cache목적으로 쓰는게 더 좋다. Volume으로 잡자.
대부분 예기치 않은 정전과 책임감 없는 사람에게 root 권한을 주는 경우, 그리고 thirdparty에서 제공하는 toolchain을 잘못 설치할때 파일시스템이 우리를 배신했었다. 디스크가 베드섹터가 나는 경우는 손에 꼽을정도로 드문것 같다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.