DNF 사용하기

CentOS 8 로 넘어오면서 기본 패키지 매니지먼트로 dnf 가 되었다. 여전히 yum 을 지원하지만 앞으로는 dnf 로 쭉 간다고 하니 이참에 배워보자고 생각하지만….

겁나 빡치는게, 이제 그만 바꿨으면 한다. 뭔 yum 정도로도 충분히 잘 쓰고 있고 괜찮다고 싶다. 무슨 겁나 가볍네, 더 빠르네 어케 좋네… 응 yum 도 그렇게 느리고 그렇게 무겁지도 않아! 도대체 뭘 할때마다 갈아 엎고 이걸 새로 배우라고 하니.. 뭐 어쩌것나.. 그렇게 하겠다는데, 닥치고 배워야지!

dnf

햐.. 쓰기도 귀찮다… “DNF is the next upcoming major version of YUM, a package manager for RPM-based Linux distributions” 이렇게 맨 페이지에 설명이 나온다.

사용법

사용법은 아주 간단하다. yum 의 기본 사용법은 대동소이하다고 하겠다.

이정도만 알아도 패키지를 다루는데는 문제가 없을 것이다.

Ubuntu, systemd-networkd 전환하기

Ubuntu 16.04 로 넘어오면서 SysV 의 Init 이 Systemd 로 변경되었다. 이런 변화에는 Network 관리에도 적용되고 있는데, 이에 대해서 알아보자.

기존의 Network 관련된, 정확하게는 Network Interface 와 관련된 일은 NetworkManager 가 담당했다. Network Interface 가 무엇인지, 아이피는 DHCP 혹은 Static 인지 등이 그것이다.

하지만 Ubuntu 16.04 로 넘어오면서 시스템에 관련된 일체가 systemd 로 통합되면서 네트워크 관련 작업도 systemd 로 통합되어지게 되는데, 이것이 systemd-networkd 이 이다.

하지만 Ubuntu 18.04 로 넘어온 시점에서도 NetworkManger 는 이전과 호환을 위해서 살려뒀고 살려둔김에 지금도 기본적인 네트워크 설정 프로그램으로 활약(?) 하고 있다.

Network Manager

Network Manager 의 동작은 다음의 명령어로 이루어진다.

관련 설정은 /etc/NetworkManger/NetworkManger.conf 파일이다. 위 프로그램을 실행하게 되면 기본적으로 이 파일을 읽게 되어 있다.

그리고 netplan 설정에서도 NetworkManager 를 기본으로 지정하도록 되어 있다.

Network Manager 비활성화

비활성화는 다음과 같이 하면 된다.

이렇게 하면 네트워크가 비활성화 됨으로 절대로 원격지 서버에서 하면 안된다.

systemd-networkd 활성화

netplan

systemd-networkd 를 활성화하면 이제 네트워크 작업은 netplan 명령어를 통해서 이루어진다. 이 netplan 명령어는 기본적으로 ‘/etc/netplan’ 디렉토리에 파일을 읽어서 네트워크 설정을 적용해 준다.

‘/etc/netplan’ 디렉토리에 설정파일은 기본적으로 yaml 파일형식을 가진다. 예를 들면 다음과 같다.

파일을 수정한 후에는 다음과 같이 명령어만 주면 적용이 된다.

‘–debug’ 는 제외해도 된다.

기업이 프리랜서를 정규직으로 뽑지 않는 이유

나이가 먹어가면서 이런 저런 사회현상에 대한 답을 얻어가는 것 같다. 과거 어렸을적(?) 에는 그것이 왜 그렇게 되는지에 대한 의문만 가득했지만 시간이 약이라고 했던가…

한국 사회에서 나이가 가지는 특별함으로 인해서 나도 모르게 이제는 아랫사람이 생기고 과거에 윗사람에게 존댓말을 했던 내가 이제는 존댓말을 받을 위치에서 사회를 바라보게 됨에 따라서 과거에 못보던 것이 이제는 보이는 신기한 현상을 자주 겪는다.

개인적인 경력을 이야기를 하면 정규직 생활을 약 7년 정도하고 프리랜서로 전향한지 이제 약 5년쯤 됐다. 중간에 약 1년 쯤 놀았으니까 프리랜서를 개월수로 환산하면 만 4년 조금 될까…

