서버를 재부팅 하더라도 설정은 그대로 유지 되기 때문에 접속 할 수 없는 상태.

문제가 생긴 EC2의 root volume을 떼어낸 후  다른 인스턴스에 장착 한다.

이후 아래의 레지스터리를 수정하고 다시 원상복구한다.

driveOfOtherSystem:\windows\system32\config\system

HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile

 

I’ve had the same problem. you can turn off the firewall by plugging the C drive of the inaccessible pc into another instance and then edit the SYSTEM registry key :

HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile

currentControlSet could also be ControlSet001 or 002

you can use regedit to edit that key. Select HKLM , then File/Load hive , load the system hive(driveOfOtherSystem:\windows\system32\config\system) , edit the key and then unload the hive(important)

 

EIP 추가를 통해서도 해결 가능 했다.

MySQL/필드값중 특정 문자열 치환,대체,변환 명령문(예;카테고리값변경

phpMyAdmin에서 sql query 실행 클릭해서 아래 사용

필드내 특정 문자열 치환하는 mysql 명령문;

update 테이블명 set 필드명=REPLACE(필드명,’찾는문자열’,’수정할 문자열’)

예시) g4_write_free 테이블의 ca_name 필드값중에 “추천”이라고 들어간 단어를 “강추”로 일괄치환하고자할때

update g4_write_free set ca_name=REPLACE(ca_name,’추천’,’강추’)

제목 일괄 변경시,
update g4_write_hsuam set wr_subject=REPLACE(wr_subject,’수암 몸짱 만들기’,’수암’)

웹사이트 이전을하면서 도메인을 변경하는 경우 기존에 쌓아왔던 많은 데이터들에 대한 일괄적인 변경이 필요하다. 이를 워드프레스의 글/옵션들 하나하나 찾아다니면서 검색하기는 매우 힘들기때문에 Database에서 sql 구문으로 한번에 변경하면 빠르게 일괄 처리가 가능하다. 일괄변경을 하기전에는 문제가 생기거나 실수를 할 수 있으니 꼭 DB를 백업해두고 작업을 진행하도록 하자.

1. wp_options 변경

다음 쿼리를 이용하여 기존 사이트 주소와 직접적으로 연관이된 옵션설정값들을 일괄로 확인하는것이 가능하다.

siteurl, home 변경

워드프레스의 경우 위의 두 값을 기반으로해서 모든 퍼머링크나, 메뉴링크, 자바스크립트/CSS 링크 등을 출력하므로 위 두개 사항은 필수적으로 확인하여 수정하여여한다.

기타 값

위의 두 값 외에는 해당 쿼리에 대한 결과들을 보고 수정해야할지 판단해서 수정한다. 잘 확신이서지 않는 값들은 바꿔가면서 사이트가 잘 동작하는지 미리 테스트 해보고 변경해야한다. 테마의 파비콘 파일이라던가, 테마용으로 업로드했던 이미지들이 기존주소로 고정되어 저장된 경우들이 많기때문에 이런 값들은 다음 쿼리를 이용하여 새 주소값으로 replace 해주면 된다.

2. wp_post 변경

포스트 내용에도 기존 사이트에 링크를 걸었거나 할경우 동일한 방법을 통해 새 주소로 다 바꿔치기 할 수 있다.

3. wp_postmeta 변경

포스트 메타에는 포스트내용 외에 추가적인 기타 정보들이 많이 들어간다.
특히 워드프레스 메뉴 생성시 메뉴클릭했을때 어느주소로 이동할지 사용자가 직접 지정했던 값들이 있다면, 해당 값들을 일괄 변경해줄 수 있다. 커스텀 포스트를 사용하면서 저장되었던 메타 값들도 일괄변경 가능하다.

위의 쿼리로 변경해야할 부분이 뭐가 있는지 확인한 후, 수동으로 바꿀것은 바꾸고 확실한것들은 다음 쿼리로 일괄 replace한다.

생각해볼것: 상대 주소 사용

새 주소로 변경하는 김에 http://가 박혀있는 절대주소 값 대신에 상대주소를 사용하는 것도 나중을 위해 도움이 될듯하다.
상대주소의 여러 종류에 대한 부분은 스택오버플로우에 누가 잘 설명해두었으니 여기를 참조

상대주소값을 사용할경우 추후 http -> https 변경이나 또다른 사이트 이전시에 최소한의 변경으로 사이트를 정상 동작하게 만들 수 있는 장점이 있다. 사이트 전반에 걸쳐 상대주소값을 사용하게되면 실사이트 말고 localhost나 테스트 서버에서 테스트를 진행할 경우에도 손쉽게 테스트를 할 수 있다.

 

