최근 시스템이 ‘무음’ 변경 사항으로 download_remote_images_to_local 기능을 비활성화했습니다. 사이트 소유자로서 이 건에 대해 다이렉트 메시지를 받았으면 유용했을 것입니다. 다만, 이와 유사하게 시스템이 업데이트할 수 있는 변경 사항이 더 있는지는 확실하지 않습니다.
10개의 좋아요
디스크가 가득 차면 그런 일이 발생하는 걸 본 적이 있어요. 그게 원인이었나요, 아니면 다른 문제가 있었나요?
3개의 좋아요
완전 가득 차진 않았지만, 원격 이미지 다운로드를 위해 설정한 임계값 아래로 내려간 상태였습니다.
4개의 좋아요
제안은 합리적이라고 생각합니다. 불행히도, 당분간 이 작업에 시간을 할애하기는 어려울 것 같습니다.
커뮤니티에서 이 문제를 조사해 보고 싶은 사람이 있을 경우를 대비해 pr-welcome 태그를 붙여 두었습니다. (설정을 조정할 때 관리자에게 PM을 보내야 합니다)
7개의 좋아요
시스템이 기본 신뢰 수준을 우리가 설정해 둔 “1”에서 “0”으로 변경하면서 사이트가 손상되었습니다.
승인이나 통보 없이 시스템이 프로덕션 사이트에 임의의 변경을 가할 수 있다는 점은 매우 놀라운 일이며, 앞으로 이러한 일이 다시 발생하지 않도록 방지해야 합니다.
이러한 자동 시스템 변경을 비활성화하는 방법이 있을까요?
1개의 좋아요
이런 일은 일어나서는 안 됩니다. TL1을 기본값으로 사용하는 사이트가 꽤 많습니다. 더 많은 맥락이 필요하니, 이 문제에 대해 새로운 주제를 열어 주시겠습니까?
4개의 좋아요
결국 이 문제는 우리가 설정 중이던 새로운 서버/앱에서 부트스트랩(bootstrap) 모드가 활성화되어 발생한 것으로 밝혀졌습니다.
하지만 제 메시지는 이 특정 시스템 변경 사항 자체보다는, 시스템 변경이 이상적으로는 승인 과정을 거쳐야 한다는 점에 더 초점을 맞추고 있었습니다. 그렇게 해야 시스템이 깨지는 일이 방지될 수 있거든요. 승인이 불가능하다면, 최소한 변경 사항에 대해 모든 관리자(Admin)에게 이메일로 통보하는 것(이것이 원글 작성자가 원했던 것 같습니다)이 좋겠습니다.
Discourse 개발에 수고 많으셨습니다!
2개의 좋아요
안녕하세요 @Earnie_Baird, 정말 좋은 피드백입니다.
한 가지 제안 드리자면, 부트스트랩 모드에 대한 명확성을 더 높이는 것이 좋을 것 같습니다. 헤더에서 해당 항목을 보고 클릭했을 때, 어떤 일이 발생했는지가 매우 명확하게 설명되도록 하는 것이죠.
3개의 좋아요
내가 알지 못하는 변경 사항이 있었다면 (있었다고 생각하지는 않지만), 이 기능 요청에 강력히 찬성합니다.
디스크 공간이 일시적으로 부족할 때 이 문제를 여러 번 겪었습니다.
매번 우연히 해당 설정이 비활성화되어 있다는 사실을 알게 되었습니다. 디스크 공간 임계값에 도달했을 때 설정 변경 사항을 확인해야 한다는 생각조차 하지 못했습니다. 심지어 이 문제를 여러 번 경험한 후에도요.
한 해 전에 디스크 공간이 부족해졌을 뿐이라는 이유로, 관리자가 이를 인지하지 못한 채 이 설정이 비활성화된 사례가 실제로 많이 있을 것이라고 확신합니다.
해당 설정 변경 사항은 /admin/logs/staff_action_logs?filters=%7B"subject"%3A"download_remote_images_to_local"%7D에 기록되지만, 트리거가 발생했을 때 알림을 받은 기억이 없습니다.
이상적으로는 대시보드에 최소한 경고가 표시되거나, 사용자 메뉴에 알림이 뜨거나, 이메일을 받는 것이 좋겠습니다.
아래 인용문의 맥락은 꽤 구체적이고 오래되었지만, 이 경우에도 적용됩니다.
@system에 의해 설정이 변경될 때 어떤 형태의 알림도 없는 것은 해로울 수 있습니다.
download_remote_images_to_local이 어느 시점에 비활성화되었음을 알게 되면, 원격 파일을 다운로드하도록 트리거하기 위해 다음 레일스 스크립트 중 하나(또는 한 번만 둘 다)를 실행합니다:
주어진 날짜 이후의 모든 게시글 다시 생성(Rebake)
i = 0
Post.where('created_at >= ?', Date.new(2023, 5, 1)).where('user_id > 0').find_each do |post|
post.rebake!
puts "Post #{post.id}, Created at #{post.created_at}"
i += 1
end
puts "Total number of posts rebaked: #{i}"
두 주어진 날짜 사이의 모든 게시글 다시 생성(Rebake)
i = 0
Post.where('created_at >= ? AND created_at < ?', Date.new(2021, 12, 1), Date.new(2022, 3, 1)).where('user_id > 0').find_each do |post|
post.rebake!
puts "Post #{post.id}, Created at #{post.created_at}"
i += 1
end
puts "Total number of posts rebaked: #{i}"
3개의 좋아요
Get admin notification from logs? - #4 by JammyDodger 을 읽다가 이 주제에 대해 다시 생각하게 되었습니다. “Data Explorer 결과를 통해 PM 예약” 또는 “Data Explorer 결과를 통해 토픽에 게시글 예약” 자동화 스크립트와 데이터 탐색기 쿼리를 사용하여 시스템에 의한 사이트 설정 변경 사항에 대한 알림을 받을 수도 있다고 생각합니다.
다음과 같은 쿼리를 사용할 수 있습니다.
SELECT subject, previous_value, new_value, updated_at
FROM user_histories uh
where uh.action = 3
AND uh.acting_user_id = -1
AND uh.updated_at > CURRENT_TIMESTAMP - INTERVAL '60 minutes'
order by updated_at desc
그런 다음 쿼리의 간격과 일치하도록 재발을 설정하고, 결과가 없으면 건너뛰도록 하여 노이즈를 방지하면 됩니다.
쿼리를 개선하여 정확한 subject를 필터링할 수도 있지만, 다른 자동 변경 사항들도 흥미로울 수 있다고 생각했습니다.
5개의 좋아요
Moin님 안녕하세요
이렇게 답변해 주셔서 감사합니다. 정말 유용한 아이디어네요!
이 쿼리를 실행해 보았지만, 서사(Narrative) 자동 비활성화와 같은 변경 사항은 표시되지 않습니다.
1개의 좋아요
맞습니다! 로그에 이 항목이 없습니다. 자동화 기능은 스태프 액션 로그에 기록된 변경 사항에 대해서만 알림을 보내기 때문입니다. 그래서 이러한 변경 사항에 대해 항상 항목이 생성되어야 한다고 제안드렸습니다.
이 쿼리는 의도적으로 짧은 시간 범지만 조회합니다. 시간 제한 주석을 해제하면 일부 변경 사항은 확인되지만, 대부분의 변경 사항에 대해서는 로그 항목이 없습니다.
- AND uh.updated_at > CURRENT_TIMESTAMP - INTERVAL '60 minutes'
+ --AND uh.updated_at > CURRENT_TIMESTAMP - INTERVAL '60 minutes'
다만, 자동화 스크립트가 이러한 오래된 변경 사항을 보고하지 않도록 하기 위해 이 시간 제한을 추가했습니다.
3개의 좋아요
어떤 동작이 예상치 못하게 변경되었을 때 문제 해결을 위해 어떤 사이트에서든 유용한 쿼리입니다. 심지어 관리자 본인이나 다른 관리자가 무언가를 변경하여 예상치 못한 결과가 발생했을 수도 있습니다.
저는 메타에서 이 쿼리를 주 1회 실행하는 자동화를 설정하여 지난 1주일 동안 기록된 모든 변경 사항을 표시하도록 했습니다. 여기에는 많은 관리자가 활동하고 있어 상황을 한눈에 파악하기가 쉽지 않은 경우가 있습니다.
제 생각에는 여기의 기능 요청 사항은 모든 스태프의 작업을 더 포괄적으로 기록하는 것일 것입니다.
2개의 좋아요
공유한 쿼리는 사이트 설정에 대한 변경 사항으로 제한되며, 시스템에 의한 작업으로만 제한됩니다. 따라서 디스크가 가득 차서 이미지 다운로드를 비활성화하는 것과 같은 자동화 때문이거나, 부트스트랩(bootstrap) 모드가 끝나면 설정이 변경되는 경우와 같이 시스템에 의해 설정이 변경된 시점을 파악하는 데 도움이 됩니다. 자동화 플러그인의 게시글이나 개인 메시지(PM)와 결합하면 OP(원포스터)에서 설명한 것과 같은 사례에서 도움이 될 수 있습니다.
그러나 이 쿼리는 discobot @gassim 이 알기를 원했던 환영 메시지 비활성화 변경 사항과 같은 의도치 않은 변경 사항을 찾는 데는 실제로 도움이 되지 않습니다. Discourse 업데이트 동안 발생하는 대부분의 설정 변경 사항은 기록되지 않으며, 이것이 그들을 추적하기 어렵게 만드는 이유입니다.
2개의 좋아요
지난 1주일 동안 기록된 모든 변경 사항을 표시하도록 쿼리를 수정했습니다.
공백을 채워야 한다는 점에 동의합니다. 기록되는 작업이 충분하지 않습니다.
2개의 좋아요
여기서 두 가지 생각이 듭니다:
- 이는 대시보드에 관리자 알림을 추가하는 간단한 문제 검사로 처리할 수 있습니다.
- 코드는 디스크 공간이 부족할 때 설정을 비활성화하는 것을 알고 있습니다. 하지만 코드는 디스크 공간이 충분할 때도 알기 때문에, 이론적으로는 다시 다운로드를 시작할 수 있어야 합니다. 다만, 코드는 해당 설정이 의도적으로 활성화되어 있어야 한다는 사실을 알지 못하므로, 이를 위해서는 다른 진실의 원천(source of truth)이 필요합니다.