KVM Image 용량 증설하기

KVM 가상화를 운영하고 있는데, 운영중인 VM 하나가 용량이 부족해지는 상황이 발생했다. KVM 가상화 VM 의 용량은 결국 이미지 파일 한개임으로 이 이미지 파일의 용량을 늘려주면 VM 의 용량이 사실상 늘어나는 것으로 생각했다.

하지만 현시점(2023) 에서 검색을 해보니 다양한 방법들이 존재했다. 그 중에는 VM 이미지를 로컬에 마운트해서 늘려주는 방법도 존재했지만 너무나 복잡해 보였다. 좀 더 쉬운 방법이 없을까 해서 검색한 결과 가장 쉬워보이는 것을 발견했고 이 방법으로 손쉽게 VM 용량을 늘리는데 성공했다.

VM 상태

용량을 늘리려는 VM 의 상태는 다음과 같다.

/dev/vda1 으로 파티션 하나로 보이지만 사실 SWAP 파티션도 존재한다. 이 SWAP 파티션의 /dev/vda2 디바이스이며 약 2G 용량을 차지한다.

VM 이미지 경로

VM 을 운영하는 Host 서버에서 VM 의 이미지가 어디에 있는지를 다음과 같이 살펴볼 수 있다.

VM 이미지 정보

VM 이미지의 정보를 아는 것은 매우 중요하다. VM 이미지의 타입이 존재하는데 raw, qemu 타입이다. 어떤 타입인지에 따라서 VM 이미지 용량을 늘리는 방법이 달라진다.

또, 가상 크기와 디스크 크기 정보 표시되는데 간혹 이 크기가 서로 다를 수가 있다.

기존 이미지 백업

혹시 모를 불상사를 방지하기 위해서 기존 이미지를 백업해 두자.

패키지 설치

VM 이미지를 늘리기 위한 작업을 위해서 필요한 패키지를 설치 해준다. 설치는 환경이 RedHat 기반이기 때문에 dnf 명령어로 설치를 하였다. 설치하는 패키지 이름은 배포판마다 다를 수 있다.

이 패키지를 설치하게 되면 virt-resize 명령어를 사용할 수 있다.

VM 이미지 디스크 정보

앞에서 VM 이미지 정보를 표시했다면 이제는 이미지 안에 디스크 정보를 봐야 한다. 각각 설치한 방법이 다르고 파티션 정보도 다르기 표시 되기 때문에 이를 잘 파악해야 한다.

VM 이미지 내의 디스크 정보는 다음과 같이 알 수 있다.

단일 파티션 /dev/sda1 만 보이지만 virt-df 명령어의 한계로 보인다. 왜냐하면 SWP 파티션도 존재하기 때문인데, 이 SWAP 파티션은 표시되지 않았다.

virt-filesystems 명령어를 통해서 이를 정확하게 알 수 있다.

위 정보를 보면 전체 50G 에 /dev/sda1 과 /dev/sda2 로 나뉘어 있다. /dev/sda2 는 swap 파티션으로 virt-df 일때는 나오지 않았다.

용량 증설을 위한 이미지 생성

다음과 같이 백업한 이미지를 가지고 작업을 진행한다.

이 작업은 매우 중요하다. truncate 명령어를 이용하는 것인데, -r 옵션으로 용량 증설을 위한 이미지를 만들었다. 그리고 그 이미지에 용량 증설을 설정한다. 여기서는 10G 용량을 늘린다

루트(/) 피티션 /dev/sda1 크기 변경

VM 이미지 내의 파티션 정보는 /dev/sda1 으로 보인다. 여기서 주의해야 할 것은 VM 이 가동된 후에 이미지 정보의 디바이스 이름은 /dev/vda1 으로 다르다. virt-df 혹은 virt-filesystems 나온 내용을 기반으로 디바스 이름을 정해야 한다.

용량 증설은 루트 파티션만 하면 됨으로 /dev/sda1 의 크기를 변경할 것이다.

