데비안 7.0 Wheezy 공식 릴리즈

오랜 개발 기간 끝에 코드네임 "Wheezy" 인 데비안 7.0 이 5월4일 공식적으로 릴리즈 되었습니다. 이번 릴리즈에 포함된 주요 기능은 저번 데비안 컨퍼런스 DebConf11 에서 소개된 "Multiarch support" 기능이 들어가 있습니다. 파일시스템상의 라이브러리와 헤더 경로를 유연하게 만들어 다른 하드웨어 아키텍쳐에서 라이브러리를 쉽게 설치할 수 있도록해줍니다.  쉽게 말하면 데비안 사용자는 같은 컴퓨터에서 여러 아키텍쳐의 패키지를 설치할 수가 있게 된 것으로 32 비트 64비트 소프트웨어도 완벽하게 동작할 수 있도록 해줍니다.  그리고 개인 클라우드 환경을 사용할 수 있도록 지원해 줍니다. 익숙하게 들었던 Saas(Software as a Service) 형태를 지원하는데, 이것을 지원하기 위하여 오픈스택(OpenStack)과 XCP(Xen Cloud Platform) 을 사용하고 있습니다.

멀티미디어 코덱도 완벽하게 지원하고 설치를 좀더 쉽게 할 수 있도록 많은 향상이 있었다고 합니다. 설치 언어도  73 개국어를 지원하고 거기다 처음으로 데비안에서는 UEFI 를 이용한 부팅을 지원합니다. 다만, 아직 "Secure Boot" 기능은 지원하지 않습니다. 제 바이오스는 이걸 지원하긴 하는데, 아쉽네요.

주요하게 설치된 패키지는 아파치 2.2.22, GCC 4.7.2, LibreOffice 3.5.4, Perl 5.14.2, Python 2.7.3, 3.2.3 , X.Org 7.7 등 36,000 개 이상의 패키지가 설치 준비가 되어 있습니다. 다만 리눅스 커널이 3.2 를 기반으로 하고 있습니다. 현재 최신 리눅스 커널이 3.9 인 것을 보면 다소 늦은 감도 있습니다. 안정성을 추구하다 보니 이런 부분은 감수해야죠 :-)

데비안 6.0 릴리즈를 2011년 초에 포스팅 했었는데, 오랜 시간이 지나 드디어 7.0을 만나보게 되었네요. 야~호 반갑다 Wheezy 야~

다운로드 : http://www.debian.org/CD/http-ftp/

[참고]
1. Debian 7.0 Wheezy released
http://www.debian.org/News/2013/20130504
2. Deploy your own cloud with Debian Wheezy
http://www.debian.org/News/2012/20120425
3. 데비안 6.0 (코드명:Squeeze) 공식 릴리즈!
http://www.packetinside.com/2011/02/60-squeeze.html

데이터 유실없이 디스크 파티션 크기 재 조정하기

몇일전에 디스크 전체를 파티션 하나로 잡고 리눅스를 설치하였습니다. 그런데 윈도우도 설치할 필요가 있어서 멀티부팅으로 해야 할 상황이 생겼습니다. 그러나 디스크는 전체가 이미 파티션으로 잡혀 있어서, 파티션 재조정을 하였습니다. (아무것도 없이 새로 설치한 것이라 다시 재 설치하면 되었지만 그게 귀챦았습니다 ^^ ) 데이터 유실 없이 간단히 할 수 있는 방법으로 Gparted 를 이용하는 것입니다. resize2fs 를 이용하기도 하나, GUI 기반으로 쉽게 이용할 수 있는 Gparted 를 추천합니다.

자리에 굴러다니는 Rescue 시디가 하나 있어서 부팅해 보았더니 gparted 가 있어서 실행하여 파티션을 Resize 시도하였습니다.

그런데 실패했습니다. 이상한 부분이 있긴 했었습니다. Ext4 파일시스템 인데 위 그림과 같이 Ext3 로 나오는 것이었습니다. 버전이 오래된 것이라 제대로 지원을 하지 않나 봅니다.

다시 Gparted 를 다운로드 받았습니다.

http://gparted.sourceforge.net/

저는 이게 ISO 부팅 으로도 파일을 지원하는지 몰랐는데, 있더군요 ^^
간단히 해당 시디로 부팅을 하고 보면 파일시스템도 Ext4 로 완벽하게 인식됩니다. 파티션 Resize 를 선택하고 용량을 줄이고 재조정을 끝냈습니다. 그리고 남은 파티션 영역쪽에 윈도우를 설치하여 멀티부팅을 할 수 있었습니다.

파티션 재조정이 필요한 경우에 gparted 를 떠올려 보세요. 윈도우 환경의 여러 도구들도 많지만, 리눅스 유저라면...

참고로, 데이터 유실이 발생할 수 도 있는 가능성이 있을수도 있으므로 백업을 받고 진행하는 것이 좋습니다. 혹시라도 모를 미연의 사태를 방지하기 위하여 ㅜㅜ

4월의 마지막 불타는 금요일 잘 보내세요 ^^

GUI 기반의 리눅스 포렌식 도구 SMART

저번 포스팅에서 Wiping 도구를 소개하였다. 오랜시간을 걸려 와이핑을 한 디스크가 정말 제대로 된 것일까 하는 궁금증이 생긴다. 찾다보니 GUI 화면의 나름 깔끔해 보이는 것이 하나 있어 테스트해 보았다. 무료는 아니지만 평가판으로 설치하여 간단하게 나마 확인하는 차원에서는 나쁘지 않을것 같다. (제품을 광고하고자 하는 것은 아니다 ^^)

ASR DATA 사의 스마트 포렌식이라는 도구를 이용하였는데, 다음 경로에서 평가판을 다운로드 받을 수 있다.

http://www.asrdata.com/forensic-software/smart-for-linux/

다운로드 받은 파일을 설치해 주면 /usr/local/SMART/ 경로가 생긴다. 여기서

# ./smart-eval 로 실행해 주면 로그인 창이 하나 나타나게 되고, 사용자 생성없이 No User 로 로그인해 사용해 보면 된다. 그러면 위와 같은 메인 화면이 나타난다. 여기서 /dev/sdb 로 연결되어 있는 80G 하드 디스크를 대상으로 할 것이다. 오른쪽을 클릭해서 디바이스 정보를 확인해 보면 기본 정보를 확인해 볼 수 있다. 디스크에서 데이터 View 기능을 누르면 위 우측 화면과 같이 기록되어 데이터가 나타난다. "aa" 로 다 기록되어 있는 것을 볼 수가 있고 처음부터 끝까지 모든 데이터는 다 이렇게 기록되어 있다. 확실하게 Wiping 이 된것 같다.

 자, 그럼 일반적인 하드 디스크의 경우는 어떨까? 운영체제가 설치되어 있는 디스크 영역으로 살펴보니 데이터들이 보인다.

 SMART 의 기능중에 하나인 검색기능을 이용해 보았다. 'network' 라는 문자열을 검색해 보았더니 상당히 많은 데이터가 검출되었다.

여기서는 앞서 소개한 Wiping 을 간단하게 확인하는 수준에서 다뤘고 데이터 뷰, 검색 기능등을 이용하여 포렌식을 하는데 이용하면 된다. 차차 리눅스 기반의 포렌식에 대해서도 다뤄볼까 한다. 참고로 해당 도구를 64비트 환경에서 실행했을때 문제가 발생하여 32비트의 가상 이미지에서 실행하였다. 64 비트 환경의 사용자 분들은 참고하길 바란다.

NetEM을 이용한 Traffic Shaping (패킷 지연,유실,대역폭 제한등)

NetEM(Network Emulation)기능을 활용한 패킷의 지연, 중복, 유실 등을 테스트해보자. 에뮬레이션은 다양한 관점에서 활용될 수 있다. 애플리케이션의 벤치마크라든지 제품의 테스트 또는 대역폭의 제한으로까지 이용할 수 있다.

NetEM 은 크게 2개의 컴포넌트로 구성되어 있다. 큐를 위한 커널 모듈과 설정을 위한 커맨드라인 도구인 tc 가 있다. 커널모듈은 2.6.8 이후부터 통합되었고, iproute2 패키지의 한 부분이다. 여기서는 Traffic Shaping 과 관련하여 소개를 해 보고자 한다. Traffic Shaping 은 네트워크 트래픽을 제한하여 자원에 대한 우선순위를 조정한다. 사전에 정의된 분류, 정책, 큐 등을 이용하여 네트워크 자원을 필요에 따라 효과적으로 정의하는 것이다. 이것을 통해 여러분들은

- 네트워크 서비스 조절
- 대역폭의 제한
- 서비스에 대한 QoS(Quality of Service) 보장

을 통해 네트워크의 안정적인 운영, 서비스 가용성등을 확보할 수도 있다.

