[펌]md5(), crypt(), password() 등의 문제점 및 로그인 보안에 대하여..

카테고리 없음 2008. 9. 1. 12:19

로그인에 관련된 보안얘기를 하려고 합니다.

password(); // mysql.
md5(); // php.
crypt(); // php.

뭐, 암호화에 관련된 함수들이 여러 가지 있겠지만 위 3가지 함수는 범용적으로 많이들 쓰고 있고
안정성이 검증된 함수들이죠.. 그리고 모두 복호화가 안되거나, 어려운 해쉬함수들입니다.

흔히 password() 로 암호화시킨 비밀번호... 원래의 값을 절대 알 수 없다고들 표현합니다......

절대 알 수 없다 ?
절대 알 수 없다 ?
절대 알 수 없다 ?

id = 'abcd'
pw = '4ed0bdda4ee8f6a5'

위 pw 원래의 값을 과연 절대 알 수 없을까요 ? 정말 그럴까요 ?


password() 뿐 아니라, md5(), crypt() 등 해쉬함수들이 있는데요....
지금부터 제가 생각하고 있는 바를 차근차근 얘기해 나가려고 합니다....

그다지 어려운얘기 아니고요,

누구나 알 수 있는 쉬운 얘기들뿐입니다..

( 제가 워낙 쉬운 것만 좋아해서 쉬운 것밖에는 모릅니다 ^^ )


--------------------------------------------------------------------------------------


가령,

사용자가 비밀번호를 '3204' 라고 입력한 것을  md5() 로 해쉬시키면

' 640258597cbc50037072712f964cf5d8 ' 라는 값이 나오게 되지요...

md5() 는 디코딩을 지원하지 않는 단방향성 해쉬함수이기에 위 문자열을 보고 원래 값 '3204'를
추출 할 수는 없을 것입니다.

나머지 password(), crypt() 들도 마찬가지죠.. 상당히 어려운 알고리즘을 통해 해쉬된 문자열이
나오면서 원래의 값을 알아낼 수는 없게 됩니다.

특히 crypt() 는 두 번째에 주어지는 salt 값에 따라  똑같은 패스워드를 해쉬해도 결과는
매번 틀리게 됩니다...

가령,

$password = '20930';
$savepw = crypt( $password, md5( time() ) );
이런식으로 하면

실행 할 때마다 94JrlBxXigCZU , 30K4887zrFHBw , 등의 틀린 결과를 나오게 합니다.

모두 대단한 함수들입죠 ~~


------------------------- 그런데, 취약점은 항상 있는 법 --------------------------------

아이디 해킹을 하기위한 몇 가지 조건들이 있기 마련이죠..
그중, 해킹에 의해 DB가 노출되었다고 칩니다......

DB 비번관리를 잘못하던지, 디렉토리파싱을 당하던지 여러 이유로 DB가 노출되었다고 치구요..

DB 내용에는 사용자 계정 정보가

id = 'abcd'
pw = '640258597cbc50037072712f964cf5d8'

위처럼 되있다고 치구요.....


비밀번호가 암호화 되어있으니, 과연 안전할까요 ?

그런데 위 문자열 패턴을 보면, md5 로 해쉬된 것을 쉽게 알 수 있습니다.
지금부터 md5() 함수를 이용해서 원래의 비번을 찾아보도록 하겠습니다.

<?
for( $pw = 0; $pw < 99999; $pw ++ ) {
       if( '640258597cbc50037072712f964cf5d8' == md5( $pw ) ) {
              echo "find ok : $pw ";
              break;
       }
}
// 출력 -> find ok : 3204
?>

간단하게 찾았습니다.



그러면, crypt() 는 안전 할까요 ??

아닙니다.. crypt() 역시 똑 같습니다..

노출된 DB 에.
id = 'abcd'
pw = '12FP8QJo.OCVg';

위 문자열 패턴을 보면, crypt() 로 해쉬된 것을 알 수 있습니다.
이것도 원래의 비번을 찾아보도록 하겠습니다.
<?
for( $i = 0; $i < 99999; $i ++ ) {
       if( '12FP8QJo.OCVg' == crypt( $i, '12FP8QJo.OCVg' ) ) {
              echo " find ok : $i ";
              break;
       }
}
// 출력 -> find ok : 20930
?>

이번에도 결과가 나와 버립니다.


하지만 실제 암호는 숫자만 쓰는 것이 아니고, 문자열을 섞어서 입력하겠지요?
그렇다고 못 찾는 건 아닙니다.
.....
.....
$pw = $chk.chr($i);
if( '640258597cbc50037072712f964cf5d8' == md5( $pw ) ) {
.....
.....
}
$i ++;
if( $i > 126 ) $chk = ( ord( $chk ) + 1 );
.....
.....

저런 식으로 숫자 대신 문자를 자동으로 대입하게 해서 돌아가게 만들면 된다는 것이죠....

수행시간이 오래 걸린 것입니다만,,
문자 하나당 유효값이 93 자 인가? 그러니, 비밀번호가 4글자만 되도
loop 를 93 * 93 * 93 * 93 = 74,805,201 번을 돌아야 할 것입니다...

문제는 요즘 컴퓨터 성능이 워낙 좋아져서, loop 도는 시간이 그리 오래 걸리지도 않고,
또, 단위별로 끊어서 몇 단계 나누어서 병렬로 돌리면 결과는 더욱 빨리 나오게 된다는 것이죠.

그리고, 시간이 좀 걸려서 1주일쯤 걸렸다고 칩니다.
그 1주일동안 해커가 컴퓨터 앞에 매달려 있습니까 ? 잠을 못잡니까 ?
계속 지켜봐야 합니까 ?? 아니면 컴퓨터가 망가집니까 ?

그냥 디코드 돌려놓고 지 할일 하다가 결과 나오면 그때 해킹하는 것이죠...