변경 요약을 보면 /dev/sda1 의 용량이 증설될 것인데, 이 파티션의 파일시스템이 ext4 임으로 resize2fs 방법을 이용해서 크기가 확장될 것임을 알려주고 있다.

진행 상태를 보면 Copying /dev/sda1 으로 나오고 실행 명령어에서 변경전 이미지와 truncate 명령어로 새롭게 생성한 이미지를 인자로 줬는데, 아마도 변경전 이미지를 truncate 명령어로 새롭게 생성한 이미지에 순차적인 복사를 하는 것으로 보인다.

이미지 용량에 따라서 작업 시간는 차이를 보일 것이다.

새로운 이미지로 VM 시작한 후 파티션 확인

/mnt7/ubuntu20.04-new.img 이미지로 VM 을 부팅한다. 그리고 난 후 다음과 같이 파티션 용량이 늘었는지 체크한다.

용량이 10G 늘었다.

파일시스템 용량을 봐 본다.

앞에서 변경 요약을 보면 파일시스템이 뭔지를 파악하고 거기에 맞게 파티션 Resize 작업도 해주는 것으로 보인다. ext4 의 경우 resize2fs, XFS 의 경우에는 xfs_growfs 을 사용하는데 이런 작업은 파티션의 크기를 변경하는 것으로 VM 이미지 용량 증설과 함께 해준다.

따라서 별도의 파티션 용량 증설작업은 필요하지 않다.

G1 Collector 기본 설정

G1 GC 의 기본적인 목표는 짧은 STW 시간을 가지고 가는 것이다. 어짜피 STW 를 피하지 못할 바에야 이 시간을 짧게 가지고 가는게 유리하다.

여기서 구분해야할는게 있는데 STW 는 Young GC 일때도 발생한다. 하지만 그 시간이 매우 짧아서 못 느낄 정도일 뿐이다. Old GC 의 경우에는 Young GC 대비 STW 시간이 매우 길다. 그 이유는 Heap 메모리 전체를 청소해야하기 때문이며 청소해야할 공간이 클 수록 Garbage Collector 작동을 위한 자원 소모가 많아진다.

다음과 같은 목표를 갖는다.

  • 짧은 STW 시간을 갖도록 한다.
  • Full GC 가 발생되지 않도록 한다.

여기서 주목해야하는 것이 Full GC 발생하지 않도록 이다.

Full GC 발생 않도록…

MaxTenuringThreshold

이 말은 결국에는 Young GC 만 만들어야 한다는 것을 의미한다. 문제는 live Object 는 결국 최종적으로는 Old Generation 영역으로 이동할 수밖에 없다는데 있다. 그래서 G1 에서는 최대한 Old Generation 영역으로 이동하는 것을 늦출려고 한다. 이에 대한 파라메터가 -XX:MaxTenuringThreshold 다.

  • -XX:MaxTenuringThreshold: Sets the maximum amount of iterations to keep live objects in the new generation. This defaults to 15.

live 객체를 new generation 에 머물게하기 위한 최대 반복횟수로 번역된다. new generation 에서 Young GC 가 발생하면 오래 살아남을 live 객체를 선별되게 된다. 오래 살아남을 live 객체는 당연히 Old generation 영역으로 이동해야 하는데, 이것을 한번에 판단하지 않겠다는 뜻이다.

적어도 여러번.. 기본값으로 15번 정도는 같은 live 객체가 new generation 에서 생존해 있어야 한다. 그래야 ‘아~ 이놈은 오래 살아남을 놈이구나.. Old Generation 으로 옮기자’ 가 된다.

이러한 메커니즘은 Full GC 를 피하기 위한 것이다. Old Generation 에 live 객체가 많아지면 많아질 수록 Full GC 발생가능성은 커진다. 그래서 왠만하면 Young Generation 에 객체를 머물게하고 Garbage 가 되길 기다린다.

MaxGCPauseMillis – Do not set the new generation size unless required.

