수안이의 컴퓨터 연구실

printf, fprintf, sprintf

출력 스트림에 각 인자를 표현하는 방법은 format 매개변수에 의해 조절된다. 이 매개변수는 출력할 일반적인 문자와 변환 지정자(conversion specifier)라고 불리는 코드를 포함하고 있다.

• %d, %i: 정수를 십진 형태로 출력한다.

• %o, %x: 정수를 8진수, 16진수 형태로 출력한다.

• %c: 문자를 출력한다.

• %s: 문자열을 출력한다.

• %f: 부동 소수점(단일 정밀도) 숫자를 출력한다.

• %e: 배정밀도(double precision) 숫자를 고정된 형식으로 출력한다.

• %g: 배정밀도 숫자를 일반적인 형식으로 출력한다.

printf에 전달된 인자의 개수와 형식이 format 문자열에 있는 변환 지정자와 일치한다는 것은 매우 중요하다. 크기 지정자를 사용하여 정수 인자의 형식을 지정할 수도 있는데 없어도 된다. 크기 지정자는 h 혹은 l이 될 수 있다. 예를 들어 %hd는 short int를 나타내고, %ld는 long int를 나타낸다. 어떤 컴파일러는 이러한 printf 구문들을 검사할 수 있으나 절대 오류가 없을 수는 없다. GNU 컴파일러 gcc를 사용한다면 –Wformat이 이러한 검사를 수행해준다.

이 모든 예제는 10문자의 너비를 가진 필드에 출력된다. 음수 필드 너비는 항목이 필드 내에서 왼쪽 정렬됨을 의미한다. Asterisk(*)를 사용하여 변수 필드 너비를 지정한다. 이 경우에 다음 인자가 너비로 사용된다. 앞에 오는 0은 항목의 앞에 0이 쓰여짐을 의미한다. POSIX 명세에 따르면 printf는 필드의 내용을 지우지 않고 딱 맞도록 필드를 확장한다. 예를 들어 필드보다 긴 문자열을 출력하고자 시도한다면 필드는 커진다.

출처 : Beginning Linux Programming 제3판 (정보문화사)

출처 : http://palantir.swarthmore.edu/maxwell/ ··· tutor%2F

Makefiles are a simple way to organize code compilation. This tutorial does not even scratch the surface of what is possible using make, but is intended as a starters guide so that you can quickly and easily create your own makefiles for small to medium-sized projects.

A Simple Example

Let's start off with the following three files, hellomake.c, hellofunc.c, and hellomake.h, which would represent a typical main program, some functional code in a separate file, and an include file, respectively.

#include 

int main() {
  // call a function in another file
  myPrintHelloMake();

  return(0);
}

#include 
#include 

void myPrintHelloMake(void) {

  printf("Hello makefiles!\n");

  return;
}

/*
example include file
*/

void myPrintHelloMake(void);

Normally, you would compile this collection of code by executing the following command:

gcc -o hellomake hellomake.c hellofunc.c -I.

This compiles the two .c files and names the executable hellomake. The -I. is included so that gcc will look in the current directory (.) for the include file hellomake.h. Without a makefile, the typical approach to the test/modify/debug cycle is to use the up arrow in a terminal to go back to your last compile command so you don't have to type it each time, especially once you've added a few more .c files to the mix.

Unfortunately, this approach to compilation has two downfalls. First, if you lose the compile command or switch computers you have to retype it from scratch, which is inefficient at best. Second, if you are only making changes to one .c file, recompiling all of them every time is also time-consuming and inefficient. So, it's time to see what we can do with a makefile.

The simplest makefile you could create would look something like:

hellomake: hellomake.c hellofunc.c
     gcc -o hellomake hellomake.c hellofunc.c -I.

