ubuntu 16.04  터미널에서 로그파일등에서 주요 키워드를 볼때 색상을 표시하고자 한다.

watch --color -n 10 \
 'bash your-program-run.sh |  \
GREP_COLOR="01;33" grep --color=always -i -e "Warnning.*" -e "^" | \
GREP_COLOR="01;35" grep --color=always -i -e "Fail.*" -e "^" | \
GREP_COLOR="01;31" grep --color=always -i -e "Alert.*" -e "^"  \
 '

프로그램 실행 명령이 출력으로 나올 때 grep 으로 색상을 표시한다. ( --color=always )
GREP_COLOR 로 키워드 별로 색상을 다르게 줄 수 있다.
(색상코드는 여기 참조 : https://chrisyeh96.github.io/2020/03/28/terminal-colors.html )

또한 -e ".*Keyword.*" 처럼 하면 해당 키워드가 나온 모든 줄이 되고, -e "Keyword" 를 하면 해당 키워드만 색상표시된다.

그런데, 문제는 watch 를 조합하면 색상 표시가 안된다.(우분투 16.04)

동일 명령을 ubuntu 22.04 에서는 정상으로 나온다.

터미널에서 색상코드(ansi code) 표시를 제대로 처리 못하는 것 같다.

우분투 16.04 의 watch 버전은 3.3.10 버전 ( 22.04 는 3.3.17 버전이다)

# 해결 방안

방법1. 정상동작 하는 터미널에서 원격으로 접속 명령을 내린다.

watch --color -n 10 'ssh {your-username}@{your-server} {원래 명령}'

위 처럼 해서 watch 가 색상코드를 정상적으로 처리하도록 한다.

방법2. watch 버전을 해결된 버전으로 소스 컴파일 한다.

위 방법이 뭔가 찜찜하다면, 소스를 직접 컴파일한다.

소스 : https://gitlab.com/procps-ng/procps/-/releases/v3.3.13

해당 릴리즈의 Changelog 를 보니

watch: Support ANSI 39,49 reset sequences              issue #73

가 해당 버그인 듯 싶다.

암튼 소스를 받고 컴파일 한다.

wget https://gitlab.com/procps-ng/procps/-/archive/v3.3.13/procps-v3.3.13.tar.gz

tar xvzf procps-v3.3.13.tar.gz
cd procps-v3.3.13/

sudo apt install autoconf libtool autopoint libtool-bin ncurses-dev

./autogen.sh
./configure
make

설치는 make install 으로 하면 /usr/local/bin 으로 설치가 될 것이다.

그런데, 이 경우 watch 만 필요하니 $HOME/bin 디렉토리에 복사해서 사용했다.

정상적으로 색상이 나오는 것을 확인했다.

방법3. 상위버전 deb 패키지에서 watch 파일을 추출한다.

위 방법2 로 소스컴파일 하니, 문제는 한글이 watch 를 거치면서 사라져 버린다. ㅜㅜ

상위 deb 패키지에서 추출하기로 한다.(현버전 16.04 => 18.04 의 패키지)

상위버전 패키지 - https://launchpad.net/ubuntu/+source/procps/2:3.3.12-3ubuntu1.2/+build/17397008

procps_3.3.12-3ubuntu1.2_amd64.deb (219.4 KiB)

하단의 deb 파일을 다운로드

패키지를 설치하면 다른 이상이 있을 수 있으니, watch 실행파일만 추출한다.
(참조 : https://www.cyberciti.biz/faq/how-to-extract-a-deb-file-without-opening-it-on-debian-or-ubuntu-linux/ )

ar x procps_3.3.12-3ubuntu1.2_amd64.deb

tar xvJf data.tar.xz

cp usr/bin/watch $HOME/bin

이제 한글도 제대로 나온다.

오래된 서비스가 돌아가는 머신이 있다.

ubuntu 10.04 버전이니 14년이 넘어가는 머신 - 리얼서버 => 가상서버 로 몇번 옮겨지기도 했다.

새버전으로 바꾸기에는 레거시 코드가 있어서 그냥 돌리고 있다.

리얼 => 가상 서버로 옮겨지면서, 가상머신 내부는 최소의 용량으로 두고, 데이터는 외부로 두고 nfs 로 마운트해서 사용하고 있다.

재부팅할 때 - 아래 부분에서 딜레이가 발생한다.

원인을 찾아보다가, 보아하니 nfs 마운트한 위치를 bind 로 재마운트 한 부분에서 딜레이가 발생하는 것 같다.

# apache logs
/data8/apache2                /var/log/apache2   bind    bind,rw,defaults  0  2

/data8 이 nfs 로 마운트 된 위치 , 그것을 mount bind 로 했다.

재부팅 reboot / 종료 halt 시에 딜레이가 발생한다. ( 이 부분이 ubuntu 상위 버전에서는 일어나지 않는 듯 하다)
10.04 버전에서 이상현상.(다른 모든 버전을 체크하지는 못 함 - 비슷한 환경을 구성한 14.04 은 정상 )

종료프로세스인 /etc/rc6.d 부분이

umount 코드들이 실행되지만, mount bind 는 제대로 언마운트를 못하는 듯 하다.

그래서

S22umount-work-nfs -> ../init.d/umount-work-nfs*

위 파일을 만들어 줬다.

# cat /etc/init.d/umount-work-nfs 
#! /bin/sh
### BEGIN INIT INFO
# Provides:          unmount work nfs
# Required-Start:
# Required-Stop:
# Default-Start:
# Default-Stop:      6
# Short-Description: Umount nfs work dir before reboot.
# Description:
### END INIT INFO

PATH=/sbin:/usr/sbin:/bin:/usr/bin

. /lib/lsb/init-functions

do_stop () {
	# Message should end with a newline since kFreeBSD may
	# print more stuff (see #323749)
	log_action_msg "Will umount all nfs work dir - before restart"
	umount /var/log/apache2 
}

case "$1" in
  start)
	# No-op
	;;
  restart|reload|force-reload)
	echo "Error: argument '$1' not supported" >&2
	exit 3
	;;
  stop)
	do_stop
	;;
  *)
	echo "Usage: $0 start|stop" >&2
	exit 3
	;;