이 값을 꼭 지정하도록 하고 있다. G1 은 a pause time-target 을 갖는다. 이값은 MaxGCPauseMillis 로 지정하게 되는데 문제는 이 값을 어떻게든 충족되도록 동작하기 뒤해서 G1은 Young Generation 크기를 자동으로 조정하게 된다.

따라서 반드시 Young Generation 크기를 지정해서는 안된다. 오로지 MaxGCPauseMillis 값을 지정해주고 이를 통해서 자동으로 조정되도록 해야 한다. 200 ~ 500 사이에 값을 지정하면 되는데 될수있으면 그냥 기본값으로 둔다.

G1 에서 추천하는 JVM Options

다음은 G1 에서 추천하는 JVM Options 이다.

JVM OptionDetails
-XX:+DisableExplicitGC기본 추천 옵션으로 명시적 GC 를 사용하지 못하게 한다.
-XX:+UseStringDeduplication기본값이 disabled 인데, 켜준다. String deduplication 에 대한 메모리 사용을 줄여준다.
-XX:MaxMetaspaceSize최대 사용가능한 클래스 메타데이터 크기. 네이티브 메모리를 사용한다. 256MB 를 권장하지만 값은 유동적이다.
-XX:MaxTenuringThreshold기본값: 15. new generation 에 live 객체를 유지하기 위한 최대 반복 횟수. 오랫동안 살아남아야할 live 객체가 많다면 값을 낮추고 그렇지않다면 기본값 사용 권장.
-XX:+ParallelRefProcEnabled기본값으로 Disabled 인데, 사용하길 권장.

대략 다음과같이 Command Line 을 사용할 수 있다.

참고: Best practice for JVM Tuning with G1 GC

Docker, 클라이언트 TLS 인증서 설정

Docker 서버를 구축했으며, 도메인은 정식 도메인이 아닌 개인 도메인이며 인증서를 셀프 싸인 인증서를 만들어서 TLS 서버 설정을 했다고 치자. 이렇게 되면 Docker 가 TLS 를 이용해서 서버에 접속을 하기 위해서는 서버 TLS 인증서에 대응하는 클라이언트 인증서가 필요하게된다.

Docker 클라이언트 인증서

Docker 는 클라이언트 인증서를 /etc/docker/certs.d 디렉토리에서 찾게 된다. 이 디렉토리에 Docker 레지스트리 서버 호스트 이름과 같은 이름으로 디렉토리를 생성하고 그 안에 클라이언트 인증서를 세팅하면 된다.

이러한 구조는 다음과 같다.

의외로 간단하다.

참고: Verify repository client with certificates

Gitlab 백업/복원

Gitlab 을 업데이트 하면서 보여지는 백업 메시지들은 다음과 같다.

업데이트를 하기전에 데이터베이스와 설정 파일들을 백업하고 있다.

만일 전체 백업을 하고 싶다면 다음과 같이 명령어를 이용할 수 있다.

수행후 생성된 백업 파일은 /var/opt/gitlab/backups 디렉토리에 만들어 진다.

만일 복원을 해야 한다면 백업 디렉토리에 백업한 파일을 올려놓고 다음과 같이 하면 된다.

거머리 같은 한국의 IT 프리 개발자들….

요즘에 자주 들리는 뉴스, 아니 어찌보면 몇해전부터 듣고 왔던 이야기들… 유리지갑 직장인들, 장시간 노동에 업계에 몇년을 있어도 실소득이 오르지 않는 기이한 현상. 이러다보니 너도나도 주머니에 들어도는 돈을 중요시하는 시점에서 살게된다.

이왕이면 연봉이나 복지에 안정적인 직장인 보다는, 아니 ‘안정적인 직장’ 이라는 개념이 없어진지 오래고 복지라는 것도 기껏해야 돈 몇푼 더 지원해주는 정도이다 보니 너도나도 이제는 실질적인 손에 쥐는 돈에 눈이 돌아갈 수밖에 없는 세상.

