오래전부터 느껴오던 문제가 있다.

굿네이버스 등 여러 단체들을 통해 해외 어린이 정기 후원을 하는 사람들이 많고,
자신의 후원 이야기를 담은 글을 블로그 등에 올리는 경우도 많다.
대개는 후원을 하게 된 개인적인 동기, 후원의 느낌, 자신만의 의미부여 소회 등을
기록하고 싶은 마음에 올리는 글들인데, 그 취지는 충분히 공감하고 보기에도 좋지만
그런 글의 상당수가 아이의 신상정보를 지나치게 드러내고 있는 점만은 문제가 있다고 생각한다.

아이의 사진은 물론이고 신상정보가 정리된 카드까지 통째로 찍어서 올리곤 하는데
아이의 입장에서 이런 행위가 달가울 리는 없을 것이다.

후원자는 후원자로써 아이를 도울 뿐, 아이에 대해 어떤 권리를 가지는 것은 아니다.
아이의 개인정보는 후원자에게만 특별히 제공된 것이며 소중히 보호받아야 한다.

후원자라고 해서 아이의 개인정보를 함부로 공개하는 행위는 삼가도록
후원중개기관에서 배포하는 개인정보 카드에 눈에 잘 띄게 적어주면 좋겠다.

ZFS 오류 복구 3 (정확히는 4)

시게이트 ST3000DM001 (/dev/sdb)가 하다 더 맛이 갔다.
지난번까지는 HGST HDN724030ALE640로 교체했지만,
이번에는 TOSHIBA DT01ACA300 모델로 교체했다.
과정은 전과 같음.

# Here Strings
$ cat <<<asdf
asdf

# Process substitution
$ cat < <(echo asdf)
asdf
$ cat <(echo asdf)
asdf

$ echo asdf | cat
asdf

하드 디스크 6개 짜리 RAID-Z2 볼륨에서 네 번째로 디스크 문제가 생겼다.
2013년 4월에 Seagate Barracuda ST3000DM001 모델 6개로 구성했는데
만 2년이 지난 (보증기간이 딱 지난) 2015년 6월부터 하나씩 문제가 생기더니 최근 1년 사이에 4개째다.

처음 두 개는 같은 모델 여분의 디스크로 교체하다가 뭔가 아니다 싶어서
이후부터는 다른 모델로 교체했다 (HGST HDN724030ALE640).

오늘 생긴 문제는 디스크가 죽는 수준은 아니고
배드섹터 전단계의 섹터가 8개 나왔다는 SMART 경고가 메일로 날아온 것이었다.

접속해서 살펴본 SMART 정보는 아래와 같았다.



경험상 이 모델은 믿을 수 없으므로, 문제의 소지가 발견된 순간 바로 교체했다.

