2018년 5월 31일 목요일

Java/JSP Web Application을 WAR 파일로 만든 후 Tomcat 웹 애플리케이션 서버에 배포하는 법.





Java/JSP Web Application을 WAR 파일로 만든 후 Tomcat 웹 애플리케이션 서버에 배포하는 법.

본 포스팅은 다음 상황에서의 설명이다.
 -. Ubuntu 16.04 LTS 버전
 -. Tomcat 8.0
 -. 톰캣 가상 호스트를 이용해서 joe.iptime.org에 대한 웹 루트를 /home/joe/www/ROOT/로 변경하였다.
    (톰캣 가상 호스트 설정하는 법은 여기를 참조)

Java/JSP로 개발된 웹 애플리케이션을 실제 서버에 배포할때 WAR 파일을 만들어 배포하게 된다. 그런데 톰캣 가상호스트를 만들어 디폴트 웹 root 디렉토리를 /home/joe/www/ROOT/로 변경하였을 경우 WAR 파일을 배포하는 방법에 대한 것이다.

Ubuntu의 경우 Tomcat의 웹 루트(DocumentRoot)는 /var/lib/tomcat8/webapps/ROOT/이다. 따라서 가상호스트를 만들지 않은 상황에서는 WAR 파일을 /var/lib/tomcat8/webapps 폴더로 FTP 등을 이용해서 올리면 자동으로 WAR 파일을 압축을 풀어서 해당 웹 애플리케이션이 배포가 된다. 만일 압축 해제및 배포가 자동으로 되지 않는다면 터미널 창에서 다음과 같이 tomcat을 재시작해 주면 정상적으로 배포가 된다.

# service tomcat8 restart

그런데 가상 호스트를 만들을 때는 WAR 파일을 어디로 올려야 되는가?
/home/joe/www로 WAR 파일을 올려도 WAR 파일이 자동으로 압축해제 및 배포가 되지를 않는다. 톰캣을 재시작해도 마찬가지이다.

/etc/tomcat8/server.xml을 열어보면 unpackWARs="true" autoDeploy="true"로 되어 있음에도 불구하고 /home/joe/www에 WAR 파일을 업로드해도, 혹은 톰캣을 재시작해도 WAR파일이 자동으로 배포가 되지 않는다.

      <Host name="joe.iptime.org"  appBase="/home/joe/www"
            unpackWARs="true" autoDeploy="true">
... 중 략 ...
       </Host>

이런 경우 다른 더 좋은 방법이 있는지 모르겠으나 톰캣의 디폴트 웹 root인 /var/lib/tomcat8/webapps/에 WAR 파일을 업로드하면 자동으로 배포가 이루어진다. 이렇게 압축이 풀려진 해당 디렉토리와 그 하위 디렉토리 및 전체를 가상 호스트를 만든 해당 웹 루트(여기서는 /home/joe/www/ROOT/)에 복사하는 수 밖에는 없다.  Flower.WAR 파일이라고 한다면 이 파일을 /var/lib/tomcat8/webapps/로 업로드하면 이 디렉토리에 Flower라는 새로운 디렉토리가 생성이 되고 그 하위에 개발했던 웹 애플리케이션의 파일과 해당 디렉토리들이 압축이 풀려져 있다. 따라서 다음 명령을 이용해서 가상 호스트의 해당 웹 root로 복사를 하면 정상적으로 웹 애플리케이션이 구동이 된다.

# pwd
/var/lib/tomcat8/webapps
# cp -r ./Flower/* /home/joe/www/

이클립스에서 WAR 파일을 만드는 방법은 해당 프로젝트 위에 마우스 우측 클릭하여 다음 그림과 같이 진행하면 WAR 파일을 얻을수 있다.





2018년 5월 30일 수요일

동일한 서버에서 Apache - Tomcat 연동하기





동일한 서버에서 Apache - Tomcat 연동하기

아래 내용은 다음의 상황에서 진행된 내용이다. apache2와 tomcat8, openjdk-8-jre-headless, openjdk-8-jdk 등이 이미 설치되어 있다고 가정한다.
-. Ubuntu 16.04
-. Apache 2.4
-. Tomcat 8.0

서버에 PHP와 JSP 모두를 개발하고 실행할수 있는 환경을 구축하고자 한다. 이 경우 우선적으로 문제가 되는 것은 apache의 경우는 80포트를 기본으로 사용하고 tomcat의 경우는 8080 포트를 기본으로 사용한다.
따라서 동일 서버상에서 80으로 접속해 오는 경우들에 대해서 상황에 맞게 때로는 apache를 통해 php, html 등을 실행시키고 혹은 tomcat을 통해 jsp를 실행하도록 할려면 Apache와 Tomcat을 연동하도록 해야한다.
그 외에 부하를 분산시키는 등의 잇점들이 있을 것이다. 

