정리 블로그

1. Linux 부팅 문제 발생 확인

 AWS 콘솔창에서 인스턴스 우클릭 후 'Get Instance Screenshot'을 보면 위와 같이 부팅에 문제가 생긴 것을 확인할 수 있음.

화면에 Control-D를 누르면 계속할 수 있다지만, On-Prem 환경이 아니기때문에 직접 누를 수 없음. 재부팅을 계속 한다고해서 해결되지 않고 같은 부분에서 부팅 문제가 발생한다.

2. 해결방안

1. Volume Tag.

문제가 발생한 Volume에 Tag를 먼저 할 것.(다른 Volume과 헷갈릴 수 있음)

2. 새로운 인스턴스 생성 및 Mount

 인스턴스를 새롭게 생성해서 해당 인스턴스를 Attach.

Root Volume이지만, 다른 인스턴스에 Mount 시키기 때문에 위에서는 /dev/sdf 로 Attach.

parted -l

디스크 확인은 parted -l로 했음.

/dev/xvdf를 보니, Attach는 제대로 됐음.

'xvdf1' 디스크를 마운트 시킨다

'/FIX' 위치에 마운트 시켰음

'/FIX'에 들어가보면 위와 같이 Linux 기본 디렉토리들이 확인 가능함

내가 겪은 문제의 원인은 fstab을 수정했는데, 정상적으로 적용이 되지 않고 임시파일(?) 비슷한 문서 에디터 비정상종료에 따른 swap파일이 생겼음.

rm /FIX/etc/.fstab.swp

rm 명령어를 통해 삭제했음

삭제 후 umount를 통해 정상적으로 마운트 제거하여 나머지 작업 진행!

작업 완료 후 처음 인스턴스에 다시 Attach하고 부팅하면 끝!

1. ELB 종류

 지난 블로그에도 적었던 것 처럼 Elastic Load Balancer는 3가지 종류가 있음.

ALB(Application Load Balancer), NLB(Network Load Balancer), CLB(Classic Load Balancer).

각각의 LB는 사용 용도에 따라 선택이 필요하며, 오늘 작성할 내용은 CLB(단순 LoadBalancing 역할)를 작성

2. CLB 생성하기

STEP 1.

- 첫 단계에서는 LB의 이름과 사용 포트를 정함.

CLB는 단순한 포트 포워딩만 가능. 위 캡쳐에서는 LB에 HTTP 80으로 들어온 통신을 LB에 연결된 EC2 80포트로 연결해주는 것을 나타냄.

- 내부에서만 사용하는 시스템에 적용하려면 'Internal Load Balancer'를 클릭 후 생성하면 외부에서 해당 LB를 통해 접속이 불가.(사실 여기서 Internal Load Balancer를 클릭하지 않더라도, LB의 Subnet을 Private으로 하면 외부에서 접속할 수 없음. 외부에서 nslookup 입력 시, 쿼리 확인 불가)