esac

do_stop 부분에 bind mount 한 위치를 umount 해준다.

10.04 버전을 아직도 쓰실 분이 얼마나 있겠냐마는 ㅜㅜ

난 여러버전을 쓰고 있구나. 10.04 / 14.04 / 18.04 .. 최근 22.04 도 ,  곧 나올 24.04 도 쓰겠군.

우분투 <=> 윈도우 의 경우는 심볼릭링크가 크게 상관없을 듯 하다.

그런데, 우분투 <=> 우분투 의 경우 samba 마운트 시에 symlink 유지여부가 SMB 버전마다 차이가 있는 듯 하다.

결론부터 이야기 하면 vers=1.0 으로 해야 유지가 되는 듯 하다.

//ubox-serv/data  /data/   cifs uid=ccex,gid=ccex,username=guest,password=,iocharset=utf8,vers=1.0  0  2
#//ubox-serv/data  /data/   cifs uid=ccex,gid=ccex,username=guest,password=,iocharset=utf8,noserverino 0  2

fstab 에 설정에서 위처럼 vers=1.0 으로 하는 경우만 symlink 유지됨.

SMB버전은 올리고, noserverinfo 등의 옵션은 안되는 듯 하다.

다른 해결 방법이 있을지는 추후 필요하면 정리.

