'IT/Linux'에 해당되는 글 90건

데비안 계열 리눅스에서 /etc/rc.local 파일에 고칠 부분이 있어서 고쳤는데, 막상 재부팅을 하기는 싫고 그냥 rc.local에서 수정된 부분만 적용하는 방법이 없는지 잠깐 고민을 했는데, 부질없는 짓이었다. -_-;;

만약 예를 들어 /etc/sysctl.conf 와 같은 "설정 파일"의 경우에는 내용을 고치고 나서 새로 적용할 때, 해당하는 서비스나 프로세스를 재시작하는 것이 맞다.

하지만 /etc/rc.local 파일은 그 자체가 실행 스크립트이고, 파일에 기록하는 내용 또한 쉘 명령들이니까 그냥 파일 자체를 실행하면 되는 거였다. ㅡㅡ;;

다만 rc.local 파일에 원래부터 적혀 있었던 연유로 기존의 특정 명령어가 중복 실행되지 않도록 하고 싶으면, 그냥 방금 수정한 라인들을 쉘에다 복사해서 실행해야 된다. 다른 신기한 방법이 있기라도 하겠는가?

밤에 정신없이 작업하니 스크립트 파일을 설정 파일로 착각하는 일도 생기는 것 같다. ㅜㅜ 하지만 인터넷에는 나같은 바보짓(...)을 똑같이 시도하는 사람들도 많이 있다는 데서 위안을 삼는다. ㅋㅋ [1]

<참고자료>

[1] http://www.linuxquestions.org/questions/slackware-14/execute-rc-local-without-reboot-of-linux-server-467282/

2014년부터 지금까지 Ubuntu 14.04.1 LTS (64bit)를 계속 써 왔고, 다만 아직 16.04로 업그레이드를 하지는 않았다. 16.04로 업그레이드 하라는 안내 메세지가 뜰 때마다 나중에 하겠다는 버튼만 눌렀는데, 그런데 어제 "New important security and hardware support update." 라는 대화창이 뜨면서 업데이트를 하라는 메세지가 화면에 나타났다.

이전에 주기적으로 보던 Software Updater의 앱 업데이트 알림 창도 아니고, 새 버전(16.04)으로 바꾸라는 메세지도 아닌 처음 보는 안내창인데 메세지도 뭔가 심각해 보인다. (-_-) 중요한 보안 업데이트겠거니 생각하고 무심코 업데이트 버튼을 눌렀는데...

그런데 거의 한 시간이나 업데이트를 진행하는 것이었다.

뭘 저렇게 많이 설치하는 걸까?

나중에 다 끝나고 나서 보니...

뭘 많이 설치해서 그랬던 것이 아니고, 뭘 많이 지우느라 그랬던 것이었다! ㅜㅜ

재부팅을 했더니 이상하게 몇몇 앱 아이콘이 사라져 있고(Dropbox, VLC, Terminator 등),  듀얼 모니터 화면도 초기화되어서 화면 순서가 뒤바뀌었다. 그런데 디스플레이 설정을 바꾸려고 보니까 System Settings도 찾을 수 없댄다. (헐?)  게다가 Software Updater도 없어져 있었다. 이건 무슨 시츄에이션?

아니 이게 무슨 재앙인가? ㅜㅜ 인터넷에서 검색해 보니, 위의 업데이트 메세지는 커널을 최신 버전으로 업데이트하는 것과 관련된 것이라고 한다. 실제로 확인해 보니 원래 3.16.X 대의 버전으로 되어 있던 커널이 4.4.0.36-generic을 바뀌어 있었다.

물론 커널을 새 버전으로 바꿔서 잠재적인 보안 문제를 해결하는 것 자체는 좋으나, 이로 인해 기존에 쓰고 있던 앱들이 영문도 모르게 사라지고, 심지어 우분투인데 자기 데스크탑 환경까지 날려먹는 상황을 뭘로 설명해야 할까?

일단 재부팅 후에 unity-control-center, ibus, ubuntu-desktop, 그외 내가 쓰던 앱들(Dropbox, terminator, vlc 등)을 재설치했다. 아마 이외에도 상당히 많은 앱들이 영문도 모르게 삭제되었을 가능성이 높은데, 무엇이 삭제되었는지 아직 다 파악이 되지 않는다. 앞으로 쓰다 보면 뭔가 없어서 또 재설치를 하면 되겠지만, 정말 어이가 없다.