지금도 그렇지만 과거에 이런 의문을 가진적이 있다.

다 똑같은 IT 기술을 가지고 일을 하는 사람들인데, 어째서 좀 나간다하는 기업에서는 프리랜서들을 정규직으로 고용하려고 하지 않는가?

과거에 가졌던 의문인데, 요새 그것이 정말로 맞는 말이라는 것을 절감한다.

새로운 프로젝트에 투입되고 새로운 인력을 뽑아 프로젝트를 지휘해야하는 입장에 있다. 문제는 SI 프리랜서에게 지급되는 월별 단가라는 것이 프리랜서 경력만 가지고 결정된다.

아무리 능력이 좋다고 한들 5년차라면 돈을 많이 못 받는다. 아무리 능력이 없다고해도 경력이 15년차면 특급대우를 해준다. 이력서에 많은 프로젝트를 뛰었다는 것이 그 사람의 IT 능력을 증명한다는 것이 웃기는 일인과 동시에 의문인데 이러한 의문 때문에 과거에 저런 질문이 절로 떠올라고 과연 맞는 말이라는 것을 절감한다는 것이다.

나랑 같이 투입된 15년차 프리랜서가 있다. 나이도 많아서 부장이라고 달았는데, 그야말로 기계적인 일만 한 경우였다. 그리고 그렇게 기계적인 일만으로 단가를 높게 받다보니 그것을 벗어나는 일은 절대로 하려고 하지 않는다.

더 웃긴건 한국 사회도 변화하고 있고 IT 세계도 그 변화에 흐름은 빗겨가지 못하고 있는데도 과거에 했던 버릇을 버리지 못하고 있다는데 있다.

한국 사회에서 저작권에 대한 생각이 많이 바뀌어 있고 그래서 요새 젊다하는 프리랜서들은 나름대로 소프트웨어 저작권에 대한 인식이 잘 갖춰져 있다. OS, MS Office 등은 업무에 필요한 필수 소프트웨어도 과거에 비해서 나름 저렴해진 것도 한 몫이다.

하지만 나랑 같이 투입된 15년차 프리랜서… MS Office 는 2007년 버전이고 그것도 크랙 버전이다. 사업장 마다 다르지만 소프트웨어 라이센스에 민감곳이 점점 많아지고 있는 시점이고 내가 있는 사업장도 불법 소프트웨어에 대해서 그렇게 좋게 보지 않는다. 한번 걸리면 사업장이라고 책임을 면할 수 있는 상황도 아니기 때문이지..

그래서 크랙 버전은 사용하면 안되고 문제가 될 거 같으니 돈 주고 사라고 권했다. MS Office 365 의 경우에 비지니스 버전 1년 구독으로 12만원이면 사용할 수 있다. 프리랜서 15년차면 단가가 적어도 700 은 넘을테니 1년 12만원 그냥 껍 아니겠나..

하지만 이 양반.. 그 돈이 아깝다는 거다. 계약을 체결한 회사가 제공해주지 않느냐는 질문부터 해서 어떻게든 싸게 구매할려는지 이커스 마켓에서 출처도 불문명한 3만원짜리 라이센스 구매가 어떠냐고 내게 물어보기까지…

더 웃긴건, 이 프로젝트에 투입된 그 인력은 인프라를 담당하는 사람이다. OS, Application 서버등을 운영, 모니터링, 장애대응이 주 임무다. IT 그것도 인프라 운영에 발을 들여논 순간부터 24시간 장애대응은 염두해 둬야하는 직업이다. 하지만 이 양반 집에 컴퓨터가 없다.

장애가 발생하면 집에서 회사까지 출근해서 할 사람으로 보이지도 않는데도 “어? 집에 컴터 없어요” 를 아주 대놓고 당당하게 하는 사람…

사업장에서는 그래도 야밤에 출근하는 불상사를 없애기 위해서 원격 접속 프로그램을 지원해 주고 있다. 실시간 대응이 필요한 서비스의 경우 이렇게 해주는 곳이 많은데 “어? 집에 컴터 없는데요~” 를 당당하게 말할 수 있는 배짱, 아니 객끼를 들어내는 사람..

나 같아도 정규직으로 안 뽑는다.

