Tôi có nên chỉnh sửa / etc / crontab hoặc chạy crontab -e với quyền root không?

43

Tôi đang thiết lập các tác vụ bảo trì hệ thống thường xuyên phải chạy bằng root. Tôi dự định sử dụng hương vị của cron đi kèm với Ubuntu 14.04 LTS làm mặc định.

Tôi thấy quản trị viên trước đó (người đã rời công ty) đã chỉnh sửa / etc / crontab trực tiếp. Tuy nhiên tôi hiểu một cách tiếp cận khả thi khác là sử dụng crontab -enhư root. Có bất kỳ đối số hấp dẫn để sử dụng cái này hay cái kia, hoặc nó tùy thuộc vào sở thích?

linux cron ubuntu-14.04

— tháng ba
nguồn

9

Đối với tôi, đây có vẻ như là một câu hỏi thực hành tốt nhất hợp pháp và tôi hy vọng nó không bị đóng cửa. Tôi đã có thể thấy các điểm thực tế có liên quan được đưa ra trong các câu trả lời và nhận xét.

— MadHatter hỗ trợ Monica

1

Tôi đã từng đi gõ crontab -l (để liệt kê crontab) nhưng tôi đã gõ crontab -; thay vào đó là do xóa crontab của tôi. Tôi đã học được rất nhiều ngày hôm đó.

— Lumberjack

64

Có thể hữu ích khi lưu ý rằng các công việc trong crontab ( crontab -e) cá nhân luôn được thực thi với tư cách là chủ sở hữu của chúng, trong đó /etc/crontabcó một <user>trường bắt buộc bổ sung cho phép quản trị viên định cấu hình công việc để chạy như một người dùng không root.

Chỉnh sửa crontab hệ thống hoặc thiết lập crontab cá nhân cho root có thể dễ mang theo hơn một chút, không cụ thể đối với các bản phân phối Linux nhất định và có thể thuận tiện hơn cho một người để duy trì, với tất cả các công việc trong một tệp nhưng:

Cá nhân tôi ủng hộ một lựa chọn thứ ba : cho mỗi nhiệm vụ được lên lịch

một tập tin /etc/cron.d/với một đoạn cron
một tập tin thực thi (script) trong /etc/cron.[hourly |daily |weekly |monthly]thư mục có liên quan .

Việc tạo tập lệnh dễ dàng hơn (bạn có thể chỉ cần tạo / ghi đè / xóa các tệp đó và bạn không phải làm hỏng nội dung của một tệp crontab) và hoạt động tốt với công cụ quản lý cấu hình và đó là những gì trình quản lý gói đã có làm gì cũng được.

Các công việc / tập lệnh trong /etc/cron.[hourly |daily |weekly |monthly]luôn được thực thi dưới dạng root, trong đó các đoạn cron /etc/cron.d/cho phép cả hai thiết lập lịch tùy chỉnh cũng như chạy như một người dùng khác với cùng một <user>trường bắt buộc được tìm thấy /etc/crontab.

— HBruijn
nguồn

18

Một nhược điểm của chỉnh sửa /etc/crontablà hợp nhất sẽ được yêu cầu bất cứ khi nào bạn cập nhật crongói. Bạn không gặp vấn đề đó nếu bạn chỉ cần thêm một tệp mới vào một trong các /etc/cron.*thư mục.

— kasperd

1

Bạn nên thêm rằng trong hầu hết các distro /etc/cron.[hourly |daily |weekly |monthly]giữ thực thi trong khi /etc/cron.dgiữ crontabs. Ngoài ra, +1.

— GnP

Tôi chắc chắn là một fan hâm mộ của các thư mục cron. [Thời gian], tôi hiếm khi cần bất cứ điều gì chi tiết hơn các tùy chọn commn. Mặc dù xin lưu ý rằng một số bản phát hành, đặc biệt là Ubuntu, sẽ âm thầm bỏ qua các tập lệnh có phần mở rộng tệp trong các thư mục này (một lỗi khá khó chịu trên internet, vì hầu hết mọi người sẽ thêm .sh, có thể đã được sửa trong các bản phát hành gần đây). Rất khó để tìm ra lý do tại sao các tập lệnh không hoạt động trong tình huống đó - ít nhất là thêm vào crontab được đảm bảo để thực thi.

— Gargravarr

15

