쿠분투에서 muon 으로 chromium-browser를 설치할 때 모종의 이유로 도중에 멈추면 설정과 파일들이 엉켜서 설치를 재시도할때마다 error status 10 내고 중단됩니다. 이를 muon 패널에서 해결하는게 불가능해 보이구요. 명령어로 처리하면 muon에서 다시 설치 시도를 할 때 성공하게 할 수 있습니다. 아래처럼 입력합니다.
Konsole 에서
|
1 2 3 4 5 6 7 |
$ sudo apt-get autoclean $ sudo apt-get install deborphan $ sudo deborphan | xargs sudo apt-get -y -remove --purge $ sudo snap list $ sudo snap remove chromium |
이렇게 하면 엉킨 파일들이 제거되고 패키지도 삭제되서 muon으로 다시 재설치가 가능해지는 것 같습니다. 다른 원인으로 안되면 해당이 안될 수는 있습니다.
쿠분투 20.04에서 Tomcat 9은 Muon으로 설치해서 잘 작동한다는 전제 하에 설명합니다.
Muon으로 설치하면 Tomcat 9의 CATALINA_HOME 은 /usr/share/tomcat9이고 CATALINA_BASE는 /var/lib/tomcat9 입니다.
우선 NetBeans를 실행해서 Tomcat 9을 등록해주어야 JSP 프로그래밍 프로젝트를 만들수 있습니다.
등록하려면, Tools→Servers 로 가서 Tomcat 9을 등록할 수 있습니다.
Catalina Home 은 /usr/share/tomcat9으로
Catalina Base 는 /var/lib/tomcat9 으로
Use Private Configuration Folder (Catalina Base) 체크 후
기본값으로 설정하면 $CATALINA_BASE/conf/server.xml 과 $CATALINA_BASE/conf/tomcat-users.xml 을 읽지 못한다는 오류가 뜨고 Finish 버튼을 누를 수가 없습니다.
그렇다면, 터미널을 띄워서 아래처럼 입력합니다.
|
1 2 3 4 |
$ sudo chmod +r /etc/tomcat9/server.xml $ sudo chmod +r /etc/tomcat9/tomcat-users.xml |
대부분 이렇게 하면 해결됩니다.
Muon 말고 수동으로 Tomcat 을 설치한 경우 아래 명령어로$CATALINA_HOME과 $CATALINA_BASE를 알아낼 수 있습니다.
|
1 2 3 |
$ ps aux | grep -i catalina |
톰캣 9는 몇가지 설정을 편리하게 하기 위해 기본적으로 관리 툴을 지원합니다. 일단 설치가 되어있다는 전제 하에 해설합니다.
우선 톰캣 9이 잘 실행되어 있다면 기본값으로 했을 때 http://localhost:8080 을 실행하면 문서가 뜨는데 거기에 링크를 누르면Virtual Host Manager와 Web Application Manager 페이지가 뜹니다. 그런데 기본적으로 유저네임과 패스워드가 지정되어 있어야 접근이 되고 그렇지 않은 경우 401 에러 납니다.
이 경우 아래처럼 조치하면 됩니다.
|
1 2 3 |
$ sudo vi /etc/tomcat9/tomcat-users.xml |
여기에 주석달린 것은 그대로 두고 아래 라인을 추가합니다.
|
1 2 3 4 5 |
<role rolename="manager-gui"/> <role rolename="admin-gui"/> <user username="admin" password="admin" roles="manager-gui,admin-gui"/> |
이렇게 저장하고 나와서 아래처럼 톰캣을 재실행합니다.
|
1 2 3 |
$ sudo systemctl restart tomcat9 |
웹브라우저에서 http://localhost:8080/host-manager 와 http://localhost:8080/manager 접근시 위에 설정한 유저네임과 패스워드를 입력하면 연결이 됩니다.
참고로 유저 홈 디렉토리 아래에 있는 디렉토리에서 작업해야 될 때 이 디렉토리를 톰캣이 연결할 수 있게 하려면 Web Application Manager (http://localhost:8080/manager) 에서 아래처럼 하면 됩니다.
다른 것은 안건드려도 되며
Deploy 섹션의 하부 섹션인 Deploy directory or WAR file on server 에서
Context Path: /유저홈디렉토리
WAR or Directory path: /home/유저홈디렉토리/public_html
이렇게 해두고 /home/유저홈디렉토리/public_html 에 작업한 웹파일을 저장하고 웹브라우저에서 http://localhost:8080/유저홈디렉토리/웹파일명 처럼 입력하면 화면에 표시됩니다. 틸데(~)는 입력안해도 됩니다.
우선 타볼이나 집파일을 직접 받아와서 설치하기보다 Muon으로 설치한 이후를 설명합니다.
설치하고나서 시스템 재부팅후 아래 명령어를 쳐봅니다.
|
1 2 3 |
$ sudo systemctl status tomcat9 |
9월 15 12:44:55 pizza-hot tomcat9[1325]: No JDK or JRE found – Please set the JAVA_HOME variable or install the default-jdk package
라고 나오면
|
1 2 3 |
$ ps -ax | grep tomcat |
을 쳐봐도 실행이 안된 상태로 나옵니다.
이 경우 JAVA_HOME 환경변수를 설정해야 하는데 .bashrc나 /etc/environment 같은 파일에 해두기보다 아래 파일에 하면 즉효입니다.
/etc/default/tomcat9
이 파일을 vi로 열어서 JAVA_HOME을 추가합니다.
|
1 2 3 4 |
$ sudo vi /etc/default/tomcat9 JAVA_HOME=/usr/lib/jvm/java-14-openjdk-amd64 |
정확한 디렉토리는 설치한 openjdk 마다 다릅니다. 이를 확인하려면
|
1 2 3 4 5 |
$ cd ~ $ locate openjdk > r $ sudo vi r |
해서 나온 디렉토리 중에 위에 표시한 디렉토리와 같은 패턴의 디렉토리를 찾으면 됩니다.
이렇게 하고나서
|
1 2 3 4 5 |
$ sudo systemctl daemon-reload $ sudo systemctl start tomcat9 $ sudo systemctl status tomcat9 |
이렇게 해서 작동하면 성공입니다.
참고로 이 글에서는 tomcat 9에 집중해서 위와 같은 기술을 했으나, 타 자바 앱이 돌아가려면 .bashrc나 /etc/environment 에도 JAVA_HOME 환경변수를 지정하는 것은 필요합니다. /etc/default/tomcat9은 tomcat 9 에만 적용됩니다.
널리 알려진 상식은 컴퓨터 오작동의 원인으로 후보에 손꼽히는게 와레즈 사용이다. 이를 구체적으로 살펴보자. 왜 그럴까? 왜 와레즈를 쓰면 컴퓨터가 오작동할까?
우선 알려진 것은 와레즈에 숨겨진 보안을 뚫는 백도어 기능이 심어져 있어서 와레즈 설치시 컴퓨터에 백도어를 심어두게 되는 경우다. 이는 설치 후 제거하더라도 시스템 어딘가에 보안 헛점을 놔두게 되서 크랙커가 그 헛점을 이용하면 보안이 뚫리게 된다. 이 백도어를 심는 방식 중의 하나가 튜닝된 와레즈이므로 사용을 금지한다. 업체의 저작권 보호만이 그 이유가 아닌 것이다.
또하나 특수한 이유도 있다. 내 관찰에 의한 것인데, 와레즈가 배포하는 것이 운영체제인 경우 조작된 ISO일 가능성이 있다. ISO로 만들기전 재료가 된 시스템 파일들 중 부속파일에 이상한 처리가 된 경우다. 이상한 처리가 된지는 ISO를 해제해서 일일히 수만가지의 파일을 찾아보지 않는 한 모르는 일이다. 그래서 사용자가 ISO 파일을 다운받아 설치 과정까지 정상적으로 이루어졌으면 그런가보다하고 일이 생겨도 다른 것이 원인처럼 느낀다. 이는 부속파일을 시스템 오작동하게 튜닝해서 원본과 바꾸고 다시 캐비닛 형식으로 압축해서 다시 ISO를 만들면, 그 ISO를 설치한 사용자는 모르는 상태에서 운영체제 설치시에 바꿔진 부속파일이 나중에 오작동 문제를 경험하게 된다. 이 현상이 일어나도 대개는 설치가 잘 되면 잘 되었다고 느끼므로, 원인이라고 느끼지 않는 사이에 컴퓨터가 망가지는 것.
요즘은 클라우드 체제로 저렴하게 앱을 쓸 수 있으므로 와레즈 사용을 권하지 않겠다.
요즘은 PC를 구입하면 프린터를 공짜로 줄 정도로 프린터 가격이 많이 내렸다. 내가 2005년쯤부터 쓰던 캐논 잉크젯 프린터는 본체 가격이 40불 정도로 (3만 2천원) 아주 저렴했다. 잉크도 카트리지가 30불 정도 했던 것 같다.
하지만 저렴한 프린터는 그만큼 성능이 받춰주지 않는다. 포토 인쇄가 되는 점은 있으나, 잉크가 수용성이라 물 묻으면 잘 지워진다. 잉크 카트리지도 저렴하지만 다른 프린터의 삼분의 일 용량밖에 안되서 소모가 빨라 결국 같은 값이거나 더 낸다.
프린터 수명도 짧은 것 같더라. 교체해야 되는 시기가 빠르다.
그래서 아주 프린터에 신경을 쓰지 않는 경우를 제외하고, 전문적인 인쇄를 해야 되는 경우라면, 가격을 좀 더 높혀잡고 제품 선택을 할 필요가 있다. 비싸면 비싼만큼 기능을 한다.
비싼 프린터 중에서 엡슨 제품은 액적을 더 작게 여러 번 뿌릴 수 있어서 예술가들에게 적합하다고 알려져 있다. 그러나 이 경우에도 프린터 헤드가 프린터에 고정된 형태라, 수명 문제가 있을 수도 있다던데, 이것도 잘 살펴보면 좋다.
그리고 전용 잉크의 색료가 무엇인지 (염료? 안료?) 용제에 어떤 성분이 주된 것인지 (잉크가 잘 번지나?) 이것도 문의해서 알고 구입하면 실패가 없을 것이다. 염료인 경우 물에 녹고 입자가 작아서 흡수력이 좋다. 안료인 경우 입자가 커서 피인쇄체 표면에 머무는 입자가 많은데 이 경우 색상 표현에 유리할 때도 있다. 용제 또한 잘 살펴야 물이 묻었을때 안번지는 잉크를 쓸 수 있다.
대개 싼 프린터들은 어느 정도 품질은 보장해도, 세세한 부분에서 낮은 품질이나 성능을 보이게 구성된 경우도 있으므로 잘 분별해서 선택해야 한다.
요즘 잉크젯들은 ecosystem 이라고 해서 제작사에서 리필을 가능하게 해서 출시한 제품들이 많다. 새로 구입한다면 이런 제품을 쓰면 좋다.
IT 업계에서 하드웨어/소프트웨어 개발시 프로젝트에 별명을 붙여 개발이 진행되는데 이때 붙여지는 별명을 코드네임이라고 합니다. CPU에도 코드네임이 붙습니다. 예를 들면 같은 인텔 Core i3 CPU도 발표 시기에 따라 Sandy Bridge니, Ivy Bridge니 하는 다른 코드네임을 갖죠.
보통 CPU가 새롭게 발표되면 경우에 따라 다르지만 대개 마더보드 아키텍처도 새롭게 바뀝니다. 그러면 램 사양도 바뀌고 주변기기를 달아쓰는 인터페이스 사양도 바뀝니다. 일반적으로 일반 사용자들은 CPU가 뭐냐, 램 용량이 몇기가다 이정도로만 판별하는데 사실 CPU가 새로워지면 덩달아 램 사양이 바뀐 경우, 용량만으로는 성능을 정밀하게 나타내지 못합니다. 이는 다른 하드웨어 사양도 마찬가지 입니다.
그래서 CPU만으로 사양을 다 유추할 수 있게 고안된 방법이 CPU 브랜드명과 코드네임을 함께 말하는 방식입니다. 식자들은 CPU 브랜드, 발표 시기, 램 데이터 전송폭, 하드디스크 인터페이스, USB 버전, 그래픽 카드 인터페이스 등등을 따로 말하면 정밀하더라도 번거롭기 때문에, CPU 브랜드와 코드네임으로 소통합니다. 코드네임으로 소통하면 성능을 보다 더 정확하게 유추할 수 있습니다.
즉 “나 인텔 Core i3 Ivy Bridge 쓴다”라고 하면 발표 시기와 다른 부속 하드웨어 사양도 손쉽게 알 수 있죠. 그래서 CPU 코드네임을 알아두면 소통과 판별에 딱 좋습니다.
CPU 브랜드와 코드네임으로 판별하면 좋은 또 다른 점은, CPU가 Core i3여도 한참 전의 출시 제품일 수도 있고, 램이 같은 용량이어도 구식임을 모르고 사는 실수를 방지할 수 있다는 것입니다. 그래서 PC 구입시에도 CPU 브랜드와 코드네임을 살펴보는게 추천됩니다. 똑같이 Core i3이고 램이 4GB로 표시되도 구형인지 아닌지 판별이 쉽게 됩니다.
예외적으로 간간히 발표되는 최고급 사양의 코드네임 아키텍처는 시간이 지나도 성능이 아주 좋아서 여전히 쓰이는 경우가 있긴 합니다.
참고로 CPU는 코드네임에 따라 1세대, 2세대, 3세대, … 처럼도 불립니다.
최신 코드네임을 알려면 위키페디아에서
List of Intel microprocessors
List of AMD microprocessors
이 두 검색어로 검색하면 역대 발표된 양사의 CPU가 리스팅되고 코드네임도 나오니 확인이 편리합니다.
안드로이드는 리눅스 커널에 기반한 플랫폼이다. 플랫폼은 운영체제에 미들웨어, 앱들이 묶인 개념으로 안드로이드는 하드웨어, 커널, 네이티브 라이브러리, HAL, VM, 프레임워크, 공장 초기버전에 번들되는 앱 들로 구성된다. 리눅스가 지원하는 다수의 하드웨어를 지원하고 소스코드가 공개되어 있는 장점을 지닌 플랫폼이다. 커널은 여타 운영체제처럼 자원을 배분하고 메모리 관리를 하는 기능을 담당한다. 그외 작동은 커널 혼자서 이루지는 않으며 위 링크에 나온 계층도에 의해 각각의 요소 성분들이 협력하는 체제다.
하드웨어는 물론 엄밀히 말해 안드로이드의 범용 릴리즈에 포함이 안된다. 하드웨어 제조사가 커스터마이징을 해서 제품으로 출시하면 포함이 된다고 볼 수 있다. 리눅스 커널은 C로 만들어져 있고, 네이티브 라이브러리와 한 집합이 되어 안드로이드가 운용된다. 이들의 커스터마이징을 위해 액세스가 가능한 NDK를 제공한다. 네이티브 라이브러리들은 바이오닉이라는 핵심 런타임을 쓴다. 안드로이드에서 제공하는 하드웨어 추상화 계층(HAL)이 바이오닉에 기반한 예다.
바이오닉은 BSD 라이선스로 만들어진 libc의 확장 구현체로 리눅스에서 쓰이는 glibc를 대체하는 것이다. 네이티브 라이브러리의 차이가 리눅스 배포판과 안드로이드의 차이점이다. 구조적으로는 보다 더 가볍기도 한데, 리눅스 배포판에서 주로 쓰는 glibc 보다 경량으로 되어 있다고 한다. 추가된 기능이나 삭제된 기능은 안드로이드라는 협소한 플랫폼 운용에 대해 필요한 것은 추가하고 불필요한 것은 규모를 줄이거나 삭제했다고 알려져 있다. 시스템 V 방식의 IPC 기능이 제외되었다든지.
위 계층들은 C와 C++로 액세스하지만, 앱 개발자가 만든 앱은 자바로 구현되어 VM에서 돈다. 안드로이드 4.4 까지는 달빅 VM이 쓰였고, 5 이후부터는 보다 더 향상된 ART(Android RunTime)을 쓴다. 저 위 페이지에 가보면 ART에서 잘 도는 앱들은 달빅에서도 잘 돌지만, 그 반대는 아닐 수도 있다는데서 참고할만한 것 같다. 지금 확인은 안했는데 하위 호환성 측면에서 문제가 생긴다는 것인지 모른다. 저기 링크된 문서에서는 404 에러 나는 링크가 있는데 번역 페이지가 없어서인지 지금은 해결된건지 모른다.
달빅은 아주 적은 메모리로도 앱 실행을 하도록 한게 특징이고, ART는 이에 더해 보다 더 향상된 성능을 보여주도록 개발되었다.
지금 읽는 책에서는 달빅과 ART의 차이를 분권에서 다루겠다는데 아쉽다.
안드로이드 플랫폼의 또하나의 계층인 프레임워크는 앱 개발의 일관성과 범용성을 부여한다. 같은 구문으로 개발되어 같은 조건에서는 어느 하드웨어에서 작동하든 문제가 없다. 보통 안드로이드 앱 개발을 한다고 하면 프레임워크의 API를 배우는 것이다. 프레임워크 하단의 계층 제어에 NDK가 쓰인다면 프레임워크는 SDK가 쓰인다.
JNI도 지원하는데, 자바로 작성하다가 C나 C++로 만들어진 모듈이나 애플리케이션이 자바 클래스와 상호작용하게 하는 기술이다.
조금 밀도 높게 구겨넣어 정리했는데 이해는 되실 것이다.
안드로이드는 adb 쉘이라고 해서 전용 쉘이 존재합니다. 개발자 모드를 켜고 크라이언트에서 명령어를 치면 연결이 됩니다. 루팅안하고 실행해도 쉘 진입이 가능하지만 루팅을 곁들이고 연결해서 저장된 su 명령어를 쓰면 리눅스에서 슈퍼유저 권한으로 작업하듯 작업이 됩니다.
방법:
(1) 환경설정에 들어가서 디바이스 정보 메뉴로 들어가 빌드번호 항목을 일곱번 연타한다.
(2) 한단계 상위 환경설정 메뉴로 나와보면 개발자 옵션 메뉴가 추가되어 있다
(3) 개발자 옵션에 들어가서 USB 디버깅을 체크 해준다
(4) 안드로이드 SDK가 설치된 상태에서 adb.exe 바이너리의 위치를 PATH에 설정한다.
기본값일 때 C:\Users\유저네임\AppData\Local\Android\Sdk\platform-tools 일 것이다.
(5) 관리자 권한으로 명령 프롬프트를 실행한다
(6) USB로 안드로이드 기기를 연결한다.
(7) 명령 프롬프트에서 adb devices를 입력하면 기기명이 뜬다.
(8) adb shell 이라고 치면 adb 쉘로 진입한다.
문제 해결:
(1) adb shell 명령어 입력시 device unauthorized. This adb server’s $ADB_VENDOR_KEYS is not set. Try ‘adb kill-server’ if that seems wrong. Otherwise check for a confirmation dialog on your device. 라고 나오고 쉘 진입이 안된다면:
C:\Users\유저네임.android 에 가서 del adbkey* 입력
adb kill-server 입력 후 adb shell을 재차 입력
안드로이드 기기에서 RSA 키 자문 대화상자가 뜨면 확인해줌
daemon이 재시작되고나면 쉘 진입. daemon 재시작후 재자 adb shell 명령어 입력이 필요할 수도 있음.
요약: RSA 인증키를 지우고 adb kill-server 입력을 해야 될 수도 있다
(2) adb 쉘에서 루트 권한이 없이 진입한다:
각 기기에 맞게 루팅을 해줘야 한다. 대개 su 명령어를 주어지게 하는 과정이 필요하다. 삼성 기기의 경우 Odin이라는 프로그램을 써서 간편하게 루팅을 할 수 있다. 루팅하고 adb 쉘에 진입했다면 진입후 su 명령으로 슈퍼유저 권한을 얻는다.
루팅하면 기기가 벽돌될 수도 있고 애프터 서비스도 불가하므로 안쓰게 된 구형 기기에서 실험하기를 추천합니다.
PC 고장은 운영체제 설정, 마더보드 BIOS/펌웨어 비트 변경과 같은 상상을 초월하는 여러 원인들이 조합되서 발생한다. 이는 실력자들이 후배들을 골탕먹이는 용도로도 쓰이는 경우가 있어서 잘 알려진 방법이 아니고 전수되는 방법이라 해결 방법을 맞춤으로 찾기가 애매한 경우가 많다.
그래서 수리 기능사들은 포괄적인 방법을 쓴다. PCI-E 장비가 잘 쓰다가 인식이 안되는 경우, 슬롯에서 장비를 빼내서 두번 운영체제 부팅을 하고나서 장비를 다른 슬롯에 꽂고 재부팅해서 인식되면 마더보드 교체 없이 그대로 쓰게 하고, 그래도 안되면 마더보드를 교체한다든지, 장비를 교체하는 방법이 대표적이다.
이 경우 랜 장치인 경우 운영체제에서 표시하는 장치 명칭에 2 같은 숫자가 붙게 인식이 되는데 이 경우 레지스트리와 시스템 설정을 바꾸면 완벽하게 되기도 한다. (그러나 물론 마더보드에서 망가졌다고 된 PCI-E 슬롯은 작동불능으로 지속되기도 한다)
만약 고약하게 고장이 난 경우 포괄적 방법을 쓰다보면 수리 기능사를 골탕먹이는 방식으로 고장 증상이 나타날 때도 있다. 이는 대부분 BIOS/펌웨어 비트 조합, 운영체제 설정 등이 얽혀 있다. 때로 운영체제 재설치와 같은 포괄적 해결법을 적용하다보면 중간에 중단되는 현상이 계속될 때가 있는데 이 경우 마더보드를 바꿔야 하고, 마더보드가 구형이면 다른 부품도 바꿔야 될 때가 많다. CPU나 램이 대표적이다.
기성품 PC라면, 장비 교체를 할 때 업체에 장비 오더를 해서 바꾼다. 이 경우 잘 찾아보면 일반 사용자도 오더가능한 상점이 찾아지는데 스스로 해보는데 정보가 될듯하다.
때로는 마더보드 부품에 전하를 가해서 살펴보는 경우도 있던데 이는 마더보드 교체를 전체를 안하고 하려는 배려지만 돈이 충분하고 문제가 지속될 가능성이 없으면 그냥 마더보드와 CPU, 램 바꾸는게 간단할 수도 있다.
어떤 경우 수리비를 들여서 고치느니 중고 PC를 구한다는 결정도 하는데, 중고 PC는 마더보드 이상이 있어도 그냥 파는 경우도 있어서 비추천이다. 수리비가 삼사백불이 아닌 이상 수리받는게 좋다.
암튼 고약하게 고장난 PC와 사투를 벌이다보면 상식을 벗어난 현상이 혼란을 줄 때도 있어서 그냥 수리 기능사에게 맡기는게 좋다.
어떤 경우 동시성으로 일어난 일들이 인과적 겹침이 되면 수리 방법에 대한 인식이 틀리는 경우도 있다. 예를 들면 PCI-E 고장일 때 그 부품만 떼어내서 두번 부팅하고나서 다시 끼우고 부팅을 다시하는게 세번의 부팅 과정인데, 이를 해결하려고 모든 부품을 떼어내서 세번 반복하는 등의 해결법을 쓰다보면 똑같이 세번 부팅이지만, 수고는 배가 된다. 이는 전문가들이 모이지 않은 정보 루트를 살펴보면 통용되는 방법이지만, 전문적인 방법을 잘 살펴야 한다. 물론 설정이 겹치면 이런 비전문가들이 하는 방법이 진짜로 일어나기도 하니까 문제가 된다. 고약하게 고장나는 것이 이런 유형도 있다. 전문가들이 하는 방법만 알다보면 시도도 안하는 경우.
이 경우 수리 기능사분들도 다 이해하는 조건이라, 해결을 용이하게 하기 위해서는 포괄적인 방법이 제일 간편하니까 참고하세요.