새로운 Magento 업데이트 (1.9.4.1)에서 Mage :: log ()가 작동하지 않음


23

이 새로운 업데이트 (1.9.4.1) 후에 Mage :: log ()가 작동하지 않습니다. 분명히 Zend_Validate_File_ExtensionMage.php의 819 라인 과 관련 이 있으며 파일 is_readable()이 존재하기 전에 파일이 있는지 확인 합니다. 전체 log()방법을 이전 버전으로 되돌리고 다시 작동합니다.

이 문제를보고하기 위해 Magento 팀에 연락 할 수있는 기본 채널은 무엇입니까?


1
@PiotrSiejczuk 새 로그 파일에는 작동하지 않습니다. 두 번째 의견은 로그 회전 구성을 변경하는 기능으로 인해 심각한 문제가 아니며 완전히 동의하지 않는다는 것을 의미합니다. 첫 번째 의견은 이것이 OP 또는 아마도 어떤 경우에는 문제 일 뿐이며, 나는 그것에도 동의하지 않습니다. Magento가이 버그를 알아 채지 못한 이유를 완전히 이해하지만, 이러한 의미는 여기에 필요한 것과 반대입니다 (고의적이든 아니든).
toon81

3
새로 설치 (이 경우 system.log가 아직 존재하지 않음), 사용자 지정 로그 파일에 기록하는 로컬 및 타사 모듈의 생성 / 설치, 명시 적으로 생성하지 않은 구성을 로테이션 원본 로그 파일을 보관하십시오.
Aad Mathijssen

3
예, 로깅은 모든 소프트웨어에 필수적입니다. 왜 그렇게했는지 궁금합니다. 내 꿈은 2020오고 젠토 팀 정지 1.x에서 지원하는 경우, 그들은 사회가 최신으로 유지할 수 힘내 너무 REPO 공식에 자신의 마지막 버전을 업로드 할 것입니다
rodrigoriome

1
@cslogic "제 꿈은 2020 년이오고 Magento 팀이 1.x 지원을 중단하면 커뮤니티가 최신 버전을 유지할 수 있도록 공식 Git 리포지토리에 마지막 버전을 업로드하는 것입니다."=> 이미 OpenMage LTS로 완료되었습니다 : github. com / OpenMage / magento-lts
프레데릭

1
@ FrédéricMARTINEZ 우스운, Ben Marks는 실제로 당신의 의견을 읽기 30 분 전에 그 레포에 대해 이야기했습니다. 어쨌든 감사합니다.
rodrigoriome

답변:



7

SUPEE-11086 패치와 관련하여 Magento와의 지원 및 Slack과의 연구 및 상호 작용을 기반으로 지금까지 찾은 모든 것을 요약합니다. 수행 할 수있는 작업 :