우선 다음과 같은 시나리오로 진행될 것이다.
 -. joekog.iptime.org에 대한 apache 가상 호스트를 생성해서 해당 도메인에 대한 php에 대한 웹 서비스를 처리하도록 할 것이다
 -. joekog.iptime.org에 대한 tomcat 가상 호스트를 생성해서 해당 도메인에 대한 jsp 웹 서비스를 처리하도록 할 것이다.
 -. joekog.iptime.org에 대한 apache와 tomcat이 처리할 웹 루트 경로는 /home/joekog/www/ROOT/가 될 것이다.
 -. /home/joekog/www/ROOT/ 아래에 .html, .php, .jsp 파일들이 위치해 있을 것이고 웹브라우저에서 http://joekog.iptime.org로 접속할 때 /home/joekog/www/ROOT/ 아래에 있는 .html, .php, .jsp 파일들이 실행될 것이다. 적절히 apache와 tomcat이 알아서 실행하게 될 것이다.
 -. IpTIME의 DDNS 기능을 이용하여 joekog.iptime.org라는 도메인을 생성해서 위의 내용을 테스트 할 것이다.

이상의 내용을 위해 다음의 내용을 사전에 알고 있어야 한다.
 -. apache 가상 호스트(Virtual Host) 생성하는 법 및 IpTIME DDNS 생성하는 법 : 여기를 참조
 -. tomcat 가상 호스트 생성하는 법 : 여기를 참조

우선 Ubuntu 터미널 창에서 root로 로그인 한 후 apache와 tomcat의 연동을 위한 다음 모듈을 설치한다.

apt-get install libapache2-mod-jk

위의 파일을 설치하면 다음과 같은 경로와 파일이 생성이 된다.

/etc/libapache2-mod-jk/workers.properties

이 파일에서 3가지를 현재의 서버 환경에 맞게 설정해 주면 된다. 나머지는 디폴트 상태로 두면 된다.
 -. tomcat home 디렉토리
 -. java home 디렉토리
 -. 톰캣이 맡아서 처리할 내용을 아파치가 톰캣에게 넘기기 위해 톰캣을 지칭하기 위한 이름

workers.properties를 열어서 아래의 내용을 찾아서 해당하는 환경 정보를 입력해 준다.

workers.tomcat_home=①
workers.java_home=②
worker.list=③

① tomcat 홈 디렉토리를 찾을려면 아래 명령을 실행하면 아래와 같은 정보가 보일 텐데 여기서 CATALINA_HOME의 경로인 /usr/share/tomcat8가 tomcat의 홈 디렉토리 경로가 된다.

/usr/share/tomcat8/bin/version.sh

Using CATALINA_BASE:   /usr/share/tomcat8
Using CATALINA_HOME:   /usr/share/tomcat8
Using CATALINA_TMPDIR: /usr/share/tomcat8/temp
Using JRE_HOME:        /usr
Using CLASSPATH:       /usr/share/tomcat8/bin/bootstrap.jar:/usr/share/tomcat8/bin/tomcat-juli.jar
Server version: Apache Tomcat/8.0.32 (Ubuntu)
Server built:   Sep 27 2017 21:23:18 UTC
Server number:  8.0.32.0
OS Name:        Linux
OS Version:     4.13.0-43-generic
Architecture:   amd64
JVM Version:    1.8.0_171-8u171-b11-0ubuntu0.16.04.1-b11
JVM Vendor:     Oracle Corporation

② java 홈 디렉토리를 찾기위해서는 다음 명령을 실행하면 

find / -name '*-openjdk-*'

/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64
/usr/lib/jvm/java-1.8.0-openjdk-amd64
/usr/lib/jvm/.java-1.8.0-openjdk-amd64.jinfo
/usr/lib/jvm/java-8-openjdk-amd64
/usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64

여기서 /usr/lib/jvm/java-8-openjdk-amd64가 java의 홈 디렉토리이다. cd 명령으로  /usr/lib/jvm/ 이 위치로 가서 ls -l을 해 보면 다음과 같은 정보가 보일 것이다. java-8-openjdk-amd64가 디렉토리임을 알수 있다. 따라서 java 홈 디렉토리는 /usr/lib/jvm/java-8-openjdk-amd64가 되는 것이다.

-rw-r--r--   1 root root 2600  4월 28 03:42 .java-1.8.0-openjdk-amd64.jinfo
lrwxrwxrwx   1 root root   20  4월 28 03:42 java-1.8.0-openjdk-amd64 -> java-8-openjdk-amd64/
drwxr-xr-x   7 root root 4096  5월 11 15:56 java-8-openjdk-amd64/

③은 apache 웹 서버가 톰캣에게 실행을 넘길 때 톰캣을 지칭할 이름이다. 이 이름은 임의로 원하는대로 수정을 하면되는데 기본적으로는 ajp13_worker로 되어 있다. 이 이름을 그대로 사용한다면 여기까지가 workers.properties에 대한 설정 작업은 끝났다. 그러면 다음과 같은 형태가 될 것이다.

workers.tomcat_home=/usr/share/tomcat8
workers.java_home=/usr/lib/jvm/java-8-openjdk-amd64
worker.list=ajp13_worker

그런데 만일 ajp13_worker를 임의의 이름으로 변경한다면 workers.properties에서 ajp13_worker라는 이름도 모두 바꾸어 주어야 한다. 예를 들어 아래에서 ajp13_worker를 임의로 변경한 이름과 동일한 이름으로 고쳐주어야 한다.

worker.ajp13_worker.port=8009 
worker.ajp13_worker.host=localhost ⇒ 톰캣이 설치되어 있는 곳의 IP이다.
worker.ajp13_worker.type=ajp13