그런데, 문제는 그렇게 실질적인 손에 쥐는 돈을 얻기 위해서 지켜야하는 것들은 안중에도 없고 좋은 것만 가지고 갈려고하는 인간들이 넘쳐나는데 문제가 있다. 이러한 기이한 현상에는 돈에 미친 정신병력 보다는 ‘남보다 우월적 지위’를 획득하거나 그것을 남에게 증명함으로써 과거 조선시대의 양반/상놈 계급화를 해야지만 자신의 존재감을 드러낼수 있다는 또 다른 정신병력 증상들…

그것을 앞세우는 이들이 바로 한국의 IT 개발자들이다.

IT 프리 개발자 등급 = 몇년 됐냐..

한국의 IT 프리 개발자들이 가지는 관심은 오직 하나다.

한국 IT 프리 개발자들의 병폐중에 하나가 바로 ‘등급’ 이다. 등급의 기준은 프리랜서로서 얼마만큼의 시간을 보냈냐하는 것이다. 이것을 IT 프리 개발자들은 ‘경력’ 이라고 떠들지만 경력이라는 건 그만큼의 능력이 뒷받침되어야 한다는 것을 전재로 함으로 IT 프리 개발자들이 말하는 등급과는 거리가 있다.

초급/중급/고급/특급… 이건 곧 IT 프리 개발자로서 몇년차 정도의 의미일 뿐이다. 문제는 이렇게 몇년정도 됐는에 따라서 돈의 지급량을 결정하는 산업은 그 어디에도 없다.

한국 사회는 경쟁사회다. 거기다 자본주의와 결합해 ‘능력 경쟁 사회’ 다. 능력이 좋으면 더 많은 부를 얻는 것이 당연한 공식이다. 한 분야에서 몇년 일을 하였다고 해서 그것 곧 능력을 보장하지 않는다. 이력서가 아무리 화려하다고 해도 회사에 입사하기 위해서는 면접을 봐야 한다. 기술적인 시험을 본다거나 아니면 대면 상담면접을 한다거나 뭐가 어떻게 되었든 간에 그 사람이 과연 그만한 경력을 가지고 있는지를 테스트 받는다.

하지만 한국의 IT 프리 프리랜서는 그걸 하지 않는다. 초급 500, 중급 700, 고급 900, 특급 1200. 10년이상했으니 고급 정도는 될듯하고 그러니 나는 900은 받아야 한다는 사고 방식. 그 어떤 산업분야에도 없는 이런 해괴하기 짝없는 돈 계산법…

프리 개발자 = 노동자??

그 어떤 산업에도 없는 해괴한 기준의 돈 계산 방법. 그러다보니 너도나도 뭐가 뭔지 모르는 사람들이 업계에 유입되고, 그렇게 몇년 있다보니 ‘나도 개발자’라고 하지만 정작 본질은 ‘코더’ 를 못 벗어나는 인간들이 허다 한 현실. 더 웃긴건 ‘코더’ 라고 부르면 득달같이 ‘어디 개발자에게 코더라고 하냐’ 하면서 눈에 불을 키는데, 정작 세상 돌아가는 건 몰라도 IT 기술 발전이 어떻게 되고 있는지, 더 좁게는 Java 가 어떻게 바뀌고 있는지 조차도 모르는채 ‘금융권 플젝 10년’ 만 외치면서 개발자다라고 우기는게 전부인데다 뭐가 됐던 ‘화면만 나오면 됐다’ 를 외치는 그들에게 ‘코더’ 라고 그 누구도 알려주지 않는 짬짜미까지…

이제 이들은 능력이고 뭐고는 둘째고 고급에 900을 외치면서, 이제는 법마져 내게 유리한대로 해석하고 그래서 불쌍하고 억울한 인간으로 둔갑하는데 주저함이 없는 저렬함마져 보여주기에 이른다.