- Available Subnets는 LB가 위치할 Subnet을 추가.(AWS 권장은 LB를 Public에 두고, LB의 뒷 단(EC2)를 Private에 위치시켜 사용하는 방식. 즉, EC2는 외부에서 접속 불가하지만 LB를 통해 접속 가능

STEP 2, 3는 생략.(Security Group 설정)

STEP 4.

- LB는 기본적으로 Health Check를 통해 Healthy인 인스턴스로만 로드밸런싱 함.

- Healthy Check는 루트 경로의 파일의 ping port를 통해 진행되는데, 위와 같이 Ping Path에 해당 파일이 위치하고 있어야 한다. html을 사용하면 문제 없지만, 사용하지 않는 경우에는 'index.html'과 같이 비어있는 html 파일을 넣어둬도 체크가 가능하다.(단, 서비스에 이상이 생겼을 때, Healthy 상태를 유지한다는 단점이 있음.)

위 화면을 보면 조금 더 잘 보임. hello.html은 80포트를 이용하며, 30초 간격으로 Health Check. Timeout은 5초, 2번 체크가 되지 않으면 Unhealthy 상태로 변경되어, 해당 인스턴스는 밸런싱 되지 않음.

STEP 5.

- LB에 Attach 할 인스턴스를 지정하는 화면

- 하단에 Enable Cross-Zone Load Balancing은 해당 LB에 서로 다른 가용영역의 인스턴스를 넣을 수 있게 해줌. 위 화면에서는 둘 다 ap-northeast-2a를 사용했지만(보이지는 않음), ap-northeast-2c 등 다른 가용영역을 함께 사용할 수 있음

- 'Enable Connection Draining' 옵션은 LB에서 특정 인스턴스를 제거할 때, 해당 인스턴스에 신규 접속자는 차단하면서 기존에 인스턴스에 연결되어 서비스를 이용하는 사용자가 설정 시간동안 사용할 수 있도록 함.(위는 300초)

3. 포트 포워딩

* 예제에서 구성한 인스턴스는 80포트를 사용하는 중임.

- 'ELB주소:8080'을 입력하는 것과 'ELB주소:80'을 입력하는 것이 같은 페이지를 출력함.

- '여러 서비스를 사용할 때 쓸수 있나?'라는 생각을 가졌지만, 기본적으로 Health Check에서 80 포트를 체크하기 때문에 한 가지 서비스에 여러가지 포트를 사용할 때만 가능한 것 같다는 생각.(나중에 아닌 경우가 생각나면 수정해라)

4. AutoScaling과 연계

- LB를 설정하고 AutoScaling을 설정하여, 특정 임계치(CPU, Memory, Request Count 등의 지표)에 도달하면 새로운 인스턴스를 생성하여 LB에 Attach를 할 수 있다. 이 부분은 추후 작성예정이지만, 필요한 경우 구글링하면 금방 할 수 있을 것.

1. LVM 생성 순서

 -. LVM은 PV, VG, LV 순으로 만들어야하며, 트리형식으로 생각하면 된다.

PV를 만들면 하위에 Volume Group를 여러 개, 생성 가능하고, 각 각의 VG에 LV를 생성할 수 있다.

2. 생성하기

lsblk 명령어를 통해 LVM으로 만들 디스크를 선택한다.

‘pvcreate’를 통해 Attachment Disk 이름을 입력해준다.(해당 디스크를 PV로 설정하는 것.)

   >> pvcreate /dev/xvdf

앞에서 ‘xvdf’를 PV로 설정하였으므로, xvdf에 VolumeGroup를 설정해준다.

아래에서 vg01은 임의로 작성한 이름이며, 사용자 목적에 맞게 네이밍한다.

  >> vgcreate vg01 /dev/xvdf

참고) 만약xvdf에 2개의 VG를 만들고 싶다면,

  >> vgcreate vg02 /dev/xvdf와 같이 작성.

(동일한 이름은 사용 불가함. 같은 이름을 사용하여도 Overwrite 바로 안되기때문에 걱정할 것 없음.)

‘lvcreate’ 명령어를 통해 LV를 생성 가능하며, -L 명령어는 정확한 용량을 입력해줘야함.