이제 apache 가상 호스트를 위한 설정을 할 차례이다. 
/etc/apache2/sites-available으로 이동해서 000-default.conf를 여기서 사용하게 될 도메인 이름으로 복사본을 만들고 필요한 환경설정을 한다. 아래와 같이

cp 000-default.conf  joekog.iptime.org.conf
vi joekog.iptime.org.conf

위 파일을 열어서 아래의 내용을 찾아 위에서 가정했던 해당 정보대로 입력한다.

      9         ServerName joekog.iptime.org 
     10 
     11         ServerAdmin webmaster@localhost
     12         DocumentRoot /home/joekog/www/ROOT

     20         ErrorLog ${APACHE_LOG_DIR}/joekog.iptime.org-error.log
     21         CustomLog ${APACHE_LOG_DIR}/joekog.iptime.org-access.log combined

그리고 이 파일의 끝 부분 </VirtualHost> 위에 다음 내용을 작성해서 jsp에 대해서는 tomcat(위에서 별칭으로 정한 ajp13_worker)이 처리한다는 것을 명시한다.

         JKMount /* ajp13_worker
</VirtualHost>

여기서 JKMount /* ajp13_worker로 표현한 것은 현재의 웹 root(/home/joekog/www/ROOT/) 아래에 있는 모든 파일을 ajp13_worker(톰캣)이 담당하게 된다는 뜻이다.
그런데 이 웹 root상에 .php가 있다면 이 파일도 톰캣이 담당하게 될텐데 톰캣은 php를 실행할수가 없게 된다. 따라서 php 소스 자체를 웹 브라우저에 출력하게 될 것이다.
그런데 만일 JKMount /*.jsp ajp13_worker로 한다면 .jsp 파일만 톰캣이 맡고 나머지는 아파치가 실행하게 되므로 동일 웹 루트상에 .php가 있더라도 정상적으로 php를 실행한 결과를 보여주게 될 것이다.
그런데 문제는 JKMount /*.jsp ajp13_worker 이렇게 하게되면 .jsp, .php, .html이 정상적으로 실행이 되지만 Java Servlet은 이 상태에서는 실행할수 없게 된다.
따라서 jsp와 php가 같은 경로상에서 실행되어야 할 경우는 없을 것이므로 JKMount /* ajp13_worker로 설정해서 .jsp와 Java Servlet도 정상적으로 실행되게 설정하면 될것이다.
참고로 Java Servlet의 .class 파일이 위치하는 경로는 웹 root 아래 /WEB-INF/classes/해당패키지명/ 아래에 위치하게 된다. 만일 해당 서블릿의 패키지 명이 com.joe.test라고 한다면 /WEB-INF/classes/com/joe/test/ 이 위치에 *.class 파일이 위치하게 될 것이다.

다음으로 할 것은 apache의 가상 호스트 설정에 대한 설정을 해 주어야 한다. 

vi /etc/apache2/apache2.conf

아래 파일을 열어서 다음 내용을 추가해 준다.

    182 <Directory /home/joekog/www/ROOT/>
    183         Options FollowSymLinks
    184         AllowOverride None
    185         Require all granted 
    186 </Directory>

이제 톰캣에 대한 설정을 할 차례이다. 아래 파일을 열어서

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> 이 부분이 주석되어 있다면 주석을 해제하고 내용이 없다면 이 내용을 추가해준다.

/etc/tomcat8/server.xml

이상을 작업을 하면 apache와 톰캣에서의 연동을 위한 설정은 끝이 났다. 그런데 여기서 우리는 joekog.iptime.org/joe.php라는 도메인으로 접속시 apahce를 통해 /home/joekog/www/ROOT/ 이 경로에 있는 joe.php를 실행할 것이고 동일하게  joekog.iptime.org/hi.jsp로 접속시에는 tomcat을 통해서 /home/joekog/www/ROOT/ 이 경로에 있는 hi.jsp를 실행해야 하므로 아파치 뿐만 아니라 톰캣에 대해서도 가상 호스트(Virtual Host)를 설정해 주어야 한다. 위의 server.xml을 열어서 아래 내용을 기존에 있던 <Host name... </Host> 아래 적당한 곳에 추가해 준다.

    161       <Host name="joekog.iptime.org"  appBase="/home/joekog/www"
    162             unpackWARs="true" autoDeploy="true">
    163 
    164         <!-- SingleSignOn valve, share authentication between web applications
    165              Documentation at: /docs/config/valve.html -->
    166         <!--
    167         <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
    168         -->
    169 
    170         <!-- Access log processes all example.
    171              Documentation at: /docs/config/valve.html
    172              Note: The pattern used is equivalent to using pattern="common" -->
    173         <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
    174                prefix="joekog.iptime.org_access_log" suffix=".txt"
    175                pattern="%h %l %u %t &quot;%r&quot; %s %b" />
    176       </Host>

이제 아파치와 톰캣을 재시작한다.

service apache2 restart
service tomcat8 restart

그리고 /home/joekog/www/ROOT/ 이 경로에 index.html, hi.jsp, joe.php 파일을 적당한 내용으로 작성해서 웹 브라우저에서 접속해 본다.

http://joekog.iptime.org/hi.jsp
http://joekog.iptime.org/joe.php
http://joekog.iptime.org/index.html

이제 톰캣의 기본 포트인 8080 없이 웹 브라우저에서 접속해서 필요를 따라 혹은 apache 혹은 tomcat이 실행되어 위의 3종류의 파일이 정상적으로 실행되고 웹 브라우저에서 보이게 될 것이다.
Apache - Tomcat의 연동과 Apache Virtual Host, Tomcat Virtual Host 등이 같이 엮이어 돌아가야 되는 상황이라 사실상 처음 하는 사람에게는 많이 복잡한 내용이다.
이상으로 아파치 톰캣 연동을 마무리하게 되었다. 휴~;;;

2018년 5월 29일 화요일

Tomcat 가상 호스트(Virtual Host) 구축 방법





Tomcat 가상 호스트(Virtual Host) 구축 방법

서버에 tomcat이 설치되어 있을 경우 Java/JSP를 이용한 웹서비스를 개발할 때도 apache의 경우와 같이 하나의 서버에 여러개의 도메인으로 접속시 각각의 해당 웹 서비스가 실행되도록 가상 호스트를 만들수 있다.

Ubutnu 16.04, Tomcat 8.0의 상황에서 다음 경로에 있는 server.xml을 가상 호스트 환경으로 변경해 준다.

vi /etc/tomcat8/server.xml

위의 파일을 열어 보면 다음과 같은 내용이 있을 것이다.

    128       <Host name="localhost"  appBase="webapps"
    129             unpackWARs="true" autoDeploy="true">
    130 
    131         <!-- SingleSignOn valve, share authentication between web applications
    132              Documentation at: /docs/config/valve.html -->
    133         <!--
    134         <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
    135         -->
    136 
    137         <!-- Access log processes all example.
    138              Documentation at: /docs/config/valve.html
    139              Note: The pattern used is equivalent to using pattern="common" -->
    140         <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
    141                prefix="localhost_access_log" suffix=".txt"
    142                pattern="%h %l %u %t &quot;%r&quot; %s %b" />
    143       </Host>

이 상황에서 2개의 도메인에 대한 가상 호스트를 만들기로 해 본다.
joekog.iptime.org 
fullstack.iptime.org
이상의 2개의 도메인으로 동일 서버(Ubuntu 16.04, Tomcat 8이 설치된 서버)로 접속해 돌 때
joekog.iptime.org  ⇒ /home/joekog/www의 웹 서비스가 실행되고
fullstack.iptime.org  ⇒ /home/fullstack/www의 웹 서비스가 실행되도록 Tomcat virtual host(톰캣 가상호스트)를 설정해 보고자 한다.

위에서 열었던 server.xml의 위의 <Host name... 아랫쪽에 아래와 같이 도메인 관련정보를 추가해 준다.

    145       <Host name="joekog.iptime.org"  appBase="/home/joekog/www"
    146             unpackWARs="true" autoDeploy="true">
    147 
    148         <!-- SingleSignOn valve, share authentication between web applications
    149              Documentation at: /docs/config/valve.html -->
    150         <!--
    151         <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
    152         -->
    153 
    154         <!-- Access log processes all example.
    155              Documentation at: /docs/config/valve.html
    156              Note: The pattern used is equivalent to using pattern="common" -->
    157         <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
    158                prefix="joekog.iptime.org_access_log" suffix=".txt"
    159                pattern="%h %l %u %t &quot;%r&quot; %s %b" />
    160       </Host>
    161 
    162       <Host name="fullstack.iptime.org"  appBase="/home/fullstack/www"
    163             unpackWARs="true" autoDeploy="true">
    164 
    165         <!-- SingleSignOn valve, share authentication between web applications
    166              Documentation at: /docs/config/valve.html -->
    167         <!--
    168         <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
    169         -->
    170 
    171         <!-- Access log processes all example.
    172              Documentation at: /docs/config/valve.html
    173              Note: The pattern used is equivalent to using pattern="common" -->
    174         <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
    175                prefix="fullstack.iptime.org_access_log" suffix=".txt"
    176                pattern="%h %l %u %t &quot;%r&quot; %s %b" />
    177       </Host>


위 파일을 저장한 후 tomcat을 재시작한다.

service tomcat8 restart

이제 각각의 경로에 해당하는 웹 서비스를 구현하면 된다.

joekog.iptime.org를 위해 joekog에 대한 사용자를 아래와 같이 추가해 준다.

adduser joekog

위의 사용자를 추가하고 나면 /home/joekog라는 디렉토리가 생성되었을 것이다. 이후 아래 디렉토리 경로를 생성해 준다.

/home/joekog/www/ROOT/

이때 주의할 것은 server.xml에 appBase="/home/joekog/www"와 같이 설정되어 있지만 기본적으로 tomcat은 이 경로 아래의 ROOT를 웹의 루트 디렉토리로 인식하기 때문에 index.jsp와 같은 파일을 /home/joekog/www/index.jsp와 같이 위치시키면 파일을 찾을수 없다는 에러를 발생시킨다. 반드시 ROOT 디렉토리를 생성 후 /home/joekog/www/ROOT/index.jsp와 같이 웹 서비스 실행 파일을 위치시켜야 한다.

이제 웹 브라우저에서 http://joekog.iptime.org:8080/index.jsp로 접속하면 정상적으로 실행이 된다.
fullstack.iptime.org에 대한 것도 동일한 방법으로 테스트해 볼수 있다.

사용자 추가, IpTIME에서의 DDNS 설정 및 apache에 대한 가상 호스트 구축 방법은 아래 링크를 참조한다.

2018년 5월 28일 월요일

원격 IP로 MySQL(MariaDB)에 접속이 되지 않을 때의 해법





원격 IP로 MySQL(MariaDB)에 접속이 되지 않을 때의 해법

※ Ubuntu 16.04 MariaDb 10.0의 상황과 원격 IP의 주소가 111.222.33.44라고 가정한다.

Java에서 다음과 같이 원격의 MySQL에 접속을 시도할때

String url = "jdbc:mysql://111.222.33.44:3306/나의DB명";

Connection refused 에러가 발생하거나 telnet을 이용해서 MySQL이 설치된 IP의 3306포트로 접속시 연결이 되지 않을 때의 해법이다.
네트워크의 연결 상태에따라 다양한 이유가 있을 수 있다. 예를들어 공유기 아래 서버가 물려있을 때 공유기에서 3306에 대한 포트 포워딩이 되어있지 않다면 아래의 방법이 통할수 없을 것이다.
다양한 원인들이 있으나 본 포스트는 3306 포트에 listening이 외부 IP로 설정되지 않고 127.0.0.1로 설정되어 있을 경우에 대한 해법이다.

telnet을 이용해서 해당 IP로 3306포트로 접속이 되는지부터 확인해보자.
일단 Windows에서는 기본적으로 telnet을 사용할수 없는 상태로 설정되어 있다. 다음과 같이 하여 telnet을 사용할수 있도록 변경한다.

제어판 - 프로그램 제거 또는 변경 - Windows 기능 켜기/끄기 - 텔넷 클라이언트 체크

MS-DOS 창에서 telent으로 다음과 같이 먼저 확인해 본다.

telnet 111.222.33.44 3306
연결 대상 111.222.33.44...호스트에 연결할 수 없습니다. 포트 3306: 연결하지 못했습니다.

SQLyog에서 접속시도해 보면 다음과 같은 에러가 발생한다.

오류 번호 2003 Can't connect to MySQL server on '111.222.33.44'

이럴 경우 MySQL이 외부 IP의 3306포트로 접속이 가능하지 않은 상태이다. 
아래와 같이 자기 자신의 IP(여기서는 111.222.33.44)로 3306 포트로 접속시 접속을 시도했을 때 접속이 되지 않는다면 외부 IP에서 3306포트로 접속이 가능하지 않은 상태라는 뜻이다.

물론 아래의 접속으로 접속이 되기 위해서는 사전에 아래 명령어에 의해서 root가 외부 IP로 접속할수 있는 권한 설정이 mysql 데이터베이스에 설정 되어 있어야 하는 걸 전제로 한다.

MariaDB [(none)]> grant all privileges on *.* to 'root'@'%' identified by '비번';
MariaDB [(none)]> flush privileges;

만일 위와 같이 root가 외부 IP로의 자유로운 접속이 허락되어 있지 않으면 아래의 명령으로 접속이 안되는 건 당연한 일이다.
다음과 같이 MySQL에서는 권한 설정이 아래와 같이 정상적으로 되어 있다고 가정해 보자.

MariaDB [(none)]> use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [mysql]> select host, user, password from user;
+-----------+------+-------------------------------------------+
| host      | user | password                                  |
+-----------+------+-------------------------------------------+
| localhost | root | *8EA3CE4E6710007B6FD72BC385D48F3D985FD258 |
| %         | joe  | *8EA3CE4E6710007B6FD72BC385D48F3D985FD258 |
%         | root | *8EA3CE4E6710007B6FD72BC385D48F3D985FD258 |
+-----------+------+-------------------------------------------+
3 rows in set (0.00 sec)

MariaDB [mysql]> select host, user, db from db;
+------+------+-------+
| host | user | db    |
+------+------+-------+
| %    | joe  | mysql |
+------+------+-------+
1 row in set (0.00 sec)

일단 여기서는 root에 대한 외부 IP로의 접속 권한이 설정되어 있다는 걸 전제로 했을 때 아래와 같이 접속이 안된다면 현재 MySQL(MariaDB)는 외부 IP로의 접속을 위한 설정에 문제가 있다는 것이다.

root@xxx:/home/joe# mysql -h 111.222.33.44 -P 3306 -uroot -p
Enter password: 

이 경우 다음과 같은 에러가 발생한다.

ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.0.107' (111 "Connection refused")

이상과 같이 정상적으로 외부 IP로의 접속이 허용되어 있음에도 접속 불능사태가 발생한다면 다음 명령으로 3306 포트에 대해 listening 상태를 확인해 보자.

# netstat -ntlp | grep 3306
을 하면 

tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1235/mysqld

이렇게 나오면 localhost에서는 접속이 되지만 원격 IP에서는 접속이 안된다.

이 문제에 대한 해법은 아래 파일에서
/etc/mysql/mariadb.conf.d/50-server.cnf
  
bind-address            = 127.0.0.1 를 주석처리하고
bind-address   = 0.0.0.0 을 추가한다. 다음과 같이

#bind-address            = 127.0.0.1 
bind-address   = 0.0.0.0

변경된 사항을 적용하기 위해서 
# service mysql restart
를 하면된다고 검색해 보면 나와있는데 이 방법으로는 netstat으로 확인해보면 여전히 3306에 대한 listening을 127.0.0.1로되어 있다.
현재 가장 확실한 방법은 서버를 재부팅하면 변경된 설정 값이 제대로 적용이되고 외부 IP로 접속이 정상적으로 된다.
재부팅 없이 되는 방법을 아직은 모르겠다....;;;

2018년 5월 22일 화요일

구축된 WordPress 홈페이지의 IP 주소 변경시 접속이 안되는 문제





WordPress로 홈페지를 구축했다가 구축당시의 IP가 변경될 경우 해당 WordPress 홈페이지는 웹브라우저에서 열리지를 않는다.
이때에는 WordPress의 환경 설정 값을 새로 바뀐 IP로 변경해 주어야 한다.
다음과 같은 환경이라고 가정해 보자.

ㆍ 노트북 PC Windows 10에 VirtualBox로 Ubuntu 16.04를 설치하고 여기에 WordPress로 홈페이지를 만듦

ㆍ VirtualBox의 Ubuntu에 있는 WordPress 접속 IP가 다음과 같다.
   http://192.168.0.10/wordpress

ㆍ노트북 PC를 다른 장소로 옮김으로 인해 VirtualBox의 Ubuntu IP가 다음과 같이 변경되었다.
   192.168.89.105
   이때 http://192.168.89.105/wordpress로 접속하면 해당 홈페이지가 열리지 않는다.

이 문제의 해법은 몇 가지가 있는데

(1) wp-config.php 설정 값 조정을 통해
WordPress가 설치된 경로에서 wp-config.php 파일을 열어 다음의 내용을 변경해준다. 만일 다음 내용이 없으면 해당 파일의 적당한 곳에 다음 내용을 추가해 준다.

    define('WP_HOME', 'http://192.168.89.105/wordpress');
    define('WP_SITEURL', 'http://192.168.89.105/wordpress');

(2) WordPress에서 사용하는 Database 설정 값 조정을 통해
WordPress가 사용하는 Database(여기서는 MariaDB)에 접속해서 관련 정보의 변경을 통해서 문제를 해결할수 있다.
여기서는 WordPress 홈페이지가 사용하는 Database 명이 mywp2라고 가정한다.

root@....# mysql -uroot -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 55
Server version: 10.0.34-MariaDB-0ubuntu0.16.04.1 Ubuntu 16.04

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> use mywp2
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

WordPress 홈페이지가 사용하는 데이터베이스 mywp2에서 변경작업을 해야 할 table은 wp_options 테이블이다. 이 테이블의 구조를 보면 다음과 같다.

MariaDB [mywp2]> desc wp_options;
+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| option_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
option_name  | varchar(191)        | NO   | UNI |         |                |
option_value | longtext            | NO   |     | NULL    |                |
| autoload     | varchar(20)         | NO   |     | yes     |                |
+--------------+---------------------+------+-----+---------+----------------+
4 rows in set (0.00 sec)

이 테이블에서 option_name 필드의 값이 home인 레코드와 option_name 필드의 값이 siteurl을 값으로 갖는 레코드가 있는데 그 2 레코드의 option_value의 값을 새로 바뀐 IP주소로 변경해 주어야 한다.
즉 wp_options라는 테이블에서 option_name필드의 값이 home인 레코드와 siteurl인 레코드의 option_value 필드에 해당 홈페지의 IP 주소 값이 설정되어 있다.
이 2 레코드의 값을 새로 변경된 IP 주소로 update해 주면 된다.  먼저 현재 어떤 값이 들어 있는지 확인해 본다.

MariaDB [mywp2]> select * from wp_options where option_name='home';
+-----------+-------------+--------------------------------+----------+
| option_id | option_name | option_value                   | autoload |
+-----------+-------------+--------------------------------+----------+
|         2 | home        | http://192.168.0.10/wordpress | yes      |
+-----------+-------------+--------------------------------+----------+
1 row in set (0.00 sec)

MariaDB [mywp2]> select * from wp_options where option_name='siteurl';
+-----------+-------------+--------------------------------+----------+
| option_id | option_name | option_value                   | autoload |
+-----------+-------------+--------------------------------+----------+
|         1 | siteurl     | http://192.168.0.10/wordpress | yes      |
+-----------+-------------+--------------------------------+----------+
1 row in set (0.00 sec)

위와 같은 값을 가지고 있을 것이고 저 IP는 변경되기 이전의 IP 주소가 될 것이다.
저 두 값을 새롭게 변경된 IP로 update해 주는 것이다.
참고로 위에서 2개의 SQL 쿼리로 해당 정보를 확인했는 아래와 같이해도 동일한 결과가 나온다.

MariaDB [mywp2]> select * from wp_options where option_name in ('siteurl', 'home');
+-----------+-------------+--------------------------------+----------+
| option_id | option_name | option_value                   | autoload |
+-----------+-------------+--------------------------------+----------+
|         2 | home        | http://192.168.0.10/wordpress | yes      |
|         1 | siteurl     | http://192.168.0.10/wordpress | yes      |
+-----------+-------------+--------------------------------+----------+
2 rows in set (0.00 sec)

이제 새롭게 바뀐 IP로 변경해 주도록 하자.

MariaDB [mywp2]> update wp_options set option_value='http://192.168.89.105/wordpress' where option_name='home';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1  Changed: 0  Warnings: 0

MariaDB [mywp2]> update wp_options set option_value='http://192.168.89.105/wordpress' where option_name='siteurl';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1  Changed: 0  Warnings: 0

WordPress 홈페이지의 IP 주소가 정상적으로 변경되었는지 확인해 보도록 하자.

MariaDB [mywp2]> select * from wp_options where option_name in('siteurl', 'home');
+-----------+-------------+--------------------------------+----------+
| option_id | option_name | option_value                   | autoload |
+-----------+-------------+--------------------------------+----------+
|         2 | home        | http://192.168.89.105/wordpress | yes      |
|         1 | siteurl     | http://192.168.89.105/wordpress | yes      |
+-----------+-------------+--------------------------------+----------+
2 rows in set (0.00 sec)

이후부터는 변경 된 IP 주소로 WordPress 홈페이지가 정상적으로 잘 접속이 될 것이다. 아래와 같이 변경된 IP로 WordPress 홈페이지에 접속해 본다.

http://192.168.89.105/wordpress 

2018년 5월 18일 금요일

Ubuntu 16.04에서 SFTP 접속 포트 변경하기





Ubuntu 16.04에서 SFTP 접속 포트 변경하기

SFTP(Secure File Transfer Protocol)의 디폴트 접속 포트는 22번이다. SFTP는 SSH 접속시 사용하는 포트를 사용하므로 SSH의 설정 값에서 원하는 포트를 변경하는 작업을 하면된다.

Ubuntu의 경우 아래 경로의 파일에서 접속 포트의 설정 값을 변경할수 있다. vi로 아래 파일을 연다.
만일 /etc/ssh/ 경로에서 sshd_config 파일이 보이지 않는다면, 즉 ssh_config는 있는데 sshd_config 파일이 없다면 아래 패키지를 설치해 주어야 한다.

apt-get install openssh-server

vi /etc/ssh/sshd_config

파일을 열어보면 다음 항목이 있을 것이다.

Port 22

이 항목의 값을 원하는 숫자로 설정하고 파일을 저장한다.
변경된 내용을 적용하기 위해서 ssh를 재시작해 준다.

# service ssh restart

이제부터 FileZilla의 SFTP로 접속시 포트 번호를 변경된 값으로 서버로 접속이 가능해진다.
동시에 PuTTY를 이용해서 SSH 접속시에도 포트 번호는 여기서 변경한 값으로 접속해야 된다.

Ubuntu 16.04에서 vsftpd를 이용하여 FTP 접속 포트 변경하기





Ubuntu 16.04에서 vsftpd를 이용하여 FTP 접속 포트 변경하기

FTP의 디폴트 접속 포트는 21번이다. FTP 자체가 보안상 약점이 있는데 포트 번호가 21이라는 것까지 기본적으로 알려진 정보이다 보니 FTP의 기본 포트 21번을 다른 포트로 변경하는 작업은 보안상의 기본적인 작업이 되겠다. 물론 FTP보다는 SFTP를 사용해야겠지만 아무튼...

전제조건으로 vsftpd가 설치되어있다고 가정한다. 만일 설치되지 않았다면

# apt-get install vsftpd로 해당 패키지를 설치해야 한다.

Ubuntu의 경우 vsftpd의 환경 설정 파일은 아래 경로에 있다. 이를 vi로 열어서 특정 설정 값을 변경한다.

vi /etc/vsftpd.conf

파일을 열어보면 listen=NO라는 항목이 있을텐데 그 아랫쪽에 다음 내용을 추가해 준다.

listen_port=1234 (원하는 포트 번호로 설정)

이때 listen=YES로 하면 FTP 접속이 되지않는다. listen의 값은 NO로 해두어야 한다.
이상의 작업이 끝났으면 파일을 저장하고 vsftpd를 재실행해 준다.

# service vsftpd restart

이제부터 FTP 접속은 21이 아닌 1234로 접속이 가능해 진다.

WordPress Plugin 설치시 Could not create directory라는 에러에 대한 손쉬운 해법





WordPress Plugin 설치시 Could not create directory라는 에러에 대한 손쉬운 해법

리눅스 Ubuntu에 WordPress를 설치하고 원하는 플로그인을 설치하다보면 Could not create directory라는 에러가 발생하면 플로그인 설치가 실패하는 경우를 종종 보게된다.

이 문제는 디렉토리의 권한 문제 때문에 발생하는 현상이다. 즉 플러그인을 설치하기 위해서 기존의 wordpress 디렉토리 안에 새로운 디렉토리나 파일을 생성해야 하는 경우가 있는데 새로운 디렉토리나 파일을 생성할 권한이 없기 때문에 발생하는 현상이다.

Wordpress를 최초 설치하면 wordpress라는 디렉토리가 생기고 이 안에 필요한 파일들이 생성이 되는데 문제는 wordpress라는 디렉토리의 소유권자가 다음과 같이 되어있다.

drwxr-xr-x  5 nobody        nogroup          4096  5월 18 13:21 wordpress/

해석해 보면
d(첫 번째 자리) : wordpress가 디렉토리라는 뜻
rwx(2~4번째 자리) : 소유자는 r(읽기), w(쓰기), x(실행)을 모두 할수 있다는 뜻
r-x(5~7번째 자리) : 그룹 사용자는 r, x만 가능하다는 뜻
r-x(8~10번째 자리) : 그외 모든 일반 사용자는 r, x만 가능하다는 뜻.

그런데 wordpress라는 디렉토리 안에 새로운 디렉토리나 파일을 생성할수 있는 권한은 이 디렉토리에 대한 소유자인 nobody라야 가능한 것이다. 그룹 사용자는 nogroup이고 이 또한 w 권한이 없으므로 어떠한 디렉토리나 파일도 wordpress 디렉토리 안에 생성할수가 없다. 따라서 현 상태에서는 WordPress의 플러그인 설치시 Could not create directory라는 에러가 발생할 수 밖에 없다.
이 경우 제일 손쉬운 방법은 디렉토리의 권한을 777로 설정해주면 간단히 해결이 된다. 그러나 이것은 보안상 심각한 설정법이므로 곤란하다.

여기서 중요한 개념을 알아야한다. 서버에서 웹 서비스의 소유권자는 누구인가하는 것이다.
즉 WordPress를 실행하는 소유권자가 누구냐 하는 것이다. Ubuntu의 경우 기본적으로 웹 서비스를 실행하는 소유권자는 로그인한 계정의 사용자도 아니고 Ubuntu 시스템이 설정한 웹 서비스를 실행하는 소유권자는 www-data이다.
따라서 wordpress라는 디렉토리의 소유권자를 www-data로 지정해 주면 소유자의 권한이 rwx이므로 WordPress 플러그인 추가에 아무런 문제가 없다.
그룹 사용자 또한 www-data로 지정해 주면 일단 WordPress 플러그인 문제나 테마, 파일 업로드 등에서 아무런 문제가 없다.
chown 명령을 사용해서 해당 디렉토리의 소유권을 변경한다.
chown의 사용법은 다음과 같다.

chown 사용자명:그룹사용자명 대상

chown -R www-data:www-data /home/joe/www/wordpress/

참고적으로 여기서 -R은 Recursive를 의미하는데 적용할 디렉토리의 모든 하위 디렉토리와 파일들에도 모두 적용하겠다는 뜻이다.
따라서 위의 명령을 해석해 보면 /home/joe/www/wordpress라는 디렉토리의 모든 하위 디렉토리까지를 포함해서 소유자는 www-data로 변경하고 해당 디렉토리의 그룹 사용자도 www-data로 변경한다는 뜻이다. 이 작업을 하게 되면 다음과 같이 바뀌게된다.

drwxr-xr-x  5 www-data        www-data          4096  5월 18 13:21 wordpress/

사용자(www-data)의 권한은 rwx이므로 플러그인 설치시 새로운 디렉토리나 파일의 생성에 아무런 문제가 없다.
그런데 이렇게만 설정을 한다면 FTP 사용시 문제가 발생한다.

FTP(SFTP)의 로그인 계정이 adduser로 등록한 joe라는 사용자로 로그인했다고 할 경우 joe는 wordpress 디렉토리의 사용자(user)도 아니고 group user도 아니고 others에 해당된다(user-group-others). 따라서 wordpress의 권한이 rwxr-xr-x이므로 others가 할수 있는 것은 r-x뿐이므로 FTP로 파일 업로드가 불가능하다.
따라서 FTP 업로드도 문제가 없게 할려면 다음 2가지 방법으로 해결하는 방법을 취할수 있다(더 좋은 방법이 있을수 있겠지만 골치 아프니 이정도 수준으로...).

(1) wordpress 디렉토리의 소유자는 joe로 설정하고 그룹 사용자는 www-data로 설정한후
(2) 해당 디렉토리의 권한을 775(rwxrwxr-x)로 지정하게 되면 웹 서비스의 소유자인 www-data에게 rwx의 권한이 주어지므로 플러그인 설치 등의 작업에 문제 없을뿐 아니라 FTP 로그인을 joe로 로그인 했을 경우 디렉토리 소유자가 joe인데 소유자에게 주어진 권한이 rwx이므로 역시 FTP 업로드 또한 문제 없게 된다.
다음과 같이 변경한다

# chown -R joe:www-data /home/joe/www/wordpress/
# chmod -R 775 /home/joe/www/

소유자 및 권한 설정이 다음과 같이 변경되어 있을 것이다.

drwxrwxr-x  5 joe        www-data          4096  5월 18 13:21 wordpress/

참고로 WordPress가 설치된 디렉토리의 wp-config.php의 권한을 600으로 다음과 같이 주어졌을 경우 다른 모든 것이 정상일지라도 해당 홈페이지는 웹 브라우저에서 실행되지 않는다.

-rw-------  1 joe www-data  2988  5월 23 14:54 wp-config.php

왜냐하면 위에서 보는바와 같이 Ubuntu에서 웹 서비스를 실행시키는 소유자는 www-data인데 wp-config.php는 소유자가 joe로 되어 있고 이 사용자(joe)에 대해서만 rw의 권한이 주어져 있고 www-data를 포함한 그외의 사용자에게는 어떠한 권한도 주어져 있지 않기 때문에 이 홈페이지는 실행이 될수가 없다. 이럴 경우 다음과 같이 권한을 755로 설정해 주면 문제가 해결된다.

# chmod 755 wp-config.php

그러면 다음과 같이 되어 정상적으로 WordPress 홈페이지가 실행이 될 것이다.

-rwxr-xr-x  1 joe www-data  2988  5월 23 14:54 wp-config.php*