Category: Linux

terraform-provider-ncloud-review

오늘 하시코프x네이버클라우드 웨비나에서 terraform 과 Vault 에 대한 웨비나를 청취했습니다.

https://github.com/NaverCloudPlatform/terraform-provider-ncloud

이전에 방과후(?) meetup에서 네이버클라우드가 테라폼의 프로바이더로 있다는것을 알았습니다. 그 덕분에 네이버클라우드에서 terraform은 이미 경험이 있는 상태고, Vault도 경험이 있었습니다. 오늘의 주제 중 Secrets Engines이 궁금했습니다.

https://www.vaultproject.io/docs/secrets

Secrets engines are components which store, generate, or encrypt data.

시크릿엔진은 데이터를 저장또는 생성하고 암호화하는 구성요소.

AWS 의 Parameter Store / Secrets Manager 와 비슷한 기능을 한다고 생각이 들었습니다. 다른 벤더에서도 비슷한 서비스들이 있습니다.

https://hackernoon.com/aws-secrets-manager-vs-hashicorp-vault-vs-aws-parameter-store-bcbf60b0c0d1

https://www.cloudjourney.io/articles/security/aws_secrets_manager_vs_hashi_vault-su/

가장 일반적인 사용예라 생각되는것은, access key의 암호화라 생각됩니다. 일반적으로 aws-vault 같은 명령어로 지원합니다.

아직 ncp-vault 가 만들어진게 아니라, ncp 내에서 사용하기엔 좀 불편한 부분이 있으리라 생각됩니다. 현재 npc 는 provider로 등록된 상태고 cli 를 지원하므로 차차 지원하리라 생각됩니다.

https://www.44bits.io/ko/post/securing-aws-credentials-with-aws-vault#%ED%85%8C%EB%9D%BC%ED%8F%BCterraform%EC%97%90%EC%84%9C-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0

aws 에서의 vault 사용예입니다.

https://www.vaultproject.io/docs/secrets/databases/mysql-maria

mysql-maria db의 user 암호화입니다.

이런 방법이 필요한 이유는 결국 어플리케이션 소스의 탈취로 문제를 방지하기 위함입니다. key의 자동로테이션이나, expire time 을가진 key 발급등을 할 수 있습니다.

Vault 는 근래에 들어서 굉장히 핫한 오픈소스라 테스트 해보시는게 좋을것 같습니다.

마무리를 하자면..

템플릿 소스들이 점점 쌓이고 사용예가 늘면 IaC는 점점 더 일반화 될것입니다.

미리미리 IaC를 준비하고 사용방법을 익히는것도 좋을것 같습니다.

조만간 Secrets Engines 사용하기 위해 자동화 스크립트를 적용하는 고민을 한번 해보려 합니다. 시간이 나면 한번 테스트 해봐야겠습니다.

읽어주셔서 감사합니다!

linux-port-range-reuse

https://www.cyberciti.biz/tips/linux-increase-outgoing-network-sockets-range.html

https://meetup.toast.com/posts/55

http://docs.likejazz.com/time-wait/

tcp port range는 32768에서 61000까지다 대략 28000개의 가용포트가 있다는것이다.

클라이언트로서 28000개의 가용포트를 모두사용하게되면?

더이상의 새로운 TCP 세션을 생성할수 없게된다. 

#tcp port range
echo 10240 60999 > /proc/sys/net/ipv4/ip_local_port_range

그래서 일단 10240 - 60999 개의 포트를 사용할수 있도록 수정해줬다.

예약포트들은 포통 10240 아래로 포진되어 있고, 61000 포트위로는 패시브 포트로 사용하는경우가 많으므로 일단 10240-61000포트를 사용할수 있도록 수정했다. 50000개 가량의 포트를 사용가능하도록 수정한거다.

그래도 해결이안되는듯 했다. 

[root@linuxer ~]# netstat -an | grep TIME_WAIT | wc -l
51314

두배 이상의 port range 에도 처리가 불가능한 수준이었던것..