출처 : http://www.letmecompile.com/%EC%9B%8C%EB%93%9C%ED%94%84%EB%A0%88%EC%8A%A4-%EC%82%AC%EC%9D%B4%ED%8A%B8-%EC%9D%B4%EC%A0%84-%ED%8C%81/

 

http://chonnom.com/bbs/board.php?bo_table=B19&wr_id=347

 

http://heart4u.co.kr/tblog/370

 

http://www.smallake.kr/?p=17592

 

– iptables logging

http://paraclete.tistory.com/entry/iptables-logging%EC%9D%84-syslog-%EC%84%9C%EB%B2%84%EB%A1%9C

 

http://system-monitoring.readthedocs.org/en/latest/log.html

Bash 쉘은 명령어 히스토리 기능을 제공 합니다. history 명령어를 입력하면 지금까지 사용했던 Bash 명령어들이 모두 보여 줍니다.

이러한 기능은 사용자 홈 디렉토리에 ‘.bash_history’ 파일에 기록되어 집니다. 그러나 여러 사람이 사용하는 서버에서 각 사용자 홈 디렉토리에 히스토리를 남기기 보다는 리눅스의 syslog 에 남기게 함으로써 사용자가 못된 일을 하는지 않하는지를 감시하도록 하면 좋을 것입니다.

이 문서는 Bash History 를 Syslog 에 남기기 에 대한 것입니다.

1. logger 를 이용한 방법

logger 는 쉘 명령어를 syslog 에 적도록하는 모듈 입니다. 이를 이용하면 수동으로 syslog 에 기록을 남기게 할 수 있습니다. 이를 이용해서 다음과 같이 /etc/profile.d/cmd.sh 파일을 작성 합니다.

 

function history_to_syslog
{
declare cmd
        who=$(whoami)
        cmd=$(history 1)
        TTY=tty
        HISNAME="basename $TTY"
ip=who |grep pts/${HISNAME} |cut f 2 d \(|cut f 1 d \)
logger -p local7.notice -- IP=$ip USER=$who, PID=$$, PWD=$PWD, CMD=$cmd
}
trap history_to_syslog DEBUG || EXIT
HISTSIZE=10000
HISTFILESIZE=1000000
HISTTIMEFORMAT="%F %T "
export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE HISTFILESIZE HISTTIMEFORMAT INPUTRC
declare -r HISTFILE

이제 이를 Source 해 줍니다.

2. rsyslog 설정

다음과 같이 설정을 해줍니다.

이렇게하면 ‘/var/log/bash_history’ 파일에 Bash 쉘 히스토리가 남기며 ‘192.168.0.2’ 서버에 로그를 전송합니다.

 

출처 : http://linux.systemv.pe.kr/bash-history-%EB%A5%BC-syslog-%EC%97%90-%EB%82%A8%EA%B8%B0%EA%B8%B0/

 

출처 : http://hbiedu.tistory.com/20

 

사진, 동영상, 웹로그 등 비 정형화된 데이터베이스를 통계 수집 – 처리 – 통계 분석하는 기술을 빅데이터 기술이라고 합니다. 기업에 입장에서는 고객의 동선을 파악, 마케팅에 활용을 하며, 국가에 있어서는 범죄예방등의 목적으로 활용이 되기 때문에 요즘 떠오르는 기술이라고 볼 수 있습니다.

빅데이터 저장기술의 핵심인 NoSQL,, NoSQL을 사용하는 데이터베이스로는,, 몽고DB, 카산드라DB, Hbase, Redis 등이 있습니다. 각각의 차이점은 뭐가 있을까요..?

 

 

 

 

