참조
http://www.linux-radar.net/reset-password-ubuntu.html


재시작시키고, Esc 키를 눌러 GRUB 메뉴가 나오게 한다. recovery menu를 선택한다.

아래와 같은 Recovery Menu가 나오면, root 메뉴를 선택하고, 셀로 나오게 한다.

패스워드를 수정하고 다시 재부팅해서 ubuntu가 정상적으로 뜨게 한다.
passwd '계정명'

1. ubuntu 한글 환경 (입력) 구축
http://skcha.tistory.com/196

2. ubuntu 자동 로그인
http://log.bestf.net/230

3. ubuntu Lock Screen 설정 해지 및 시작 설정/ 데스크탑 설정 / 개인 설정

tweak 설치

좌측메뉴에서 security related 를 선택하고,  disable "Lock Screen"하니, timeout되면서 screen lock되는게 사라진다.



4. root 패스워드 변경
sudo 쓰기 귀찮음.
http://knight76.tistory.com/entry/Ubuntu-11-root-password패스워드-변경

5. ssh 서버 및 클라이언트 쓰기
윈도우에서 작업하기 편하게 함

sudo apt-get install openssh-server openssh-client

만약 우리가 관리하고 있는 서버에서 설정을 하지 않았다면 계속 무한대기 상태로 있을까요?

OS 레벨에서는 tcp 레벨 단위의 socket timeout 이 있는데요.  이 값에 영향을 받습니다.

리눅스의 경우는 커널 파라미터라고 그 값을 볼수도 바꿀 수 있습니다.

tcp_keepalive_time 파라미터는 " keepalive 가 활성되 되어 있을 경우, 얼마나 자주 TCP 가 keepalive 메세지를 보내게 할 것인지를 설정."에 대한 값을 정의합니다.  tcp_fin_timeout은 "tcp fin 패킷에 대한 timeout"이며, tcp_syn_retries 는 "tcp syn 패킷을 몇번이나 시도할 것이냐"에 대한 값입니다. 이 모든 값은 os level 단의 timeout에 큰 영향을 미칩니다.

자세히 보도록 하겠습니다.

ubuntu 설정으로는 7200초 (2시간)이 디폴트값입니다.

cat /proc/sys/net/ipv4/tcp_keepalive_time
7200

/proc/sys/net/ipv4/tcp_keepalive_intvl/와 /proc/sys/net/ipv4/tcp_keepalive_probes 의 값과 함께 계산되어 timeout이 될 때, 상당히 긴 시간동안 timeout 이벤트가 일어나지 않을 가능성이 높으니, db에 대한 timeout은 반드시 지정될 필요가 있습니다.

tcp fin 패킷을 못받는 경우에 대한 timeout은 60초 (1분)입니다.

cat /proc/sys/net/ipv4/tcp_fin_timeout
60

tcp syn 패킷에 대한 시도는 5번이나 합니다.  

cat /proc/sys/net/ipv4/tcp_syn_retries

5

실제 timeout 은 특정 이벤트마다 시도 값 * timeout + 약간의 delay  으로 계산이 되겠죠?

DB단에서 이런 리눅스의 tcp 커널 파라미터를 수정하여 성능을 높이는 일을 많이하고 있습니다만, 웹 서비스쪽은 굳이 할 필요는 없다고 생각듭니다. 어플단에서 충분히 할 수 있으니까요.

os level 단에 있는 timeout을 의존하기 보다는 db connection에 대해서 socket timeout , connect timeout을 잘 정의하는 것이 훨씬 운영면에서 편리합니다. 

점점 까먹어진다. 틈틈히 복습하자..



1. select function 좋은 예제

5초동안 표준입력으로부터 입력값을 받는다. 5초 이내로 글자를 받으면 (해당 fd에 대한 값이 변경) 입력받은 문자를 그대로 출력

소스
#include <stdio.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

#define TIMEOUT 5
#define BUF_LEN 1024