#tcp_timestamps 기본으로 이미 적용되어있음
$ sysctl -w ipv4.tcp_timestamps="1" 
#tcp reuse
$ sysctl -w net.ipv4.tcp_tw_reuse="1"

그래서 두가지 방법중 tw_reuse / tw_recycle 둘중 하나를 사용하려했다. reuse 옵션은 소켓재활용, recycle 은 강제로 TIME_WAIT인 포트를 종료하는거다. 좀 더 시스템에 영향을 덜주는 방법인 reuse를 선택했다.

-홀스님의 첨언

tw_recycle은 서버입장에선 문제가 생길수있으니 설정에는 반드시 주의가 필요하다.

일단은 처리를 했고, 서비스의 동작을 모니터링중이다.

모든옵션을 켜는 방법이다. 참고하길..tcp_tw_recycle옵션은 사용할때 꼭 주의 해야한다

sysctl -w ipv4.tcp_timestamps="1"
sysctl -w net.ipv4.tcp_tw_reuse="1"
sysctl -w net.ipv4.tcp_fin_timeout="10"

일단 이 방법은 좀 임시방편이고, 좀 더 확장성있는 방법으로 가기위해선 scale out을 해야한다.

또 추가하자면..

FIN_WAIT2 / TIME_WAIT 두가지의 TCP 파라미터가 60초의 기본시간을 가지게 되어서 총 2분의 대기시간을 가지게 된다. 컨트롤 할수있는 파라미터는 FIN_WAIT2 상대의 파라미터를 수정 하는경우도 있다고 한다. 수정할수 있는파라미터는 대부분 /proc/sys/net/ipv4 경로에 위치하니 하나씩 확인해 보자.

글을 다쓰고 추가로 내용을 덕지덕지 붙인거라 깔끔하지 않다.

하지만 도움이 되길 바란다!

마지막으로 php-mysql은 커넥션풀이 없다고 알고있었는데 라이브러리가 있었다.

https://bkjeon1614.tistory.com/216

아직테스트는 해보지 않은 상태고, 슬슬 해보겠다.

DNS-spf-google

spf 레코드는 RFC 4408 의해서 255 characters으로 제한된다.

하나의 레코드가 255 characters 라는 이야기다.

그래서 255 characters 이상을 쓰려면 어떻게 해야할까? 그것을 구글의 사용 예를 들어서 설명하고자 한다.

google.com text = "v=spf1 include:_spf.google.com ~all"

_spf.google.com 도메인을 include 하고 _spf.google.com 도메인을 쿼리하면

_spf.google.com text = "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

_netblocks.google.com
_netblocks2.google.com
_netblocks3.google.com

세개의 도메인을 알려준다. 세개의 도메인은 각각의 역할에 따라 ipv4나 ipv6를 응답한다.

_netblocks.google.com text = "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

_netblocks2.google.com text = "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"

_netblocks3.google.com text = "v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

이렇게 2단계의 include를 거쳐서 255 characters 이상의 레코드를 구성한다.

그렇다면 A recode로 spf 를 관리하려면 어떻게해야 할까?

https://spam.kisa.or.kr/filemanager/download.do?path=spam/customer/archive/&filename=SPF%EA%B8%B0%EC%88%A0%EB%AC%B8%EC%84%9C.pdf

linuxer.name text = "v=spf1 a:_1.linuxer.name ~all"

바로 이런식이다 include: 부분을 a: 로 변경하는것이다.

그리고.. spf 레코드는 사용하는 대역이나 ip를 알려주는것 외에 정책을 정하는 역할을 하는데 다음과 같은 규칙이 적용된다.

Neutral (?) 출판된 데이터에 근거해 판단을 내릴 수 없음
Pass (+) 가 인가되어진 발송서버로 확인됨
Fail (-) 가 인가되어지지 않은 발송서버로 확인됨
Softfail (~) 는 인가되지 않은 발송서버이나 “Fail” 정책의 적용은 유보함.

linuxer.name text = "v=spf1 a:_1.linuxer.name +all"