프리랜서는 법적으로 ‘도급계약자’ 에 속한다. 더 넗게는 ‘용역계약’ 인데, 용역계약에는 노동계약과 도급계약으로 분류된다. 노동계약은 다 알고 있듯이 정규직이라고 보면 된다. 노동법에 적용를 받으며 4대보험을 납부해야한다. 대부분 연봉계약자, 직장인들이 여기에 속한다. 하지만 도급계약은 노동계약과는 달리 ‘민사합의계약’으로 분류된다. 프리랜서는 기본적으로 도급계약에 속한다. 따라서 노동자가 될 수가 없다.

노동자와 도급계약자, 즉 프리랜서와 가장 큰 차이는 세법에 있다. 세금관련해서 다르다. 노동자는 4대보험이 의무가입이다. 사용자가 절반을 내고 노동자가 절반을 내는 형식으로해서 세금을 낸다. 연봉계약에는 4대보험까지 포함되어 있기 때문에 월급명세서에는 4대보험 공제가 되어 실수령액이 결정된다. 하지만 프리랜서는 도급계약자, 세법상으로는 ‘개인사업자’ 속한다. 계약금액의 3.3%만 공제하고 지급 받는다. 별도의 세금을 내는 건 없다. (정확하게 몇년전에 법이 바뀌어서 고용보험, 산재보험을 납부해야하나 안할 수도 있다.)

프리랜서는 도급계약자이다. 세법 외에도 한가지 더 있다. 도급계약은 민사합의 계약이기 때문에 프리랜서가 만들어낸 결과물에 대해서 책임을져야 한다. 이것은 마치 인터넷을 통해서 물건을 구매했는데, 하자가 있어서 환불이 되어야 하는 것과 같다. 결과물이 문제가 있다고 한다면 이에 대한 책임, 민사적으로는 배상책임이 존재한다.

노동자가 받는 돈을 월급이라고 하지만 프리랜서는 ‘단가’ 라고 한다.

또 있다. 노동자는 종속관계 계약이라고 한다. 상급자의 지시에 따라야 한다. 하지만 프리랜서는 그런게 없다. 오히려 상급자가 지시를 하면 안된다. 이것을 한마디로 정의하면 ‘노무를 제공하지 아니 한다’ 로 규정된다. 프리랜서는 노무를 제공하지 않는다. 따라서 출퇴근, 근무장소등을 지정할 수가 없게 된다.

그런데….

돈은 단가로 받고 권리는 노동자… 배상책임도 안지고 9시~6시 칼퇴근 보장..

여기에 ‘거머리 같은’ 인간들의 이면이 나온다. 단지 몇년 일했다고 해서 800, 900 따지면서도 그 결과물에 대해서는 절대로 책임은 안지겠다, 더나가 근무시간을 설정해서 그 시간외에는 절대로 일을 안하겠다. 프리랜서들에게 근무시간이라는 개념도 없지만 그들이 말하는 것은 ‘나는 노동자다’ 라는 거다.

IT 프리 개발자들이다. 더군다나 오래된 프리 개발자들 일수록 이런 인식이 강하다. 얼마간 잇었으니까 단가는 이정도로 받아야하고 자신이 짠 프로그램 개발 소스에 대한 책임은 없고 대충 시간 때우다 퇴근하고…대부분의 SI 프로젝트가 이런 인간들로 다 채워져 있다고 생각하면 맞다. 적어도 대한민국에서는…

얼마나 거머리 같은 인간들인가… 대한민국이 세계에서 사기 범죄가 많다고 하는데, 사기 범죄의 기본이 일은 안하고 남을 등쳐먹는 것인데, 여기에는 내가 일은 안하고 돈은 내가 가지고 간다는 개념이 존재한다. IT 프리 개발자들도 이와 다르지 않다.