처음 팝업 메세지를 봤을 때 바로 업데이트 버튼을 누르지 말고 검색을 해 봤어야 했다. 나와 입장이 같으면서 업데이트를 진행하지는 않은 채 우분투 측에 불만을 토로하는 글이 있었다. [1] 이걸 먼저 봤어야 하는데...

이건 어떻게 보면 사실상 반 강제적으로 16.04를 쓰라고 유도하는 것이나 마찬가지이다. 그뿐만 아니라, 업그레이드를 하면서 기존의 시스템 설정을 최대한 유지해야 하는데 업그레이드가 아닌 커널 업데이트만으로 운영체제 환경이 통째로 망가지는 상황이니 오히려 16.04로 업그레이드를 할 마음이 싹 사라진다. 업그레이드하고 나서 시스템 어딘가가 망가지고 원래 쓰던 중요한 앱들이 작동하지 못해서 발생하는 손실에 대해 책임지기라도 할까?

PC의 주 운영체제로 윈도우7, 윈도우10을 쓰다가 우분투로 바꾸고 윈도우는 서버에서 VM으로 만들어서 쓰고 있는데, 여전히 우분투는 윈도우에 비해 불안정한 요소가 너무 많은 것 같다. 특히 시스템 업데이트를 할 때 너무 문제가 많다. 윈도우는 7에서 10으로 업그레이드하고 나서 망가진 프로그램이 단 하나도 없었는데, 우분투는 예전에 10.04를 12.04로 바꿀 때도 대다수의 패키지가 망가졌고, 이번에도 단지 커널만 (그것도 우분투가 강요해서) 바꿨는데 데스크탑 환경이 엉망이 되었다.

오픈소스에 무료로 쓰는 입장에서 우분투가 나날이 발전해 가는 모습은 좋지만, 기왕 개선하고 새 버전으로 업데이트를 해주고 싶으면 최대한 기존 시스템 설정이 망가지지 않도록 더 많이 신경을 써 줬으면 좋겠다.

이번 사건 때문에 어딘가 망가져 있을 현재 시스템을 계속 쓰는 것도 찝찝해서, 조만간 14.04 자체를 클린 설치하거나, 좋든 싫든 16.04로 클린 설치를 해야 할 것 같다. 

(우분투 나빠요!! ㅠㅠ 사실 이렇게 말하고도 윈도우로 돌아가지는 않고 우분투나 다른 리눅스 계열을 쓸 궁리를 하고 있으니, 이쯤 되면 그냥 애증의 관계인 듯 하다.)

<참고자료>

[1] Ubuntu Forums, "I thought 14.04 was supported for 5 years so why am I getting HWE stack message?" https://ubuntuforums.org/showthread.php?t=2334371

OS: Ubuntu 14.04.1 LTS, Raspbian Jessie

tcpdump: Version 4.6.2 (libpcap 1.6.2)

리눅스에서 네트워크(e.g. 메쉬 네트워크)에 참여하는 각각의 기기가 자신을 거쳐 가는 모든 트래픽 사용량을 네트워크 인터페이스별로 구분해서 통계를 낼 필요가 생겼다.

Tcpdump에서는 "-i any" 옵션을 써서 한꺼번에 모든 인터페이스를 모니터링할 수는 있다. 하지만 아쉽게도 화면에 표시되는 로그 한 줄이 어느 네트워크 인터페이스에 연관된 것인지 알 수 없다. 특히 멀티라디오 멀티채널 라우팅 프로토콜을 돌리는 메쉬 라우터의 입장에서는 지나가는 트래픽 플로우 하나가 어느 네트워크 인터페이스를 거쳐서 지나가고, 소비하는 대역폭의 양이 어느 정도인지 반드시 확인해야 한다.

결국 두 가지 방법 중 하나를 써야 한다.

1. Tcpdump 인스턴스 하나를 모든 네트워크 인터페이스에 대해서 검사하도록 실행하고, tcpdump에 찍히는 source, destination IP 주소를 검사해서 어느 네트워크 인터페이스에 해당되는지 확인(예측)하는 방법
2. 각 네트워크 인터페이스별로 tcpdump 인스턴스를 별도로 실행하고, 각 인터페이스별로 구분되는 로그를 활용하기