이런식이면 _1.linuxer.name a 레코드로 등록된 IP는 인가된 발송서버로 확인된다는 의미다.

오랜만에 spf 레코드를 다시 복습하면서 정보진흥원의 문서를 보며 감탄 또 감탄했다.

위의 문서를 꼭 보시라!

linux-lsof

사이트 확인중 이상 증상이 있는 고객이 있었다.

사용량이 많아지면 mysql.sock 에러가 발생하는 것이었다.

apache 에서 mysql 접속시 socket을 생성한다는건 일반적으로 접속을 Localhost 로 설정해야 하는데, local의 database를 사용하지 않는 상태였다.

socket을 사용하는 에러를 찾기위해 lsof 를 먼저 사용했다.

lsof | grep sock
httpd 15233 apache 5u sock 0,7 0t0 658393448 can't identify protocol
httpd 15250 apache 3u sock 0,7 0t0 658393444 can't identify protocol
httpd 15250 apache 5u sock 0,7 0t0 658393448 can't identify protocol
httpd 15258 apache 3u sock 0,7 0t0 658393444 can't identify protocol
httpd 15258 apache 5u sock 0,7 0t0 658393448 can't identify protocol
httpd 15312 apache 3u sock 0,7 0t0 658393444 can't identify protocol
httpd 15312 apache 5u sock 0,7 0t0 658393448 can't identify protocol
httpd 15314 apache 3u sock 0,7 0t0 658393444 can't identify protocol
httpd 15314 apache 5u sock 0,7 0t0 658393448 can't identify protocol

can't identify protocol mysql.sock 문제가 아니라 apache 의 sock 문제가 발생하고 있었다.

can't identify protocol 는 소켓이 완전히 닫히지 않거나 누수가 있다고 판단되는데, 확인이 필요했다. 요인은 openfile 갯수나 여러가지 요인이 있을거라 생각해서 먼저 openfile을 확인했다.

ulimit 로 확인한 openfile 갯수는 1024와 일단 수정해 줬다.

echo "* soft nofile 65535" >> /etc/security/limits.conf
echo "* hard nofile 65535" >> /etc/security/limits.conf
ulimit -Hn 65536
ulimit -Sn 65536

cat /proc/net/sockstat
sockets: used 261
TCP: inuse 17 orphan 0 tw 44811 alloc 54 mem 49
UDP: inuse 5 mem 15
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0

sockstat 를 확인시에 현재는 문제가 되는 상태는 아니었다.

이 조치 이후 추가적인 모니터링을 진행할 것이다.

AWS-Linux-EBS-to-EFS

아키텍쳐를 수정중에 EBS에서 EFS로 파일을 넘길일이 생겼다.

300G 가량의 대량의 파일이 있는 디렉토리를 sync 해야했다.

EBS는 GP2로 400G, 1200IOPS를 가진 볼륨이었다. 스냅샷에서 볼륨을 생성해서 4T로 확장하여 12000IOPS를 가진 볼륨에서 테스트를 진행하였다.

새벽에 먼저 싱크를 진행한 내용이 있는데 network out 이 40mb를 넘지 않았다.

싱크는

rsync -av /src /dst

로 진행한것 같았다. rsync 의 속도를 끌어 올리기 위해 테스트했으나 실패. 속도는 40mb 에서 더 이상 올라가지 않았다.

그래서 강구한 방법이 tar 를 이용한 데이터 이동이었다.

tar -C <src> -cf - . | tar -C <dst> -xf -

속도는 170mb 정도 그러나, 치명적인 단점이 존재했다. 소유권과 퍼미션을 가져오지 않는것이었다.

-_-; 파일이동이라 함은..소유권과 퍼미션을 그대로 가져가야하는데...그게 안됬다. 그래서 임시 방편으로

tar -cvf /dst/file.tar /src

명령어로 EBS의 데이터를 tar 로 압축해서 EFS로 저장하는 명령어로 작업했다.