자… 잘 생각해보라… 경쟁을 하지 않아도 된다. java 문법을 약간 공부하고 스프링 프레임을 조금 할줄 알면 된다. DTO 구조를 죽어도 못 벗어나는 틀을 가지고 있으니 Controller, Service, Repository 등 나누고 데이터베이스에 쿼리하고 보여주면 된다. 그걸 대충 한 1 ~ 2년 정도면 뭐가 뭔지 대충 알게되고 그때부터는 대충 화면에 나오게만 짜면 그만이다.

코드의 성숙이나 하다못해 유닛 테스트 코드는 작성해서 프로덕트의 품질을 보증하는 일따위는 없어도 된다.

대충 일하면서 돈은 많이 받고 싶은가? 그러면 IT 프리 개발자가 되어라… 사회에 거머리로서 신나게 한 평생을 살 수 있다.

wp-cli 를 이용한 core, plugin 업데이트 하기

워드프레스(WordPress) 를 사용하고 있는데, 갑자기 화면을 통한 플러그인(Plugin), 코어(Core) 업데이트가 되지 않았다. 보통은 문제 없이 이것이 수행되었는데, 뭔가 문제가 있는건지 파악해봤지만 찾지지는 못했고 그냥 포기해야 하나 하는 찰라에 wp-cli 를 이용하면 업데이트를 모두 할 수 있다는 사실을 알게 됐다.

wp-cli.phar

워드프레스에서 정식으로 배포하는 것 같지는 않다. github 에서 배포 받을 수 있는데, 간단하게 wp-cli.phar 파일을 다운로드 받으면 된다.

사용법

다운받은 wp-cli.phar 를 /usr/local/bin 으로 복사하고 워드프레스 설치한 계정으로 전환해서 사용하면 된다고 하지만 개인적으로 그냥 워드프레스가 설치된 계정에서 실행해도 된다.

위와같이 abcd 계정에 wordpress 디렉토리에서 실행한 결과다.

코어 업데이트

코어(Core) 업데이트를 할 수 있다.

플러그인(Plugin) 업데이트

플러그인 업데이트를 다음과 같이 할 수다.

위 예제에서는 모든 플러그리인을 업데이트했다.

MySQL 모니터링을 위한 계정 권한

MySQL 에서는 각종 지표등을 제공하는데, 이러한 지표를 얻기 위해서는 MySQL 계정이 있어야 한다. 대부분 MySQL 계정을 생성하고 권한을 주는데, 습관처럼 “ALL PRIVLEGES” 를 주는 경우가 많다. 하지만 모든 시스템에서 계정은 최소한의 필요한 권한만 주도록 하는 것이 보안의 시작이다.

이 문서는 MySQL 모니터링을 위한 계정 권한에 대해 다룬다.

계정생성

MySQL 8.0 기준으로 계정 생성은 다음과 같다.

이렇게 생성을 하고 난 후에 이제 GRANT 명령어를 이용해서 권한을 줘야 한다.

모니링을 위한 권한 부여

‘ALL PRIVILEGES’ 로 모든 권한을 줘는 안되며 모니터링을 위한 권한만 주면 된다.

telegraf 사용자의 경우에 최대 접속자 수를 5로 제한했다. 프로세스와 리플리케이션 상태를 보기 위해 PROCESS, REPLICATION CLIENT 권한을 부여 했다.

performance_schema 데이터베이스에 대한 SELECT 권한을 부여 한다. 성능관련 지표들을 performance 스키마에 기록하는데, 이에 대한 접근권한을 부여 한 것이다.

결론

무수히 많은 메트릭들을 제공하는 MySQL 이라 어떤 것을 수집할지에 따라서 부여해야할 권한도 달라지지만, 대략적으로 이 정도면 MySQL 을 모니터링하는데 무리는 없다.

출처: The MySQL Input Plugin for Telegraf gathers data from a MySQL server.

Mint Linux 21.1 설정

