Hiểu đăng nhập trong Linux

Theo tôi hiểu, nhân Linux ghi nhật ký vào /proc/kmsgtập tin (chủ yếu là các tin nhắn liên quan đến phần cứng) và /dev/logổ cắm? Bất cứ nơi nào khác? Các ứng dụng khác cũng có thể gửi tin nhắn đến /proc/kmsghay /dev/log? Cuối cùng nhưng không kém phần quan, tôi sửa rằng đó là daemon syslog ( rsyslog , syslog-ng ) mà kiểm tra các tin nhắn từ những người hai nơi và sau đó phân phối những các tập tin khác nhau như /var/log/messageshoặc /var/log/kern.loghoặc thậm chí máy chủ syslog trung tâm?

Đơn giản hóa, nó đi ít nhiều như thế này:

Hạt nhân ghi thông điệp (sử dụng printk()hàm) vào bộ đệm vòng trong không gian kernel. Các thông báo này được cung cấp cho các ứng dụng không gian người dùng theo hai cách: thông qua /proc/kmsgtệp (với điều kiện /proclà được gắn kết) và thông qua tòa nhà sys_syslogchọc trời.

Có hai ứng dụng chính đọc (và, ở một mức độ nào đó, có thể kiểm soát) bộ đệm vòng của hạt nhân: dmesg(1)và klogd(8). Cái trước được dùng để chạy theo yêu cầu của người dùng, để in nội dung của bộ đệm vòng. Cái sau là một daemon đọc các tin nhắn từ /proc/kmsg(hoặc các cuộc gọi sys_syslog, nếu /prockhông được gắn kết) và gửi chúng đến syslogd(8), hoặc đến bàn điều khiển. Điều đó bao gồm phía hạt nhân.

Trong không gian người dùng, có syslogd(8). Đây là một trình nền nghe trên một số ổ cắm tên miền UNIX (chủ yếu /dev/log, nhưng những cái khác cũng có thể được cấu hình) và tùy chọn cổng UDP 514 cho các tin nhắn. Nó cũng nhận được tin nhắn từ klogd(8)( syslogd(8)không quan tâm /proc/kmsg). Sau đó, nó viết các thông báo này đến một số tệp trong /loghoặc gửi các ống có tên hoặc gửi chúng đến một số máy chủ từ xa (thông qua sysloggiao thức, trên cổng UDP 514), như được định cấu hình trong /etc/syslog.conf.

Các ứng dụng không gian người dùng thường sử dụng libcchức năng syslog(3)để ghi nhật ký tin nhắn. libcgửi các tin nhắn này đến ổ cắm tên miền UNIX /dev/log(nơi chúng được đọc bởi syslogd(8)), nhưng nếu một ứng dụng được xử lý, chroot(2)các tin nhắn có thể sẽ được ghi vào các ổ cắm khác, fi đến /var/named/dev/log. Tất nhiên, điều này là cần thiết cho các ứng dụng gửi các bản ghi này và syslogd(8)để thống nhất về vị trí của các ổ cắm này. Vì những lý do này syslogd(8)có thể được cấu hình để lắng nghe các ổ cắm bổ sung ngoài tiêu chuẩn /dev/log.

Cuối cùng, sysloggiao thức chỉ là một giao thức datagram. Không có gì ngăn ứng dụng gửi các datagram syslog đến bất kỳ ổ cắm tên miền UNIX nào (miễn là thông tin đăng nhập của nó cho phép nó mở ổ cắm), bỏ qua syslog(3)chức năng libchoàn toàn. Nếu các datagram được định dạng chính xác, syslogd(8)có thể sử dụng chúng như thể các tin nhắn được gửi qua syslog(3).

Tất nhiên, ở trên chỉ bao gồm lý thuyết khai thác "cổ điển". Các trình tiện ích khác (như rsyslog, và syslog-ngnhư bạn đã đề cập) có thể thay thế đồng bằng syslogd(8)và thực hiện tất cả các loại tiện lợi, như gửi tin nhắn đến máy chủ từ xa thông qua kết nối TCP được mã hóa, cung cấp dấu thời gian có độ phân giải cao, v.v. Và cũng có systemd, điều đó đang dần thực hiện phần UNIX của Linux. systemdcó cơ chế ghi nhật ký riêng, nhưng câu chuyện đó sẽ phải được kể bởi người khác. :)

