이것은 이 포럼의 첫 번째 게시물이며 이 질문의 성격 때문에 여기에 와야 했습니다. 나와 상사는 무슨 일이 일어나고 있는지 혼란스러워서 여기 전문가를 만나야 했습니다.
머리말로서 저는 소규모 회사의 주니어 웹 개발자이고 회사의 서버 구성에 직접 액세스할 수 없습니다. 내 모든 작업은 Docker에서 로컬로 수행된 다음 승인을 위해 상사에게 제출됩니다. 설정에 대한 특정 세부정보가 필요한 경우 필요한 내용을 게시물에 업데이트해 드리겠습니다.
어쨌든, 이 기사의 제목에서 알 수 있듯이 우리는 Apache2를 사용하는 Debian Stretch에서 Apache 2를 사용하는 Debian Bullseye로 웹 애플리케이션을 천천히 마이그레이션해 왔습니다.
우리는 이 서버 환경에서 3개의 웹 애플리케이션을 실행하고 있는데, 2개는 PHP이고 1개는 Perl입니다. 세 가지 모두 사용자에게 파일 업로드 기능을 제공합니다.
상황을 더욱 복잡하게 만들기 위해 제 상사는 세 개의 웹 서버를 운영하고 있습니다. web01 및 web02는 작동 중인 Stretch 버전을 실행 중입니다. 그런 다음 그는 소프트 배포 및 소규모 사용자 테스트를 위해 web03에 대한 Bullseye 업데이트를 시작하려고 시도했습니다.
이제 주니어 개발자로서 로컬 Docker 환경에서 테스트할 때 이 오류를 완전히 무시했습니다. 내 상사는 web03에 배포한 후에야 이 업로드 문제를 발견했습니다. 이 업로드 문제는 PHP와 Perl 웹 애플리케이션 모두에 영향을 미치므로 코드보다는 구성과 관련된 것으로 보입니다. Bullseye 배포의 다른 모든 항목은 정상적으로 실행되지만 파일 업로드 및 검색이 우리를 괴롭히는 유일한 버그이며 이 특정 문제가 있는 다른 사람을 찾을 수 없습니다.
다음은 Perl 프로그램의 간단한 코드 조각입니다. 이 줄에서 실패하는 것을 좋아하며 /tmp 디렉토리가 이미 존재하더라도 수정할 수 없다고 주장합니다.
open(my $fh, "<", "/tmp/$csvfile") or die "Can't open $csvfile: $!";
이것은 그가 본 것을 설명하는 내 상사의 직접적인 인용문입니다.
이상한 문제가 발생하여 /tmp에 업로드된 파일을 찾을 수 없습니다. systemd가 apache2 /tmp를 사용하여 이상한 작업을 수행하고 이를 별도의 개인 폴더로 지정한다는 것을 알고 있지만 이미 그런 경우가 늘어나고 있습니다. 과녁의 무언가가 그것을 더 깨뜨리는 것처럼 보였습니다. 응용 프로그램 1과 응용 프로그램 2가 모두 영향을 받으므로 이는 Perl이나 PHP에만 국한되지 않습니다. jobtracker에서 "파일 /tmp/xxxxx.csv를 찾을 수 없음" 오류가 발생합니다. 애플리케이션 2는 디스크 공간이 부족하다고 불평하지만 이는 업로드되는 파일의 크기를 확인할 수 없기 때문에 기본 오류일 뿐입니다.
뭔가를 업로드할 때 /tmp/systemd-..../tmp/ 경로의 타임스탬프가 업데이트되고 있다는 것을 분명히 볼 수 있습니다. 그래서 뭔가를 하고 있는데 어디서 실패하는지 모르겠습니다.
백엔드 지식의 한계에 확실히 도달했지만, 정말 상사를 돕고 세상을 구하여 보너스 포인트를 얻고 싶습니다.
이 글을 게시하기에 더 적절한 장소가 있는지 알려주세요. 하지만 제 직감으로는 서로 다른 두 언어로 된 두 애플리케이션에 동일한 파일 업로드 문제가 있는 경우 Debian 또는 Apache2 구성 문제인 것 같습니다.
내 상사는 세 개의 웹 서버가 모두 동시에 실행되기 때문에 처음에는 이것이 로드 밸런싱 문제일 수 있다고 생각했지만 web03이 web01 및 02 환경과 독립적으로 실행되고 있음에도 불구하고 업로드 문제를 재현했습니다. 데이터베이스 액세스를 제외하고 내 Docker 환경에서 동일한 오류가 발생합니다. 자체 지역화된 환경에서 실행되어야 합니다. 그렇죠?
더 많은 배경 정보가 필요한 사람이 있으면 언제든지 문의하세요. 배경 정보를 제공하려고 노력하겠습니다.
답변1
Debian 11 런타임에 대한 Apache 설정은 다음 섹션 에 포함되어 systemd있습니다 ./lib/systemd/system/apache2.service[Service]PrivateTmp=true녹음된처럼:
PrivateTmp=부울 매개변수를 사용합니다. 만약 사실이라면,새 파일 시스템 네임스페이스 설정 실행된 프로세스와 네임스페이스 외부의 프로세스에서 공유하지 않는 개인
/tmp/및 내부 디렉터리를 마운트합니다./var/tmp/. 이는 프로세스의 임시 파일에 안전하게 액세스하는 데 유용하지만/tmp/또는를 통해 프로세스 간 공유/var/tmp/가 불가능합니다 .. true인 경우 서비스가 중지된 후 해당 디렉터리에서 서비스에 의해 생성된 모든 임시 파일이 삭제됩니다. 기본값은 거짓입니다.
[...]
따라서 원래 호스트와는 숨겨져 있고 apache2다릅니다 ./tmp//tmp/
물론 해당 설정을 재정의할 수 있지만( 를 사용하여 sysctl edit apache2서비스 섹션 사용 및 추가 PrivateTmp=false) 권장되지 않습니다. 비공개 /tmp는 추가 보안을 위한 것이며 다른 패키지 앱은 동일한 설정을 가질 가능성이 높으며 설정도 변경해야 합니다( 이는 사실이 아닌 것으로 보입니다 php-fpm). 이 디렉토리를 공유하고 그에 따라 애플리케이션을 재구성하기 위한 전용 디렉토리를 갖는 것이 더 좋습니다.
단지 디버깅을 위한 경우나 단순히 숨겨진 파일이 어디에 있는지 알아내기 위한 경우에는 프로세스의 마운트 네임스페이스를 사용하지 않고도 프로세스의 마운트 네임스페이스에 액세스할 수 있는 바로가기가 있는데, unshare -m이러한 경우에는 종종 어렵습니다. /proc/<pid>/root/이 프로세스에 의해 마운트된 네임스페이스/마운트 지점에 대한 직접 링크입니다. 예를 들어, pgrep -u root ^apache2$12345와 같은 PID 결과가 주어지면(또는 생성된 apache2 PID 중 하나가 무작위로 선택된 경우) ls /proc/12345/root/tmp/이제 숨겨진 콘텐츠가 표시됩니다 /tmp/. 이런 방식으로 파일을 복사하는 것도 가능하지만 심각한 용도로 사용해서는 안 됩니다. 이 내용은 다음과 같이 기록됩니다.man proc.