Tomcat 웹어플리케이션의 구조

톰캣으로 개발을 진행하려할 때 가장 처음에 막히는 부분은 웹어플리케이션의 구조이다. 일반적으로 파일을 올려서 동작시키기만하면 되던 PHP와는 달리, 자바 서블릿&JSP에서는 웹어플리케이션이라는 하나의 단위로서 해당하는 파일들의 관리를 해줘야한다.

일반적으로 Tomcat에 웹어플리케이션을 개발할 때에는 서블릿 컨테이너의 SERVER_ROOT에서 생성시켜야한다. Tomcat이 /usr/local/apache-tomcat 에 설치되어있다면 SERVER_ROOT는 /usr/local/apache-tomcat/webapps 가 된다.

해당하는 루트에 웹어플리케이션을 개발하자. 이름을 firstapp 이라고 한다면 다음과 같은 디렉토리를 가져야한다.

• /firstapp : 웹어플리케이션의 루트 디렉토리. JSP나 HTML을 보관한다.
• /firstapp/WEB-INF : 웹어플리케이션 루트에 포함되지않을 모든 애플리케이션 및 자원이 포함된다. 또한 배치지시자(DD)가 저장되는 곳이다.
• /firstapp/WEB-INF/classes: 서블릿 및 기타 유틸리티 클래스를 넣어두는 곳
• /firstapp/WEB-INF/lib: 의존하는 각종 자바 압축파일을 넣어둔다. 예를 들면 JDBC 드라이버등을 들 수 있다.
  

Tomcat 웹어플리케이션의 구조

톰캣으로 개발을 진행하려할 때 가장 처음에 막히는 부분은 웹어플리케이션의 구조이다. 일반적으로 파일을 올려서 동작시키기만하면 되던 PHP와는 달리, 자바 서블릿&JSP에서는 웹어플리케이션이라는 하나의 단위로서 해당하는 파일들의 관리를 해줘야한다.

일반적으로 Tomcat에 웹어플리케이션을 개발할 때에는 서블릿 컨테이너의 SERVER_ROOT에서 생성시켜야한다. Tomcat이 /usr/local/apache-tomcat 에 설치되어있다면 SERVER_ROOT는 /usr/local/apache-tomcat/webapps 가 된다.

해당하는 루트에 웹어플리케이션을 개발하자. 이름을 firstapp 이라고 한다면 다음과 같은 디렉토리를 가져야한다.

• /firstapp : 웹어플리케이션의 루트 디렉토리. JSP나 HTML을 보관한다.
• /firstapp/WEB-INF : 웹어플리케이션 루트에 포함되지않을 모든 애플리케이션 및 자원이 포함된다. 또한 배치지시자(DD)가 저장되는 곳이다.
• /firstapp/WEB-INF/classes: 서블릿 및 기타 유틸리티 클래스를 넣어두는 곳
• /firstapp/WEB-INF/lib: 의존하는 각종 자바 압축파일을 넣어둔다. 예를 들면 JDBC 드라이버등을 들 수 있다.
  

Mercurial 을 이용한 소스 관리

필요한 것

1. SSH를 지원하는 Mercurial 서버
2. Mercurial Client 패키지가 설치된 클라이언트

먼저 서버쪽에 repository를 설치할 필요가 있다. 해당 디렉토리에 들어가 다음과 같이 명령을 내린다.

hg init

다음에 클라이언트에서는 해당 서버에 clone을 행한다.

hg clone ssh://username@server/home/hg/repo/ [받을디렉토리]

이제 클라이언트에서는 파일을 수정하면 된다. 다음으로 수정후에 commit을 한다.

hg commit -Am "커밋로그설명"

그리고 해당 파일을 push한다.

hg push

그렇게되면 해당SSH계정의 암호를 입력하게되면 된다.

마지막으로 update하면 끝

hg update

Google Calendar의 국가별 세팅에 따라 하는 일이 다른 듯..

한국버전으로 하니까 사라진 Tasks가.. 영어버전으로 하니 떡하니 나온다.
각국마다 따로 시스템을 관리하는 듯한데 처음해볼때 엄청 당황했다.

사실 국가에 따라서 이런 모듈이 들락 날락 한다는 것 자체가 좀 의아스럽다.
가면 갈수록 클라우드 시스템에 대해 별로라는 생각만 드는 것은 왜그럴까..