int main(void) {

 struct timeval tv;
 fd_set readfds;
 int ret;

 FD_ZERO(&readfds);
 FD_SET(STDIN_FILENO, &readfds);

 tv.tv_sec = TIMEOUT;
 tv.tv_usec = 0;

 //  nfds is the highest-numbered file descriptor in any of the three sets, plus 1.

 ret = select (STDIN_FILENO + 1, &readfds, NULL, NULL, &tv);
 if (ret == -1) {
  perror("select");
  return 1;
 } else if (!ret) {
  printf ("%d senconds elapsed. \n", TIMEOUT);
  return 0;
 }

 if (FD_ISSET(STDIN_FILENO, &readfds)) {
  char buf[BUF_LEN + 1];
  int len;

  len = read(STDIN_FILENO, buf, BUF_LEN);
  if (len == -1) {
   perror("read");
   return 1;
  }

  if (len) {
   buf[len] = '\0';
   printf("read : %s \n", buf);
  }

  return 0;
 } 

 fprintf(stderr, "This should not happen!\n");
 return 1;

}

$ gcc select-demo.c
$ ./a.out
5 senconds elapsed.
$ ./a.out
123
read : 123
 

2. man select 내용

       /* According to POSIX.1-2001 */
       #include <sys/select.h>

       /* According to earlier standards */
       #include <sys/time.h>
       #include <sys/types.h>
       #include <unistd.h>

       int select(int nfds, fd_set *readfds, fd_set *writefds,
                  fd_set *exceptfds, struct timeval *timeout);

       void FD_CLR(int fd, fd_set *set);
       int  FD_ISSET(int fd, fd_set *set);
       void FD_SET(int fd, fd_set *set);
       void FD_ZERO(fd_set *set);

       #include <sys/select.h>

       int pselect(int nfds, fd_set *readfds, fd_set *writefds,
                   fd_set *exceptfds, const struct timespec *timeout,
                   const sigset_t *sigmask);

pselect 라는 것이 있는데. 차이점이 있다.
1. 시간과 관련된 struct이 다르다. select : timeval, pselect : timespec (초와 나노초)
2. 시그널 관련 sigset_t가 있다. 시그널과 관련된 mask를 파라미터로 사용한다. select 함수는 signal 파라미터를 사용하지 않는다.
   (pselect를 사용하는 예제를 거의 못본 것 같다. 나는 아직까지는 select만 사용하는 어플만 본 것 같다.)

pselect 예제는 sigprocmask 함수를 사용한 예제와 비슷하다.
 ready = pselect(nfds, &readfds, &writefds, &exceptfds,
                           timeout, &sigmask);

           sigset_t origmask;
           sigprocmask(SIG_SETMASK, &sigmask, &origmask);
           ready = select(nfds, &readfds, &writefds, &exceptfds, timeout);
           sigprocmask(SIG_SETMASK, &origmask, NULL);

3. poll 좋은 예제

#include <stdio.h>
#include <unistd.h>
#include <sys/poll.h>

#define TIMEOUT 5

int main(void) {
 struct pollfd fds[2];
 int ret;

 fds[0].fd = STDIN_FILENO;
 fds[0].events = POLLIN;
 
 fds[1].fd = STDOUT_FILENO;
 fds[1].events = POLLOUT;

 ret = poll(fds, 2, TIMEOUT * 1000);
 if (ret == -1) {
  perror("poll");
  return -1;
 }
 
 if (!ret) {
  printf("%d seconds elapsed. \n", TIMEOUT);
  return 0;
 }

 if (fds[0].revents & POLLIN) {
  printf ("stdin is readable.\n");
 }

 if (fds[1].revents & POLLOUT) {
  printf ("stdout is writable.\n");
 }

 return 0;
}

결과
$ gcc poll-demo.c
$ ./a.out
stdout is writable.

$ touch xx.txt
$ ./a.out  < xx.txt
stdin is readable.
stdout is writable.