우분투 배포판은 지원기간이 있다. LTS 버전은 좀더 오래 지원한다.
(지원 기간은 https://wiki.ubuntu.com/Releases 참조)

ubuntu 12.04 를 사용할 일이 생겨 - 설치를 했는데, 패키지가 깔리지 않아 한글도 안보이고 이상한 부분이 있었다.

추가적인 보안 지원같은 것은 안되지만, 마지막 패키지까지는 사용할 수 있다.

deb http://old-releases.ubuntu.com/ubuntu/ precise universe
deb-src http://old-releases.ubuntu.com/ubuntu/ precise universe
deb http://old-releases.ubuntu.com/ubuntu/ precise-updates universe
deb-src http://old-releases.ubuntu.com/ubuntu/ precise-updates universe

/etc/apt/sources.list 를 위처럼 old-releases 주소로 바꿔준다.

보통 다음 주소로 되어 있을 것이다.

http://kr.archive.ubuntu.com

주소를 바꿔주면, apt-get 으로 패키지를 설치해서 사용할 수 있다.(한글 언어 패키지 등 설치 가능)

동일한 환경의 서버에 ssh 접속하는데, 5초가량 늦는다. (차이점은 동일버전의 서버용/데스크탑용 의 차이)

ssh server -vvv 로 접속해보면

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50

위 부분에서 5초가량 늦게 접속이 된다.(다른 서버는 거의 바로 접속)

구글링을 해보니, avahi-daemon 이라는 용의자가 보인다.

service avahi-daemon stop
or
systemctl stop avahi-daemon

정지하고 접속하니 해결.

여러 서버/데스크탑을 사용해봤지만, 이런 상황은 처음 겪어본다.
우분투 12.04 지원까지 끊긴 서버라 그런가? 확인해보니 최근 배포판은 그런 현상은 없었다.

간만에 우분투를 데스크탑 용도로 활용하려고 한다.(주로 서버용으로 많이 썼다.)
맥미니를 쓰면서 더욱 원격으로 사용하게 된다.

놀고(?)있는 컴이 있어서, 데스크탑 용도로 써보기로 하고, 최근 배포판 22.04 를 설치했다.

1. 처음에는 우분투 기본 공유를 써보기로 했다.

이런 메세지가 보이면서 화면이 검정이 된다.

/etc/gdm3/custom.conf

# uncomment
WaylandEnable=false

위 라인을 설정해주고, 재부팅.

접속을 RealVNC 로 접속했는데, 역시나 검정화면

화면 퀄리티를 High 나 Medium 으로 해주면 정상으로 보이긴 한다.

그런데, 느리다. 참고 쓸만한 정도가 아니다. 느리다. 못쓰겠다.

2. 더욱 문제인 것은 재부팅 하면 접속암호가 계속 바뀐다.

키인증 관련 문제인 듯 싶다.(https://askubuntu.com/questions/1396745/21-10-make-screen-share-password-permanent )

설정을 잘 못 했는지, 해결이 되지는 않는다.
이걸 해결해도 느려서 못 쓰겠다.

3. 그래서 고전적인(?) 방법으로 하기로 한다.

x11vnc 를 사용하기로 한다. https://blog.1day1.org/561 예전에 실패한 gdm3 (기본) 를 다시 시도해봤다.
이번에도 동일하다. 접속이 안된다. 그래서 다시 lightdm 으로 해결.

1804 버전 이후로는 저 문제는 해결이 안된다.(나중에 다시 시도해볼지는 모르겠지만...)
점점 우분투가 이상해(?)지는 부분이 있다.

우분투 20.04 에서 기본 패키지로 phpmyadmin 을 설치했다. ( apt install phpmyadmin )
(DB 관리툴은 여러가지가 있지만, 손에 익어서 그런지 phpmyadmin 이 제일 낫다.)

설치 / 설정은 구글링 해보면 잘 나와 있다.(세팅후 접속시 이슈를 정리한다)

그런데, 설정 후 접속해보면 다음처럼 로고까지만 나오고 나오지 않는다.

개발자 도구에 보니 , jquery 등을 불러오지 못한 현상이다.

사실 OOO도메인/phpmyadmin 등으로 접속하면 잘 나오는데, 문제는 phpmyadmin 을 다른 이름으로 바꿀때 나오는 이슈이다.

phpmyadmin / pma 등 자주 쓰는 이름은 무작위 공격에 노출되게 되어 , 가능하면 안쓰는 이름으로 바꿔서 하려고 한다.
즉, OOO도메인/db-secure 등과 같은 자신만의 이름으로 바꾼다.

ln -s /usr/share/phpmyadmin /{nginx-document-root}/db-secure

{nginx-document-root} 는 OOO도메인 을 설정한 위치이다.

저렇게 심볼릭링크만으로 완료되면 좋겠는데, 저렇게 하면 js 파일등이 /db-secure/js/vendor/jquery/jquery.min.js 위치에서 불러와야 하는데, nginx 기본설정으로는 해당위치에 파일을 로딩하지 못한다.
실제 접근하는 주소를 /usr/share/phpmyadmin/js/vendor/jquery/jquery.min.js 가 되도록 설정해줘야 한다.

location /db-secure/ {
    root /usr/share/;
    index index.php index.html index.htm;
    location ~ \.php$ {
        root /usr/share/;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.4-fpm.sock;
        fastcgi_read_timeout 300;   
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
    location ~* ^/db-secure/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
        root /usr/share/;
    }
}

위 설정 후에 systemctl restart nginx 로 설정을 적용한다.

그러나 접속해도 동일한 현상이 발생. js 파일 접속주소가 이상하게 되어 있다.
/usr/share/db-secure/js/vendor/jquery/jquery.min.js 로 접근한다.

다음처럼 해서 해당 경로를 만들어 줬다.

cd /usr/share
ln -s phpmyadmin db-secure

위 설정후에 nginx 를 재시작 하면 다음처럼 정상으로 나온다.

뭔가 설정이 찜찜한 구석이 있지만, 위와 같이 해결.

추후 좀더 깔끔한 설정을 찾으면, 추가 메시지를 남기겠다. 일단 끝.

https 를 사용하는 것은 옵션이 아니라 이젠 필수요소인듯 하다.

명령은 2줄이면 될려나?  

apt install certbot python3-certbot-nginx
certbot --nginx -d {도메인} -d {여러개일때 도메인 추가}

나중에 도메인을 추가하려면 2번째 명령을 -d 옵션 추가해서 다시 해주면 된다.

명령 후 다음과 같은 메시지가 나오면.

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2

2번 즉, http 로 접속하면 https 로 리다이렉트 해준다. (본인의 사례에 따라 1번이 필요하면 1번)

자동으로 cron.d 에도 넣어주어 주기적으로 갱신한다.(즉, 신경쓸 것이 없다)

예전에는 좀 귀찮았던것 같은데, 요즘은 그냥 한줄이면 끝나네.

끝.

ubuntu 22.04 로 업그레이드 후에 기존 autossh 로 설정해놓은 터널링이 안된다.
그래서 확인해보니. autossh 가 실패되었다.

더 확인해보니 ssh 로 접속이 안되고, 암호를 물어본다.

ssh -vvv 로 접속해서 메시지를 확인해봤다.

다음과 같은 메시지가 보인다.

ssh send_pubkey_test no mutual signature algorithm
or
sign_and_send_pubkey: no mutual signature supported

검색해 보니, 보안관련 이슈인듯 싶다.

일단 해결방안은 아래 링크로

https://transang.me/ssh-handshake-is-rejected-with-no-mutual-signature-algorithm-error/

https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

위 방법중 임시방편? 으로 일단 해결해본다.

.ssh/config 에 접속설정을 추가한다.

Host server-nickname
        hostname servername.com
        User root
        Port 2222
        PubkeyAcceptedKeyTypes +ssh-rsa

추천하는 방법은 보안성에 좋은 key 를 재생성해서 사용하는 것 같다.
추후 시간내서 조치해야 겠다.

우분투 데스크탑을 사용하면서, 보통 계속 켜두고 쓴다.

그런데, 왜 그런지, 잠금화면이 마우스는 움직이는데, 키보드가 안 되는 듯 하다. 또한 상단 메뉴등이 클릭이 되지 않는다.

아예 멈춘것은 아닌데, 이상하다. 그래서 ssh 로 접속해보니, 정상적으로 동작하고 있었다.
lock screen 만 이상한 것이다.

이런경우 ssh 로 root 접속한 후 다음 명령을 입력한다. (또는 sudo 명령으로 )

# loginctl unlock-sessions

일단 해결은 했는데, 왜 그런 현상이 발생했는지는 모르겠다.

현상 중 하나가 잠금화면의 암호 입력부분이  마치 키보드의 특정키가 눌린 것처럼  여러개가 눌려져 입력되어 있다는 것이다.
(어디서 이상한 입력이 들어온다? - 해킹?)
위 원인으로 인한 다른 현상은 잠금화면이 되면, 모니터도 잠자기(?) 모드로 가는데, 모니터도 켜져 있다.

좀더 현상을 지켜봐야 겠다. (18.04 등으로 업그레이드를 해야할려나?)

[추가]
현상 재연을 확인했다. 키보드가 로지텍 무선 키보드인데, usb 리시버의 이상인지.
무선키보드 전원 껐다 다시 키면 , 특정문자가 여러개 입력이 되버린다.

켜져있는 상태에서 드라이버 문제인지, 키보드 자체문제인지, 혹은 usb 리시버, 혹은 메인보드 이상 현상으로 인한 문제일 듯 하다.

우선 재부팅 등으로 조치해보고, 추후 키보드 교체 등을 해볼 예정.

우분투 로그인이 안된다.

.xsession-error 파일을 확인해 본다.(계정 폴더에 있다.)

/etc/X11/Xsession.d/99x11-common_start: line 5: /sbin/upstart: No such file or directory

다음과 같은 에러가 보인다.

우분투는 부팅 스크립트 방식을 바꿔왔다. 

system-v 방식 : /etc/init.d , rcX.d 형태의 관리

upstart 방식 : /etc/init/ 안에 부팅 관련 스크립트 관리  ( service OOO restart 형태 관리 )

systemd 방식 : 가장 최근 방식 ( systemctl restart OOO )

설치된 운영체제는 18.04 버전인데, systemd 을 쓰기에 upstart 는 쓰지 않는다.
(16.04 => 18.04 로 업그레이드해서 남아있었던듯 하다)

해결 방법은 upstart 를 제거해준다.

apt purge upstart

다시 GUI 로그인 해보면 될 것이다.

오래된 우분투 버전을 사용하고 있다. (12.04)

서버 자체가 오래되었고, 돌아가고 있는 어플도 레거시라 업그레이드 하기가 애매하다.

그런데 서버를 옮기고 나서 다음과 같은 메시지가 나온다.

[ 2676.415781] mei 0000:00:16.0: unexpected reset.
[ 2706.390158] mei 0000:00:16.0: unexpected reset.
[ 2736.364548] mei 0000:00:16.0: unexpected reset.
[ 2766.338924] mei 0000:00:16.0: unexpected reset.
[ 2796.313317] mei 0000:00:16.0: unexpected reset.
[ 2826.287704] mei 0000:00:16.0: unexpected reset.
[ 2856.262086] mei 0000:00:16.0: unexpected reset.
[ 2886.236475] mei 0000:00:16.0: unexpected reset.

원래부터 나오던 메시지였는지도 불확실 하다.

다음과 같은 장치인데,

# lspci -v |grep -i mei
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
	Kernel modules: mei

MEI 는 Management Engine Interface  라고 한다.

관리 엔진? 인터페이스 장치인듯 싶다. 뭐 하여간 잘 모르겠다.
(참고 : https://www.intel.co.kr/content/www/kr/ko/support/articles/000008927/software/chipset-software.html )

저 메시지가 계속 생겨서 없애고자 한다.

일단 modprobe 로 제거

# modprobe -r mei

# dmesg
mei 0000:00:16.0: PCI INT A disabled

위와 같이 나오고 중지된다.

부팅시 나오지 않게 한다. ( /etc/modprobe.d/blacklist.conf 에 다음 추가 )

blacklist mei

좀더 상태를 살펴보고 이상이 없는지 체크해보고 치명적인 이상이 있으면 추가(없으면 패스)

모니터 연결이 안된 서버에 vnc 접속시 해상도가 1024x768 등 낮게 설정이 된다.

가상의 모니터로 접속할 수 있게 설정해준다.

더미 모니터 패키지를 설치한다.

apt install xserver-xorg-video-dummy

xorg 설정을 해준다. ( /usr/share/X11/xorg.conf.d/xorg.conf )

Section "Device"
    Identifier "DummyDevice"
    Driver "dummy"
    VideoRam 256000
EndSection

Section "Screen"
    Identifier "DummyScreen"
    Device "DummyDevice"
    Monitor "DummyMonitor"
    DefaultDepth 24
    SubSection "Display"
        Depth 24
        Modes "1920x1080_60.0"
    EndSubSection
EndSection

Section "Monitor"
    Identifier "DummyMonitor"
    HorizSync 30-70
    VertRefresh 50-75
    ModeLine "1920x1080" 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +Hsync +Vsync
EndSection

재부팅하면 원하는 해상도로 접속이 된다.

우분투에서 윈도우의 공유폴더를 연결해 사용하고 있다.
그동안 별 이슈 없이 사용했던것 같다.

그런데, 윈도우 업데이트 후에 다음과 같은 에러가 발생하면서 연결이 안된다.

mount error(127): Key has expired

"키가 만료되었습니다" / NT_STATUS_ACCOUNT_DISABLED 등의 메시지가 보일 수도 있다.

mount 할때 guest 계정으로 연결하는데, 윈도우 업데이트 후에 해당 계정설정이 바뀐 듯 하다.

위 그림은 조치한 후에 화면이다.   활성계정 부분이 "예" 로 되어 있어야 하는데, "아니오" 로 되어 있었다.

net user guest /active:yes

로 활성화 해준다.

LG 그램을 사용중이다. 윈도우가 기본 설치가 되어 있지만, 개발에 필요해서 우분투를 설치해서 사용하려 한다.

USB 부팅(설치) 디스크를 만들고 부팅을 시도 했는데. 다음과 같은 에러가 나면서 부팅이 되지 않는다.

Failed to open \EFI\BOOT\NULL - Not Found
Faild to load image \EFI\BOOT\NULL : Not Found
start_image() returned Not Found

위와 같은 에러가 나는 경우. USB 설치 디스크의 해당 위치를 보면

grubx64.efi
mmx64.efi
bootx64.efi

등의 파일이 있는데.

난 grubx64.efi 를 복사해서 NULL 파일로 이름을 바꿔줬다. (NULL.efi 가 아닌 그냥 NULL )

다시 재부팅을 해보니 정상적으로 부팅화면으로 넘어갔다.

ps. 여러가지 그램 바이오스 세팅을 바꾸는 방법이 구글링 하면 나오는데.
난 위 방법으로 했다. (secure boot : disable 등 몇가지는 설정했다.)

사용중인 시스템에 HDD 관련 커널에러가 발생하였다.

보통 여러가지 이유가 많지만, 이런 에러가 생기면 그냥 AS 보낸다.

그런데, 이번에는 디스크 관리를 보니 배드섹터 1 개 라고 나온다. 애매하네...
당장 시스템 교체할 하드가 마땅치 않아, AS 보내기전 잠시라도 계속 사용해야 하는 상황.

배드섹터를 기록(?)해서 에러가 발생하지 않도록 하고자 한다.

커널 에러 메세지는 이런식이다. (에러 종류에 따라 , 메시지가 다르다 )

[348303.307873] ata4: EH complete
[348305.814497] ata4.00: exception Emask 0x0 SAct 0x1000000 SErr 0x0 action 0x0
[348305.814503] ata4.00: irq_stat 0x40000008
[348305.814508] ata4.00: failed command: READ FPDMA QUEUED
[348305.814517] ata4.00: cmd 60/08:c0:78:3b:76/00:00:31:01:00/40 tag 24 ncq 4096 in
                         res 41/40:00:78:3b:76/00:00:31:01:00/40 Emask 0x409 (media error) <F>
[348305.814521] ata4.00: status: { DRDY ERR }
[348305.814524] ata4.00: error: { UNC }
[348305.815611] ata4.00: configured for UDMA/133
[348305.815625] sd 3:0:0:0: [sdc] tag#24 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[348305.815630] sd 3:0:0:0: [sdc] tag#24 Sense Key : Medium Error [current] [descriptor] 
[348305.815635] sd 3:0:0:0: [sdc] tag#24 Add. Sense: Unrecovered read error - auto reallocate failed
[348305.815639] sd 3:0:0:0: [sdc] tag#24 CDB: Read(16) 88 00 00 00 00 01 31 76 3b 78 00 00 00 08 00 00
[348305.815643] blk_update_request: I/O error, dev sdc, sector 5124799352

눈에 띄는 부분은 마지막줄.

blk_update_request: I/O error, dev sdc, sector 5124799352

배드 섹터가 생긴 것으로 보인다(다른 에러로 인해 나오는 경우도 있을 수 있을 듯 하다 - 입출력시 에러이니 다양한 원인이 있을 수 있음)

보통의 절차는 badblocks 로 배드섹터 위치를 찾고, fsck 로 배드섹터 표시를 해서 디스크사용시 해당 섹터를 건드리지 않도록 한다.

badblocks -v /dev/sdc1 > badsectors.txt

위 처럼 배드섹터 위치를 찾는다 ( /dev/sdc1 등은 본인의 HDD 명칭으로 쓰면 된다)
오래걸린다 (디스크 크기가 크면 클수록)
검색 범위를 정할 수 있는지 모르겠다. 2930265542

그 다음은 배드섹터를 파일시스템에 기록(?) 한다.

fsck.ext4 -l badsectors.txt  /dev/sdc1

fsck 명령은 본인의 파일시스템에 맞게 적절하게 바꿔준다. (fsck.ext2 , fsck.ext3 등)

끝.

이게 영구적인 해결방법은 아닐 듯 하다. 배드섹터가 계속 생길 수 있으니, AS 보내기 전까지 버텨보자.

추가

badblocks 가 너무 오래 걸린다. (거의 2시간 넘게 했는데, 반도 못했다. 6시간 넘게 걸릴 듯 하다 - 하드디스크 속도에 따라 차이가 있을 듯 함. 해당 HDD 는 7200 rpm )

badblocks -v /dev/sdc1 > badsectors.txt
Checking blocks 0 to 2930265542
Checking for bad blocks (read-only test): ^C

Interrupted at block 1102688832

block 범위를 정해서 다시 해본다. ( 전체가 5860533168 이다. 대략 배드섹터 위치는 5124799352 )

Disk /dev/sdc: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt

위 처럼 한 블럭이 512 byte ( badblocks 의 기본값은 1024 - 그래서 0 to 2930265542 으로 나옴)
그런데, 512 로 하면 다음과 같은 메시지가 나온다.

badblocks: 정의한 자료형으로 쓰기엔 너무 큰 값 invalid end block (5860531087): must be 32-bit value

기본값 1024 로 해야겠다. 대신 뒤의 블럭을 반으로 나눠서 범위를 정해야 겠다. ( 2562399676 가 된다)
그러고 보니 기본값을 fsck 쪽과도 맞춰야 할까? 파일시스템마다 다를려나? ( 4096 이 기본값인가? 5124799352 x 0.125 = 640599919 이 된다.)

# badblocks -b 4096 -v /dev/sdc1 640600000 640590000 > badsectors.txt
Checking blocks 640590000 to 640600000
Checking for bad blocks (read-only test): done                                                 
Pass completed, 1 bad blocks found. (1/0/0 errors)
# cat badsectors.4096.txt 
640599663

뒤의 숫자는 640599919 의 대략 범위 위치를 {last block} {first block} ( 끝 / 시작 값을 약간 여유 잡고 지정한다 )
실제 블록 위치는 640599663 로 확인된다.

fsck 를 해보니.

# fsck.ext4 -l badsectors.4096.txt /dev/sdc1
e2fsck 1.42.13 (17-May-2015)
/dev/sdc1: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes

Running additional passes to resolve blocks claimed by more than one inode...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in inode 110625949: 640599663
Pass 1C: Scanning directories for inodes with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 1 inodes containing multiply-claimed blocks.)

File { ================== 에러난 파일 =================== } (inode #110625949, mod time Wed Jun 26 16:35:07 2019) 
  has 1 multiply-claimed block(s), shared with 1 file(s):
    <The bad blocks inode> (inode #1, mod time Sat Jul 27 21:54:33 2019)
Clone multiply-claimed blocks<y>? yes
Error reading block 640599663 (Attempt to read block from filesystem resulted in short read).  에러 무시<y>? yes
강제로 덮어쓰기<y>? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create<y>? no
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23517, counted=23516).
Fix<y>? yes
Free blocks count wrong for group #19549 (65535, counted=0).
Fix<y>? yes

/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdc1: ********** WARNING: Filesystem still has errors **********

/dev/sdc1: 36792/183148544 files (0.0% non-contiguous), 632810807/732566385 blocks

위에서 Clone multiply-claimed blocks? yes => 이 부분을 그냥 n 로 건너뛰는게 좋다. 어차피 에러로 복사(clone) 실패 하는 듯 함.

일단 위와 같이 조치했는데, 잘 된 것인지는 좀더 체크해봐야 겠다. ( 특히 block 의 위치가 맞게 처리된 것인지... )

ubuntu 에서 squid3 설정.

- 설정은 간단하다.

- curl 을 이용해 해당 proxy 서버를 사용할때 주의점.

# 설치

apt-get install squid3 
또는
apt install squid

끝. 쉽다.

# 설정

/etc/squid3/squid.conf 을 설정 (다른 위치 : /etc/squid/squid.conf )

(원래 파일은 복사하고, 새로 생성한다)
  => 원래 파일을 주석제거하고 복사하고 싶을때

mv squid.conf squid.conf.old     # backup
cat squid.conf.old | egrep -v '^[[:space:]]*(#.*)?$' > squid.conf

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT

 

# digest

auth_param digest program /usr/lib/squid3/digest_file_auth /etc/squid3/squid3.digest.passwd

auth_param digest realm proxy

acl sq_digest proxy_auth REQUIRED

http_access allow sq_digest

 

# basic

auth_param basic program /usr/lib/squid3/basic_ncsa_auth /etc/squid3/squid3.basic.passwd

auth_param basic realm proxy

acl sq_basic proxy_auth REQUIRED

http_access allow sq_basic

 

cache deny all

 

http_port 4128

 

#http_port 3128

coredump_dir /var/spool/squid3

 

refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
refresh_pattern .               0       20%     4320

 

진한 부분이 추가한 부분이다. 기본파일에는 http_access 관련 설정이 있는데 삭제했다.

# 포트 변경

그리고 추천하는 부분은 기본포트인 3128 을 다른 포트로 바꾸길 권장한다.
언제나 그렇듯이 공격 대상이 될 수 있다. (ssh 도 필수로 바꾸는 것이 좋다. 22 -> 다른 포트)

# 캐시 비활성화

cache deny all 

캐시를 비활성화 했는데, 필요하면 삭제 또는 주석처리한다.

# 인증 모드

인증 모드는 digest 와 basic 이 있는데 설정은 위와 같다. 동시에 써도 되는지는 모르겠다.

암호파일 생성은 htpasswd / htdigest 를 사용한다.

사용법은

htpasswd -c /etc/squid3/squid3.basic.passwd {username}

htdigest -c /etc/squid3/squid3.digest.passwd proxy {username}

암호화는 digest 방식을 추천한다.

모두 설정이 완료되었으면 재시작해서 바뀐 설정을 적용한다.

service squid3 restart

# curl 에서는 다음처럼 사용한다. ( php 기준 설명 )

php curl 은 아쉽게도 digest 모드를 아직 지원안하는 듯 하다.

$proxyserv = '123.123.123.123:4128' ;
$proxyauth = 'username:password';

 

curl_setopt($ch, CURLOPT_PROXY, $proxyserv );

curl_setopt($ch, CURLOPT_PROXYUSERPWD, $proxyauth );

 

위와 같이 써준다.

curl_setopt($ch, CURLOPT_PROXYAUTH, CURLAUTH_DIGEST ); 

위 옵션이 되면 좋겠는데, 아쉽게도 현재는 안된다.( 현재는 CURLAUTH_BASIC , CURLAUTH_NTLM 만 지원)

sublime text 를 쓰던 환경을 그대로 복사하거나 옮길경우

1. 계정폴더의 .config/sublime_text_3 폴더를 그대로 복사하면 된다.

해당 폴더 자체를 dropbox 등으로 동기화를 해도 될 듯 하지만,
충돌 가능성이 있으니 일단 배제.

2. license 파일은 그대로 복사해도 안된다. 다시 키 입력해서 새로 생성한다.

자동실행을 잘 활용하면 편하다.

/etc/cron.d/ 폴더에 해당 스크립트를 복사하는 형태로 관리한다.

/etc/crontab 에 직접관리하는 것 보다 편리하다.

Centos 에서 쓰던 cron 스크립트를 Ubuntu 에 적용하니 cron 이 실행이 안되었다.

이것저것 찾아보던중.

11doSomethingJob.cron  => 이런 형태는 ubuntu 에서 동작을 안한다.

11doSomethingjobCron 이나 11doSomethingjob_cron 은 되는 듯 하다.

Centos 와 다른 부분이 있다.

지난번 icinga 로 모니터링 서버를 만들었다.( http://blog.1day1.org/547 )

그런데, 서버가 자주 죽는다. vagrant 로 구축해서 그런가?

아니면 다른 문제일까? vagrant 에 icinga 만 세팅해놨다. icinga 가 불안한가?

좀더 상황을 지켜봐야 겠다.

그냥 리얼서버에 구축해야 할까?

우분투에서 vino-server 보다 x11vnc 가 나은듯 하다.

x11vnc 를 설치해보자

로 설치해준다.

그리고, xinetd 는 x11vnc 를 자동실행시켜주기 위해 사용한다(취향에 따라 gdm 로그인시 자동실행시켜도 된다.)

/etc/xinetd.d/x11vnc 로 다음 내용을 저장한다.

여기서 조심할 항목은 /etc/x11vnc.passwd 의 암호를 지정하는 것이다.

로 하면 암호를 물어보고, 해당 파일로 저장이 된다.

server_args 부분설명
  -noxdamage :  compiz 상에서 화면갱신등의 성능이 좋지 않는데, 저 옵션을 주면 좋아진다.

  -xkb -repeat  : shift 키가 안먹을때 넣어 준다.

  -auth {xauth} : ps aux | grep auth  명령으로 위치를 찾아준다.

ubuntu 14.04 에서는 위와 같다. lightdm 부분 /var/run/lightdm/root/:0 을 -auth 옵션뒤에 넣어준다.

설정 완료 후에는 xinetd 를 재시작 해준다.

[추가-2020-03-31]

우분투 18.04 에서는 lightdm 대신에 gdm 을 사용한다.(auth 부분이 /run/user/121/gdm/Xauthority 이다 )
특정 시스템의 문제인지 모르겠지만, 로그인 하면 검정화면이 된다.

해결 방법이 있을듯 하지만, 그냥 lightdm 을 설치해서 해결했다.

apt install lightdm

microSD 를 써보려고 하는데, exfat 으로 포맷되어 있다.

기본으로 설치된 ubuntu 에서 인식을 못한다.

우분투 14.04 에서는 공식패키지로 있다.(이전에는 PPA 를 사용했다)

exfat-utils / exfat-fuse 를 설치하면 된다.

재부팅 안해도 바로 인식한다.

관리하는 서버 대수가 많아지다 보니 모니터링이 쉽지 않다.

서버 호스팅 업체를 통한 기본관리도 가능하지만, 부족한 부분이 있고, 여러 호스팅 업체를 사용하다보면 그것도 불편하다

icinga 로 모니터링 서버를 구축해본다.

웹 모니터링 화면을 접속하면 이런식으로 나온다.

관련글 : https://www.digitalocean.com/community/tutorials/how-to-use-icinga-to-monitor-your-servers-and-services-on-ubuntu-14-04

설정은 위 링크를 참조하기로 하고 특이사항 들을 추가한다.

관련 패키지를 설치하면 몇가지 설정단계를 거친다.

1) 처음에는 mysql root 계정 암호를 넣을 것이다. 적당한 암호를 넣는다.

2) 메일 설정 부분

메일 설정을 해준다. 메일로 알람을 받을 때 쓰는 듯 하다.

3) 관리자 화면에 쓸 icingaadmin 계정 설정

관리용 웹화면의 암호를 입력한다.

다음은 그냥 No 로 넘어가고,

4) icinga-idoutils 관련 설정