집에서 일하는 데 필요한 제언..

1. 일하는 공간과 생활하는 공간은 분리한다. 어떠한 경우라도 공간을 분리해야한다. 정 안되면 파티션이라도 쳐야한다. 사람은 공간에 영향을 심각할 정도로 많이 받기 때문에 약간의 분리만으로도 큰 효과를 얻을 수 있다.
2. 문을 닫아라. 일단 일을 한다면 외부와의 접촉을 모두 끊어버리는 것이 중요하다.
   
3. 규칙적으로 일하라. 집에서 일하는 데에도 사무실에서 일하는 것과 같은 규칙을 사용해야한다.
4. 먹는 데에 소홀해지지 마라. 집에서 일하는 사람은 먹는 시간을 상당히 소홀히 한다. 먹는 시간은 규칙적으로 하고, 필요한 간식도 챙겨 먹도록 한다. 그래야만 일의 맥을 끊는 것을 막을 수 있다.
   

Fixed-Schedule Productivity

원문에서 나온  Fixed-Schedule Productivity의 요점은

1. 일과 휴식의 균형이 이상적이라고 생각되는 근무시간의 스케쥴을 정하고
2. 이 스케쥴을 깰 수 있는 어떤 상황이든 거부한다

라는 것이다. 1을 충족한다는 것은 매우 쉽지만, 2를 충족하는 것은 그렇게 쉽지않다. 수많은 일과 엮인 상황에서 무조건 거부하기란 매우 어려운 일이다. 간단한 사실이 있다면 : 이상적인 스케쥴을 유지하려면 약간의 극단적인 행동도 필요하다는 점이다.
따라서 다음의 상황이 벌어질 수 있다.

• 작업중인 많은 프로젝트를 과감히 쳐낸다.
• 일일 스케쥴에서 불필요한 습관을 없앤다
• 자유시간을 얻는 대가로 다른 사람을 자극할 수 있다.
• 미루는 습관을 없앤다.

이런 상황을 위해서 원저자는 다음과 같은 작업을 했다고 한다.

• 작업을 직렬화한다. : 프로젝트 큐를 만들어서, 개별 큐의 최상단에 위치한 프로젝트만을 수행하도록 한다. 이것이 끝나야 다음 작업으로 넘어갈 수 있도록하여, 집중도를 높인다.
• 결과를 내야할 시점이 언제쯤인지 명확하게한다: 누군가가 큐에 할일을 넣을 때, 이를 평가해서 언제쯤 수행해야할지를 정한다. 이에 대해서 의사소통을 한다.
• 프로젝트 수행중에 큐가 너무 복잡해져서 특정 프로젝트를 제시간에 마칠 수 없을 것 같다면, 거절한다.
• 프로젝트가 제어범위를 벗어나서, 스케쥴의 시간을 지나치게 잡아먹기 시작한다면, 프로젝트를 버린다. 다른 더 중요한 일이 다가오고, 큐에 있는 어떤 일과 충돌하게된다면, 좀 덜 중요한 프로젝트를 버린다. 예상시간이 너무 길다면 중지한다. 어느 누구도 당신이 작은 부분에서 무엇을 하는지 궁금해하지 않는 다는 점이 중요하다. 최종적으로, 중요한 완료리스트를 가지고 스스로 판단해야한다.
• 숨어라. 종종 아무도 보이지 않는 곳에서 일하고는 하는데, email같은 수단이 아니고서는 접촉할 수 없게한다. 하지만 굳이 모든 일에 즉각적으로 대응할 필요는 없다. 중요한 것은 내가 일을 완료하는 것ㅇ이다.
• 순차작업과 습관화하기. 어떤한 규칙적인 작업이 있다는 이를 그냥 습관화한다. 일요일 아침에 블로그를 쓴다던가, 세미나 자료를 금요일이나 월요일 오전에 읽는 등이다. 습관화된 스케쥴은 비정규적인 프로젝트에 착수하기 쉽게한다. 또한 스케쥴이 해야할 일로 넘치는 것을 방지한다.
• 일찍 시작한다. 어떤 일을 실제보다 2,3주 먼저 시작할 필요가 있다면 그렇게한다.