오랫동안 민트 리눅스(Mint Linux) 를 데스크탑 운영체제로 사용해왔다. 정확하게는 데스크탑 PC 를 새로 맞춤과 동시에 설치해서 써왔는데, 이번에 데스크탑 PC 를 교체하게 되면서 민트 리눅스를 재설치해야하는 상황이 되어 그 동안 써왔던 민트 리눅스 설정을 기록으로 남긴다.

XFCE 데스크탑

민트 리눅스 데스크탑은 세가지가 존재하는데, 그중에서 XFCE 데스크탑을 사용했다. 이 XFCE 를 만진지도 거의 20년이 넘었다. 솔라리스의 CDE 를 닮아서 쓰기 시작해서 지금까지 쓰고 있다. XFCE 는 가벼우면서도 복잡하지 않는 데스크탑이다. 그러다보니 별로 설정할게 존재하지 않는다. 데스크탑이라는 것이 어짜피 설치하고 나면 쓰는 것만 쓰게 되어 있어서 뭔가 많은 것을 만져야하고 존재하는 것 부터가 거추장스러운 것이다. 단순하면서도 필요한 것만 있는 XFCE 를 그래서 20년 넘게 사용했다.

설치 후 화면

설치 후에 처음 화면은 다음과 같다.

그냥 윈도우처럼 보인다. 이 겉모양은 XFCE 의 본래 모습이 아니다.

XFCE 는 솔라리스의 CDE 를 모티브로 만들어졌다. 그래서 초창기때부터 솔라리스 CDE 의 겉모양을 본떠서 데스크탑을 꾸미기 시작했다. 이 글을 쓰는 목적도 대충이나마 솔라리스CDE 겉모양을 꾸미는 과정을 기록으로 남기기 위서다.

패널 기본 설정

화면 아래 길게 늘어진 바가 패널(Pannel) 이다. 이 패널을 약간 손질해서 기본적인 CDE 모양으로 만들어보자. 패널에 마우스 오른쪽 버튼을 클릭하고 ‘패널 -> 패널 기본 설정’ 으로 들어간다.

패널 기본 설정

첫번째로 해야하는 것은 패널을 추가는 것이다. 설정 창에 맨 위 ‘패널1’ 글자 옆에 + 버튼을 클릭하면 ‘패널2’ 라고 바뀌고 화면 어딘가에 패널 바가 생성된다. 한 화면에 패널을 두개 사용할 것인데, 하나는 화면 위에 올려두고 시작메뉴와 태스크바로 사용하 다른 하나는 솔라리스CDE 처럼 일종의 런처로 사용할 것이다.

‘패널1’ 을 설정창에서 선택하고 ‘표시탭->일반’ 에서 ‘패널 고정’ 체크를 해제해 준다. 그러면 패널 양쪽에 마우스를 올리고 잡을 수 있는 상태가 표시된다. 마우스로 잡은 다음에 화면 위쪽으로 옮겨준다. 다 옮겨 줬으면 ‘패널 고정’ 체크를 해 패널1을 고정 시켜준다.

‘패널 기본 설정’ 창에서 ‘패널2’를 선택하면 화면 어딘가에 패널이 보인다. 이 패널2도 ‘표시탭->일반’ 에서 ‘패널 고정’ 체크를 해제해준다. ‘패널1’ 과는 달리 아무것도 없다보니 패널 가로길이가 작다. 솔라리스CDE 의 런쳐처럼 사용할 것이기에 화면 중앙에 놓는다. 그리고 ‘표시탭->일반’ 에서 길이(%) 를 44 로 조정하고 열 높이(S) 를 59 로 변경한다.

패널2 설정

대충 런쳐로 쓰일 패널이 만들어졌다. 이 패널2에 쓸만한 항목들을 추가해준다.

패널2 항목 추가

대략 왼쪽부터 ‘프로그램 메뉴’, ‘위치’, ‘파이어폭스’,’Xfce터미널’,’작업공간전환기’,’눈동자’,’스크린샷’,’로그아웃’,’휴지통’,’날짜와시간’ 이다.