(-l 명령어는 Percent 단위로 사용 // -l과 -L은 차이가 있음)

(-n 명령어는 네이밍을 주기 위함. vg01에 lv_data라는 lv를 생성.)

LV까지 생성한 후에는 LV DISK를 필요한 타입 설정 후 초기화 시켜줘야 함.

위에서는 ext4 타입으로 초기화하였으며, disk 위치는 /dev/mapper/[VG이름-LV이름]으로 되어있음.

3. FSTAB 추가

전에도 작성했지만, fstab에 추가해줘야 재부팅이 되었을 때, 디스크가 마운팅된 상태로 시스템이 부팅됨.

‘blkid’ 명령어를 통해 UUID를 확인할 수 있으며, fstab에 추가하여 Mount시켜야함.

‘/dev/mapper/vg01-lv_data=UUID(으브브브브)‘라고 써진 부분에서 UUID를 복사하여

 > ‘/etc/fstab’에 추가 필요

UUID 2개 중 위는, 기본 root볼륨의 UUID이고, 아래가 추가한 UUID값.

UUID / Mounting Point / Type  순으로 작성하면 되고,

defaults 0 0을 보통 입력하며 해당 옵션은 이전 글 참고.

Fstab 입력 후 ‘mount –a’ 혹은 ‘mount /dev/mapper/vg01-lv_data [Mounting Point]를 통해 마운트를 완료

4. LV 추가하기

초기에 ‘vg01-lv_data’를 만들었으며, 처음과 동일한 방식으로 lv_data2를 만들었음.

여기서 참고할 사항은 1개의 PV 안에 위치한 2개의 LV 이지만, 서로 다른 타입의 디스크를 사용해도 됨.(ext4, xfs)

  --- 특징

xfs의 경우, 디스크 크기 증가는 가능하지만, 감소는 불가.

ext4의 경우, 디스크 크기 증가 및 감소 모두 가능.

5. LV 용량 증가시키기

초기에 설정한 LV 용량이 부족하다면 명령어를 통해 용량 증가 가능.(초기화 아님)

처음 생성한 LV 용량이 부족하여 용량 증가를 하고자 한다면 아래와 같은 명령어로 가능.

  >> lvextend –r –L +40G /dev/vg/lv_data (-r 명령어는 resizefs, -L 명령어는 정확한 디스크 size)

  --- 참고

6. 무조건 조심해야할 주의사항

 위의 설정은 fstab을 수정해주는데, 설정이 잘못된 경우 부팅이 되지 않을 수 있으니, 테스트가 아니고서야 무조건 조심해야할 필요가 있음.

 혹시나 /etc/fstab을 잘못 설정하여 부팅이 되지 않는 경우, 포멧을 생각하지 말고

문제가 발생한 루트 디스크를 다른 장비로 마운트시켜 /'마운팅포인트'/etc/fstab 의 경로로 이동하여 fstab에서 잘못된 설정을 수정하여 다시 마운트 시키면 해결됨!

1. 신규 Instance 생성과 동시에 'Auto-assign Public IP' 기능을 사용할 경우

 - Instance를 생성하면서, 'Auto-assign Public IP'를 사용하면 EIP를 별도로 생성할 필요 없이 Public IP를 사용할 수 있다. 하지만, 해당 케이스는 Public IP가 변동되어도 상관 없다면 사용이 가능하다. 하지만, DDNS를 사용하지 않는다면 Public IP가 바뀔 때 마다, DNS 설정을 변경해줘야 하는 번거로움이 생긴다.

 ex) Auto-assign Public IP 기능을 사용하여 받은 Public IP가 10.10.10.10일 때, DNS서버에

'www.dennsworld.com' == '10.10.10.10' 로 되어있을 것이고, 인스턴스가 Stop이 된다면 이미 할당받은 '10.10.10.10'은 사라지게 된다. 그렇게 된다면, 사용자들은 'www.dennsworld.com' 에 접속할 수 없다.(DNS 통신 불가)

 - 'Auto-assign Public IP'는 서버 상태가 'STOP'이 될 경우, 할당 받은 Public IP가 사라진다. 사라진 Public IP는 'START'할 경우, '다른' Public IP와 함께 시작된다!

  ex) 인스턴스를 시작하면서 '11.11.11.11'이라는 Public IP를 가지고 시작되었다면

DNS서버에서 'www.dennsworld.com' == '11.11.11.11' 로 변경해야 사용자가 접속 가능.

2. 변경되지 않는 Public IP를 사용하려면..

 - Auto-assign Public IP를 기본 설정으로 둔다. 'Use subnet setting(Disable)'

 - 인스턴스 생성 방법은 취향과 필요에 맞춰 생성하도록 하고.. 다 만들고 나면 EC2 서비스의 좌측 패널 중간에 위치한 'NETWORK & SECURITY' -> 'Elastic IPs'로 들어가서 새로운 EIP를 할당받는다. (영문버전에서는 Allocate new address)

새롭게 할당받은 EIP와 인스턴스를 연결해줘야 한다.

Associate address를 통해 연결해 줄 수 있으며, 아래를 참고.

할당받은 EIP와 Instance ID를 연결해주자.. Instance의 Name을 통해 입력해줘도 되고, Private IP를 입력해줘도 되니 편할대로 하면 된다.

 * 경고 : 이렇게 할당받은 EIP는 서버를 중지시켜도 EIP에 대한 비용은 계속 청구되니, 별도의 주의가 필요하다.

* 서버가 STOP되어도 내가 가지고 있는 Public는 고정되어있다는 장점과 WEB 서버를 신규 구축하여 이전할 경우에도 할당받은 EIP를 신규 인스턴스와 연결해주면 새로운 서비스를 이용할 수 있다.(물론 대부분은 LB를 사용하기 때문에 EIP를 이동시키는 경우는 거의 없을 것이다..)

1. CLI ??

 CLI는 Command Line Interface의 줄임말이며, 말 그대로 명령어를 입력하여 사용하는 방식. 대부분의 사람들이 AWS Console을 이용해 손쉽게 AWS를 컨트롤하지만, CLI를 사용하면 조금 더 쉽게 원하는 내용만 추출할 수 있다는 장점이 있으며, 지속적으로 활용해볼 가치가 있음.