4. man poll

       #include <poll.h>

       int poll(struct pollfd *fds, nfds_t nfds, int timeout);

       #define _GNU_SOURCE
       #include <poll.h>

       int ppoll(struct pollfd *fds, nfds_t nfds,
               const struct timespec *timeout, const sigset_t *sigmask);

         struct pollfd {
               int   fd;         /* file descriptor */
               short events;     /* requested events */
               short revents;    /* returned events */
           };

5. select 와 poll 비교

- poll 은 가장 높은 fd에 +1을 할 필요가 없다.
- poll은 fd가 클 경우 좋다. select는 모든 fd의 비트를 검사한다. (select는 for loop에서 set 된 정보를 찾음)
  -> 그렇다고 select가 안좋다고 말할 수 없다. 이벤트가 자주발생하고 연속적인 시스템에서는 select를 사용 (apache http)
     poll은 어느 정도 분산되어 있거나 크기 제한이 없는 여러개의 array 형태로 넘겨서 사용할 때 유용하다.
            그리고, 필요한 것만 비교할 경우가 효과적이다.
- select는 fd set을 초기화를 해야 하지만, poll은 입력과 결과를 분리할 수 있다.
- select는 사이즈 제한이 있다.
- select가 이식성이 좋음. 어떤 시스템은 poll을 쓰지 않기도 함
- select의 timeout이 poll의 timeout보다 안정적임

6. 레벨트리거와 엣지트리거

select와 poll 은 레벨트리거

레벨 트리거  : 파일에 데이터가 있는지 여부에 대한 판단, 완전히 다 읽을때까지 계속 이벤트를 발생한다. 즉 '동안'에 집중
에지 트러거  : 파일이 특정 데이터를 저장하는 '특정시점'에만 발생

좋은 설명은 다음 블로그에서 잘 해놨다.
http://no1rogue.blog.me/30091246644
- 에지 트리거 : 인터럽트가 발생하여 레벨이 상승하거나 하강할 때.
- 레벨 트리거 : 인터럽트가 발생하여 그 레벨이 인가될 때.

출처
- http://no1rogue.blog.me/30091246644
- 리눅스 시스템 프로그래밍, 한빛미디어
- http://kldp.org/node/35279

과거에 https 연결해서 테스트한 적이 있었고, 그 이후에 쓰지 않다가 최근에 https로 사용해야 해서 https로 테스트하던 중에 발견되었습니다.

브라우져상의 에러

(크롬) : err_connection_reset 에러 발생

IE 쪽

Apache Http 서버의 설정파일이나 java 연결부분, 인증서 부분에도 특별한 문제점을 파악하지 못했습니다.

에러 로그에서도 특별한 징후를 찾을 수 없었습니다.

그래서 터미널에서 해당 서버에 로그인 한 후, openssl을 이용해서 디버깅을 해보았습니다.

localhost의 443포트에 접속해서 ssl 통신을 체크하였습니다.

ssl 통신은 최초 통신의 시작을 hello 라는 패킷을 client와 server 에 서로 전달하는데. 그 부분에서 에러가 발생한 것입니다. 저는 좀 더 상세한 정보를 보기 위해서 linux의 시스템 콜과 에러 내용에 대해서 정확히 분석하기 위해서 strace 라는 리눅스 명령어를 이용했습니다.

서버에서 접속을 끊었다는 ECONNRESET (error number 104) 이라는 에러가 발생되었음을 정확히 확인할 수 있었습니다.

ECONRESET 은  TCP 통신과 연관이 있습니다

A,B 노드가 있다고 가정하고, A가 Syn 패킷을 통해 connection을 시도했지만, 서버에서 port가 존재하지 않거나 중간에 소켓에 문제가 생겨 서버로부터 RST 패킷을 받게 됩니다. 이 때, -1이 리턴되고 ECONNRESET이 errono로 셋팅되며, Connection reset by peer 메시지를 보여 줍니다.

일반적인 케이스는 아파치 에러 로그(LogLevel debug 설정)에 보여지기도 하지만, 이번 경우는 에러 로그에 남지 않았습니다. 그 이유는 Http 단 연결이 아닌 TCP 단에서의 연결에서 종료되었기 때문입니다.

