블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 IT 프로젝트에서 사용되는 툴들에 대해 많은 분들과 정보를 공유하고 싶습니다.
솔웅

최근에 받은 트랙백

글 보관함

calendar

        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  


How do I unset the clean URLs?

Last updated March 18, 2011. Created by dman on February 2, 2004.
Edited by mr.baileys, jonhattan, jwuk, greggles. Log in to edit this page.


clean URLs를 하지 않고 두루팔을 옮긴 경우가 발생할 수 있습니다. 그러면 모든 링크는 제대로 작동하지 않을 겁니다. 왜냐하면 이미 생성된 path는 hosting platform에 의해 지원되지 않기 때문이죠.


This occasionally happens아래의 경우도 발생할 수 있습니다.

  • 호스트 간 데이터베이스를 transfer 한 이후
  • local copy를 한 이후
  • 백업에서 restoring 한 이후 (.htaccess 가 없을 경우)
  • .htaccess 가 지워진 경우
  • 혹은 여러분 호스트에서 원하지 않은 security change가 있는 경우


문제는 여러분은 세팅을 할 수 없게 됐다는 겁니다. 왜냐하면 configuration page를 더이상 링크해서 들어갈 수 없기 때문이죠.

드루팔 (Drupal)은 여러분이 해당 링크에 접근하도록 하기 전에 먼저 clean URLs 가 지원되는지 부터 체크 하고 계속 작업이 이루어 질 수 있는지 여부를 체크합니다.




이 문제를 해결의 가장 간단한 방법은 unclean 시스템 path를 직접 entering 하는 겁니다.

여러분 스스로 lock 됐다면 아래 경로를 통해서 접근하세요.
http://example.com/?q=user

그 페이지에서 여러분은 로그인을 할 수 있습니다. 그러면 admin 권한을 받을 수 있겠죠. 아직까지 모든 링크는 작동하지 않을 겁니다.

다음으로는 아래 url로 접근하세요. (Drupal 5와 Drupal 6 의 경우). 그러면 여러분이 unset clean URLs를 할 수 있는 페이지를 보실 수 있을 겁니다.
http://example.com/?q=admin/settings/clean-urls

이제 여러분은 사이트를 제대로 이용할 수 있을 겁니다. 링크가 제대로 걸릴 테니까요.

Other options that should get the same result include:

다른 방법도 있습니다.

  • Drush command를 실행하세요.

    drush vset clean_url 0 --yes

  • mysql command를 실행하세요.

    UPDATE variable SET value = 's:1:"0";' WHERE name = 'clean_url';
    DELETE FROM cache;
  • 혹은 settings.php를 수정하셔도 됩니다.
    $conf['clean_url'] = 0;


저작자 표시 비영리 동일 조건 변경 허락
신고

두루팔 옮기기 2 - 체크 리스트 -

2012.07.18 21:43 | Posted by 솔웅


Checklist for migrating to a new server

Last updated October 31, 2011. Created by dman on November 13, 2008.
Edited by xamount, Kami Petersen. Log in to edit this page.




두루팔을 새로운 호스트로 옮기고 사이트를 활성화 할 때 살펴봐야할 것들이 있습니다.

이 체크리스트는 이미 로컬이건  호스트된 서버이건 사이트가 돌아가도록 하는데 성공했지만 다른 host나 architecture에 이 사이트를 옮겨야 할 필요가 있는 사람들을 위해 쓴 글입니다. 서버별로 그리고 버전별로 조금 다를 수가 있습니다. 그러니까 옮기고 난 이후에 겉으로 잘 돌아가는 것 처럼 보여도 여러 테스트를 해야 합니다. 