------------------------------------------------------------------------------

결국은 DB 가 노출되거나, 해쉬된 비밀번호의 결과값이 노출되면 게임은 끝이라는 겁니다.

가령, 비밀번호를 암호화시켰다고 해서 비밀번호를 쿠키로 날아다니게 한다던지,
페이지에 폼값으로 날려준다던지 하는 것은 해커에게 비밀번호를 다이렉트로 알려주는 것과
같습니다......

그럼,

비밀번호 안 날라 다니게 하고 DB노출만 막으면 안전할까요 ??


그것도 만만치 않습니다.

크라이언트에서 서버 접속해서 비밀번호 처음에 날려줄 때,,,,
네트웍을 감시당하면 아예, 원 비밀번호가 그대로 노출될 수 있습니다...

그래서 클라이언트에서도 JavaScript 를 이용해서 나름대로 암호화시킨 문자열을
날아다니게 하지요...

네트웍 감시를 당했을 때, 암호화된 비밀번호가 노출되는 것이구요..

하지만,, 이 역시 결과는 마찬가지죠.......

이 경우는 암호를 풀고 자시고도 없이
그냥 암호화된 비번 그 자체를 login 페이지로 날려서 그대로 접속해 버리면 되지요..
이 경우라면 원래의 암호는 알 필요도 없는 것이지요..


-------------------- 그럼 가장 안전한 방법은 무엇인가 ---------------------------------

개발자는 어떤 상황이던 비밀번호 스트링이 네트웍감시를 당하던, DB 가 노출되던 해서
해커에게 알려진다고 간주해야 합니다.

그럼 이러던 저러던 끝이라는 얘기일까요 ?
... 꼭 그렇지만은 않다고 봅니다.

여기서 우리는 보안을 위해 몇 가지 노력해야 할 것이 있습니다.


#-------------- 비밀번호가 어떤 모듈로 해쉬가 됐는지 모르게 하자.

가장 쉬운 방법은,, 암호화함수 1개에 의존하지 않고 여러 함수를 거쳐 2중 3중으로 돌려야 합니다.



#-------------- 외부에 노출이 안되는 서버만의 고유한 토큰키를 만들자.

가령,

사용자가 '1234' 라는 비밀번호를 쳤을 때 DB 저장할 때는 고유의 '키값'을 정해 눌러서 저장합니다.
예) 키값 '1011' + 비밀번호 '1234' = '2245'
저장도 '2245' 로 저장하고 로그인 인증 때도 또 키값을 더해서 인증하는 것이죠...

'키값'은 절대 DB 에 저장하지 않고, 파일로 접근하게 만듭니다.
서버 자체가 해킹당하기 전에는 절대 볼 수 없도록 실행권한과 접근권한도 설정 되야 겠지요..



#-------------- 클라이언트와 주고받는 비밀번호역시 또 다른 유일한 '키값'을 부여해서 주고받습니다...

서버쪽에서 DB 저장할 때와는 조금 틀리죠...
이 '키값'은 접속시마다 틀리게 합니다.

예) 키값 '0012'

클라이언트 '1234' + '0012' = '1246' ---- 송신 ----> 서버 '1246' - '0012' = '1234' 저장.

그런데,
주고 받을때 사용하는 키값은 클라이언트 페이지에 남아 있으면 안됩니다.

가령,

<form name=hashKey type=hidden value='<?=$hashKey?>'>

저렇게 되 있다면,

Temporary Internet Files 디렉토리만 뒤져봐도 키값이 노출되겠지요...

그러니 페이지에 남기지 않고 로그아웃시 메모리에서 사라지게
lifetime 0 짜리 1회용 쿠키나 세션에 담아쓰면 좀 낳을 수 있겠지요...

페이지에서 쿠키값을 검색해서 '키값'을 뽑아내고 메모리 상에서만 연산을 하면 되겠지요..

저렇게나마 해 두면 네트웍 감시를 당해도

id = 'abcd'
pw = '1246'
이라는 해쉬된 값이 나오기 때문에 원래의 비밀번호 '1234' 는
'키값'을 알기 전에는 무용지물이 되겠지요....

그리고  login 페이지로 '1246'을 날려도 소용없게 해야죠...
주고받는 그 때만 생성되는 유니크한 값을 '키값'으로 사용해서
어떨 때는 '1246' 이 '1234' 로 해석되지만,
어떨 때는 '3266' 이 '1234' 로 해석이 되게 하는 등.....
지속적으로 키값이 바뀌게 해야 하는 것이죠.....


보통 setCookie("hashKey", rand( 1000, 9000), 0 ) 식으로 라이프타임을 0 으로 주면
페이지 접속창이 닫힐 때 까지만 한번 정해진 '키값'이 유효한 상태가 되고,
이후 새로운 창이 열리거나 기존 창을 닫으면 사라지게 되지요..

쿠키도 마찬가지로 라이프타임을 0 으로 주면 되구요,.,



------------- 이정도 가지만 해도 ---------------------------------------------------

# DB 가 노출되었을 때 사용자들을 보호할 수 있습니다.

# 네트웍이 감시를 당해도 원래의 아이디를 모를 뿐 아니라
    해쉬된 스트링으로 로그인을 시도해도 키값이 수시로 변하기에 안전할 수 있습니다.



물론 헤커가 세션과, 쿠키까지 파싱하고, 서버디렉토리도 들락날락거린다면 속수무책이 되게지만,
최소한 실력없는 헤커로부터는 안전을 보장받을 수 있게 됩니다.




아참,
mysql 의 password() 함수를 실험 안 해 보았군요....



id = 'abcd'
pw = '4ed0bdda4ee8f6a5'

<?
for( $i = 0; $i < 99999; $i ++ ) {

       $temp = mysql_fetch_array( mysql_query ( "select password('$i')" ) );

       if( '4ed0bdda4ee8f6a5' == $temp[0] ) {
              echo " find ok : $i ";
              break;
       }
}
// 출력 -> find ok : 50267
?>


