PHP 5.4 + 그누보드 5.2.9 사이트를 PHP 8 이상으로 올려야 하는데, 현실적인 방법 문의
안녕하세요. 대학 기관 서버에서 운영 중인 사이트 때문에 문의드립니다.
대학 기관 보안 점검에서 "PHP 8.1 미만 사용 서버는 외부 접속 불가" 판정을 받았습니다.
외부 공개를 하려면 PHP를 8.1 이상으로 올려야 합니다.
[상황]
- 서버: CentOS 7 (지원 종료 OS), Apache 2.4.6, MariaDB 5.5.68
- PHP: 5.4.16 - 그누보드: 5.2.9.8.3
- 사이트 구성: 소개 페이지 + 로그인 + 게시판 1개 정도의 작은 사이트입니다. 자체 PHP 파일 몇 개가 그누보드 common.php를 불러서 로그인·회원 조회를 하고, 게시판은 그누보드 게시판을 그대로 사용합니다.
- 서버를 새로 구성하거나 OS를 바꾸기는 당장 어렵고, VM 스냅샷도 없는 환경입니다.
[저희가 세운 방법]
1. PHP 8.3을 기존 PHP 5.4와 별도 경로에 설치 (php-fpm)
2. 그누보드 5.6.48을 새 폴더에 풀고 기존 data 폴더만 복사
3. 관리자 페이지 DB 업그레이드 실행
4. 사이트 폴더만 PHP 8.3으로 연결하고 PHP 5.4는 끔
[문의드리고 싶은 것]
1. 이렇게 5.2.9에서 5.6.48로 한 번에 올리는 방식이 현실적으로 괜찮은지, 아니면 더 안전하거나 권장하는 방법이 있는지요?
2. 이 정도 규모의 사이트라면 5.6.48로 올리는 것과 그누보드7로 새로 구축하는 것 중 어느 쪽을 권하시나요?
3. 위에서 직접 처리한 부분(회원 비밀번호, 누락 컬럼)에 대해 공식적인 처리 방법이 있다면 알려주시면 감사하겠습니다.
4. 혹시 이런 구버전 업그레이드를 유료로 지원하는 서비스가 있는지도 궁금합니다.
방향을 확인하고 싶어서 질문드립니다. 감사합니다.
대학 기관 보안 점검에서 "PHP 8.1 미만 사용 서버는 외부 접속 불가" 판정을 받았습니다.
외부 공개를 하려면 PHP를 8.1 이상으로 올려야 합니다.
[상황]
- 서버: CentOS 7 (지원 종료 OS), Apache 2.4.6, MariaDB 5.5.68
- PHP: 5.4.16 - 그누보드: 5.2.9.8.3
- 사이트 구성: 소개 페이지 + 로그인 + 게시판 1개 정도의 작은 사이트입니다. 자체 PHP 파일 몇 개가 그누보드 common.php를 불러서 로그인·회원 조회를 하고, 게시판은 그누보드 게시판을 그대로 사용합니다.
- 서버를 새로 구성하거나 OS를 바꾸기는 당장 어렵고, VM 스냅샷도 없는 환경입니다.
[저희가 세운 방법]
1. PHP 8.3을 기존 PHP 5.4와 별도 경로에 설치 (php-fpm)
2. 그누보드 5.6.48을 새 폴더에 풀고 기존 data 폴더만 복사
3. 관리자 페이지 DB 업그레이드 실행
4. 사이트 폴더만 PHP 8.3으로 연결하고 PHP 5.4는 끔
[문의드리고 싶은 것]
1. 이렇게 5.2.9에서 5.6.48로 한 번에 올리는 방식이 현실적으로 괜찮은지, 아니면 더 안전하거나 권장하는 방법이 있는지요?
2. 이 정도 규모의 사이트라면 5.6.48로 올리는 것과 그누보드7로 새로 구축하는 것 중 어느 쪽을 권하시나요?
3. 위에서 직접 처리한 부분(회원 비밀번호, 누락 컬럼)에 대해 공식적인 처리 방법이 있다면 알려주시면 감사하겠습니다.
4. 혹시 이런 구버전 업그레이드를 유료로 지원하는 서비스가 있는지도 궁금합니다.
방향을 확인하고 싶어서 질문드립니다. 감사합니다.
답변 11개
질문자님이 세우신 순서(새 폴더에 5.6.48 + data 복사 → DB업그레이드)는 맞습니다. 다만 위 답변들과 다른 점이 하나 있어서 꼭 적습니다.
지금 그대로 5.6.48로 가시면 최고관리자를 포함해 회원 전원이 로그인이 안 됩니다.
1. 회원 비밀번호 — "로그인할 때 자동 변환"은 5.6.36까지 이야기입니다
- 5.2.9.8.3은 config.php 에 G5_STRING_ENCRYPT_FUNCTION 이 'sql_password' 로 되어 있어서, 비밀번호가 MySQL PASSWORD() 방식(* 로 시작하는 41자)으로 저장돼 있습니다.
- 5.4부터 저장 방식이 create_hash 로 바뀌었고, 그동안은 lib/common.lib.php 의 login_password_check() 가 옛 방식으로 맞으면 새 방식으로 바꿔 저장해 줬습니다.
- 그런데 이 변환 코드가 5.6.37(2026-09-09)부터 빠졌습니다. 5.6.48의 login_password_check() 는 check_password() 만 부르고, 이 함수는 옛 해시를 읽지 못합니다. 깃허브에서 v5.6.36 과 v5.6.37 태그의 lib/common.lib.php 를 비교해 보시면 바로 보입니다.
- 그래서 업그레이드 직후 관리자로도 못 들어가고, 관리자 > DB업그레이드 화면에도 못 들어가게 됩니다.
- 비회원 게시글 비밀번호는 extend/g5_54version_update.extend.php 가 아직 옛 방식을 받아 줘서 괜찮습니다. 문제는 회원 로그인뿐입니다.
해결은 코어 파일을 고치지 않고 extend 폴더에 파일 하나만 두시면 됩니다(extend/ 안의 *.extend.php 는 자동으로 읽힙니다). 옛 방식으로 비밀번호가 맞으면 새 방식으로 바꿔 저장하고 로그인시킵니다. PASSWORD() 계산은 DB 함수에 기대지 않고 PHP로 똑같이 했습니다.
extend/legacy_password.extend.php
<?php
if (!defined('_GNUBOARD_')) exit;
// 5.2.x 이하에서 가입한 회원(MySQL PASSWORD() 해시)이 처음 로그인할 때 새 방식으로 바꿔 저장
add_replace('login_check_need_not_password', 'legacy_mysql_password_login', 10, 5);
function legacy_mysql_password_login($need_not, $mb_id, $mb_password, $mb, $is_social_login)
{
global $g5;
if ($need_not || empty($mb['mb_id']) || $mb_password === '') return $need_not;
$hash = $mb['mb_password'];
if (strlen($hash) !== 41 || $hash[0] !== '*') return $need_not; // 옛 해시가 아니면 그냥 통과
// MySQL PASSWORD() 와 같은 값 = '*' + SHA1(SHA1(비번)) 대문자
$legacy = '*' . strtoupper(sha1(sha1($mb_password, true)));
if (!hash_equals($hash, $legacy)) return $need_not;
$new = create_hash($mb_password);
sql_query(" update {$g5['member_table']}
set mb_password = '" . sql_real_escape_string($new) . "'
where mb_id = '" . sql_real_escape_string($mb['mb_id']) . "' ");
return true; // 비밀번호 확인 끝 → 뒤의 차단·탈퇴 검사는 그대로 진행
}
맞는 비밀번호는 통과하면서 새 방식으로 바뀌고, 틀린 비밀번호는 그대로 거절되고, 이미 새 방식인 회원은 건드리지 않는 것까지 5.6.48 원본 함수로 확인했습니다. 회원들이 한 번씩 로그인할 때마다 하나씩 바뀌니, 남은 옛 해시가 0이 될 때까지 파일을 두시면 됩니다.
SELECT COUNT(*) FROM g5_member WHERE LENGTH(mb_password) = 41 AND mb_password LIKE '*%';
2. 자체 PHP 파일도 같은 이유로 확인하세요
common.php 를 불러 로그인하는 자체 파일이 비밀번호를 직접 비교하고 있으면(예: sql_password($pw) == $mb['mb_password'], get_encrypt_string($pw) == $mb['mb_password']) 업그레이드 뒤 항상 틀립니다. 새 방식은 같은 비밀번호도 저장할 때마다 값이 달라서 이렇게 비교할 수 없습니다. login_password_check($mb, $pw, $mb['mb_password']) 로 바꾸시면 위 extend 파일 없이도 새 방식 회원은 맞게 확인됩니다. mysql_* 함수, each() 같은 것은 위 답변 말씀대로입니다.
3. 누락 컬럼 — 공식 방법은 DB업그레이드 "전체 실행"입니다
5.6.37부터는 화면에 접속할 때 컬럼을 몰래 채우던 방식이 없어지고, migrations 폴더의 SQL을 관리자 > 환경설정 > DB업그레이드에서 직접 실행하는 방식으로 바뀌었습니다. 2014년 변경분부터 들어 있고 "컬럼이 없을 때만 추가" 같은 조건이 붙어 있어서, 5.2.9 DB도 전체 실행 한 번이면 됩니다. DB 계정에 ALTER·CREATE 권한이 있어야 합니다. 공식 설명은 깃허브 gnuboard5 저장소 docs/database-migrations.md 에 있습니다.
순서만 주의하세요. 위 1번 파일을 먼저 넣어야 관리자로 들어가서 이걸 누를 수 있습니다.
4. 새 config.php 의 G5_DOMAIN
data 폴더만 옮기시면 config.php 는 새 판 것을 쓰게 되는데, 5.6.37부터는 G5_DOMAIN 이 비어 있으면 비밀번호 찾기·가입 인증 메일이 아예 나가지 않습니다. define('G5_DOMAIN', 'https://실제주소'); 로 채워 주세요.
5. 보안 점검을 다시 받기 전에
점검 도구는 응답 헤더를 많이 봅니다. 사이트 폴더만 php-fpm 8.3으로 돌려도 Apache에 mod_php(5.4)가 그대로 올라가 있으면 Server 헤더에 "PHP/5.4.16"이 찍힐 수 있습니다. "PHP 5.4는 끔"을 모듈 자체를 내리는 것으로 하시고(/etc/httpd/conf.modules.d/10-php.conf 의 LoadModule 줄 주석 처리 후 httpd 재시작), curl -I 주소 로 헤더를 직접 확인해 보세요. ServerTokens Prod 도 같이 권합니다.
정리하면 순서는 이렇습니다.
DB·파일 백업 → 새 폴더에 5.6.48 + data 복사 + extend 파일 + G5_DOMAIN → 관리자 로그인 → DB업그레이드 전체 실행 → 자체 PHP 파일 수정 → 로그인·글쓰기·첨부·비밀번호 찾기 메일 확인 → mod_php 내리고 헤더 확인
그누보드7은 위 답변들 말씀처럼 이 규모 사이트를 옮기기엔 새로 만드는 일에 가까워서, 5.6.48 판올림을 권합니다.
맡기시는 경우: 서버의 PHP 8.3 설치는 계획하신 대로 직접 하시고, 그누보드 판올림 + 비밀번호 처리 + 자체 PHP 파일 PHP 8 수정 + 확인까지 하루, 40만 원(부가세 별도)입니다. 기관 서버라 외부 접속이 어려우면 파일을 받아 고쳐서 돌려드리는 방식도 됩니다. 자체 파일이 생각보다 많으면 목록을 보고 다시 말씀드리겠습니다.
상상인 · https://thanksfor.co.kr/
판올림 전에 확인할 것들은 여기 따로 정리해 두었습니다: https://sangsangin.co.kr/blog/board.php?id=49
지금 그대로 5.6.48로 가시면 최고관리자를 포함해 회원 전원이 로그인이 안 됩니다.
1. 회원 비밀번호 — "로그인할 때 자동 변환"은 5.6.36까지 이야기입니다
- 5.2.9.8.3은 config.php 에 G5_STRING_ENCRYPT_FUNCTION 이 'sql_password' 로 되어 있어서, 비밀번호가 MySQL PASSWORD() 방식(* 로 시작하는 41자)으로 저장돼 있습니다.
- 5.4부터 저장 방식이 create_hash 로 바뀌었고, 그동안은 lib/common.lib.php 의 login_password_check() 가 옛 방식으로 맞으면 새 방식으로 바꿔 저장해 줬습니다.
- 그런데 이 변환 코드가 5.6.37(2026-09-09)부터 빠졌습니다. 5.6.48의 login_password_check() 는 check_password() 만 부르고, 이 함수는 옛 해시를 읽지 못합니다. 깃허브에서 v5.6.36 과 v5.6.37 태그의 lib/common.lib.php 를 비교해 보시면 바로 보입니다.
- 그래서 업그레이드 직후 관리자로도 못 들어가고, 관리자 > DB업그레이드 화면에도 못 들어가게 됩니다.
- 비회원 게시글 비밀번호는 extend/g5_54version_update.extend.php 가 아직 옛 방식을 받아 줘서 괜찮습니다. 문제는 회원 로그인뿐입니다.
해결은 코어 파일을 고치지 않고 extend 폴더에 파일 하나만 두시면 됩니다(extend/ 안의 *.extend.php 는 자동으로 읽힙니다). 옛 방식으로 비밀번호가 맞으면 새 방식으로 바꿔 저장하고 로그인시킵니다. PASSWORD() 계산은 DB 함수에 기대지 않고 PHP로 똑같이 했습니다.
extend/legacy_password.extend.php
<?php
if (!defined('_GNUBOARD_')) exit;
// 5.2.x 이하에서 가입한 회원(MySQL PASSWORD() 해시)이 처음 로그인할 때 새 방식으로 바꿔 저장
add_replace('login_check_need_not_password', 'legacy_mysql_password_login', 10, 5);
function legacy_mysql_password_login($need_not, $mb_id, $mb_password, $mb, $is_social_login)
{
global $g5;
if ($need_not || empty($mb['mb_id']) || $mb_password === '') return $need_not;
$hash = $mb['mb_password'];
if (strlen($hash) !== 41 || $hash[0] !== '*') return $need_not; // 옛 해시가 아니면 그냥 통과
// MySQL PASSWORD() 와 같은 값 = '*' + SHA1(SHA1(비번)) 대문자
$legacy = '*' . strtoupper(sha1(sha1($mb_password, true)));
if (!hash_equals($hash, $legacy)) return $need_not;
$new = create_hash($mb_password);
sql_query(" update {$g5['member_table']}
set mb_password = '" . sql_real_escape_string($new) . "'
where mb_id = '" . sql_real_escape_string($mb['mb_id']) . "' ");
return true; // 비밀번호 확인 끝 → 뒤의 차단·탈퇴 검사는 그대로 진행
}
맞는 비밀번호는 통과하면서 새 방식으로 바뀌고, 틀린 비밀번호는 그대로 거절되고, 이미 새 방식인 회원은 건드리지 않는 것까지 5.6.48 원본 함수로 확인했습니다. 회원들이 한 번씩 로그인할 때마다 하나씩 바뀌니, 남은 옛 해시가 0이 될 때까지 파일을 두시면 됩니다.
SELECT COUNT(*) FROM g5_member WHERE LENGTH(mb_password) = 41 AND mb_password LIKE '*%';
2. 자체 PHP 파일도 같은 이유로 확인하세요
common.php 를 불러 로그인하는 자체 파일이 비밀번호를 직접 비교하고 있으면(예: sql_password($pw) == $mb['mb_password'], get_encrypt_string($pw) == $mb['mb_password']) 업그레이드 뒤 항상 틀립니다. 새 방식은 같은 비밀번호도 저장할 때마다 값이 달라서 이렇게 비교할 수 없습니다. login_password_check($mb, $pw, $mb['mb_password']) 로 바꾸시면 위 extend 파일 없이도 새 방식 회원은 맞게 확인됩니다. mysql_* 함수, each() 같은 것은 위 답변 말씀대로입니다.
3. 누락 컬럼 — 공식 방법은 DB업그레이드 "전체 실행"입니다
5.6.37부터는 화면에 접속할 때 컬럼을 몰래 채우던 방식이 없어지고, migrations 폴더의 SQL을 관리자 > 환경설정 > DB업그레이드에서 직접 실행하는 방식으로 바뀌었습니다. 2014년 변경분부터 들어 있고 "컬럼이 없을 때만 추가" 같은 조건이 붙어 있어서, 5.2.9 DB도 전체 실행 한 번이면 됩니다. DB 계정에 ALTER·CREATE 권한이 있어야 합니다. 공식 설명은 깃허브 gnuboard5 저장소 docs/database-migrations.md 에 있습니다.
순서만 주의하세요. 위 1번 파일을 먼저 넣어야 관리자로 들어가서 이걸 누를 수 있습니다.
4. 새 config.php 의 G5_DOMAIN
data 폴더만 옮기시면 config.php 는 새 판 것을 쓰게 되는데, 5.6.37부터는 G5_DOMAIN 이 비어 있으면 비밀번호 찾기·가입 인증 메일이 아예 나가지 않습니다. define('G5_DOMAIN', 'https://실제주소'); 로 채워 주세요.
5. 보안 점검을 다시 받기 전에
점검 도구는 응답 헤더를 많이 봅니다. 사이트 폴더만 php-fpm 8.3으로 돌려도 Apache에 mod_php(5.4)가 그대로 올라가 있으면 Server 헤더에 "PHP/5.4.16"이 찍힐 수 있습니다. "PHP 5.4는 끔"을 모듈 자체를 내리는 것으로 하시고(/etc/httpd/conf.modules.d/10-php.conf 의 LoadModule 줄 주석 처리 후 httpd 재시작), curl -I 주소 로 헤더를 직접 확인해 보세요. ServerTokens Prod 도 같이 권합니다.
정리하면 순서는 이렇습니다.
DB·파일 백업 → 새 폴더에 5.6.48 + data 복사 + extend 파일 + G5_DOMAIN → 관리자 로그인 → DB업그레이드 전체 실행 → 자체 PHP 파일 수정 → 로그인·글쓰기·첨부·비밀번호 찾기 메일 확인 → mod_php 내리고 헤더 확인
그누보드7은 위 답변들 말씀처럼 이 규모 사이트를 옮기기엔 새로 만드는 일에 가까워서, 5.6.48 판올림을 권합니다.
맡기시는 경우: 서버의 PHP 8.3 설치는 계획하신 대로 직접 하시고, 그누보드 판올림 + 비밀번호 처리 + 자체 PHP 파일 PHP 8 수정 + 확인까지 하루, 40만 원(부가세 별도)입니다. 기관 서버라 외부 접속이 어려우면 파일을 받아 고쳐서 돌려드리는 방식도 됩니다. 자체 파일이 생각보다 많으면 목록을 보고 다시 말씀드리겠습니다.
상상인 · https://thanksfor.co.kr/
판올림 전에 확인할 것들은 여기 따로 정리해 두었습니다: https://sangsangin.co.kr/blog/board.php?id=49
추천을 하자면 우선 CentOS 7 에 PHP 8.3와 PHP 5.4를 서버에 동시에 올릴수 있습니다.
이렇게 되면 PHP 8.3에서 기존에 그누보드 5.2.9을 돌리게 되면 일부 오류가 있을수 있습니다.
기존에는 운영을 하셨다면 문제 없이 PHP 5.4에서는 잘돌아 갔지만 PHP 8.3 이상으로 올리게 되면
기존 그누보드 5.2.9는 에러날 확율이 높습니다.
그래서 지금 상황을 보면 "PHP 8.1 미만 사용 서버는 외부 접속 불가" 란 판정을 받았다고하니
외부 공개를 위해서 쓰는 프로그램이 그누보드 5.2.9이라하면 그누보드 패치작업을 하셔야 할꺼 같습니다.
만일 여러개의 프로그램이 웹서버에서 운영한다면 버전에 맞게 공개와 비공개로 구분하셔서 버전별로
돌리시는게 맞다고 생각합니다.
왜냐면 일부러 기존 사용하는 모든 프로그램까지 모두다 PHP 8.3으로 수정하여 완벽하게 돌게 작업하면이야
좋을수 있겠지만 이렇게 되면 많은 시간과 노력이 필요가 뒤따르기 때문입니다.
그래서 아래의 답변을 드리겠습니다.
1. 이렇게 5.2.9에서 5.6.48로 한 번에 올리는 방식이 현실적으로 괜찮은지, 아니면 더 안전하거나 권장하는 방법이 있는지요?
> PHP 8.3으로 가신다면 5.6 이상의 버전으로 패치하시는 것을 권장드립니다.
2. 이 정도 규모의 사이트라면 5.6.48로 올리는 것과 그누보드7로 새로 구축하는 것 중 어느 쪽을 권하시나요?
> 그누보드7은 새로운 개념의 보드입니다. 아울서 시스템 사양도 어느정도 좋아야 합니다. CentOS 7을 쓰는걸로 봐선
사양이 좀 낮을것으로 사료되어 개인적으로는 조심스럽지만 비추천을 드립니다.
그리고 그누보드7로 새로구축하게 되면 이 또한 만만한 작업이 아닐것으로 생각됩니다.
따라서 5.6.48으로 올리는 편이 비교적 가성비적인 방법이라 생각됩니다.
3. 위에서 직접 처리한 부분(회원 비밀번호, 누락 컬럼)에 대해 공식적인 처리 방법이 있다면 알려주시면 감사하겠습니다.
> 이부분은 MariaDB 5.5.68 이라면 이전시 비밀번호 이슈는 없을것으로 예상됩니다만, 상황에 따른 변수가 발생될수 있겠습니다.
4. 혹시 이런 구버전 업그레이드를 유료로 지원하는 서비스가 있는지도 궁금합니다.
> 유료로 지원하는 서비스는 없습니다. 다만 별도의 개발사나 개발의뢰 하는 분이라면 가능하리라 생각됩니다.
더 궁금하신 사항이 있으면 쪽지 주시면 안내드리겠습니다.
이렇게 되면 PHP 8.3에서 기존에 그누보드 5.2.9을 돌리게 되면 일부 오류가 있을수 있습니다.
기존에는 운영을 하셨다면 문제 없이 PHP 5.4에서는 잘돌아 갔지만 PHP 8.3 이상으로 올리게 되면
기존 그누보드 5.2.9는 에러날 확율이 높습니다.
그래서 지금 상황을 보면 "PHP 8.1 미만 사용 서버는 외부 접속 불가" 란 판정을 받았다고하니
외부 공개를 위해서 쓰는 프로그램이 그누보드 5.2.9이라하면 그누보드 패치작업을 하셔야 할꺼 같습니다.
만일 여러개의 프로그램이 웹서버에서 운영한다면 버전에 맞게 공개와 비공개로 구분하셔서 버전별로
돌리시는게 맞다고 생각합니다.
왜냐면 일부러 기존 사용하는 모든 프로그램까지 모두다 PHP 8.3으로 수정하여 완벽하게 돌게 작업하면이야
좋을수 있겠지만 이렇게 되면 많은 시간과 노력이 필요가 뒤따르기 때문입니다.
그래서 아래의 답변을 드리겠습니다.
1. 이렇게 5.2.9에서 5.6.48로 한 번에 올리는 방식이 현실적으로 괜찮은지, 아니면 더 안전하거나 권장하는 방법이 있는지요?
> PHP 8.3으로 가신다면 5.6 이상의 버전으로 패치하시는 것을 권장드립니다.
2. 이 정도 규모의 사이트라면 5.6.48로 올리는 것과 그누보드7로 새로 구축하는 것 중 어느 쪽을 권하시나요?
> 그누보드7은 새로운 개념의 보드입니다. 아울서 시스템 사양도 어느정도 좋아야 합니다. CentOS 7을 쓰는걸로 봐선
사양이 좀 낮을것으로 사료되어 개인적으로는 조심스럽지만 비추천을 드립니다.
그리고 그누보드7로 새로구축하게 되면 이 또한 만만한 작업이 아닐것으로 생각됩니다.
따라서 5.6.48으로 올리는 편이 비교적 가성비적인 방법이라 생각됩니다.
3. 위에서 직접 처리한 부분(회원 비밀번호, 누락 컬럼)에 대해 공식적인 처리 방법이 있다면 알려주시면 감사하겠습니다.
> 이부분은 MariaDB 5.5.68 이라면 이전시 비밀번호 이슈는 없을것으로 예상됩니다만, 상황에 따른 변수가 발생될수 있겠습니다.
4. 혹시 이런 구버전 업그레이드를 유료로 지원하는 서비스가 있는지도 궁금합니다.
> 유료로 지원하는 서비스는 없습니다. 다만 별도의 개발사나 개발의뢰 하는 분이라면 가능하리라 생각됩니다.
더 궁금하신 사항이 있으면 쪽지 주시면 안내드리겠습니다.
1. 이렇게 5.2.9에서 5.6.48로 한 번에 올리는 방식이 현실적으로 괜찮은지, 아니면 더 안전하거나 권장하는 방법이 있는지요?
=> 그냥 5.6.48 를 설치하고 5.2.9 의홈페이지 디자인을 입히는것을추천
2. 이 정도 규모의 사이트라면 5.6.48로 올리는 것과 그누보드7로 새로 구축하는 것 중 어느 쪽을 권하시나요?
==> 5.6
추천 이유
유지보수비용이 적음
3. 위에서 직접 처리한 부분(회원 비밀번호, 누락 컬럼)에 대해 공식적인 처리 방법이 있다면 알려주시면 감사하겠습니다.
==>공식적인 방법은 모르게고
소스에 5.2 로그인과 5.6 로그인 을 다넣고 로그인 할때에 교차 채크해서 5.6 비번을 새로 만드는것을 추천
4. 혹시 이런 구버전 업그레이드를 유료로 지원하는 서비스가 있는지도 궁금합니다.
https://sir.kr/jobs/requests
의뢰 하시면 50만원~ @ 처리해주실분이 75명이나 대기중입니다
=> 그냥 5.6.48 를 설치하고 5.2.9 의홈페이지 디자인을 입히는것을추천
2. 이 정도 규모의 사이트라면 5.6.48로 올리는 것과 그누보드7로 새로 구축하는 것 중 어느 쪽을 권하시나요?
==> 5.6
추천 이유
유지보수비용이 적음
3. 위에서 직접 처리한 부분(회원 비밀번호, 누락 컬럼)에 대해 공식적인 처리 방법이 있다면 알려주시면 감사하겠습니다.
==>공식적인 방법은 모르게고
소스에 5.2 로그인과 5.6 로그인 을 다넣고 로그인 할때에 교차 채크해서 5.6 비번을 새로 만드는것을 추천
4. 혹시 이런 구버전 업그레이드를 유료로 지원하는 서비스가 있는지도 궁금합니다.
https://sir.kr/jobs/requests
의뢰 하시면 50만원~ @ 처리해주실분이 75명이나 대기중입니다
사실상 위에 주된내용의 불안요소는
1. 기존 회원정보
2. 게시판의 게시물
3. 게시물내에 업로드되어있는 썸네일 및 파일들
총 3개로 판단되기때문에 사실상 만약에 저라면 어차피 해야될거
1. 최신버전으로 한번에 올리며 관리자 DB 업그레이드를 실행함
2. Mysql 버전또한 최신버전으로 업그레이드 해서 처리함
위 두개방식으로 처리하는게 향후 유지보수나 일부 업그레이드로 인해 또 똑같은 일을 겪게될 예정이라면
최신버전으로 모두 올리시는게 나아보입니다.
페이지 양도 적고 자체 PHP 파일만 점검하면되기때문에 본인이 만든 파일이라면
변경된 요소 또는 에러 요소만 검색해 수정하는게 나아보이거든요.
그리고 그누보드 7 같은경우 아직까진 사용기간이 길지않아 대부분을 AI에게 기대거나
또는 디버깅모드로 처리하는경우가 많아서. 자료가 가장많은 그누보드 5 로 일단 채택하는게 안정성면에서도 나아보입니다.
그리고 회원 비밀번호같은경우나 누락컬럼같은경우에 DB 마이그레이션을 처리하면 대부분이 해결되지만.
그럼에도 문제가 생긴다면 랜덤비밀번호로 일단 임의 생성후 고지를 통해 변경하면 어떨까 싶네요.
어차피 하실거면 신규나 이전이 답입니다.
리눅스때문에 저는 신규 구매를 선택할 수 밖에 없었습니다.
한대로는 해결이 안되겠더라구요.
임대서버 잠시 빌려서 옮겼다가 다시 오는 방법도 고려해 보세요.
그누5에서 최신버전으로 가는것은 껌(?)입니다.ㅎㅎ
그누4에서 그것도 커스텀 여러군데 한것은 노답입니다.
지금 자동이전솔루션 쳇하고 클로드에게 작업시키고 있는데
야들도 헤매고 있어요.
차라리 제가 노과다하는게 편하겠다는 생각이 듭니다.
오늘까지 시켜보고 안되면 수작업해야겠어요.ㅠㅠ
답변을 작성하려면 로그인이 필요합니다.