Sự khác biệt với thế giới * BSD:

Trên * BSD không có klogd(8)và /prockhông tồn tại (trên OpenBSD) hoặc hầu hết đã lỗi thời (trên FreeBSD và NetBSD). syslogd(8)đọc các thông điệp kernel từ thiết bị ký tự /dev/klogvà dmesg(1)sử dụng /dev/kmemđể giải mã tên kernel. Chỉ OpenBSD có một /dev/log. FreeBSD sử dụng hai ổ cắm tên miền UNIX /var/run/logvà var/rub/logprivthay vào đó, và NetBSD có một /var/run/log.

Câu trả lời khác giải thích, như tác giả của nó nói, "ghi nhật ký cổ điển" trong Linux. Đó không phải là cách mọi thứ hoạt động trong rất nhiều hệ thống ngày nay.

Nhân

Các cơ chế hạt nhân đã thay đổi.

Nhân tạo đầu ra cho bộ đệm trong bộ nhớ. Phần mềm ứng dụng có thể truy cập điều này theo hai cách. Hệ thống con đăng nhập thường truy cập nó dưới dạng giả giả tên là FIFO /proc/kmsg. Nguồn thông tin nhật ký này không thể được chia sẻ một cách hữu ích giữa các trình đọc nhật ký, bởi vì nó được đọc một lần. Nếu nhiều tiến trình chia sẻ nó, mỗi tiến trình chỉ nhận được một phần của luồng dữ liệu nhật ký kernel. Nó cũng chỉ đọc.

Cách khác để truy cập nó là /dev/kmsgthiết bị nhân vật mới hơn . Đây là giao diện đọc-ghi có thể chia sẻ giữa nhiều tiến trình máy khách. Nếu nhiều quá trình chia sẻ nó, tất cả chúng đều đọc cùng một luồng dữ liệu, không bị ảnh hưởng bởi nhau. Nếu họ mở nó để truy cập ghi, họ cũng có thể đưa tin nhắn vào luồng nhật ký của kernel, như thể chúng được tạo bởi kernel.

/proc/kmsgvà /dev/kmsgcung cấp dữ liệu nhật ký ở dạng không phải RFC-5424.

Các ứng dụng

Các ứng dụng đã thay đổi.

syslog()Chức năng của thư viện GNU C trong các nỗ lực chính để kết nối với một AF_LOCALổ cắm datagram có tên /dev/logvà ghi các mục nhật ký vào nó. ( syslog()Ngày nay, chức năng của thư viện BSD C sử dụng /var/run/loglàm tên ổ cắm và thử /var/run/logprivtrước.) Các ứng dụng dĩ nhiên có thể có mã riêng để thực hiện việc này trực tiếp. Rốt cuộc, chức năng thư viện chỉ là mã (để mở, kết nối, ghi và đóng ổ cắm) thực thi trong bối cảnh quy trình riêng của ứng dụng.

Các ứng dụng cũng có thể gửi tin nhắn RFC 5424 qua UDP đến máy chủ RFC 5426 cục bộ, nếu một người đang nghe trên một ổ cắm AF_INET/ AF_INET6datagram trên máy.

Nhờ áp lực từ thế giới daemontools trong hai thập kỷ qua, rất nhiều hỗ trợ đã chạy trong chế độ mà họ không sử dụng syslog()chức năng thư viện GNU C hoặc ổ cắm UDP, nhưng chỉ đưa dữ liệu nhật ký của họ ra lỗi tiêu chuẩn trong thời trang Unix thông thường.

quản lý nhật ký với nosh và gia đình daemontools nói chung