아래 체크 리스트들이 많은 것 처럼 보이지만 이 리스트 들 중 대부분인 이미 제대로 세팅 돼 있을 겁니다. 하지만 옮긴 이후에 체크를 해서 문제 없다는 것을 확인 해야 이후에 발생될 여러 문제점을 예방할 수 있습니다. 여러분들 중 대부분은 아래 작업을을 해 보셨겠지만 사이트를 옮긴 후에 이 작업을 반복해서 해야 합니다. 이 체크리스트대로 하지 않고 이미 업로드를 해 버렸고 제대로 작동하지가 않는다면 unset clean-urls 를 manually 해야 합니다.



Server basics


Drupal UI

  • TEST an upload.
  • TEST an image derivative rebuild.
  • Review access control settings for admin/editor/authenticated/anonymous users.
    각 role 별로 로그인을 한 후 체크하세요. big file을 업로드 할 수 있는지 input filter 등을 사용할 수 있는지 등등.


Permissions checks

  • Adjust write-access to sites/${SITENAME} (if installing) and sites/${SITENAME}/files
    • Check at admin/settings/file-system, it'll warn you if there's a problem.
    • What you need to do and what you CAN do to adjust permissions on the server will vary between systems.
  • check write-access to /tmp . Change it to sites/${SITENAME}/files/tmp (no leading slash) if needed.


Security tweaks

  • 셋업을 하고 난 후 모든 코드가 security 때문에 read-only  되 있는지 체크해 보세요.
    See more at File Permissions and Ownership For Security.
  • 새롭게 생성된 파일과 폴더의 owner와 group을 확인하세요. Check the owner and group of any newly created files and folders
    ls -la files/
    If the owner of web-process created files is the same as your login username (not www-data), that means it's theoretically possible for web scripts to modify themselves. This is a hack vector, and could be a concern.
  • settings.php 를 체크하세요. 여기에 database 암호가 text로 돼 있습니다. 이 파일의 접근 권한을 보고 모두에게 readable 돼 있지 않나 살펴 보세요. 만약에 그렇게 돼 있으면 웹을 통해서 여러분 디비의 암호가 노출 될 수 있습니다.
    For this reason, it would be good to have your :
    - Admin-control panel-ssh login password different from your
    - database password different from your
    - Drupal user #1 password.
    ...even though that's a pain.
  • If you have enough rights, consider shifting htaccess directives into apache configuration files for performance.
  • Remove phpinfo.php if you had one.


Testing

  • TEST directory browsing is disabled for files/ (by attempting to access it in a browser)
  • TEST that www.example.com and example.com perform the same, preferably by redirecting one to the other. See .htaccess [handbook doc needed?]
  • TEST email sending. Email setup is different for different hosts, but should be configured already by the sysadmin.
  • Check the email:from headers and see what you can do to avoid system emails going into a spam bucket
  • More testing ideas.


Best Practice Extras

  • Run a links checker. Xenu is simple for windows. linklint is adequate for commandline.
  • Visit your admin/reports after running a link checker and see what shows up. Other errors, not just 404s may appear there and need attention.
  • Consider benchmarking Drupal Performance. apachebench (ab) is OK, but needs root and just whacks one page. siege is better (can script a session), but needs installing.
  • If you have a high level of control on the server, Consider other tuning issues like PHP accelerators.
  • Consider your backup plan.
  • TEST your backup recovery.
  • Remember to configure and test any non-Drupal logging tool you may want to use. eg, Webalizer, Google Analytics or something provided by your host.
    Now is a good time to locate your server logs, and make sure you have access to them from your host. When you need them to troubleshoot problems it's too late to find that they don't exist.
  • Document every password, path and IP you can find. Domain registration, Control Panel login, User account info, FTP server, MySQL connection string, location of the config files for your backups, contact details for key parties etc. Put it all in a document with a DATE in it. Print that off and save it in three SAFE places.
  • Review your hosts policies on overages. It's much better if your host provides a warning & throttle service when/if you overrun your bandwidth or storage allocation than if they let it run then charge and penalize you (or just shut you down). Some hosts also punish 'excessive' use of the database or processor - which Drupal can be guilty of. Read the fine print.


