require내 PHP 스크립트 상단에 파일이 있습니다 . 이 파일에는 MySQL 연결 개체만 있습니다.
$c->new mysqli('host','usr','pass','db')
파일에 400권한이 있으며 웹페이지 루트( )에서 멀리 -r--------
옮겼습니다 ./etc/mysql//var/www/html
매일 밤 자정에 작동이 중지되고 내 모든 페이지에 대해 권한 거부 오류가 발생하는 것을 제외하면 훌륭하게 작동합니다.
Warning: require(/etc/mysql/.myfile.php): Failed to open stream: Permission denied in...
권한을 으로 변경하려면 444내 사이트에 로그인하여 권한을 다시 변경하세요 400. 다음날 자정까지 일했습니다. 하루 종일 여러 번 내 사이트에 로그인하고 로그아웃할 수 있지만 자정이 되면 실패합니다.
이 문제의 원인과 해결 방법은 무엇입니까?
root분명히 일반 텍스트 비밀번호가 있으므로 파일을 읽을 수만 있도록 보관하고 싶습니다 .
답변1
이것은 주석이어야 합니다. 하지만 공간이 제한되어 있고 형식도 마찬가지입니다.
이 상황에 대해 실제로 좋은 설명을 제공하지 않습니다.
"권한을 잃었다"고 정상적인 작업을 재개하는 방법에 대해 말씀하셨지만 권한이 무엇인지는 밝히지 않으셨습니다.뒤쪽에자정 이벤트.
액세스 권한을 결정할 때 소유권 세부정보가 없으면 권한은 의미가 없습니다. 아마도 파일은 원래 웹 서버 uid가 소유했을 것입니다(실제로 웹 서버에서 실행되는 스크립트가 파일에 액세스했다고 말하지는 않았지만). 다시 말하지만, 이전과 이후는 무엇입니까?
자정에 멈췄다는 것을 어떻게 확인했나요? 이벤트가 발생한 시기를 정확히 아는 것은 문제 해결을 위한 유용한 디딤돌입니다. 00:00:00에서 00:03:00 사이에 발생하면 예약된 작업으로 인한 것일 가능성이 높습니다. 이것도 만들어준다많은시스템 로그(웹 서버 로그 포함)와 이벤트를 더 쉽게 상호 참조할 수 있습니다.
다만, 권한과 접근권한을 고려해 주셔서 감사합니다...
선택한 권한은 적합하지 않습니다. 다시 한번 이것이 웹 서버라고 가정하면 이 파일은 루트 사용자만 관리할 수 있습니다. 서버를 유지 관리하는 유일한 사람인 경우 더 나은 접근 방식은 소유권을 bungee1980:wwwgrp(여기서 wwwgrp는 웹 서버 uid의 기본 그룹) 및 권한 -rw-r----(0750)으로 설정하는 것입니다.
선택한 위치가 이상적이지 않습니다. 대부분의 최신 운영 체제는 필수 액세스 제어 메커니즘(RHEL의 SELinux 및 그 파생 제품, Apparmor의 다른 곳)을 통해 파일 액세스를 제한합니다. 네트워크 서버는 일반적으로 해당 내용을 포함하는 디렉토리 트리로만 제한됩니다. 분명한 이유로 이 파일이 문서 루트에 있는 것을 원하지 않는 반면, (보통) 스크립트가 /etc의 다른 많은 파일에서 직접 읽는 것을 허용하지도 않습니다.
작은 문제는 PHP입니다메커니즘을 제공합니다기본 자격 증명 및 데이터베이스 세부 정보를 설정하는 데 사용됩니다.추가 상용구 코드 실행대상 스크립트 앞). 웹 서버 구성에서 설정할 수 있다는 점을 고려하면 이것이 더 적절한 자격 증명 도구일 수 있습니다.
답변2
권한을 444로 변경하면 내 사이트에 로그인하여 권한을 다시 400으로 변경하세요.
즉, 권한 400을 사용하면 스크립트가 파일을 읽을 수 없지만 권한 444를 사용하면 읽을 수 있습니다. 그런 다음 일부 프로세스는 자정까지 파일을 열어 두거나 RAM에 자격 증명을 유지합니다. 이때 자정까지 일부 이벤트가 트리거됩니다. 재부팅하거나 일종의 정리를 수행합니다.
어떤 OS/배포판을 사용하고 있는지는 언급하지 않았지만 먼저 /etc/cron.*관련 사용자의 crontab(일반적으로 crontab /var/spool/cron[/crontabs]또는 유사)에서 자정에 실행되는 일일 cron 작업을 확인하겠습니다. 어쩌면 오래된 PHP 세션을 정리할 뭔가가 있을까요? 아니면 일일 로그 회전 일정의 일부로 logrotate무언가 다시 시작을 트리거 할 수도 있습니까?php-fpm
또한 시스템에서 타이머 단위를 사용하는 경우 타이머 단위를 확인하세요 systemd. systemctl list-units --type=timer모든 시스템 전체 타이머를 나열하고 systemctl cat <name>.timer확인하세요.
예를 들어 Debian 12에서는 logrotate에 의해 트리거될 수 있고 에 지정된 시간에 실행될 /etc/cron.daily/logrotate수 있으며 기본값은 시스템이 실행되는 07:30에서 23:30 사이의 가장 빠른 시간입니다. 그러나 이 일정은 실제로는 사용된anacron/etc/cron.d/anacronsystemd사용하지 않을 때만에 지정된 작업은 /etc/cron.d/anacron조건부 작업이므로/run/systemd/system 아니요기존의.
systemd대신 logrotate.timer다음과 같이 지정된 를 사용하십시오 .
systemctl cat logrotate.timer
# /lib/systemd/system/logrotate.timer
[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)
[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true
[Install]
WantedBy=timers.target
에 명시된 바와 같이 man systemd.time는 정확히 매일 자정을 OnCalendar=daily의미합니다 . 이 타이머를 00:00에서 01:00(있는 경우) 사이에 작동하는 다른 타이머와 병합하여 절전을 최적화할 *-*-* 00:00:00수 있습니다 . AccuracySec=1h적어도 내 시스템에서는 최종 결과는 시스템이 해당 시간에 다운되지 않는 한 정확히 자정에 로그 회전이 발생하는 것 같습니다.
을 사용하면 systemctl status logrotate.timer타이머의 다음 예정된 작동 시간을 볼 수 있습니다.