* 출처 : http://www.phpschool.com



결론!!!
md5() , crypt(), password() 를 비밀번호 암호화에 사용하지 마세요.
누가 이거 사용해도 된다고 하는거에요?

okjsp에 세영아범님이 사용하지 말라고 하니 해우님이 사용해도 된다고 했는데

전 비밀번호는 복호화가 불가능한걸로 사용을 해야 된다로 생각하고 있습니다.


음.. 문제는 복호화가 안되면 로그인시 어떻게 확인을 하지 인데~~

그건 그렇고 어떤걸 사용할까~~

비밀번호를~~

Posted by [czar]
,

자바 암호화 및 복호화 † JAVA

카테고리 없음 2008. 9. 1. 10:29
자바 암호화 및 복호화 † JAVA

2006/01/04 17:09

복사 http://blog.naver.com/hellowkorea/50000660127

//출처:http://blog.empas.com/inter999/read.html?a=9251209



public class Crypto{
    /**
     * 파일암호화에 쓰이는 버퍼 크기 지정
     */
    public static final int kBufferSize = 8192;
public static java.security.Key key = null;
public static final String defaultkeyfileurl = "defaultkey.key";
/**
     * 비밀키 생성메소드
     * @return  void
     * @exception java.io.IOException,java.security.NoSuchAlgorithmException
     */
public static java.io.File makekey() throws java.io.IOException,java.security.NoSuchAlgorithmException{
  return makekey(defaultkeyfileurl);
}
public static java.io.File makekey(String filename) throws java.io.IOException,java.security.NoSuchAlgorithmException{
  java.io.File tempfile = new java.io.File(".",filename);
  javax.crypto.KeyGenerator generator = javax.crypto.KeyGenerator.getInstance("DES");
  generator.init(new java.security.SecureRandom());
  java.security.Key key = generator.generateKey();
  java.io.ObjectOutputStream out = new java.io.ObjectOutputStream(new java.io.FileOutputStream(tempfile));
  out.writeObject(key);
  out.close();
  return tempfile;
}

    /**
     * 지정된 비밀키를 가지고 오는 메서드
     * @return  Key 비밀키 클래스
     * @exception Exception
     */
    private static java.security.Key getKey()
    throws Exception{
        if(key != null){
   return key;
  }else{
   return getKey(defaultkeyfileurl);
  }
    }
private static java.security.Key getKey(String fileurl)
    throws Exception{
  if(key == null){
   java.io.File file = new java.io.File(fileurl);
   if(!file.exists()){
    file = makekey();
   }
   if(file.exists()){
    java.io.ObjectInputStream in = new java.io.ObjectInputStream(new java.io.FileInputStream(fileurl));
    key = (java.security.Key)in.readObject();
    in.close();
   }else{
    throw new Exception("암호키객체를 생성할 수 없습니다.");
   }
  }
        return key;
    }

    /**
     * 문자열 대칭 암호화
     * @param   ID  비밀키 암호화를 희망하는 문자열
     * @return  String  암호화된 ID
     * @exception Exception
     */
public static String encrypt(String ID)
  throws Exception{
   if ( ID == null || ID.length() == 0 ) return "";
   javax.crypto.Cipher cipher = javax.crypto.Cipher.getInstance("DES/ECB/PKCS5Padding");
   cipher.init(javax.crypto.Cipher.ENCRYPT_MODE,getKey());
   String amalgam = ID;
 
   byte[] inputBytes1 = amalgam.getBytes("UTF8");
   byte[] outputBytes1 = cipher.doFinal(inputBytes1);
   sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();        
   String outputStr1 = encoder.encode(outputBytes1);
   return outputStr1;
}

    /**
     * 문자열 대칭 복호화
     * @param   codedID  비밀키 복호화를 희망하는 문자열
     * @return  String  복호화된 ID
     * @exception Exception
     */
public static String decrypt(String codedID)
  throws Exception{
   if ( codedID == null || codedID.length() == 0 ) return "";
   javax.crypto.Cipher cipher = javax.crypto.Cipher.getInstance("DES/ECB/PKCS5Padding");
   cipher.init(javax.crypto.Cipher.DECRYPT_MODE, getKey());
   sun.misc.BASE64Decoder decoder = new sun.misc.BASE64Decoder();
 
   byte[] inputBytes1  = decoder.decodeBuffer(codedID);
   byte[] outputBytes2 = cipher.doFinal(inputBytes1);
 
   String strResult = new String(outputBytes2,"UTF8");
   return strResult;
}

    /**
     * 파일 대칭 암호화
     * @param   infile 암호화을 희망하는 파일명
     * @param   outfile 암호화된 파일명
     * @exception Exception
     */
    public static void encryptFile(String infile, String outfile)
    throws Exception{
            javax.crypto.Cipher cipher = javax.crypto.Cipher.getInstance("DES/ECB/PKCS5Padding");
            cipher.init(javax.crypto.Cipher.ENCRYPT_MODE,getKey());

            java.io.FileInputStream in = new java.io.FileInputStream(infile);
            java.io.FileOutputStream fileOut = new java.io.FileOutputStream(outfile);

            javax.crypto.CipherOutputStream out = new javax.crypto.CipherOutputStream(fileOut, cipher);
            byte[] buffer = new byte[kBufferSize];
            int length;
            while((length = in.read(buffer)) != -1)
                    out.write(buffer,0,length);
            in.close();
            out.close();
    }
    /**
     * 파일 대칭 복호화
     * @param   infile 복호화을 희망하는 파일명
     * @param   outfile 복호화된 파일명
     * @exception Exception
     */
    public static void decryptFile(String infile, String outfile)
    throws Exception{
            javax.crypto.Cipher cipher = javax.crypto.Cipher.getInstance("DES/ECB/PKCS5Padding");
            cipher.init(javax.crypto.Cipher.DECRYPT_MODE,getKey());

            java.io.FileInputStream in = new java.io.FileInputStream(infile);
            java.io.FileOutputStream fileOut = new java.io.FileOutputStream(outfile);

            javax.crypto.CipherOutputStream out = new javax.crypto.CipherOutputStream(fileOut, cipher);
            byte[] buffer = new byte[kBufferSize];
            int length;
            while((length = in.read(buffer)) != -1)
                    out.write(buffer,0,length);
            in.close();
            out.close();
    }
   
