Logrotate จะไม่อ่านไฟล์กำหนดค่าที่เชื่อมโยงแล้วเนื่องจากความเป็นเจ้าของที่ไม่ใช่รูท


15

ขณะนี้เรากำลังอัปเกรดจาก Ubuntu 12.04 LTS เป็น 14.04 LTS บน ruby ​​ของเราบนเซิร์ฟเวอร์แอปพลิเคชันทางรถไฟและสังเกตว่าไฟล์บันทึกไม่หมุนอีกต่อไป

ในทั้งสองเครื่องเรามีไฟล์ที่/var/app-name/config/logrotateเป็นของผู้ใช้ unix deployerซึ่งมีไฟล์ logrotate ที่ถูกต้องดังนี้:

/var/app-name/log/*.log {
  daily
  rotate 365
  delaycompress
  compress
  dateext
  dateformat -%Y%m%d
  missingok
  copytruncate
}

นี่คือ symlinked ใน/etc/logrotate.d/ไดเรกทอรีเป็นapp-name

บนเซิร์ฟเวอร์ Ubuntu 12.04 ของเราเรามี logrotate 3.7.8 ซึ่งทำงานได้ดี มันจะเข้าสู่var/app-name/log/ไดเรกทอรีและหมุนไฟล์บันทึกทั้งหมด

แต่บนเซิร์ฟเวอร์ Ubuntu 14.04 เรามี logrotate 3.8.7 ซึ่งไม่หมุนไฟล์ล็อกสำหรับแอปพลิเคชันของเรา

เมื่อฉันดีบักผ่านsudo logrotate -d -f /etc/logrotate/.confฉันได้รับผลลัพธ์ต่อไปนี้:

Ignoring /etc/logrotate.d/app-name because the file owner is wrong (should be root).

ดูเหมือนว่าการเปลี่ยนแปลงนี้จะถูกเพิ่มเข้ามาสำหรับสตรีมที่วางจำหน่าย 3.8.x: https://github.com/demands/logrotate/commit/b8ce386a969c60e5c8ee78023c24a1ba0aab1526

หากฉันเปลี่ยนความเป็นเจ้าของไฟล์ที่เชื่อมโยงไป/var/app-name/config/logrotateเป็นrootแล้วมันจะเริ่มทำงานอีกครั้ง แต่เนื่องจากไฟล์นี้เป็นส่วนหนึ่งของแอปพลิเคชันของฉันและสร้างโดยกรอบการปรับใช้ capistrano ที่เราใช้ในสถานะนี้ฉันไม่ต้องการแก้ไขความเป็นเจ้าของเมื่อมันใช้งานได้ดี

ดังนั้นไฟล์กำหนดค่า symlinked แนะนำ / สนับสนุนโดย logrotate?

และถ้าเป็นเช่นนั้นมันควรจะปฏิเสธที่จะใช้ไฟล์ของฉัน (เป็นเจ้าของโดยdeployer) ซึ่งเชื่อมโยงไปยัง/etc/logrotate.dไดเรกทอรีจะถูกมองว่าเป็นข้อผิดพลาด?

หรือมีวิธีอื่นที่แนะนำสำหรับการหมุนเวียนบันทึกเฉพาะแอปพลิเคชัน

(ถามด้วยunix StackExchange )


คำถามที่ดี! ฉันเห็นว่ามีการสนทนาในภายหลังเกี่ยวกับการตรวจสอบชื่อผู้ใช้ "รูท" แทนที่จะเป็น uid == 0 แต่นั่นก็ไม่ได้ทำให้เกิดคำถามว่าทำไมต้องมีการเป็นเจ้าของรูท
ตลอดไป

คำตอบ:


6

ปัญหาคือไฟล์ config logrotate สามารถเรียกใช้คำสั่งใด ๆในฐานะ root (โดยใช้ prerotate / postrotate stanzas) ดังนั้นคุณจะได้อย่างมีประสิทธิภาพจะให้คุณdeployerสิทธิ์ root /etc/logrotate.d/ผู้ใช้โดยให้มันเขียนการเข้าถึงไฟล์ใน ไม่ใช่เลยมันไม่ใช่บั๊ก

หากคุณไว้วางใจใช้ Deployer ของคุณแล้วผมคิดว่าคุณสามารถแก้ปัญหาที่เกิดขึ้นโดยให้มัน sudo /etc/logrotate.d/สิทธิในการคัดลอกไฟล์ลงใน แน่นอนว่าผู้ใช้งานไม่ใช่ผู้ใช้เดียวกันกับที่เว็บแอปพลิเคชันทำงาน


วิธีการของเรานั้นต้องการ symlink จากไดเรกทอรีภายนอกไปยังแอปพลิเคชันลงในไฟล์แอปพลิเคชันเสมอซึ่งการปรับใช้แต่ละครั้งไม่เพียง แต่ผลักดันแอปพลิเคชันใหม่ แต่ยังรวมถึงการเปลี่ยนแปลงไฟล์การกำหนดค่าด้วย แม้แต่การให้สิทธิ์แก่ผู้ปรับใช้ในการปรับใช้โค้ดนอกไดเรกทอรีแอปพลิเคชันก็เป็นการละเมิดวิธีการนี้ แต่อย่างเท่าเทียมกันที่ต้อง chown ไฟล์แอพพลิเคชั่นเพื่อให้ root เป็นเจ้าของหลังการปรับใช้รู้สึกเหมือนสิ่งเลวร้ายเช่นกัน บางทีวิธีการดั้งเดิมดังนั้นจึงไม่สามารถทำงานได้ดีกับ logrotate 3.8.0+ อีก
phantomwhale

2
@phantomwhale วิธีการดั้งเดิมของคุณให้สิทธิ์ผู้ใช้โปรแกรมรูเล็ตแบบเต็มโดยปริยาย นั่นไม่ใช่เรื่องใหม่ใน logrotate 3.8 หากคุณต้องการ จำกัด สิทธิ์ของผู้ปรับใช้ในขณะที่ยังอนุญาตให้อัปเดตการกำหนดค่าฉันคิดว่าคุณต้องใช้สิ่งอื่นที่ไม่ใช่ logrotate
เพลล์

2

ฉันรู้ว่าฉันมาสายไปงานเลี้ยง แต่ฉันมีปัญหาที่คล้ายกันและคิดว่าฉันจะแบ่งปันวิธีแก้ปัญหาของฉัน

ปัญหาของฉันเริ่มต้นเมื่อlogrotateไม่อ่านการกำหนดค่าที่ฉันเขียน ฉันไม่ต้องการปรับใช้การกำหนดค่าใหม่ลงในโฟลเดอร์ที่เป็นเจ้าของโดยรูทเพราะฉันไม่ต้องการให้ผู้ใช้งานสามารถเข้าถึงรูทได้ทุกอย่าง

ตอนแรกผมพยายามที่จะทำงานlogrotateเป็นผู้ใช้ปรับใช้ /var/lib/logrotate/stateแต่ก็บ่นเรื่องที่มีการเข้าถึงไฟล์รัฐที่ จากนั้นฉันก็อ่าน man page คุณสามารถระบุไฟล์สถานะที่logrotateใช้! ดังนั้นจึงเป็นวิธีที่ดีกว่าสำหรับฉันในการตั้งค่า cron รายวันเพื่อดำเนินการlogrotateในฐานะผู้ใช้งานด้วยไฟล์สถานะที่กำหนดเอง วิธีนี้ไม่จำเป็นต้องเข้าถึงรูทโดยผู้ใช้หรือแอ็พพลิเคชัน

นี่คือวิธีที่คุณระบุไฟล์สถานะ:

logrotate --state /path/to/status /path/to/custom_logrotate.conf

ตอนนี้คุณสามารถรัน logrotate ในฐานะผู้ใช้และเจ้าของการกำหนดค่าที่คุณต้องการ!

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.