이때 속도는 170MB 정도.. tar로 압축하지 않고 pipeline 으로 보냈을때와 동일한 방식이지만 소유권과 퍼미션을 유지할수 있는 방법이다.

그렇지만 속도가 마음에 들지 않았다.

물망에 rclone / rdiff-backup 가 있었다.

rclone 은 씅광님이 추천해줘서 오후내내 테스트를 했다. 그런데 속도가 너무 잘나오는데 문제는 퍼미션과 소유권을 가져올수 없는것이다.

그래서 승광님께서 주신 힌트로 테스트를 진행했다.

clone sync /src /dst --checkers 128 --transfers 128

속도는 놀라웠다. T3a.medium type의 네트워크 성능(Gbps) 이라 표기된 5G를 모두쓰는것이었다.

이렇게 network 를 모두 사용하는것은 처음이라 신기할정도로 rclone는 빨랐다.

300G 모두 sync하는데 1시간 30분밖에 걸리지 않았으니까..

그런데 여기서 rclone은 문제가 발생한다.

https://rclone.org/local/#filenames

Filenames

Filenames should be encoded in UTF-8 on disk. This is the normal case for Windows and OS X.

There is a bit more uncertainty in the Linux world, but new distributions will have UTF-8 encoded files names. If you are using an old Linux filesystem with non UTF-8 file names (eg latin1) then you can use the convmv tool to convert the filesystem to UTF-8. This tool is available in most distributions' package managers.

If an invalid (non-UTF8) filename is read, the invalid characters will be replaced with a quoted representation of the invalid bytes. The name gro\xdf will be transferred as gro‛DF. rclone will emit a debug message in this case (use -v to see), eg

인코딩 문제인데 이건...하...나중에 rsync 로 남은파일을 채워볼까 생각했지만 불확실성이 너무 컷다. 파일의 누락이 너무많았다

그래도 테스트는 그냥 진행했고 싱크속도 무지빠르고 쓸만했다.

그래서 이후에 소유권과 퍼미션을 넣어주는 작업을 궁리했다.

getfacl -R /src > file.list
sed 's/src/dst/g' file.list
cd /dst
setfacl --restore=file.list

4줄의 명령어로 소유권과 퍼미션을 그대로 가져오는 방법을 찾았다.

이제 인코딩 문제만 해결하면된다 생각했지만, 안정성의 문제때문에

tar로 압축해서 넘기를 방식으로 계속진행하기로 생각했다.

오늘 적당한 낚시와 어드바이스를 주신 승광님께 감사드린다!

Linux-ping-test

http://ping.pe/

세계 곳곳의 IPS에서 ping test를 해볼수 있는 사이트.

이사이트가 정말 좋은게....이미지 저장 기능을 지원한다.

http://i.ping.pe/x/O/img_xONzUz1e.png

이렇게 이미지를 저장해서 링크로 지원한다는 사실!

그리고 또

port 나 dig 를 지원하는데

이렇게 TTL까지 남은 값을 보여주므로...시안성이 폭발한다는거..

NCP-SSD-Server-IOPS

오늘 [7월] 네이버클라우드플랫폼 공인교육 - Professional을 다녀왔습니다.
교육을 받다보니 좀 흥미로운 내용이 있더군요.

NCP의 SSD VM은 최소 IOPS가 4000입니다.

블로깅을 하던때가 아니라서 포스팅이나 결과를 깔끔하게 정리한게 아니라 공개하긴 어렵지만 AWS에서도 비슷한 테스트를 한적이 있습니다.

EBS- GP2를 20개를 하나의 인스턴스에 붙여서 100 IOPS 인볼륨을 20개를 붙여서 2000 IOPS로 늘려서 디스크 자체의 퍼포먼스를 올리는 테스트를요.

이 테스트는 많은 엔지니어들이 장난식으로 테스트를 진행했고 유효한 결과를 얻은적이 있는 테스트 입니다. 물론 라이브 서버에 도입하기엔 부담이 따르고 리스크에 비해 얻을수 있는 장점이 크지 않다보니 테스트로만 끝낸적이 있습니다.