    public static void main(String[] ars)
    throws Exception {
        if(ars.length < 2) {
            System.out.println("USE : java com.crypto.Crypto [-d | -e | -fd | -fe] [text | inputfilename outputfilename]");
            System.exit(0);
        }
        if(ars[0].equals("-d"))
            System.out.println(Crypto.decrypt(ars[1]));

        if(ars[0].equals("-e"))
            System.out.println(Crypto.encrypt(ars[1]));

        if(ars[0].equals("-fd"))
            Crypto.decryptFile(ars[1], ars[2]);

        if(ars[0].equals("-fe"))
            Crypto.encryptFile(ars[1], ars[2]);

    }
}

//출처:http://blog.empas.com/inter999/read.html?a=9251209

[출처] 자바 암호화 및 복호화|작성자 나무꾼

Posted by [czar]
,

휘슬러 솔라 압력밥솥

카테고리 없음 2008. 8. 31. 17:03
휘슬러 솔라 압력밥솥

SOLARㅣpressure cooker
 
솔라 압력솥
234
1.8L(18cm), 2.5L (22cm), 4.5L (22cm), 4.0L(26cm)







독일 국기를 형상화한 삼색의 고급스러운 솔라 패턴의 솔라 압력솥은 다양한 사이즈로 구성되어 있습니다.  2~3인의 한끼 분량 조리가 가능한 실용적 사이즈의 1.8L는 신혼부부의 살림이나 요리를 즐기는 싱글족에게 제격이며, 일반적인 사이즈의 4~5인용의 밥을 하시기에 적당한 사이즈인 2.5L는 깊이가 낮아 일반 팬의 용도로도 활용하실 수 있습니다.

6~7인용의 밥을 하시기에 적당한 사이즈인 4.5L 압력솥은 깊이가 깊어 갈비찜, 삼계탕 등의 요리 시 다양하게 활용하실 수 있습니다. 또한 내부에 찜기와 삼발이가 들어있어 찜요리나 이중 요리도 가능합니다.

4.0L 압력솥 9~10인용의 밥 요리가 가능하며 일반 냄비 뚜껑이 포함되어 있어 압력솥 뿐만 아니라 냄비로도 다양하게 활용하실 수 있습니다. 바닥면이 넓고 깊이가 낮아 볶음 요리나 전골 요리 등의 냄비 요리를 준비하기에 이상적입니다.

쿼트로 세트는 2.5L와 4.5L 바디와 일반 냄비 뚜껑, 압력솥 뚜껑으로 이루어져 압력솥과 냄비 겸용 사용이 가능합니다.


전공정 독일 생산(Made in Germany)

위생적이고 내구성이 강한 스테인레스 스틸 18-10

1,600톤의 순간 고온 및 고압에 의해 삼중 바닥을 접합시키는 프릭션(Friction)공법으로 제작된 바닥

자동 공기 배출 장치로 조리 시 내부의 산소를 배출하여 진공상태를 이루게 하므로 비타민, 미네랄 등 영양소의 파괴를 막아 주고 음식 고유의 맛을 유지

넓어진 단면적으로 높은 열효율과 요리에 무늬를 더해주는 효과를 내는 휘슬러만의 노보그릴(Novogrill) 바닥

3단계의 압력계기밸브로 조리 재료에 따라 압력의 단계를 선택 조절

인체공학적으로 고안된 안심형 손잡이- 뚜껑을 닫는 동시에 자동 잠금

엄격한 독일 안전규격(DIN 66065)심사를 통해 제작


-사용전 스테인리스 스탤 광택 유지 방법

- 찬물에 식초를 적당량(물 한컵당 식초 한스푼 정도)을 혼합하여 끓여 주신호, 주방용 중성세제를 푼 따뜻한 물에 스펀지나 부드러운 천으로 깨끗이 닦은 다음 사용하십시오.

사용시 주의 사항

- 조리 중인 압력솥을 어린이가 만지지 않도록 주의하십시오.

- 본 제품은 주방용 조리 기구입니다. 일반 조리 이외의 다른 목적의 사용을 금합니다.

- 전기레인지, 전기 오븐에서는 사용을 금합니다.

- 실리콘 바킹, 유니매틱 등 소모성 부품은 장기간 사용함에 따라 자연 마모되므로 6개월~1년마다 정기적인 점검 및 교체가 필요합니다.  교체 시기는 압력솥 사용 방법이나 빈도에 따라 차이가 날 수 있습니다.

- 압력계기밸브는 주기적으로 분해, 세척하여 청결한 상태로 사용하여야 합니다.

- 조리 중 뚜껑을 무리하게 여는 것은 금물이며, 압력솥 내부에 압력이 남아 있으면 열리지 않도록 안전하게 설계되어 있습니다.

- 조리중에는 뚜껑을 열지 않으며, 뚜껑을 열어야 할 경우에는 반드시 압력계기가 원래의 위치로 되돌아온 것을 확인한 후에 여십시오.

- 조리량은 압력솥 용량의 2/3 이하로 사용하는 것이 적당하며, 콩 종류와 같이 조리방법에 따라서 조리 중 분량이 늘어나는 것은 1/3 이하로 사용하는 것이 적당합니다.  조리량은 재료, 양념, 수분 등 모든 것을 포함한 양을 말합니다.