기본적으로 큐는 FIFO 패킷 큐 형태로 동작한다. 학교 수업때 한번쯤 들어보았을 만한 이 것은 먼저 들어온 것이 먼저 나간다는 First In First Out 개념이다.

이제 몇 가지 사용 예제를 알아볼 것인데, 여러분들이 사용하는 커널이 2.6.8 이상 이라면 특별한 설치는 필요하지 않다. 아마 대부분의 경우 사용할 수 있을 것이다.

해당 기능은 커널 컴파일 옵션시 다음 그림과 같이 선택되어 있으면 된다.

예제를 설명하기 전에 주로 'tc' 커맨드 도구를 이용하여 설명을 할 것이다. tc 의 기본적인 사용방법은 아래와 같다:

 tc  qdisc [ add | change | replace | link ] dev DEV [ parent qdisc-id |

       root ] [ handle qdisc-id ] qdisc [ qdisc specific parameters ]

       tc class [ add | change | replace ] dev DEV parent qdisc-id  [  classid

       class-id ] qdisc [ qdisc specific parameters ]

       tc filter [ add | change | replace ] dev DEV [ parent qdisc-id | root ]

       protocol protocol prio priority filtertype [ filtertype specific param‐

       eters ] flowid flow-id

       tc [ FORMAT ] qdisc show [ dev DEV ]

       tc [ FORMAT ] class show dev DEV

qdisc 는 Queue Discipline (qdisc) 로 패킷을 받고 서비스하기 위한 순서를 정하기 위한 어떤 룰들의 집합이라고 보면 된다. 즉, 이것은 패킷 큐로 패킷을 전송할때 어떤 알고리즘을 사용해 패킷을 보낼지 정하는 것이다. qdisc 는 Classless, Classful, Root, egress, ingress 등이 있다. Root 는 classful/classless 랑 상관없이 각 네트워크 인터페이스의 상위 qdisc 이고 egress 는 밖으로 나가는 패킷에 대해서만 동작하고 ingress 는 내부로 들어오는 트래픽에 대해서 동작한다.

- 패킷 80ms 지연하기 

# tc qdisc add dev eth0 root netem delay 80ms

add 를 통해 dev 로 네트워크 인터페이스를 정의해 주고 qdisc 를 처리하기 위한 이름을 netem 로 지정하였다. 그리고 마지막으로 delay 를 80ms 주었다.

일단 정상적인 지연을 적용하기 전에 Ping 을 해 보았다. 평균적으로 0-1ms 속도가 나왔다. 하지만, 지연을 적용하고서는 다음과 같이 81ms 정도로 지연되었다.

# ping 203.255.xxx.xxx
PING 203.255.xxx.xxx (203.255.xxx.xxx) 56(84) bytes of data.
64 bytes from 203.255.xxx.xxx: icmp_req=1 ttl=244 time=81.0 ms
64 bytes from 203.255.xxx.xxx: icmp_req=2 ttl=244 time=81.0 ms
64 bytes from 203.255.xxx.xxx: icmp_req=3 ttl=244 time=81.2 ms
^C
--- 203.255.xxx.xxx ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 81.067/81.117/81.208/0.064 ms

- 패킷을 랜덤하게 지연시키기 (30ms ~ 80ms)

특정 값으로 정하기 보다는 지정된 범위안에서 랜덤하게 지연하는 것이다. 명령어 마지막에 추가적으로 값을 하나 더 지정해 주면 된다.

# tc qdisc change dev eth0 root netem delay 80ms 30ms
# ping 203.255.xxx.xxx
PING 203.255.xxx.xxx (203.255.xxx.xxx) 56(84) bytes of data.
64 bytes from 203.255.xxx.xxx: icmp_req=1 ttl=244 time=77.1 ms
64 bytes from 203.255.xxx.xxx: icmp_req=2 ttl=244 time=93.7 ms
64 bytes from 203.255.xxx.xxx: icmp_req=3 ttl=244 time=78.8 ms
64 bytes from 203.255.xxx.xxx: icmp_req=4 ttl=244 time=100 ms
^C
--- 203.255.xxx.xxx ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 77.131/87.483/100.138/9.756 ms

- 기존에 정의된 지연을 다른 값으로 변경

처음 add 를 사용한 것과 달리 change 라고만 바꿔주고 delay 시킬 값을 지정해 주면된다.

# tc qdisc change dev eth0 root netem delay 30ms
# ping 203.255.xxx.xxx
PING 203.255.xxx.xxx (203.255.xxx.xxx) 56(84) bytes of data.
64 bytes from 203.255.xxx.xxx: icmp_req=1 ttl=244 time=31.0 ms
64 bytes from 203.255.xxx.xxx: icmp_req=2 ttl=244 time=31.0 ms
64 bytes from 203.255.xxx.xxx: icmp_req=3 ttl=244 time=31.0 ms
^C
--- 203.255.xxx.xxx ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 31.024/31.062/31.090/0.205 ms

- 현재 정의된 네트워크 인터페이스의 설정 값 확인

# tc qdisc show dev eth0
qdisc netem 8001: root refcnt 2 limit 1000 delay 30.0ms

- 패킷 유실 15% 설정하기 

loss 라는 파리미터를 주고 값을 입력한다. 여기서는 약 15% 정도 유실을 설정하였다.

# tc qdisc change dev eth0 root netem loss 15%
# tc qdisc show dev eth0
qdisc netem 8001: root refcnt 2 limit 1000 loss 15%
# ping 203.255.xxx.xxx
PING 203.255.xxx.xxx (203.255.xxx.xxx) 56(84) bytes of data.
64 bytes from 203.255.xxx.xxx: icmp_req=1 ttl=244 time=0.935 ms
64 bytes from 203.255.xxx.xxx: icmp_req=3 ttl=244 time=1.36 ms
64 bytes from 203.255.xxx.xxx: icmp_req=4 ttl=244 time=1.10 ms
64 bytes from 203.255.xxx.xxx: icmp_req=6 ttl=244 time=1.01 ms
64 bytes from 203.255.xxx.xxx: icmp_req=7 ttl=244 time=1.00 ms
64 bytes from 203.255.xxx.xxx: icmp_req=8 ttl=244 time=1.57 ms
^C
--- 203.255.xxx.xxx ping statistics ---
8 packets transmitted, 6 received, 25% packet loss, time 7011ms
rtt min/avg/max/mdev = 0.935/1.164/1.570/0.227 ms

ping 을 해보면 패킷이 유실되는 것 같이 지연이 발생한다.
예를들어 0.1% 라면 대략 1000개중에 1개 정도가 랜덤하게 Drop 된다고 볼 수 있다.

- 패킷 중복 

# tc qdisc change dev eth0 root netem duplicate 1%

duplicate 를 이용하여 정의하면 된다.

- 패킷 깨트리기 

# tc qdisc change dev eth0 root netem corrupt 0.1%

- 정의된 설정정보 제거하기 

# tc qdisc del dev eth0 root
# tc qdisc show dev eth0
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

- 특정 IP 목적지 우선순위 조정 

203.255.xxx.xxx 로 나가는 것은 Priority 를 3으로 조정하는 것이다.

# tc qdisc add dev eth0 root handle 1: prio
# tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst 203.255.xxx.xxx/32 flowid 1:3
# tc qdisc show dev eth0
qdisc prio 1: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

- 패킷 대역폭 정의하기 

# tc qdisc add dev eth0 root handle 1:0 netem delay 100ms
# tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 256kbit buffer 1600 limit 3000
# tc -s qdisc ls dev eth0
qdisc netem 1: root refcnt 2 limit 1000 delay 100.0ms
 Sent 306774 bytes 4269 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 5p requeues 0
qdisc tbf 10: parent 1:1 rate 256000bit burst 1600b lat 43.8ms
 Sent 305784 bytes 4254 pkt (dropped 0, overlimits 3 requeues 0)
 backlog 0b 5p requeues 0

지연을 100ms 로 지정하였고, 대역폭을 256Kbit 로 설정하였다.

이상 여기까지 간단히 NetEM 을 이용한 트래픽 제어를 살펴보았다. 간단하게만 언급하였으니 세부적인 것은 Man Page 등을 살펴보길 바란다.



[참고]
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem

리눅스 3.7 커널 릴리즈: TCP Fast Open, vxLan 지원

리눅스 3.7 커널이 12월10일에 릴리즈 되었다. 이번 릴리즈는 ARM 64비트 아키텍쳐를 지원하고 서명된 커널 모듈, Btrfs 파일시스템 업데이트, strace 후의 새로운 "perf trace" 도구, 서버측면의 TCP Fast Open 기능, 안정적인 NFS 4.1 등 많은 기능이 업데이트 되었다.

눈에 띄는 변화는 ARM 멀티 플랫폼과 64 비트 지원이다. 싱글 ARM 커널 이미지로 여러 하드웨어에서 부팅이 가능해 졌다. ARM 플랫폼을 지원하도록 배포할때 더욱 쉬워지게 된 것이다.