그런데 제앞에 10G의 기본 IOPS가 4000짜리가 나타난 것입니다.

NCP의 VM이 가진 제한이 볼륨 16개 까지 붙일수 있는데, OS 볼륨을 제외하면 15개 까지.

150G의 용량으로 60000 IOPS라는 계산이 나옵니다. 그럼 NCP 의 최대 IOPS는 얼마인지 볼까요?

NCP의 IOPS 계산은 1GB당 40IOPS가 증가합니다. 500GB 일때 20000 IOPS 그러니까 볼륨의 가성비는 10G일때 제일 높은셈입니다.

가성비가 제일 높은 볼륨 15개를 추가할 비용을 계산해보면 월 17280원이 추가되는군요.

그럼 월 17280 원으로 낼수있는 최대 성능을 테스트 해볼겁니다.

사실 객관성은 이쯤해선 망각해도 됩니다.
아무래도 서비스에선 사용하기 어려운 구성이니까요.

먼저 볼륨 15개를 인스턴스에 붙입니다.

그리고 아래 스크립트를 돌려서

#!/bin/sh
for VAR in `fdisk -l | grep "Disk /dev/" | grep -v xvda | awk -F: '{print $1}' | awk '{print $2}`';
do
(echo n; echo p; echo 1; echo 2048; echo; echo t; echo 8e; echo w) | fdisk $VAR
done
a=`fdisk -l | grep '/dev/xvd.1' | grep -v '/dev/xvda' | awk '{print $1}'`
pvcreate $a
vgcreate linuxer-lvm $a
lvcreate -l 38385 -n volume linuxer-lvm
mkdir /lvm
mkfs.xfs -f /dev/linuxer-lvm/volume
mount -t xfs /dev/linxer-lvm/volume /lvm

마운트 까지 완료했습니다.

[root@s1734ba4660a ~]# vgdisplay
--- Volume group ---
VG Name linuxer-lvm
System ID
Format lvm2
Metadata Areas 15
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 15
Act PV 15
VG Size 149.94 GiB
PE Size 4.00 MiB
Total PE 38385
Alloc PE / Size 38385 / 149.94 GiB
Free PE / Size 0 / 0
VG UUID YEEHFI-FpvU-fTmE-YnHx-9itm-mhH6-QUsz8j

vg도 잘만들어져서 마운트까지 정상적으로 됩니다.

속도 테스트하려니까 너무 귀찮아서..........................

으앙주금...

여러분 이포스팅은 언젠간 마무리 할테지만...

오늘은 아닌가 봅니다.

굿밤!

linux-유용한 명령어

7/6일 오픈카톡 대화에서 발췌

glances - top / htop 대용

yum install python-pip python-devel
pip install glances

lsof list open files

lsof 는 열려있는 파일리스트를 보여준다. 예를들어 pid 3222를 확인하려 한다고 하면 아래와 같이 쓰면 된다.

lsof -p 3222
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
httpd 3222 apache cwd DIR 202,1 278 96 /
httpd 3222 apache rtd DIR 202,1 278 96 /
httpd 3222 apache txt REG 202,1 553600 61998 /usr/sbin/httpd
httpd 3222 apache mem REG 202,1 26976 1392 /usr/lib64/libnss_dns-2.26.so
httpd 3222 apache mem REG 202,1 57296 1394 /usr/lib64/libnss_files-2.26.so
httpd 3222 apache mem REG 202,1 37032 35796 /usr/lib64/libnss_sss.so.2
httpd 3222 apache mem REG 202,1 62432 8533557 /usr/lib64/httpd/modules/mod_proxy_http2.so
httpd 3222 apache mem REG 202,1 2462992 86241 /usr/lib64/libcrypto.so.1.0.2k
httpd 3222 apache mem REG 202,1 158280 485506 /usr/lib64/libnghttp2.so.14.18.0
httpd 3222 apache mem REG 202,1 248888 8533556 /usr/lib64/httpd/modules/mod_http2.so
httpd 3222 apache mem REG 202,1 40152 8676027 /usr/lib64/httpd/modules/mod_cgid.so