icinga-idoutils 의 설정 : 모니터링 데이터에 쓰이는 듯 하다.

여기에서는 mysql 을 쓸 것이다.

초기데이터 설정을 위해 관리자 암호를 물어본다(처음에 설정한 값)

icinga-idoutils 가 쓸 mysql 계정암호를 넣는다.

여기까지 기본설정 완료. 추가로 패키지들이 마저 설치된다.

5) 모니터링 관리자 화면 접속.

난 설정을 포트포워딩 해서 http://localhost:8800/icinga/ 으로 접속했다.

아이디는 icingaadmin 이고, 암호는 설정시 입력한 값을 넣는다.

참고로 난 vagrant 로 가상머신을 만들고, icinga 를 세팅했다.
vagrant 로 세팅후 box 의 80포트를 포트포워딩 하고, 부팅시 자동실행하도록 설정했다.

1) 포트포워딩(Vagrantfile)

2) 부팅시 자동실행(vagrant box) : http://blog.1day1.org/543

vagrant up 을 하게 되면 virtualbox 가 시작되면서 가상머신이 부팅하게 된다.

기본 설정은 private network 로 되는 듯 하다.

브리지 모드로 하려면

Vagrantfile 에 다음 항목을 넣어준다.

설정값이 vagrant 버전에 따라 차이가 있는 듯 하다.