처음에는 내가 1번 방식을 써서 라우팅 프로토콜에서 tcpdump 로그를 파싱하고 source, destination IP주소를 가지고 네트워크 인터페이스 이름을 알아내는 함수를 코딩해서 썼는데, 예상치 못한 문제가 발생했다. 로그에 찍히는 source와 destination IP 주소가 현재 로깅을 하는 기기와 상관없는 원격지의 IP주소일 경우에는 어느 인터페이스를 통해서 패킷이 들어오고 나가는지 알 수가 없었다. 아주 불가능한 것은 아니지만, 라우팅 테이블에 접근해서 source, destination 양쪽으로 가는 경로와 네트워크 인터페이스를 확인해야 했다. 그리고 외부에서 현재 기기로 들어오는 패킷인지, 패킷이 현재 기기를 통해서 다른 노드(next hop)로 빠져나가는 것인지를 tcpdump 로그에서는 알 길이 없었다. 라우터 입장에서는 똑같은 로그가 두 줄이 찍히는 것처럼 표시가 되었다.

결국 2번 방법을 쓰기로 하고 인터넷을 찾아보니 나와 비슷한 목적으로 tcpdump를 응용하는 사례가 이미 있었다. [1]

핵심은, 동시에 여러 개의 tcpdump 인스턴스를 실행하고, 그 대신 각 인스턴스에서 로그가 한 줄 찍힐 때마다 앞에 네트워크 인터페이스 이름을 추가해서 한 화면에 모두 출력하는 것이고, 이것을 bash script로 만든 것이 첫 번째 답변이다. ([2]에도 있음)

다만 [1]과 [2]에 소개된 스크립트가 라즈베리파이에서는 에러가 나서, 그냥 옵션들 빼고 여러 인터페이스를 동시에 쓰도록 간단하게 만들었다.

[anydump2.sh]

사용 예시:

출력 예시:

(listening 이후부터 출력되는 로그의 맨 앞에 인터페이스 이름이 다르게 찍히는 것을 볼 수 있다)

<참고자료>

[1] StackOverflow, "How to display interface in tcpdump output flow?," http://serverfault.com/questions/224698/how-to-display-interface-in-tcpdump-output-flow

[2] Sebastian Haas, "Anydump 1.3," http://sebastianhaas.de/anydump-release/

OS: Ubuntu 14.04.1 LTS (64-bit)

Target: QualNet 설치를 위한 Makefile

<문제 상황>

• Qualnet 설치 파일이 32비트 전용인데 64비트 운영체제에서 빌드하는 과정에서 /usr/bin/ld: cannot find -lexpat 에러가 발생한다.
• 하지만 컴퓨터에는 이미 libexpat1, libexpat1-dev 모두 설치되어 있다.

<해결 방법>

컴퓨터에 설치된 libexpat 라이브러리가 64비트 전용이기 때문에 빌드할 때 링크가 안돼서 발생하는 에러이다.

아래 명령으로 32비트 전용 libexpat1-dev 를 설치해야 한다.

며칠 전부터 휴가 기간이 되면서 잠시 고향 집에 방문하게 되었다.

오랜만에 뵙는 반가운 가족들, 맛있는 고향의 음식들과 함께 나의 관심을 끄는 작은 문제점 하나가 있었으니, 바로 내가 오래 전에(거의 8년쯤 전) 설치해 둔 와이파이 공유기가 전원 계통이 고장나서 더이상 켜지지 않는 것이었다. 하긴 IEEE 802.11n 표준도 구현되어 있지 않던 값싼 구형의 액세스 포인트를 지금까지 단 한 번도 전원을 끄지 않고 써 왔으니 하드웨어에 문제가 생길 만도 했을 것이다.

집에서는 통신사에 요청해서 무선랜 서비스를 새로 신청해 둔 상태라고 했지만, 내가 방문했던 때는 휴일이라서 당장 와이파이를 쓸 수는 없는 상황이었다. 마침 나는 랩탑을 갖고 있었고, 랩탑에 내장된 와이파이 인터페이스를 사용해서 내가 집에 있는 동안만 임시로 와이파이 AP를 만들면 되겠다고 생각했다.

내 랩탑에는 윈도우 10과 우분투 14.04가 멀티부팅으로 설치되어 있었고, 윈도우에서는 이미 잘 알려진 Connectify라는 어플리케이션을 설치해서 쓸 수는 있었지만 무료 버전의 경우 설정에 제한이 많고 설치되는 윈도우 환경을 더럽히는(?) 듯한 느낌이 들어서 우분투에서 쉘 스크립트로 직접 AP를 만들기로 했다.

