Thursday, May 18, 2017

Developing SNMP trap handlers using Net-SNMP

Net-SNMP is used as standard SNMP manager by almost all Linux distribution, which is de facto standard. I had a chance to develop a handler application for SNMP Trap message, and I'd like to write down some of the important stuff.

[Configuration, test, and troubleshooting]
  • snmptrapd can send received SNMP trap to stdout with designated format
  • Running snmptrapd in foreground and showing logs in stdout
    • snmptrapd -f -Lo -c snmptrapd.conf
  • If snmptrapd can't receive traps, iptables may block it
    • iptables -I INPUT -p udp -m udp --dport 162 -j ACCEPT
    • iptables-save > /etc/sysconfig/iptables
  • In CentOS, if snmptrapd can't read /etc/snmp/snmptrapd.conf, SELinux  security label may be incorrect
    • ls -Z /etc/snmp/snmptrapd.conf (compare labels with other files, e.g. snmpd.conf with ls -Z command)
    • chcon system_u:object_r:etc_t:s0 /etc/snmptrapd.conf
[/etc/snmp/snmptrapd.conf example]
disableAuthorization yes
authCommunity log,execute,net public
#logoption -Lf /root/snmp.log
#logOption -Lo

#format execute %B\n%b\n%V\n%v\n <- default
format execute %b\n%V\n%v\n
#man snmptrapd:FORMAT SPECIFICATIONS for format details
# %b: [Protocol(UDP/TCP] source IP:port -> destination IP:port
# %V: separators between trap values
# %v: actual values representation

#format print1
#format print2

traphandle default /Automata/AutomataSnmpTrapReader
# default: handle everything

Net-SNMP 기반의 SNMP Trap 연동 프로그램 개발

Net-SNMP는 거의 모든 리눅스 배포본에서 표준 SNMP 관리자로 사용되고 있는, 사실상의 표준이라고 할 수 있는 범용적인 도구입니다. 이번에 기회가 있어서 SNMP Trap 메시지를 받아서 처리는 도구를 만들게 되었는데, 개발중 중요하다고 생각되는 내용 몇 가지를 옮겨 적고자 합니다.

