사용자 모니터 설정은 ~/.config/monitors.xml에 저장된다. GNOME에서 사용하는 모니터 설정을 GDM에도 적용하자.
sudo cp ~/.config/monitors.xml ~gdm/.config/monitors.xml
sudo chmod gdm:gdm ~gdm/.config/monitors.xml
monitors.xml를 복사해도 설정이 적용 안되는 경우 아래와 같이 GDM과 GNOME에서 사용하는 디스플레이 서버가 같은지 확인해 보자. 다음과 같은 경우일 수 있다.
이전에 평균에 대한 글을 쓴 적이 있다. 그 다음 편으로 예정 되어 있던 이동 평균에 대한 알아보자.
통계에서 이동평균은 전체 데이터 집합의 여러 하위 집합에 대한 일련의 평균을 만들어 데이터 요소를 분석하는데 사용되는 계산이다. 금융에서 이동평균은 분석에 일반적으로 사용되는 주식 차트 이다.
지난번 알아 보았던 평균과 평균 필터는 전체 값중 중간 값을 알수 있기 때문에 유용하지만 전체 샘플의 수가 많으면 최근 값이 평균값에 미치는 영향이 작아 지기때문에 누적 데이터가 많아 질수록 현재의 변화 상태를 반영하지 문하는 문제가 있다.
이 포스트에서 사용된 Raw 데이터는 Bitcoin data at 1-min intervals from select exchanges, Jan 2012 to March 2021에서 다운 받은 데이터 중 최근 365일 데이터를 사용하였다.
Gnome 기본 IM(Input Method)인 IBus 입력기에 문제가 있어 fcitx로 입력기를 변경 했다.
pacman -S fcitx5 fcitx5-hangul fcitx5-gtk fcitx5-qt fcitx5-configtool
/etc/environment
GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
시스템을 재시작 하면 fcitx가 자동 실행된다.
어러 쉘이 있다. sh(Bourne Shell)을 기반으로 하는 Bash(Bourne-again shell), zsh(Z shell) 등은 문법이 거의 똑같지만 완전히 같지는 않다.
쉘스크립트를 만들어 실행 하는 경우 #! 지시자로 사용할 쉘을 지정할 수 있기 때문에 크게 문제가 없지만 source 명령이나 dot(.) 명령으로 현재 환경(Current Environment Context)에서 스크립트를 실행하는 경우 사용중인 쉘의 종류에 따라 문법이 달라 문제가 발생 할 수 있다. 주의해서 처리 하도록 하자.
기본쉘을 Zsh 사용하기 시작하면서 겪은 문제다. 보통 리눅스에서 기본쉘은 Bash 이기 때문에 거의 모든 프로그램들이 Bash 위주로 구현되어 있기 때문에 발생 하는 문제이다.
대부분 다음과 같은 문제이다.
실행 스크립트의 파일 이름을 알고 싶을때 Bash에서는 $BASH_SOURCE를 사용한다. 하지만 이 변수는 Bash 에서만 지원됨으로 Zsh에서는 $0 변수를 사용해야 된다. Bash에서도 $0변수를 지원하지만 Bash에서 $0 변수를 사용하면 쉘의 정보((bash)가 표시된다.
쉘스크립트에서
$0는 실행파일의 이름을 나타내는 변수 이다. Bash에서$0변수는 쉘이 시작할 때만 초기화 되지만dot명령은 새로운 쉘을 시작하는 것이 아니라 현재 쉘의 컨텍스트에서 실행 하는 것이므로 쉘에서echo $0를 실행한것과 같은 결과(즉,bash)가 출력된다. 그런데 Zsh 에서는$0가 스크립트 이름으로 세팅된다.
구글링을 해보면 Zsh에서 Bash의
$BASH_SOURCE와 가장 가까운 결과를 내는것은${(%):-%x}라고 한다. 하지만$0도 같은 결과는 내기 때문에 그냥 사용하기로 한다.
다음은 ./env 파일의 내용이다.
| |
각 SHELL에서 실행 해 보자
. ./env
다음과 같은 출력을 얻을 수 있다.
bash
$BASH_SOURCE = ./env
$0 = bash
zsh
$BASH_SOURCE =
$0 = ./env
따라서 실행 되는 스크립트의 이름 알기 위해서는 다음과 같이 쉘에 따라 다른 방식을 정용하여야 한다.
SH_NAME=$(basename $(readlink /proc/$$/exe))
case ${SH_NAME} in
"zsh") SELF=$(realpath $0) ;;
"bash") SELF=$(realpath ${BASH_SOURCE[0]}) ;;
*) echo "Unknown SHELL $SH_NAME" && exit 0 ;;
esac
echo $SELF
Bash 또는 Zsh 만 사용한다면 다음과 같이 사용해도 같은 결과를 얻을 수 있다.
SELF=$(realpath ${BASH_SOURCE[0]:-$0})
echo $SELF
아래와 같이 env 파일을 만들고 dot command로 실행해보자
SELF=${BASH_SOURCE[0]:-$_}
echo $(basename $SELF) is located at $(realpath $SELF)
env 파일 실행
. ./env
Bash, Zsh 둘다 같은 결과를 얻을 수 있다.
env is located at /home/euikook/src/env
$SHELL/etc/password 파일에 정의된 사용자에 할당된 SHELL 출력한다.
echo $SHELL
지정된 쉘 정보를 표시 하지만 현재 사용중인 SHELL 정보를 출력하지 않는다.
$ cat /etc/passwd | grep $USER
john:x:1000:1000::/home/john:/usr/bin/zsh
cat 명령으로 /etc/passwd 파일을 확인 결과 /usr/bin/zsh 가 쉘로 할당되어 있다.
아래와 같이 bash로 쉘을 변경 후 $SHELL 과 $0 정보를 출력 해보자.
$ bash
$ echo echo User SHELL is $SHELL, Current SHELL is $0
User SHELL is /usr/bin/zsh, Current SHELL is bash
로컬 네트워크에서 사용할 목적으로 직접 서명(Self Signed)한 인증서를 가지고 서비스를 제공 하는 경우 인증서를 인증한 인증 기관의 공개키 인증서가 브라우저 또는 운영체제에 없기 때문에 신뢰할 수 없는 사이트 경고 메시지를 보게 된다. 경고 메시지를 없에려면 인증서를 인증한 사설 인증기관(CA)의 공개키 인증서(Public Key Certificate)를 브라우저 또는 운영체제에 설치 하여야 한다. 이 글에서는 Windows환경에서 사설 인증 기관 인증서를 설치 하는 벙법에 대하여 알아본다.
Windows는 운영체제 수준에서 CA 인증서를 관리 하기 때문에 운영체제의 CA 인증서 저장소에 인증서를 등록하면 특별한 경우를 제외 하면 거의 모든 프로그램에서 해당 인증서에 접근 할 수 있다.
mmc를 입력 하고 Enter 키를 누른다.
시작 에서 실행을 검색하여 실행한다.
어떤 설치 미디어나 라이브 디스크 라도 상관 없지만 이 글에서는 우분투를 기준으로 설명 하도록 한다.
원하는 우분투 미러 사이트에서 설치 미디어를 다운로드 한다.
이글에서는 ubuntu-22.04.3-live-server-amd64.iso 파일을 기준으로 설명 한다.
파일의 검증을 위해 SHA256SUM 파일과 SHA256SUM.gpg 파일도 같이 다운로드 한다.
SHA256SUM 파일은 내려 받은 ubuntu-22.04.3-live-server-amd64.iso 파일이 손상 되거나 변조 되었을 우려가 있으므로 파일의 SHA256 해시가 저장되어 있어 파일의 무결성 검증에 사용된다. SHA256SUM.gpg 파일은 SHA256SUM에 GPG 서명으로 SHA256SUM 파일이 손상되거나 변조 되었을 경우 이를 인지 하기 위해 사용된다.
먼저 SHA256SUM.gpg 파일을 이용해 SHA256SUM 파일을 검증한다.
gpg --verify SHA256SUMS.gpg SHA256SUMS
아래와 같은 에러 메시지가 나온다면 키서버로 부터 공개키를 내려 받아야 한다.
$ gpg --verify SHA256SUMS.gpg SHA256SUMS
gpg: Signature made Fri 11 Aug 2023 03:33:07 AM KST
gpg: using RSA key 843938DF228D22F7B3742BC0D94AA3F0EFE21092
gpg: Can't check signature: No public key
공개키의 ID 가 843938DF228D22F7B3742BC0D94AA3F0EFE21092 이라는 것을 알 수 있다.
gpg --keyid-format long --keyserver hkp://keyserver.ubuntu.com --recv-keys 843938DF228D22F7B3742BC0D94AA3F0EFE21092
해당 키를 내려 받는다.
$ gpg --keyid-format long --keyserver hkp://keyserver.ubuntu.com --recv-keys 843938DF228D22F7B3742BC0D94AA3F0EFE21092
gpg: key D94AA3F0EFE21092: public key "Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
공개키를 내려 받았음니 SHA256SUM 파일을 다시 검증해 보자.
$ gpg --verify SHA256SUMS.gpg SHA256SUMS
gpg: Signature made Fri 11 Aug 2023 03:33:07 AM KST
gpg: using RSA key 843938DF228D22F7B3742BC0D94AA3F0EFE21092
gpg: Good signature from "Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8439 38DF 228D 22F7 B374 2BC0 D94A A3F0 EFE2 1092
gpg: Good signature from “Ubuntu CD Image Automatic Signing Key (2012) cdimage@ubuntu.com” [unknown]
위와 같은 출력이 나온다면 SHA256SUMS 파일의 무결성은 확인 되었다.
이제 SHA256SUMS 파일을 이용하여 ubuntu-22.04.3-live-server-amd64.iso 파일의 무결성을 검증해보자.
SHA256SUMS 파일의 내용을 보면 sha256 해시와 파일 대상파일의 파일명이 같이 기술되어 있다.
a435f6f393dda581172490eda9f683c32e495158a780b5a1de422ee77d98e909 *ubuntu-22.04.3-desktop-amd64.iso
a4acfda10b18da50e2ec50ccaf860d7f20b389df8765611142305c0e911d16fd *ubuntu-22.04.3-live-server-amd64.iso
아래 명령을 이용하여 ubuntu-22.04.3-live-server-amd64.iso의 무결성을 검증한다.
SHA256SUMS 파일에는 2개의 파일이 기술되어 있지만 우리는 ubuntu-22.04.3-live-server-amd64.iso 파일만 다운로드 하였기 때문에 --ignore-missing 옵션을 이용하여 없는 파일은 무시 하도록 한다. 4
sha256sum --check --ignore-missing SHA256SUMS
아래와 같이 OK 가 나오면 iso 파일의 무결성은 검증이 완료 되었다.
$ sha256sum --check --ignore-missing SHA256SUMS
ubuntu-22.04.3-live-server-amd64.iso: OK
FAILED 가 나온다면 파일이 손상되었거나 변경되었다는 의미 이므로 다시 다운로드 하자.
자동 마운팅 기능이 활성화 되어 있거나 수동으로 마운팅 하여 USB저장 장치가 마운트 되어 있다면 마운트해제한다.
lsblk 명령으로 블럭 디바이스를 확인한다.
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 953.9G 0 disk
├─sda1 8:1 0 512M 0 part
└─sda2 8:2 0 953.4G 0 part /home/data
sdc 8:32 1 14.3G 0 disk
└─sdc1 8:33 1 14.3G 0 part /run/media/user/7AFC-CAE9
nvme0n1 259:0 0 1.9T 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot
├─nvme0n1p2 259:2 0 64G 0 part /
└─nvme0n1p3 259:3 0 1.8T 0 part /home
sda, sdc, nvme0n1 세개의 블럭 디바이스가 있다. 그중에 sdc가 USB 장치 이고 sdc1 이 /run/media/user/7AFC-CAE9에 마운트 되어 있다.
마운트를 해제한다.
sudo umount /dev/sdc1
LD_LIBRARY_PATH vs LIBRARY_PATH외부 C 라이브러리를 사용하는 Python 패키지를 빌드 하는데 참조하는 라이브러리가 표준 라이브러리 디렉터리에 있지 않아 검색할 라이브러리의 위치를 LD_LIBRARY_PATH 환경변수를 이용하여 지정하였으나 빌드가 계속 실패 한다.
/usr/bin/ld: cannot find -ltest
삽질을 좀 하다가 생각해보니 LD_LIBRARY_PATH는 런타임(실행시)에서 사용되고 실제 컴파일 시에는 -L 옵션을 했다는 것이 생각 난다.
다음과 같이 -L 옵션으로 라이브러리를 검색할 디렉터리를 지정할 수 있다. -l 옵션으로는 라이브러리 피일을 지정한다.
gcc -o test.o -L/path/to/custom/lib -ltest
빌드 설정파일을 변경하면 되지만 직접 관리하는 소스가 아닌경우 업데이트 시 매번 같은 작업을 해주어야 하기 때문에 환경 변수로 라이브러리 경로를 설정 하는 방법이 있으면 좋을 것 같다. GCC manual 페이지를 읽어 보니 컴파일 타임에 라이브러리(링커 파일)검색 할 때는 LIBRARY_PATH 변수를 설정해 주면 된다. -L 옵션에서 지정한 디렉터리가 우선순위를 갖는다.
Git은 분산형 버전관리 시스템(VCS, Version Control System)이기 때문에 가지고 있는 태생적인 문제가 있다. Subversion과 같은 중앙 집중형 버전관리 시스템은 모든 수정 사항이 중앙(버전관리서버)에서 관리 되기 때문에 사용자가 자신의 수정 사항을 소스 트리에 저장하고 싶으면 중앙에 있는 버전관리 시스템으로 커밋(서브버전 기준)하여야 한다. 인증 이 필요한 원격의 저장소를 사용한다고 가정하면 커밋할때 마다 매번 인증을 받아야 하고 인증이 정상적으로 완료 되어야 Commit이 반영되기 때문에 인증 정보를 도용당하지 않는 이상 기여자의 정보가 부정(도용) 사용될 경우는 거의 없다.
하지만 Git와 같은 분산형 버전관리 시스템의 경우 로컬에서 자신만의 소스트리의 관리가 가능하고 커밋에 저장되는 커밋의 작성자(Author) 커밋터(Committer)정보가 커밋을 하고자 하는 사람(또는 장치)가 제공하는 정보에 의존하기 때문에 기여자의 정보가 부정(도용) 사용 될 우려가 있다.
최근 나오는 치팅의 대부분은 권위있는 사람이나 사이트 또는 단체로 가장하여 사용자의 결제 정보를 포함한 개인 정보를 탈취하는 것이다.
프로젝트의 관리자가 Pull Request를 받았다고 가정하자. 가장 이상적인 관리 방법은 관리자가 모든 코드를 리뷰 하고 문제가 없을 경우에만 해당 요청을 승인 하는것이지만 관리자가 모든 코드를 리뷰 하지 못하는 경우 앞서 학습된 기여자의 평판에 의존 하여 승인 여부를 결정 할 수 있다. 공격자는 관리자가 신뢰할 만한 기여자의 이름을 도용하여 Pull Request를 하면 관리자는 도용된 기여자의 평판을 기반으로 승인 여부를 결정할 수 있기 때문에 문제가 발생할 수 있다. 그렇다면 이러한 명의의 도용을 막는 방법은 무엇이 있을까?
이 글에서는 Insync을 사용중 PC를 옯기거나 OS를 재설치 하여야 하는 경우 재 동기화 없이 데이터를 옮기는 방법에 대하여 설명한다.
Insync: Google Drive Syncing Application for Linux
Insync: 리눅스를 위한 Google Drive 동기화 어플리케이션
PC를 Apple에서 Banana로 옯기는 경우 Apple PC와 Bnana PC에서 Insync를 종료 한다. OS를 다시 설치 하는 경우 해당 PC의 Insync만 종료 한다.
insync quite
insync-headless quite
Insync의 동기화 폴더를 Apple에서 Banana로 이동한다.
리눅스의 경우 rsync로 동기화 할 수 있다. 이동 하고자 하는 Banana에 접속 하여 아래 명령을 수행한다.
실제 명령 입력 시
Apple은 자신의 기존 컴퓨터의 호스트네임으로 변경한다.
Apple과 Banana의 동기화 디렉터리는 경로가 같아야 한다.
Desktop 라이센스로 같이 사용할 수 있을 줄 알았는데. 서버용 라이센스를 별도로 구매 해야 된다.
WTF그것도 일년에 39.99 달러, 거기다 나처럼 Google Workspace를 사용하여 gmail.com 이 아닌 커스텀 도메인 을 사용하는 사람은 일년에 159.99 달러다.돈이 썩어 나는구나.다음글을 참고 하여 Insync Desktop 버젼을 자동실행 하는 방법을 사용하자. Insync 3.x auto start with xvfb and systemctl. 굳이 연간 39.99 달러나 159.99 달러를 내면서 headless 버젼을 사용하고 싶으신 분은 다음글을 참고 하기 바란다.
그냥 GoodSync로 갈아 타 버릴까?
이 글에서는 Google Drive 와 One Drive의 third-party 동기화 유틸인 Insync의 headless 버전을 설치 하고 자동 실행 하는 방법에 대하여 알아본다.
Insync: Google Drive Syncing Application for Linux
Insync: 리눅스를 위한 Google Drive 동기화 어플리케이션
Insync가 3.x 버전으로 판올림 되면서 headless 버전이 사라지는 바람에 xvfb를 통해 우회 실행 하는 방법에 대하여 설멍한 적이 있다.
하지만 Insync 3.x 대한 headless 버전이 릴리즈 되었기 때문에 이런 번거로운 작업이 필요 없어 졌다.
잘 돌아가는 Insync를 headless 버전으로 바꾸기 귀찮아서 미루고 있었는데 이번에 Ubuntu Box를 Bionic에서 Focal로 판올림 하는 김에 시간을 내서 headless 버전으로 변경 하였다.
Insync의 설치 방법은 Insync - Linux에서 Google Drive Desktop Client 사용하기를 참고 한다.