이 글을 읽는 사람이라면 프리랜서 전체를 매도하는게 아니냐고 하겠지만 안타갑게도 저렇지 않는 프리랜서 본적이 없다. 계약서를 따지고 단가를 계산하고 사업장에서는 정규직과 동일한 복지를 요구하면서도 진정으로 개인사업자에 준하는 대우와 그에 맞는 결과를 요구하면 그것이 매우 부당하다고 주장하는 이들… 출퇴근은 칼같이 지켜내야만 한다고 주장하는 사람… (원래 프리랜서는 출퇴근 개념이 없다.)

한국 사회에서 공무원들을 영혼없는 사람처럼 대하는데, 한국 프리랜서들도 별반다르지가 않더라는 거다. case by case 대로 Tip 을 많이 알고 있는 것이 한국 IT 인력들의 능력 수준일 뿐이다. 그것을 조금만 벗어나면 뭘 어쩌지 못하는 무능을 금방 들어내고야 많은 선배님들… 제발 빨리 은퇴하시고 치킨집 차리시길 권한다.

Ubuntu 18.04, Static IP 할당하기

Ubuntu 18.04 의 경우 네트워크 인터페이스 관련 작업은 netplan 으로 바뀌었다. 만일 Static IP 를 할당하고 싶다면 netplan 의 설정 파일을 수정하고 적용하면 된다.

