MOODLE의 설치전 준비사항을 앞전 포스팅에서 알아보았다. 이제 무들을 설치해보자. 리눅스 시스템관리자라면 무들용 계정을 만들거나, 호스팅을 받는 사람들이라면, 이 단락을 뛰어넘어 실제 설치부터 시작하면 된다.

무들을 설치하기 위한 계정준비 사항이니 참조하기 바랍니다.

도메인은 도메인을 구입한 딜러회사의 네임서버에서 도메인을 등록하던지, 아니면 자신의 네임서버에 등록한다.

웹페이지가 외부에서 볼수 있게끔 707권한을 준다. (moodle은 기본적으로 무들이 설치되는 바로 앞단계의 디렉토리에 moodledata디렉토리인 캐쉬용 저장소를 만든다. 이 캐쉬용 저장소는 http프로토콜로 외부에서 접근할수 없는 디렉토리에 위치시키는것이 좋다. 단, moodle캐쉬용 디렉토리인 moodledata이외의 moodle용 파일들은 설치후 705로 바꿔도 무관하다.

(현재는 도메인이 발급안된 상태이므로, IP/~moodletest 상태로 진행해본다.)

• 무들의 설치

무들을 인터넷상에서 다운로드한다.

압축이 제대로 다운받아지지 않았거나 에러가 생기면 FTP를 통하여 업로드후 압축을 풀면 된다.

압축을 풀면 moodle이라는 디렉토리를 만들므로, 직접 도메인에서 index.html을 호출하기 쉽게, public_html에 압축을 푼 파일을 모두 옮긴다. (moodle디렉토리 아래 있는 파일만 옮긴다.)

클라이언트 브라우져로 이동하여, 압축된 파일을 이동하여, 무들을 본격 설치하자.

설치한 웹서버의 주소창을 입력하면, 무들 설치화면 나온다. 기본 언어팩을 물어보는데, 한글을 선택할경우 한글언어팩이 다운이 안받아지는 경우가 있다. 차후 설치후 언어팩을 변경할수 있으니 영어 언어팩 하나로만 진행해보자.

      PHP라이브러리에 대한 체킹을 실시한다. Pass되지 않으면 무들을 설치할수 없다.

  무들이 설치될 디렉토리와 웹주소, 캐쉬디렉토리, 설치디렉토리를 묻는다. 별다른 입력이 없으면 자동으로 설정된다. (차후에 도메인이 변경될때는 셀에서 변경하여 주면 된다.)

  SQL의 DB이름과 계정,비밀번호를 입력한다. 위 단락에서 생성한 SQL DB를 사용해보기로 하겠다.

서버에 필요한 프로그램들과 php확장요소들이 설치되었는지 마지막으로 체크한다. 모두 OK가 나오면 성공, 만약 모두 OK가 나오지 않으면 불안요소가 될수도 있으므로 리눅스의 경우 Apache와 PHP 를 재컴파일하거나 윈도우즈의 경우 라이브러리모듈을 추가한다.

 무들의 설치를 진행하겠다는 메세지

  저작권확인등의 작업이다.

  자동으로 설치할것이냐? 아니면 수동으로 설치할것이냐를 묻는다. 자동/수동 아무런 차이가 없다. 수동은 OK나 Next버튼을 눌러줘야 다음단계가 진행되는것뿐이다.

DB Table의 생성과 filed를 생성하고 기본적인 항목에 데이타를 기입하며, 웹상으로 설치를 다이나믹하게 보여준다.

 최고관리자의 비번과 정보를 입력한다.

  사이트에 대한 정보를 물어본다. (사이트에 대한 정보입력을 취소하고 진행했다.)

 최종으로 설치된 무들의 초기화면...! 소문과는 틀리게 상당히 심플(?)하고 단순한 레이아웃을 보여준다.

이상으로 무들의 설치과정을 자세히 포스팅했다. 드디어 무들의 테마(Moodle theme)작성에 대한 포스팅을 시작하여야 겠다.

원본환경 : Fedora Core 6 X86 i386

lampp를 이용한 APM

목적지환경  Linux server4-166 2.6.18-164.11.1.el5 

Source Compile을 통한 APM

이 포스팅은 리눅스에서 리눅스로 서버이전한 것을 전제로 쓰여집니다.

XE의 서버이전이라 함은, 별로 대수롭지 않게 생각하였다. 하지만, 그리 녹녹한 작업은 아님을 밝혀둔다. 우선 테스트 환경이 원본은 자체도메인이 있는 상황이고, 타겟은 자체도메인이 없는 IP/~사용자계정 환경이었다.

도메인이 없는 환경에서는 단순한 사용자계정만 가지고 서버이전을 한다면, CSS가 적용되지 않으며, 게시글간의 이동이 불가능하다. 꼭 도메인이 적용된 Document Root에서 작업하거나 그런 여건이 되지 않는다면, Apache의 httpd.conf를 열어 Document Root를 계정디렉토리로 인식시키기 바란다.

웹호스팅 시스템 하에서는 도메인구입이 같이 이루어지니, 별탈없이 진행할수 있겠다.

1. 원본으로부터의 백업.

우선 mysqldump명령어가 실행되는지 확인하여 보자.

[root@localhost htdocs]# whereis mysqldump
mysqldump: /usr/local/mysql/bin/mysqldump
[root@localhost htdocs]# /usr/local/mysql/bin/mysqldump -uDB계정 -pDB비번 > 데이타베이스명.sql

데이타베이스가 백업되면 그다음으로 자신이 xe폴더의 바로앞 상위폴더로 이동하자.

#tar –cvvf  xe_backup.tar public_html/

이런식으로 다운받아 sql과 tar두 화일을 클라이언트에 내려받는다.

클라이언트에서 내려받는것이 구찮으면 tar와 sql파일을 httpd가 서비스될수 있는 디렉토리에 옮긴다음 타겟 콘솔에서 wget명령으로 내려받으면 ftp를 이용하지 않아도 무관하다.

이제 타겟 서버에서의 도메인의 root document의 상위 디렉토리에 두개의 파일을 업로드하여, tar화일의 압축을 풀어 도메인시작지점에 index.php가 오게한다.

두번째작업으로 타겟 서버의 db에서 원본서버와 같은 이름,같은 비번,같은 문자셋,같은 사용자로 DB를 만든다.

(SQL db명이 틀릴경우 xe폴더아래 file/config/db.config.php파일의 

$db_info->db_userid = '새로운디비유져';

$db_info->db_password = '새로운디비패스워드';

$db_info->db_database = '새로운디비명';

를 변경한다. )

mysql>create database 디비이름 default character set utf8 collate utf8_unicode_ci;

mysql>grant all on 디비이름.* to 사용자이름@localhost by identified by ‘디비비번’;

Mysql을 재가동시켜준후, 백업받은 sql파일을 생성된 DB에 이식시킨다. 

#mysql -u디비사용자 -p디비비번 디비명 < 데이타베이스명.sql

자 이제 DB의 백업은 끝났다.

도메인의 변경이 있는 시스템은 mysql에서 직접 도메인을 변경시켜주어야 한다.

mysql>select * from 식별자_sites;

mysql>update 식별자_sites set domain=”새로 쓰일 도메인이나 IP” where regdate=xxxxxxx;

식별자_sites는 전 서버의 설치시 다른이름으로 지정하지 않은 시스템은 보통 xe_sites가 되며, 지정을 aa로 하였다면 aa_sites가 된다.

select문으로 regdate를 확인하후 조건으로서 regdate문의 데이타를 이용하여 식별자_sites의 domain을 바꾼다.

/* 같은 도메인을 쓰는경우에는 이런 작업을 할필요가 없다.

xe디렉토리/files/config/로 이동하여

db.config.php을 vi나 gedit를 이용하여 편집한다.

[root@localhost config]# vi db.config.php
<?php if(!defined("__ZBXE__")) exit();
$db_info->db_type = 'mysql';
$db_info->db_port = '3306';
$db_info->db_hostname = 'localhost';
$db_info->db_userid = '디비계정';
$db_info->db_password = '디비비번';
$db_info->db_database = '디비이름';
$db_info->db_table_prefix = ‘테이블식별자';
$db_info->time_zone = '+0900';
$db_info->use_rewrite = 'N';
$db_info->default_url = 'http://해당domain이나 IP/';
$db_info->use_optimizer = 'Y';
$db_info->qmail_compatibility = 'N';
$db_info->use_ssl = 'none';
$db_info->use_db_session = 'Y';

위와같이 바꾸고 저장..

브라우져에서 http://해당domain이나 IP를 입력하여보자.

page에 CSS가 적용되지 않음을 알수있다!

브라우져에서 Admin모드로 입장한다. 메뉴와 레이아웃 페이지 세팅등을 체크한다.

아마도 레이아웃이 변형되어있을것이다. 상단메뉴,하단메뉴,로고,홈페이지url등을 고쳐주고 여러 설정중에 캐쉬화일 업그레이드를 실행한다.

다시 putty같은 터미널로 돌아와서 압축을 푼 해당디렉토리로 이동하여..

#chown –R nobody.nobody files

#chmod –R 777 files를 실행한다.

다시 클라이언트 브라우져로 돌아와서 F5 새로고침을 하면 자잘한 세팅외에 모두 제대로 이식했음을 알수있다.

<원본사이트>

<이식된 사이트>

아직 레이아웃의 설정이 덜되어 사이트안에서 로고와 색지정이 안되어 있다. 나머지는 모두 동일..

FC6의 Yum이 갑자기 움직이지 않는다. baseurl의 repodata를 읽을수 없다는 에러 메세지와 함께...
FC6이 언제의 배포본인지 정확히 기억이 안나지만, 약 5년정도는 된거로 알고있다.

리눅스의 단점중 가장 큰것이 바로 프로그램들간의 의존성에 관한 문제인데, 의존성의 어려움때문에 프로그램의 설치와 제거가 어렵다는 점에서, 다른 OS에 비해 상당히 어려운것으로 이해되고 있는 실정이다.

그런문제를 해결해준것이 yum이나 우분투의 apt-get이다.
우선 해결문서를 찾아 yum의 설정화일을 업데이트 하였다.

그리고 libc-client-devel을 설치해보았다.. 성공.. 하지만 너무느리다..
그러나 어찌하겠는가.. 느려도 써야하는걸...

Vsftp의 업로드가 일정지역에서 끊김현상이 계속 발생된다. 어떤 버그인지 모르겠지만, 검색을 해봐도, 충분한 답을 얻을수 없었다.

문제는 내가 운영하는 자체 서버에서 가상호스트를 받는 지인들의 호소로서, 난 돈도 안생기지만 ftp의 서버프로그램을 변경해주어야 했다. 우선 Proftp로 바꿔본다.

개인적으로는 proftp보다 vsftp를 선호한다. 속도면에서 훨 월등한 차이를 보였기에

 wget ftp://proftpd.get7.biz/proftpd/distrib/source/proftpd-1.3.0a.tar.bz2

Proftp의 일본 서버이다. 그래도 한국에서 제일 가깝다. 다운을 받고 압축을 푼후 해당 디렉토리에 가서 소스컴파일 설치를 한다.

#./configure --prefix=/usr/local/proftpd --enable-autoshadow
#make && make install

기존의 vsftp데몬을 중지시키고

[root@localhost proftpd-1.3.0a]# service vsftpd stop
vsftpd瑜?醫낅즺?섍퀬 ?덉뒿?덈떎:                       [  OK  ]

proftp의 설정을 해주자.

[root@localhost proftpd-1.3.0a]# cd /usr/local/proftpd/etc
[root@localhost etc]# pwd
/usr/local/proftpd/etc
[root@localhost etc]# vi proftpd.conf


ServerType                      standalone

# Set the user and group under which the server will run.
User                            ftp
Group                           ftp

MaxClient - 자신이 원하는 동시 접속자수를 정해서 입력한다.

저장하고 나와서

#/usr/local/sbin/proftpd
#

ftp데몬을 실행시켜준다.

접속이 잘된것을 알수있다. 그러나 Vsftp보다는 접속시에 약간 느리다. vsftpd보다 보안이 강화된 이유도 있을듯 하다.

그동안 너무 힘들었다

그동안 너무 많은 사람들을 힘들게 했다.
마을 주변에 작은 비석 하나 세워달라
책을 읽을 수도 없다
원망하지 마라. 삶과 죽음은 하나가 아니냐

이런 정치인을 누가 죽였나요? 아 안타깝네요…

우선 첫 예문을 통해서 CSS의 편리성을 한번 맛보자.

갑자기 만든거라.. 그림이 형편없다..ㅎㅎ

상단의 코드와 하단의 코드는 비슷한출력을 보여준다. (적색박스안이 검은색만 틀리고 다른 보여주는것은 상당히 비슷하다)

아래의 코드는 HTML코드을 이용해 Dreamweaver에서 작성한것이고 위의것은 에디트 플러스를 가지고 CSS코드로 만든것이다. 바깥박스의 색을 바꾸고 싶다면 위의 경우는

#mybox 의 background: #FFCC00;부분만 수정하면 된다.

하지만 아래의 경우 셀속성을 일일히 바꾸어주어야 한다. (물론 표속성으로 만들어주면 괜찮지만)

또한 지금 만든 이 그림을 이동하고 싶을때는? CSS코드는 x축과 y축을 px로 나타내주기만 하면 이동한다.(레이어와는 틀린 개념이다.) 하지만 테이블로 작성했을경우 이동하기 위해서는 다시 더 큰 표를 만들어주어야 한다.

웹을 만드는 사람이 포토샵으로 한장의 레이아웃을 만들었다고 치자..CSS와 보통의 HTML코드와 어느코드로 작업하는것이 쉬우며, 실현이 빠를까?

CSS코드로 만드는것이 대답이다. 위의 예제를 실행해보고, 아래의 코드가 쉽다는 사람은 좀 생각할 여유를 만들기 바랍니다.

이번장은 왜 CSS를 써야만 하는가에 대한 강좌였다. 다음 장은 선택자를 공부합니다.

(http://www.snowrice.com > moodle > Learn CSS에 기재됩니다.)

웹이 처음 만들어졌을때는 상당히 단순했다고 합니다. HTML문법 양식이 매우 단순한것이어서, 누구든 쉽게 HTML문법을 이용하여 문서를 작성했다고 합니다.

그러나, 인간의 욕구는 너무나도 큰것이어서, 계속적으로 웹의 변화를 요구했습니다. 처음 그림과 단순한 글만 올릴수 있던 HTML코드는 테이블,폰트,심지어는 멀티미디어까지 도입되며, 점차 시각적인 인간의 욕구의 목적으로 점점 한계성에 부딛치고 맙니다.

이에 HTML의 보조적인 역활을 할수있는 CSS코드가 W3C를 통해 이세상에 나오게 됩니다.각 브라우져사들은 W3C의 권고안을  받아들여, 브라우져에 CSS기능을 기능을 첨부시킵니다.

2009년 오늘날 CSS도 진화하여 CSS3에 이르게 되지만, 그간 CSS코드의 굴곡도 많았습니다. 애플과 모질라 MS사등의 CSS코드에 대한 해석이 각자 틀렸기 때문입니다.

각 브라우져사들은 각자 자기만의 CSS코드를 해석하여, 브라우져를 출시했으며, 결국엔 윈도우즈를 등에 업은 MS사의 승리로 끝났습니다.

MS윈도우의 explorer와 Macintosh의 safari의 레이아웃이 틀렸던점이 바로 CSS코드의 적용 차이때문입니다.

이 3사는 CSS3의 국제코드의 준수를 약속했고, 표준 CSS3에 입각한 새로운 버젼들을 내놓게 됩니다.

Explorer 7.0 , Safari 3.0 , Firefox 2.0이 약속한 국제 표준의 CSS3를 적용한 브라우져들이며, 이 브라우져들은 이제 국제표준 CSS코드 적용으로 이제는 약간의 차이만 보일뿐 매우 비슷합니다. 이는 , 곧 그간 MS편중의 브라우져시장 경쟁에 치열한 전쟁을 예고하고 있습니다. 브라우져를 잡는 기업이, 곧 인터넷을 잡는 기업이 될테고, 세계의 정보를 장악할테니깐요… 그만큼 CSS해석은 아주 중요한일입니다.

CSS가 적용된 문서(좌)와 CSS가 적용되지 않은 문서(우)

브라우져.

적어도 홈페이지를 만드는 사람들에게는 3가지의 브라우져는 반드시 필요합니다.

Apple사의 Safari 와 Mozilla사의 Firefox MS사의 Explorer입니다.

애플사는 맥킨토시와 OS/ X이라는 무서운 하드웨어와 흡사 종교와도 같은 맥킨토시 신봉자들이 상당히 많습니다. 또한 모질라사의 파이어폭스는 리눅스 배포판들의 기본 브라우져이며 또한 개발자들에게 없어서는 안될 CSS Code Viewer가 ADD on 프로그램으로 제공된다는 HTML문서를 만드는 사람들에게는 없어서는 안될 브라우져입니다.

MicroSoft의 익스플로러는 전세계의 70%이상이 이 브라우져를 이용하니, 어쩔수 없이 있어야 하는것이고요…

이번에 공개된 사파리4는 애플이 항상 그래왔던 것처럼 가히 혁명적인 사용자 인터페이스를 가지고 있습니다. 또한 서버와 클라이언트간의 응답기간이 매우 빠르며 신속합니다.

그래서 사파리로 웹서핑을 하고 파이어폭스로 HTML을 수정작성하고  익스플로러로 디자인레이아웃의 체크를 하는가 봅니다.

사파리의 즐겨찾기기능, 커다란 멀티시어터에 앉아 사이트를 고르는 느낌을 준다.

Learn CSS를 하기전의 준비물-

1. EditPlus 3.0 (에디터 프로그램의 대강자)

빠른 코드입력,빠른검색,각종 언어코드 컨버터 기능들.. vi에 버금가는 이루말할수 없이 좋은 윈도우용 에디터다.

2. Dreamweaver - Editplus를 많이 이용하나, 아무래도 웹문서 전용 에디터도 필요하다.

3 웹서버

윈도우즈의 Xampp나 인터넷이 연결된곳이라면 호스팅 업체도 좋다. 도서관같은데서 랩탑으로 조용히 CSS코드를 입력하실분들은 역시 APMsetup이 최고..

제로보드를 쓰다보면 상당히 신경을 많이 썼다고 하는부분이 일반 가입형 블로그에서 볼수 있는 rewrite mod이다.

기존의 제로보드4에서는 domain/zeroboard.php?=xxxx.xxx이런식으로 표현되었으나, rewrite모드로 인해, domain/숫자 , domain/게시판명으로 쉽게 이동할수 있다.

그러나 도메인이 없는 ~userid를 이용하는 사람들에게는 약간의 설정이 필요하다.

.htaccess 화일을 수정해야한다.숨김화일이기 때문에 ls -la명령으로 봐야한다.

vi .htacess 으로 수정하자.
화일의 앞부분...

RewriteEngine On RewriteBase /~communityart/ # static files RewriteRule ^(.+)/files/member_extra_info/(.*) ./files/member_extra_info/$2 [L] RewriteRule ^(.+)/files/attach/(.*) ./files/attach/$2 [L]

Rewrite /~userid/ 부분을 추가하자...
그리고 저장...

설정완료..이제부터 rewrite모드를 사용할수 있다.

정상적으로 rewrite mod가 적용되었음을 알수있다.

도고헤이아치로 - 일본 해군의 아버지로 불리는 사람이다. 이순신의 학익진을 러시아의 발틱함대에게 구사하여 러일전쟁 승리의 견인차를 만들어낸 인물이다.

하지만 학익진구사외에도 도고의 전술,전법이 러시아를 압도했음을 알수있다.

첫번째는 함정의 우수성이다. 당시의 세계 해전의 주류는 거함거포주의였다. 거포의 힘으로 적을 공격하는 전술이지만, 도고는 화약의 폭발력으로 적을 공격해야 우의에 선다는 전술로 발틱함대를 능멸할수 있었다.

두번째, 동아시아에 부동항이 없는 러시아로서는 유럽의 끝에서 항해를 시작해서, 극동아시아에 진출할수 있었다. 즉 러시아의 발틱함대가 극동지역으로 오기 위해서는 이집트의 수웨즈 운하를 통과해야 만 했다. 그러나 일본과 결탁한 영국이 수웨즈운하의 통과를 불허함으로서 발틱함대는 멀고도 먼 아프리카 남단을 지나 극동아시아에 올수 있었다, 추가적인 국가의 지원없이 먼길을 항해하여 온 지칠대로 지친 함대와 싸우는것은 너무나도 쉬운일.... 일본 외교력의 승리라고 할수 있다.

러일전쟁에서의 도고군이 지노비 로젠스발틱스키의 발틱함대를 상대로 승리를 이끌어낸것은 일본이 잘했다기 보다는 러시아의 삽질이 컸다. 이때부터 일본이 국제사회에서의 주목을 받게 되고, 일본의 조선합병은 러일전쟁으로 기정사실화 된다.

그렇다면 반대로 민자영(민비)의 바램대로 러일전쟁에서 러시아가 이기고, 러시아가 조선에서의 종주권을 획득하였다면 어찌되었을까?

러시아와 같은 나라를 조선이 견제하며, 끝까지 지켜낼수 있었을까?

두가지의 가정이 있다. 하나는 지금 우리는 소비에트 연방 공화국의 한 일원이었다가 독립하여 우즈베키스탄이나 카자흐스탄과 같은 독립국이 되었있을수도 있다. 물론 북부유럽의 백인종과 황인종이 결합된 민족구성을 보일것이다.

소비에트가 성립된것이 1920년대이고 ,러일전쟁이 일어나고 30년후의 일이다.. 조선은 일본이 아닌 서구 열강중 후진국의 하나인 러시아의 지배를 받을것이다.

독립을 지켰다고 해도 주류세력이 러시아와 교체되면서, 러시아 문화의 유입은 실로 커졌을것이다. 소비에트에서 볼세비키 혁명이 일어나듯이, 러시아의 주류 사상이 그대로 도입되어, 조선도 볼세비키 혁명에 가담하는 세력이 나오거나, 공산주의자들 세력이 커졌을것이다. 소비에트 연방에 가입했을 경우가 크다.

독립을 지키지 못했다고 한다면, 러시아의 속국이 되어있을지도 모른다. 러시아공국으로서의 한 일원으로 조선은 지방 행정정부를 만들고, 러시아의 군대가 파견, 외교권 박탈로 이어졌을것이다. 물론 볼세비키 혁명에 의해, 자연적으로 왕족의 숙청과 함께 소비에트 연합의 한 일원으로 사회주의 정권이 도입되었을것이다. 아마도 카자흐스탄이나 우즈벡키스탄의 지위에 오르지 않았을까 하는 가정을 생각해본다.

두번째 가정으로는 극동아시아에서 부동항을 획득한 러시아가 제국주의 노선을 확대하여, 극동아시아의 맹주가 되어, 경제적인 이득의 획득과 함께 일본을 제압하여 일본마져도 러시아 세력으로 만들었을 수도 있다. 물론 덩치가 크지만 패전국 일본은 러시아의 요구조건을 안들어줄수 없고 , 극동의 정세가 러시아로 집중되어 러시아 왕조가 계속 이어질수 있는 발판을 만들어줬을수도 있다. 그렇다면 볼세비키 혁명이 실패로 돌아가서, 2차세계대전을 다시 써야 하는 가정을 만들수 있다.

볼세비키 혁명이 없었다면, 냉전은 오지 않았지만, 대공황의 엄습으로 계속되는 대규모적인 전쟁은 필연적이었다고 생각된다. 그 와중에서 사회주의자들은 계속적으로 혁명을 일으켰을것이고, 결국은 제2의 볼세비키가 일어나, 러시아는 공산주의의 실험의 한장소가 됐을리 자명하다.

어쨋건 러시아가 러일전쟁에 이겼다면, 우리는 지금 카자흐스탄이나 우즈베키스탄과 같은 비슷한 지위에 있지 않을까 가정해본다...

물론 한반도의 그들은 우리가 아닐것이다...