/var/log/error.log 를 보니 evasive:20 persimission denind 오류가 떠있었다.

그래서 a2dismod evasive 를 하니 일단 오류가 더이상 뜨진 않는다.

이건 극단적인 방법이고, mods-enabled 에서 evasive.conf 를 열어 제한 수를 조정해주는것도 한 방법이 되겠다.

Apache UserDir 모듈

 

Apache 서버의 내부 사용자들이 외부에 공개하고자 하는 html 문서를 저장하기 위한 용도로 사용되는 내부 사용자별 디렉터리를 말한다.  UserDir 모듈 사용방법은 아래와 같이 사용한다. 


1. userdir.conf 편집

 

#/etc/apache2/mods-available/userdir.conf

 

<IfModule mod_userdir.c>

          UserDir public_html    // 사용자별 디렉터리 이름

          UserDir disabled root  // userdir 모듈 허용 / 거부 설정 

         

          <Directory /home/*/public_html> // 사용자별 디렉터리 위치

                  AllowOverride FileInfo AuthConfig Limit Indexes

                  Options Multiviews Indexes SymLinksIfOwnerMatch IncludesNoExec

                  <Limit GET POST OPTIONS>

                         Order allow,deny

                         Allow from all

                  </Limit>

                  <LimitExcept GET POST OPTIONS>

                         Order deny,allow

                         Deny from all

                  </LimitExcept>

              </Directory>

</IfModule>

 

위에서 살펴본 userdir.conf파일을 이용하여특정 사용자만 UserDir 디렉터리를 허용시키고자 할 때는 enabled을 사용하여아래와 같이 설정한다.

 

) UserDir disabled

    UserDir enabled user1 user2

 

대부분의 사용자는 허용하고 일부만 거부하고자 한다면 disabled을 이용하여아래와 같이 설정한다.

 

) UserDir enabled

    UserDir disabled user1 user2 

 

2. 링크 또는 복사


Userdir.conf 파일 설정이 완료되면, /etc/apache2/mods-acailable/안에 있는 userdir.cof

userdir.load 파일을 /etc/apache2/modes-enabled/으로 복사하거나 링크를 걸어 준다.

 

링크

#cd /etc/apache2/modes-enabled/

#ln -s /etc/apache2/mods-available/userdir.conf

#ln -s /etc/apache2/mods-available/userdir.load

 

복사

#cp /etc/apache2/modes-available/userdir.* /etc/apache2/modes-enabled/

 

3. 폴더 생성

 

2번 까지 모두 완료되었으면이제 Home 디렉터리에 존재하는 사용자 폴더 밑에 public_html 폴더를 생성 후 안에 *.html 을 생성 해준다

 

4. 모든 설정이 끝났다이제 apache 데몬을 재 시작한다.


#/etc/init.d/apache2 restart

 

- Userdir 접속 방법

브라우저에서 http://도메인/~사용자/ (http://ex.com/~user1/)

외부에서 불법 링크를 차단 할 경우 (내부링크는 허용됨)
apache virtualhost부분에 아래 추가

   SetEnvIFNoCase Referer "daum.com" link_allow
   SetEnvIFNoCase Referer "111.111.13.111" link_allow - localhost를 지정해주지 않으면 IP로 접속시 이미지 깨짐
   <FilesMatch "\.(gif|jpg|)$"> - gif|jpg 지정할 경우 웹페이지중 gif 및 jpg는 외부링크는 허용안됨 추가로 확장자 지정됨
ex> (gif|jpg|png|bmp|zip|tar|rar|alz|a00|ace|jpg|jpeg|txt|GIF|JPG|BMP|ZIP|TAR|RAR|ALZ|A00|ACE|TXT|mp3|MP3|mpeg|MPEG|wav|WAV|asf|ASF|wmv|WMV|swf|SWF|exe|EXE)$">
   order allow,deny
   allow from env=link_allow
   deny from all
 </FilesMatch>


 <VirtualHost *:80>
   # ServerAdmin webmaster@daum.or.kr
    DocumentRoot /home/public_html/
    ServerName daum.com
    ServerAlias www.daum.com
    SetEnvIf Request_URI \.gif image-request
    SetEnvIf Request_URI \.jpg image-request
    SetEnvIf Request_URI \.png image-request
    CustomLog logs/access_log common env=!image-request
    #ErrorLog "logs/damc.or.kr-error_log"
    #CustomLog "logs/damc.or.kr-access_log" common

    <FilesMatch "\.(gif|jpg|png|bmp|zip|tar|rar|alz|a00|ace|jpg|jpeg|txt|GIF|JPG|BMP|ZIP|TAR|RAR|ALZ|A00|ACE|TXT|mp3|MP3|mpeg|MPEG|wav|WAV|asf|ASF|wmv|WMV|swf|SWF|exe|EXE)$">
  order allow,deny
  allow from env=link_allow
  deny from all
 </FilesMatch>
</VirtualHost>

 

우분투에서 사용하는 apt 패키지 관리자의 기본 저장소를 변경하는 방법입니다.

/etc/apt/sources.list 파일을 편집하면 되는데요. 아래는 우분투 기본 저장소인데 아무래도 해외이다보니 속도가

느립니다. kr.archive.ubuntu.com 도 있긴 한데 이것도 역시 좀 느립니다. 그래서 daum 에서 제공하는 저장소를

많이 사용하게 되는데요.

 

deb http://archive.ubuntu.com/ubuntu trusty main
deb http://archive.ubuntu.com/ubuntu trusty-updates main
deb http://security.ubuntu.com/ubuntu trusty-security main
deb http://archive.ubuntu.com/ubuntu trusty universe
deb http://archive.ubuntu.com/ubuntu trusty-updates universe

 

아래는 daum 의 저장소로 변경한 파일입니다. vi 로 작업하실 경우는 간단히 치환 명령어를 사용하면 됩니다.

 

:%s/archive.ubuntu.com/ftp.daum.net/g

:%s/security.ubuntu.com/ftp.daum.net/g

deb http://ftp.daum.net/ubuntu trusty main
deb http://ftp.daum.net/ubuntu trusty-updates main
deb http://ftp.daum.net/ubuntu trusty-security main
deb http://ftp.daum.net/ubuntu trusty universe
deb http://ftp.daum.net/ubuntu trusty-updates universe

 

저장한 후에 apt-get update 한번 해 주시고 apt-get upgrade 도 하시되 중간에 grub 을 변경할지 물어볼 경우 반드시

현재 버전을 유지하는 걸로 하시기 바랍니다. 아니면 가상서버 부트섹터가 변경되어서 부팅이 안 될 수가 있습니다.

 

출처 http://blog.fun25.co.kr/%EC%9A%B0%EB%B6%84%ED%88%AC-apt-%EA%B8%B0%EB%B3%B8-%EC%A0%80%EC%9E%A5%EC%86%8C-%EB%B3%80%EA%B2%BD%ED%95%98%EA%B8%B0/

find 라는 명령으로, 디스크에 저장된 각종 파일/디렉토리를 검색할 수 있습니다.


파일 찾기 (파일명 검색)


현재 디렉토리에서, pl 확장자를 가진 모든 파일 찾기
find -name '*.pl'

(현재 디렉토리 밑의 하위 디렉토리까지 다 찾습니다.)


루트에서부터, 즉 전체 하드에서, pl 확장자를 가진 모든 파일 찾기
find / -name '*.pl'



전체 하드 디스크에서, 파일명이 ab 로 시작하는 모든 파일 찾기
find / -name 'ab*'



전체 하드 디스크에서, 파일명이 .bash 로 시작하는 모든 파일 찾기
find / -name '.bash*'



전체 하드 디스크에서, 파일명이 .bash 로 시작하는 모든 파일 찾기
+ ls 명령 형식으로 출력
find / -name '.bash*' -ls

뒤에 -ls 라는 옵션을 붙이면 됩니다.




디렉토리명 찾기


전체 하드 디스크에서, 디렉토리 이름이 et 로 시작하는 모든 디렉토리 찾기
find / -name 'et*' -type d


주의! 옵션 순서를 바꾸면 에러가 납니다.

 

MyISAM과 달리 InnoDB 테이블들은 매우 안정적이며, 왠만해서는 데이터 파일이 깨어지는 경우는 거의 경험하지 못했다.
하지만, 데이터 파일이 깨어진다면 어떻게 해야 할까 ?. DBMS 벤더를 불문하고 손상된(깨어진) 데이터 파일을 복구한다는 것은 쉽지 않은 문제이며 위험도 크다.
이런 비 정상적인 현상은 어느 DBMS에서나 발생할 수 있는 현상이며, 이를 위해서 우리는 데이터베이스를 그렇게 열심히 백업하고 있었던 것이다.
만약, 백업마저도 복구가 안 된다면, 결국 지금의 깨어진 데이터 파일이라도 어떻게든 복구를 해야 한다.
하지만, InnoDB myisamchk와 같은 별도의 복구 도구를 제공하지 않는다.
손상된 InnoDB 테이블의 복구는 우선 MySQL을 기동시켜서 데이터를 덤프(mysqldump, SELECT INTO OUTFILE…)를 받는 것이 유일한 방법이다.
하지만, InnoDB Boot-up 과정에서 여러 가지 체크 및 정리 작업들을 하게 되는데, 이 중에서 하나라도 문제가 있을 경우 시작이 되지 않는다. (MySQL이 시작도 안 되는데 어떻게 덤프를 받지? ㅠㅠ)
그래서 MySQL의 설정 옵션 중에서 "innodb_force_recovery" 라는 설정 변수를 제공하고 있다
아래와 같이 MySQL의 설정 파일(my.cnf, my.ini)에 설정하면, 이 설정 값에 의해서 InnoDB에게 어떤 체크나 정리 작업을 건너뛰어야 할지를 알려 줄 수 잇다.

## 0 ~ 6까지의 값 중에서 하나를 설정 (0은 정상 상태인 경우이며 그 이상의 경우 강제 복구모드에 해당됨)
innodb_force_recovery = 1


기본 설정 값은 "0" 인데, 이는 InnoDB에게 모든 체크와 정리 작업을 정상적으로 실행하도록 명령하는 것이다.

그 이외의 설정 값은 모두 비 정상적인 상황을 위한 설정 값이며, 일반적인 서비스 환경에서는 사용하면 안 된다.
또한 "0"이 아닌 그 이외의 값을 설정하게 되면, InnoDB는 복구 모드라고 가정하고 SELECT 이외의 데이터를 변경하는 SQL들은 모두 처리를 거절해 버린다.


각 설정값별 복구 내용과 방식을 간단히 살펴보자. 

·         1 ( SRV_FORCE_IGNORE_CORRUPT )
데이터 파일의 손상된 페이지가 발견되어도 무시하고 MySQL을 기동시킨다.  일단 MySQL이 기동되면, SELECT * FROM tbl_name; 명령문을 실행하여 데이터를 덤프하여 다시 적재하거나 다른 데이터베이스로 이전하는 것이 좋다. 이 때, 손상된 인덱스 레코드와 페이지는 모두 건너뛰게 된다. (, 무시해 버리므로 데이터를 잃게 된다.)
에러 로그 파일에 "Database page corruption on disk or a failed "라고 출력되는 경우, 대부분 이 케이스인데 이는 테이블 스페이스의 페이지가 손상되어서 발생하는 문제이다. 이 경우에는 이 모드로 MySQL의 기동 후, mysqldump SELECT INTO OUTFILE...을 이용하여 덤프 및 재 적재가 가능하다.

·         2 ( SRV_FORCE_NO_BACKGROUND )
InnoDB의 여러 가지 Background thread들 중에서 Main thread를 시작하지 않고 MySQL을 기동시킨다. InnoDB의 경우 트랜잭션과 동시성 향상(MVCC)을 위해서 Undo 정보를 보존하게 되는데, Undo 정보는 변경되기 전 데이터를 가지게 된다. 이러한 Undo 정보는 여러 가지 상황에 맞춰서 적절한 시점에 삭제가 되어야 하는데 이 작업을 Main thread가 처리한다 (이 작업을 Purge라고도 부른다.). 그런데 만약 MySQL 의 시작 과정에서 InnoDB가 이러한 Purge 작업 중 오류를 발생시킨다면, MySQL의 기동 시에 Main thread를 시작시키지 않기 때문에 Purge 작업 중의 오류를 피할 수 있게 되므로, 일단 MySQL을 시작시킬 수는 있게 된다. Undo 정보는 InnoDB의 시스템 테이블 스페이스에 관리되기 때문에, 이 경우에는 전체 데이터베이스를 덤프 받은 후 다시 MySQL 서버를 구성해야 한다.

·         3 ( SRV_FORCE_NO_TRX_UNDO )
MySQL을 종료하던 시점에 만약 진행 중인 트랜잭션이 있었다면, MySQL은 그냥 단순히 그 Connection을 강제로 끊어 버리게 된다. 그 이후 별도의 정리 작업은 진행하지 않게 된다. MySQL은 종료되었지만, 진행 중이던 트랜잭션의 정리 작업은 하지 않게 되는 것이다. MySQL이 다시 시작하게 되면, InnoDB 엔진은 트랜잭션 로그(Redo log라고도 함)를 읽어서 다시 처리 해주고(이 작업을  Roll forward라고 함), 최종적으로 어떤 트랜잭션이 완료되지 않고 Connection이 종료되었는지 판단 후, 그 트랜잭션들은 InnoDB 엔진이 Rollback을 시키게 되는데, 만약 Undo 영역이나 다른 관련된 데이터들이 손상된 경우에는 Rollback 처리를 해줄 수 없게 되는데, 이 경우에 사용하는 복구 모드이다. 이 경우에는 사실은 Rollback되어야 하지만, 실제 데이터 파일에는 그 데이터가 남아 있을 수 있다. (이 부분은 Binary log Application의 로그를 통해서 수동으로 보완해 주거나 무시하는 방법밖에 없다.)

·         4 ( SRV_FORCE_NO_IBUF_MERGE )
MySQL InnoDBINSERT, UPDATE, DELETE 등의 데이터 변경 작업으로 발생하는 인덱스 변경 작업들을 상황에 따라서 즉시 실행할 수도 또는 나중에 처리하도록 지연시킬 수 도 있다. 이렇게 나중에 처리하도록 지연시키기 위해서는 변경 내용을 어딘가에 기록해 두어야 하는데, 그 용도로 사용되는 버퍼가 "Insert Buffer"이다. Insert Buffer의 내용은 언제 데이터 파일에 병합(Merge)될지 알 수 없다. MySQL을 종료해도 병합되지 않을 수 있는데, 만약 MySQL이 재 시작 되면서 Insert Buffer의 손상을 감지하게 되면 Insert Buffer의 병합 작업이 실패하고 MySQL이 기동하지 못하게 된다. 이 경우 사용할 수 있는 강제 복구 모드이다. (이 경우에는 테이블 통계 정보 갱신을 유발하는 작업들을 해서는 안 된다. 주로 DDL이나 ANALYZE 명령 등). Insert Buffer는 실제 데이터와 관련된 부분이 아니라 인덱스에 관련된 부분이라 테이블을 덤프 후 다시 적재하면 처리될 수도 있고, 아니면 단순히 "ALTER TABLE tbl_name ENGINE=InnoDB;" 명령만으로 해결될 수도 있다.

·         5 ( SRV_FORCE_NO_UNDO_LOG_SCAN )
복구 모드 3 ( SRV_FORCE_NO_TRX_UNDO )의 처리와 비슷하며, 이 모드에서는 Undo 로그를 완전히 무시하고 완전히 종료되지 않은 트랜잭션(COMMIT/ROLLBACK되지 않은)을 모두 COMMIT된 것으로 처리해 버린다.  또한 이 모드에서는 Undo 로그를 전혀 참조하지 않는 형태로 강제 복구 시킨다.

·         6 ( SRV_FORCE_NO_LOG_REDO )
이것은 MySQL 서버가 재 시작되기 전 가장 뒤에 발생한 체크 포인트 이후의 모든 트랜잭션을 버리고 복구 시키는 모드이다. 당연히 Redo 로그를 참조하지 않으므로 Roll forward라는 작업도 하지 않고 강제 복구시키게 된다. Redo 로그가 손상된 경우 이 모드로 강제 복구가 가능하다.

여기서 설명된 강제 복구 모드는 그 설정 값이 높아질수록 손실되는 데이터가 많아지기(복구 가능한 데이터가 적어지기) 때문에, 가능한 강제 복구 모드를 낮은 것(1 -> 2 -> 3 ->4 -> 5 -> 6)부터 시도해 볼 것을 추천한다.

아래 내용은 HighPerformanceMySQL 블로그에서 발췌한 내용을 번역한 것인데, 같이 참조하면 좋을 듯 하다.
InnoDB 테이블이 손상되는 경우는 상당히 희박
Double write, Checksum 그리고 기타 Validation 로직들과 버그 보완으로 인해서, 실제로 MyISAM에 비해서 InnoDB 테이블 스페이스 및 데이터 파일은 상당히 안정적이다.

대부분의 손상은 인덱스에서 발생
많은 사람들이 경험하는 InnoDB 데이터 파일의 손상은 80~90% 정도가 InnoDB 인덱스 (Secondary index)에 발생한 손상인 경우이며, 이 경우에는 단순히 ALTER TABLE 또는 데이터 덤프 및 재 적재만으로 해결된다. 복구 모드 "1 ( SRV_FORCE_IGNORE_CORRUPT )" 참조.

이 이외의 InnoDB 테이블의 문제점들의 경우는 덤프 및 적재
이 이외의 복잡한 형태의 장애에 대해서는, (아주 심한 경우가 아니라면)데이터베이스 전체를 덤프하고 다시 적재하는 것으로 해결될 수 있다. 하지만, 가장 최근의 백업에 Binary log Replay (재 실행)해주는 것보다 빠를지는 상황을 적절히 판단해서 결정하는 것이 좋을 듯 하다.


이래도 저래도 안 되는 경우에는(대표적으로 InnoDB의 시스템 테이블 스페이스가 손상된 경우) 아래 URL의 도구를 참조하는 것도 도움이 될 수 있을 듯 하다.
(사용해 본 경험이 없어서, 얼마나 작동할지는 잘 모르겠다.)

 

'서버 등 운영체제(OS) > Linux' 카테고리의 다른 글

우분투 apt 기본 저장소 변경하기  (0) 2015.04.24
find 리눅스에서 파일 찾기  (0) 2015.04.20
innodb_force_recovery  (0) 2015.04.15
MySQL 백업과 복구  (0) 2015.04.15
SAMBA 에 새로운 사용자 등록 절차  (0) 2015.04.15
crontab 설정 방법  (0) 2015.04.15
백업
MySQL 데이터를 백업하는 방법은 크게 물리적 백업과 논리적 백업이 있다. 

1. 물리적 백업
 - 물리적 백업은 MySQL DB의 물리 파일을 백업하는 것이다.
 - 장점
  + 물리적 백업은 속도가 빠르며 작업이 단순하다.
 - 단점
  + InnoDB의 물리적 파일은 상응하는 논리 백업에 비해 상당히 크다.
  + 데이터 복구시에 문제가 발생할 소지가 있으면 문제발생시 원인파악 및 해결이 어렵다.

2. 논리적 백업
 - 논리적 백업은 mysqldump 혹은 기타 툴을 이용해서 SQL문을 갖는 텍스트 파일을 생성하는 것이다.
 - 장점
  + 논리적 백업은 데이터를 검토할 수 있다.
  + 복원작업이 수월하며, 물리적 백업에 비해 복원시 데이터 손상을 막아주며, 문제 발생시 원인 파악및 해결하기가 수월하다. 
 - 단점
  + 백업/복원시 시스템 리소스를 더 많이 소모한다. (물리적 백업은 파일 copy만 하면 되니까!!!)
  + 부동 소수점 데이터의 백업&복원시 데이터 정확성을 잃게 될 수 있다.

3. mysqldump 사용법
 $ mysqldump -u[userId] -p[password] --all-databases > dump.sql  // 서버에 있는 모든 것의 논리 백업 생성
 $ mysqldump -u[userId] -p[password] --databases [DB명] > dump.sql // 특정 데이터베이스만의 논리 백업 생성
 $ mysqldump -u[userId] -p[password] [DB명] [테이블명]

 
- 기타 옵션
   -A, --all-databases : 모든 DB 덤프
   -B, --databases : 특정 DB를 덤프

   --opt : 버퍼링을 비확성화 하고, 많은 데이터를 덤프에 있는 소량의 SQL구문에 기록해 더효율적으로 동작하다록 한다.
   --allow-keywords, --quote-names : 예약어를 사용하는 테이블을 덤프하고 복원할 수 있게 한다.
   --lock-alltables : 전역적으로 일관된 백업을 만들도록 "FLUSH TABLES WITH READ LOCK"을 사용한다. 
   --tab : "SELECT INTO OUTFILE"로 파일을 덤프하여, 덤프 및 복원 속도가 매우 빠르다.
   -d, --no-data :  데이터는 제외하고 스키마만 덤프
   -t, --no-create-info : 스키마는 제외하고 

4. dump 파일 복원 방법
 - mysql -u [userId] -p [password] [DB명] < dump.sql
 - mysql 접속한 후 아래의 명령 실행
     mysql> source dump.sql

 

출처 : http://dimdim.tistory.com/entry/MySQL-%EB%B0%B1%EC%97%85-%EB%B0%8F-%EB%B3%B5%EA%B5%AC 


 

'서버 등 운영체제(OS) > Linux' 카테고리의 다른 글

find 리눅스에서 파일 찾기  (0) 2015.04.20
innodb_force_recovery  (0) 2015.04.15
MySQL 백업과 복구  (0) 2015.04.15
SAMBA 에 새로운 사용자 등록 절차  (0) 2015.04.15
crontab 설정 방법  (0) 2015.04.15
우분투 Postfix를 이용한 메일서버 구축  (0) 2015.04.09
samba 계정 등록 절차는 다음과 같다. 
1. 시스템 사용자 등록(useradd) 및 패스워드 등록 (passwd)
2. 그룹 사용자 등록(gpasswd) 
3. samba 사용자 등록(smbpasswd)


1. 시스템 사용자 등록(useradd) 및 패스워드 등록(passwd)
[root@nmsfile ~]# useradd user01
[root@nmsfile ~]# passwd user01
Changing password for user user01.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

등록 확인 :  /etc/group 파일을 보면 user01 에 대한 내용이 추가된 것을 확인 할 수 있다. 
[root@nmsfile ~]# cat /etc/group
(-생략-)
testuser01:x:545:
user01:x:546:
[root@nmsfile ~]#


2. 그룹 사용자 등록(gpasswd) 
디렉토리에 대한 권한을 개별 사용자 별로 지정해 준다면 sambauser 파일에 등록해서 사용할수 있지만, 
그룹에 대한 설정이 안되서 그룹 사용자에 등록해서 samba 그룹 설정을 해준면 편한다. 
[root@nmsfile ~]# gpasswd -a user01 (등록할 group명)
user01 그룹에 (group명) 사용자 등록중

등록 확인 : 해당 그룹명 끝에 사용자이름(user01)이 추가된 것을 확인 
[root@nmsfile ~]# cat /etc/group
(group명):x:0:root, citylock, user01


3. samba 사용자 등록(smbpasswd)
마지막으로 samba사용자 등록해주면 된다. 여기서는 사용자 계정에 대한 얘기만 하겠다. 
(samba 설정에 대한 이야기는 다른 글을 통해서 확인해 주세요.)

[root@nmsfile samba]# smbpasswd -a user01
New SMB password:
Retype new SMB password:
Added user user01.
[root@nmsfile samba]#

등록 확인 : samba 디렉토리의 smbpasswd 을 열어보면 등록된 사용자 이름을 확인 할수 있다. 
[root@nmsfile samba]# cat /etc/samba/smbpasswd
#
# SMB password file.
#
citylock:502:CA2C4014679EACCEAAD3B435B51404EE:F2AEE55B79859CA8BD95FA8F38880D4B:[U          ]:LCT-47A7A405:
(생략....)
user01:546:32E9BD72F5671469AAD3B435B51404EE:84440338F26BF725BE78C015F7D62C88:[U          ]:LCT-4D2694F5:

 

 

출처 : http://citylock.tistory.com/547

'서버 등 운영체제(OS) > Linux' 카테고리의 다른 글

find 리눅스에서 파일 찾기  (0) 2015.04.20
innodb_force_recovery  (0) 2015.04.15
MySQL 백업과 복구  (0) 2015.04.15
SAMBA 에 새로운 사용자 등록 절차  (0) 2015.04.15
crontab 설정 방법  (0) 2015.04.15
우분투 Postfix를 이용한 메일서버 구축  (0) 2015.04.09

+ Recent posts