안양 PORCH ucim-minion App 배포 문제 기술지원
안양 NW인증팀에서 ares-k33이라는 서버에 CentOS 7 자동 설치하고 ucim-minion App을 배포하는데 실패했다고 한다.
로그 파일을 보니 docker 설치에서 에러가 났다.
/path/to/logfile:
TASK [ucim-minion : Install docker container engine package] *******************
failed: [106.241.8.33] (item=['docker', 'python-pip']) =>
{"changed": false, "failed": true, "item": ["docker", "python-pip"],
"msg": "\n\n One of the configured repositories failed (Unknown),\n
and yum doesn't have enough cached data to continue.
At this point the only\n safe thing yum can do is fail. There are a few
ways to work \"fix\" this:\n\n
yum이 패키지를 가져오지 못하고 있다.
왜?
Bacula 설치부터 운영까지
개요
Bacula 는 C++ 프로그래밍 언어로 개발되고 GNU(General Public License) 버전 2.0 오픈 소스 네트워크 기반 백업 프로그램이다. ᅟBacula 라는 이름은 Backup 과 Dracula 에 혼합어이다. 드라큘라처럼 데이터를 흡혈하듯 백업한다는 재미난 이름이다.
Bacula 의 특징으로는 다음과 같다.
- 쉬운 설치 및 설정
- 다양한 백업 장치 지원 (하드디스크, ᅟLTO 1-5 테이프 장치 등등)
- 다양한 모니터링툴 지원
- 증분, 차등, 차등 증분, 변경분, 가상 백업, 백업 주기, 압축 프로토콜 등 다양한 백업 방식 지원
- 백업 전후 실시할 명령어 지정이 가능
- 네트워크로 백업되는 데이터의 암호화를 위한 다양한 옵션 (MD5, SHA, TLS, CRAM-MD5 등등) 지원
- 데이터 압축 전송
- 네트워크 bandwidth 제한 가능
KUBIC 안양 BIND 성능 문제 해결
뭐라 시작해야 할 지 모르겠다.
지난 3월부터 계속된 안양 고객 KUBIC 구축이 드디어 상용 서비스에 들어가기 직전이다.
3개월이 넘는 긴 여정을 이제야 마무리하게 되었다.
PORCH CentOS 6 지원
PORCH 현 구축 사이트에는 HP 구형 장비가 많이 있다. 이 장비들을 활용하려다 보니 최신 OS와는 호환이 되지 않는다.
HP Proliant DL380 G4/G5/G6와 같은 장비는 CentOS 7과 호환이 잘 되지 않아 CentOS 6를 설치하기로 했다.
PORCH는 CentOS 7, Debian Jessie만 현재 지원한다. CentOS 6도 지원하자.
PORCH WAN 구간지원 2
문제점
지난 1차 문서에서 WAN구간 서버 OS 자동 설치 세팅을 하였으나 서버가 준비되지 않아 시험하지 못했다. 오늘 시험을 해 보았으나 다음과 같은 문제가 발생하였다.
dracut Warning: Could not boot.
dracut Warning: /dev/root does not exist
DHCP서버로부터 IP는 잘 받아오고, kernel/initrd 이미지도 http로 잘 받아 부팅하는 중 위 에러가 나오고 서버는 멈춘다.
kube-router에 대한 생각
아래 kube-router URL입니다.
https://github.com/cloudnativelabs/kube-router
결론부터 말하자면, kube-router를 통한 성능 향상의 가능성은 높아 보입니다. 물론 실험을 해야 확실히 말할 수 있겠지요. 그러나 제가 기술한 kube-proxy의 문제점이 kube-router에서는 개선될 것으로 보입니다.
PORCH WAN 구간 지원 1
PORCH WAN support 논의
목표는 WAN 건너 원격 서버를 PORCH으로 OS/APP 설치하고 싶다. 과연 PORCH이 WAN 구간에서도 제대로 작동하게 할 수 있는가?
Performance problem with Kubernetes-based BIND container
kubernetes 기반 BIND DNS container 서비스 프로젝트를 하고 있다.
성능 상 문제가 있어 여기에 기술한다.
문제 원인
BIND DNS 서비스는 가벼운 서비스이기 때문에 kubernetes 기반으로 빠르고(agile) 탄력적인(elastic) 서비스를 하기에 적합하다고 보았다.
그러나 성능면에서 문제가 발생하였다.
Google Authenticator(OTP)를 이용한 SSH 2차 인증
개요
일반적으로 SSH 인증 방벙들 중 사용자로부터 패스워드를 입력받는 방법인 password authentication을 많이 사용한다. 가장 심플하며 사용하기도 쉽고, 간편한 방법이다. 하지만 보안상 안전한 방법은 아니다. 패스워드가 간단한 규칙이거나 복잡하지 않을수록 brute force attack(무작위 대입 공격)에 취약해진다. 또 패스워드를 직접 입력해야만 하는 방식인 만큼, 이른바 shoulder surfing 등의 사용자 부주의로 인한 패스워드 노출에도 신경 써야 할것이다.
SSH key authentication은 보다 안전한 방법이다. client의 허락된 ssh public key를 server에 미리 넣어둠으로 패스워드 입력없이 서버에 접근 할수 있다. 사용자 입력이 없으니 key logger나 위에서 언급한 shouler surfing 등에서 자유롭고, 사용자는 패스워드를 기억할 필요도 없으니 어딘가에 적어둘 필요도 없어 노출될 가능성도 매우 적다. 그러나 이 방법 역시 단점이 없는것은 아니다. 많은 서버들로 구성된 대규모 환경에서 사용자들의 public key(authorized_keys) 관리는 예상보다 훨씬 간단하지 않다. 또한 어떻게든 사용자의 private key가 유출된다면 아무 의미없는 인증이 되어 버린다.
보다 나은 여러 방법이 있겠지만, 이 문서는 Google Authenticator(https://github.com/google/google-authenticator)를 이용하여 OTP(one-time password) 2차 인증에 대해 기술할 것이다. 위의 인증방법과 더불어 하나의 인증이 추가되는 2차 인증(Two-Factor Authentication: 2FA)이니만큼, 보안적으론 더 안전할수밖에 없다. 그러나 언제나 그렇듯 보안과 편의는 반비례 관계이다. 로그인할때마다 OTP를 확인하고 입력하는 추가작업은 생각보다 불편할 것이다. 하지만 비교적 높은 수준의 보안을 간단하게 구성할 수 있으니, 여러 인증방법중 하나로 충분히 고려해볼만 할것이다.