If you put this rule into a file called Makefile or makefile and then type make on the command line it will execute the compile command as you have written it in the makefile. Note that make with no arguments executes the first rule in the file. Furthermore, by putting the list of files on which the command depends on the first line after the :, make knows that the rule hellomake needs to be executed if any of those files change. Immediately, you have solved problem #1 and can avoid using the up arrow repeatedly, looking for your last compile command. However, the system is still not being efficient in terms of compiling only the latest changes.

One very important thing to note is that there is a tab before the gcc command in the makefile. There must be a tab at the beginning of any command, and make will not be happy if it's not there.

In order to be a bit more efficient, let's try the following:

CC=gcc
CFLAGS=-I.

hellomake: hellomake.o hellofunc.o
     $(CC) -o hellomake hellomake.o hellofunc.o -I.

So now we've defined some constants CC and CFLAGS. It turns out these are special constants that communicate to make how we want to compile the files hellomake.c and hellofunc.c. In particular, the macro CC is the C compiler to use, and CFLAGS is the list of flags to pass to the compilation command. By putting the object files--hellomake.o and hellofunc.o--in the dependency list and in the rule, make knows it must first compile the .c versions individually, and then build the executable hellomake.

Using this form of makefile is sufficient for most small scale projects. However, there is one thing missing: dependency on the include files. If you were to make a change to hellomake.h, for example, make would not recompile the .c files, even though they needed to be. In order to fix this, we need to tell make that all .c files depend on certain .h files. We can do this by writing a simple rule and adding it to the makefile.

CC=gcc
CFLAGS=-I.
DEPS = hellomake.h

%.o: %.c $(DEPS)
	$(CC) -c -o $@ $< $(CFLAGS)

hellomake: hellomake.o hellofunc.o 
	gcc -o hellomake hellomake.o hellofunc.o -I.

This addition first creates the macro DEPS, which is the set of .h files on which the .c files depend. Then we define a rule that applies to all files ending in the .o suffix. The rule says that the .o file depends upon the .c version of the file and the .h files included in the DEPS macro. The rule then says that to generate the .o file, make needs to compile the .c file using the compiler defined in the CC macro. The -c flag says to generate the object file, the -o $@ says to put the output of the compilation in the file named on the left side of the :, the $< is the first item in the dependencies list, and the CFLAGS macro is defined as above.

As a final simplification, let's use the special macros $@ and $^, which are the left and right sides of the :, respectively, to make the overall compilation rule more general. In the example below, all of the include files should be listed as part of the macro DEPS, and all of the object files should be listed as part of the macro OBJ.

CC=gcc
CFLAGS=-I.
DEPS = hellomake.h
OBJ = hellomake.o hellofunc.o 

%.o: %.c $(DEPS)
	$(CC) -c -o $@ $< $(CFLAGS)

hellomake: $(OBJ)
	gcc -o $@ $^ $(CFLAGS)

So what if we want to start putting our .h files in an include directory, our source code in a src directory, and some local libraries in a lib directory? Also, can we somehow hide those annoying .o files that hang around all over the place? The answer, of course, is yes. The following makefile defines paths to the include and lib directories, and places the object files in an obj subdirectory within the src directory. It also has a macro defined for any libraries you want to include, such as the math library -lm. This makefile should be located in the src directory. Note that it also includes a rule for cleaning up your source and object directories if you type make clean. The .PHONY rule keeps make from doing something with a file named clean.

IDIR =../include
CC=gcc
CFLAGS=-I$(IDIR)

ODIR=obj
LDIR =../lib

LIBS=-lm

_DEPS = hellomake.h
DEPS = $(patsubst %,$(IDIR)/%,$(_DEPS))

_OBJ = hellomake.o hellofunc.o 
OBJ = $(patsubst %,$(ODIR)/%,$(_OBJ))


$(ODIR)/%.o: %.c $(DEPS)
	$(CC) -c -o $@ $< $(CFLAGS)

hellomake: $(OBJ)
	gcc -o $@ $^ $(CFLAGS) $(LIBS)

.PHONY: clean

