리눅스 Run level 이란?

이번에는 리눅스의 런 레벨에 대해 알아 보겠습니다. 우선 Run level이 무엇인지부터 알아야겠죠?
런레벨(Run level)이란, 시스템 관리의 용이함을 위하여 서비스의 실행을 단계별로 구분하여 적용하는 것을 말합니다.

런레벨은 0부터 6번까지 있는데요. 한번 알아보겠습니다.

# 0 - halt (DO NOT set initdefault to this)
시스템 종료를 의미합니다. 즉, 런레벨 0으로 변경하라는 명령을 내리면 시스템을 종료하는 것이죠.
# 1 - Single user mode
시스템 복원모드라고도 하며, 기본적으로 관리자 권한 쉘을 얻게 됩니다.
주로, 파일시스템을 점검하거나 관리자 암호를 변경할 때 사용합니다.
# 2 - Multiuser mode, without NFS (The same as 3, if you do ot have networking)
NFS(Network File System)을 지원하지 않는 다중 사용자 모드입니다.
네트워크를 사용하지 않는 텍스트 유저모드라고 할 수 있죠.
# 3 - Full muliuser mode
일반적인 쉘 기반의 인터페이스를 가진 다중 사용자 모드입니다.
쉽게 말하면 그래픽 유저 모드가 아닌 '텍스트 유저 모드'입니다.
# 4 - unused
4번은 쓰이지 않습니다. 기본적으로는 사용되지 않지만, 임의로 정의해서 사용할 수 있는 레벨입니다.
# 5 - X11기본적으로는 level 3과 같습니다. 다른 점은 '그래픽 유저 모드' 라는것!!!
# 6 - reboot (DO NOT set initdefault to this)
시스템 재부팅을 의미합니다. 런레벨 6으로 변경하라는 명령을 내리면 시스템을 재부팅 하죠.



주로 사용하게 되는 것은 0, 3, 5, 6 을 많이 씁니다. 이 런레벨의 변경은 root 사용자의 경우만 가능합니다. 즉, 터미널 창에서 관리자 모드로 들어가 gedit /etc/inittab을 입력하면 런레벨을 바꿔줄 수 있습니다. 한번 해볼까요?

터미널 창을 켜고, 관리자 모드로 들어갑니다. gedit /etc/inittab 명령어를 입력해주세요.

그럼 아래와 같은 창이 켜지죠. 위에서 봤던 runlevel에 안내가 나옵니다.

그리고 그 간단한 안내 아래에서..! 런레벨을 바꿔줄 수 있습니다.
한번 텍스트 유저 모드로 바꿔볼까요? 블록한 부분을 봐주세요 :)

5를 3으로 바꿔주고 빨간색 네모로 강조한 '저장' 버튼 클릭하면 끝! 입니다 :)

그럼 이제 시스템을 다시 시작해볼까요? 아래 화면과 같이 텍스트 모드로 시작되는 것을 볼 수 있습니다. :)

다시 그래픽 유저 모드로 돌아가고 싶을 때는, init 명령어를 이용하시면 됩니다. 이렇게요. :)
inittab이나 init 명령어 처럼 런레벨을 변경하는 것은
오직 관리자 모드에서만 가능하므로 su - 부터 입력해주셔야합니다.

그럼 명령어 입력하기 무섭게 그래픽 유저 모드로 넘어가지요.

명령어 init은 단순히 런레벨을 변경해서 부팅하는 명령어이기 때문에
시스템 종료후, 이대로 다시 부팅하게 되면 텍스트 유저 모드로 부팅하게 됩니다.

다시 그래픽 유저 모드로 바꿔주려면,
 로그인하셔서 아까처럼 터미널 창에서 관리자 모드로 바꿔주고 gedit /etc/inittab 입력후
inittab창에서 id:3:initdefault → id:5:initdefault 로 바꿔주시면 됩니다. :)

DHCP General Operation and Client Finite State Machine

DHCP General Operation and Client Finite State Machine

Dynamic address allocation is probably the most important new capability introduced by DHCP. In the last section I discussed in detail the significance of the change from IP address ownership to IP address leasing. I also provided a high-level look of the activities involved in leasing, by providing an overview of the DHCP lease “life cycle”.

An overview of this sort is useful to get a general handle on how leases work, but to really understand the mechanics of DHCP address assignment and client/server communication, we need more detail on how the devices behave and what messages they send. One tool often employed by networking engineers to describe a protocol is a theoretical model called a finite state machine (FSM). In this technique, the protocol's specific behavior is illustrated by showing the different states a device can be in, what possible transitions exist from one state to another, what events cause transitions to occur, and what actions are performed in response to an event. The TCP operational overview contains more general background information on finite state machines.

The DHCP standard uses an FSM to describe the lease life cycle from the perspective of a DHCP client. The client begins in an initial INIT state where it has no lease, and then transitions through various states as it acquires, renews, rebinds and/or releases its IP address. The FSM also indicates what message exchanges occurs between the server and client at various stages.

Some people think finite state machines are a little “dense” and hard to understand, and I can see why. You can skip this topic of course, but I think the FSM provides a useful way of illustrating in a comprehensive way most of the behavior of a DHCP client. Table 188 describes each of the DHCP client states, and summarizes the messages sent and received by the client in each, as well as showing the state transitions that occur in response. The FSM’s states, events and transitions are easier to envision in Figure 262, which also incorporates a color coding scheme so you can see which states are associated with each of the main DHCP processes.

Table 188: DHCP Client Finite State Machine