AP를 설정하는 방법은 지금 연구실에서 실험으로 쓰고 있는 라즈베리파이 기반의 무선 메쉬 네트워크 환경에서 AP 생성하는 방법만 가져오면 되었기에 금새 완료할 수 있었다. 랩탑에 랜선을 꽂고, 와이파이 인터페이스, hostapd, isc-dhcp-server, iptables를 차례대로 설정해 주었다.

금새 스마트폰에 나타난 새로운 와이파이 액세스 포인트에 동생은 신기해하면서 바로 내가 생성한 와이파이에 접속해서 스마트폰을 쓰기 시작했고, 나는 평소에 연구하던 것이 이럴 때 도움이 될 수 있다는 것이 뿌듯했다.

하지만... 역시 임시로 만든 AP는 어디까지나 임시로밖에 쓸 수 없다는 현실을 체험하는 계기가 되었다. 내가 집에 갔던 첫째날과 다음날까지 내가 랩탑으로 생성한 와이파이 AP를 실제로 써 보면서, 물리적인 무선랜 공유기와의 성능 차이를 몸소 체험할 수 있었다. ㅜㅜ

가장 먼저는 이상하게 랩탑이 자꾸만 인터넷에 한동안 연결을 하지 못하는 문제로 인해서 스마트폰 입장에서는 와이파이에 접속한 상태는 변함이 없지만 갑자기 인터넷이 안 되는 현상이 간헐적으로 일어났다. 그런 문제가 생겼을 때 내가 바로 재부팅으로 해결하는 바람에 원인을 정확하게 파악하지는 못했지만, 재부팅하기 전에 도메인 네임 서버에 ping이 가지 않았던 현상을 통해서 도메인 네임 서버와의 연결이 간헐적으로 끊어졌던 것 같다.

두 번째로는 속도가 그다지 만족스럽지는 못했다. 내가 AP로 설정한 노트북인 삼성 뉴 시리즈9(NT900X3C-A64)이 비록 802.11n을 내장하고 있었고 안드로이드에서도 접속했을 때의 속도가 65Mbps였지만, 실제로는 그 속도가 나오지 않았다. ㅜㅜ 플레이스토어에서 각종 앱을 다운로드 받아서 설치한 적이 있었는데 그 때의 체감속도가 대략 16-24Mbps (1초에 약 2-3MB 정도를 다운로드 받았으므로 bps로 환산하면 대략 이 정도)였다. 동생도 와이파이를 쓰는 동안 좀 느리다고 얘기했던 것을 보면, 제대로 AP 역할을 수행하기 위해서는 HT를 비롯한 좀더 세부적인 설정이나 tweak 등을 해 줬어야 하는 것 같다. 하지만 나는 그렇게까지 자세한 설정을 고치지는 못했고, HT20, HT40 같은 것을 적용해 보려고 노력했지만 결국 실패로 돌아갔다.

결국 이틀간 쓰면서 이전에 고장나기 전까지 쓰던 802.11g보다 오히려 안정적이지 못하고 속도도 별 차이가 없거나 오히려 느리다는 결론을 내릴 수밖에 없었다.

집에 2박 3일 간 머무르는 중에 첫 이틀을 이렇게 내가 랩탑으로 와이파이를 만들어서 쓰고, 마지막 날 아침에는 통신사가 직접 자체 와이파이 공유기를 설치해 주었는데, 그 전용 장비의 체감 속도와 안전성은 확연히 달랐다.

비록 실제로 시중에서 쓰는 공유기들이 랩탑에 비하면 매우 느린 CPU와 아주 적은 양의 메모리를 갖고 있지만, 아무래도 AP 역할을 잘 할 수 있도록 외부로 노출된 안테나를 포함해서 최적으로 설계된 와이파이 네트워크 인터페이스와 그외 여러 측면에서 최적화된 라우터 전용 운영체제와 세부 소프트웨어 설정의 영향을 무시할 수 없는 것 같다. 

결론적으로, 와이파이가 아예 없는 것보다는 랩탑으로 설정한 AP라도 있는 것이 훨씬 나았지만, 전용 하드웨어가 제공하는 와이파이는 그 임시방편보다도 한층 더 좋을 수밖에 없었다. 혹시나 나중에 와이파이 말고도 또다른 연구하던 것을 현실에 써먹어야 할 때에는 꼭 실제 제품과의 차이가 클 수 있다는 것을 염두에 둬야겠다.