-소다와 같이 갑자기 열 반응을 하여 발효하는 재료나, 기름을 사용하여 튀김요리를 할 경우 또는 카레 등 점성이 강한 요리를 할 경우에는 뚜껑을 덮지 마시고, 냄비의 용도로 사용하십시오.

-내용물이 없는 상태에서의 조리는 삼가여 주십시오.

-조리 중 충격을 주지 마십시오.

* 압력솥 사용 전에는 반드시 사용설명서를 숙지하시기 바랍니다.
Posted by [czar]
,

돌잔치 음악

카테고리 없음 2008. 8. 22. 18:11

1. 토토로 - 오케스트라연주

2. 에반게리온OST - 피아노연주곡

3. 포레스트검프 - 피아노연주곡

4. John Williams-Cavatina(해리포터)

5. Reflections of passion-Yanni

6. CF - 감미로운 곡. 예쁜 곡

7.[김광민]러브어페어피아노솔로

8. 이루마(FirstLove)06_It'sYourDay

9. 오르골소리가넘좋은 이웃의 토토로

10. 만화-토토로 오프닝 주제가

11. [동요]방귀대장뿡뿡이

 12. 닥터슬럼프

13. 올챙이송

14. 인어공주-언더더씨(Under the sea)

15. ☆발랄한 생일축하곡모음☆

16. 권진원 - Happy birthday to you

17. 뉴키즈온더블럭-생일축하

18. 동요 - 생일축하노래

19. 테마-귀여운 생일축하곡

20. 포지션 - 생일축하곡

 21. 푸른하늘 - 생일축하합니다

22. 자전거탄풍경 - 그대와함께라면

23. 비쥬-누구보다 널사랑해 ..

Posted by [czar]
,

돌잔치 성장앨범에 어울리는 음악모음

카테고리 없음 2008. 8. 22. 18:08
돌잔치 행사 당일날 식사 할 때 배경음악으로 깔아도 좋은 잔잔한 음악들입니다.
 
영화 '피노키오' 주제곡 When you wish upon a star - Acoustic Cafe
When I Was Young - Steve Barakatt
당신의 소중한 사람 - 수잔네 룬뎅
사랑의 품안에서(L'amour Reve) - 앙드레가뇽
How Deep Is Your Love - Richard Clayderman
어린이의 정경 중 꿈 - 슈만
영화 러브 어페어 삽입곡 Love Affair - Ennio Morricone
                                    Piano solo - Ennio Morricone
멘델스존 (Mendelssohn) / Spring Song In A - Eugen Cicero Trio (오이겐 키케로 트리오)
As You Wish - 이루마
사랑의 꿈 3번 (작곡：리스트) - Various Artists
퐁세 / 나의 작은 별 / 멕시칸 세레나데 - 양고운
Sundial Dreams - Kevin Kern
Angel Over Me - Steve Barakatt
아가에게 - 김수지
Most People Are Nice - Frank Mills
 
☞ 음악 샘플 들어 보기 :
http://openalbum.bugs.co.kr/openalbumview.asp?albumno=287291
 
 
아기가 웃거나 잠잘 때, 즐거운 아기의 모습 등 사랑스럽고 귀여운 아기를 테마로 한 스토
리에 삽입하면 좋은 음악들입니다.
깜찍하고 상큼한 곡으로 골라봤습니다.
 
A lover's concerto - Ash
Happy birthday to you - 권진원
그대 그리고 사랑 - 박지윤
니가 참 좋아 - 쥬얼리
아기코끼리의 걸음마(Baby Elephant Walk) - 핸리 맨시니
모차르트：'아, 어머님께 말씀드리죠' 주제에 의한 변주곡 K.265 - Various Artists
좋은 아침 - 메이세컨
The Happy Song - Frank Mills
마법의 성 -As One
널 사랑해 (I Will) - 7 Princess
Pinocchio - Daniel Vidal
사랑+ - As One
요한 쉬트라우스 / 봄의 소리 왈츠 (피아노 독주를 위한 편곡판) - 조수미
Mother Nature (Feat. Little Trees) -Christian Wunderlich
 
☞ 음악 샘플 들어 보기 :
http://openalbum.bugs.co.kr/OpenAlbumView.asp?AlbumNo=287293
 
 
아기가 조용할 때는? 대부분 말썽을 부릴 때지요. 귀염둥이 아기가 몰래 사고치는 장면에
딱 좋은 음악이 있는데 바로 미션 임파서블에 삽입된 곡으로 빰빰빠바 빰빰빠바~ 하는 긴
장감 넘치는 음악이 있지요?
아기가 재롱떨 때는 경쾌하고 재미있는 음악으로, 말썽부리는 장면에는 긴장감 넘치는 음
악을 삽입한다면 재미있겠지요.
 
미션 임파서블 - Billy May
검은 고양이 네로 - 양고운
영화 '메리 포핀스' 중 침침체리 - 양고운
Hungarian Dance No.5：J.Brahms(1833~1897) - 유진박
영화 '타잔' 삽입곡 Trashin The Camp - Phil Collins
Tarzan And Jone (CF 롯데껌 '황인영 편') - Toy Box
Let's Twist Again - Chubby Checker
니가 참 좋아 - 7 Princess
サラバイ / Happy編 (Off Vocal) - Various Artists
ぽいぽい Peace (Off Vocal) - Various Artists
Surfin USA (Main Mix) - Aaron Carter
Mickey - Toni Basil
 
 
제작진, 출연진 등 엔딩 자막이 올라갈 때 사용하면 좋은 음악으로 빠르고 경쾌한 음악으로
골라봤습니다.
 
Stupid Cupid / Mandy Moore
Juliet - LMNT
It's Alright - S Club 7
Reach - S Club 7
Who Let The Dogs Out - Baha Men 
 
내용출처 : [직접 서술] 직접 서술

(출처 : '돌잔치 성장동영상 사용하면 좋은 배경음악 모음' - 네이버 지식iN)

(출처 : '아기 돌 성장비디오 음악' - 네이버 지식iN)

[출처] 돌잔치 성장앨범에 어울리는 음악모음|작성자 crocop77

Posted by [czar]
,

돌잔치 배경음악으로 좋은 노래들조이

카테고리 없음 2008. 8. 22. 18:07
그녀의 생일 / 뱅크
그대와 함께라면 / 자전거 탄 풍경
기분 좋은 상상 / 여행 스케치
너의 생일 / 이기찬
당신은 사랑받기위해 태어난 사람 / 러브
마법의 성
방귀대장 뿡뿡이
쁘띠쁘띠 / 샹송
사랑의 인사 / 엘가(정경화 바이얼린 협주곡)
생일 축하해요 / 이소라
생일 축하해요 / 비쥬
생일맞은친구 / 김동률
생일선물 / 솔리드
생일선물 / 차태현
생일축하곡 / 디제이덕
생일축하곡 / 정지영의 Sweet Music Box
생일축하곡 / 졸라맨
생일축하곡 / 클리프리차드
생일축하송 / 마릴린몬로
happy birthday to you / 터보
happy birthday to you / 포지션
happy day / 비쥬
happy happy birthday / 소리엘
I Will / 심혜원, 강윤도, 정다빈
If / Sissel
Longer / Dan Fogelberg
Oh Champs-Elysees / Daniele Vidal		 아에이오우 / 예민
아이사랑송
올챙이송
우유송
웃어요 / 유리상자
이 시간 너의 맘 속에 / 김수지
일년만에 돌아왔네 / 자두
생일 축하합니다 / 동요
축하해요 / 이문세
축하해요 / 자화상
축하해요 / 푸른하늘
축하해줄까 / 컬트트리플
키커 체조
해피버스데이 / 엔싱크
해피버스데이 / 컨츄리꼬꼬
Congratulations
Happy Birthday / 스티비 원더
happy birthday to me / 불독맨션
happy birthday to you / 권진원
happy birthday to you / 코요테
Pinocchio / Daniele Vidal
Pretty Boy / M2M
Rico vacilon / karl zero
Solomom Burke / 째즈
TV 유치원 딩동댕송
WeeSing for baby series
You Are The Sunshine Of My Life / 리사 오노



출처 - http://cafe.daum.net/hsh4u
Posted by [czar]
,

mysql innodb 설정

카테고리 없음 2008. 8. 20. 10:17
출처 : 어디서 퍼 왔는지 기억이 안납니다.. 문제가 되면 즉각 삭제 하겠습니다.
==============================================

1. MyISAM



1) 예전의 MySQL 의 Storage Engines 으로 MyISAM 을 사용했었습니다.

    예를 들자면 블로그라던지, 게시판 처럼 한사람이 글을 쓰면 다른 많은 사람들이 글을 읽는 방식에

    최적의 성능을 발휘를 하지요. 지금도 많이 사용하고 있는 방식입니다.