2. CLI 활용이 필요한 상황

 현재 사용하고 있는 여러개의 ALB 중 일부가 Access Log 기능이 활성화되어있지 않아 장애 발생 시, 로그 확인에 어려움을 겪을 수 있는 상황 발생. Access Log 기능이 활성화되어있는지를 확인하기 위해서는 한 개씩 모든 ALB를 확인하면 되지만 더 쉽게 찾아보기 위해 시도.

CLI를 통해 해당 문제가 완전히 해결된 상황은 아니지만, 혹여나 저와 비슷한 생각을 가지고 계신 분이 있지 않을까 하여 우선 작성.

CLI를 활용하기 위해서는 사용자 PC에 AWS CLI를 설치해야하며, 설치 방법은 검색해보시길..

3. CLI 활용 방법

 CLI는 리눅스와 마찬가지로 지속적으로 help 명령어를 통해 확인할 수 있음.

처음 사용을 어떻게 해야할지 모르겠을 때는, aws help를 입력하면 aws의 어떤 서비스들을 CLI를 통하여 사용가능한지 모든 서비스 확인 가능.

aws elbv2 describe-load-balancers

현재 aws cli를 설정한 계정에는 테스트를 위해 ALB 하나만 만들어 둔 상태이며, ALB에 대한 설명이 나옴.

하지만 제가 확인하고자 하는 정보는 해당 명령어를 통해 확인이 불가능하여 다른 명령어를 찾아 다시 입력.

aws elbv2 describe-load-balancer-attributes --load-balancer-arn arn:aws:(내소중한 정보)

해당 명령어를 입력하였을 때, 내가 찾고자 하는 "access_logs.s3.enabled", "false"가 나옴.(테스트를 위해 만든 ALB는 access log 비활성화 상태)

위의 명령어는 원하는 로드밸런서의 ARN(Amazon Resource Name)이 필요하기 때문에 VPC에 있는 모든 정보를 한번에 찾을 수 없다.

방법을 찾기위해 노력하는중..

시도했던 방법 1.

arn을 입력하여야 할 부분에 *를 사용하여 모든 arn을 검색하는 방법이 될까 싶어 시도해보았지만..내가 찾는것과는 다르지만 IAM의 무언가를 추출할 때도 ARN이 필요한 것을 알았으며, AWS측에서 가이드하는 아래 내용을 보고 포기.

시도중인 방법 2.

현재 내 계정내에 있는 모든 로드밸런서의 arn을 먼저 추출하여, 위 식에 대입해보는 방법

테스트를 위해 로드밸런서를 한개 더 생성하여(총 2개 로드밸런서) 모든 로드밸런서 arn을 추출하고,

arn을 사용해야 할 곳에 반복문이나 aws cli에서 사용가능한 논리연산을 사용하여 찾는 방법을 고민중...

*elbv2를 통해 ALB, NLB, CLB 모두 확인할 수 있는 명령어이며, 'elb'명령어도 있으니 필요에 따라 참고해서 사용하면 됨.

4. 느낀점

 CLI를 이리저리 잘만 사용하면 많은 AWS 리소스 컨트롤을 보다 쉽게 할 수 있을 것(모든 리소스를 사용자가 굳이 찾아 낼 필요 없이 추출)이라 생각하며, CLI를 활용하여 많은 테스트 진행 필요.

1. 만료되는 인증서 확인하기.

만료 인증서 : recruit.---.com

DashBoard를 들어가면 'Scheduled Changes'를 통해 확인이 가능하다.

위의 사진을 보면 총 3개의 예정된 작업이 있으므로 확인이 필요함.

'Event' 내용 중 'CertificateManager renewal state change'는 인증서를 의미하며, 우측 화면을 보면 어떤 인증서가 만료되는지 확인이 가능하다.

기본적으로 Amazon에서 발급받은 인증서는 자동연장이 되는 것으로 교육을 받았으나, 아마존 초기에 발급받은 인증서라 자동 연장이 안되는 것으로 파악되며, 어느 시점의 인증서부터 수동 연장인지 확인 불가.

2. 'Certificate Manager' 서비스 확인

Certificate Manager를 들어가면 SSL 인증서를 확인할 수 있으며, 해당 화면의 'Type'에 Amazon Issued 라고 되어있는 것은 아마존에서 발급받았다는 것을 의미. 외부 인증서의 경우 'Imported'로 표기됨.