clean:
	rm -f $(ODIR)/*.o *~ core $(INCDIR)/*~ 

So now you have a perfectly good makefile that you can modify to manage small and medium-sized software projects. You can add multiple rules to a makefile; you can even create rules that call other rules. For more information on makefiles and the make function, check out the GNU Make Manual, which will tell you more than you ever wanted to know (really).

NAME

DESCRIPTION

Standard Signals

The entries in the "Action" column of the table specify the default action for the signal, as follows:

Term

Default action is to terminate the process.

Ign

Default action is to ignore the signal.

Core

Default action is to terminate the process and dump core.

Stop

Default action is to stop the process.

First the signals described in the original POSIX.1 standard.

The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.

Next the signals not in the POSIX.1 standard but described in SUSv2 and SUSv3 / POSIX 1003.1-2001.

Up to and including Linux 2.2, the default behaviour for SIGSYS, SIGXCPU, SIGXFSZ, and (on architectures other than SPARC and MIPS) SIGBUS was to terminate the process (without a core dump). (On some other Unices the default action for SIGXCPU and SIGXFSZ is to terminate the process without a core dump.) Linux 2.4 conforms to the POSIX 1003.1-2001 requirements for these signals, terminating the process with a core dump.

Next various other signals.

(Signal 29 is SIGINFO / SIGPWR on an alpha but SIGLOST on a sparc.)

SIGEMT is not specified in POSIX 1003.1-2001, but neverthless appears on most other Unices, where its default action is typically to terminate the process with a core dump.

SIGPWR (which is not specified in POSIX 1003.1-2001) is typically ignored by default on those other Unices where it appears.

SIGIO (which is not specified in POSIX 1003.1-2001) is ignored by default on several other Unices.

Real-time Signals

Unlike standard signals, real-time signals have no predefined meanings: the entire set of real-time signals can be used for application-defined purposes. (Note, however, that the LinuxThreads implementation uses the first three real-time signals.)

The default action for an unhandled real-time signal is to terminate the receiving process.

Real-time signals are distinguished by the following:

1.

Multiple instances of real-time signals can be queued. By contrast, if multiple instances of a standard signal are delivered while that signal is currently blocked, then only one instance is queued.

2.

If the signal is sent using sigqueue(2), an accompanying value (either an integer or a pointer) can be sent with the signal. If the receiving process establishes a handler for this signal using the SA_SIGACTION flag to sigaction(2) then it can obtain this data via the si_value field of the siginfo_t structure passed as the second argument to the handler. Furthermore, the si_pid and si_uid fields of this structure can be used to obtain the PID and real user ID of the process sending the signal.

3.

Real-time signals are delivered in a guaranteed order. Multiple real-time signals of the same type are delivered in the order they were sent. If different real-time signals are sent to a process, they are delivered starting with the lowest-numbered signal. (I.e., low-numbered signals have highest priority.)

If both standard and real-time signals are pending for a process, POSIX leaves it unspecified which is delivered first. Linux, like many other implementations, gives priority to standard signals in this case.

According to POSIX, an implementation should permit at least _POSIX_SIGQUEUE_MAX (32) real-time signals to be queued to a process. However, rather than placing a per-process limit, Linux imposes a system-wide limit on the number of queued real-time signals for all processes. This limit can be viewed (and with privilege) changed via the /proc/sys/kernel/rtsig-max file. A related file, /proc/sys/kernel/rtsig-max, can be used to find out how many real-time signals are currently queued.

CONFORMING TO

SEE ALSO

출처 : 시스템 로그 분석 (해킹 피해와 보안 추적의 결정적 파일) - 안정철 지음
(안정철 님에게 책 내용에 대해 발췌하는 것에 대해서 허락을 구하지 못하였습니다. 삭제를 요구하시면 바로 삭제 조취 하겠습니다.)

Session 01. 웹 로그 분석의 개요

인터넷의 대중화로 한 기업의 이미지를 대표함과 동시에 기업의 생존전략 도구로서 필수불가결한 것 중의 하나가 바로 사용자에게 실질적인 서비스를 제공해 주고 있는 웹 서버이다. 더욱이 시간이 흐르면서 지금의 상황에 반문이라도 하듯이 늘어나고 있는 방대한 양의 컨텐츠와 멀티미디어 서비스 등으로 인하여 인터넷에서의 웹 서버 역할은 날로 중요해지고 있다.

웹 서버를 운영하는 목적 중의 하나는 클라이언트에게 다양한 정보를 제공하는 역할을 수행하는 것이다. 그렇다면 관리자는 이러한 환경의 제공만으로 본연의 역할을 다한 것일까? 어떠한 목적으로의 운영을 결정하였는가에 따라, 이 질문에 대한 대답은 달라질것이며 필자의 입장에서는 클라이언트에게 더 나은 정보 및 환경을 제공하기 위한 방법의 하나로 웹 서버의 단순한 운영만으로는 시스템 운영자 또는 웹 마스터의 역할을 다한것이라고 생각하지 않는다.

한 예로 모 기업의 마케팅 부서 담당자 입장에서 생각해보면, 마케팅 담당자는 그 기업의 생산 계획에서 판매 계획에 이르기까지 전 과정을 체크해야 한다. 여기에 웹 사이트를 이용한 제품 및 여러 가지 홍보 등은 결코 빠질 수 없는 중요한 광고매체로 인식되고 있으며, 대부분의 담당자들은 웹사이트에 기록된 일종의 가공되지 않은 데이터를 원하지는 않을 것이다.

웹사이트를 방문한 사용자들의 정보가 필요로 하는 것에 따라 한눈에 파악하기 쉽도록 만들어지고, 많은 유용한 정보들을 포함하도록 한다면 곧 이러한 정보와 전통적인 데이터들의 통합된 정보는 마케팅적인 면에서 큰 장점을 가지고 있다는 것은 굳이 언급하지 않아도 알 수 있다. 효과적인 광고, 웹사이트에서의 방문자 행동, 구매비율과 같이 총체적으로 이미 분석된 정보를 활용할 수가 있다. 이러한 모든 것들이 현재의 마케팅의 이해와 함께 웹사이트의 분석에 마케팅적으로 이용될 수 있는 부분으로 시장에서 새로운 비즈니스로서 성장하고 있다.

웹 서버의 로그 파일은 초기에 문제의 진단 및 처리량 등의 파악에 이용될 목적으로 디자인되었으나, 지금과 같이 웹사이트의 성능 개선 및 다양한 곳에 이용되리라고는 예상하지 못했다. 현 상에서의 이와 같은 모든 로그 정보들이 웹사이트 운영에 중요한 정보로서 자리매김하였으며, 이는 단순히 접속되는 데이터로 모든 방문객과 모든 페이지에 대해 기록할 수 있게 하여 웹사이트 내에 누군지는 모르지만 수많은 방문객에 관계없이 웹 서버는 바쁘게 움직이고 있다. 이제 필자가 여러분들과 함께 웹 로그의 중요성을 설명한 만큼 아파치 웹 서버에서 제공하는 로그의 이해에 기본을 두고 방문자 정보 분석에 첫 발걸음을 내딛어보자!

01. 어떠한 정보를 이용할 수 있을까?
시작하기에 앞서 여러분들은 웹 서버에서 제공하는 정보로는 어떠한 것이 가능한지 알아야 한다. 아파치 웹 서버는 클라이언트가 요청하는 모든 정보를 로그 파일에 기록하게 되고, 기록된 여러 다양한 정보는 다음을 포함하여 분석을 하게 된다.

1. 원격접근 호스트의 주소
이것은 "누가 나의 웹사이트를 방문했는가" 와도 비슷하다고 할 수 있다. 좀 더 자세히 말하자면, 방문자가 어디에서 접속했는지를 말해준다.

2. 방문횟수 및 시간
방문자가 얼마나 자주 웹사이트를 방문했는가를 알려준다. 주로 오전 9시부터 오후 6시까지의 업무시간 사이에 많은 방문이 이루어진다고 생각할 수 있고, 그렇지 않은 이외의 시간은 집에서의 접속으로 추정할 수가 있다.

3. 요청한 웹 서버의 자원
사이트에서 가장 인기 있는 페이지는 어디일까? 클라이언트가 요청한 자원의 정보를 기록하여 운영자는 어느 부분이 가장 인기 있는 부분이며, 또 그렇지 않은 부분을 판별할 수가 있다.

4. 방문자의 운영체제(Operating System), 브라우저 그리고 브라우저 버전
여러분들의 사이트를 방문하는 사용자가 Mac 또는 PC를 이용한 접속이 몇 %나 될까? 또는 넷스케이프, 인터넷 익스플로러를 이용한 퍼센트는 기본 정보 이외의 'User Agent'정보를 이용하여 방문자의 부가적인 정보를 얻을 수 있다. 위와 같은 정보들은 정확하지 않을 수도 있으나, 완벽히 신뢰하지 못할 만큼은 아니다. 이 뜻은 웹 서버의 로그 자료에만 너무 의존하지 말아야 한다는 점이다. 어떤 페이지에 어느 정도의 사용자가 방문했는지 정확히 알ㄹ줄 수 있을까? 물론 수치상으로 기록된 정보로는 그렇지만, 프록시 캐쉬 등을 이용한 경우에는 웹 서버에 직접적으로 접근하지 않으므로 로그에 기록되지 않을 수가 있다.

비록 이러한 데이터들이 정확하지 않더라도 여러분들의 사이트를 얼마나 방문하는지 등의 대략적인 정보로 사용할 수가 있기 때문에 웹 서버의 로그 파일이 중요한 역할을 한다는 것은 의심할 여지가 없다.

02. 로그 파일은 어떻게 작동되나?
매 시간 웹사이트의 모든 정보는 웹 서버에 의해 파일로 기록된다. 아파치 웹 서버는 이 정보를 접속 로그, 에러 로그 등으로 불리는 다양한 형태로 저장한다. 로그 파일에는 어느 시간에 어떤 페이지를 요청했는지의 기록뿐만 아니라, 클라이언트가 요청한 것에 대한 추가적인 여러 유용한 정보들이 존재한다. 아파치를 설치하면 기본적으로 두개의 파일이 쓰이며, 이중의 하나는 access_log이고, 다른 하나는 error_log이다.

이 파일들은 아파치의 기본 설치에 따라 '/usr/local/apache/logs'에 위치하게 되며, 설정 파일을 통해 로그 파일의 위치는 변경이 가능하다. 이전의 버전에서는 로그 파일이 내용에 따라 다음과 같이 두 가지로 나누어져 있었으나, 현재의 1.3.x에서는 차후 설명할 mod_log_config에 따라 통합적인 방법의 사용이 가능하였다.

• 접속로그
• 에러 로그

접속 로그는 웹 서버로부터 전송되는 정보가 기록되는 것으로 여러 페이지 중의 하나를 방문한 사용자가 어떤 링크를 통하여 혹은 배너를 통하여 접속하게 되었는지의 정보 등을 알 수 있다. 이러한 정보는 여러분들이 방문자의 관심 사항을 간접적으로나마 파악할 수 있게 한다.

아울러 온라인 광고를 하는 경우 이 정보를 이용하여 어느 사이트에 배너 광고를 해야 효율적인가를 결정할 수 있고 더불어 기업의 입장에서는 어떠한 사이트와 좋은 관계를 유지해야 하는가의 판별력에도 도움을 줄 것이다. 클라이언트가 사용한 브라우저에 대한 정보를 에이전트 로그에 기록되며, 웹 서버 운영상에 나타나는 에러 또는 CGI 스크립트 실행 시 발생되는 문제점은 에러 로그 파일에 쓰여진다.