위와 같이 옵션을 넣어줘도 되는 듯 하다. ( 구분은 " => 로 하는게 더 쉬워보인다)

비슷하게 포트 포워딩을 하려면 이런식.

# vagrant -v
Vagrant 1.6.3

그냥 config.vm.network "public_network" 부분까지만 넣어주면, 네트웍인터페이스(랜카드) 가 여러개이면 선택하는 화면이 나온다.

=> 매번 선택 해줘야 한다. bridge 옵션으로 network interface 를 정해주면 선택하지 않고 바로 가동할 수 있다.

하위 버전은 아래 명령중 하나로 작동할 듯 함.(아래 설정중 알아서 설정)

vagrant 를 우분투에 세팅해서 사용중이다.

호스트 머신인 우분투를 재부팅할 때 vagrant box 도 재부팅해보자.

방법1) 이건 해보니 안된다. => 실패!!

vi /etc/rc.local 파일에 다음을 추가

=> vagrant box 위치로 가서 vagrant up 을 해주는 간단한 스크립트.
  부팅 실행시 rc.local 이 실행되면서 처리되어야 하는데, 안된다.

  아마도 14.04 가 systemd 인가? upstart 인가? 를 사용해서 rcX.d 의 방식이 안되는 것 같다.

방법2) /etc/init 에 스크립트를 만들어준다. => 성공!!