*참고로 외부에서 발급받은 인증서(Sectigo '예전 Comodo', Global Sign 등) Import가 가능함. Import 방법은 추후 인증서 교체 시기에 작성 예정

'recruit.---.com' 도메인을 찾아 클릭 후 Action -> Resend validation email 을 통해 메일로 수신 가능

(Resend validation email인 이유는...사실 인증서 만료일이 다가오면 등록된 이메일로 승인 요청 메일이 오지만, 일정 기한이 지나면 해당 메일은 유효하지 않아 재전송해야함. 만료일이 남아있더라도 이메일 유효 기간은 지남.)

- 이메일을 수신하면 위의 내용으로 메일을 받으며, Certificate Manager의 경우 글로벌 서비스가 아니라 인증서가 있는 지역을 선택. 예시 도메인은 'ap-northeast-2' 이므로, 서울 지역에 있음.

- 'Amazon Certificate Approval' 클릭

인증서 만료일이 연장되었다는 문구를 바로 확인 가능.

3. 웹콘솔에서 인증서 기한 연장 확인 방법

인증서 클릭 후 확장버튼을 클릭(체크박스 오른쪽에 화살표)하면, Validation status를 확인 가능.

'recruit.---.com' 인증서 상태 변경을 깜빡해서 다른 인증서 사진으로 교체..

4. 인터넷 창에서 인증서 확인 방법

인터넷 창에서 https://recruit.---.com 을 입력하여, 인증서를 확인.

발급대상 : recruit.---.com

발급자 : Amazon

5. 외부 인증서 만료 시

외부 인증서가 만료될 경우, 발급받은 사이트에서 연장하더라도 AWS에서는 확인이 불가능하기 때문에 다시 한번 인증서를 Import해야함.

1. FSTAB의 용도

 - 파일시스템 정보가 저장되어 있음.

 - 해당 탭에 저장되지 않은 파일시스템이 있을 경우, 재부팅했을 때 기록되어 있지 않은 파일시스템은 마운트가 빠짐.

 - /etc/fstab 에 위치하고 있으며, 지속적으로 마운트시키고 싶은 경우에는 에디터를 이용하여 내용 수정이 필요.

 - 즉, 영구적 마운트를 설정하는 탭

2. FSTAB 구성

명령어 : vi /etc/fstab

편집기를 사용하여 fstab을 수정할 경우, 위와 같은 화면이 나타난다.

[파일시스템장치] - [마운트 위치] - [파일시스템 종류] - [옵션] - [덤프] - [파일체크 옵션] 순으로 기록되어 있음.

[파일시스템 장치]

: 파일시스템 장치명이 입력되어야 하며, 명령어 df -h 를 입력할 경우 파일시스템 장치명을 확인할 수 있다.(ex. /dev/xvda1 과 같음.)

[마운트 위치]

 : 말 그대로, 마운트 위치를 어느곳으로 할 지 입력하면 됨. 다른 글에도 작성했던 것 처럼, 마운트는 대체로 /mnt 에 위치시키기는 하지만 원하는 곳으로도 변경이 가능하다. /mnt 파일 안에 mkdir point1(point1 이라는 디렉토리 생성)을 입력하여 mnt 디렉토리 하위에 point1(이름은 알아서..)을 만들고 그 곳에 마운트 되도록 입력해주면 됨. 예시를 든 것이기 때문에 원하는 위치에 디렉토리를 생성하여 사용.

fstab은 현재 붙어있는 디스크를 영구적으로 마운트 시키는게 대부분이기 때문에 현재 마운트된 위치에 해주는 것이 바람직.

[파일시스템 종류]

 : 파일 시스템은 다양. ext, ext2, ext3, ext4, nfs 등등이 있으며, 현재 마운트시키는 디스크의 종류가 무엇인지 필히 확인 후 입력해야한다.

명령어 : df -T  (대소문자 구분)

해당 명령어를 입력해보면 현재 마운트되어있는 파일의 시스템 종류 확인이 가능.(옵션 T는 Type)

파일시스템 종류를 확인 후 fstab에 입력해주면 된다.

[옵션]

 : 파일시스템을 용도에 맞게 사용하기 위한 속성을 설정하는 옵션. 옵션은 아래와 같은 종류가 있으며,

특별한 옵션 설정이 필요하지 않으면 default를 사용.

default : rw, suid, dev, exec, auto, nouser, async 옵션을 모두 선택한 것과 같다.