만약 정상적인 연결이었다면, 아래와 같이 SSL 통신하고 클라이언트에서 인증서를 받는 형태로 가게 됩니다.

ssl 통신(handshaking) 은 다음과 같습니다.

1. Client(터미널에서 openssl 요청, 브라우져)가 Https를 이용해서 Server(google.com) URL로 통신을 시도한다. Hello 라는 통신인데, 지원 가능한 암호방식, 키 교환 방법, 압축 방식을 서로 의사소통합니다.

2. Server(google.com)가 인증서를 client에 전달합니다.

3. Client에서는 Server 인증서 public key 얻어옵니다. (기본적인 인증서에 대한 검증 절차를 거침. 인증서의 도메인과 실제 요청하는 도메인이 갖은지. CA가 정확하게 인증했는지 등등)

5. Client에서는 public key를 이용한 pre-master key(RSA 키교환) 를 생성하고 서버에 전달하여 상호간의 키를 교환하도록 합니다..  (key exchange)

6. Client에서 인증서 검증 정보를 보내고,  SSL 통신에 의해 결정된 암호방식, 키교환 방법, 서명방식, 압축방식을 다음부터 적용할 것을 정합니다. (cipher spec)

6. Server는 Client로부터 받은 pre-master key(또는 pre master secret)를 private key로 디코딩하고 Session ticket으로 생성하고 Client에 전송합니다.  (session ticket)

7. Server 에서는 Session Ticket를 이용하여 Server와 Client간의 발생하는 모든 통신은 암호화가 되게 합니다

통신 에러는 client->server 로 SSL Handshake 하는 첫번째 단계("1. Client(터미널에서 openssl 요청, 브라우져)가 Https를 이용해서 Server(google.com) URL로 통신을 시도한다. Hello 라는 통신인데, 지원 가능한 암호방식, 키 교환 방법, 압축 방식을 서로 의사소통합니다. ")에서 문제가 발생한 것이었습니다.

이에 대한 정확한 진단을 위해서 아파치 서버의 설정 파일을 수정하였습니다.

Prefork 설정에서 StartServer와 MaxClient를 1로 주어 리스타트를 하였습니다.

root 권한으로 동작하는 httpd 데몬과 www 권한으로 동작하는 httpd 데몬(worker)만이 리눅스에서 실행하게 됩니다.

Http 요청이 웹서버에 들어오면 1111 root 권한으로 실행되는 httpd 데몬이 1112 라는 httpd로 요청을 전달시킵니다.

그래서, www 권한으로 동작하는 httpd 데몬에다가 시스템 콜을 확인하는 strace를 붙여서 프로세스가 어떤 일을 하는지 확인합니다.

strace 로 프로세스를 띄우고, openssl로 https 패킷을 날리면 다음의 결과를 얻게 됩니다.

httpd 데몬에서 중간에 read 콜 이후에 Resource temporarily unavailable 이 일어나고.
나중에는 SIGSEGV (Segmentation fault)가 발생하게 되었습니다. 마지막에는 www 프로세스가 종료되었음을 확인할 수 있었습니다. (kill(1112, SIGSEGV))

즉, 요청이 들어올 때마다 www 프로세스(apache worker)가 동작하다가 Segment fault가 발생한 것이었습니다.
그리고, ps 명령어를 이용해서 프로세스 확인을 하니. 새로운 프로세스가 떠져 있는 것을 확인했습니다.

아파치에 문제가 있는 것은 확인했습니다. 그 중의 어디서 문제가 있는지 확인을 해야 했습니다.

vhost.conf 설정 파일은 이런식으로 되어 있습니다.

먼저 회사에서 만든 특정 모듈을 읽고, mod_ssl을 읽는 구조로 되어 있습니다.

좀 더 자세히 문제를 확인하기 위해서 httpd 데몬에 대해서 디버깅(gdb)를 하였습니다.

