Migration 진행 사항 공지
안녕하세요. KLDP.org migration 진행 사항을 공지 합니다.
현재, 이 글을 보시다시피 Draupal 7을 위한 database 및 application migration은 완료되었습니다. 한번 예행 연습을 해서 그런지 생각보다 일찍 작업이 완료되어, 뒷정리가 좀 남았지만 먼저 서비스 open을 하게 되었습니다.
현재 까지의 작업 내용은 다음과 같습니다.
1. 안녕 리눅스 3 업그레이드
2. Mariadb 10.1 업그레이드
3. InnoDB format을 Antelope 에서 barracuda 로 변경
4. PHP 7 업그레이드
5. HTTP/2 지원
6. Drupal 7 migration
일단, 서비스는 가능 할 것 같아 open을 했으며, Drupal 6 시절의 설정값이 migration 시에 소실된 부분이 많이 있기 때문에 권한 문제 같은 것이 발생할 수도 있을 것 같습니다.
문제가 있으면, 이 글에 댓글로 남겨 주시면 가능한 처리해 보도록 하겠습니다. 다만 최악으로, 8/17 상태로 rollback 의 가능성도 있습니다.
P.S.
migration 후, 반응 속도가 좀 느린 것 같습니다. 이 부분은 migration 마무리가 되는대로 대응하려 합니다.
그리고, Noto Sans CJK KR web font를 사용하고 있어, FOUT 현상(웹폰트가 로드 되기 전에 화면에 글자가 나오지 않거나, 또는 기본 폰트 출력 후에 웹폰트로 변경되는 현상)이 발생할 수 있습니다. Noto Sans CJK 폰트가 워낙 사이즈가 큰 관계로, 3G 환경 같은 곳에서는 처음 페이지 로딩이 쉽지 않을 수 있습니다. (이 부분에 대해서는 media query를 이용해서 웹폰트를 제공하지 않는 것을 고려하고 있습니다.)
일단, FOUT 현상이 거슬린다면, Noto Sans CJK KR 폰트(https://noto-website.storage.googleapis.com/pkgs/NotoSansCJKkr-hinted.zip)를 시스템에 설치 하시면 이 문제는 해결이 되오니 참고 하시기 바랍니다.
댓글
작업 진행하시느라 고생하셨습니다.
작업 진행하시느라 고생하셨습니다.
당장은 생소한 느낌이지만 곧 익숙해지겠죠. 'ㅡ')
깔끔하네요. 수고 하셨습니다.
깔끔하네요.
수고 하셨습니다.
고작 블로킹 하나, 고작 25점 중에 1점, 고작 부활동
"만약 그 순간이 온다면 그때가 네가 배구에 빠지는 순간이야"
개인적으로는 더 빨라진 느낌이네요. 수고하셨습니다.
개인적으로는 더 빨라진 느낌이네요.
수고하셨습니다.
소곤소곤
마이그레이션 수고하셨습니다 ~
마이그레이션 수고하셨습니다 ~
깔끔하고 좋습니다
수고 많으셨습니다.
좋네요
언제나 감사히 잘 쓰고 있습니다.
대충 migration 작업은 완료 된 것 같습니다.
대충 migration 작업은 완료 된 것 같습니다. 혹시 Noto Sans 웹 폰트 때문에 화면의 글자 출력이 느리신 분들은 (외국의 폰트 사이즈가 좀 커서 ..) 시스템에 Noto Sans CJK KR 폰트(https://www.google.com/get/noto/#sans-kore)를 설치 하시면 한결 빨라 질 겁니다.
Mac OS X, iOS 에서는 "Apple SD
Mac OS X, iOS 에서는 "Apple SD Gothic Neo" 로 출력되게 수정 했습니다.
feed 받아보기가 좀 난감하네요.
전에는 https://kldp.org/taxonomy/term/5+6/0/feed 로 "KLDP - 프로그래밍 QnA, 설치 및 활용 QnA" 를 한번에 받아왔는데, 이젠 안되나요 ?
7에서 combination을 지원하지 않는 듯 싶은데요
음 drupal 7의 taxomony에서 기본으로 AND 결합을 지원을 하지 않는 것 같은데요. --; 다른 방법을 강구해 봐야 할 듯 싶습니다.
일단 제가 taxomony에 대한 인지가 없어서, 순선옹 복귀하면 다른 방법이 있는지 확인해 보도록 하겠습니다.
View에서 Taxomony term을 enable
View에서 Taxomony term을 enable 시키고 multiple value를 허가해 주니 가능하네요. drupal 6에서는 그냥 기본으로 지원이 되었는데, 7에서는 설정을 해 줘야 동작하도록 변경이 된 듯 싶습니다.
확인 해 보시고 이상 있으면 다시 댓글 달아 주세요.
아주 잘 됩니다.
이런 사소한 것까지 챙겨주셔서 감사합니다.
좀 찾아봤는데 이게 drupal의 기본 모듈이
좀 찾아봤는데 이게 drupal의 기본 모듈이 아니라서 아마 업데이트 되면서 바뀐 모양입니다. 죄송합니다..
kldp founder 님께서 살아계셨군요. 요즘
kldp founder 님께서 살아계셨군요. 요즘 kldp에 글이 안 보이시길래 kldp에 손 놓은 줄 알았는데 반갑습니다!!!
세벌 https://sebuls.blogspot.kr/
뭐 실질적으론 손을 놓은지 엄청 오래되었지요 :-)
뭐 실질적으론 손을 놓은지 엄청 오래되었지요 :-)
알려진 버그들..
* 신규 버그
- viewtopic.php 동작 안함. (drupal6 resource 사용, 재작성 필요)
https://kldp.org/viewtopic.php?p=151115
- PHP 7 warning, notice, error fix
* 기존 버그
- node에 제목이 없는 글들이 41개 있음. crazyWWWboard -> jsboard -> phpBB -> drupal6 마이그레이션 와중에 발생 했을 듯..
viewtopic.php (검색 엔진의 PHPBB
viewtopic.php (검색 엔진의 PHPBB URL redirect용) migration 완료
PHP notice 는 loggin 하지 않도록 코드 수정 (bootstrap.inc, E_ALL & ~E_NOTICE)
PHP warning log에 남은 것 까지는 처리 완료. 계속 감시 필요
PHP error 현재 없음. 계속 감시 필요
GeSHi code highlight 동작 안하는 문제 해결
간혹 HTTP 500 Internal server error 발생. PHP fpm segfault 발생하는 경우인데 이건 PHP 7.0.7의 버그로 보임. debugging 귀찮아서, PHP 버전을 올릴까 고민 중.. ;-)
HTML5가 아닌XHTML+RDFa 1.0로 유지 하신 이유 있나요?
제가 아직 웹사이트에 모르는게 많아서 그런데요. 웹사이트 개편 혹은 기술적인 흐름상(혹은 트렌드)로 보면 HTML5로 변경하는걸로 알고 있어요.
HTML5로 바꾸면 4가지의 장점이 있다고 들었어요.
HTML5을 당장 도입해야 하는 네 가지 이유
1. 빨라진 이미지 다운로드, 모바일 사용자에게 유리
2. 향상된 SEO
3. 세련된 애니메이션 효과
4. 쉬워진 앱 개발, 모바일 사용자에게 유리
출처 : itworld, http://www.itworld.co.kr/news/75243
하지만 HTML5가 아닌 XHTML+RDFa 1.0로 유지 하시는 이유가 따로 있는지 알고 싶습니다.
굳이 HTML5로 바꾸지 않아도 되나요?
일단은 기본적으로 drupal 7용 테마 중에서
일단은 기본적으로 drupal 7용 테마 중에서 KLDP 컨텐츠와 어울리는 테마를 찾다보니 현재 테마가 선택 되었습니다. 딱히 HTML5냐 XHTML1.1 이냐가 선택의 고려 대상은 아니었습니다.
그리고, 처음에 KLDP의 모바일 접근성이 떨어져, 반응형 테마(거의 HTML5 이죠)를 찾아 보았으나, 대부분의 테마들이 웹진 형태의 구성을 하고 있어, 테이블 기반으로 구성되어져 있는 KLDP와는 좀 어울리지 않는 문제가 있어 일단 눈에 가장 띄었던 현재 사용하는 테마로 운영을 시작했습니다.
더 솔직히는, 테마의 선택은 우선 순위에 들어가지 못했습니다. 짧은 시간내에 migration을 해야 하는 이유로 기능의 동작 문제가 가장 우선 순위 였기 때문에 테마 선택에 들인 시간은 대략 15분 정도 였습니다. :-)
어제 순선옹과 이런 저런 얘기를 나누었는데, 일단은 현재 테마를 유지하고 기능적인 부분을 처리한 후에 모바일 지원에 대해서 고민을 하기로 했습니다.
마지막으로, 딱히 XHTML 1.1 을 사용한다고 해서 크게 문제될 것은 없을 것 같습니다. XHTML 지원을 browser들이 deprecated 시킨다면 모르겠지만요. 아직까지도 HTML 3.0도 잘 지원해 주는데 ^^;
테마에 대해서는 좀 살펴 보았는데, 일단 drupal
테마에 대해서는 좀 살펴 보았는데, 일단 drupal 7이 나오면서 mobile 전용 테마들이 거의 없고, 반응형 테마로 모바일을 지원 하는 것 같습니다. 모바일 전용 테마 혹시 괜찮은 것 발견 하시면 소개좀..
반응형 테마의 경우에는, KLDP가 대부분 forum contents를 사용하므로 table 구조를 가져야 하는데, 이게 반응형 테마와는 매칭이 별로 좋지 않은 것 같습니다. 차라리 그냥 PC 버전을 모바일에서 사용하는 것 보다 더 불편해 보이는 것 같군요.
그래서 일단 현재 cti_flex (KLDP fixed) 버전을 유지하려고 합니다.
댓글을 다신걸 못보고 이제야 댓글을 답니다.
댓글이 길어서 못봤어요...;;
드루팔 모바일테마에 대해서 제가 이제 xe나 워드프레스 4.6 간단히 구성을 하고 있는 형편이다보니 아직 드루팔(CMS)에 대해서 잘 모릅니다... -_-;;
혹시 나중에(언젠가일수도...;;) 괜찮은 드루팔 모바일 테마 발견하면 댓글로 알려 드리겠습니다...
반응형 테마에 관해서 KLDP에서 CMS를 사용하다보니 반응형 테마를 쉽고 간단하게 바꿀수 일을거라 생각했데, 그리 쉬운일이 아닌줄 몰랐습니다...;; 현재 상황에서 cti_flex (KLDP fixed) 버전을 유지하신것은 올바른 판단이라고 생각합니다.
Markdown 지원
감사합니다. 그런데 Markdown 지원이 제대로 안 먹히는 듯합니다.
감사합니다.
처리 했습니다. migration 중에
처리 했습니다. migration 중에 markdown 설정이 이상하게 되어 있었네요.
속도에 관련에서 DH Param, OCSP Stapling 적용을 고려 해보시는게 어떨까요?
반응속도가 약간 떨어지신다고 하셨는데, DH Param하고 OCSP Stapling 적용을 고려해보시는게 어떨까요?
물론 이 기술을 적용을 안해서 반응속도가 떨어지는건지는 잘 모르겠지만, 이게 아니라면 추가 혹은 별도로 찾아야 하겠지만요...
KLDP 웹사이트를 DH Param와 OCSP Stapling 적용되었는지 확인해보니 해당 기술을 적용을 안하신것 같습니다.
https://www.ssllabs.com/ssltest/analyze.html?d=kldp.org
DH Param와 OCSP Stapling에 대한 간단한 소개 입니다.
DH Param은 일부 암호화 알고리듬에 사용되는 커다란 난수 하나를 미리 생성해 두어서, 암호화 성능을 향상시키고 보안을 높이는 방법입니다.
OCSP Stapling은 서버의 인증서가 유효하다는 증명을 미리 받아두어서 사용자가 웹사이트에 처음 방문할 때 접속 속도를 높여주는 방법입니다.
주의: StartSSL에서 인증서를 구입하신 경우, 약 24시간 동안은 OCSP Stapling을 사용하지 않는 것이 좋습니다.
인증서 구입 직후에 OCSP Stapling을 사용하면 오히려 인증서가 유효하지 않다고 나옵니다.
출처 : SSL의 정석 (아파치 & nginx), https://www.xpressengine.com/tip/23021383
참고 다음 링크에 있는 본문과 댓글도 참고 바랍니다.
https://www.xpressengine.com/forum/22875483
반응 속도가 좀 떨어지게 느낀 것은 migartion
반응 속도가 좀 떨어지게 느낀 것은 migartion 직후 innodb buffer pool 에 데이터가 올라오지 못해서 이고, 현재는 migration 이전 보다 상황이 좀 더 괜찮은 듯 싶습니다. drupal 6에서 부하가 걸리던 부분을 해소한 것들도 있고요.
또한, kldp의 SSL 접근 비율이 10%도 안되기 때문에 크게 영향을 미칠 정도는 아닙니다. 그래서 DH param 은 적용하지 않았고, OCSP stapling이 경우에는 귀찮음의 요소가 있을 듯 해서 적용하지 않았습니다. :-)
하지만, 언제나 그렇듯 이렇게 관심을 가져 주시는 것은 감사히 생각하고 있습니다. 좋은 정보 감사합니다. 다른 분들께도 도움이 되지 않을까 싶고요. 관심을 가지고 있지 않은 사항에 대해서 다시 생각해 보게 해 주셔서 감사합니다. DH param은 그냥 적용 시켜도 괜찮을 듯..
음.. 하도 오래된 일이라서.. 잘못 기억하고
음.. 하도 오래된 일이라서.. 잘못 기억하고 있었네요. DH param을 적용하지 않은 이유는 DHE suite을 사용하고 있지 않아서 였습니다. ^^;
KLDP의 chiper 설정이 아주 과격하게 old browser를 배제하고 있어서요 ^^; 그래서 SSL을 기본 protocol로 하고 있지 않은 이유 입니다.
오랜만에 SSL을 다시 본 김에, OCSP stapling 설정과, HPKP(Public Key Pinning) 설정을 추가 했습니다. 그리고 HSTS Preloading 작업 하다보니, chiper 설정이 너무 과격해서 하면 안될 것 같아서 HSTS에서 includeSubdomains 옵션을 제거 했습니다. (생각해 보면 SSL이 적용되지 않은 사이트도 있어서.. 예를 들어 remote console 등등)
DH param에 대한 지속적인 관심과 답변 감사합니다.
DH param을 적용하지 않은 이유에 대해서 잊지 않고, 지속적으로 관심과 답변 해주셔서 감사합니다. ^0^
올드 웹브라우저 얘기가 나와서 제 개인적인 생각은 웹사이트 만들때 올드 웹브라우저의 호환 및 지원안 하는게 좋다고 생각합니다.
익스플로러11도 호환성을 생각하자면 올해 기준으로 1, 2년 정도 호환성 고려를 해야 될까? 말아야 될까? 할 정도로 생각이 듭니다.
제가 생각해도 과감한 생각인지 무모한 생각인지 그런 생각 하지만, 올드 웹브라우저에 대한 호환성과 지원을 해주지 말아야 한다고 생각합니다.
왜냐하면 올드 웹브라우저의 호환성 때문에 웹사이트 보안을 높힐수가 없어요. 뿐만 아니라 상위버전을 이용하는 웹브라우저 사용자들한테도 효율성과 보안성을 저하 되거나 높힐수가 없어요.
html5, ECMAScript 2016, CSS3, http/2 같은 기술을 도입할 때 웹브라우저 구버전과의 호환성 때문에 도입이 지연되요.
거기에서 끝나지도 않고 웹사이트 제작하시는 분들도 올드 웹브라우저 호환성에 대해 고충이 있을 거라 생각 합니다.
그 동안 여러 웹사이트에서 올드 웹브라우저의 호환성을 너무 신경써주니 올드 웹브라우저 사용자들이 다른 웹브라우저로 바꾸지 않거나 업그레이드를 하지 않는다고 생각합니다. 물론 국내의 엑티브엑스나 플러그인, exe프로그램 설치 및 실행 환경도 원인이긴 합니다.
특히 국내의 현실을 생각하면 생각할수록 안타깝고, 씁쓸합니다... ㅠㅠ
수고하셨습니다.
근 한달 만에 왔는데 그 사이 많은 변화가 생겼네요....
에고.. 고생하셨습니다....
이래저래.. 이런 migration 이 쉬운일은 아니죠.. 그나저나 PHP 7 으로 가셨다니.... 물론 drupal core 에 따른 변화기도 하겠지만...
여튼 이래저래.. 정말 고생 많으셨습니다..(꾸벅)
-----새벽녘의 흡혈양파-----
drupal 7은 아직 PHP 7을 공식적으로
drupal 7은 아직 PHP 7을 공식적으로 지원하지 않습니다. 그리고 core의 경우에는 log message(E_NOTICE, E_WARNING, E_DEPRECATED)를 무시한다면 core의 경우에는 수정 없이 사용이 가능 합니다만, 많은 drupal 7용 모듈 중에서 문제가 되는 것들이 꽤 있습니다.
저희도 서비스 기반을 PHP 7 로 이전하기는 해야하는데...
CodeIgnite 개발버전과 PHP7 의 이슈문제를 감히 넘을 생각을 못하고 있습니다. 허들이 높네요...T.T
-----새벽녘의 흡혈양파-----
저도 전 회사에서 PHP 5.3을 5.5로 이전하기
저도 전 회사에서 PHP 5.3을 5.5로 이전하기 위해서 5.5에서 deprecated 된 features와 remove 된 features를 5.5에서 사용할 수 있도록 패치한 적이 있지요.
https://kldp.org/node/141409
https://joungkyun.gitbooks.io/annyung-3-user-guide/content/pkg-addon-php56.html
그럼에도 불구하고 QA 여력이 없어 업그레이드를 못했죠. 아직도 5.3으로 동작하고 있더군요. 아마 OS관리를 할 수 있는 인력이 없을테니.. :-)
일단, 공식적으로 migration 작업은 여기서
일단, 공식적으로 migration 작업은 여기서 완료 선언을 합니다. engine level의 문제는 거의 해결이 된 것 같고, PHP 7 issue도 거의 해결이 된 것 같습니다.
"완료 선언"을 하였다고 하여도, 문제를 발견 하시면 여기에 문제를 남겨 주시면 해결하도록 하겠습니다.
이전 글의 첨부파일들을 접근할 수 없게 된 것
이전 글의 첨부파일들을 접근할 수 없게 된 것 같습니다.
링크가 보이지 않아요...
해당 node를 알려 주실 수 있으신지요?
https://kldp.org/node/84820 보시면 2007년도 글인데 첨부 파일이 보이는데요. 혹시 이 글도 안보이시나요?
그 글의 첨부파일은 보이는데... 아무래도 댓글의
그 글의 첨부파일은 보이는데... 아무래도 댓글의 첨부파일이 안 보이나 봅니다. 예를 들면https://kldp.org/comment/451337#comment-451337
아.. 대충 살펴본 바로, 이 문제는 좀 난감한데요
아.. 대충 살펴본 바로, 이 문제는 좀 난감한데요 --;
첨부 파일들이 file system 상에는 존재를 하는데, 문제는 drupal 7 migration시에 3th-party module들을 모두 제거하고 migration을 시켜야 해서, comment 첨부 파일들이 db에서 migration 처리가 안된듯 보입니다.
조금 더 살펴 봐야 할 듯..
아 이런...오늘이 금요일인 걸 잊고 있었네요...
아 이런...오늘이 금요일인 걸 잊고 있었네요...
네.. 괴롭히시네요 :-)
네.. 괴롭히시네요 :-) TGIF 이 아니라 FGIF 이군요 ㅋㅋㅋ
comment 첨부 파일용 data를 drupal6 backup database에서 가져와 가공해서 추가했습니다. 확인 부탁 드립니다. 일단 예제로 주신 커멘트에는 잘 나오는 것 확인 했습니다만..
쉽지 않네요 쩝.. 첨부 파일 관련 table이 drupal 6에서는 2개였는데, drupal 7에서는 3개로 늘어 나서.. 삽질 좀 했네요.
다른 댓글에서도 잘 보이는 것을 확인했습니다.
다른 댓글에서도 잘 보이는 것을 확인했습니다. https://kldp.org/comment/548562#comment-548562
메일 주소 표현에 오류가 있습니다.
미리보기로 시험해보니 "Filtered HTML" 과 "BBCode" 양식으로 지정했을 때 eval(unescape("...")) 코드로 보이네요.
그나저나... 또 금요일이네요.
샘플 부탁 드립니다. 무슨 말인지 잘 모르겠습니다.
샘플 부탁 드립니다. 무슨 말인지 잘 모르겠습니다. :-)
요즘 일을 쉬고 육아 중이라서 요일이 좀 의미가 없습니다. ^^;
https://kldp.org/node/155821
https://kldp.org/node/155821 에 있는 댓글에 그런 예가 있네요.
세벌 https://sebuls.blogspot.kr/
처리가 된 것 같습니다만 :-)
처리가 된 것 같습니다만 :-)
BB코드에서 mail address를 javascript로 encoding을 한 후에, script tag가 HTML filter에 의해서 escape 되어 발생한 문제 입니다. BB 코드에서 javascript encoding을 해제 하여 해결 했습니다.
eval unescape 로 검색을 해보면 거의 모든
eval unescape 로 검색을 해보면 거의 모든 글들의 메일 주소가 아직 이상하게 보입니다.
검색 색인 문제인 듯 싶은데요. 해당 글에 직접
검색 색인 문제인 듯 싶은데요. 해당 글에 직접 접근을 하면 제대로 보이는 것 같습니다만..
색인은 구글 site 검색을 사용하는 것이라 제가 해결할 방법이 없습니다. :-)
구글의 db가 갱신되면 풀리겠군요.
구글의 db가 갱신되면 풀리겠군요.
퍼온 기사 글에 적힌 기자의 email 주소를 가지고 시험했는데,
"문병도 기자" 의 "do@sed.co.kr" 은 검색이 되지 않고, "우현석 기자" 의 "hnskwoo@sed.co.kr" 는 검색이 됩니다.
(이 댓글을 올리고 다시 검색했을 때 어떤 결과가 나올지 궁금...)
OS하고 프로그램 업그레이드 하면 호환성 문제가 생기지 않나요?
예전부터 궁금한게 있었는데요.
KLDP에서 사용되는 운영체제와, 프로그램, CMS 등을 안녕 리눅스 3와 PHP 7, Mariadb 10.1 등을 업그레이드 하고 Drupal 7(CMS) 마이그레이션을 하면, 호환성 문제가 발생하나요? 다른 웹사이트들을 보면 운영체제와 프로그램, CMS를 업그레이드, 업데이트 하지 않고, 웹페이지 디자인만 바꾸는 것만 봐서 "운영체제와 프로그램, CMS 업데이트가 어렵고, 위험한 작업인가?" 하는 그런생각이 들더라구요... 소프트웨어 업그레이드 작업이 어려운가요?
HTTP/2에 대한 질문인데요. KLDP 웹페이지 로딩중에 일부는 h2가 아닌 spdy 프로토콜로 로딩하는게 보이더라구요(크롬 개발자 도구로 확인 했어요...). 완전히 h2 프로토콜로 변경이 가능한가요?
그리고 제말은 h2로 바꿔달라는게 아니구요. 제가 웹사이트에 모르는게 많아서 나중에 웹서버 구축 연습 할때 http/2 적용 해보면서 완전히 기존의 http1.1을 h2로 적용해보려고요.
이번 KLDP의 작업의 경우에는 한번에 많은 일을 한
이번 KLDP의 작업의 경우에는 한번에 많은 일을 한 것이죠. 보통 business site 에서는 동시에 이렇게 작업 하지는 않습니다. 당연히 migration에는 호환성 문제는 따라오기 마련이고요.
다만, OS 업그레이드, PHP 7 update, MariaDB 10.1 update 의 경우에는 이미 wiki.kldp.org 등에서 수행을 하여 어떤 일이 벌어질지 예상을 할 수 있는 범위이고, drupal 7 및 php 7 migration도 개발 서버에서 선 테스트를 한 후에 수행을 한 것입니다. 즉 migration 시에 어떤 문제가 발생할 지 예상을 할 수 있는 범위에서 수행을 했다는 얘기입니다.
이런 작업들은 누군가에게는 어렵고 위험한 일일 수도 있고, 누군가에게는 그냥 귀찮은 일 일수도 있고 사람과 그 사람의 능력, 성격 등등에 따라 분류가 되지 않을까 싶습니다.
그리고, spdy 문제는 browser cache를 모두 제거 하고 한번 다시 해 보세요. 또는 browser가 최신 버전인지 확인해 보시고요. 저는 첨부한 이미지와 같이 모두 h2 로만 합니다. 서버에서 따로 spdy를 지원하도록 설정한 것이 없기 때문에 브라우저의 차이로 보입니다. 서버에서는 apache 2.4 http2 module을 이용하여 서비스 하고 있습니다. (openssl 1.0.1e에 ALPN 패치가 반영이 되어 있습니다.) openssl 에 NPN patch 가 같이 적용이 되어 있기 때문에 브라우저 동작 여부에 따라 SPDY통신도 아마 가능할 수도 있을 것 같습니다.
이제 h2 로딩 및 표시가 되요. ^0^
웹사이트 마이그레이션에 대해 궁금했었는데, 답변해주셔서 감사합니다.
웹브라우저 캐시 지우고 곧바로 kldp.org에 접속해봤는데, https가 아닌 http로 접속되서 깜짝 놀랐습니다. https로 바꿔서 접속해보니 https로 접속이 되고, h2 로딩 및 표시가 됩니다.
참고로 저도 크롬 53.0.2785.89 m (64-bit)사용합니다. ^_^v
KLDP는 기본으로 SSL을 지원하지 않습니다.
KLDP는 기본으로 SSL을 지원하지 않습니다. SSL 접속을 원하면 명시적으로 protocol을 지정하셔야 합니다. 다만, SSL 설정에 HTTP Strict Transport Security(HTST)이 되어 있으므로, SSL로 한번 접속을 하게 되면, 쿠키를 모두 지우지 않는 한(음 정확히는 쿠키에 기록이 되는지 확실하지는 않습니다.) 1년 동안은 브라우저가 알아서 SSL로 접속을 하게 해 줍니다.
익명 사용자 forum 글 등록 안되는 문제 해결
익명 사용자 forum 글 등록 안되는 문제 해결 되었습니다.
드루팔8로 마이그레이션 할 생각은 없으셨나요?
늦었긴 했지만, 궁금한점이 올립니다.
이번 마이그레이션 하실 때 드루팔8 버전도 있는데, 드루팔 7으로 마이그레이션을 한 이유도 알고 싶습니다.
일단 6->8 로 의 migration은 안되고, 6
일단 6->8 로 의 migration은 안되고, 6->7->8 로 migration을 해야 했는데, migration 당시 drupal 공식 홈페이지에서 7->8로의 migaration에 대해서 보장을 하지 못하고 있었습니다. 지금은 어떤지 모르겠네요. 그리고, KLDP에서 사용하고 있는 모듈 중에서 drupal 8에서 미지원 상태인 모듈들이 꽤 있었습니다. (후자의 이유가 더 컸습니다.)
원 계획은 drupal 8로의 mitration 이었습니다. :-)
댓글 달기