업데이트 2 :이 문제는 다음 패치 SUPEE-11155 ( https://magento.com/security/patches/supee-11155) 에서 해결되었습니다 . 패치를 적용하기 전에 항상 가능한 문제 스레드에 대한 점검- 보안 패치 SUPEE-11155-가능한 문제? Aad Mathijssen 에게 감사의 말을 전합니다.

업데이트 : 요청시 EE 버전에 대한 공식 패치가 제공됩니다. 기본적으로 Piotr Kaminski의 요지는 Magento 패치 파일로 싸여 있습니다.

  1. app/Mage.php패치 파일에서 변경 사항을 삭제 하십시오. 이것이 내가 지금까지 한 일입니다.
    장점-로깅은 이전과 동일하게 작동합니다.
    단점-패치 파일을 편집하고 로깅은 가능한 악용으로부터 보호되지 않습니다 (그러나 이것은 위험이 매우 낮습니다). Magento가 공식 픽스를 릴리스하면이를 수정하고 원래의 편집되지 않은 패치를 적용해야합니다.
  2. Piotr Kaminski의 요점-https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f에 따라 다른 패치를 추가 하십시오 . 피오트르 카민스키 (Piotr Kaminski)는 보안을 담당하는 마 젠토 (Magento)의 일원으로 말의 입에서 바로 나온다. 요점은 마 젠토 슬랙에서 공유되었으며 아마도 SUPEE-11086 v1.1로 끝날 것입니다.
    찬성-이것은 마 젠토 방식의
    단점입니다-공식이되기를 기다리거나 책임을지고 그것을 패치로 직접 포장해야합니다. 공식 패치가 완료되면 되돌릴 필요가 있습니다.
    약간의 변형은 두 개의 패치를 추가하여 해당 변경 사항으로 원래 패치를 편집하는 것입니다.
  3. Zend_Validate_File_Extension::isValid파일 존재 검증을 편집 하고 제거하십시오. Magento LTS github- https: //github.com/OpenMage/magento-lts/pull/648에 대한 긴 토론이 있습니다 . 이 isValid방법은 예상하지 못한 작업을 수행하므로 일부 회원은 수정을 제안합니다. 내 의견은 이것이 좋은 해결책은 아니며 예 코드는 나쁘지 만 영원히 존재했으며 사용자 정의 모듈 / 코드에서 사용될 수 있다는 것입니다. 반대로, 최악의 상황은 파일이 존재하지 않는지 확인하는 것입니다.
    찬성-오히려 간단한 수정
    단점-라이브러리 파일을 변경하고 기능을 수정합니다.
    이를 사용자 지정 패치로 적용하거나 local코드 풀 에서 전체 클래스를 다시 작성하여 적용 할 수 있습니다 .

패치를 편집하기로 선택했고 v1.1이 나오면 편집 한 패치를 되돌리고 원래 버전과 수정 후에 적용합니다. 이것은 우리의 빌드 프로세스와 내부 정책에 잘 맞으며, 여러분에게 다를 수 있습니다. 무엇을 선택하든 나중에이 패치를 빨리 적용하는 것이 좋습니다.


1
6 월 25 일부터 Magento는이 문제에 대한 수정 프로그램이 포함 된 SUPEE-11155, Magento Commerce 1.14.4.2 및 Magento Open Source 1.9.4.2를 발표했습니다. 본질적으로 Piotr Kaminski의 패치가 포함되었습니다.
Aad Mathijssen

4

커뮤니티 입력에서 무언가. 새로운 Validator가 아래와 같이 Zend_Validate_File_Extension으로 사용되었습니다 :

https://github.com/brentwpeterson/magento-patches/blob/master/CE1.9/PATCH_SUPEE-11086_CE_1.9.4.0_v1-2019-03-26-03-05-04.sh#L183

"해결책은 패치를 편집하고 app / Mage.php에서 변경 사항을 제거하는 것입니다.이 방법을 강력히 권장하지는 않지만 상황은 매우 중요합니다."


실제로 나쁜 습관이지만 로깅 없이는 살아남을 수 없습니다. Adobe가 곧 고칠 수 있기를 바랍니다
rodrigoriome

예, logrotator 스크립트가 파일을 삭제하고 zip 파일을 생성했기 때문에 모든 로그 파일을 다시 작성해야했습니다. magento의 더 나은 스크립트를 찾아서 thi를 수정하지 않아야합니다.
Kalvin Klien

1
@ KalvinKlien : 시도 했습니까 : logrotate의 copytruncate 옵션? "오래된 로그 파일을 이동하고 선택적으로 새 로그 파일을 작성하는 대신 사본을 작성한 후 원래 로그 파일을 0 크기로 자릅니다. 일부 프로그램이 로그 파일을 닫으라고 지시 할 수 없어서 계속 쓸 수있는 경우에 사용할 수 있습니다 ( 이전 로그 파일에 영구적으로 추가) 파일 복사와 잘라 내기 사이에 시간 분할이 매우 작으므로 일부 로깅 데이터가 손실 될 수 있습니다.이 옵션을 사용하면 create 옵션이 적용되지 않습니다. 오래된 로그 파일이 그대로 유지됩니다. "
Piotr Siejczuk

감사합니다 @PiotrSiejczuk! 나는 이것을 사용했다 : / path / var / log / * log {7 copytruncate 매일 압축 missingok notifempty}
Klien

1

내 임시 방편 복사하는 것이었다 lib/Zend/Validate/File/Extension.phpapp/code/local/Zend/Validate/File/Extension.php제거 의 코드의이 부분 isValid()방법 :

    // Is file readable ?
    #require_once 'Zend/Loader.php';
    if (!Zend_Loader::isReadable($value)) {
        return $this->_throw($file, self::NOT_FOUND);
    }

그것은 될 것입니다 ...

public function isValid($value, $file = null)
{
    if ($file !== null) {
        $info['extension'] = substr($file['name'], strrpos($file['name'], '.') + 1);
    } else {
        $info = pathinfo($value);
...

Magento 1.9.4.2가 릴리스되면 다시 확인합니다.

실제로 파일을 읽을 수 없거나 존재하지 않는다고해서 파일 이름이 유효하지 않은 것은 아닙니다.



0

하위 폴더에 로그 파일을 작성할 수없는 또 다른 문제 (Magento 팀에서 의도적으로 발생할 수 있음)가 있습니다. 예를 들면 다음과 같습니다.

Mage::log('Some log information', Zend_Log::DEBUG, 'somefolder/anotherfolder/somelogfile.log', true);

이전 버전에서는 해당 호출이 위치에 파일을 작성했을 것입니다.

/your-magento-app-root-folder/var/log/somefolder/anotherfolder/somelogfile.log

그러나 메소드에 basename()함수 호출 이 있기 때문에 Mage::log()파일은 다음 위치에 작성됩니다.

/your-magento-app-root-folder/var/log/somelogfile.log.

여기에 설명 된 코드가 있습니다 app/Mage.php.

$file = empty($file) ?
    (string) self::getConfig()->getNode('dev/log/file', Mage_Core_Model_Store::DEFAULT_CODE) : basename($file);

특히 1.9.4.1과 관련이없는 경우에도 문제는 최근에 (최신 1.9.3.x 버전 근처에서) 시작되었으며 많은 이름의 로그 파일을 처리해야 할 때 매우 성가시다. 처음에는 다른 하위 폴더에 있음).

그 코드 조각은 아마도 Magento 팀에서 의도적으로 만들어 졌기 때문에 추가 릴리스에서 수정 할 계획이 없다고 생각합니다. 초기 동작을 복원하기 위해 해킹해야합니다 ...


그 하위 폴더 문제에 대해서는 실마리가 없지만 실제 로깅 문제에 대해서는 gist.github.com/piotrekkaminski/…
rodrigoriome
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.