Với bộ công cụ daemontools, có rất nhiều tính linh hoạt trong việc đăng nhập. Nhưng nói chung trên toàn bộ gia đình, ý tưởng là mỗi dmon "chính" có một "nhật ký" liên quan. Các công cụ "chính" hoạt động giống như các quy trình không phải và ghi thông điệp nhật ký của chúng vào lỗi tiêu chuẩn (hoặc đầu ra tiêu chuẩn) mà hệ thống con quản lý dịch vụ sắp xếp để kết nối qua một đường ống (nó giữ mở để dữ liệu nhật ký không bị mất khởi động lại dịch vụ) vào đầu vào tiêu chuẩn của "đăng nhập" dmon.

Tất cả các "nhật ký" chạy chương trình ghi nhật ký ở đâu đó . Nói chung, chương trình này là một cái gì đó giống như multiloghoặc cyclogđọc từ các tệp nhật ký đầu vào tiêu chuẩn của nó và ghi (ghi dấu thời gian nano giây) trong một thư mục có kích thước nghiêm ngặt, tự động xoay, ghi độc quyền ,. Nói chung, cũng vậy, tất cả các tài khoản này đều chạy dưới sự hỗ trợ của các tài khoản người dùng không dành riêng cho từng cá nhân.

Vì vậy, một kết thúc với một hệ thống ghi nhật ký phân tán phần lớn, với dữ liệu nhật ký của mỗi dịch vụ được xử lý riêng.

Một có thể chạy một cái gì đó giống như klogdhoặc syslogdhoặc rsyslogddưới một quản lý dịch vụ daemontools-gia đình. Nhưng thế giới daemontools nhận ra nhiều năm trước rằng cấu trúc quản lý dịch vụ với các "nhật ký" cho vay khá gọn gàng để thực hiện mọi việc theo cách đơn giản hơn. Không cần phải quạt tất cả các luồng nhật ký thành một mash-mash khổng lồ, phân tích dữ liệu nhật ký và sau đó quạt các luồng trở lại để tách các tệp nhật ký; và sau đó (trong một số trường hợp) bắt vít một cơ chế xoay vòng log bên ngoài không đáng tin cậy ở bên cạnh. Cấu trúc gia đình daemontools như là một phần của quản lý nhật ký tiêu chuẩn của nó đã thực hiện xoay vòng nhật ký, ghi logfile và phân tách luồng.

Hơn nữa: Mô hình tải chuỗi giảm đặc quyền với các công cụ phổ biến trên tất cả các dịch vụ có nghĩa là các chương trình ghi nhật ký không cần đặc quyền siêu người dùng; và mô hình UCSPI có nghĩa là họ chỉ cần quan tâm đến sự khác biệt, chẳng hạn như vận chuyển luồng so với datagram.

Bộ công cụ nosh minh họa điều này. Trong khi người ta có thể chạy rsyslogdtheo nó, ra khỏi hộp và chỉ cần quản lý kernel /run/logvà nhập nhật ký UDP theo cách cũ; nó cũng cung cấp nhiều cách ghi nhật ký "daemontools" hơn:

• một klogddịch vụ đọc từ /proc/kmsgvà chỉ đơn giản ghi luồng nhật ký đó vào lỗi tiêu chuẩn của nó. Điều này được thực hiện bởi một chương trình đơn giản có tên klog-read. Việc ghi nhật ký được liên kết cung cấp luồng nhật ký trên đầu vào tiêu chuẩn của nó vào một /var/log/sv/klogdthư mục nhật ký.
• một local-syslog-readdịch vụ đọc các datagram từ /dev/log( /run/logtrên BSD) và chỉ cần ghi luồng nhật ký đó vào lỗi tiêu chuẩn của nó. Điều này được thực hiện bởi một chương trình có tên syslog-read. Việc ghi nhật ký được liên kết cung cấp luồng nhật ký trên đầu vào tiêu chuẩn của nó vào một /var/log/sv/local-syslog-readthư mục nhật ký.
• một udp-syslog-readdịch vụ lắng nghe trên cổng syslog UDP, đọc những gì nó được gửi đến nó và chỉ cần ghi luồng nhật ký đó vào lỗi tiêu chuẩn của nó. Một lần nữa, chương trình là syslog-read. Việc ghi nhật ký được liên kết cung cấp luồng nhật ký trên đầu vào tiêu chuẩn của nó vào một /var/log/sv/udp-syslog-readthư mục nhật ký.
• (trên BSD) một local-priv-syslog-readdịch vụ đọc các datagram từ đó /run/logprivvà chỉ cần ghi luồng nhật ký đó vào lỗi tiêu chuẩn của nó. Một lần nữa, chương trình là syslog-read. Việc ghi nhật ký được liên kết cung cấp luồng nhật ký trên đầu vào tiêu chuẩn của nó vào một /var/log/sv/local-priv-syslog-readthư mục nhật ký.