/etc/netplan/*.yml

여기서 파일을 수정하면 된다. 대략 다음과 같은 포맷을 갖는다.

dhcp4: yes 로 되어 있는 경우에는 DHCP 로 아이피를 받아온다. 하지만 이것을 no 바꾸면 Static IP 를 할당할 수 있다.

netplan 적용

수정을 다 했다면 다음과 같이 적용해 준다.

Ubuntu 18.04 ethernet 이름 변경하기

Ubuntu 18.04 를 설치하면 ethernet 인터페이스 이름이 과거 eth0 가 아닌 ens3 과 같이 나온다. 하지만 아직도 많은 프로그램들이 기본적으로 eth0 를 기본으로 찾기도 한다. eth0 변경하는 방법에 대해 다룬다.

GRUB 파라메터 수정

다음과 같이 Grub 에 파라메터를 추가 한다. Grub 에 파라메터는 /etc/default/grub 파일에서 다음과 같이 추가할 수 있다.

수정된 사항이 Grub 에 반영하기 위해서 업데이트를 수행한다.

여기서 중요한 것이 바로 재부팅을 하면 안된다. 특히나 DHCP 환경에서는 다음의 단계를 수행한 후에 재부팅을 해야 한다.

netplan 수정

netplan 은 Ubuntu 17.04 에서 소개된 기능으로 네트워크 인터페이스 관련 작업을 해준다. 이 프로그램은 /etc/netplan/*.yml 파일을 참조하는데, Ubuntu 18.04 의 경우에 /etc/netplan/01-netcfg.yaml 파일을 참조 한다.

eth0 부분이 수정한 것이다. 이렇게 수정을 다 했으면 다음과 같이 명령어를 수행해 준다.

이렇게 한 후에 재부팅을 하면 DHCP 환경에서 문제 없이 eth0 인터페이스 이름으로 네트워크가 정상 동작한다.

Trac 에서 Ticket 삭제하기

Trac 을 사용하다보면 Ticket 을 삭제하고 싶을때가 있다. Ticket 삭제 플러그인이 존재하지만 Ticket 이란게 자주 삭제를 하는 것이 아니여서 굳이 이것을 설치해서 사용해야할 만큼은 아닌듯 한데, 그런데도 잘못된 Ticket 을 삭제해야한다면 다음과 같이 하면 된다.

trac-admin 을 활용하면 된다.

출처: Deleting trac tickets created since a certain date until today

두번째 방법으로 ‘ticket.deleter’ 를 활성화하면 된다. 이는 Trac 에서 공식지원하는 것으로 Ticket 웹화면에서 Reply 버튼 옆에 Delete 버튼이 나타난다. 이를 위해서는 trac.ini 설정파일에 다음과 같이 설정해준다.

Ansible, ec2.py 를 이용한 Dynamic Inventory 활용

Ansible 에는 접속 정보와 관련된 정보들을 Inventory 라고 부른다. 접속 호스트, 접속 계정 정보뿐만 아니라 이들을 그룹으로 묶거나 변수 설정도 가능하다.

그런데, 클라우드 시스템과 같이 서버 관련 정보를 API 형식으로 제공할 경우에 일일이 호스트 정보를 파일로 저장할 필요가 없다. 클라우드 시스템에 서버 관련 정보를 호출하며 자동으로 Inventory 정보가 생성되는 기능을 제공하는데 이를 Dynamic Inventory 라고 한다. 이 기능은 클라우드 뿐만 아니라 LDAP 과 같은 인증 시스템에도 활용가능하다.

Ansible 세팅

AWS 클라우드의 Dynamic Inventory를 활용하기 위한 Ansible 을 세팅해 보자. 가장 중요한 ansible.cfg 는 다음과 같다.

특별히 inventory 에는 AWS 클라우드에 제공하는 Dynamic Inventory 스크립트 위치를 지정해준다. ansible 을 이용한 접속 정보, 실행할 계정에 대한 정보등을 기재한다.

디렉토리는 구조는 대략 다음과 같다.

AWS 클라우드 Dynamic Inventory 파일

AWS 클라우드의 경우에도 Ansible 의 Dinamic Inventory 기능을 제공한다. 작동원리는 AWS 자원 정보를 불러오고 이것을 Ansible 이 인식하는 Inventory 정보를 구성하는 것이다. AWS 자원 정보를 불러오기 위해서 AWS 는 다음과 같은 스크립트와 환경설정 정보를 제공한다.

ec2.py 는 AWS 클라우드 시스템에 호스트 관련 정보를 불러오도록 한다. ec2.ini 는 어디, 어떤 정보를 불러올 건지 어떤 내용을 출력할 것인지를 지정할 수가 있다. 예를들면 다음과 같다.

regions 이 기본값은 all 이다. 이러면 모든 리전에 대해서 호스트 정보를 수집할려고 하기 때문에 시간이 오래걸리는 문제가 발생한다. 특정한 리전에 대해서만 수행하도록 지정하는 것이 좋다.

IAM 설정

가장 중요한것이 IAM 설정이다. Ansible 을 실행하는 서버에는 호스트 정보를 불러올수 있는 IAM 권한이 필요하다. 보통 IAM Role 지정이라고 하는데 대략 다음과 같은 Policy 를 만들어 Role 적용을 하면 된다.

Access Key, Secret key 를 이용하는 방법도 있지만 권장하지 않는다.

ec2.py 테스트 및 특징

이제 요건이 갖춰졌으니 테스트를 해보자.

내용을 보면 위와같은 key 값들을 보게 된다. 집작했겠지만 ec2.py 는 ec2 인스턴스의 tag 를 key 로 지정해준다. tag 뿐만 아니라 ec2 인스턴스의 정보를 key 만들어준다.

이 key들은 Ansible Inventory 의 group 변수로 활용이 가능하다.

ec2 key pair 를 이용한 접속 정보 만들기

ec2.py 에서 key 들은 곧바로 Ansible 의 group 으로 활용 가능하다. 이를 위해서 inventory/production/group_vars 디렉토리에 key 이름으로 yaml 파일을 생성한다. 그리고 다음과 같이 내용을 입력한다.

Ansible이 그룹 접속을 할때에 위 변수를 활용하게 된다. AWS 클라우드 ec2 접속하기 위한 keypair 를 이용하는데 따른 설정이다.

접속 테스트

이제 다 됐다. 다음과 같이 접속 테스트를 한번 해본다.

위와같이 나오면 성공한 것이다.

Grub2 에 기본 커널 지정하기

Grub2 은 리눅스 시스템의 부팅 메니져이다. 리눅스는 커널을 여러개를 설치하고 부팅시에 선택해서 원하는 커널로 부팅을 할 수 있도록 해준다. 비상 복구가 필요할 경우에도 부팅 메니져인 Grub2 에서 비상복구 모드를 선택하면 된다.

문제는 어떻게 기본 커널을 지정할 수 있을까?

먼저, 기본 부팅 커널은 다음과 같이 확인할 수 있다.

만일 부팅 상황이라면 위에 설정한 커널을 기본으로 부팅을 진행하게 된다. 만일 이 기본 커널을 변경하고자 할 경우에는 어떻게 할까?

우선, 현재 Grub2 에 등록된 커널 목록들을 알아야하는데 다음과 같이 하면 알 수 있다.

커널 목록을 확인할 수 있는데, 맨 위쪽부터 0 을 시작으로 번호를 붙일 수 있다. 이러한 번호는 기본 부팅 커널을 바꾸는데 유용하게 사용된다. 이제 기본 부팅 커널을 다음과 같이 바꿀 수 있다.

확인을 한번 해보면 다음과 같다.

이렇게 한 후에 다시 Grub 을 설치해줘야 한다.

정상적으로 되었다면 기본 부팅 커널이 바꾼 것이다.

AMAZON S3 버킷 램덤화 객체 접두사 불 필요.

과거에 AMAZON S3 버킷 성능 끌어올리기 라는 글을 통해서 S3를 사용하는데 있어서 성능향상 방법에 대해서 설명한 적이 있다. 핵심은 객체 접두사를 램덤화해서 S3에 올라가는 파일들이 균일하게 넓게 퍼질 수 있도록 해야한다는 것이였다.

하지만 2018년 7월 17일에 AWS 에서는 S3에 성능향상을 언급하면서 이제 객체 접두사의 랜덤화는 불필요하다고 말했다.

Amazon S3, 요청 처리 성능 개선 발표

이 같은 S3 요청 처리 성능 향상으로 인해 객체 접두사를 랜덤화하여 더 빠른 성능을 실현하라는 이전의 지침은 더 이상 적용되지 않습니다. 즉, 이제 성능 저하 없이 S3 객체에 논리적 또는 순차적 명명 패턴을 사용할 수 있습니다. 이 성능 향상은 이제 모든 AWS 리전에서 제공됩니다. 자세한 내용은 Amazon S3 개발자 가이드를 참조하십시오.

이제 S3 버킷에서 객체를 저장할때 접두사를 램덤화하려는 고민을 하지 않아도 된다.

Tomat 8.5 Manager 패스워드 암호화 하기

Tomcat 8 로 넘어오면서 manager 페이지 접근을 위한 패스워드 암호화 방법에 조금 변화가 있었다. 이에 대해서 기술한다.

Manager 페이지 접근 권한 – context.xml

기본값으로 /manager 페이지에 대한 접근은 localhost 로 제한이 걸려 있다. 이것은 manager 앱에 대한 context.xml 파일에 설정되어 있는 내용인데, 파일 경로는 $CATALINA_HOME/webpps/manager/META-INF/context.xml 이다. 다음과 같이 접근 제한된 부분에서 외부접속을 위한 설정을 해준다.

Valve 를 이용해서 RemoteAddrValve 에 대해서 접근 아이피 주소가 적혀 있다. 여기서는 접근 제한을 해제해주고 있다. 하지만 product 환경에서는 절대로 이렇게 하지말고 접근 가능한 IP 주소를 입력해주도록 하자.

암호화 알고리즘 정의 – server.xml

암호화 알고리즘에는 md5, sha-256, sha-512 등을 지정할 수 있다. 이를 위해서 server.xml 을 수정해 줘야 한다.

CredentialHandler 를 통해서 algorithm을 SHA-256 으로 정의해주고 있다. 중요한 것은 어디다가 해주냐하는 것임으로 위에 예제를 유심히 보고 정확한 위치에 이를 추가해줘야 한다.

암호화된 스트링 얻기 – digest.sh

이제 암호화된 스트링을 얻어야 한다. 이는 $CATALINA_HOME/bin/digest.sh 스크립트를 이용해서 손쉽게 얻을 수 있다. 주의할 것은 암호화 알고리즘에 맞는 암호화된 스트링을 얻기위해서 알고리즘을 옵션으로 알려줘야 한다.

결과에서 콜론(:)을 기준으로 앞은 평문 문자열, 뒤는 암호화된 문자열을 보여준다.

manager 인증 설정 – tomcat-users.xml

이제 manager 인증을 위한 설정을 해준다. 이는 tomcat-users.xml 해주는데, 다음과 같이 해준다.

위와 같이 암호화된 스트링을 password 인자로 주면 된다.

이렇게 Tomcat 8.5 에 대한 /manager 인증 암호 문자열 암호화 하기에 대해 알아 봤다.