저작자 표시 비영리 동일 조건 변경 허락
신고


지금 사용하던 Drupal 을 다른 곳으로 옮겨야 됩니다.
두루팔 사용경험이 하나도 없어서 부랴부랴 정보 researching 하고 있습니다.

혹시 두루팔을 A 서버에서 B 서버로 Migration 하는 방법 아시는 분 있으면 정보 부탁드립니다.



Last updated April 13, 2012. Created by LeeHunter on April 20, 2010.
Edited by John_B, sebastianSue, vj_pdx, ajspadial. Log in to edit this page.


만약 host를 바꾼다던가 개발서버와 실제 서버를 분리해서 관리를 할 경우에는 Drupal site를 migrate 할 필요가 있을 겁니다. 이 글은 이 일에 대한 outline 입니다. (아마 체크리스트라고 해야 할 것 같습니다.) 하지만 다른 곳에서는 제대로 묘사되지 못한 몇가지 스텝들도 포함돼 있습니다. 여러분들은 여러분들이 사용하는 모듈과 여러분 서버의 환경에 따라 이 스텝들을 약간씩 수정할 필요가 있습니다.

아래 과정은 한개의 site에 대한 과정을 담고 있습니다. Multi-site migration (Windows/Apache와 Linux) 은 다른 곳에서 다뤄지고 있습니다.


Before You Start


두개의 서버에 있는 PHP installation의 차이점을 정리해 두세요. (버그들이나 기능, 모듈, configurations, version 등등). 그리고 MySQL과 Apache 에 대해서두요.

파일을 업로드하고 다운로드하고 압축된 파일들을 다루고 퍼미션과 ownership을 수정하고 MySQL을 다루고 하는데 필요한 적절한 툴들을 준비하세요. 이런 스텝들을 다루는 Drupal tools들이 몇개 있습니다. 예를 들어 데이터를 백업하고 restoring 하는 것들 같은거요. 그렇다고 모든 과정을 다 처리해 주지는 않습니다. 여러분들이 아래 과정을 진행하는데 도움을 주는 툴이 있으면 사용하시고 아니면 그냥 직접 다 하셔도 됩니다.

새로운 사이트로 migrating 하기 위한 체크 리스트 - target site에서 두루팔이 필요로 하는 모든 기능 (mod_rewrite, AllowOverride) 등을 모두 지원하고 있어야 합니다. 전부 지원해 주는 호스트에서 조금 지원해주는 호스트로 옮기면 제대로 작동하지 않을 겁니다. 이건 migration에서 뭔가 잘못되지 않아도 target host의 세팅에 문제가 있으면 제대로 작동하지 않을 수 도 있다는 것을 말합니다.



