sudo apt-get update
sudo apt-get upgrade
sudo add-apt-repository "deb http://archive.zentyal.org/zentyal 5.1 main extra"
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 10E239FF wget -q http://keys.zentyal.org/zentyal-5.1-archive.asc -O- | sudo apt-key add -
sudo apt-get update
sudo apt-get install zentyal
2019/02/27
2019/02/11
우분투 설치 이미지 관련
우분투 설치 이미지 관련
http://archive.ubuntu.com/ubuntu/dists/bionic-updates/main/installer-amd64/current/images/
Live : CD/DVD 또는 USB에서 부팅
cdrom : CD로 부팅후 HDD 설치.
hd-media: ISO 부팅 후 HDD 설치.
영국의 캐노니컬에서 개발하는 우분투 14.04 리눅스 커널의 새로운 기능 추가나 버그 수정 또는 보안 취약점 문제 해결한 HWE 커널 4.4.0-119 버전이 업데이트를 통해 배포
*LTS : Long Term Support - 5년 간의 장기 지원
*HWE : Hardware Enablement - 하드웨어 지원 강화를 위한 커널로, 6개월마다 4번에 걸쳐 판올림하면서 지원
*GA : General Availability - 출시 당시의 커널로, 5년 간 판올림 없이 지원
hwe-cdrom: CD로 부팅후 HDD 설치.
hwe-hd-media: ISO 부팅 후 HDD 설치.
hwe-netboot: 네트워을 통한 설치
http://archive.ubuntu.com/ubuntu/dists/bionic-updates/main/installer-amd64/current/images/
Live : CD/DVD 또는 USB에서 부팅
cdrom : CD로 부팅후 HDD 설치.
hd-media: ISO 부팅 후 HDD 설치.
영국의 캐노니컬에서 개발하는 우분투 14.04 리눅스 커널의 새로운 기능 추가나 버그 수정 또는 보안 취약점 문제 해결한 HWE 커널 4.4.0-119 버전이 업데이트를 통해 배포
*LTS : Long Term Support - 5년 간의 장기 지원
*HWE : Hardware Enablement - 하드웨어 지원 강화를 위한 커널로, 6개월마다 4번에 걸쳐 판올림하면서 지원
*GA : General Availability - 출시 당시의 커널로, 5년 간 판올림 없이 지원
hwe-cdrom: CD로 부팅후 HDD 설치.
hwe-hd-media: ISO 부팅 후 HDD 설치.
hwe-netboot: 네트워을 통한 설치
2019/01/11
D-Bus 보안, 세션, 오브젝트, 서비스, 커널 이벤트, API
보안 (systemwide mode of message bus)
D-Bus의 개념
D-Bus는 몇가지 버스로 구성된다.
system bus:
부팅 시간에 시작함. 이 버스는 운영체제와 데몬들에의해 사용됨.
임의의 응용프로그램들이 시스템 이벤트를 spoof하지 못하도록 보안이 되어있음.
session bus:
사용자 로긴시에 동작함(private).
사용자 응용프로그램에서의 session bus는 통신에 주로 사용된다.
시스템 버스로 부터 메세지를 받을 수 있으며, 반대로 보내는 것에는 제약이 있다.
Objects, Messages, Services의 개념도 알아둘 필요가 있다.
Objects
- D-Bus는 주고 받는 모든 메세지의 소스와 목적지가 있는 peer-to-peer 프로토콜이다.
메세지를 주고 받는데 쓰이는 주소들은 object path로 나타낸다.
Objects의 집합을 가진 D-Bus를 사용하는 모든 응용프로그램들에서 메세지들은 어플리케이션이 아닌 특정한 objects로 전달되거나 그것으로 부터 전송받으며 object path로 구분한다.
모든 object들은 하나 혹은 그 이상의 인터페이스를 제공하는데, 인터페이스는 메쏘드 이름의 namespace로 사용되며 단일 object는 여러 메쏘드를 가지고, 메쏘드는 여러 인터페이스를 가진다.
object ---- method 1 ---- interface 1
---- interface 2
---- method 2
---- method 3
Messages
header와 body로 구성됨.
header:
message의 meta data. routing information, 데이터(body)의 타입.(네가지 타입의 메세지가 존재함)
method calls, method returns, signals, errors
data: type code + data + type code + data ... (type: byte/32bit/64bit integer/doubles/strings)
Services
- D-Bus에서 가장 상위 레벨로 현재 계속적으로 구현중에 있다.
응용프로그램은 버스에 service를 등록할 수 있고, 등록에 성공하면 service를 획득하게 된다.
다른 응용프로그램들은 특정한 service가 버스에 존재하는지 검사할 수 있고 그 service가 아직 시작전이면 시작할 수 있는지 버스에 문의할 수 있다. (org.freedesktop.DBus)
Native Objects 와 Object Paths
java나 python, GObject와 같은 native object를 사용하지 않고,
Low-level D-Bus 프로토콜과 libdbus API에서도 native object 대신 object path라는 native object 들을 higher-level binding한것을 제공한다. (/org/kde/kspread/sheets/3/cells/4/5)
Methods 와 Signals
Object들은 두 멤버를 가지는데, method와 signal이다.
Method는 Object안에서 발생하는 것이고, signal은 object로 부터 그 object를 주시하고 있는(관계된) 서비스? 들에게 broadcast 되는 것을 말한다.
Interfaces
인터페이스는 method와 signal의 그룹으로 이름이 지어지는데,
Glib, Qt, Java에서 사용된다. (org.freedesktop.DBus.Introspectable)
Proxies
다른 프로세스에 있는 (remote) object들이 proxy를 통해 버스의 object에 접근할 수 있다.
Proxy를 호출하게 되면 D-Bus는 method 호출, reply message를 기다리고, return value, return from native method.
proxy를 사용하지 않는 경우는 다음과 같이 프로그램할 수 있다.
<pre>
Message message = new Message("/remote/object/path", "MethodName", arg1, arg2);
Connection connection = getBusConnection();
connection.send(message);
Message reply = connection.waitForReply(message);
if (reply.isError()) {
} else {
Object returnValue = reply.getReturnValue();
}
</pre>
Proxy를 사용한 경우
<pre>
Proxy proxy = new Proxy(getBusConnection(), "/remote/object/path");
Object returnValue = proxy.MethodName(arg1, arg2);
</pre>
Bus Names
각 응용프로그램들은 bus daemon으로 연결되며 daemon은 unique한 이름을 할당한다.
: (콜론)으로 시작되는 bus 이름은 데몬이 살아있는 동안은 재사용되지 않는다.
그것은 응용프로그램으로 부터 같은 이름으로 반복적으로 호출되기 때문이다.
한 예를들면 :34-907 이라고 할당이 되는데, 콜론뒤의 번호는 특별한 의미를 지니지는 않는다.
Addresses
D-Bus의 주소는 서버 측에서는 듣는것으로,
클라이언트에서는 접속하는 용도로 쓰인다.
Message bus daemon을 쓰는 경우에는 libdbus는 자동으로 환경변수를 읽어 bus daemon의 주소를 알아온다.
Big Conceptual Picture
<pre>
Address -> [Bus Name] -> Path -> Interface -> Method
Messages - Behind the Scenes
Calling a Method - Behind the Scenes
Emitting a Signal - Behind the Scenes
Introspection
</pre>
Kernel Event Layer
kernel event layer는 고속의 netlink socket을 사용한 사용자 영역으로의 비동기 kernel-to-user 통신 메카니즘인데,
이 메카니즘은 커널이 D-Bus signal을 보낼 수 있도록 D-Bus에 포함시킬 수 있다.
실행 예
<pre>
#include <dbus/dbus.h>
DBusError error;
DBusConnection *conn;
dbus_error_init (&error);
conn = dbus_bus_get (DBUS_BUS_SYSTEM, &error);
if (!conn) {
fprintf (stderr, "%s: %s\n",
err.name, err.message);
return 1;
}
dbus_bus_acquire_service (conn, "org.pirate.parrot", 0, &err);
if (dbus_error_is_set (&err)) {
fprintf (stderr, "%s: %s\n",
err.name, err.message);
dbus_connection_disconnect (conn);
return;
}
DBusMessage *msg;
DBusMessageIter iter;
/* create a new message of type signal */
msg = dbus_message_new_signal(
"org/pirate/parrot/attr",
"org.pirate.parrot.attr", "Feathers");
/* build the signal's payload up */
dbus_message_iter_init (msg, &iter);
dbus_message_iter_append_string (&iter, "Shiny");
dbus_message_iter_append_string (&iter,
"Well Groomed");
/* send the message */
if (!dbus_connection_send (conn, msg, NULL))
fprintf (stderr, "error sending message\n");
/* drop the reference count on the message */
dbus_message_unref (msg);
/* flush the connection buffer */
dbus_connection_flush (conn);
if (conn)
dbus_connection_disconnect (conn);
</pre>
D-BUS API
개요
D-BUS 를 이용한 간단한 샘플 프로그램을 확인 후 실제로 사용하는 API 에 대해 알아본다.
D-BUS 라이브러리
http://dbus.freedesktop.org/doc/dbus/api/html/modules.html
API 정리
DBusServer
DBusWatchList watchs list : 변수를 read/write 콜백함수가 호출되도록 함 - dbus_watch_handle(watch, flags) 함수 호출시 콜백함수가 동작함.
DBusTimeoutList timeout : 주기적으로 동작할 함수를 등록함.
dbus_server_init_base () / dbus_server_listen() 함수 호출에 의해 생성되는 서버측 정보를 가짐
hal 모듈에서는 서버 구조체를 이용하여 작업
powersave 모듈은 서버 구조체를 이용하지 않도록 되어 있음
DBusConnection
#define DBUS_PATH_DBUS "/org/freedesktop/DBus"
#define DBUS_SERVICE_DBUS "org.freedesktop.DBus"
#define DBUS_PATH_LOCAL "/org/freedesktop/DBus/Local"
enum DBusBusType
DBUS_BUS_SESSION - The login session bus.
DBUS_BUS_SYSTEM - The systemwide bus.
DBUS_BUS_STARTER
- dbus_bus_get()
- 시스템 디폴트 값을 이용 (환경 변수 이용)
- 이미 알려진 메시지 버스를 자동으로 open 할때 사용함.
- connection_try_from_address_entry()
- 직접 어드레스 정보를 이용하여 connection을 생성함
- dbus_bus_request_name (DBusConnection *connection, const char *name, unsigned int flags, DBusError *error)
- DBUS_SERVICE_DBUS 에서 RequestName method 를 호출하여 name 이 등록되어 있는지 확인하고 등록한다.
- dbus_bus_add_match(DBusConnection *connection, const char *rule, DBusError *error)
- DBUS_SERVICE_DBUS 에서 AddMatch method 를 호출하여 rule 에 맞는 메시지만을 받을 수 있도록 한다.
- dbus_connection_send (DBusConnection *connection, DBusMessage *message, dbus_uint32_t *serial)
- 메시지를 전송하고 블럭킹되지 않고 다음 작업을 진행한다.
- dbus_connection_send_with_reply (DBusConnection *connection, DBusMessage *message, DBusPendingCall **pending_return, int timeout_milliseconds)
- 메시지를 전송후 reply 가 오거나 timeout이 발생할 경우의 동작할 pending을 등록한다. (논블록킹)
- dbus_connection_read_write (DBusConnection *connection, int timeout_milliseconds)
- 논블로킹 모드로 메시지를 쓰거나 읽는다.
- dbus_connection_pop_message (DBusConnection *connection)
- 메시지를 하나씩 얻어 온다.
DBusMessage
DBUS_MESSAGE_TYPE_INVALID 0
DBUS_MESSAGE_TYPE_METHOD_CALL 1
DBUS_MESSAGE_TYPE_METHOD_RETURN 2
DBUS_MESSAGE_TYPE_ERROR 3
DBUS_MESSAGE_TYPE_SIGNAL 4
- dbus_message_new_signal (const char *path, const char *interface, const char *name)
- 시그널 메시지를 생성한다.
- dbus_message_new_method_call(const char *destination, const char *path, const char *interface, const char *method)
- 메쏘드 메시지를 생성한다.
- dbus_message_new_method_return(DBusMessage *method_call)
- DBUS_MESSAGE_TYPE_METHOD_RETURN 타입의 메시지를 생성한다.
DBusMessageIter
- dbus_message_iter_init_append (DBusMessage *message, DBusMessageIter *iter)
- 메시지에 가변 변수가 등록 가능하도록 초기화한다
- dbus_message_iter_append_basic (DBusMessageIter *iter, int type, const void *value)
- 메시지에 변수타입과 값을 추가한다.
DBusError
error.message 를 변수를 직접 접근하여 에러메시지를 얻을 수 있다.
- dbus_error_init (DBusError *error)
- dbus_error_is_set (const DBusError *error)
- dbus_error_free(DBusError *error)
DBusPendingCall
- dbus_pending_call_block(DBusPendingCall *pending)
- 콜백함수가 완료 될때까지 블럭킹된다
- dbus_pending_call_steal_reply(DBusPendingCall *pending)
- Reply 값을 반환한다.
DBusAddressEntry
method : unix, tcp ...
key : path, tmpdir, abstract ...
value
Gnome Screen Saver 메시지 예
dbus-monitor 를 실행하여 dbus 메시지를 확인
signal sender=:1.11 -> dest=(null destination) path=/org/gnome/ScreenSaver; interface=org.gnome.ScreenSaver; member=SessionPowerManagementIdleChanged boolean false
signal sender=:1.11 -> dest=(null destination) path=/org/gnome/ScreenSaver; interface=org.gnome.ScreenSaver; member=SessionPowerManagementIdleChanged boolean false
D-Bus의 개념
D-Bus는 몇가지 버스로 구성된다.
system bus:
부팅 시간에 시작함. 이 버스는 운영체제와 데몬들에의해 사용됨.
임의의 응용프로그램들이 시스템 이벤트를 spoof하지 못하도록 보안이 되어있음.
session bus:
사용자 로긴시에 동작함(private).
사용자 응용프로그램에서의 session bus는 통신에 주로 사용된다.
시스템 버스로 부터 메세지를 받을 수 있으며, 반대로 보내는 것에는 제약이 있다.
Objects, Messages, Services의 개념도 알아둘 필요가 있다.
Objects
- D-Bus는 주고 받는 모든 메세지의 소스와 목적지가 있는 peer-to-peer 프로토콜이다.
메세지를 주고 받는데 쓰이는 주소들은 object path로 나타낸다.
Objects의 집합을 가진 D-Bus를 사용하는 모든 응용프로그램들에서 메세지들은 어플리케이션이 아닌 특정한 objects로 전달되거나 그것으로 부터 전송받으며 object path로 구분한다.
모든 object들은 하나 혹은 그 이상의 인터페이스를 제공하는데, 인터페이스는 메쏘드 이름의 namespace로 사용되며 단일 object는 여러 메쏘드를 가지고, 메쏘드는 여러 인터페이스를 가진다.
object ---- method 1 ---- interface 1
---- interface 2
---- method 2
---- method 3
Messages
header와 body로 구성됨.
header:
message의 meta data. routing information, 데이터(body)의 타입.(네가지 타입의 메세지가 존재함)
method calls, method returns, signals, errors
data: type code + data + type code + data ... (type: byte/32bit/64bit integer/doubles/strings)
Services
- D-Bus에서 가장 상위 레벨로 현재 계속적으로 구현중에 있다.
응용프로그램은 버스에 service를 등록할 수 있고, 등록에 성공하면 service를 획득하게 된다.
다른 응용프로그램들은 특정한 service가 버스에 존재하는지 검사할 수 있고 그 service가 아직 시작전이면 시작할 수 있는지 버스에 문의할 수 있다. (org.freedesktop.DBus)
Native Objects 와 Object Paths
java나 python, GObject와 같은 native object를 사용하지 않고,
Low-level D-Bus 프로토콜과 libdbus API에서도 native object 대신 object path라는 native object 들을 higher-level binding한것을 제공한다. (/org/kde/kspread/sheets/3/cells/4/5)
Methods 와 Signals
Object들은 두 멤버를 가지는데, method와 signal이다.
Method는 Object안에서 발생하는 것이고, signal은 object로 부터 그 object를 주시하고 있는(관계된) 서비스? 들에게 broadcast 되는 것을 말한다.
Interfaces
인터페이스는 method와 signal의 그룹으로 이름이 지어지는데,
Glib, Qt, Java에서 사용된다. (org.freedesktop.DBus.Introspectable)
Proxies
다른 프로세스에 있는 (remote) object들이 proxy를 통해 버스의 object에 접근할 수 있다.
Proxy를 호출하게 되면 D-Bus는 method 호출, reply message를 기다리고, return value, return from native method.
proxy를 사용하지 않는 경우는 다음과 같이 프로그램할 수 있다.
<pre>
Message message = new Message("/remote/object/path", "MethodName", arg1, arg2);
Connection connection = getBusConnection();
connection.send(message);
Message reply = connection.waitForReply(message);
if (reply.isError()) {
} else {
Object returnValue = reply.getReturnValue();
}
</pre>
Proxy를 사용한 경우
<pre>
Proxy proxy = new Proxy(getBusConnection(), "/remote/object/path");
Object returnValue = proxy.MethodName(arg1, arg2);
</pre>
Bus Names
각 응용프로그램들은 bus daemon으로 연결되며 daemon은 unique한 이름을 할당한다.
: (콜론)으로 시작되는 bus 이름은 데몬이 살아있는 동안은 재사용되지 않는다.
그것은 응용프로그램으로 부터 같은 이름으로 반복적으로 호출되기 때문이다.
한 예를들면 :34-907 이라고 할당이 되는데, 콜론뒤의 번호는 특별한 의미를 지니지는 않는다.
Addresses
D-Bus의 주소는 서버 측에서는 듣는것으로,
클라이언트에서는 접속하는 용도로 쓰인다.
Message bus daemon을 쓰는 경우에는 libdbus는 자동으로 환경변수를 읽어 bus daemon의 주소를 알아온다.
Big Conceptual Picture
<pre>
Address -> [Bus Name] -> Path -> Interface -> Method
Messages - Behind the Scenes
Calling a Method - Behind the Scenes
Emitting a Signal - Behind the Scenes
Introspection
</pre>
Kernel Event Layer
kernel event layer는 고속의 netlink socket을 사용한 사용자 영역으로의 비동기 kernel-to-user 통신 메카니즘인데,
이 메카니즘은 커널이 D-Bus signal을 보낼 수 있도록 D-Bus에 포함시킬 수 있다.
실행 예
<pre>
#include <dbus/dbus.h>
DBusError error;
DBusConnection *conn;
dbus_error_init (&error);
conn = dbus_bus_get (DBUS_BUS_SYSTEM, &error);
if (!conn) {
fprintf (stderr, "%s: %s\n",
err.name, err.message);
return 1;
}
dbus_bus_acquire_service (conn, "org.pirate.parrot", 0, &err);
if (dbus_error_is_set (&err)) {
fprintf (stderr, "%s: %s\n",
err.name, err.message);
dbus_connection_disconnect (conn);
return;
}
DBusMessage *msg;
DBusMessageIter iter;
/* create a new message of type signal */
msg = dbus_message_new_signal(
"org/pirate/parrot/attr",
"org.pirate.parrot.attr", "Feathers");
/* build the signal's payload up */
dbus_message_iter_init (msg, &iter);
dbus_message_iter_append_string (&iter, "Shiny");
dbus_message_iter_append_string (&iter,
"Well Groomed");
/* send the message */
if (!dbus_connection_send (conn, msg, NULL))
fprintf (stderr, "error sending message\n");
/* drop the reference count on the message */
dbus_message_unref (msg);
/* flush the connection buffer */
dbus_connection_flush (conn);
if (conn)
dbus_connection_disconnect (conn);
</pre>
D-BUS API
개요
D-BUS 를 이용한 간단한 샘플 프로그램을 확인 후 실제로 사용하는 API 에 대해 알아본다.
D-BUS 라이브러리
http://dbus.freedesktop.org/doc/dbus/api/html/modules.html
API 정리
DBusServer
DBusWatchList watchs list : 변수를 read/write 콜백함수가 호출되도록 함 - dbus_watch_handle(watch, flags) 함수 호출시 콜백함수가 동작함.
DBusTimeoutList timeout : 주기적으로 동작할 함수를 등록함.
dbus_server_init_base () / dbus_server_listen() 함수 호출에 의해 생성되는 서버측 정보를 가짐
hal 모듈에서는 서버 구조체를 이용하여 작업
powersave 모듈은 서버 구조체를 이용하지 않도록 되어 있음
DBusConnection
#define DBUS_PATH_DBUS "/org/freedesktop/DBus"
#define DBUS_SERVICE_DBUS "org.freedesktop.DBus"
#define DBUS_PATH_LOCAL "/org/freedesktop/DBus/Local"
enum DBusBusType
DBUS_BUS_SESSION - The login session bus.
DBUS_BUS_SYSTEM - The systemwide bus.
DBUS_BUS_STARTER
- dbus_bus_get()
- 시스템 디폴트 값을 이용 (환경 변수 이용)
- 이미 알려진 메시지 버스를 자동으로 open 할때 사용함.
- connection_try_from_address_entry()
- 직접 어드레스 정보를 이용하여 connection을 생성함
- dbus_bus_request_name (DBusConnection *connection, const char *name, unsigned int flags, DBusError *error)
- DBUS_SERVICE_DBUS 에서 RequestName method 를 호출하여 name 이 등록되어 있는지 확인하고 등록한다.
- dbus_bus_add_match(DBusConnection *connection, const char *rule, DBusError *error)
- DBUS_SERVICE_DBUS 에서 AddMatch method 를 호출하여 rule 에 맞는 메시지만을 받을 수 있도록 한다.
- dbus_connection_send (DBusConnection *connection, DBusMessage *message, dbus_uint32_t *serial)
- 메시지를 전송하고 블럭킹되지 않고 다음 작업을 진행한다.
- dbus_connection_send_with_reply (DBusConnection *connection, DBusMessage *message, DBusPendingCall **pending_return, int timeout_milliseconds)
- 메시지를 전송후 reply 가 오거나 timeout이 발생할 경우의 동작할 pending을 등록한다. (논블록킹)
- dbus_connection_read_write (DBusConnection *connection, int timeout_milliseconds)
- 논블로킹 모드로 메시지를 쓰거나 읽는다.
- dbus_connection_pop_message (DBusConnection *connection)
- 메시지를 하나씩 얻어 온다.
DBusMessage
DBUS_MESSAGE_TYPE_INVALID 0
DBUS_MESSAGE_TYPE_METHOD_CALL 1
DBUS_MESSAGE_TYPE_METHOD_RETURN 2
DBUS_MESSAGE_TYPE_ERROR 3
DBUS_MESSAGE_TYPE_SIGNAL 4
- dbus_message_new_signal (const char *path, const char *interface, const char *name)
- 시그널 메시지를 생성한다.
- dbus_message_new_method_call(const char *destination, const char *path, const char *interface, const char *method)
- 메쏘드 메시지를 생성한다.
- dbus_message_new_method_return(DBusMessage *method_call)
- DBUS_MESSAGE_TYPE_METHOD_RETURN 타입의 메시지를 생성한다.
DBusMessageIter
- dbus_message_iter_init_append (DBusMessage *message, DBusMessageIter *iter)
- 메시지에 가변 변수가 등록 가능하도록 초기화한다
- dbus_message_iter_append_basic (DBusMessageIter *iter, int type, const void *value)
- 메시지에 변수타입과 값을 추가한다.
DBusError
error.message 를 변수를 직접 접근하여 에러메시지를 얻을 수 있다.
- dbus_error_init (DBusError *error)
- dbus_error_is_set (const DBusError *error)
- dbus_error_free(DBusError *error)
DBusPendingCall
- dbus_pending_call_block(DBusPendingCall *pending)
- 콜백함수가 완료 될때까지 블럭킹된다
- dbus_pending_call_steal_reply(DBusPendingCall *pending)
- Reply 값을 반환한다.
DBusAddressEntry
method : unix, tcp ...
key : path, tmpdir, abstract ...
value
Gnome Screen Saver 메시지 예
dbus-monitor 를 실행하여 dbus 메시지를 확인
signal sender=:1.11 -> dest=(null destination) path=/org/gnome/ScreenSaver; interface=org.gnome.ScreenSaver; member=SessionPowerManagementIdleChanged boolean false
signal sender=:1.11 -> dest=(null destination) path=/org/gnome/ScreenSaver; interface=org.gnome.ScreenSaver; member=SessionPowerManagementIdleChanged boolean false
D-Bus IPC 통신
데스크탑 세션과 운영체제(Operating System)와의 통신
- 여기서 운영체제라고 하면 커널과 시스템 데몬까지를 포함한다.
예를들어, 디바이스가 연결되었을때, D-Bus는 udev를 가동시킨다.
이것은 데스크탑의 하드웨어와의 더욱 긴밀한 결합을 가져왔다.
다른 IPC 시스템과 구분되는 D-Bus의 장점은 다음과 같다.
비동기적으로 사용할 수 있도록 디자인 된 바이너리 프로토콜
stateful(서버와 클라이언트가 연결하면서 계속 클라이언트와의 상태를 유지하는 것), 신뢰성있는 연결 message bus 가 daemon 형식
구조나 문법등이 DCOP과 흡사하여 KDE에서 사용이 용이함
- 여기서 운영체제라고 하면 커널과 시스템 데몬까지를 포함한다.
예를들어, 디바이스가 연결되었을때, D-Bus는 udev를 가동시킨다.
이것은 데스크탑의 하드웨어와의 더욱 긴밀한 결합을 가져왔다.
다른 IPC 시스템과 구분되는 D-Bus의 장점은 다음과 같다.
비동기적으로 사용할 수 있도록 디자인 된 바이너리 프로토콜
stateful(서버와 클라이언트가 연결하면서 계속 클라이언트와의 상태를 유지하는 것), 신뢰성있는 연결 message bus 가 daemon 형식
구조나 문법등이 DCOP과 흡사하여 KDE에서 사용이 용이함
d-bus 응용
D-Bus 응용
D-Bus는 다음의 두가지 특별한 경우를 위해 디자인되었다.
같은 데스크탑 세션안에서 데스크탑 응용프로그램간의 통신 (데스크탑 세션의 통합)
- 데스크탑에서는 여러 프로그램들이 동시에 실행된다.
또 서로 통신하기를 원한다.
DCOP은 KDE를 위해 만들어졌지만, QT이외에 다른 환경에서는 적용이 힘들다.
Bonobo는 GNOME을 위해 만들어졌지만 덩치가 크고, GNOME이외에서는 사용하기 힘들다.
D-Bus는 이런 DCOP과 Bonobo를 대체하여 두 데스크탑 환경을 통합하고 좀더 단순한 IPC를 위해 만들어졌다.
D-Bus에 대한 의존성을 굉장히 작기 때문에 D-Bus를 사용하고자 하는 다른 응용프로그램들은 걱정할 필요가 없다.
D-Bus는 다음의 두가지 특별한 경우를 위해 디자인되었다.
같은 데스크탑 세션안에서 데스크탑 응용프로그램간의 통신 (데스크탑 세션의 통합)
- 데스크탑에서는 여러 프로그램들이 동시에 실행된다.
또 서로 통신하기를 원한다.
DCOP은 KDE를 위해 만들어졌지만, QT이외에 다른 환경에서는 적용이 힘들다.
Bonobo는 GNOME을 위해 만들어졌지만 덩치가 크고, GNOME이외에서는 사용하기 힘들다.
D-Bus는 이런 DCOP과 Bonobo를 대체하여 두 데스크탑 환경을 통합하고 좀더 단순한 IPC를 위해 만들어졌다.
D-Bus에 대한 의존성을 굉장히 작기 때문에 D-Bus를 사용하고자 하는 다른 응용프로그램들은 걱정할 필요가 없다.
D-Bus(Desktop Bus)
D-Bus?
D-Bus은 Desktop Bus의 약자로 사용 목적은 어플리케이션 간의 IPC(Inter-Process Communication) 또는 RPC 프로토콜 을 제공하는 메시지 버스 시스템이다.
즉, 로컬 컴퓨터에서 통신하기 위한 목적이 강하다.
원래는 KDE의 DCOP에서 영향을 받아서 지금의 D-Bus가 생겨났음.
리눅스에서는 이전에 CORBA를 많이 사용했는데 지금은 D-Bus로 대체되었음.
자세히 D-Bus를 보니 Corba의 이벤트 서비스와 비슷한 느낌이다.
Corba event site: http://www1.erlang.org/documentation/doc-4.7.3/lib/orber-2.0/doc/html/ch_event_service.html
예를 들어 장비의 하드웨어 정보가 변경되면 HAL 데몬이 시그널을 발생하고 D-Bus를 통해서 해당 처리하는 어플리케이션의 객체로 전달된다는 것이다.
메세지 버스 시스템을 이용해 어플리케이션끼리 대화를 하는 간단한 방법이다.
칩셋에서 내부적인 통신뿐만 아니라 D-Bus는 상호적인 Life cycle 도와준다.
또한, 간단하고 신뢰성있는 single instance단위의 어플리케이션과 데몬을 코딩할수있게 만들어주며, 관련서비스가 실행되어야 할때 데몬과 어플리케이션이 실행될수있도록 도와준다.
구조
3 계층 구성.
라이브러리 libdbus가 최하위에 있고 메시지 전달하는 역활을 수행
메시지 버스 데몬 libdbus위에 구성되며 여러 어플리케이션과 접속하여 메시지를 처리한다. 발생/가입 패러다임을 사용.
특정 어플리케이션 프레임워크를 위한 포장된 라이브러리(wrapper library).
사용하는 곳이 어플리케이션 간, 데스크탑 세션와 운영체제 간에 주로 사용한다.
실제 사용하는 것을 보면 어플리케이션의 특정 객체로 메시지를 보내는 것으로 큰 그림에서는 CORBA와 비슷하다.
이는 주로 로컬에서 작동하는 것이 문제이다.
이는 unix domain socket를 사용하고 있기 때문이다.
이 부분은 원격 D-Bus(DBusRemote)로서 계획되고 있지만, 아직은 완벽하지는 않다.
현재 TCP/IP도 가능한 것 같지만 사용에 있어서 검증되지 않았다는 것 같다.
그리고 SSH forwarding, Proxy daemon, D-Bus over X에서 사용될 가능성이 있다.
즉, 아직까지 원격에서 사용하기에는 부적합하다. 나중에는 가능할지도..
간단한 용법
전체적인 흐름을 보면,
프로그램이 서비스를 제공하기 위해 등록을 한다.
이 등록은 데몬(dbus-daemon)에서 수행한다.
클라이언트 프로그램은 서비스를 확인하고 가입을 한다.
시스템에서 이벤트(사용자 로그인, 하드웨어 변경)가 발생하면 데몬이 이를 감지하고 해당 이벤트에 가입된 클라이언트 프로그램으로 메시지를 전달한다.
메시지가 원하는 목적 객체로 가기 위해서 D-Bus는 디렉토리 구조와 비슷한 명명 규칙을 사용한다.
이는 읽기쉬운 형태로 되어 있어서 보기 편하다.
예를 들어 /org/kde/kspread/sheets/3/cells/4/5로 되어 있다.
이는 프로그램 내에 특정 객체의 특정 객체를 표시한다.
물론 내부용으로 사용되는 명명법도 있다. 예를 들어 /com/mycompany/c5yo817y0c1y1c5b도 가능하다.
추가로
D-Bus는 최하위 libdbus와는 별개로 D-Bus 프로토콜을 만족하는 다른 구현 라이브러리가 있다고하니 참고하면 좋을 것 같다.
libdbus로 사용하기에는 작업이 많아지고 고려할 것이 많아지는 단점이 있다.
Windows용으로도 포팅되어 있지만, 아직 베타 상태라서 바로 사용하기에는 어려움이 있다.
이름은 winDBus로 되어 있다.
릴리즈된 일자도 한참이어있는데 아직 현재(2010.03)까지 갱신이 안되는 것을 보면, 작업이 더딘것 같다.
결론
CORBA를 보던 중에 D-Bus가 눈에 들어왔지만,
아직까지 원격에 대한 지원이 미미하여 사용하는데 문제가 많이 발생할 것 같다.
사실 CORBA는 무겁고, 기능이 워낙 많다보니 필요없는 것도 많아서 경량화된 목적으로 사용하기 부적합 할 수도 있다.
그래서 CORBA에서도 임베디드 목적의 CORBA가 나오고 있기는 하다.
그러나 크기는 크다. 최근 속도도 괜찮고 가볍다고 하는 omniORB를 사용했는데 실재 빌드해서 나온 바이너리가 의외로 크며, 부수적으로 설치해야할 라이브러리도 많았다.
그렇다고 해서 정적으로 빌드해서 전체 크기를 줄인다고 해도 다른 어플에서도 사용하기에 그 크기는 더 커질 것이다.
그냥 대충 봐도 기본적으로 5MB가 된다.
임베디드에서는 쉽게 넘어갈 크기는 아니다.
물론 일반 데스크탑 용이면 문제는 없다. 그렇다고 해서 D-Bus도 직업 확인해보지 않아서 어떻게 될지는 모르겠다. 선택은 자신의 몫이다.
마지막으로 라이센스는 GPL 또는 AFL(Academic Free License)이다.
libdbus:
두 응용프로그램 간의 연결 및 메세지 교환을 할 수 있도록 한다.
message bus daemon 실행 파일:
libdbus를 기반으로 하여 제작되었으며 여러개의 응용프로그램에서 연결이 가능하다.
데몬은 응용프로그램으로부터 메세지를 전송받아 다른 응용프로그램으로 전송한다.
wrapper library or binding:
libdbus-glib, libdbus-qt 등 특정 어플리케이션 프레임워크 혹은 파이썬과 같은 언어에 wrapping/binding 가능하다.
D-Bus 프로그래밍을 쉽게 할 수 있도록 도와준다.
즉 libdbus는 high-level binding을 위해 low-level backend로 다루어진다고 볼 수 있다.
많은 libdbus api가 binding을 위해 만들어졌다.
libdbus는 오직 one-to-one 연결만 지원하지만 라우터 역할을 하는 message bus daemon과 message를 이용한다면 제약을 극복할 수 있다.
D-Bus은 Desktop Bus의 약자로 사용 목적은 어플리케이션 간의 IPC(Inter-Process Communication) 또는 RPC 프로토콜 을 제공하는 메시지 버스 시스템이다.
즉, 로컬 컴퓨터에서 통신하기 위한 목적이 강하다.
원래는 KDE의 DCOP에서 영향을 받아서 지금의 D-Bus가 생겨났음.
리눅스에서는 이전에 CORBA를 많이 사용했는데 지금은 D-Bus로 대체되었음.
자세히 D-Bus를 보니 Corba의 이벤트 서비스와 비슷한 느낌이다.
Corba event site: http://www1.erlang.org/documentation/doc-4.7.3/lib/orber-2.0/doc/html/ch_event_service.html
예를 들어 장비의 하드웨어 정보가 변경되면 HAL 데몬이 시그널을 발생하고 D-Bus를 통해서 해당 처리하는 어플리케이션의 객체로 전달된다는 것이다.
메세지 버스 시스템을 이용해 어플리케이션끼리 대화를 하는 간단한 방법이다.
칩셋에서 내부적인 통신뿐만 아니라 D-Bus는 상호적인 Life cycle 도와준다.
또한, 간단하고 신뢰성있는 single instance단위의 어플리케이션과 데몬을 코딩할수있게 만들어주며, 관련서비스가 실행되어야 할때 데몬과 어플리케이션이 실행될수있도록 도와준다.
구조
3 계층 구성.
라이브러리 libdbus가 최하위에 있고 메시지 전달하는 역활을 수행
메시지 버스 데몬 libdbus위에 구성되며 여러 어플리케이션과 접속하여 메시지를 처리한다. 발생/가입 패러다임을 사용.
특정 어플리케이션 프레임워크를 위한 포장된 라이브러리(wrapper library).
사용하는 곳이 어플리케이션 간, 데스크탑 세션와 운영체제 간에 주로 사용한다.
실제 사용하는 것을 보면 어플리케이션의 특정 객체로 메시지를 보내는 것으로 큰 그림에서는 CORBA와 비슷하다.
이는 주로 로컬에서 작동하는 것이 문제이다.
이는 unix domain socket를 사용하고 있기 때문이다.
이 부분은 원격 D-Bus(DBusRemote)로서 계획되고 있지만, 아직은 완벽하지는 않다.
현재 TCP/IP도 가능한 것 같지만 사용에 있어서 검증되지 않았다는 것 같다.
그리고 SSH forwarding, Proxy daemon, D-Bus over X에서 사용될 가능성이 있다.
즉, 아직까지 원격에서 사용하기에는 부적합하다. 나중에는 가능할지도..
간단한 용법
전체적인 흐름을 보면,
프로그램이 서비스를 제공하기 위해 등록을 한다.
이 등록은 데몬(dbus-daemon)에서 수행한다.
클라이언트 프로그램은 서비스를 확인하고 가입을 한다.
시스템에서 이벤트(사용자 로그인, 하드웨어 변경)가 발생하면 데몬이 이를 감지하고 해당 이벤트에 가입된 클라이언트 프로그램으로 메시지를 전달한다.
메시지가 원하는 목적 객체로 가기 위해서 D-Bus는 디렉토리 구조와 비슷한 명명 규칙을 사용한다.
이는 읽기쉬운 형태로 되어 있어서 보기 편하다.
예를 들어 /org/kde/kspread/sheets/3/cells/4/5로 되어 있다.
이는 프로그램 내에 특정 객체의 특정 객체를 표시한다.
물론 내부용으로 사용되는 명명법도 있다. 예를 들어 /com/mycompany/c5yo817y0c1y1c5b도 가능하다.
추가로
D-Bus는 최하위 libdbus와는 별개로 D-Bus 프로토콜을 만족하는 다른 구현 라이브러리가 있다고하니 참고하면 좋을 것 같다.
libdbus로 사용하기에는 작업이 많아지고 고려할 것이 많아지는 단점이 있다.
Windows용으로도 포팅되어 있지만, 아직 베타 상태라서 바로 사용하기에는 어려움이 있다.
이름은 winDBus로 되어 있다.
릴리즈된 일자도 한참이어있는데 아직 현재(2010.03)까지 갱신이 안되는 것을 보면, 작업이 더딘것 같다.
결론
CORBA를 보던 중에 D-Bus가 눈에 들어왔지만,
아직까지 원격에 대한 지원이 미미하여 사용하는데 문제가 많이 발생할 것 같다.
사실 CORBA는 무겁고, 기능이 워낙 많다보니 필요없는 것도 많아서 경량화된 목적으로 사용하기 부적합 할 수도 있다.
그래서 CORBA에서도 임베디드 목적의 CORBA가 나오고 있기는 하다.
그러나 크기는 크다. 최근 속도도 괜찮고 가볍다고 하는 omniORB를 사용했는데 실재 빌드해서 나온 바이너리가 의외로 크며, 부수적으로 설치해야할 라이브러리도 많았다.
그렇다고 해서 정적으로 빌드해서 전체 크기를 줄인다고 해도 다른 어플에서도 사용하기에 그 크기는 더 커질 것이다.
그냥 대충 봐도 기본적으로 5MB가 된다.
임베디드에서는 쉽게 넘어갈 크기는 아니다.
물론 일반 데스크탑 용이면 문제는 없다. 그렇다고 해서 D-Bus도 직업 확인해보지 않아서 어떻게 될지는 모르겠다. 선택은 자신의 몫이다.
마지막으로 라이센스는 GPL 또는 AFL(Academic Free License)이다.
libdbus:
두 응용프로그램 간의 연결 및 메세지 교환을 할 수 있도록 한다.
message bus daemon 실행 파일:
libdbus를 기반으로 하여 제작되었으며 여러개의 응용프로그램에서 연결이 가능하다.
데몬은 응용프로그램으로부터 메세지를 전송받아 다른 응용프로그램으로 전송한다.
wrapper library or binding:
libdbus-glib, libdbus-qt 등 특정 어플리케이션 프레임워크 혹은 파이썬과 같은 언어에 wrapping/binding 가능하다.
D-Bus 프로그래밍을 쉽게 할 수 있도록 도와준다.
즉 libdbus는 high-level binding을 위해 low-level backend로 다루어진다고 볼 수 있다.
많은 libdbus api가 binding을 위해 만들어졌다.
libdbus는 오직 one-to-one 연결만 지원하지만 라우터 역할을 하는 message bus daemon과 message를 이용한다면 제약을 극복할 수 있다.
systemd
새로운 PID 1, systemd ?
ConsoleKit(udev, mdev, dev) 변천 과정에서 생기는 방식으로 추정됨.
즉 부팅시 프로세스 관리 방법을 변경 되어진다. Systemd 방식
데비안이 다음 버전 init으로 systemd를 선택했고 우분투도 따라가는 것 같다.
RHEL - 버전 7부터
CentOS - 마찬가지
Fedora - 가장 처음 systemd를 기본으로 채택
Arch
openSUSE
SLES - 버전 12부터
Debian
Ubuntu - 채택
systemd가 새로운 대세가 된.
ConsoleKit
- Session
하나의 부모에서 파생되는 특정 프레세스들의 집합,
환경 변수를 공유하므로 한 유저 이상이 같은 세션을 공유하는건 불가능함.
- Seat
Sear는 여러 세션과 하드웨어 자원을 엮어놓은 상위 집합이라고 할 수 있다.
기존 권한관리 시스템을 이용하면 그룹이나 오너가 아니면(보통 root) 하드웨어 자원을 사용하기가 어렵고 보안상의 문제도 있었지만,
이를 해결 할 수 있는 방법으로 seat를 통해 하드웨어를 자원을 이용할 수 있게 하는 것 같다.(는 내 생각)
보통 이런 방식으로 보안 로그를 확인 한다.
즉, 보안에 관련된 프로세스(서비스하고 있는 프로세스)에 대한 로그를 만들어 그 로그를 보고 보안상에 이슈를 확인하는 방식으로
보안 장비들이 만들어진다.
systemd와 consolekit를 같이 설치할 수 없다는 에러메시지 둘중 하나를 선택해서 사용해야 한다.
consolekit는 더이상 관리되지 않기 때문에 안쓰는게 좋다는 얘기가 보였다.
systemd 가 기존의 init 시스템인 OpenRC 를 대체한다는 점이다.
즉 시스템의 부팅을 관장하는 프로그램이 바뀌는 것이 때문에 무턱대로 설치할 수도 없는 노릇이었다.
그래서 우선 systemd 로 왜 바꾸는지, 그리고 이게 도데체 무엇인지 좀 알아봤다.
여기서 부터 퍼온글인데... 2014년에 전리한 문서라서. 출처를 모르겠음.
systemd는 오랫동안 사용되어 온 shell script 기반의 init 시스템을 대체하기 위해 만들어졌다.
가장 큰 특징은 부팅시에 띄워야 하는 서비스 수를 최대한 줄이고,
서비스 간의 의존성을 없애서 서비스들을 병렬로 실행하게 함으로써 부팅속도를 획기적으로 개선했다는 점이다.
가령 bluetoothd 와 같은 daemon은 블루투스 동글이 접속되지 않은 이상 꼭 떠야할 필요는 없다.
즉 그것이 필요할 때까지 최대한 기다려서 띄우는 방식이라 꼭 부팅 때 실행할 필요가 없게 만든 것이다.
또 서비스 간의 의존성이란, 예를 들어 D-Bus가 실행되려면 로그시스템인 syslog가 먼저 준비되어 있어야 하는 경우처럼 순차적으로 꼭 실행해야하는 것을 의미한다.
하지만 systemd는 이 부분을 각 서비스가 의존하고 있는 선행 서비스에서 꼭 필요한 부분이 그 서비스 전체가 아니라 소켓이라는 사실을 이용하여 해당 소켓을 먼저 생성해 두고,
경우에 따라 들어오는 시그널은 소켓 버퍼에 쌓아두었다가 해당 서비스가 준비 완료되면 그것을 처리하게 해주는 방식으로 의존성을 낮추었다고 한다.
암튼 이런 기발한 방법으로 시스템의 부팅속도를 높였다.
이런 장점 외에도 대부분 c로 구현되어 있어서, 실행중 사용하는 다른 유틸리티들 때문에 수시로 포크가 일어나는 shell script 기반의 실행속도 보다 훨씬 빠르다고 한다.
이런 저런 이유로 최근 배포판들의 대세가 된 듯한데…
이거 반대하는 쪽도 꽤 있나보다.
systemd 메인개발자 중 한명이 PulseAudio 개발자인데 이걸 싫어하는 사람들이 systemd도 싫어하는 듯 하다(나는 PulseAudio의 내력을 잘 몰라서 뭐가 문제인지 모르겠다).
그런데 그들의 주장 또한 일리가 있는 듯 한다.
우선 systemd가 이식성이 낮아서 리눅스에만 적용할 수 있다는 점이다.
Debian의 경우
커널을 리눅스 뿐만 아니라 FreeBSD나 Hurd 버전도 있기 때문에 systemd을 default로 적용하기 어렵다고 한다.
또 다른 이유로는 소켓 preallocation 관련하여 각 데몬들에 패치를 적용해야한다는 점이다.
만약 Systemd를 사용한다면
systemd로 바꾸게 되면 기존의 SysVinit - /sbin/init은 물론 /etc/init.d/*, /etc/rc*.d 이런 디렉토리에 있는 데몬 관리용 스크립트들과 배포본별로 제공하던 런레벨 관리자도 사용하지 않습니다.
패키지별로 systemd 방식의 설정 파일을 /usr/lib/systemd/ 아래에 설치하고 systemctl 명령어를 통해 시작/중지/등록/삭제 작업을 합니다.
데몬의 상태를 관리하는 일도 합니다.
죽거나 멈추면 다시 시작해주고 다양한 조건에 따라 중지하거나 시작하거나 하는 일도 합니다.
설정 파일의 형식은 .ini 파일이나 .desktop 파일 하고 비슷합니다.
각 데몬의 출력 - 로그는 journald에서 일괄적으로 처리해서 journalctl 명령어로 조회하거나 별도의 로그 데몬으로 전달할 수 있습니다.
그런데 단순히 /sbin/init을 대체하고 데몬 관리만 하는 것은 아니더군요.
세부적인 설명은 제가 기술이 짧아서 언급하기 힘듭니다만 그동안 systemd 관련 글타래를 훑어본 결과로는 온갖 바닥 일은 systemd가 다 할 수 있는 것 같습니다.
동적인 장치 관리, 사용자 인증, 권한 관리, 프로세스별 자원(cgroup) 관리, 로그 관리, 사용자별 서비스 등등 별 별거 다 하더군요.
systemd의 구현 방식이 좋다 나쁘다 할 지식은 없지만 어쨌든 systemd 광고대로 잘 되면 배포본별로 제각기 다른 시스템 관리 작업이 통합된다는 점은 저한테 큰 장점으로 보입니다.
mysql, apache 다시 시작하는데 배포본마다 다른 방법을 사용해야 한다는 게 좋은 일만은 아니질 않습니까?
어차피 패키지 업스트림은 다 같은 데서 가져다 쓰는 데 사용하는 방식도 통일될 수 있다면 좋은 일이 아닐까 합니다.
데스크탑 사용자의 입장에서 systemd로 돌아가는 배포본을 써보면 당장 피부에 와 닿는 느낌은 없습니다.
아치 리눅스 써 본 경험에 의하면 시스템 종료가 우분투보다 빠르다?
그것이 systemd 때문인지도 확실하진 않습니다. 부팅도 우분투와 비교하여 좀 빠른 감은 있는데 큰 차이는 아니었습니다.
systemd의 관한 논쟁 중에 재밌는 점은 개발자
- Lennart Poettering -
개인에 관한 공격이 많다는 겁니다. 이 분은 pulseaudio 개발자이기도 한데 개발 과정에서 안 좋은 인상을 남겼는지 삐딱하게 보는 시선이 상당히 많이 보였습니다.
기술적인 측면이 아닌 개발자 개인의 성향에 관한 비판이 어떤 면에서는 유치한 공격이 아닌가 할 수도 있습니다만 시선을 바꿔서 바라보면 또한 일리가 있습니다.
systemd가 담당하는 부분은 커널을 제외하고는 가장 핵심적인 부분이고 밑바탕이라고 볼 수 있습니다.
한 번 선택하면 쉽게 다른 패키지로 대체할 수 없고 적어도 5년, 10년은 바라봐야 하는 그런 패키지라고 생각합니다.
이런 중요한 패키지의 핵심 개발자가 커뮤니티와 의사소통이 잘 안 되고 프로젝트 관리 방식이 편협하거나 독재적인 성향이 강하다면 큰 골칫거리가 될 수 있습니다.
그래서 개발자의 개인적인 성향도 해당 소프트웨어를 선택하는 데 중요한 이유가 되는 것이 맞는다고 생각합니다.
Lennart의 개발자로서의 성향은 잘 모르나 여하튼 pulseaudio를 사용하면 받은 인상은 나쁘지 않기 때문에 전 별다른 유감은 없습니다.
기술적인 측면에서의 비판은 '한 가지만 잘하자'는 유닉스의 철학에 너무 어긋나는 설계다,
너무 많은 일을 한군데서 담당한다는 의견을 자주 보였습니다. 이 문제는 '한 가지'를 어떻게 정의하느냐에 따라 다양한 해석이 가능할 것 같습니다.
기존의 sysv 스타일의 시스템도 많이 다뤄 보시고 systemd도 만져 보신 분들이 있으신가 궁금합니다.
어떤 장단점이 있는지 들어 보고 싶네요.
제 경우 손에 잘 달라붙는 유용한 명령들은 journalctl로 특정 서비스 로그 골라보기하고 systemctl status로 역시 특정 서비스 상태 골라 보기가 맘에 들었습니다.
이전에도 가능했던 작업이지만 더 편하게 볼 수 있어서 좋더군요.
데비안이 어떤 결정을 할 지도 참 궁금합니다.
데비안과 우분투도 systemd를 선택하면 리눅스 세계에서 꽤 기념비적인 '대통합'으로 기억될 것 같습니다.
정리하면.
systemd로 서비스 관리
서비스 로그 확인 명령어: journalctl
프로세스 상태 확인: systemctl status
ConsoleKit(udev, mdev, dev) 변천 과정에서 생기는 방식으로 추정됨.
즉 부팅시 프로세스 관리 방법을 변경 되어진다. Systemd 방식
데비안이 다음 버전 init으로 systemd를 선택했고 우분투도 따라가는 것 같다.
RHEL - 버전 7부터
CentOS - 마찬가지
Fedora - 가장 처음 systemd를 기본으로 채택
Arch
openSUSE
SLES - 버전 12부터
Debian
Ubuntu - 채택
systemd가 새로운 대세가 된.
ConsoleKit
- Session
하나의 부모에서 파생되는 특정 프레세스들의 집합,
환경 변수를 공유하므로 한 유저 이상이 같은 세션을 공유하는건 불가능함.
- Seat
Sear는 여러 세션과 하드웨어 자원을 엮어놓은 상위 집합이라고 할 수 있다.
기존 권한관리 시스템을 이용하면 그룹이나 오너가 아니면(보통 root) 하드웨어 자원을 사용하기가 어렵고 보안상의 문제도 있었지만,
이를 해결 할 수 있는 방법으로 seat를 통해 하드웨어를 자원을 이용할 수 있게 하는 것 같다.(는 내 생각)
보통 이런 방식으로 보안 로그를 확인 한다.
즉, 보안에 관련된 프로세스(서비스하고 있는 프로세스)에 대한 로그를 만들어 그 로그를 보고 보안상에 이슈를 확인하는 방식으로
보안 장비들이 만들어진다.
systemd와 consolekit를 같이 설치할 수 없다는 에러메시지 둘중 하나를 선택해서 사용해야 한다.
consolekit는 더이상 관리되지 않기 때문에 안쓰는게 좋다는 얘기가 보였다.
systemd 가 기존의 init 시스템인 OpenRC 를 대체한다는 점이다.
즉 시스템의 부팅을 관장하는 프로그램이 바뀌는 것이 때문에 무턱대로 설치할 수도 없는 노릇이었다.
그래서 우선 systemd 로 왜 바꾸는지, 그리고 이게 도데체 무엇인지 좀 알아봤다.
여기서 부터 퍼온글인데... 2014년에 전리한 문서라서. 출처를 모르겠음.
systemd는 오랫동안 사용되어 온 shell script 기반의 init 시스템을 대체하기 위해 만들어졌다.
가장 큰 특징은 부팅시에 띄워야 하는 서비스 수를 최대한 줄이고,
서비스 간의 의존성을 없애서 서비스들을 병렬로 실행하게 함으로써 부팅속도를 획기적으로 개선했다는 점이다.
가령 bluetoothd 와 같은 daemon은 블루투스 동글이 접속되지 않은 이상 꼭 떠야할 필요는 없다.
즉 그것이 필요할 때까지 최대한 기다려서 띄우는 방식이라 꼭 부팅 때 실행할 필요가 없게 만든 것이다.
또 서비스 간의 의존성이란, 예를 들어 D-Bus가 실행되려면 로그시스템인 syslog가 먼저 준비되어 있어야 하는 경우처럼 순차적으로 꼭 실행해야하는 것을 의미한다.
하지만 systemd는 이 부분을 각 서비스가 의존하고 있는 선행 서비스에서 꼭 필요한 부분이 그 서비스 전체가 아니라 소켓이라는 사실을 이용하여 해당 소켓을 먼저 생성해 두고,
경우에 따라 들어오는 시그널은 소켓 버퍼에 쌓아두었다가 해당 서비스가 준비 완료되면 그것을 처리하게 해주는 방식으로 의존성을 낮추었다고 한다.
암튼 이런 기발한 방법으로 시스템의 부팅속도를 높였다.
이런 장점 외에도 대부분 c로 구현되어 있어서, 실행중 사용하는 다른 유틸리티들 때문에 수시로 포크가 일어나는 shell script 기반의 실행속도 보다 훨씬 빠르다고 한다.
이런 저런 이유로 최근 배포판들의 대세가 된 듯한데…
이거 반대하는 쪽도 꽤 있나보다.
systemd 메인개발자 중 한명이 PulseAudio 개발자인데 이걸 싫어하는 사람들이 systemd도 싫어하는 듯 하다(나는 PulseAudio의 내력을 잘 몰라서 뭐가 문제인지 모르겠다).
그런데 그들의 주장 또한 일리가 있는 듯 한다.
우선 systemd가 이식성이 낮아서 리눅스에만 적용할 수 있다는 점이다.
Debian의 경우
커널을 리눅스 뿐만 아니라 FreeBSD나 Hurd 버전도 있기 때문에 systemd을 default로 적용하기 어렵다고 한다.
또 다른 이유로는 소켓 preallocation 관련하여 각 데몬들에 패치를 적용해야한다는 점이다.
만약 Systemd를 사용한다면
systemd로 바꾸게 되면 기존의 SysVinit - /sbin/init은 물론 /etc/init.d/*, /etc/rc*.d 이런 디렉토리에 있는 데몬 관리용 스크립트들과 배포본별로 제공하던 런레벨 관리자도 사용하지 않습니다.
패키지별로 systemd 방식의 설정 파일을 /usr/lib/systemd/ 아래에 설치하고 systemctl 명령어를 통해 시작/중지/등록/삭제 작업을 합니다.
데몬의 상태를 관리하는 일도 합니다.
죽거나 멈추면 다시 시작해주고 다양한 조건에 따라 중지하거나 시작하거나 하는 일도 합니다.
설정 파일의 형식은 .ini 파일이나 .desktop 파일 하고 비슷합니다.
각 데몬의 출력 - 로그는 journald에서 일괄적으로 처리해서 journalctl 명령어로 조회하거나 별도의 로그 데몬으로 전달할 수 있습니다.
그런데 단순히 /sbin/init을 대체하고 데몬 관리만 하는 것은 아니더군요.
세부적인 설명은 제가 기술이 짧아서 언급하기 힘듭니다만 그동안 systemd 관련 글타래를 훑어본 결과로는 온갖 바닥 일은 systemd가 다 할 수 있는 것 같습니다.
동적인 장치 관리, 사용자 인증, 권한 관리, 프로세스별 자원(cgroup) 관리, 로그 관리, 사용자별 서비스 등등 별 별거 다 하더군요.
systemd의 구현 방식이 좋다 나쁘다 할 지식은 없지만 어쨌든 systemd 광고대로 잘 되면 배포본별로 제각기 다른 시스템 관리 작업이 통합된다는 점은 저한테 큰 장점으로 보입니다.
mysql, apache 다시 시작하는데 배포본마다 다른 방법을 사용해야 한다는 게 좋은 일만은 아니질 않습니까?
어차피 패키지 업스트림은 다 같은 데서 가져다 쓰는 데 사용하는 방식도 통일될 수 있다면 좋은 일이 아닐까 합니다.
데스크탑 사용자의 입장에서 systemd로 돌아가는 배포본을 써보면 당장 피부에 와 닿는 느낌은 없습니다.
아치 리눅스 써 본 경험에 의하면 시스템 종료가 우분투보다 빠르다?
그것이 systemd 때문인지도 확실하진 않습니다. 부팅도 우분투와 비교하여 좀 빠른 감은 있는데 큰 차이는 아니었습니다.
systemd의 관한 논쟁 중에 재밌는 점은 개발자
- Lennart Poettering -
개인에 관한 공격이 많다는 겁니다. 이 분은 pulseaudio 개발자이기도 한데 개발 과정에서 안 좋은 인상을 남겼는지 삐딱하게 보는 시선이 상당히 많이 보였습니다.
기술적인 측면이 아닌 개발자 개인의 성향에 관한 비판이 어떤 면에서는 유치한 공격이 아닌가 할 수도 있습니다만 시선을 바꿔서 바라보면 또한 일리가 있습니다.
systemd가 담당하는 부분은 커널을 제외하고는 가장 핵심적인 부분이고 밑바탕이라고 볼 수 있습니다.
한 번 선택하면 쉽게 다른 패키지로 대체할 수 없고 적어도 5년, 10년은 바라봐야 하는 그런 패키지라고 생각합니다.
이런 중요한 패키지의 핵심 개발자가 커뮤니티와 의사소통이 잘 안 되고 프로젝트 관리 방식이 편협하거나 독재적인 성향이 강하다면 큰 골칫거리가 될 수 있습니다.
그래서 개발자의 개인적인 성향도 해당 소프트웨어를 선택하는 데 중요한 이유가 되는 것이 맞는다고 생각합니다.
Lennart의 개발자로서의 성향은 잘 모르나 여하튼 pulseaudio를 사용하면 받은 인상은 나쁘지 않기 때문에 전 별다른 유감은 없습니다.
기술적인 측면에서의 비판은 '한 가지만 잘하자'는 유닉스의 철학에 너무 어긋나는 설계다,
너무 많은 일을 한군데서 담당한다는 의견을 자주 보였습니다. 이 문제는 '한 가지'를 어떻게 정의하느냐에 따라 다양한 해석이 가능할 것 같습니다.
기존의 sysv 스타일의 시스템도 많이 다뤄 보시고 systemd도 만져 보신 분들이 있으신가 궁금합니다.
어떤 장단점이 있는지 들어 보고 싶네요.
제 경우 손에 잘 달라붙는 유용한 명령들은 journalctl로 특정 서비스 로그 골라보기하고 systemctl status로 역시 특정 서비스 상태 골라 보기가 맘에 들었습니다.
이전에도 가능했던 작업이지만 더 편하게 볼 수 있어서 좋더군요.
데비안이 어떤 결정을 할 지도 참 궁금합니다.
데비안과 우분투도 systemd를 선택하면 리눅스 세계에서 꽤 기념비적인 '대통합'으로 기억될 것 같습니다.
정리하면.
systemd로 서비스 관리
서비스 로그 확인 명령어: journalctl
프로세스 상태 확인: systemctl status
주기적 검사 cron
파일 추가 /etc/cron.daily
fcheck_test.cgi
mlocate.cron
Prelink
Prelink는 프로그램이 시작할 때 소요되는 시간을 감소시킴으로써 시스템의 속도를 증가시킨다.
스타트업 스크립트중에 보면, readahead, readahead_early가 있다.
특정한 파일이 필요하기 전에 미리 메모리에 불러 들여서, 속도 향상에 도움이 된다.
readahead()는 파일의 데이터로 페이지 캐시를 채워서 이후 그 파일에서 읽을 때 디스크 I/O 대기를 하지 않게 한다.
fd 인자는 읽을 파일을 가리키는 파일 디스크립터이다.
offset 인자는 데이터를 읽을 시작점을 지정하며 count는 읽어들일 바이트 수를 지정한다.
I/O는 페이지 단위로 이뤄지며, 따라서 페이지 경계에 맞춰 offset을 내림 하고, (offset+count)와 같거나 그보다 큰며 다음 페이지 경계까지의 바이트들을 읽어들인다.
readahead()는 파일 끝 너머는 읽지 않음.
readahead()는 지정한 데이터를 읽을 때까지 대기. fd가 가리키는 열린 파일의 현재 파일 위치는 변경하지 않음.
apt-get install Prelink
apt-get install ureadahead 우분투에서는 이 패키지로 변경된다.
apt-get install preload
apt-get install readahead-fedora 페도라 방식으로 설치시
일별 파일 체크
cd /etc/cron.daily
cat fcheck
#!/usr/bin/perl
############################################################################
# add program #
############################################################################
$TASK = `/usr/local/fcheck/fcheck -a|grep Inode`;
$HOSTNAME = `/bin/hostname`;
$HOSTNAME =~ s/\n//g;
$TO_EMAIL = 'leejh@l-ht.com';
$SUBJECT = "$HOSTNAME 파일변조 확인";
$MAIL_PROGRAM = "/usr/sbin/sendmail";
if ($TASK){
$TASK_CONFIRM = `/usr/local/fcheck/fcheck -a`;
&task_confirm;
}
sub task_confirm {
open(MAIL,"|$MAIL_PROGRAM -t");
print MAIL"To: $TO_EMAIL \n";
print MAIL"Subject: $SUBJECT \n\n";
print MAIL"Host: $HOSTNAME \n";
print MAIL"$TASK_CONFIRM \n";
close(MAIL);
}
참고:
위에 방식도 있지만 패키지를 사용하는 방식도 있음.
apt-get install fcheck
cd /etc/cron.d/
일주일 루트키 확인.
cd /etc/cron.weekly
cat rkhunter.cron
#!/bin/sh
IP=$(/sbin/ifconfig eth0| head -n2 | awk '/inet.*Bcast/ {print $2}'| cut -f 2 -d':')
(
/usr/local/bin/rkhunter --versioncheck
/usr/local/bin/rkhunter --update
/usr/local/bin/rkhunter --cronjob --report-warnings-only
) | /bin/mail -s "rkhunter Daily Run - $IP" linuxleejang@gmail.com
fcheck_test.cgi
mlocate.cron
Prelink
Prelink는 프로그램이 시작할 때 소요되는 시간을 감소시킴으로써 시스템의 속도를 증가시킨다.
스타트업 스크립트중에 보면, readahead, readahead_early가 있다.
특정한 파일이 필요하기 전에 미리 메모리에 불러 들여서, 속도 향상에 도움이 된다.
readahead()는 파일의 데이터로 페이지 캐시를 채워서 이후 그 파일에서 읽을 때 디스크 I/O 대기를 하지 않게 한다.
fd 인자는 읽을 파일을 가리키는 파일 디스크립터이다.
offset 인자는 데이터를 읽을 시작점을 지정하며 count는 읽어들일 바이트 수를 지정한다.
I/O는 페이지 단위로 이뤄지며, 따라서 페이지 경계에 맞춰 offset을 내림 하고, (offset+count)와 같거나 그보다 큰며 다음 페이지 경계까지의 바이트들을 읽어들인다.
readahead()는 파일 끝 너머는 읽지 않음.
readahead()는 지정한 데이터를 읽을 때까지 대기. fd가 가리키는 열린 파일의 현재 파일 위치는 변경하지 않음.
apt-get install Prelink
apt-get install ureadahead 우분투에서는 이 패키지로 변경된다.
apt-get install preload
apt-get install readahead-fedora 페도라 방식으로 설치시
일별 파일 체크
cd /etc/cron.daily
cat fcheck
#!/usr/bin/perl
############################################################################
# add program #
############################################################################
$TASK = `/usr/local/fcheck/fcheck -a|grep Inode`;
$HOSTNAME = `/bin/hostname`;
$HOSTNAME =~ s/\n//g;
$TO_EMAIL = 'leejh@l-ht.com';
$SUBJECT = "$HOSTNAME 파일변조 확인";
$MAIL_PROGRAM = "/usr/sbin/sendmail";
if ($TASK){
$TASK_CONFIRM = `/usr/local/fcheck/fcheck -a`;
&task_confirm;
}
sub task_confirm {
open(MAIL,"|$MAIL_PROGRAM -t");
print MAIL"To: $TO_EMAIL \n";
print MAIL"Subject: $SUBJECT \n\n";
print MAIL"Host: $HOSTNAME \n";
print MAIL"$TASK_CONFIRM \n";
close(MAIL);
}
참고:
위에 방식도 있지만 패키지를 사용하는 방식도 있음.
apt-get install fcheck
cd /etc/cron.d/
일주일 루트키 확인.
cd /etc/cron.weekly
cat rkhunter.cron
#!/bin/sh
IP=$(/sbin/ifconfig eth0| head -n2 | awk '/inet.*Bcast/ {print $2}'| cut -f 2 -d':')
(
/usr/local/bin/rkhunter --versioncheck
/usr/local/bin/rkhunter --update
/usr/local/bin/rkhunter --cronjob --report-warnings-only
) | /bin/mail -s "rkhunter Daily Run - $IP" linuxleejang@gmail.com
wget 정리
wget 파일 다운로드
하위 디렉토리 다운로드
wget -m -p -E -k -K -np {URL Address}
하위 디렉토리
wget -r
링크 파일
wget -r -l 1
html에 링크된 파일들을 가져온다.
-r 옵션은 --recursive 이고 -l 은 반복할 레벨을 뜻한다. (즉 링크를 추적할수 있는 방법론 1으므로 한번 링크 추적)
다른 이름 저장
wget -O 새로운이름 http://l-ht.com
-np: 링크된 파일 중 상위 디렉토리는 제외 (no-parent)
-A html.htm : html.htm 형식의 파일만
-L : 상대주소를 이용한 링크
-q : 메세지 출력 금지
-nv: 메세지 요약 출력
-nd : no directoris, 로컬에 다운받을때 디렉토리를 생성하지 않으며 모든 파일을 같은 디렉토리 넣는다.
-t 1: retries, 링크된 주소로 서버를 찾기 못할때 재 전송 할 횟수를 지정한다.
-H : 다른 호스트의 재귀적 탐색을 원할 경우 span-host를 의미한다.
index.html 만 가지고 오기
wget -r -l 0 -L -np -A index.html -nv URL
wget -A mpg,mpeg,avi,asf -r -H -l 2 -nd -t 1 http://usrl.com
ftp로그인 다운로드 방법
wget -f ftp://아이디:votmdnjem@아이피주소및 파일 위치
wget을 이용한 사이트 응답시간 체크
다음과 같은 2가지 사항에 대해서 체크한다면, 웹서비스에 대한 기본적인 품질 체크 가능.
페이지 응답체크
페이지 응답시간
Submit Process
여기에 덧붙여서 Submit Process까지 체크한다면, 더 나은 품질 모니터링 환경을 만들 수 있다.
어떤 웹서비스가 제대로 작동하는지 확인하고 싶을 경우, POST(:12) 혹은 GET(:12)으로 연결된 몇개의 페이지를 연결해서 검사해야할 필요가 있다. 예를 들어서 로그인을 위해서 OpenID(:12)를 사용한다고 가정해보자.
기존의 로그인 방식이라면, 로그인관련 데이터가 로컬에 있으니, 로그인데이터를 관리하는 DB시스템이 제대로 살아있는지만 확인할 수 있으면 된다. 그러나 OpenID와 같은 경우에는 로컬 DB를 이용하는게 아닌, 로그인 서비스를 이용하는 방식이기 때문에 실제 Submit을 해서 다음 페이지로 넘어가는지를 확인해 주어야 한다.
Submit 프로세스를 체크하기 위해서는 HTTP(:12)와 POST(:12), GET(:12)을 이용한 데이터 전달방식 그리고 cookie(:12)에 대해서 알고 있어야 할것이다. 여기에서는 그냥 wget(1)을 이용해서 간단하게 처리하는 방법에 대해서 알아본다.
# wget --load-cookies=cookies.txt --save-cookies=cookies.txt \
--post-data 'uname=myid&pass=mypass&op=login' \
'http://www.domain.com/auth.php' -O /dev/null
아주 간단하다. --post-data 옵션을 이용하면, 해당 페이지에 POST 데이터를 넘길 수 있다. POST 데이터를 받은 웹서버는 인증과정을 거친 후, 그 결과를 Cookie로 클라이언트에 전달하고, 이후의 인증 세션유지는 cookie 값의 교환으로 이루어지게 된다. --save-cookies 옵션을 이용하면, 서버로 부터 넘어온 cookie 값을 파일에 저장할 수가 있다. 이제 --load-cookies 옵션을 이용해서 해당 웹페이지를 호출할 때, 쿠키도 같이 보내면 된다.
위의 명령을 쉘스크립트(:12) 형태로 만들어서 주기적으로 실행하고, 그 결과를 분석하는 걸로, 간단하게 Submit Process에 대한 체크를 할 수 있다. C(:12) 언어가 마음에 든다면, fork(:12) & exec(:12)를 이용한 실행코드를 만들어 낼 수도 있을 것이다. 위의 경우는 요청한 페이지정보를 /dev/null 로 보내고 있는데, 로그인 결과까지를 확인하고 싶다면, 입력받은 페이지를 스트링매칭 시키는 방법으로 분석해야 할 것이다.
응답시간
응답시간 역시 wget을 이용해서 간단하게 해결할 수 있다. 더불어 -p옵션을 사용한다면, 해당 페이지에 링크되어 있는 이미지, 사운드, CSS(:12) 데이터들의 로딩시간까지 함께 체크할 수 있다.
# wget -p http://www.domain.com/index.php > /dev/null
하위 디렉토리 다운로드
wget -m -p -E -k -K -np {URL Address}
하위 디렉토리
wget -r
링크 파일
wget -r -l 1
html에 링크된 파일들을 가져온다.
-r 옵션은 --recursive 이고 -l 은 반복할 레벨을 뜻한다. (즉 링크를 추적할수 있는 방법론 1으므로 한번 링크 추적)
다른 이름 저장
wget -O 새로운이름 http://l-ht.com
-np: 링크된 파일 중 상위 디렉토리는 제외 (no-parent)
-A html.htm : html.htm 형식의 파일만
-L : 상대주소를 이용한 링크
-q : 메세지 출력 금지
-nv: 메세지 요약 출력
-nd : no directoris, 로컬에 다운받을때 디렉토리를 생성하지 않으며 모든 파일을 같은 디렉토리 넣는다.
-t 1: retries, 링크된 주소로 서버를 찾기 못할때 재 전송 할 횟수를 지정한다.
-H : 다른 호스트의 재귀적 탐색을 원할 경우 span-host를 의미한다.
index.html 만 가지고 오기
wget -r -l 0 -L -np -A index.html -nv URL
wget -A mpg,mpeg,avi,asf -r -H -l 2 -nd -t 1 http://usrl.com
ftp로그인 다운로드 방법
wget -f ftp://아이디:votmdnjem@아이피주소및 파일 위치
wget을 이용한 사이트 응답시간 체크
다음과 같은 2가지 사항에 대해서 체크한다면, 웹서비스에 대한 기본적인 품질 체크 가능.
페이지 응답체크
페이지 응답시간
Submit Process
여기에 덧붙여서 Submit Process까지 체크한다면, 더 나은 품질 모니터링 환경을 만들 수 있다.
어떤 웹서비스가 제대로 작동하는지 확인하고 싶을 경우, POST(:12) 혹은 GET(:12)으로 연결된 몇개의 페이지를 연결해서 검사해야할 필요가 있다. 예를 들어서 로그인을 위해서 OpenID(:12)를 사용한다고 가정해보자.
기존의 로그인 방식이라면, 로그인관련 데이터가 로컬에 있으니, 로그인데이터를 관리하는 DB시스템이 제대로 살아있는지만 확인할 수 있으면 된다. 그러나 OpenID와 같은 경우에는 로컬 DB를 이용하는게 아닌, 로그인 서비스를 이용하는 방식이기 때문에 실제 Submit을 해서 다음 페이지로 넘어가는지를 확인해 주어야 한다.
Submit 프로세스를 체크하기 위해서는 HTTP(:12)와 POST(:12), GET(:12)을 이용한 데이터 전달방식 그리고 cookie(:12)에 대해서 알고 있어야 할것이다. 여기에서는 그냥 wget(1)을 이용해서 간단하게 처리하는 방법에 대해서 알아본다.
# wget --load-cookies=cookies.txt --save-cookies=cookies.txt \
--post-data 'uname=myid&pass=mypass&op=login' \
'http://www.domain.com/auth.php' -O /dev/null
아주 간단하다. --post-data 옵션을 이용하면, 해당 페이지에 POST 데이터를 넘길 수 있다. POST 데이터를 받은 웹서버는 인증과정을 거친 후, 그 결과를 Cookie로 클라이언트에 전달하고, 이후의 인증 세션유지는 cookie 값의 교환으로 이루어지게 된다. --save-cookies 옵션을 이용하면, 서버로 부터 넘어온 cookie 값을 파일에 저장할 수가 있다. 이제 --load-cookies 옵션을 이용해서 해당 웹페이지를 호출할 때, 쿠키도 같이 보내면 된다.
위의 명령을 쉘스크립트(:12) 형태로 만들어서 주기적으로 실행하고, 그 결과를 분석하는 걸로, 간단하게 Submit Process에 대한 체크를 할 수 있다. C(:12) 언어가 마음에 든다면, fork(:12) & exec(:12)를 이용한 실행코드를 만들어 낼 수도 있을 것이다. 위의 경우는 요청한 페이지정보를 /dev/null 로 보내고 있는데, 로그인 결과까지를 확인하고 싶다면, 입력받은 페이지를 스트링매칭 시키는 방법으로 분석해야 할 것이다.
응답시간
응답시간 역시 wget을 이용해서 간단하게 해결할 수 있다. 더불어 -p옵션을 사용한다면, 해당 페이지에 링크되어 있는 이미지, 사운드, CSS(:12) 데이터들의 로딩시간까지 함께 체크할 수 있다.
# wget -p http://www.domain.com/index.php > /dev/null
피드 구독하기:
글 (Atom)