보안적으로는 서명된 커널모듈을 지원해서, 올바르게 서명되지 않은 모듈은 커널에 로드하지 못하도록 한 것이다. 이 기능은 루트킷등을 이용해 모듈을 추가할 수 없도록 해 보안적으로도 상당히 유용한 기능이다.

네트워크 관점으로 보면 서버 측면에서 TCP Fast Open 을 지원한다. 이미 이 기능은 3.6 커널에서 추가된 것이나 이번 릴리즈는 서버측을 지원하는 것이다. TCP 연결을 맺을때 "Fast Open" 은 더욱 최적화하여 페이지 로드시 4% ~ 41% 정도 속도 향상을 가져온다. 물론 사용되는 환경마다 다르지만 말이다. 이 기능은 추후 블로그에서 다시 한번 소개할 예정이다.

또한 SMBv2 를 지원하고(시험적인 기능) NFS 4.1 이 오랜 기간을 끝내고 드디어 안정 버전으로 릴리즈 되었다. NFS 4.1 의 주 기능은 pNFS 라 하여 패러랠 NFS 을 지원한다. 이로 인해 분산된 여러 서버들 간의 파일시스템에 패러랠한 접근이 가능하다. UDP 프로토콜을 통해 레이어 2 이더넷 패킷을 전송할 수 있는 터널링 프로토콜 vxlan 을 지원한다. vxlan 은 가상화된 환경에서 터널링된 네트워크 환경을 지원하는데 주로 이용된다. VLAN 은 4096 개로 제한되었지만 이것은 24bit 로 확장되어 훨씬 많은 개수를 지원하게 된다. 이것또한 블로그에서 추후 언급할 예정이다.

마지막으로 네트워킹 관점의 변화된 주요 내용은 다음과 같다

• loopback: set default MTU to 64K (commit)
• Providing protocol type via system.sockprotoname xattr of /proc/PID/fd entries (commit)
• Use a per-task frag allocator (commit)
• Netfilter
  • Add protocol-independent NAT core (commit)
  • Add IPv6 MASQUERADE target (commit)
  • Add IPv6 NETMAP target (commit)
  • Add IPv6 REDIRECT target (commit)
  • Add IPv6 NAT support (commit)
  • Support IPv6 in FTP NAT helper (commit)
  • Support IPv6 in IRC NAT helper (commit)
  • Support IPv6 in SIP NAT helper (commit)
  • Support IPv6 in amanda NAT helper (commit)
  • Add stateless IPv6-to-IPv6 Network Prefix Translation target (commit)
  • Remove xt_NOTRACK (commit)
• Near Field Communication (NFC): Add an Link Layer Control (LLC) Core layer to HCI (commit), add an shdlc llc module to llc core(commit), LLCP raw socket support (commit)
• bonding: support for IPv6 transmit hashing (and TCP or UDP over IPv6), bringing IPv6 up to par with IPv4 support in the bonding driver (commit)
• team: add support for non-Ethernet devices (commit)
• gre: Support GRE over IPv6 (commit), add GSO support (commit), add GRO capability (commit)
• packet: Diag core and basic socket info dumping (commit)
• ethtool: support for setting MDI/MDI-X state for twisted pair wiring (commit)
• ppp: add 64-bit stats (commit)
• Add generic netlink support for tcp_metrics (commit)

[참고]
1. 리눅스 커널 3.7 릴리즈
http://kernelnewbies.org/Linux_3.7

vi 에서 ^M 문자열 지우기와 유닉스 포맷으로 변경

윈도우에서 만들어진 데이터를 가져와 *NIX 시스템에서 사용하다 보면 윈도우 캐리지 리턴 값이 들어가 있는 경우가 있다. 해당 파일을 열어 보면,

blablabla^M
blabla^M

와 같이 끝에 ^M 에 붙어 있는 것이다. 쉽게 사용할 수 있는 방법은 vi 에디터에서

:%s/^M//g

로 다 제거해 버리면 된다. 여기서 주의할 점은 ^M 이 그냥 입력하면 안되고 Ctrl + v + m 으로 입력해 주어야 한다.

이외 텍스트파일을 검색해서 사용하려고 하는데, 이상하게도 해당 데이터가 들어있는데도 불구하고 검색이 되지 않는 것이었다. vi 로 열어보니 아래와 같이 나온다.

" test-dataset.txt" [dos] 999715L, 16340756C

[dos] 라고 표시가 되고 있다. 이럴때는

:set ff=unix

로 설정하고 w 로 저장해 주면 된다.

윈도우와 *NIX 시스템 사이에 데이터를 주고 받는 과정에서 쉽게 발생될 수 있는 일이므로 알아두자.

안드로이드 폰에 리눅스(BackTrack5) 올리기

집에서 장난감 대용으로 사용하고 있는 소니에릭슨 X10 안드로이드 단말기에 리눅스를 올려보았다. 정확히 말하면 BackTrack5 를 올려 본 것이고 일단은 동작 한다. 설치는 어렵지 않게 진행할 수 있었다. 복잡한 방법으로 롬을 올리는 것이 아니라, 해당 이미지를 복사해 놓고   몇 가지 실행하는 것만으로 쉽게 된다. 그렇기 때문에 단말기에 있는 모든 파일도 그대로 유지할 수 있다. 루팅된 단말기를 가지고 있다면, 아래 참고에 적어놓은 주소를 통해서 어렵지 않게 해 볼 수 있을 것이다.

실행하면 옆 화면과 같이 BackTrack 실행화면이 나온다. 안드로이드 단말기에서 화면을 보니 나름 느낌이 다르다. 메뉴는 보는 것과 같이 여러가지 도구들이 보인다. 참고로, 이 BackTrack 이미지는 용량 이슈로 모든 것을 다 포함하고 있지는 않다.

일단 속도는 느렸다. 단말기가 오래되기도 하였고, 움직이면서 실행하는데 있어서는 끈기를 가지고 실행해야 한다 :-)

아래 화면은 패킷 스니핑을 해 본것이다. 패킷 블로그 답게 이 부분을 빼 먹어서는 안될것 같아 실행해 보았다. 블로그에서도 소개한 ettercap 을 이용한 것이다.

느려서 그렇지 일단은 실행이 된다. 단말기만 빠르다면 앞으로 이동하면서 패킷덤프를 손쉽게도 할 수 있을것이다. 자, 그럼 브라우징은 어떨까?  아래 화면과 같이 브라우징도 OK 다. 한글도 잘 표시되었고 패킷인사이드 페이지가 잘 나타난다.

이상 간략한 실행기였고 설치방법은 하단의 URL 을 참고하면 된다. 앞으로 재미있는 내용은 다시 한번 공유하도록 하겠다. :-)

[참고]
1. 소니에릭슨 X10 에서 BackTrack5 설치하기
http://forum.xda-developers.com/showthread.php?t=1074169

리눅스 패키지 포맷 다른 패키지 포맷으로 변환하기

이미지 출처: http://tenoch.scimexico.com

사용하고자 하는 프로그램이 특정 패키지로만 제공되는 경우 다른 패키지로 변환하여 설치가 가능한 방법이 있다. Alien 은 다른 리눅스 패키지 포맷 형태로 변환해 준다.

예를 들어, NMAP 의 경우 RPM 으로 패키지를 제공해 준다. 소스를 다운로드 받아 설치할 수도 있고, 기존 배포판을 이용하는 방법도 있을 수 있겠지만, 리눅스 배포판은 항상 최신의 버전을 제공하지는 못한다.
Alien 은 RPM, deb, slp, pkg, tgz 의 패키지 형식을 지원하며, 사용방법도 아주 간단하다.

데비안 계열이라면 우선 apt-get 를 이용해 쉽게 alien 을 설치할 수 있다.

#apt-get install alien

다운로드 받은 rpm 패키지를 deb 로 변경하는 경우 다음과 같이만 해 주면 된다. 옵션을 따로 지정하지 않은 이유는 deb 가 디폴트이기 때문이다.

#alien xxx.rpm

xxx.deb 가 만들어질 것이고 dpkg 를 통해 해당 패키지를 인스톨 해 주면 된다.

#dpkg -i xxx.deb

이제 패키지 포맷에 신경쓰지 말고 편하게 이용해 보자.

VMware Workstation 설치 컴파일 오류(SPIN_LOCK_UNLOCKED)

VMware 7.1.4 리눅스 버전을 설치하면서 발생하는 에러에 대해 공유하고자 한다. VMware Workstation 최신 버전은 9 이다. 그러나, 정식적으로 사용 가능한 라이센스는 7 버전을 보유하고 있기에 7.1.4 를 설치하였다. (물론, 많은 경우는 무료로 사용 가능한 VirtualBox 를 사용하지만..)