여기서 중요한 것은 ‘파이어폭’,’Xfce터미널’,’로그아웃’ 은 항목추가에서 ‘실행기’ 추가를 하고 난 다음 ‘실행기’ 설정에서 애플리케이션을 선택해준 것이다. 모든 것이 패널 항목으로만 넣을 수는 없다. 패널 항목 수보다 패널이 길이가 길다면 ‘패널 기본 설정’에서 패널의 가로 길이를 조정해 주면 된다.

모양새

모양새는 ‘설정->모양새’ 에서 찾을 수 있는데, 데스크탑에 기본 페인팅을 바꿀 수 있게 해준다. 과거 솔라리스CDE 와 비슷한 느낌의 페인팅은 회색 바탕에 핑크 창틀이였다. 인터넷에서 XFCE 에 CDE 테마를 검색해서 찾아본 결과 Soaris-9-2.0 이 잘 동작했다.

모양새 많은 페인팅들은 테마(Theme) 라고 하는데, /usr/share/themes 디렉토리에 테마 이름의 디렉토리로 존재한다. 첨부된 파일을 다운받아 압축해제하면 사용할 수 있다.

Solaris-9.2.0 모양새 적용

과거 솔라리스CDE 의 모양새 그대로다. 만일 이 모양새가 맘에 들지 않는다면, 그것이 리눅스와 좀 다른 맛(?) 을 느끼 싶다면 적어도 과거 솔라리스CDE 의 전체 테마와 잘 어울릴만한 것을 찾는다면 기본으로 제공되는 모양새중에 ‘Mint-Y-Legacy-Dark-Pink’ 를 추천해 본다.

Mint-Y-Legacy-Dark-Pink 모양새 테마

기본으로 제공해 주는 모양새 테마가 많기 때문에 원하는 취향에 맞춰 선택해주면 된다.

창 관리자

창 관리자는 창 틀의 모양과 최소,최대,없애기 버튼의 위치등을 변경할 수 있도록 해준다. 창 관리자 역시 테마 리스트들이 있고 원하는 창 모양의 테마를 선택하면 적용 된다. 인터넷을 통해 cdetheme-solaris 를 얻게 되었고 이를 통해서 과거 솔라리스CDE 창틀 모양을 얻을 수 있었다.

솔라리스CDE 테마

cdetheme-solaris 를 맨 처음 적용하면 최소,최대,없애기 버튼의 배치가 위와같지 않다. 그럴땐, 창 관리자에 ‘단추 배치’ 부분에 나온대로 단추를 배치 시켜주면 된다. 필요없는 단추는 숨김으로 옮겨놓으면 된다.

아이콘 테마

아이콘 역시 바꿀 수 있다. 이 아이콘 테마들은 모양새에 있다. 모양새에서 ‘아이콘’ 탭을 클릭하면 다양한 아이콘 테마들을 선택할 수 있다. 물론 인터넷을 통해서 다운로드 받을 수 있다.

자주 사용하는 테마는 GNUStep, McMuse-pink-dark 다.

아이콘 테마

마무리

XFCE 는 경량 데스크탑으로 불리운다. GTK 기반으로 제작되었기 때문에 GTK 테마라면 호환이되어 사용할 수 있다. 하지만 xfce-looks 에서도 구할 수 있다. 벌써 20년이나 지났지만 CDE 테마를 고집하는건 그 특유의 레트릭한 모양의 데스크탑 그래픽을 잊을 수 없었기 때문이다.

xfce-looks.org

AWS Athena 를 위한 S3 버킷 정책

AWS ELB 와같은 로그를 AWS S3 에 버킷 저장하는데, 이것을 Athena 에서 읽어서 분석을 하게 된다. 보통 이를 위해서 AWS S3 이 정책을 지정하지 않는 경우가 많은데, 보안상 좋지 않다. 다음과 같이 정책을 지정해주면 된다.

AWS Athena 는 AWS Glue 를 이용함으로 이와함께 정책을 지정해줘야 한다.