모든 일은 그 끝을 알 수 없기때문에, 스케쥴을 고정시키는 것이 중요하다. 그리고 이에 맞추어 모든 요청을 정리해야한다. 유연해지고, 효율적이 되어야한다. 만약 진행이 안된다면, 작업을 변경시켜야한다. 절대, 타협하지않아야한다. 당신 자신이외에는 어느 누구도 당신의 스케쥴에 신경을 쓰지 않는다.

Paul Graham 의 앱스토어 비평

Paul Graham 이 앱스토어에 대해 비판하다.

Paul Graham은 앱스토어를 소프트웨어의 iTunes로 보고 이를 비판하고 있다. 완성된 제품을 시장에 공급하는 음악이나 도서 산업과는 달리 소프트웨어는 지속적인 개발 사이클(iterate)을 가질 수 밖에 없다는 점을 들어, Apple의 이같은 시도가 개발자들에게 중대한 벽으로 작용한다고 보고 있다.

실제로 사용자들이 보고하는 버그를 수정해서 올려야되는 개발자 입장에서는 새로운 버전을 올릴 때마다 다시 심사(Approval)과정을 거칠 수 밖에 없는 것은 90년대 이전의 소프트웨어 시장을 생각케한다. 당시에 많은 패키지들은 한번 나오면 좀처럼 수정이 어려웠기때문에 제작에 상당한 공을 들여야했었지만, 그럼에도 불구하고 수많은 에러를 만들어 사용자를 당황시킨 적이 한두번이 아니었다.

결국 통신망을 통해 지속적으로 패치를 공급하거나 새로운 버전을 빠르게 공급할 수 있었던 업체들만이 살아남을 수 있었다. 문제는 앱스토어의 방식이 이를 근본적으로 금지시킨다는 점이다.

우후죽순격으로 생기고 있는 앱스토어를 보고 있자면, 소프트웨어의 근본적인 특성을 이해하고, 이를 배려하려는 노력이 턱없이 부족하게 느껴진다. 특히나, 날마다 새로운 기능을 요구하고, 변화를 추구해야하는 지금에 있어서, 프로그램 유통자체를 누군가에게 의존해야만하는 모델은 초기에는 제법 괜찮은 것 같겠지만, 나중으로 갈수록 정책이 개발자의 목을 조르는 일이 벌어지게된다.
이렇게 된다면 개발 동력은 저하될 것은 불보듯 뻔한 일이 될 것이며, 언젠가는 구닥다리 버전만 돌아다니는 고물상이 될지도 모른다.

보다 개방적이고, 덜 권위적이며, 프로그래머 친화적인 정책만이 앱스토어를 더억 강화시키는데 일조할 수 있을 것이라고 생각한다.

gifimg.php를 이용한 사이트 해킹

요 며칠간 일부 자바 스크립트가 먹통이 되거나 사이트가 정상적으로 열리지 않는 상황이 발생했다.,
웹쉘, 각종 악성코드를 검사하던 중 이미지를 올려놓는 디렉토리에 gifimg.php라는 정체를 알 수 없는 파일을 발견했다.
해당 파일은

eval(base64_decode(...));

와 같이 한줄만 걸려있으며 인코딩된 문자열을 가지고 있다.
이 코드는 일종의 웹쉘역할을 하지만 실제 공격코드를 가지고 있지는 않기 때문에 몇몇 검색툴에서 정상적으로 잡아내지를 못하고 있따다.

해당 파일은 FTP를 통해서 올려지기 때문에, 보유중인 ftp계정의 암호등을 리셋하는 과정에 더해서, ftp 디렉토리에 걸려있는 모든 드라이브를 검사해보도록 한다.

증상으로는 자바스크립트(*.js)나 PHP, ASP파일등에 특정 URL의 자바스크립트를 호출하는 문장이 끼어든다면 이 문제라고 볼 수 있다.

ferozkhan.in / madam / band_vid.php
art4ukorea.com / data / phpinfo.php
visorg.ru / news / style5.php
cmcludhiana.in / event_image / cmc_ludhiana_hospital.php
psusheela.org / php / index_new_template.php
ecaeda.com / language / Checklist.php

해당 URL에서는 악성코드나 스팸메일을 발송하도록 하는 코드를 수행시켜 자기도 모르는 새 스팸메일의 발송처로 악용될 수 있다.
암호화가 부실한 FTP 사이트를 통해 공격이 이루어지기때문에 웹로그만을 감시하게되면 놓치게 되는 부분이니 유의해야한다.