회사에서 만든 특정 모듈의 SSL_accept 메소드에서 문제가 되었음을 확인할 수 있었습니다.

담당자분께 확인하니 auth모듈에서는 자체적인 ssl 인증 모듈을 static linking해서 가지고 있다고 합니다.

즉, mod_ssl을 쓰지 않고 auth 모듈을 사용하는 웹 서버를 위해서 만들어 진 것인데요. 이 부분이 저희가 사용하고 있는 mod_ssl의 ssl 버전과 충돌이 난 것입니다. 그래서 segmentation fault가 난 것입니다.

먼저 auth을 읽었고, mod_ssl을 읽는 구조에서 mod_ssl을 읽고, auth을 읽는 구조로 변경했더니 무사하게 동작되었습니다.

Apache Http 서버에서 443 포트(Https)를 인증서를 이용해서 서비스하는 경우가 있다.
이때 디버깅하는 방법은 openssl을 이용하는 방법이 있다.

이를 통해서 openssl의 handshaking 방법을 이해할 수 있으며, acl 이슈나 웹 서버의 설정 이슈들을 이를 통해서 확인이 가능하다. 정상적이지 않으며 아래와 같은 handshaking에서 문제가 발생할 것이다.
ssldump 나 wireshark, etheral 같은 프로그램으로도 충분히 볼 수 있다.

google.com:443 포트 즉, https://google.com:443 포트에 접속하는 연결을 하는 예제이다.
아주 전형적인 ssl 통신이다.

SSL은  HTTP와 TCP 중간에 걸친 Layer이며, HTTPS 연결시 SSL 통신을 하게 된다.

smtps, nntps, ldaps, ftps, pops 등 다양한 secure channel에 공통적으로 사용될 수 있다.

자세한 내용은 워낙 많은 자료들이 인터넷에 많은 관계로 참조하면 된다.

- https://developer.connectopensource.org/display/CONNECTWIKI/SSL+Handshake

- http://blog.naver.com/nttkak?Redirect=Log&logNo=20130246501
  http://blog.naver.com/nttkak?Redirect=Log&logNo=20130246501
  http://blog.naver.com/nttkak?Redirect=Log&logNo=20130246501

- http://pchero21.com/798

- http://www.openssl.org/

- http://www.ibm.com/developerworks/kr/library/l-openssl.html

- http://www.joinc.co.kr/modules/moniwiki/wiki.php/article/Openssl%C0%BB_%C0%CC%BF%EB%C7%D1_%C6%C4%C0%CF_%BE%CF%C8%A3%C8%AD



하고 싶은 얘기는 SSL Handshaking이다. 트러블 슈팅이 큰 도움이 된다.
약간 광범위한 얘기이긴 하지만. 무척이나 중요한 내용이다.

* http://www.symantec.com/connect/articles/apache-2-ssltls-step-step-part-1 의 이미지 참조









이미 진행했던 구글 서버와의 openssl 통신 결과의 의미를 파악해 본다.

ssldump을 이용해서 application 단에서의 통신을 이해할 수 있다.

• /proc/sys/vm/laptop_mode: How many seconds after a read should a writeout of changed files start (this is based on the assumption that a read will cause an otherwise spun down disk to spin up again).
• /proc/sys/vm/dirty_writeback_centisecs: How often the kernel should check if there is "dirty" (changed) data to write out to disk (in centiseconds).
• /proc/sys/vm/dirty_expire_centisecs: How old "dirty" data should be before the kernel considers it old enough to be written to disk. It is in general a good idea to set this to the same value as dirty_writeback_centisecs above.
• /proc/sys/vm/dirty_ratio: The maximum amount of memory (in percent) to be used to store dirty data before the process that generates the data will be forced to write it out. Setting this to a high value should not be a problem as writeouts will also occur if the system is low on memory.
• /proc/sys/vm/dirty_background_ratio: The lower amount of memory (in percent) where a writeout of dirty data to disk is allowed to stop. This should be quite a bit lower than the above dirty_ratio to allow the kernel to write out chunks of dirty data in one go.