On the old site

  1. 사용된 모듈과 버전 그리고 path 같은 것들을 정리해 두세요. contributed module site documentation이 이런 작업을 쉽게 할 수 있도록 할 겁니다.
  2.  admin/settings/file-system에서 사용될 수 있도록 temporary directory folder를 정리해 두세요. 그리고 database를 restoring 하고나서 수정할 수 있도록 준비해 두세요. 두 site 무도에 same path 가 존재하고 있어야 합니다.
  3. site maintenance mode를 세팅하세요 : Administer -> Site maintenance, Off line 선택
  4. 두루팔 core와 모듈을 최신버전으로 업데이트 할것인가에 대해 migration 하기 전에 결정하세요.
  5. Clean URLs를 Turn off 하세요. (Administer -> "Clean URLs") . 이제부터 www.example.com/?q=user 를 통해 administrator 부분으로 들어가게 될 거라는 것을 기억해 두세요. ("user"는 다른 유저 이름에 의해 replace 되지 말아야 합니다.)
  6. cache tables로부터 데이터를 clear 해 주세요. 이 데이터들은 transfer 에 필요하지 않은 데이터들입니다. 그리고 데이터를 정리할 때 혼란을 야기시킵니다. devel 모듈과 admin menu module 에는 이것을 쉽게 할 수 있는 link를 포함하고 있습니다. 다른 방법으로는 www.example.com/admin/settings/performance 로 가서 페이지 아랫쪽에 있는 Clear cached data 버튼을 누르세요.
  7. database를 Export 하세요. MySQL Administrator나 phpMyAdmin 을 사용해서 export 할 수 있습니다. 이렇게 해서 .sql 확장자를 가지는 text 파일로 된 데이터베이스 정보를 가질 수 있습니다.


    • MySQL Administrator 에서 우선 패스워드를 사용해서 접속하시고 왼쪽의 Backup 버튼을 누르세요. Databases 리스트에서 save하기를 원하는 데이터베이스를 선택하세요. 큰 화살표를 누르세요. 그러면 데이터베이스 이름을 오른쪽에 있는 네모칸인 Backup content 로 옮길 겁니다. 그 다음엔 오른쪽 아래에 있는 Start backup 버튼을 누르세요. 저장할 폴더를 선택하시고 이 때 윗쪽의 path par와 왼쪽의 Folders 리스트를 사용하시면 됩니다. 그리고 OK 버튼을 누르세요.
  8. 이전의 site 가 public (web에서) 이면 여러분 site를 on line으로 하는 것을 고려해 보세요. :  Administer -> Site maintenance 에서 on Line을 선택하시면 됩니다. 이제 예전 서버에서 만들어진 모든 modification은 잃어버릴 겁니다. (readers' comments, forums posts 등 등). 그러므로 여러분의 old website를 on line으로 set back 하시고 웹에서 public이라면 새로운 유저가 입력한 새로운 comments 등이 유실되지 않도록 new comments를 block 하면 좋을 겁니다 Administer -> Permissions.
  9. 모든 Drupal code를 copy 하세요. core, modules,themes 등을 copy 하고나서 필요하면 다운로드를 받으세요. 아니면 곧바로 새로운 서버로 transfer 하셔도 됩니다.
  10. files 디렉토리와 비슷한 다른 directory (image galleries 등)들도 copy 히세요. 그리고 다운로드 하시던가 새로운 서버에 곧바로 transfer 하세요.


In between

이 과정들은 old/new server와는 다른 여러분의 컴퓨터에서 수행 되어 질 겁니다. 만약 old 나 new 서버에서 작업하는 것이 더 쉽다면 그렇게 하셔도 됩니다. 쓸데 없이 다른 컴퓨터에 파일들을 복사해 넣을 필요는 없으니까요.

데이터베이스의 데이터들은 hard code 된 링크들을 가지고 있을 겁니다. 이런 링크들은 새로운 사이트에서는 필요가 없겠죠. 이것들을 수정하기 위해서 새로운 데이터베이스에서 SQL query를 사용하실 수 있습니다. 혹은 .sql 파일에서 직접 수정을 하실 수도 있겠죠. 이 작업을 하시면서 아래 내용들을 고려하세요.

  1. files table 에 있는 filepath field 의 files list.
  2. 사이트 URL - 많은 node 링크들과 reference들이 full site URL을 참조합니다. 그리고 많은 log file들을 참조하기도 하죠. 그렇기 때문에 new site의  name으로 바꾸는 것이 항상 적당한 것은 아닙니다. 그러니까 이 작업을 각각의 테이블단위로 하시고 고민하세요.
  3. 위 내용들을 variation 하세요. 예를 들어 messaging module은 messaging store에 각각의 message에 대한 site URL을 저장합니다. 그리고 imagefield 모듈은 filelist 같은 리스트가 있지요.
  4. 새 데이터베이스를 create 하기 위한 facility들 (아래의 Import Your SQL data를 보세요.)
  5.  데이터베이스 이름. 호스팅 회사에서는 모든 데이터베이스 이름 앞에 yourName_ 를 붙이도록 할수도 있습니다. 그리고 데이터베이스 이름에 들어가는 text 갯수를 제한할 수 도 있습니다.
  6. 아래 command는 두루팔을 A site에서 B site로 옮길 때 옮겨질 필요가 없는 데이터베이스의 데이터를 strip 하게 할 수 있습니다.
    sed -E -e "/^INSERT INTO \`(cache|watchdog|sessions)/d" < /path/to/dump.sql > /path/to/dump-stripped.sql
    만약 여러분의 database가 table prefix를 사용한다면 이 명령어를 약간 수정하실 필요가 있을 수도 있습니다.

만약에 실제 운행되고 있는 live site 에서 move 하거나 또는 live site로 move 한다면 여러분은 DNS 세팅을 수정해서 새 서버에 pointing 할 수 있도록 해야 할 필요가 있습니다.


On the new site


이제 new site에서 위의 과정을 거꾸로 진행하셔야 합니다.

  1. 전체 Drupal code (core,modules,themes) 를 new site로업로드 혹은 copy 합니다. 여러분이 원하시면 구조를 약간 바꾸셔도 되죠. 어떤 분들은 새 버전의 drupal core를 먼저 install 해서 새로운 server 환경을 테스트 하는 분도 계실겁니다.
  2. files directory나 비슷한 디렉토리들(image galleries 같은)를 업로드 혹은 copy 합니다. 업로드 혹은 copy 장소는 .sql 파일을 수정할 때 사용하게 될 위치가 되겠죠.
  3. 두루팔이 사용할 데이터베이스 유저를 생성합니다. 호스팅 회사에서는 여러분의 모든 데이트베이스 유저 이름 앞에 yourName_을 붙일 수도 있고 그 이름의 text 숫자에 제한을 둘 수도 있습니다. 여러분 호스팅 회사에서 create 쿼리를 허용한다면 .sql 파일 에 유저 생성 쿼리를 넣고 이 과정을 건너 뛰셔도 되겠죠.
  4. SQL data를 업로드하고 import 하세요. 데이터베이스를 직접 생성할 수 없다면 호스팅 회사가 제공하는 툴을 사용하실 수 있을겁니다. 이런 경우는 .sql 파일 안에 create database 라인을 지워주세요. (create database if not exist 라인은 상관없습니다.) phpMyAdmin으로 데이터베이스를 업로드하기엔 사이즈가 너무 클 수도 있습니다. 어떤 호스팅 회사는 MySQL Administrator로 접근할 수 있는 권한을 주기도 합니다. 그런 경우 용량이 큰 파일을 사용할 수 있습니다. SSH 접근을 가지고 있다면 text  console에서 MySQL을 사용하실 수 있을 겁니다. "mysql --user=user_name --password=your_password database_name" 그리고 sourch command도 사용하실 수 있겠죠. source database_backup.sql
  5. settings.php의 Database setting 섹션부분을 바꾸세요. 이 부분에서 new database로 경로가 설정 돼 있어야 합니다. 예전 서버와 다른 유저가 세팅 됐다면 유저도 제대로 설정해야 하구요.  패스워드도 마찬가지 입니다. 그리고 sub-domain과 domain level을 옮기셨다면 base URL을 수정하셔야 합니다.  그리고 $cookie_domain이 예전 도메인으로 설정돼 있지 않은지 체크하세요.
  6. 그리고 .htaccess 파일의 rewrite rule을 수정할 필요도 있습니다.
  7. new site로 log on 을 시도해 보세요. 아마 site maintenance mode와 non clean URLs의 combination에 의해 lock 돼 있을 겁니다. 이 경우에는 newsite/?q=user로 로그인을 하세요. 그리고 clean URLs를 turn on 하세요.
  8. site information부분을 수정하실 필요가 있습니다. (Administer → Site configuration → Site information). 여기에는 모든 email address 가 있습니다. 그리고 filedirectory를 (www.example.com/admin/settings/file-system) 파일이 새로 옮겨진 곳으로 바꿔 주세요. 또한 temp folder 도 다르다면 새로운 서버의 정확한 location으로 수정하세요. 
  9. 필요하다면 새로운 버전에 맞게 모듈들을 수정해 주세요. 예를 들어 PHP 5.2.8에서 5.3.0 으로 업그레이드 됐다면 어떤 모듈들은 제대로 작동하지 않을 수도 있습니다. 이럴 경우 여러곳에서 에러메세지를 보실 수 있을 겁니다. 아래 제가 search 한 에러의 내용들 입니다.

    • Set date.timezone = php.ini file안의 UTC  (아마 이 파일이 두개 있을 수 있는데요. 하나는 command line 용이고 다른 하나는 Apache 용인데 여러분의 경우엔 아파치용을 수정하셔야 할 겁니다.)
    • Apply patch 6.x-2.x-549884-30.patch to the date module
    • Use 6.x-3.x-dev instead of 6.x-3.0-alpha3 for the admin_menu module
    • Drush 와 함께 작동하지 않는 coder module을 delete 하세요. (하지만 이 부분이 항상 이 문제 때문인지는 확실하지 않습니다.)
  10. Check the status report: Administer → Reports → Status report. Drupal 에서 suggest 한다면 Cron을 Manually 작동시키세요.
  11. 이제 여러분의 new site는 예전 사이트 처럼 작동할 겁니다. 예전것과 구분하기 위해서 theme 이나 theme color를 바꾸고 싶을 수도 있을 겁니다.
  12. 필요에 따라 performance 파라미터도 수정하세요. Administer → Site configuration → Performance.
  13. 모든것을 다 체크했다면 site-maintenance mode를 turn off 하실 수 있습니다. : in Administer → Site configuration → Site maintenance, choose "On line".
  14. 여기서 설명한 대로 cron job을 셋업하세요. 이 크론은 어떤 컴퓨터에서든 온라인으로 run 할 수 있습니다. 여러분 PC에서도 가능합니다. 반드시 Drupal이 돌아가고 있는 서버여야 할 필요는 없습니다. 원하는 컴퓨터를 선택하세요. (항상 turn on돼 있고 on line  돼 있는 컴퓨터야 겠죠.) 만약 호스팅 컴퓨터가 크론 사용을 허용하지 않고 여러분에게 이 작업을 할 만한 컴퓨터가 없으면 Poormanscron 모듈을 사용하세요.
  15. 여러분의 새 두루팔 서버가 public으로 되기를 원하신다면 (예를 들어 WEB에 개방한다던지) 지금 DNS를 세팅해야 합니다. 여러분의 새로운 서버의 IP에 DNS를 세팅하세요. 이 작업을 하려면 domain name register를 contact 해야겠죠. 만약에 두루팔 사이트가 이미 웹에 있다면 그리고 여러분의 migrating이 public server에서 다른 곳으로 이뤄졌다면 이 register를 바꿀 필요가 있습니다. 이 경우에는  new registrar의 contract를 잘 읽어 보세요. 그리고 registrar를 바꾸기 전에 예전 registrar의 데이터베이스에 있는 DNS를 업데이트 하기를 추천합니다. TLD(top level domain)에 따라 (아마 EPP code, authorization code, Auth code라고 불리는 코드가 필요할 겁니다. 예전 registrar에 물어보세요. 그 다음에 이 코드를 새로운 registrar에 할당하세요. (아마 새로운 호스팅 회사를 통해서 가능할 겁니다.) 그 다음에는 기다리셔야 됩니다. 대가 5일 정도 시간이 걸립니다. 만약 이 작업에 아주 익숙하시다면 migration 작업 하기 전에 시간에 맞춰서 작업하셔도 되겠죠. 단지 여러분 작업이 완료되기도 전에 DNS transfer가 끝났다면 그 동안은 페이지 접근이 안되겠죠.



저작자 표시 비영리 동일 조건 변경 허락
신고
이전 1 다음

티스토리 툴바