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

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

• Verify Clean-Urls in Apache. Confirm AllowOverride All is in effect, and mod_rewrite is available.
• 업로드 할 때, the Drupal .htaccess 파일 도 업로드. On some systems this file is hidden.
• Check DB support via phpinfo
  _{D7 에서는 MySQL 이외에도 pdo_mysql이 require 됩니다..}
• Check GD image toolkit support in phpinfo, or in the Drupal admin status page.
• Decent php memory_limit (32 M) (phpinfo, php.ini)
• Decent php upload_max_filesize, post_max_size (phpinfo, php.ini) For Drupal to behave as expected, post_max_size must be 2x upload_max_filesize
• Check allow_url_fopen for updates and aggregation if required.
• Check that the include_path contains '.'
• Check that safe_mode is off
• Check the error_reporting level. 인스톨링 할 때 on 할 필요가 있을겁니다. 하지만 production에서는 turn off 하세요. 
• This and more is covered in the Drupal 'requirements' doc and of course INSTALL.txt is the first reference to look at.
• Set up cron! Remember!
  _{If your host is Debian/Ubuntu less than php5/5.2.6-2 PHP sessions may not get cleared correctly, and you may need a workaround for Debian session garbage collection}

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.