vi /etc/init/vagrant-centos6.conf  파일을 만들어준다.(파일명은 알아서)

위 스크립트에서 진한부분을 본인의 설정에 맞게 바꿔준다.

재부팅해보면 정상적으로 vagrant box 도 실행되어 있을 것이다.

우분투 14.04 시스템에 btrfs 를 사용하고 있다.

SSD raid 에 LVM 으로 나눠서 쓰고 있다. 일반적인 사용형태보다는 좀 복잡할 것이다.
(물론 아주 특이한 케이스는 아니다)

docker 를 테스트 하던 중.

docker pull 로  이미지 몇개 설치하지 않았는데, 디스크가 꽉차는 현상이 발생했다.
크롬이 비정상 종료되길래 왜 그러지 싶었다. 그냥 아무 생각없이 재부팅하니. 정상부팅되지 않았다.

순간 멘붕.

허걱! 다시 OS를 깔아야 하나. 데이터 만이라도 살려야 하는데.
중요데이터는 Dropbox 로 동기화 하고 있으니 별 상관은 없지만, 또 세팅을 다시하려니 힘이 쭉.

single 모드로 다시 부팅을 해보고 점검을 해봤다.

주요 메시지는

이런식의 메시지가 계속 무한루프 된다. 위 메시지를 검색 해봤는데, 별다른 원인을 못찾겠다.