2) 제공하는 웹서비스다 그닥 크지 않다면 이것을 사용해도 괜찮다고 생각을 합니다.





2. InnoDB



1) 트랜잭션-세이프 스토리지 엔진입니다.



2) MyISAM 과 비슷하지만 ORACLE 처럼 많은 기능을 지원을 합니다.

   (* commit, rollback, 장애복구, row-level locking, 외래키 등)



3) 다수의 사용자 동시접속과 퍼포먼스가 증가하여 대용량 데이터를 처리할 때 최대의 퍼포먼스를 내도록 설계되었습니다.
   CPU효율은 어느 디스크 기반의 데이터 베이스와 비교해도 손색이 없고
   자체적으로 메인 메모리 안에 데이터 캐싱과 인덱싱을 위한 버퍼 풀(pool)을 관리합니다.

4) 테이블과 인덱스를 테이블 스페이스에 저장을 하고 테이블 스페이스는 몇개의 서버파일이나 디스크 파티션으로

   구성되어있습니다. 이것은 MyISAM 과 다른 점인데, MyISAM은 테이블과 인덱스를 각각 분리된 파일로 관리합니다.

   여기서 중요한것이 이제 InnoDB 를 제대로 사용을 하기 위해서는 테이블 스페이스 라는 개념을 파악을 하셔야합니다.
   이것에 대해서는 밑에서 따로 언급을 하겠습니다.


5) InnoDB 테이블은 OS의 파일 사이즈 한계가 2GB이더라도 상관없이 어느 크기나 가질 수 있습니다.

6) InnoDB는 높은 퍼포먼스가 필요한 대용량 사이트에 적합합니다.





3. InnoDB 사용하기



1) InnoDB 는 MyISAM 과 공유하는 메모리도 있지만 별도의 Buffer pool을 가지고 있으니까

   InnoDB 전용 DB를 구성한다면 MyISAM 이 사용하는 record_boffer 과 key_buffer 에 너무 많은 메모리를 할당하지 마세요

 
