DNF는 불평 없이 패키지를 내려받습니다. GNOME Software는 카탈로그를 보여 주다가 무언가를 설치하려 하면 멈춥니다. 그래픽 앱이 프록시를 그냥 무시한다고 결론 내리기 쉽습니다. 다른 가능성도 있습니다. 프록시 정보가 다운로드를 수행하는 구성 요소에 애초에 도달하지 못한 것입니다.

전달 과정을 따라가기

GNOME Software와 터미널에 입력한 명령은 같은 설정 경로를 쓰지 않습니다. PackageKit의 프록시 문서는 데스크톱 설정을 읽어 데몬으로 넘기는 세션 프로세스를 설명합니다. GNOME에서는 gnome-software가 GSettings를 읽고 PackageKit의 프록시 설정 인터페이스를 호출합니다.

그다음 데몬이 해당 세션의 설정을 자체 패키지 백엔드에 제공합니다. 즉 성공한 DNF 요청은 프록시가 그 DNF 호출을 처리할 수 있음을 증명합니다. 데스크톱 세션이 같은 설정을 PackageKit에 등록했다는 것은 증명하지 않습니다.

세 가지 유용한 질문

  1. 어떤 작업이 실패했는가? 카탈로그 데이터 보기, 메타데이터 새로 고침, 패키지 다운로드는 서로 다른 작업입니다. 실제로 오류를 내는 작업을 기록하십시오.
  2. 세션 프록시가 등록되었는가? 데스크톱의 실제 프록시 설정과 PackageKit이 보고한 오류를 확인하십시오. 프록시를 설정하지 못한 것과 다운로드 중 프록시가 407을 반환하는 것은 다릅니다.
  3. 어느 버전이 이 설정을 소유하는가? PackageKit은 시간이 지나며 바뀌었습니다. Fedora 25에 관한 답변에서 복사한 설정 키는 오래된 백엔드나 더는 적용되지 않는 버그를 설명할 수 있습니다.

터미널에서 export한 변수는 이 전달 과정을 확인하는 신뢰할 만한 대체물이 아닙니다. 데몬은 export를 입력한 셸의 자식 프로세스가 아니며, 그래픽 로그인은 다른 환경일 수 있습니다.

모든 수정은 문제를 소유한 구성 요소에 붙여 두십시오. 데스크톱 설정이 잘못되었다면 그 설정을 고치십시오. 등록이 실패한다면 그 오류와 버전 정보를 보존하십시오. 프록시가 다운로드를 거부한다면 인증 정책이나 대상 정책을 조사하십시오. 저장소 파일을 한꺼번에 모두 편집하면 구분이 흐려지고 명령줄과 그래픽 설정을 유지하기 어려워질 수 있습니다.

관련 글