(이 모델의 유독 높은 오류발생률은 이미 유명하다.
 CSI: Backblaze – Dissecting 3TB Drive Failure
    https://www.backblaze.com/blog/3tb-hard-drive-failure/ )



헌 디스크 분리하고, 새 디스크 다는 과정에서 생긴 dmesg 로그는 아래와 같았다.
훌륭하게 된 건지는 모르겠고, 리눅스 가동중인 상태에서도 교체는 그럭저럭 가능했다.

그나마 4칸짜리 하드디스크랙(앤디코 하드랙 EasySTOR 340SS)을 설치해뒀기에 가능한 일이었다.
전에 PC 케이스의 내장 HDD 자리에 달려있던 디스크가 죽었을때는 어쩔 수 없이 전원 끄고 작업했다.

업무상 잡용도로 혼자 쓰는 우분투 서버를 운영한다.
루트파일시스템으로 btrfs 파일시스템을 쓰고 잡 백업 용도로 zfs raid-z2 볼륨을 구성해 쓴다.

처음엔 Ubuntu 12.04를 설치해서 한두해 쓰다가 몇 달 전에 14.04로 업그레이드했고,
이번에 다시 16.04로 업그레이드했다.

14.04 LTS -> 16.04 LTS 업그레이드하며 겪은 일을 생각나는대로 간단히 적어둔다.

업그레이드는 $ sudo do-release-upgrade -d 식으로 했다.
아직 14.04 -> 16.04 업그레이드가 정식으로 오픈되지 않은 상태이므로 -d 옵션을 줘야 했다.
운영중인 시스템에 이렇게 실험적인 업그레이드를 시도한 것은 btrfs snapshot 기능을 믿었기 때문이다.

btrfs snapshot을 이용한 안전한 do-release-upgrade 실험
    http://chanik.egloos.com/4099097

업그레이드는 위 글에 나온 식으로 @_16.04, @home_16.04 snapshot을 만들고
그 스냅샷으로 부팅한 상태에서 진행했다. 하다가 꼬이면 그냥 스냅샷을 날려버리고 원복할 생각이었다.

12.04 LTS -> 14.04 LTS 때와 달라진 점은 Ubuntu 16.04 LTS가 zfs를 커널 자체에서 지원하게 된 것이다.
14.04에서 http://zfsonlinux.org/ 리포로부터 설치해서 쓰던 zfs 모듈이 16.04에서는 커널 자체모듈로 대체되고,
zfsutils-linux 패키지도 http://zfsonlinux.org/ 리포의 것이 아닌, 우분투 자체 리포의 것을 써야 했다.

업그레이드 전에는 http://zfsonlinux.org/ 리포를 꺼야 했고,
업그레이드 뒤에는 자동으로 zfs 볼륨이 올라오지 않는 현상 때문에 아래와 같이
zfsutils-linux 패키지를 자체 리포의 것으로 교체해야 했다.

ZFS Pools not mounted 16.04
    http://askubuntu.com/questions/768179/zfs-pools-not-mounted-16-04



그리고, remove 할 때 zfs-auto-snapshot 패키지도 함께 사라져서 아래와 같이 다시 설치했다.



그냥 설치했다가 "/bin/sh: 1: zfs-auto-snapshot: not found" 오류를 겪고 나서,
make install 전에 etc/zfs-auto-snapshot.cron.frequent 스크립트를 아래와 같이 수정해야 했다.



12.04 LTS -> 14.04 LTS 때와 달라진 점 또 한 가지는,
16.04 LTS에서는 python 2를 없애버려도 된다는 것이다.
아래와 같이 했다.

Ubuntu 16.04 LTS 파이썬2 제거
    http://chanik.egloos.com/4112679


끝으로, PostgreSQL 버전이 9.3 -> 9.5로 바뀌었으므로 데이터를 새 버전으로 이전해야 했다.
지난 번 12.04 LTS -> 14.04 LTS 업그레이드때도 해야 했던 작업이었고 아래 글을 참조했다.

Upgrading PostgreSQL 9.1 to 9.3 in Ubuntu
    http://nixmash.com/postgresql/upgrading-postgresql-9-1-to-9-3-in-ubuntu/

위 글의 명령대로 하면 너무 느리기도 하고 중간에 오류도 생겨서, 아래와 같이 좀 수정된 명령을 썼다.
( 그리고, 내가 관리하는 DB는 테이블이 너무 많고 데이터도 많아서 변환중에 오류를 뿜었다.
 /etc/postgresql/9.3/main/postgresql.conf 을 임시로 수정해서
 max_locks_per_transaction = 640 정도로 임시설정하고 다시 변환해야 했다)


ㅇ "-m upgrade" means using pg_upgrade instead of pg_dump & pg_restore,
ㅇ "-k" means using hard links instead of file copying (so it can be used only if old DB and new DB is in the same partition). Manual page states that "-k" is merely passed to the pg_upgrade comand.

14.04 -> 16.04 로 do-release-upgrade -d 방식으로 업그레이드하면
python2와 python3가 공존하는 형태로 설치된다.

python2를 없애고 python3만 남겨 쓰기 위해 아래와 같이 했다.


https://wiki.ubuntu.com/XenialXerus/ReleaseNotes



http://askubuntu.com/questions/761106/how-to-remove-python-2-in-16-04


이 상태에서 python을 실행하면 조용히 python3가 실행되는 것이 아니고 무슨 헛소리가 나온다.
아래와 같이 해 줘야 비로소 python 명령으로 자연스럽게 python3을 실행할 수 있다.

https://linuxconfig.org/how-to-change-from-default-to-alternative-python-version-on-debian-linux

# update-alternatives --install /usr/bin/python python /usr/bin/python3.5 1

500GB 하드디스크 두 개에 Btrfs RAID1 볼륨으로 루트파일시스템이 설치되어 있는 상태인데
이 부트파티션을 다른 테스트PC로 간단히 복제해 쓰고 싶어서 했던 작업 기록.
작업 며칠 뒤에 편집하고 재구성한 것이라서 기록이 좀 미비하다.
설치되어 있던 배포판은 CentOS-7.

볼륨 구성은 아래와 같다.


sda1은 원래는 /boot 용도였지만 지금은 쓰지 않는 파티션.
sda2는 sdb1과 함께 Btrfs RAID1 볼륨. CentOS-7 설치된 상태.
sda3은 SWAP 파티션.



#
# 원본 Btrfs 파티션 마운트
#



#
# 각 서브볼륨에 대해 snapshot 을 작성하고, snapshot 들을 읽기전용으로 변경
# 읽기전용이 아니면 send 시도할때 오류가 생긴다.
#



#
# - 새 하드디스크 /dev/sdc 연결하고 파티션테이블 레이아웃 복제 (새 디스크도 500GB 짜리)
# - /dev/sdc3에 SWAP 파티션 생성
# - /dev/sdc2에 Btrfs 파일시스템 생성 (원본은 RAID1볼륨이지만 새 볼륨은 단일디스크 볼륨)
#



#
# 새로 만든 Btrfs 파티션을 마운트하고 마운트 디렉토리로 이동
#



#
# 원본 Btrfs 서브볼륨들에 대해 만들어둔 읽기전용 스냅샷을 하나씩 send 하고
# 새로 만든 Btrfs 파티션에서 receive.
#



#
# 이제 새 디스크의 새 Btrfs 파티션에 서브볼륨들이 복제된 상태다.
# 원본은 RAID1 볼륨이었으나 새 볼륨은 단일디스크 볼륨이며, 내용물은 동일한 상태가 된다.
# 각 서브볼륨 이름을 변경하고, 읽기전용 속성도 풀어준다.
#



#
# 새 볼륨의 boot/grub2/grub.cfg 파일 적당히 편집하고
# chroot해서 grub2-install 등도 해 준다.
# 이제 새 디스크에 부트파티션의 Btrfs 볼륨이 복제되었고 grub2도 설치되었으므로
# 새 PC로 가져가서 부팅용으로 쓰면 된다.
#
# 해보니 일단 부팅은 잘 되는데,
# 일부 패키지들의 실행파일 setuid 비트가 제대로 옮겨지지 않아서 자잘한 문제가 생겼다.
# 이를테면, hostnamectl로 기기명을 변경해도 재부팅하면 다시 원래대로 되돌아가버린다든지..
#
# 아래 명령으로 전체 패키지를 재설치시켜서 해결했다. 물론 시간이 좀 걸린다.
#

Asus P5QL-EM 보드에서 CentOS7을 잠시 돌려보면서 눈에 띈 점을 적어둔다.

P5QL-EM 보드에는 사우스브리지 ICH10에서 제공되는 SATA 3Gbps 포트 6개 말고도
Marvell 88SE6121콘트롤러를통해제공되는eSATA 3Gbps 포트 1개 및 PATA 포트 한 개가 더 있다.

이 콘트롤러에는 두 가지 드라이버 중 하나를 골라 쓸 수 있다.
하나는 pata_marvell, 또하나는 ahci.

pata_marvell은 SATA 및 PATA 포트 모두를 쓰게 해 주지만 eSATA hot plug 기능이 안 된다.
ahci를 쓰게 되면 eSATA hot plug가 가능해지지만(직접 확인하지는 않음) PATA 포트를 지원하지 않는다.

기본상태로는 88SE6121 드라이버로 pata_marvell 모듈이 쓰이게 된다.
ahci 모듈을 쓰려면 ahci.marvell_enable=1 커널 옵션을 주어야 하며,
/etc/default/grub 파일에 아래와 같이 추가하면 된다.



ahci 드라이버를 쓰면 아래와 같은 메시지가 나온다.



[참고] Linux에서의 88SE6121 SATA 포트 특징.
          (pata_marvell, ahci 뭘 쓰든 마찬가지로 나온다)

  - SATA 3.0Gbps
  - NCQ 미지원
  - PMP 미지원

[참고2] Linux IDE (PATA) driver problem workaround for Marvell 88SE6111, 88SE6121, 88SE6145
    https://en.wikipedia.org/wiki/List_of_Marvell_Technology_Group_chipsets#Linux_IDE_.28PATA.29_driver_problem_workaround_for_Marvell_88SE6111.2C_88SE6121.2C_88SE6145

IPMSB 보드를 쓴 PC가 몇 대 있느데,
그 가운데 한 놈에 바이오스 업데이트를 하다가 실수로 엉뚱한 버전을 입혀서
PC가 화면도 안 나오는 상태로 죽어버렸다.
이미지 크기가 안 맞는다는 둥 하는 경고 메시지가 나왔는데 그걸 무시한 것이 화근이었다.

세계적으로 많이 쓰이는 OEM 보드인 것 같은데,
인터넷을 뒤져도 별다른 해결방법이 나오지 않았고
국내수입사 홈페이지 FAQ를 보니 아래와 같은 안내가 나왔다.


보드를 분해해서 고객센터로 가려다,
문득 옛날에 쓰던 플래시칩 교체방법이 생각나서 간단히 해결할 수 있었다.

이 방법은 동일모델의 보드가 하나 더 있고 플래시칩에 소켓형식으로 분리가 가능할 때만 쓸 수 있는 방법이다.
보드를 살펴보니 플래시칩처럼 생긴 칩이 보였다.



대충 알아볼 수 있는 "winbond 250328" 로 검색해보니 다행히도 플래시칩이 맞았다.
아래와 같이 했다.




그냥 디스켓이나 CD/DVD 갈아끼우는 기분으로 하면 된다.
다만, 동작중인 보드 표면 가까이에서 하는 작업이므로 혹시라도 플래시칩의 핀이나
(제거를 위해 사용할 수 있는) 드라이버 등의 금속 공구가 보드 패턴이나 각종 칩의 다리를 건드려
합선시키는 일이 생기지 않도록 긴장감은 유지해야 한다.


이런 동작이 가능한 이유는,
플래시칩에 전원이 공급되는 것은 아래의 두 경우 뿐이기 때문일 것이다.

  ㅇ 부팅초기에 칩에서 바이오스를 읽어들일 때 ==> 읽기 동작만 일어날 것이다
  ㅇ 바이오스 업데이트할 때 ==> 읽기와 쓰기가 모두 일어나는 경우가 많다

일단 POST 단계를 지나고 OS 부트로더로 제어가 넘어가고 나면
더이상 플래시칩에 전원이 제공되지 않으므로
동작중인 보드에서 플래시칩을 교체하는 일이 가능해지는 것이다.

( Windows 동작중에 바이오스 플래싱을 지원하는 프로그램이 제공되는 경우도 많은데,
  이 경우엔 플래싱이 일어나는 동안에만 칩에 전원이 제공되는 것이라 보면 될 것이다 )

사실 오래전부터 흔히 알려져 있는 방법인데,
요즘은 플래시칩이 소켓 형태로 분리되지 않고 납땜되어 있는 경우가 많아서
모든 보드에 적용하기는 어렵다.

pgAdmin 사용중 DB 접속할 때마다 자꾸만 팝업 안내창이 뜨길래
PostgreSQL adminpack extention을 설치했다.


주의: 모든 db에 대해 CREATE EXTENSION adminpack; 실행해야 한다고 함.
     그렇게 해줘야 pgAdmin III 에서 DB접속시 경고가 사라진다.


Ubuntu 14.04, Postgresql-9.3 에서도 아래와 같이 비슷하게 하면 됨.




그런데, CentOS5의 postgresql84 에서는 아래와 같이 좀 달랐음.

- Setting Up pgAdmin Server Instrumentation
    http://www.gistutor.com/postgresqlpostgis/6-advanced-postgresqlpostgis-tutorials/32-setting-up-pgadmin-server-instrumentation.html

- An almost idiot's guide to Install and Upgrade to PostgreSQL 8.4 with Yum
    http://www.postgresonline.com/journal/archives/144-An-almost-idiots-guide-to-Install-and-Upgrade-to-PostgreSQL-8.4-with-Yum.html