설치하는 도중에 아래 그림과 같이 Error 메시지를 출력한다.

자세한 에러 메시지를 보면

"Unable to build kernel module.
See log file /tmp/vmware-root/setup-29550.log for details"

와 같았다. 로그파일을 살펴보면 특정 파일을 컴파일 하는 과정에서 발생하는 것이고, 이것을 수동으로 컴파일 해보면 다음과 같은 과정이다.

root@:/tmp/vmware-root# /usr/bin/make -C /tmp/vmware-root/modules/vmmon-only auto-build SUPPORT_SMP=1 HEADER_DIR=/lib/modules/3.0.0-22-generic/build/include CC=/usr/bin/gcc GREP=/usr/bin/make IS_GCC_3=no VMCCVER=4.6.1
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-root/modules/vmmon-only'
make -C /lib/modules/3.0.0-22-generic/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
 MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-headers-3.0.0-22-generic'
  CC [M]  /tmp/vmware-root/modules/vmmon-only/linux/driver.o
/tmp/vmware-root/modules/vmmon-only/linux/driver.c:783:59: error: ‘SPIN_LOCK_UNLOCKED’ undeclared here (not in a function)
make[2]: *** [/tmp/vmware-root/modules/vmmon-only/linux/driver.o] Error 1
make[1]: *** [_module_/tmp/vmware-root/modules/vmmon-only] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-3.0.0-22-generic'
make: *** [vmmon.ko] Error 2
make: Leaving directory `/tmp/vmware-root/modules/vmmon-only'

SPIN_LOCK_UNLOCKED 가 선언되지 않았다고 계속 나타나는 문제였다. 관련 내용을 구글링 해보고 다음 패치파일을 찾을 수 있었다.

패치파일 다운로드 받기 : http://weltall.heliohost.org/wordpress/wp-content/uploads/2011/08/fullvmwarelinux310patch.tar.gz

패치를 실행해 보았다. 그러나 다음과 같은 메시지만 계속 출력된다.

# ./patch-modules_2.6.39.sh
Sorry, this script is only for VMWare WorkStation 7.1.5 or VMWare Player 3.1.5. Exiting

분명 패치파일에는 7.1.4 버전도 분명 명시되어 있었다. 스크립트 파일을 살펴보니

[ "$vmver" == "workstation$vmreqver2" ] && product="VMWare WorkStation"
[ "$vmver" == "player$plreqver2" ] && product="VMWare Player"

와 같이 vmreqver2 를 참고하는 변수가 있지만 실제 스크립트에는 없다. 아래와 같이 스크립트가 변경이 필요하다.

vmreqver=7.1.4
plreqver=3.1.4
vmreqver=7.1.5
plreqver=3.1.5

를 다음과 같이 변경하였다.

vmreqver=7.1.4
plreqver=3.1.4
vmreqver2=7.1.5
plreqver2=3.1.5

그리고 다시 패치 스크립트를 실행하면 깔끔하게 실행이 된다.

# ./patch-modules_2.6.39.sh
patching file vmblock-only/linux/dentry.c
patching file vmblock-only/linux/filesystem.c
patching file vmci-only/linux/driver.c
patching file vmmon-only/linux/driver.c
patching file vmmon-only/linux/hostif.c
patching file vmmon-only/linux/iommu.c
patching file vmnet-only/compat_netdevice.c
.
.
.
Built vsock module
Starting VMware services:
   VMware USB Arbitrator                                               done
   Virtual machine monitor                                             done
   Virtual machine communication interface                             done
   VM communication interface socket family                            done
   Blocking file system                                                done
   Virtual ethernet                                                    done
   Shared Memory Available                                             done


All done, you can now run VMWare WorkStation.
Modules sources backup can be found in the '/usr/lib/vmware/modules/source-workstation7.1.4-2012-10-09-15:04:41-backup' directory


자, 이제 패치가 완료되었으니 VMware 를 다시 재 설치 진행해 주면 에러 발생없이 깨끗하게 설치가 진행된다. 참고로 VMware 7.1.6.744570 버전도 해당 패치를 반영하여 사용이 가능하다. 패치 적용시 후반에 약간의 오류가 있긴 하지만 VMware 를 실행하면 커널 컴파일 하는 GUI 화면에서 제대로 진행이 계속된다.

참고로, VMWare 를 설치한 파일은 "VMware-Workstation-Full-7.1.4-385536.x86_64.bundle" 이며, 커널은 3.0.0-22 이었다. (64비트)

혹시, 같은 에러를 경험할 사용자를 위해 해결책을 공유한다.

패킷 파일 찾을때 간단하게 이렇게 해 보면 어떨까?

패킷파일을 많이 보관하고 있는 경우 find, grep 등의 명령어를 사용하여 찾고는 한다. 이럴 때 간단하게 다음과 같이 사용하여 pcap 파일을 쉽게 찾아쓰는건 어떨까?

$ fpcap() { find -maxdepth 2 -type f | grep -i "$1\.pcap"; };

fpcap 를 실행할 시 find 명령어를 이용하여 현 디렉토리에서 최대 깊이를 2단계 까지 하고 타입이 파일인 것을 대상으로 grep 을 통해 확장자가 .pcap 파일을 찾는다. 만약 인자가 주어지면 $1 이 대입된다.

인자값이 주어지지 않는 경우 확장자가 .pcap 인 것을 찾아낸다.


$ fpcap
./ppp.pcap
./packet/smtp.pcap
./http.pcap

인자값이 주어지면 해당 파일명만 보여준다.

$ fpcap smtp

./packet/smtp.pcap

여기서는 간단한 사용형태만 예로 들었지만, 사용하는 환경이 모두 다르므로 자기 업무에 맞게 이런 기본 기능들을 활용하여 적용해 보면 의외로 유용하게 사용할 수 있는 것이 많다. 비롯 간단한 명령어지만 조금이라도 수고를 덜어줄 수 있다면 유용하지 않을까 한다.

(또는 확장자를 대상으로 하지 않고 file 명령어를 통해 pcap 파일을 확인하여 사용할 수도 있을 것이다. 방법은 무한하다)

여러분들만의 유용한 도구로 상상의 나래를 펼쳐보자~

iptables 를 이용한 트래픽 복사하기

특정 인터페이스에서 발생한 트래픽을 다른쪽으로 전달하고자 할때 사용할 수 있는 방법이 있다. 스위치에서 '미러링'을 하는 것과 같은 기능을 구현할 수 있는 것으로 iptables 을 이용하고 있다면 어렵지 않게 만들어 볼 수 있다. iptables 의 모듈중 TEE 를 이용하면 간단하다. *NIX 시스템을 이용해본 사용자라면 tee 명령어에 대해서 알고 있을 것이다. tee 명령어가 수행하는 것과 같은 기능이며 아래 예제는 PREROUTING 으로 설정하고 인터페이스 eth2 에서 발생되는 tcp 프로토쿨 중 목적지가 80번인 트래픽을 192.168.0.1 로 보낸다는 것이다.

iptables -A PREROUTING -t mangle -i eth2 -p tcp --dport 80 -j TEE --gateway 192.168.0.1

그런데 실행하다보면 TEE 모듈이 없다고 아래와 같이 에러가 발생하는 경우가 있다.

iptables v1.4.8: Couldn't load target `TEE':/lib/xtables/libipt_TEE.so: cannot open shared object file: No such file or directory