State	State Description	Event and Transition
INIT	This is the initialization state, where a client begins the process of acquiring a lease. It also returns here when a lease ends, or when a lease negotiation fails.	Client Sends DHCPDISCOVER: The client creates a DHCPDISCOVER message and broadcasts it to try to find a DHCP server. It transitions to the SELECTING state.
SELECTING	The client is waiting to receive DHCPOFFER messages from one or more DHCP servers, so it can choose one.	Client Receives Offers, Selects Preferred Offer, Sends DHCPREQUEST: The client chooses one of the offers it has been sent, and broadcasts a DHCPREQUEST message to tell DHCP servers what its choice was. It transitions to the REQUESTING state.
REQUESTING	The client is waiting to hear back from the server to which it sent its request.	Client Receives DHCPACK, Successfully Checks That IP Address Is Free: The client receives a DHCPACK message from its chosen server, confirming that it can have the lease that was offered. It checks to ensure that address is not already used, and assuming it is not, records the parameters the server sent it, sets the lease timers T1 and T2, and transitions to the BOUND state.
		Client Receives DHCPACK, But IP Address Is In Use: The client receives a DHCPACK message from its chosen server, confirming that it can have the lease that was offered. However, it checks and finds the address already in use. It sends a DHCPDECLINE message back to the server, and returns to the INIT state.
		Client Receives DHCPNAK: The client receives a DHCPNAK message from its chosen server, which means the server has withdrawn its offer. The client returns to the INIT state.
INIT-REBOOT	When a client that already has a valid lease starts up after a power-down or reboot, it starts here instead of the INIT state.	Client Sends DHCPREQUEST: The client sends a DHCPREQUEST message to attempt to verify its lease and re-obtain its configuration parameters. It then transitions to the REBOOTING state to wait for a response.
REBOOTING	A client that has rebooted with an assigned address is waiting for a confirming reply from a server.	Client Receives DHCPACK, Successfully Checks That IP Address Is Free: The client receives a DHCPACK message from the server that has its lease information, confirming that the lease is still valid. To be safe, the client checks anyway to ensure that the address is not already in use by some other device. Assuming it is not, the client records the parameters the server sent it and transitions to the BOUND state.
		Client Receives DHCPACK, But IP Address Is In Use: The client receives a DHCPACK message from the server that had its lease, confirming that the lease is still valid. However, the client checks and finds that while the client was offline, some other device has grabbed its leased IP address. The client sends a DHCPDECLINE message back to the server, and returns to the INIT state to obtain a new lease.
		Client Receives DHCPNAK: The client receives a DHCPNAK message from a server. This tells it that its current lease is no longer valid; for example, the client may have moved to a new network where it can no longer use the address in its present lease. The client returns to the INIT state.
BOUND	Client has a valid lease and is in its normal operating state.	Renewal Timer (T1) Expires: The client transitions to the RENEWING state.
		Client Terminates Lease, Sends DHCPRELEASE: The client decides to terminate the lease (due to user command, for example.) It sends a DHCPRELEASE message and returns to the INIT state.
RENEWING	Client is trying to renew its lease. It regularly sends DHCPREQUEST messages with the server that gave it its current lease specified, and waits for a reply.	Client Receives DHCPACK: The client receives a DHCPACK reply to its DHCPREQUEST. Its lease is renewed, it restarts the T1 and T2 timers, and returns to the BOUND state.
		Client Receives DHCPNAK: The server has refused to renew the client's lease. The client goes to the INIT state to get a new lease.
		Rebinding Timer (T2) Expires: While attempting to renew its lease, the T2 timer expires, indicating that the renewal period has ended. The client transitions to the REBINDING state.
REBINDING	The client has failed to renew its lease with the server that originally granted it, and now seeks a lease extension with any server that can hear it. It periodically sends DHCPREQUEST messages with no server specified until it gets a reply or the lease ends.	Client Receives DHCPACK: Some server on the network has renewed the client's lease. The client binds to the new server granting the lease, restarts the T1 and T2 timers, and returns to the BOUND state.
		Client Receives DHCPNAK: A server on the network is specifically telling the client it needs to restart the leasing process. This may be the case if a new server is willing to grant the client a lease, but only with terms different than the client’s current lease. The client goes to the INIT state.
		Lease Expires: The client receives no reply prior to the expiration of the lease. It goes back to the INIT state.

Figure 262: DHCP Client Finite State Machine

This diagram shows the finite state machine used by DHCP clients. The colored background areas show the transitions taken by a DHCP client as it moves through the four primary DHCP processes: allocation, reallocation, renewal and rebinding.

This is just a summary of the finite state machine, and does not show every possible event and transition, since it is complex enough already. For example, if a client that received two offers in the SELECTING state receives a DHCPNAK from its chosen server in the REQUESTING state, it may choose to send a new DHCPREQUEST to its “second choice” instead of starting over from scratch. Also, the client must have logic that lets it “time out” if it receives no reply to sent messages in various states, such as not receiving any offers in the SELECTING state. The next few topics discuss these matters in more detail.

Note also that the DHCP standard does not describe the DHCP server's behavior in the form of a finite state machine, only the client's. Here too, there is more information on what exactly DHCP servers do in the pages that follow.

I should also point out explicitly that this finite state machine applies to dynamically-allocated clients; that is, ones with conventional leases. A device configured using “automatic” allocation will go through the same basic allocation process, but does not need to renew its lease. The process for manual allocation is somewhat different.

Reference from http://www.tcpipguide.com/free/t_DHCPGeneralOperationandClientFiniteStateMachine.htm