docker 를 테스트 하던중 용량 관련 메시지 No space left on device  => 디스크 full 일때 나오는 익숙한(?) 메시지
를 봤었다. 그것과 관련이 있을 것 같다.

그러나 시스템 용량은 충분했다. 어떤 다른 이유인것 같다.

docker pull dockerfile/mongodb

등의 명령을 내리면, 이미지를 다운로드하고 컨테이너를 생성한다.

이때 docker 는 btrfs 인 경우 subvolume (스냅샷?) 기능 을 이용하는 것 같다.

/var/lib/docker/btrfs/subvolumes 에 생성이 된다.

을 해보면 아무것도 없어야 한다. 그런데, docker pull 후에 다시 명령을 해보면.

위 처럼 많은 subvolume 이 생성된 것을 볼 수 있다.
ID 값이 동일한 것(진한부분)을 보니 ID 당 서브볼륨을 생성해서 관리하나 보다.

파일용량을 체크해보면 다음과 같다.

서브볼륨은 어느 부분에 영향을 주는지 확인해봐야 겠다.

아무튼.

명령으로 docker 이미지를 삭제하면 해당 subvolume 도 삭제된다.

개별적으로 subvolume 을 삭제하려면

으로 삭제해준다.( 부팅이 안되서 usb 우분투 로 부팅하고, 해당 서브볼륨을 위 처럼 하나씩 삭제해줬다)