awk 는 주로 sort 와 같이 사용된다.

220.122.174.19, 70.132.53.181 - - [06/Jul/2020:21:30:11 +0900] "GET /category/aws/ HTTP/1.1" 200 105327
220.122.174.19, 70.132.53.107 - - [06/Jul/2020:21:30:11 +0900] "GET /2020/06/aws-ec2-root-volume-resize-extending-linux/embed/ HTTP/1.1" 200 19832

위의 로그에서 IP 만 확인하고 싶다면

cat linuxer.name_access_log | awk '{print $1}'

같은명령어로 배열로 잘라서 출력할수 있다.

/ sed

ps -elf

ps afxuwww

ps afxuwww - 명령어는 전체를 다보여주면서 자식 프로세스까지 다보여준다...짱좋아

ps -ef -L

ss
tcp FIN-WAIT-1 0 1281 10.0.0.12:ssh 61.177.172.13:46933
tcp ESTAB 0 1280 10.0.0.12:ssh 61.177.172.13:40872
tcp ESTAB 0 0 10.0.0.12:ssh 61.177.172.13:48407
tcp ESTAB 0 0 10.0.0.12:57592 52.95.194.65:https
tcp ESTAB 0 1280 10.0.0.12:ssh 61.177.172.13:41761
tcp ESTAB 0 0 10.0.0.12:50144 52.95.195.99:https
tcp ESTAB 0 0 10.0.0.12:ssh 222.186.173.238:43018
tcp FIN-WAIT-1 0 1281 10.0.0.12:ssh 61.177.172.13:20460
tcp ESTAB 0 0 10.0.0.12:50104 52.95.195.99:https
tcp ESTAB 0 1280 10.0.0.12:ssh 61.177.172.13:19907
tcp FIN-WAIT-1 0 1 10.0.0.12:ssh 218.92.0.249:45695
tcp ESTAB 0 0 10.0.0.12:41014 52.95.195.109:https

tcpdump

ngrep - bpf filter가 되어서 L7 grep 가능

sar

iostate

strace / ftrace

NCP-CentOS7-to-CentOS8

NCP 에선 centos8을 지원하지 않는다. 그런데 yum update 를 해서 커널이 변경되면 정상적으로 부팅되지 않는다.

이런 내용들이 인스턴스를 생성할때 안내된다.

그런데, 어제 퇴근후 Meetup과정에서 KR-2 zone은 yum update 가 가능하다는 내용을 전달 받았다. 어쩐지 가끔 yum update 해도 정상적으로 부팅되는 인스턴스가 있더라니..

퇴근길 Meetup - 퇴근길 Tech Meetup 서버 관리 자동화 자료이다.

여기에서 이상함을 느끼고 여쭤봤더니 KR-2에서 하라고 하셨다..그래서 오늘작업의 힌트를 얻었다...

최신의 OS 를 사용하고 싶은건 엔지니어의 본능이 아닌가? 그래서 테스트를 시작했다.

How to Upgrade CentOS 7 to CentOS 8

준비물은 다음과 같다.

서버이미지 centos 7.3으로 생성된 인스턴스 한대다.

ACG-포트포워딩-root password 확인 이런 부분은 서버생성 가이드를 참고하자.

https://docs.ncloud.com/ko/compute/compute-1-1-v2.html

인스턴스를 생성하고 인스턴스에 접속하자 마자 할일은 yum update 이다.

yum update -y

업데이트를 마무리하면 epel repo를 설치해 사용할 수 있다.

yum install epel-release -y

epel을 설치하는 이유는 dnf 를 사용하기 위함이다. yum->dnf 로 패키지 설치 방법을 변경할거다.

yum install -y yum-utils rpmconf
rpmconf -a

rpmconf -a 를 입력하면 패키지의 conf를 업데이트 할지를 물어본다.