Cassandra
카산드라는 구글의 BigTable 컬럼 기반의 데이타 모델과 FaceBook에서 만든 Dynamo의 분산 모델을 기반으로 하여 제작되어 Facebook에 의해 2008년에 아파치 오픈소스로 공개된 분산 데이타 베이스 입니다. 기존의 관계형 데이타 베이스와 다르게 SQL을 사용하지 않는 NoSQL의 제품중의 하나이며, 대용량의 데이타 트렌젝션에 대해서 고성능 처리가 가능한 시스템입니다.(High-Scale). 노드를 추가함으로써 성능을 낮추지 않고 횡적으로 용량을 확장할 수 있으며 얼마전에 트위터도 MySQL에서 Cassandra로 데이타베이스를 전환하였다고 합니다. 자바로 작성되었음에도 불구하고, 데이타베이스라는 명칭에 걸맞게 여러 프로그래밍 언어를 지원합니다. (Ruby,Perl,Python,Scala,Java,PHP,C#)
데이타간의 복잡한 관계 정의(Foreign Key)등이 필요없고, 대용량과 고성능 트렌젝션을 요구하는 SNS (Social Networking Service)에 많이 사용되고 있으며. 성능이나 확장성과 안정성이 뛰어납니다.

 

 

 

 

HBASE
HBase는 Cassandra와 마찬가지로 Bigtable의 영향을받은, 대량 데이터를 효율적으로 다루기 위한 목적으로 개발된 NoSQL 데이터베이스입니다. 대용량 데이터를 다루는 NoSQL 데이터베이스중 Cassandra와 함께 가장 많이 사용되고 있습니다만, Cassandra와는 구별되는 뚜렷한특징을 가지고 있습니다. Cassandra는 성능을 우선시 할 경우 데이터 일관성이 보장되지 않을 수있는데. 대량 데이터를우수한 성능으로 데이터 일관성을 보장하면서 다뤄야 할 때는바로 HBase입니다.
HBase는 중앙에 전체 분산 시스템을 통제하는 마스터를 두고 복제된 전체 데이터의 일관성을 관리 하기때문에 분산된 복제 데이터 사이의일관성을 보장하며 제약이 있지만 트랜잭셔성 처리도 지원이 가능합니다.대량 데이터 분석 및 처리를 위해 사용되는 Hadoop의 산하 프로젝트로 시작된 데이터베이스로 HDFS 및 MapReduce등과 함께 사용하기에최적화 되어 있습니다. MapReduce를 지원하는 다른 데이터베이스도 있지만 별도로 개발되었기 때문에 HBase처럼 HDFS를 사용하며 MapReduce의 기능을 적합하게 사용하는 예는 없습니다.대량 데이터를 분삭하여 의미 있는 값을 만드는 데 있어 널리 사용되고 있는 MapReduce와 함께 효율적으로 이용할 수 있다는 것이 큰
장점 입니다.

 

 

 

 

Mongo DB
MongoDB는 10gen 사에서 개발된 높은 성능과 확장성을 가지고 있는 데이터베이스 입니다.
몽고DB는 크로스 플랫폼 도큐먼트 지향 데이터베이스 시스템입니다. NoSQL 데이터베이스로 분류되는 몽고DB는 JSON과 같은 동적 스키마형 문서들을 선호함에 따라 전통적인 테이블 기반 관계형 데이터베이스 구조의 사용을 하지않습니다. 이로써 특정한 종류의 애플리케이션을 더 쉽고 더 빠르게 데이터 통합을 가능케 합니다. GPL과 아파치 라이선스를 결합하여 공개된 몽고DB는 자유-오픈 소스 소프트웨어입니다.

 

 

 

 

Redis
Redis는 “REmote DIctionary System”의 약자로 메모리 기반의 Key/Value Store 입니다.
Cassandra나 HBase와 같이 NoSQL DBMS로 분류되기도 하고, memcached와 같은 In memory 솔루션으로 분리되기도 합니다.성능은 memcached에 버금가면서 다양한 데이타 구조체를 지원함으로써 Message Queue, Shared, memory, Remote Dictionary 용도로도 사용될 수 있으며, 이런 이유로 인스탄트그램, 네이버 재팬의 LINE 메신져 서비스, StackOverflow,Blizzard,digg 등 여러 소셜 서비스에 널리 사용되고 있습니다.

< Redis 특징 >
ㅁ처리 속도가 빠르다
ㅁ데이터가 메모리+Disk에 저장된다
ㅁ만료일을 지정하여 만료가 되면 자동으로 데이터가 사라진다.
ㅁ저장소 메모리 재사용 하지 않는다
ㅁ문자열, Set, Sorted Set, Hash, List등의 다양한 Data Type을 지원

 

 

떠오르는 IT 신기술인 빅데이터기술,, IT분야에 있어서 보다 높은 스팩을 원하신다면,, 도전해 보시기 바랍니다.^^

 

 

추천으로 알게 된 랙자원 관리툴 racktables. 아직 사용 전이지만,

오픈소스의 강점의 강력함을 세삼느낀다.

 

데이터센터에서 운영하는 혹은 전산실에서 운영하는 Rack 간의 서버, IP 들을 업데이트 해야 하는 어려움들 racktables를 통해 도움을 받을 수 있지 않나 싶다.

 

향후 설치 해보고 추가 업데이트 할 예정.

 

http://toofasttosee.blogspot.kr/2013/06/racktables.html

Mysql 백업
우선 Mysql 이 /usr/local/mysql/에 설치되어있으며 Mysql configure시
–localstatedir=/usr/local/mysql/data 옵션을 주고 설치했다고 가정하겠다.
백업 방법으로는 크게 2가지가 있다.
Mysql DB 데이터 화일을 직접 백업하는 경우와 mysqldump 문을 이용하여 sql문을 백업받는방법이 있다

1. 데이터 화일 직접백업
보통의 경우 Mysql 을 사용하는 Type 이 InnoDB와 Myisam 이 있다.
두 Type 의 차이는 여러가지가 있지만 여기서 언급하는것은 데이터 화일 백업에 관련된것이므로
데이터 화일의 위치를 언급하겠다.

nnodb_data_home_dir = /usr/local/mysql/data/
innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend

InnoDB 의 경우 일반적으로 위의 /etc/my.cnf 에서 설정된 것과 같이
ibdata1, ibdata2 과 같은 화일에 index 및 파일데이터가 저장된다. 그리고 DB 및 테이블 정보는
/usr/local/mysql/data/DB명/테이블명.frm 과 같은 구조로 이루어져 있다.
그러므로 ibdata1 와 같은 화일과 /usr/local/mysql/data/DB명/테이블명.frm 화일들을 복사하면 백업하면된다.

Myisam 인 경우는 좀더 직관적이다.
/usr/local/mysql/data/DB명 에 있는 화일을 통째로 백업받으면 된다.
특정 DB의 특정 테이블만 백업받을 경우에는..

/usr/local/mysql/data/DB명/테이블명.frm # 테이블 구조
/usr/local/mysql/data/DB명/테이블명.MYD # Myisam Type 테이블의 DATA
/usr/local/mysql/data/DB명/테이블명.MYI # Myisam Type 테이블의 index

위의 3개 화일만 다운받으면 된다.
물론 data 디렉토리를 통째로 백업받을수도 있다.

다만 이런 직접적으로 파일을 백업받는 방법은…
Mysql 버젼이 달라졌을때 문제가 될수도 있으니…
가급적이면 mysqldump 를 이용하는것이 좋다.

2. mysqldump를 이용한 Backup
가장 널리 이용하는 방법이고 가장 확실한 방법이다.
다만 DB 데이터가 큰 경우 Backup 시간이 많이 걸릴수 있기 때문에
보통 크론등을 이용하여 주기적으로 새벽시간을 이용하여 백업받는다.

사용방법은 다음과 같다.
/usr/local/mysql/bin/mysqldump -uroot -pPassword [백업옵션] [환경옵션] > /BackUp/Mysql/Backup.sql
/BackUp/Mysql/ <== 임의로 정한 백업화일 위치이다.

[백업옵션] 의 내용은 아래의 4가지 형태만 알아도 될듯하다.
옵션들에 주의 해주면 다양한 형태로 백업을 받을수 있다.
–all-databases # mysql DB 전체를 백업다는것을 의미한다.
–databases DB1 DB2 DB3 # mysql 에서 특정 DB만 백업받는 것을 의미한다.
DB1 # DB1 이라는 DB 만 백업받을때 사용한다.
DB1 table1 # DB1 이라는 DB의 table1 이라는 테이블만 백업받을때 사용한다.

[환경옵션]은 백업시에 어떤환경으로 백업을 할것인가에 대한 옵션이다.
–default-character-set=utf8 # 지정된 캐릭터셋을 기본으로함
–set-charset # 기본지정된 캐릭터셋(default-character-set)을 SET NAMES default-character-set로 설정
–opt # 메모리에 로드하지 않고 바로 화일로 덤프
–create-options # create문 백업시에 테이블 설정을 포함함.
–compatible=DB # 백업sql이 특정 db에 호환되도록 함 예) mysql40, mysql41, oracle, mssql
–extended-insert=FALSE # insert 문을 한줄씩 만든다
–result-file=file # 지정된 file 로 바로 넣음.. “> /BackUp/Mysql/Backup.sql”  과 같은 의미
–triggers # 트리거 덤프
–no-create-db # DB 생성정보를 뺌
–no-create-info # 테이블 생성정보를 뺌
–no-data # 테이블의 데이터를 뺌
이외에도 많은 옵션이 있지만 거의 사용할일이 없어서 나도 잘모른다.
공부하고 싶으신분들은 mysqlkorea.com 이나 mysql.com 에서 찾아보시길..

복구(Recover)
복구는 상당히 간단하다.
/usr/local/mysql/bin/mysql -uroot -pPassword < /BackUp/Mysql/Backup.sql
위의 방법은 전체복구이며 단위 DB가 생성되어 있는상태에서 db별 백업은 다음과 같이 한다.
/usr/local/mysql/bin/mysql -uroot -pPassword DB명< /BackUp/Mysql/Backup.sql

대용량DB 복구를 위한 백업
팁으로 대용량의 Table 을 덤프 받아서 입력할때…
입력속도 때문에 문제가 생기는 경우가 있다.
아마도 대부분이 InnoDB라서 그런 문제가 생기지 싶다.
그럴때는 Table Type 을 InnoDB에서 Myisam 으로 바꾸고 Insert 그리고 다 입력된 다음..
Table Type을 다시 InnoDB로 바꾸는게 빠르다.
그래도 속도가 느리다면 Mysql 에서 LOAD DATA INFILE 을 실행하여.. CSV 같은 데이터를 입력받는게
가장 빠르다.

다음은 하나의 DB(DB에 포함된 모든 테이블 정보)에 관한 DDL문 하나와 각 테이블별 CSV 데이터를 만드는
방법이다. 아래의 명령을 실행시키기 이전에 우선 /백업디렉토리 설정을 먼저해야한다.
갑자기 왠 백업디렉토리 설정이냐라고 물을수 있는데.. CSV 로 만들경우 mysql 이라는 유저권한으로
파일들이 생성되기 때문에 mysql 이 쓰기권한이 있어야한다.

/usr/local/mysql/bin/mysqldump -u root -pPASSWORD DB –no-data > /백업디렉토리/DB.sql
위의 dump 명령은 db 구조만 백업받는것이다.
/usr/local/mysql/bin/mysqldump -u root -pPASSWORD DB –no-create-info –tab=/백업디렉토리 –fields-terminated-by=’,’ –lines-terminated-by=’\r\n’ –fields-enclosed-by='”‘

여기서 주의해야 할것은 각 테이블별로 “–tab=/백업디렉토리” 정의된 곳에 table명.txt 화일로 CSV 화일이
생성된다는 것이다. 만약 –no-create-info 옵션을 주지 않는경우에는 “–tab=/백업디렉토리”에 정의된 대로
해당디렉토리에 테이블 DDL 문장이 테이블명.sql 로 각각 생성이된다.

각테이블별로 DDL문과 CSV 화일을 백업받고 싶다면..
/usr/local/mysql/bin/mysqldump -u root -pPASSWORD DB –tab=/백업디렉토리 –fields-terminated-by=’,’ –lines-terminated-by=’\r\n’ –fields-enclosed-by='”‘
이와 같이 하면된다.

만들어진 테이블DDL문과 CSV 데이터로 복구할때는 아래와 같이..
/usr/local/mysql/bin/mysql -uroot -pPassword < /백업디렉토리/DB.sql
/usr/local/mysql/bin/mysql -uroot -pPassword DB명
mysql> load data infile ‘/백업디렉토리/테이블.txt’ into table 테이블명 fields terminated by ‘,’ enclosed by ‘”‘ lines terminated by ‘\r\n’;

참고1
–tab 옵션을 사용해서 CSV 형태로 백업할때는 –all-database 와 같은 옵션과 같이 사용할수없다.
–tab 옵션은 하나의 DB 이하에서만 사용이 가능하다.
참고2
–fields-terminated-by=’,’ # 필드구분자
–fields-enclosed-by='”‘ # 필드를 특정기호로 감싸는것
–lines-terminated-by=’\r\n’ # 라인구분자(테이블 데이터의 Row 구분자)

 

출처 : http://phpschool.com/gnuboard4/bbs/board.php?bo_table=tipntech&wr_id=54465&sca=&sfl=wr_subject%7C%7Cwr_content&stx=backup&sop=and

 

보내는 메일은 잘 되는데, 받는 메일이 잘 되질 않는다고 한다.

받는 메일서버는 dovecot을 이용한 pop3를 사용중.

 

로그를 보면 아래와 같이 rubi 계정에서 inbox sync를 수행 하지 못하거나 찾지 못하는 증상 확인.

 

/var/log/maillog

Jan 29 17:18:28 atnd dovecot: POP3(rubi): Couldn’t init INBOX: Can’t sync mailbox: Messages keep getting expunged
Jan 29 17:18:28 atnd dovecot: POP3(rubi): Mailbox init failed top=0/0, retr=0/0, del=0/0, size=0

 

그래서 메일 박스 위치의 rubi 계정의 메일박스를 확인 해봤더니 lock 파일이 존재하고 있었다.

락 걸리는 전제조건은 많기에 생략하고, 락이 걸리지 않도록 수정한다.

ls -al /var/spool/mail

hostway.lock

 

vi /etc/dovecot.conf

아래 내용을 추가 후 dovecot 서비스 재시작.