2) InnoDB 설정
   ㄱ) MySql 을 설치한 폴더 아래에 ibdata 와 iblogs 폴더를 생성합니다.
   ㄴ) my.ini 파일 설정을 변경
      * innodb_buffer_pool_size

        - 현재 자신의 시스템 메모리의 50~80% 사이로 만듭니다.

           x86 시스템에서는 2G 이상 설정을 할 수 없습니다.

      * innodb_additional_mem_pool_size

        - 데이터 사전정보 나 내부의 데이터 구조 정보를 담는 메모리 입니다.

           보통 2M 정도 잡아주면 아주 많은 테이블을 사용한다면 좀 늘려주시면 됩니다.

           만약 메모리공장이 부족하면 error log 에 warning 메서지를 남기니 그때 늘려주세요

      * innodb_flush_log_at_trx_commit

        - insert, update 등 데이터 삽입과 관계가 있습니다.

           commit 을 하였을때 그 즉시 commit 된 데이터를 log file 에 기록할지 안할지를 설정합니다.

           로그파일을 기록할 경우 갑작스러운 경우 데이터 손실을 막을 수 있지만 매번 로그를 기록하므로 속도가 저하됩니다.

           1 일경우 기록을 하는것이고, 0일 경우 기록을 안하는것입니다.

      * innodb_log_file_size

        - 트랜잭션을 기록하는 로그 파일의 크기를 결정하는 옵션입니다.

           inno_buffer_pool_size 옵션은 성능을 위한것이지만 시스템이 다운되었을 경우 데이터가 손실이 되므로

           이것을 방지하기 위해 log file 을 만들어서 commit 될때마다 로그에 기억을 하고 자동복구를 합니다.

           로그파일은 무한정 계속 커지는 것이 아니라 일정한 크기와 갯수를 가지고 순환식으로 처리되므로 크기는

           inno_buffer_pool_size 의 15% 정도로 설정을 합니다.

           만약 메모리가 1기가이면 inno_buffer_pool_size = 512M 이고, innodb_log_file_size = 80M 가 됩니다.

      * innodb_log_buffer_size

        - 로그 파일을 기록하기 위한 버퍼 사이즈입니다.

          트랜잭션이 작거나 거의 없다면 크게 잡는것은 낭비이므로 보통 1M~8M 사이로 설정을 합니다.



      [mysqld]

      innodb_data_home_dir="C:/MySQL/MySQL Server 5.0/ibdata/"
      innodb_log_group_home_dir="C:/MySQL/MySQL Server 5.0/iblogs"
      innodb_data_file_path=ibdata1:10M:autoextend:max:1000M
      innodb_additional_mem_pool_size=3469K
      innodb_flush_log_at_trx_commit=1
      innodb_log_buffer_size=2M
      innodb_buffer_pool_size=256M
      innodb_log_file_size=40M
      innodb_thread_concurrency=8
      innodb_log_archive=0


   ㄷ) my.ini 을 수정했으면 mysql 서버를 재시작합니다.

3) InnoDB 테이블 만들기
   create table test_inno (

   ~

   )type=innodb;

   으로 맨 마지막에 type=innodb; 라고 명시해주시면 됩니다.

4) InnoDB 트랜잭션 사용
  ㄱ) 트랜잭션을 사용하기 위해서는 처음에 set autocommit=0; 이나 begin; 을 선언해야 합니다.

      선언 후 데이터 변경이 있을 때, 이상이 없을 경우는 commit를 하고, 이상이 있을 경우 rollback을 실행합니다.
      오라클이랑 비슷하다고 보시면 되요

      mysql>set autocommit=0; //begin; 같음
      mysql>insert into test_inno values (1,'aaa');
      mysql>select * from test_inno; //현재창에서는 입력한 내용이 보이지만 다른창에서는 보이지않음
      mysql>commit; //다른창에서 select를 할경우 입력한 값이 보임





4. InnoDB 테이블 스페이스

좀전에 MyISAM 과 차이점이 InnoDB 는 테이블과 인덱스를 테이블 스페이스 라는곳에 저장을 한다고 하였습니다.

그런데 사용을 하다보니 점차 DB가 늘어나서 테이블 스페이스가 FULL 이 발생하는 경우가 생깁니다.



4.0.x 버전부터는 일일이 할 필요가 없다는 글이 있는데 그래도 FULL이 발생하였을 때 대처방법을 알면 좋겠죠



my.ini 에서 아래와 같이 추가를 해주면 안됩니다.

innodb_data_file_path = /ibdata/ibdata1:1000M:autoextend 라고 할 경우

innodb_data_file_path = /ibdata/ibdata1:1000M;/ibdata/ibdata2:1000M:autoextend 라고 ibdata2를 추가하면 안됩니다.



아래와 같은 과정대로 하세요

1. Use mysqldump to dump all your InnoDB tables.

2. Stop the server.

3. Remove all the existing tablespace files.

4. Configure a new tablespace.

5. Restart the server.

6. Import the dump files.



즉, 일단 mysqldump 로 InnoDB 테이블의 전체 덤프뜬 다음 MySQL 서버를 중지시킵니다.

그다음 테이블스페이스 파일을 모두 지우고 테이블스페이스를 아래와 같이 추가를 합니다.

innodb_data_file_path = /ibdata/ibdata1:1000M;/ibdata/ibdata2:1000M:autoextend

그다음 MySQL 서버를 구동시킨다음 처음에 덤프뜬 파일을 import 하시면 됩니다.





5. 마지막으로

위의 단계처럼 참 어렵게 설정을 하였지만, mysql.com 사이트에 들러보시면 MySQL GUI Tools 라는 프로그램이 있습니다.

물론 무료로 다운로드 가능하고요, 이 프로그램을 설치를 하면 MySQL Administrator 라는 것이 있는데 이것을 통해서

아주 쉽게 MySQL 의 설정을 변경하실 수 있습니다.
Posted by [czar]
,

mysql error Could not open log file, Can't init tc log~~~~

카테고리 없음 2008. 8. 20. 09:59
070607 17:04:59  mysqld started
070607 17:04:59  InnoDB: Started; log sequence number 0 43665
070607 17:04:59 [ERROR] I/O error reading the header from the binary log, errno=-1, io cache code=0
070607 17:04:59 [ERROR] I/O error reading the header from the binary log
070607 17:04:59 [ERROR] Can't init tc log
070607 17:04:59 [ERROR] Aborting