Try `iptables -h' or 'iptables --help' for more information.

/lib/xtables/libipt_TEE.so 파일이 존재하지 않기 때문이다. so 파일을 찾아보면 찾아볼 수가 없다.

# ls -l *.so
-rwxr-xr-x 1 root root  8116 Jul 27 18:57 libxt_CHAOS.so
-rwxr-xr-x 1 root root  8545 Jul 27 18:57 libxt_condition.so
-rwxr-xr-x 1 root root  6833 Jul 27 18:57 libxt_DELUDE.so
-rwxr-xr-x 1 root root  9482 Jul 27 18:57 libxt_dhcpmac.so
-rwxr-xr-x 1 root root  9491 Jul 27 18:57 libxt_DHCPMAC.so

libipt_TEE.so 파일이 필요하고 이것이 /lib/xtables 경로에 있어야 한다는 뜻이 된다.

해당 so 파일을 만들어 내기 위해서는 itables 컴파일등 복잡한 과정이 필요해질 수 있다. iptables 가 기본으로 설치되어 있는 경우라면 이것을 다시 컴파일 하기 까지는 적지않은 시간이 소요될 수가 있는 것이다. 데비안, 우분투와 같은 패키지 사용자라면 다음과 같이 쉽게 사용해 볼 수 있다.

우선 xtables 패키지를 검색해 보자.

# apt-cache search xtables
iptables-dev - iptables development files
xtables-addons-common - Extensions targets and matches for iptables [tools, libs]
xtables-addons-source - Extensions targets and matches for iptables [modules sources]

xtables-addons 에 관련 모듈이 들어 있는데, 패키지로 찾을 수가 있다. 소스파일이 보이니 이것을 컴파일 해주면 되는 것이다.

# apt-get install xtables-addons-common xtables-addons-source

로 설치해 주면 /usr/src 밑에 xtables-addons.tar.bz2 파일이 생성되게 된다. 그런데 이 소스를 가지고 어떻게 해 주어야 하는 것인가?

데비안의 경우 module-assistant 를 이용하면 쉽게 컴파일이 가능하다. 크게 다음과 같은 순서로 설치가 가능해진다.

# apt-get install module-assistant 
# ./module-assistant prepare
# ./module-assistant auto-install xtables-addons-source

module-assistant 를 이용하여 build 를 할 수 있고 module-assistant 를 설명을 보면 아래와 같다. 사용가능한 옵션들이 보이는데, build 는 컴파일을 수행하는 것이고 install 은 설치 purge 는 삭제다.

NAME
       module-assistant - manage kernel modules packages

SYNOPSIS
       module-assistant  [  -fihnqstv  ]  [ -k source/headers directory ] [ -l
       kernel versions ] { update | search | prepare | auto-install |  list  |
       list-available | list-installed | auto-unpacked | get | build | install
       | clean | purge | fakesource } [ pkg ... ]

       m-a ...

위 예에서는 auto-install 을 통해 한번에 자동으로 설치되는 것을 예로 들었는데, 직접 build 만을 하기 위해서는  " m-a build xtables-addons-source " 와 같이 사용하면 된다. module-assistant 가 길기 때문에 'm-a' 로 줄여서 사용할 수 있다.

실행하게 되면 /usr/src 에 존재하는 xtables-addons 소스를 확인하고 압축해제후 컴파일을  수행한다. 완료되면 deb 패키지로 만들어 주게되는데, 수동으로 이 deb 패키지를 설치하면 된다. dpkg -i 패키지명.deb 와 같이 말이다.

# m-a build xtables-addons-source
Extracting the package tarball, /usr/src/xtables-addons.tar.bz2, please wait...
Done with /usr/src/xtables-addons-modules-2.6.32-5-amd64_1.26-2+2.6.32-45_amd64.deb .

auto-install 은 컴파일과 설치까지 한번에 다 진행하게 되는데, 만약 이런 과정에 문제가 있을시에 각 단계를 따로 진행하면서 문제의 원인을 파악해 볼 수 있다. 더불어
텍스트 모드로드 실행할 수 있는데 -t 옵션을 사용하면 된다.

# m-a -t  build xtables-addons-source
Extracting the package tarball, /usr/src/xtables-addons.tar.bz2, please wait...
dh_testdir
/usr/bin/make -C /lib/modules/2.6.32-5-amd64/build M=/usr/src/modules/xtables-addons XA_ABSTOPSRCDIR=/usr/src/modules/xtables-addons clean
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-5-amd64'
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-5-amd64'
dh_clean

-t 옵션은 텍스트로 설치과정을 세세하게 보여주므로 어디서 문제가 발생하는지 쉽게찾을 수 있다. 만약 제거를 한다면 아래와 같이 사용하면 된다.

# m-a purge --force xtables-addons-source

이외 m-a 를 그냥 실행하면 아래와 같이 interactive 화면을 볼 수 있으며, overview 를 통해서 사용가능한 명령어들을 세부적으로 확인할 수 있다.

그런에 위와 같이 설치가 완료되더라도 so 파일이 존재하지 않는다고 나타난다. 커널 모듈 형태로 컴파일이 되었기 때문에 *.ko 와 같은 파일을 대신 볼 수 있을 것이다. iptables 가 설치된 환경이 다르지만 나의 경우는 so 파일이 필요하였기에 다음과 같이 컴파일을 수행했다.

/usr/src/modules/xtables-addons 경로로 이동 후 아래와 같이 실행한다.

# /usr/bin/make -f Makefile.iptrules M=/usr/src/modules/xtables-addons XA_TOPSRCDIR=/usr/src/modules/xtables-addons XA_SRCDIR=/usr/src/modules/xtables-addons
  CC     libxt_CHAOS.oo
  CCLD   libxt_CHAOS.so
  CC     libxt_DELUDE.oo
  CCLD   libxt_DELUDE.so

그러면 .so 파일이 만들어지는 것을 볼 수 있을 것이다. 그럼 이것을 경로에다 복사해 넣어주면 OK 다. iptables 를 이용한 설정은 간단하였는데, 오히려 libipt_TEE 를 사용하기 위해서 기술한 내용이 많았다. iptables 뿐만 아니라 다른 부분에서도 유용할 수 있으니 알아두면 유익할 것이다. :-)

여러개의 네트워크 인터페이스를 하나로! Bonding 하기

오늘은 bonding 기술에 대해서 다뤄보고자 한다. 이것은 여러개의 네트워크 인터페이스를 하나로 만들어 이더넷 카드 장애 또는 링크 Fail 에 대해 대비를 할 수 있다. 또한 로드발랜스를 구현할 수 있으며, 자연스럽게 Fault tolerance 를 보장해주어 고장 허용한계를 최소화 할 수도 있겠다.  스위치 장비 같은것에서 보면 "채널본딩", "트렁킹" 같은 기술들이 이와 이론적으로는 유사하다고 할 수 있다.

여기서는 리눅스를 기반으로 설정하는 방법을 다뤄볼 것이다. 대부분의 배포용 리눅스에는 이미 본딩 드라이버를 이용할 수 있다. 가장 쉽게 설치해 볼 수 있는 방법은 각 배포판에서 제공해주는 패키지 도구를 이용하면 된다. 데비안, 우분투의 경우는 apt-get 를 이용해 설치할 수 있다.

# apt-cache search ifenslave
ifenslave-2.6 - Attach and detach slave interfaces to a bonding device
# apt-get install ifenslave-2.6

설치가 되었으면, bonding 모듈이 올라가 있는 것을 확인할 수 있다.

# lsmod | grep bon
bonding                73991  0

Bonding 인터페이스 설정 

이제 사용할 준비는 되었으니 설정만 해 주면 된다. 수동으로 명령어를 통해 다음과 같은 형태로 잡아줄 수도 있으나,

# modprobe bonding
# ifconfig bond0 192.168.0.1 netmask 255.255.0.0
# ifenslave bond0 eth0 eth1

아래와 같은 방법을 통해 설정파일에 내용을 기록해 두고 사용하는 편이 훨씬 수월하다. bond0 라는 이름이 이제 우리가 설정할 bonding 인터페이스이다.

# cat /etc/network/interface
auto bond0
iface bond0 inet static
 address 192.168.0.1
 netmask 255.255.255.0
 gateway 192.168.0.254
 bond_mode balance-tlb
 bond_miimon 100
 bond_downdelay 200
 bond_updelay 200
 slaves eth0 eth1

위 내용중에서 아래 5라인 정도가 실제 bonding 과 관련된 내용이다. 인터페이스 bond0 에 192.168.0.1 IP 를 설정하고 동작모드로 balance-tlb 를 설정하였다. 이 모드는 Active slave 모드로 슬레이브로 설정된 인터페이스에서 들어오는 트래픽을 받는다.
bond-miimon 은 링크 모니터링 주기를 설정하는 것으로 100 밀리세컨드로 지정하였다.
bond-downdelay 는 링크 Fail 이 감지된 후 Slave 를 중지시키기전 대기할 시간을 정의한 것이다. bond-updelay 는 downdelay 와 반대로 링크가 복구된 후 slave 를 재 동작하기까지 대기할 시간이다.  그리고 마지막으로 slaves 를 통해 실제 본딩에 사용될 인터페이스 eth0 과 eth1 을 지정했다.

커널상에서는 가상의 bond0 를 통해 통신되며 실제 모든 통신은 slave 를 통해서 이뤄진다는 점이다.

bond-mode 는 다양하게 존재하는데 몇 가지를 알아보면 다음과 같다.

•  balance-rr 

전달되는 패킷에 대해 sequential 하게 라운드로빈 형태로 동작하게 된다. 설정된 인터페이스로 나눠 전달되므로 로드 발랜싱 역할을 하게 된다.

• active-backup

본딩 인터페이스중 오직 한개 슬레이브만 엑티브로 동작한다. Active 로 동작하는 슬레이브가 Fail 되면 다른 슬레이브가 대체하게 된다. Fault Tolerance 형태로 보면 된다.

• balance-xor

선택된 해쉬 정책에 따라 트래픽이 전달된다. (기본 정책은 출발지 맥 주소와 목적지 맥 주소를 XOR 한다)

• broadcast

모든 슬레이브 인터페이스로 전송한다

•  balance-tlb

적절하게 로드 발랜싱 역할을 수행한다. Outbound 트래픽은 각 슬래이브의 로드를 고려해 분산되며, Incoming 트래픽은 현재 설정된 슬레이브로 받게 된다. 만약 트래픽을 받고 있는 슬레이브가 Fail 되면 다른 슬레이브가 MAC 주소를 이어받아 계속 트래픽을 전달 받을 수 있다.

• balance-alb

적절하게 로드 발랜싱 역할을 수행한다는 측면에서 balance-tlb 와 같다. 그런데 여기에 추가로 트래픽을 받는 부분에 있어서도 로드발랜싱을 수행한다. 이것은 ARP negotiation 을 통해서 동작하게 된다.

Bonding 이 잘 동작하고 있는지의 확인은 ?

내가 설정한 Bonding 이 잘 동작하고 있는지 확인하려면 간단하게는 /proc/net/bonding/bond0 를 살펴보면 된다. 그러면 현재 설정된 정보를 볼 수 있는데, Bonding mode 는 transmit load balancing 으로 되어 있고 Up Delay 나 Down Delay 등이 위 설정파일에 설정한 것과 동일하게 정의되어 있다.

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)


Bonding Mode: transmit load balancing
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200


Slave Interface: eth0
MII Status: up
Link Failure Count: 1
Permanent HW addr: 84:XX:XX:XX:10:1c


Slave Interface: eth1
MII Status: up
Link Failure Count: 1
Permanent HW addr: 84:XX:XX:XX:10:1e

또는 ifconfig 를 통해 설정한 bonding 인터페이스인 bond0 가 있는지 확인해 볼 수도 있다.


bond0     Link encap:Ethernet  HWaddr 84:XX:XX:XX:10:1c
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::862b:2bff:fefa:101c/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:64861 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2542 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4984737 (4.7 MiB)  TX bytes:176928 (172.7 KiB)

eth0      Link encap:Ethernet  HWaddr 84:XX:XX:XX:10:1c
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:32694 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1278 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2510260 (2.3 MiB)  TX bytes:90488 (88.3 KiB)
          Interrupt:36 Memory:d6000000-d6012800

eth1      Link encap:Ethernet  HWaddr 84:XX:XX:XX:10:1e
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:32167 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1264 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2474477 (2.3 MiB)  TX bytes:86440 (84.4 KiB)
          Interrupt:48 Memory:d8000000-d8012800


여기 인터페이스 정보를 보면 우선 설정한 bond0 가 보이고 그 아래 eth0, eth1 은 RUNNING SLAVE 로 동작하는 것이 보인다. eth0 은 맥 뒷자리가 10:1c 이고 eth1 은 10:1e 이다. bond0 를 보면 10:1c 로 되어 있다. 즉 현 시점에서 Active Slave 는 eth0 이 되는 것이다.

만약 eth0 인터페이스의 링크가 Fail 되면 eth1 이 맥 주소를 넘겨받아 10:1e 가 아닌 10:1c 상태가 되어 버린다. 이것은 bonding 을 구성후 랜 케이블을 뽑아보면 쉽게 살펴볼 수 있다.

링크 Fail 을 감지한다면?

링크 Fail 을 감지하면 앞서 설명한 것과 맥 주소를 넘겨받는 다고 하였는데, 이런 동작 과정이 /var/log/message 에 상세히 기록되어 있다.


Jul  6 00:18:36 test kernel: [    4.227038] bonding: bond0: Setting down delay to 200.
Jul  6 00:18:36 test kernel: [    4.233007] bonding: bond0: doing slave updates when interface is down.
Jul  6 00:18:36 test kernel: [    4.233012] bonding: bond0: Adding slave eth0.
Jul  6 00:18:36 test kernel: [    4.233014] bonding bond0: master_dev is not up in bond_enslave
Jul  6 00:18:36 test kernel: [    4.335328] bnx2: eth0: using MSIX
Jul  6 00:18:36 test kernel: [    4.337600] bonding: bond0: enslaving eth0 as an active interface with a down link.
Jul  6 00:18:36 test kernel: [    4.380870] bonding: bond0: doing slave updates when interface is down.
Jul  6 00:18:36 test kernel: [    4.380875] bonding: bond0: Adding slave eth1.
Jul  6 00:18:36 test kernel: [    4.380878] bonding bond0: master_dev is not up in bond_enslave
Jul  6 00:18:36 test kernel: [    4.463151] bnx2: eth1: using MSIX
Jul  6 00:18:36 test kernel: [    4.465304] bonding: bond0: enslaving eth1 as an active interface with a down link.
Jul  6 00:18:36 test kernel: [    4.470976] ADDRCONF(NETDEV_UP): bond0: link is not ready
Jul  6 00:18:38 test kernel: [    7.540376] bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex
Jul  6 00:18:38 test kernel: [    7.560033] bonding: bond0: link status up for interface eth0, enabling it in 0 ms.
Jul  6 00:18:38 test kernel: [    7.560037] bonding: bond0: link status definitely up for interface eth0.
Jul  6 00:18:38 test kernel: [    7.560041] bonding: bond0: making interface eth0 the new active one.
Jul  6 00:18:38 test kernel: [    7.560065] bonding: bond0: first active interface up!
Jul  6 00:18:38 test kernel: [    7.562122] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
Jul  6 00:18:39 test kernel: [    7.668144] bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex
Jul  6 00:18:39 test kernel: [    7.759691] bonding: bond0: link status up for interface eth1, enabling it in 200 ms.
Jul  6 00:18:39 test kernel: [    7.959351] bonding: bond0: link status definitely up for interface eth1.

위 로그를 보면 알 수 있듯이 eth0 링크가 문제 생기면서 eth1 으로 slave 가 변경되는 과정을 알 수 있다.

Bonding 구성을 완료후에는, 정상적으로 잘 동작하는지 랜 케이블 선을 제거해 보는 것과 같이 테스트 과정을 거치는 것이 필요하다. 최근의 서버급 장비들은 하나의 랜 카드에 4개의 이더넷 포트가 달려 있는 경우도 많이 있다. 시스템의 사용용도에 따라 이와 같이 설정해 사용해 보는 것은 어떨까 한다.

실제로 사용해 보면 아주 간단하고도 쉽게 구성할 수가 있다.

[참고]
1. 리눅스 파운데이션 : bonding
http://www.linuxfoundation.org/collaborate/workgroups/networking/bonding

*NIX 콘솔 기반 네트워크 사용량 표시 도구 - nload

현재 네트워크 사용량을 표시해주는 nload 를 소개한다. 사실 너무나도 많은 도구들이 있는데, 그래도 이런 형태의 도구는 있다고 알아두면 좋기 때문에 이름만은 기억해 두자. 'nload' 는 콘솔 기반의 프로그램으로 실시간으로 네트워크 상태를 표시해 준다. 아스키 형태의 그래프로도 말이다.

크게 Incoming/Outgoing 으로 화면이 나뉘어져 있으며 옵션은 다음과 같다.

nload  [-a period] [-i max_scaling] [-m] [-o max_scaling] [-t interval]

       [-u h|H|b|B|k|K|m|M|g|G] [-U h|H|b|B|k|K|m|M|g|G] [devices]

디바이스가 여러개 있는 경우 -m 으로 한번에 표시할 수 있으며, -t 로 화면의 Refresh 시간을 지정할 수 있다. 기본 값은 500 밀리세컨드 이다. 참고로 만약 100 밀리세컨드 이하로 값을 지정하면 빈번하게 계산해야 하기 때문에 부정확해 질 수도 있다는 점은 알아두길 바란다.

-u 로 트래픽 수치 표현 방법을 지정할 수 있다. 비트, 킬로비트, 메가 비트등의 옵션이 있다.

F2 키를 누르면 옵션 화면이 나타나서 설정 값등을 볼 수 있으며, 이동키를 통해 움직일 수도 있다.

다운로드는 다음 경로에서 가능하다

http://www.roland-riegel.de/nload/

데비안 계열 사용자는 apg-get install nload 로 쉽게 설치할 수 있다.

Screen 기능을 이용해 터미널 화면 Clone 하기!

*NIX 시스템에서 유용한 도구중에 하나가 screen 이라는 것이다. 요새야 워낙 사용하는 모니터 사이즈가 커져서 활용하는 비율이 조금 떨어지긴 하나, 터미널 환경에서 아주 강력하게 사용할 수 있는 도구였다. 터미널 창에서 화면을 반으로 가르거나 여러개의 세션을 생성해서 자유롭게 이동하거나 많은 기능이 있다. 여러 기능중에서 screen 세션 하나를 그대로 Clone 하여 사용할 수 있는 방법을 공유한다.

과연 이렇게 쓰일 일이 머가 있을까 하였는데, 이 기능이 필요할 때가 바로 발표와 같은 특정 환경에서는 필요하였다. Multi Display 를 사용할 경우, 발표자의 노트북을 보면서 쉽게 시연을 보여줄 수 있다. 물론, 전체 화면을 그대로 Clone 할 수도 있지만, 터미널 환경만 보여준다면 이 방법이 유용하다.

일단 screen 를 통해 세션 생성시 세션의 이름을 지정해 준다.

세션 이름 지정은

# screen -S sessionname 으로 할 수 있다.

예로 test, test2 라는 세션 두개를 생성하였다. 그리고 -ls 옵션을 통해 현재 활성화 되어 있는 세션을 확인할 수 있다.

# screen -ls
There are screens on:
        2585.test       (12/03/2011 09:40:52 PM)        (Attached)
        2568.test2      (12/03/2011 09:38:34 PM)        (Attached)
2 Sockets in /var/run/screen/S-root.

그리고 내가 연결하고자 하는 세션이 test 라면 다음과 같이 연결할 수 있다. 새로운 터미널 창을 하나 띄우고 -x 옵션을 통해서 말이다.

# screen -r 2585.test -x

이와 같이 하면 터미널이 그대로 복제된다. 즉 내가 치는 내용이 그대로 나타난다. 그렇다면 창 하나를 모니터 다른 화면으로 넘겨서 보여줄 수가 있다.

막상 이 기능이 발표할 때 필요하였는데, 유용하게 사용하였다. Screen 의 Clone 기능, 어디다 쓸 수 있을까 하였지만 역시나 필요한 곳은 있다.

가장 빠른 파일시스템은 무엇일까?

시스템을 구성하면서 여러가지 고려사항이 많겠지만, 요즘같이 크게 늘어나는 데이터 용량을 커버하기 위해서는 파일시스템 선택도 중요해진다. 파일시스템에 따라 성능상의 차이도 발생하고, 최대 파일크기, 볼륨 사이즈도 달라진다.

일반적으로 1U 시스템에서 사용되는 1~6 개 정도의 디스크 크기는 운영하는데 있어 큰 문제가 발생하지 않을 수 있지만, 스토리지를 연결하여 수십 테라 규모의 디스크가 된다면 고려해야 될 사항들이 많아진다. 볼륨 크기로 인한 파일시스템 선택도 필요하고, RAID 구성등 하드웨어적인 이슈도 많이 따른다.  보통 운영하고자 하는 목적에 맞게 올바른 파일시스템이 선택되기 보단 대중적인 형태로 그냥 선택되는 경우가 많다. RAID 구성, 파일시스템, 스트라이핑 사이즈 등등이 그냥 운영체제 또는 하드웨어 기본 값을 사용하는 경우가 대부분이다.

이 부분에 대해서는 더 하고 싶은 이야기가 많지만, 오늘은 파일시스템을 잘 비교해 놓은 글이 있어서 공유해 보고자 한다. 가장 빠른 파일시스템이 어떤것인가 하는 것이다. 사용된 파일시스템은 btrfs, ext2, ext3, ext4, JFS, ReiserFS, XFS 이다. 이중에서 대중적으로 많이 사용되는 것은 ext3 일 것이다. 그리고, 큰 규모의 스토리지 라면 보통 XFS 가 많이 사용되는 것 같다. 다음 그래프는 20 개의 스레드를 이용해 테스트를 한 것인데, XFS 가 가장 좋은 성능을 보여줬다. ext4 도 전반적으로는 높은 수치를 보여주었고, JFS 가 가장 낮은 점수이다. (FS Relative throughput 에 한해서)


[출처] Finding the Fastest Filesystem, 2011 Edition 블로그 글

물론, 이것은 어디까지나 참고자료이다. 테스트 형태에 따라서도 달라지므로, 실제 운영하고자 하는 목적에 따라 테스트 하여 선택하는 것이 가장 좋을것이다.  세부적인 내용은 아래 링크를 통해서 확인할 수 있다.

http://mindplusplus.wordpress.com/2011/02/02/finding-the-fastest-filesystem-2011-edition/

결론에서는 어느것이 가장 좋은 것인지 추천하지 않았고, 여러 설정에 따라 달라질 수 있는 만큼 테스트용 스트립트를 포함했다고 하니 필요한 분들은 받아서 해보기 바란다.  항상 선택하던 기본이 아닌 여러분들 시스템에 가장 최적이라고 판단되는 것을 선택하는데 도움이 될까하여 공유한다. 생각보단 꽤 많은 파일시스템이 있다는 것을 잊지말자.

큰 규모의 스토리지를 구성하면서 얻은 파일시스템에 대한 경험이 있으신 분들은 댓글로 함께 경험을 공유해 주었으면 한다.

[참고]
1. 파일시스템 비교
http://en.wikipedia.org/wiki/Comparison_of_file_systems
2. Finding the Fastest Filesystem
http://mindplusplus.wordpress.com/2008/07/14/finding-the-fas/
3. The best Linux file system of all?
http://blogs.computerworld.com/15413/the_best_linux_file_system_of_all

리눅스 GUI 기반에 뿌리를 둔 패킷생성기 packETH, 하지만 윈도우도 OK

패킷생성기 하나를 소개한다. 이번에는 리눅스 GUI 기반의 생성기로 이름은 packETH 이다. 이더넷 패킷을 생성하고 전송할 수 있는 기본적인 기능과 몇가지 유용한 기능들이 포함되어 있다. 참고로, 윈도우에서도 사용가능하도록 포팅되어 있다.


다운로드는 다음의 경로에서 할 수 있다.

[리눅스]
http://packeth.sourceforge.net/
[윈도우]
http://eth.cyberine.com/

일단 기본적인 기능을 좀더 알아보면 아래와 같다:

- 다양한 프로토콜을 지원해 이더넷 패킷을 생성, 편집, 전송 할 수 있다.
- Ethernet II, Ethernet 802.3, 802.1q
- ARP, IPv4, IPv6, 사용자 정의 페이로드
- UDP, TCP,ICMP,IGMP, 사용자 정의 레이어 페이로드 등이다.
- 패킷 연속 전송 기능 (최대 속도, 패킷간 Delay, 전송할 패킷 수 등)

현재 2010년10월 업데이트가 최신이며 버전은 1.7 이다. 설명서는 충분치 않은데, 한번 사용해 보면 어느정도 감을 잡을 수 있다. 메인 화면은 아래와 같다.



메뉴 아이콘을 보면 Builder 가 보인다. 기본 생성 도구로서 여기는 각 레이어별 생성을 할 수 있도록 지원한다.
- 링크레이어
- 네트워크 레이어 (IPv4 or IPv6 데이터)
- 트랜스포트 레이어 (TCP, UDP or )

원하는 값을 지정하고, Send 버튼을 누르면 전송이 쉽게 된다. 그 다음 Gen-b 아이콘은 전송할 패킷 수, 패킷간 딜레이 등을 지정하여 대량으로 전송할 때 사용할 수 있다. Gen-s 는 다른데서는 못 보던 기능인데, 유용할 수도 있다고 본다. 패킷 파일을 여러개 지정하여 연속적으로 전송할 수 있는 기능이다. 각 패킷에 대해서 전송 개수, 딜레이, 전송속도를 조정할 수가 있다. Pcap 을 로드한 PCAP 데이터 리스트를 보고 선택할 수 있도록 해준다. Load 아이콘을 통해 읽어들일 PCAP 을 지정하면 Pcap 리스트에 나타난다. 여기서 더블클릭하여 선택하고, Builder 를 보면 해당 데이터를 볼 수 있다. 즉, 특정 패킷파일의 데이터를 Builder 에서 다시 재조정하여 보낼 수 있는 것이다.



리눅스 기반에서 패킷생성이 많은 사용자라면 이 도구가 도움이 될 것이다. 참고로 윈도우로 포팅된 것도 리눅스와 같은 형태의 UI 를 가지고 있다.

*NIX 명령어 옵션 하나의 큰 차이 그리고 잊고 지냈던 옵션들...

여러분들이 항상 사용하는 명령어들에는, 각자 사용하는 스타일이 분명 하나씩 있다.
그것이 의식적이든 의식적이지 않던, 나도 모르게 오랜 세월동안 자주 사용하는 명령어 스타일 말이다. 예를들어, ls 명령어를 사용한다고 했을때 어떤 사람들은 그냥 ls 를 치기도 하지만, 또 다른 사람은 ls -l 또는 ls -al 등으로 다양하게 있을 것이다.

항상 익숙하게 사용하던 이 명령어 옵션도 알고 보면 시간이 지나면서 새로운 기능들이 추가되거나 또는 이미 있지만 모르고 사용하지 못했던 것들도 있다. 항상 많이 쓰는 명령어 이면서도 사용하던 옵션만 주로 사용하는 경우가 많다. 알고보면 좋은 기능이 숨어 있음에도 불구하고 말이다.

최근에는 가끔 항상 사용하던 명령어라도 한번씩은 man 페이지 또는 --help 옵션으로 무엇이 있는지 살펴본다. 그러다 아, 이런 것들이 있었네 하는 것이 있다. 너무 익숙한 명령어 이다 보니 오히려 모르고 지나치는 것이다. 예를 들어, grep 명령어는 단순히 문자열을 찾기 위해서 사용했는데, 때로는 탐지한 문자열 패턴 위, 아래 영역을 더 보고 싶을때가 있다. 이때는  -A, -B 옵션이 유용하다. -A 는 after, -B 는 before 뜻으로 탐지된 패턴의 앞뒤로 얼마 라인만큼 더 볼지 지정할 수 있는 것이다. 항상 그렇게 많이 사용하는 명령어 이면서 미처 모르고 지나쳤던 것이다.

또, netstat 는 주로 -na, -nr 만 주로 사용했는데, -p 는 해당 소켓을 사용하고 있는 프로세스를 알려준다.   다른 예로, 속도 차이를 가져오는 경우의 Case 도 있다.  한 디렉토리 안에 파일이 약 9만 4천개가 있었다. 여기서 파일 이름중에 FAIL 이라는 것이 있는 것을 찾기 위해 ls 를 사용하였다.

# time ls -1 | grep FAIL | wc -l
1428

real 0m3.337s
user 0m0.980s
sys 0m0.608s

# time ls -l | grep FAIL | wc -l
1428

real 0m39.320s
user 0m2.076s
sys 0m7.472s

위 차이를 보면 3초와 39 초로 차이가 크게 나타난다. 얼핏보면 비슷해 보이는 명령어 옵션인데 말이다. 한개는 숫자 1 을 사용한 것이고 다른 하나는 많이 사용하는 영문 l 을 사용한 것이다. 숫자 1은 파일이름만 출력하지만, 영문 l 은 파일소유주,날짜 등 좀더 많은 정보를 보여준다. 그래서 이렇게 파일이 많이 있는 경우에는 리스트 출력할때 차이가 발생하는 것이다. 사용하는 목적에 따라 다르지만, 조금만 생각해 보면 다른 결과를 가져오는 것이다.

항상 내가 똑같이 사용하던 방식에 너무 익숙해져 있다면, 한번 이런 명령어들을 다시 돌아보는 것도 좋을것 같다. 여러분이 사용하던 쉘 스크립트, 명령어들이 정말 최선의 선택인지. :-)

From Rigel.

*NIX 에서 서브넷(Subnet) 계산을 쉽게 해 보자!

초기 네트워크 설정 과정중에 서브넷을 계산해 넣는경우가 있다. 네트워크 서브넷을 계산하는 가장 쉬운 방법은
- 인터넷에서 바로 제공하는 온라인 서브넷 계산기
- 윈도우용 서브넷 계산기 프로그램 등이 있다.

자주 계산이 필요한 경우라면 윈도우용과 같은 프로그램이 설치되어 있으면 편리하다. 이런 서브넷 계산기는 인터넷에서 조금만 검색해보면 너무나 많은 도구들이 있기 때문에 따로 언급은 안하겠다. 나의 경우는 가끔씩 필요한 경우라, 인터넷상의 온라인 계산기를 주로 이용했는데, 리눅스 상에서 계산해볼 생각은 하지 않았다. 그러나, 콘솔 기반으로 간단하면서도 쉽고 빠르게 계산할 수 있는 도구들이 있다.

여기서는 subnetcalc 라는 것을 이용하였는데, 다음의 경로에서 파일을 받을 수 있다.
http://www.iem.uni-due.de/~dreibh/subnetcalc

또는 apt-get install subnetcalc 로 쉽게 설치도 가능하다. 사용법도 간단해서 아래 화면과 같이 계산할 네트워크 주소와 넷 마스크 또는 Prefix 값을 넣어주면 된다.

그러면 사용가능한 호스트 갯수부터 하여 필요한 정보를 나열해 준다. 리눅스를 주로 사용하면서 서브넷 계산이 많은 분들한테는 유용하게 사용될 수 있을 것이다. MAN 페이지에 있는 몇 가지 예제를 써 보면 아래와 같다:

subnetcalc 132.252.250.0 255.255.255.0

subnetcalc 132.252.250.0/255.255.255.0

subnetcalc 132.252.250.0 24

subnetcalc 132.252.250.0/24

subnetcalc fec0:2345:6789:1111:221:6aff:fe0b:2674 56

subnetcalc 2a00:1450:8007::69 64

subnetcalc ff08::1:2:3

subnetcalc 131.220.6.5/24

브라우저에서 동작하는 자바스크립트 리눅스

재미있는 것을 하나 소개하고자 한다. 그것은 바로 브라우저에서 동작하는 리눅스이다.
일단, 몇 마디 보다도 직접 사이트를 방문해서 사용해 보는 것이 가장 좋을 것이다. 사이트는
http://bellard.org/jslinux/ 이며, 동작하게 되면 아래와 같은 화면을 볼 수 있다.

리눅스 부팅되는 화면을 볼 수 있으며, 램디스크가 설정되고 Welcome to JS/Linux 을 볼 수 있다. 커서가 깜빡이며 명령어를 사용할 수 있으며, 사용된 커널은 2.6.20 이다.

~ # uname -a                                                                  
Linux (none) 2.6.20 #3 Sat May 14 19:08:30 CEST 2011 i586 GNU/Linux            
~ # df -k                                                                      
Filesystem           1K-blocks      Used Available Use% Mounted on            
/dev/root                 2011      1467       442  77% /                      
tmpfs                    15224         0     15224   0% /tmp                  
~ #                                                                            
~ #      

이 모든 것이 자바스크립트로 구현되었다는 것이 놀라울 따름이다. 이것을 사용하기 위해서는
파이워폭스 4, 구글 크롬 11 버전이 필요하다.

자바스크립트 리눅스에서 컴파일도 가능한데 살펴보면 아래와 같다.
                                               
~ # ls                                                                        
hello.c                                                                        
~ #                                                                            
~ # ls                                                                        
hello.c                                                                        
~ # tcc hello.c                                                                
~ # ls -l                                                                      
total 4                                                                        
-rwxr-xr-x    1 root     root          1940 May 18 13:51 a.out                
-rw-r--r--    1 root     root           214 May 18 13:51 hello.c              
~ # ./a.out                                                                    
Hello PacketInside                                                            
http://packetinside.com                                                        
~ #                    

리눅스가 브라우저 안으로까지 들어왔다는 놀라운 사실. 그렇다면 이게 뜻하는 것은 무엇일까?
앞으로 계속 발전되면 더욱 다양한 것들이 동작할 수 있게 될 것이고, 브라우저만 있으면
많은 것들을 할 수 있게 된다. 다만, 아직 아쉬운 것은 네트워크 관련한 부분은 가능하지 않다.
네트워크 인터페이스가 없기 때문이다. 설마 이 안에서 네트워크 패킷 덤프까지 가능해진다면 ? 그건 상상에 맡기고, 한번 사용해 보기 바란다.

P.S TOP 명령어도 사용가능하다. 이렇게 동작하는거 보면 진짜 동작하는게 맞다 :-)

[참고]
1. 자바스크립트 리눅스 기술적 배경
http://bellard.org/jslinux/tech.html        
2. JavaScript: Linux in a browser 기사
http://us.generation-nt.com/emulator-linux-javascript-bellard-news-2922501.html          

리눅스 20주년을 정말 축하해요 ^.^

리눅스가 올해로 20주년을 맞이했다. 리눅스 파운데이션은 이와 관련 다양한 행사도 준비하고 있다. 예를 들면, 비디오 컨테스트로 누구나 응모할 수 있다. 당첨자는 벤쿠버에서 열리는 LinuxCon 에서 발표된다.
아래 이미지는 리눅스 20년간의 주요한 내용을 담아 정리된 것이다.

1991년은 Linux Torvalds 가 포스팅 한 메시지 "Hello Everybody Out there..." 와 함게 처음으로 리눅스 코드를 배포한 해이다. 1993년에는 슬랙웨어가 주요 배포판으로 퍼져나갔는데, 나 또한 그 당시의 슬랙웨어를 기억한다. 배포되는 리눅스 중에서는 슬랙웨어가 유명했었다. 1996년에는 Linus 가 아쿠아리움에 방문하면서 리눅스의 마스코트로 펭귄을 선택했다는 사실. 1999년은 레드햇이 퍼블릭하게 배포되었으며, 2010년은 리눅스 기반의 안드로이드가 나타난다.

리눅스 20주년을 정말 축하하며, 앞으로 펭귄의 활약을 더 기대해 보고 싶다. :-)

[참고]
1. 리눅스파운데이션
http://www.linuxfoundation.org/20th/