[설정 및 테스트]
  • snmptrapd는 받은 SNMP trap을 지정된 형식을 사용하여 stdout으로 보낼 수 있음
  • snmptrapd를 foreground에서 실행하면서 stdout으로 로그 보내기
    • snmptrapd -f -Lo -c snmptrapd.conf
  • snmptrapd가 보낸 trap을 못 받는 경우 iptables가 막는 경우일 수 있음
    • iptables -I INPUT -p udp -m udp --dport 162 -j ACCEPT
    • iptables-save > /etc/sysconfig/iptables
  • CentOS에서 snmptrapd가 /etc/snmp/snmptrapd.conf를 읽지 못하는 경우 SELinux  보안 레이블이 잘못되어서일 수 있음
    • ls -Z /etc/snmp/snmptrapd.conf (ls -Z를 통해 snmpd.conf 등 파일과 레이블 비교)
    • chcon system_u:object_r:etc_t:s0 /etc/snmptrapd.conf
    [/etc/snmp/snmptrapd.conf 예시]
    disableAuthorization yes
    authCommunity log,execute,net public
    #logoption -Lf /root/snmp.log
    #logOption -Lo

    #format execute %B\n%b\n%V\n%v\n <- default
    format execute %b\n%V\n%v\n
    #man snmptrapd:FORMAT SPECIFICATIONS for format details
    # %b: [Protocol(UDP/TCP] source IP:port -> destination IP:port
    # %V: separators between trap values
    # %v: actual values representation

    #format print1
    #format print2

    traphandle default /Automata/AutomataSnmpTrapReader
    # default: handle everything

    Friday, February 17, 2017

    wxWidgets: memory of a month(+list of complaints)

    Recently, with some motivation, I left Qt and used wxWidgets for a while. I used Code::Blocks, applied Bind<>(), and so on. I enjoyed the coding, but eventually I returned to Qt. During the time, I experienced......:

    • If the application is frozen, task switcher doesn't work at all, whatever it is - Alt-Tab, Windows-Tab, taskbar click..... Nothing works. This is first time I've ever seen something like this
    •  You need some time to be accustomed to properly use wxDateTime. On calculation you use wxDateSpan, and its structure is confusing
    • In wxGrid, if you have too many rows ans set the layout side to 1 or higher, the grid wraps the entire window(......). The widget seems to calculate its size based on the sum of column widths and row heights. It must be a bug
    • Unicode adoption seems not working properly. I converted interface strings to UTF-8 using wxConvUtf8 and tried to put the string via SOCI, and Firebird complained whenever the string has some Chinese characters
    • It seems to be due to Windows control itself, but it's too slow. The fame of GDI is not void.

    And above all, Code::Blocks broke down from time to time, and well, just guess what it would feel like if you experience all above.
    For your reference, my development environment was as follows:

    • wxWidgets 3.1
    • MinGW-w64 6.3.0 release 1
    • Code::Blocks rev10922(built at Nov. 20th. 2016)

    Now I'm back to Qt, and I'm porting all my wxWidgets apps to Qt now. The apps are faster, and it's more convenient. Viola!

    wxWidgets: 한 달간의 추억(+투덜투덜 목록)

    근저 약간의 계기로 Qt를 버리고 한동안 wxWidgets를 사용했더랬습니다. Code::Blocks를 사용하고, Bind<>()도 좀 쓰고, 뭐 기타등등 그랬습니다. 한동안 꽤 즐겁게 코딩을 했는데, 결국에는 Qt로 돌아오게 되더군요. 그러니까 그동안 무슨 일을 겪었는가 하니......
    • 프로그램이 freezing 상태가 되면 task switcher가 동작하지 않습니다. Alt-Tab이고 Windows-Tab이고 작업표시줄 클릭이고 뭐고간에 하나도 동작하지 않아요. 시스템이 통째로 얼어버리는건 처음 봤습니다
    • wxDateTime은 익숙해지는데 시간이 꽤 오래 걸립니다. 연산에 wxDateSpan이라는 별도의 클래스를 사용하는데, 이게 구조가 좀 그렇더군요.
    • wxGrid의 열의 갯수가 너무 많은 상태에서 layout 크기를 1보다 크게 잡으면 grid가 창 전체를 뒤덮어버립니다(......). 아무래도 widget의 크기를 widget의 기본 크기가 아니라 내부 행/열의 크기의 합계로 계산하는 것 같습니다. 아무리 봐도 버그인데요. -_-
    • 유니코드 제어가 완전하지 않은 것 같습니다. wxConvUtf8으로 인터페이스의 글자를 UTF-8으로 변환한 뒤 SOCI를 통해 UTF-8 DB에 넣으려고 해봤는데, 글자에 한문만 들어가면 Firebird가 잘못된 글자라면서 오류를 뱉어내더군요
    • 이건 Windows 컨트롤의 한계인 것 같은데, 컨트롤이 꽤 느립니다. GDI의 명성은 헛된 것이 아니었어요. -_-
    여기에 Code::Blocks의 툭하면 죽는 현상까지 가세하니 대략 난감하더군요(-_-).
    참고로 개발환경은 아래와 같습니다.
    • wxWidgets 3.1
    • MinGW-w64 6.3.0 release 1
    • Code::Blocks rev10922(2016년 11월 20일 빌드)
    참고로 지금은 Qt로 돌아왔고, wxWidgets로 만들었던 프로그램도 모두 Qt로 porting하고 있습니다. 속도도 빨라지고 위에 이야기했던 불편함도 없고...... 훨씬 쾌적하네요. Viola!

    Monday, January 16, 2017

    QSqlQuery vs. SOCI: inserting 1000 times

    Recently I'm using QtWebApp to develop an application, and I did some performance benchmark to select a database library in the backend.  I selected QSqlQuery and SOCI as candidates, and tried to insert 10,000 rows at once. The result is as follows:

    • Repeating single query
      • QSqlQuery: 10000ms
      • SOCI: 2500ms
    • Prepared statement
      •  QSqlQuery: 7000ms
      • SOCI: 750ms(?!)
    In any situation, SOCI takes far less time than QSqlQuery. QSqlQuery seems to be really a bad choice for server applications. I suspect the bottleneck is the loooooong processing time for QString.

    QSqlQuery vs. SOCI: 1000회 연속 insert

    최근 QtWebApp을 기반으로 프로그램을 개발하고 있는 바, backend에서 사용할 DB 라이브러리를 써보려고 성능 테스트 비슷한걸 해봤습니다. 후보로는 QSqlQuery와 SOCI를 선택했고, 연속으로 10,000회 insert를 시도했습니다. 결과는 아래와 같습니다:
    • 단일 쿼리 반복
      • QSqlQuery: 10000ms
      • SOCI: 2500ms
    • Prepared statement
      • QSqlQuery: 7000ms
      • SOCI: 750ms(?!)
    어떤 상황에서든, SOCI가 QSqlQuery를 훨씬 뛰어넘는 처리속력을  보여주고 있습니다. 아무래도 QSqlQuery는 서버 상황에서는 썩 좋은 선택은 아닌 것 같습니다. 아무래도 쿼리를 구성하는데 사용되는 QString 특유의 비대함(?)이 문제가 아닐까 하는 생각이 드네요.

    Wednesday, December 21, 2016

    Recent trends in inflight entertainment system development

    Recently I had some chance to use a lot of airlines, and I found some airlines have inflight entertainment system with quite remarkable user interface/experience. I tried to find out who was behind, and all of them were found to be developed by Panasonic Avionics. And what? The company is one of the protagonists in "customer success stories" from Qt Company.

    Man, in the world of C++, Qt becomes the de facto standard.