Như tôi nhớ nhất, crontab -ecó một ưu điểm nữa là nó xác minh cú pháp crontab trước khi cài đặt nó, và sẽ lỗi và khôi phục lại trước đó nếu bạn mắc lỗi. Bằng cách này, mọi thứ trước đây hoạt động sẽ không đột ngột dừng lại nếu bạn hiểu sai cú pháp. Tôi nghĩ cách tốt nhất là sử dụng các tiện ích, như chạy visudohơn là chỉnh sửa /etc/sudoerstrực tiếp.

— Gargravarr
nguồn

2

+1 Điểm hay về xác thực cú pháp, mặc dù nó nhận ra một số lỗi cú pháp nhưng nó cũng không phải là chứng minh đánh lừa (tức là nó sẽ vui vẻ cho phép bạn nhập một /etc/crontabdòng có tên người dùng trong cột thứ 6). - Mặc dù tôi muốn lập luận rằng việc sử dụng các công cụ tương tác không phải là "cách tốt nhất" , bạn nên tự động hóa với các công cụ như Puppet / Salt / Ansible, v.v. và không nên cấu hình máy chủ bằng tay ngay từ đầu. Mặt khác, nếu bạn là trường học cũ, thì thực sự sử dụng các công cụ của bạn.

— HBruijn

Ansible và các ứng dụng khác đều tốt nếu bạn định cấu hình 5+ máy chủ, nhưng không đáng để gặp rắc rối chỉ 1. Bạn có thể lập luận rằng chỉ với 1 máy chủ, tập lệnh Ansible cung cấp cho bạn khả năng xây dựng lại chính xác khi nó bị lỗi 2 năm, nhưng tại thời điểm đó, tập lệnh có thể không hoạt động nữa do các thay đổi của distro / repos.

— marcv81

Đây là lý do tôi kịch liệt không đồng ý với câu trả lời được chấp nhận. Bất kỳ thay đổi nào đang được thực hiện nên được thực hiện thông qua quá trình xác nhận này ít nhất một lần. Nếu sau đó sao chép một dòng từ crontab mới và cung cấp nó cho một công cụ tự động để truyền tới các máy chủ khác, thì đó là điều tốt nhất của cả hai thế giới.

— Monty Harder

Không giúp được gì nếu khởi chạy một tập lệnh và có lỗi trong tập lệnh, do đó, kiểm tra chạy khô là bắt buộc theo một trong hai cách.

— mckenzm

@mckenzm đã đồng ý, nhưng bạn chỉ có thể áp dụng rất nhiều bằng chứng ngu ngốc :)

— Gargravarr

2

Nó thực sự là một câu hỏi phong cách, có một lý do nhiều phương pháp được cung cấp bởi hệ điều hành. Chỉ cần nhất quán và không trộn lẫn và khớp nếu bạn không muốn gây nhầm lẫn cho bất kỳ ai khác (hoặc chính bạn sau một thời gian không xử lý hệ thống) - nếu khó thấy các nhiệm vụ thực sự được lên lịch trên toàn bộ máy chủ, nó có xu hướng để kết thúc trong những bất ngờ khó chịu.

— rackandboneman
nguồn

2

Để chắc chắn để thêm một công việc định kỳ yêu cầu quyền của một người dùng cụ thể, cá nhân tôi sử dụng lệnh sau:

 # crontab -u <user> -e

Bạn có thể thêm sudoquá.

Như @rackandboneman đã nêu, không cần phải lộn xộn với các tập tin /etc/cron.d/. Nếu vấn đề là về công việc định kỳ của người dùng, hãy sử dụng các tính năng của crontablệnh.

— aesnak
nguồn

3

-1 Nhược điểm lớn của việc thực hiện ở trên là người dùng hiện có thể sửa đổi / xóa / ngắt cronjob, điều này thường không được mong muốn khi bạn là quản trị viên dành thời gian quý báu của mình để thiết lập mọi thứ ... Ngoài ra khi người dùng là tài khoản dịch vụ và tài khoản đó đã bị khóa / hết hạn, dịch vụ sẽ tiếp tục chạy nhưng các tab cron cá nhân cho các tài khoản bị khóa thường sẽ bị vô hiệu hóa.

— HBruijn

Nếu người dùng được chỉ định ở đây là người dùng công cộng, chẳng hạn như thành viên của môi trường dịch vụ đầu cuối công cộng, bạn đã đúng. Tuy nhiên, nếu vấn đề là về người dùng của một dịch vụ / đại lý ... theo suy nghĩ thứ hai, thì đó thực sự là về phong cách.

— aesnak