auto : 부팅시 자동으로 마운트 된다.

exec : 실행파일이 실행되는 것을 허용하는 파일 시스템이다.

suid : SetUID와 SetGID의 사용을 허용하는 파일 시스템이다.

ro : 읽기 전용 파일시스템이다.(Read Only)

rw : 읽고 쓰기(Read Write) 파일시스템으로 사용된다.

user : 일반 계정사용자들도 마운트를 할 수 있는 파일시스템이다.

nouser : root만 마운트할 수 있는 파일시스템이다.

noauto : 부팅시 자동으로 마운트 되지 않게하는 파일시스템이다

noexec : 실행파일을 실행되지 못하게 하는 파일시스템이다.

nosuid : SetUID와 SetGID의 사용을 허용하지 않은 파일시스템이다.

usrquota : 개별 계정사용자의 Quota설정이 가능한 파일시스템이다.(쿼터:사용자별로 디스크 할당을 조정(제한))

grp : 그룹별 Quota설정이 가능한 파일 시스템

[덤프]

 : 0 or 1의 설정만 가능하며, 백업이 되어야 하는지 설정하는 필드.

  0 - 백업이 불가능

  1 - 백업이 가능

[파일체크 옵션]

 : 0 or 1 or 2 의 옵션 설정이 가능.

  0 - 무결성 검사를 진행하지 않음.

  1 - 우선순위로 1순위. 보통 루트 파일시스템에 설정.(위 사진에서도 맨 윗줄에 1 옵션이 기록되어 있음.)

  2 - 1순위 검사 후 2순위 검사 진행.

0. 들어가며..

Yum을 통해 쉽게 설치할 수 있으며, RPM(Redhat Package Manager)을 통해 매우 간단하게 확인할 수 있음.

패키지 관리 툴은 설치와 삭제 등을 사용자가 쉽게 작업할 수 있도록 도와주는 역할을 함

우선 RPM은 레드햇 계열에서만 사용이 가능하니, 리눅스 계열에 따라 패키지 관리를 진행하면 됨.

 CentOS는 Redhat 계열이기 때문에 정상적으로 RPM을 통한 패키지 관리 가능

위와 같이, Ubuntu는 apt로 사용 가능하다는 문구가 출력됨.(apt : Advanced Packaging Tool)

(정정)Ubuntu는 apt를 통해 rpm을 설치해야함. apt을 통해 rpm 대체가 가능. (2020-07-17)

1. 어떤 계열의 리눅스를 사용하는지 확인(Redhat? Debian?)

- 내가 사용하고 있는 Linux가 무엇인지 확인하는 방법은 매우 간단하다. 얼마 전에도 글을 작성했지만, /etc에는 시스템의 거의 모든 설정이 들어있기 때문에 /etc 디렉토리를 통해서 현재 사용중인 OS 확인이 가능하다.

명령어 : cat /etc/os-release

혹시나, 'Red Hat 계열이 아닌 경우는 어떻게 확인하지..?'라는 의문이 생길 수 있기 때문에 Ubuntu 환경에서도 동일한 방법으로 OS를 확인하여 보았음.

2. Apache가 설치되어있는지 확인

명령어 : rpm -qa httpd, yum list httpd

해당 명령어가 궁금한 경우 rpm --help 를 통해 내용을 확인할 수 있습니다.(바로 아래 참고)

아파치가 설치된 경우에 출력되는 list는 아래 설치 완료 후 나올 예정.

3. Apache 설치하기

명령어 : yum install httpd

Apache 뿐 아니라, 어떠한 패키지를 설치하고자 한다면 Root 권한이 있는 계정으로 접속해야 한다. Root 계정이 아니라고 해서 잘못되는 건 아니고, 단순히 아래와 같은 문구가 뜰 뿐..

계정을 su 계정으로 변경 후 위 명령어를 다시 입력하면 정상적으로 설치가 진행됨

어느 정도의 용량이며 설치를 진행할 것인지를 묻는 글이 나온다. 물론 'y'

하단에 'Complete!' 문구를 본다면 설치가 완료된 것.

명령어 : rpm -qa httpd, yum list httpd

맨 위에 있는 설치 전과 비교했을 때, 'httpd-2.4.6-93.el7.x86 64'를 확인 가능.

4. 서비스 시작하기

명령어 : service httpd start

'service httpd start' == 'systemctl start httpd.service' 와 같은 명령어이며, Redirecting 된 것임(기본설정)