/etc/sysctl.conf
/etc/profile
/etc/shells
/etc/login.defs
/etc/nsswitch.conf
다섯개의 파일에 대해서 물어보는데 나는 모두 새로 인스톨하는것을 택했다. centos8 로 갈꺼니까.

package-cleanup --leaves
package-cleanup --orphans

다음은 패키지를 cleanup 하고, epel 을 설치한 이유인 dnf 를 설치한다.

yum install dnf -y

dnf 는 centos8 부터 기본적용된 rpm 패키지 관리 패키지인데 yum 에서 dnf로 변경됬다.
dnf 를 설치했다면 yum 을 지우자.

dnf -y remove yum yum-metadata-parser
rm -Rf /etc/yum

yum 을 지우고,

dnf install -y http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/centos-repos-8.2-2.2004.0.1.el8.x86_64.rpm http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/centos-release-8.2-2.2004.0.1.el8.x86_64.rpm http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/centos-gpg-keys-8.2-2.2004.0.1.el8.noarch.rpm

이제 centos8의 repo를 설치한다.

dnf -y upgrade https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

epel7 을 epel8로 업데이트 한다. 이제 centos8 패키지를 다운받을 수 있다.

dnf clean all

dnf 캐시를 clean 한다.

rpm -e `rpm -q kernel`
rpm -e --nodeps sysvinit-tools

rpm 명령어로 커널을 지운다. 여기서 모든 패키지가 삭제되지 않기때문에 후처리가 좀 필요하다.

dnf remove kernel-devel-3.10.0-1127.13.1.el7.x86_64 kernel-devel-3.10.0-327.22.2.el7.x86_64 kernel-devel-3.10.0-514.2.2.el7.x86_64 redhat-rpm-config iprutils-2.4.17.1-3.el7_7.x86_64 sysvinit-tools-2.88-14.dsf.el7.x86_64 sysvinit-tools-2.88-14.dsf.el7.x86_64 python36-rpmconf-1.0.22-1.el7.noarch

후에 의존성이 걸릴 패키지를 미리 삭제한다. 이 경우 NCP centos7.3 인스턴스에 맞춰서 의존성 패키지를 삭제한것이다. 의존성 문제가 발생하면 더삭제 해줘야 한다. 부담감 느끼지 말고 막 날리자. 안되면 처음부터 다시하면 된다.

dnf -y --releasever=8 --allowerasing --setopt=deltarpm=false distro-sync

명령어로 centos8 패키지를 설치한다. 새로 설치되는 패키지들을 유심히 보면 el8.x86_64 로 끝난다 centos8 사용하는 패키지 명으로 RHEL8 이라는 뜻이다. centos8 패키지가 잘설치된다는 소리다.

Complete!

이 단어가 보이면 거의 다된거다.

dnf -y install kernel-core
dnf -y groupupdate "Core" "Minimal Install"

dnf groupupdate 로 Core 와 Minimal Install 까지 업데이트 해주면 이제 된거다.

[root@s17308f26023 ~]# uname -a
Linux s17308f26023 3.10.0-514.2.2.el7.x86_64 #1 SMP Tue Dec 6 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@s17308f26023 ~]# cat /etc/redhat-release
CentOS Linux release 8.2.2004 (Core)

리부팅을 아직 안해서 릴리즈는 올라갔으나, 커널버전은 centos7 이다. 이제 리부팅 해주자.

[root@s17308f26023 ~]# date
Wed Jul 1 15:50:15 KST 2020
[root@s17308f26023 ~]# cat /etc/redhat-release
CentOS Linux release 8.2.2004 (Core)
[root@s17308f26023 ~]# uname -a
Linux s17308f26023 4.18.0-193.6.3.el8_2.x86_64 #1 SMP Wed Jun 10 11:09:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

이제 NCP에서 Centos8을 올렸다!

차후 커널지원이나 업데이트에 따라서 OS가 정상작동하지 않을수 있다. 모니터링이 문제가 될거라 생각했는데 잘돈다...

Centos8을 NCP에서 사용하고 싶다면 한번 진행해 보시기 바란다.

읽어 주셔서 감사하다!