btrfs 에 좀더 알기전까지는 조심해야 겠다.

다음부터 docker 는 vagrant 기반의 vm 내에서 테스트 해봐야 겠다.

ubuntu 14.04 의 byobu (screen) 가 ctrl-a 이 안 먹는다.

byobu 를 실행시키고 ctrl-a 를 눌렀을때

다음처럼 화면이 나올때 1/2 아무거나 입력해도 안되고 같은 화면만 나오는 문제가 있다.

직접 콘솔상에서 byobu-ctrl-a 를 해보면.

위처럼 에러가 발생한다.

직접 byobu-ctrl-a 를 수정한다.

120 라인부분을 보면  " => 가 빠져있다.

수정 후 저장하고 다시 해보면 정상동작한다.

저 스크립트는 최종적으로. .byobu/keybindings.tmux 파일에 설정이 저장된다.

에러가 나서 계속 같은 화면이 나왔던 것이다.

docker 를 설치해본다.

우분투 14.04 에서는 간편하다. 이미 우분투 공식패키지로 등록이 되어 있다.

그러나 공식패키지는 버전업이 느리다.

# docker.io --version

빠르게 버전업하는 패키지는 공식사이트의 배포버전을 사용하면 좋다.

한번에 끝내기

위 스크립트를 받아서 실행하는 방법이다.

최신버전으로 설치된다.

간단한 테스트.

다음과 같은 명령을 내리면.. 로컬이미지를 찾고,
없으면 저장소에서 찾아서 설치한 후 echo 'Hello World' 를 실행하게 된다.

하위 버전은 다음을 참조.

http://docs.docker.io.s3-website-us-west-2.amazonaws.com/installation/ubuntulinux/

이전글에서는

http://blog.1day1.org/497

jre 가 필요한 경우에 java8 을 설치했었다.

TI studio 에서 프로젝트 빌드중에 java 8 버전에서 다음과 같은 에러가 나온다

Titanium Studio 는 jdk7 버전이 필요하다.

버전을 낮춰서 설치해준다.

Titanium 첫 프로젝트를 생성하고 실행시켜 본다.

초 간단 앱이 완성된다.

에뮬은 느리기 때문에 폰을 직접 연결해서 사용하는 것이 좋다.

Titanium Studio 가 alloy 를 쓰면서 node 가 기본 패키지로 설치되어야 하는 듯 하다.

으로 먼저 설치가 되어 있고, 관련 npm 관련 추가 설정이 필요하다.

사용자 계정 home 디렉토리가 패키지의 기본위치로 지정한다.

vi .npmrc 파일을 생성해서

본인의 홈 폴더를 지정한다.

npm install 등의 명령으로 설치하면

홈폴더 밑으로  lib , bin 등에 관련 패키지 들이 설치된다.

등이 TI studio 에서 쓰는 패키지들이다.