070607 17:04:59  InnoDB: Starting shutdown...
070607 17:05:01  InnoDB: Shutdown completed; log sequence number 0 43665
070607 17:05:01 [Note] /usr/local/mysql/libexec/mysqld: Shutdown 이 완료됨!

이럴경우
mysql-bin.xxxx 와 mysql-bin.index 파일 리스트가 일치 하지 않을 경우 발생

대처법 : mysql-bin.index 파일을 삭제후

./bin/mysqld_safe & 로 스타트..

################################################################################

또한 가끔 mysql 소유권이 root로 된 경우 ./bin/mysqld_safe & 로만으로는 스타트 되지 않는 경우가 있다.
이경우 ./bin/mysqld_safe --user=root &   로 root권한으로 실행하면 됨..

################################################################################
일반적으로 mysql이 스타트 되지 않으면 주로 경로 (/tmp/mysql.sock) 문제인데 이경우는 경로를 바꾸어 주어야 한다.
즉 apm 세팅할때의 경로와 실제 cnt 파일과 일치 하지 않는 경우가 대부분이다.
Posted by [czar]
,

도토리 5개 선물 드립니다. 가져가세여 ^^*

카테고리 없음 2008. 8. 19. 17:15
도토리 5개 선물 드립니다. 가져가세여 ^^*

   ☜  도토리 공짜 받아가세요,!!  click,!!
Posted by [czar]
,

리눅스와 윈도우 서버 성능 비교

카테고리 없음 2008. 8. 18. 01:27

http://www.webperformanceinc.com/library/reports/windows_vs_linux_part1/



  1. Throughput: How much response bandwidth the server is able to generate.
  2. CPU Utilization: How taxed is the server becoming.
  3. Errors per Second: How frequently is the server unable to respond.
  4. Requests per Second: At what rate is the web browser making requests from the server.
  5. Hits per Second: At what rate is the server responding to requests from users.
  6. Duration: How long can a user expect to wait before the page is complete.

Throughput

We start off with how much throughput the server was able to sustain under an increasing load. This measurement is taken from the total MegaBytes of HTTP traffic, and does not consider lower level implementation overhead.

The sudden drop-off in traffic is somewhat surprising. Examining the Tomcat server logs for Windows displays some OutOfMemoryExceptions as the server is pressed under increasing load. The same logs for Linux, however, revealed no illuminating information.

CPU Utilization

The CPU Utilization will give some insight as to how well the server was able to cope with the increasing load, and whether or not the server seemed too computationally overwhelmed to process any further users. Each server in the test was equipped with one CPU with HT Technology enabled. For simplicity, we will then examine an average of the processor load of the two reported virtual CPUs.

Evidently, both servers continued to consume the CPU linearly with load, up to roughly equal proportions. However, the load eases off just slightly, but only slightly, during the server's slump in throughput. As the throughput once again begins to increase, the CPU increases as well.

The still relatively high CPU utilization during the throughput slump confirms our suspicion that Tomcat and the JVM are still chugging along, evidently running memory management or optimization cycles.

Errors per second

During our testing, the only errors that made themselves evident to the end user were transmission errors occurring when a user would attempt to open a connection to the server. To them, this means their web browser will display an error message, usually similar to "Connection refused by server". Every page returned during this test was a complete page, and not an error page from the server. Please note that since the Windows server showed significantly more tendency towards generating errors, this plot is scaled logarithmically.

Server Responsiveness

Now, let us examine the number of completed requests per second as measured by the testing tool. This number is permitted to decline with the number of users as the server becomes unresponsive and users are forced to wait before they can make another request. Under normal circumstances however, the number of requests should be equal to the number of responses received, and should overall be directly proportional to the total throughput of the server.

Interestingly, our Windows server here elects to maintain a consistent level of responsiveness to the user, preventing the web browser from having to wait a significant amount of time for a response. During our performance slump, we note that the server simply refuses further connections from the user, giving them an immediate error. By contrast, our Linux server appears accept the connection, and only responding when it is free to do so completely.

Hits per Second

After having seen how quickly requests were being issued to the server, let us move to the response rate from the server. The Hits per Second measures the rate of completed HTTP responses that were received from the server.

It seems here that even during the slump, despite error handling techniques, the rate of successful HTTP messages processed remains roughly on par between our servers, once again showing a very slight favoring towards our Linux installation.

Duration

For our last performance aspect, we concern ourselves with how long is a user going to be taking in order to complete their task. We are measuring the full time until a response was received from a server, waiting until it has arrived before moving onto the next page of the test.

For the duration times for a business case, the baseline for each graph is defined as the amount of time the user spends "interacting" with the page before moving on to the next page. The simulated time spent by the user on the last page is therefore omitted.

The duration graphs here show the full range of measured durations during a given interval (dark background), with the averages on top (highlighted points).

Long Scenario

Medium Scenario

Short Scenario

In our long case (where the user must navigate through the longest list of pages) the anomalies have had a nice chance to average out through one page or another. As expected, we see the results of our throughput slump by increased wait times from the server. For Linux, as the load approaches this turning point, the duration is seen to increase, but never fully recovers. For our other cases, the general trend remains the same with the affect on the average duration declining with shorter test cases.

Static & Dynamic Content

From these cases we see some relatively consistent increases in linux duration of each business case, but the question remains, were those increases attributed to the server being swamped by multiple requests, or were they simply getting hung by the dynamically generated portions of the page. Please note that since the maximum durations are significantly different, these graphs are scaled logarithmically.

It is interesting to note here that there is a very slight but consistent increase in average durations for both servers, though more pronounced on our Linux server. Under load, the maximum duration for windows rarely peaks above 10 seconds, where Linux steadily maintains maximum durations over 100 seconds.




사용하기는 윈도우가 편하긴 한데

믿음은 리눅스가 좀더간다. 리눅스 공부해야하는데~~  지금 서버 1년만에 다운됐고..

Posted by [czar]
,

티스토리툴바