Bộ công cụ cũng đi kèm với một export-to-rsyslogcông cụ có thể giám sát một hoặc một số thư mục nhật ký (sử dụng hệ thống các con trỏ nhật ký không xâm nhập ) và gửi các mục mới trong biểu mẫu RFC 5424 qua mạng đến máy chủ RFC 5426 được chỉ định.

quản lý nhật ký với systemd

systemd có một chương trình quản lý nhật ký nguyên khối duy nhất , systemd-journald. Điều này chạy như một dịch vụ được quản lý bởi systemd.

• Nó đọc /dev/kmsgdữ liệu nhật ký kernel.
• Nó đọc /dev/log(một liên kết tượng trưng đến /run/systemd/journal/dev-log) cho dữ liệu nhật ký ứng dụng từ syslog()chức năng của thư viện GNU C.
• Nó lắng nghe trên AF_LOCALổ cắm luồng /run/systemd/journal/stdoutcho dữ liệu nhật ký đến từ các dịch vụ do hệ thống quản lý.
• Nó lắng nghe trên AF_LOCALổ cắm datagram tại /run/systemd/journal/socketdữ liệu nhật ký đến từ các chương trình nói giao thức tạp chí dành riêng cho hệ thống (ví dụ sd_journal_sendv()và các cộng sự).
• Nó trộn tất cả những thứ này lại với nhau.
• Nó ghi vào một tập hợp các tệp nhật ký trên toàn hệ thống và theo người dùng, trong /run/log/journal/hoặc /var/log/journal/.
• Nếu nó có thể kết nối (như một máy khách) với một AF_LOCALổ cắm datagram tại /run/systemd/journal/syslognó ghi dữ liệu nhật ký ở đó, nếu chuyển tiếp tới syslog được cấu hình.
• Nếu được cấu hình, nó ghi dữ liệu nhật ký vào bộ đệm kernel bằng /dev/kmsgcơ chế có thể ghi .
• Nếu được cấu hình, nó cũng ghi dữ liệu nhật ký vào thiết bị đầu cuối và thiết bị điều khiển.

Những điều tồi tệ xảy ra trên toàn hệ thống nếu chương trình này gặp sự cố hoặc dịch vụ bị dừng.

Bản thân systemd sắp xếp các đầu ra tiêu chuẩn và lỗi của (một số) dịch vụ được gắn vào /run/systemd/journal/stdoutổ cắm. Vì vậy, các bản ghi nhật ký lỗi tiêu chuẩn theo kiểu thông thường sẽ được gửi đến tạp chí.

Điều này hoàn toàn thay thế klogd, syslogd, syslog-ng và rsyslogd.

Đây là những yêu cầu phải được cụ thể hệ thống. Trên hệ thống systemd, họ không nhận được kết thúc máy chủ /dev/log. Thay vào đó, họ thực hiện một trong hai cách tiếp cận:

• Chúng trở thành đầu cuối của máy chủ /run/systemd/journal/syslog, mà (nếu bạn nhớ) systemd-journaldcố gắng kết nối và ghi dữ liệu nhật ký. Một vài năm trước, người ta sẽ cấu hình imuxsockphương thức nhập liệu của rsyslogd để làm điều này.
• Họ đọc trực tiếp từ tạp chí systemd, sử dụng thư viện dành riêng cho systemd, hiểu định dạng tạp chí nhị phân và có thể theo dõi các tệp nhật ký và thư mục cho các mục mới được thêm vào. Ngày nay, một cấu hình imjournalphương thức nhập của rsyslogd để làm điều này.