Memahami login di Linux

Seperti yang saya mengerti, kernel Linux log ke /proc/kmsgfile (kebanyakan pesan yang berhubungan dengan perangkat keras) dan /dev/logsocket? Di tempat lain? Apakah aplikasi lain juga dapat mengirim pesan ke /proc/kmsgatau /dev/log? Last but not least, apakah saya benar bahwa itu adalah daemon syslog ( rsyslog , syslog-ng ) yang memeriksa pesan dari dua tempat dan kemudian mendistribusikannya ke berbagai file seperti /var/log/messagesatau /var/log/kern.logatau bahkan server syslog pusat?

— Martin
sumber

Jawaban:

Sederhana, ini kurang lebih seperti ini:

Kernel mencatat pesan (menggunakan printk()fungsi) ke buffer cincin di ruang kernel. Pesan-pesan ini tersedia untuk aplikasi ruang pengguna dalam dua cara: melalui /proc/kmsgfile (asalkan /procsudah terpasang), dan melalui sys_syslogsyscall.

Ada dua aplikasi utama yang membaca (dan, sampai batas tertentu, dapat mengontrol) buffer cincin kernel: dmesg(1)dan klogd(8). Yang pertama dimaksudkan untuk dijalankan atas permintaan oleh pengguna, untuk mencetak isi buffer cincin. Yang terakhir adalah daemon yang membaca pesan dari /proc/kmsg(atau panggilan sys_syslog, jika /proctidak dipasang) dan mengirimkannya ke syslogd(8), atau ke konsol. Itu mencakup sisi kernel.

Di ruang pengguna, ada syslogd(8). Ini adalah daemon yang mendengarkan pada sejumlah soket domain UNIX (terutama /dev/log, tetapi yang lain dapat dikonfigurasi juga), dan secara opsional ke port UDP 514 untuk pesan. Itu juga menerima pesan dari klogd(8)( syslogd(8)tidak peduli /proc/kmsg). Ini kemudian menulis pesan-pesan ini ke beberapa file di /log, atau ke pipa bernama, atau mengirimkannya ke beberapa host jarak jauh (melalui syslogprotokol, pada port UDP 514), sebagaimana dikonfigurasi dalam /etc/syslog.conf.

Aplikasi ruang pengguna biasanya menggunakan libcfungsi ini syslog(3)untuk mencatat pesan. libcmengirim pesan-pesan ini ke soket domain UNIX /dev/log(di mana mereka dibaca oleh syslogd(8)), tetapi jika aplikasi chroot(2)-ed pesan mungkin berakhir ditulis ke soket lain, fi ke /var/named/dev/log. Tentu saja, ini penting untuk aplikasi yang mengirimkan log ini dan syslogd(8)untuk menyetujui lokasi soket ini. Untuk alasan ini syslogd(8)dapat dikonfigurasi untuk mendengarkan soket tambahan selain dari standar /dev/log.

Akhirnya, syslogprotokol hanyalah protokol datagram. Tidak ada yang menghentikan aplikasi dari mengirim datagram syslog ke soket domain UNIX (asalkan kredensial memungkinkannya untuk membuka soket), melewati syslog(3)fungsi libcsepenuhnya. Jika datagram diformat dengan benar syslogd(8)dapat menggunakannya seolah-olah pesan telah dikirim syslog(3).

Tentu saja, di atas hanya mencakup teori logging "klasik". Daemon lain (seperti rsyslogdan syslog-ng, seperti yang Anda sebutkan) dapat menggantikan dataran syslogd(8), dan melakukan segala macam hal bagus, seperti mengirim pesan ke host jarak jauh melalui koneksi TCP terenkripsi, memberikan stempel waktu resolusi tinggi, dan sebagainya. Dan ada juga systemd, yang secara perlahan memfagositosis bagian UNIX Linux. systemdmemiliki mekanisme penebangannya sendiri, tetapi cerita itu harus diceritakan oleh orang lain. :)

Perbedaan dengan dunia * BSD:

Pada * BSD tidak ada klogd(8), dan /proctidak ada (pada OpenBSD) atau sebagian besar sudah usang (pada FreeBSD dan NetBSD). syslogd(8)membaca pesan kernel dari perangkat karakter /dev/klog, dan dmesg(1)digunakan /dev/kmemuntuk mendekode nama kernel. Hanya OpenBSD yang memiliki /dev/log. FreeBSD menggunakan dua soket domain UNIX /var/run/logdan var/rub/logprivsebagai gantinya, dan NetBSD memiliki a /var/run/log.

— lcd047
sumber

nit: rsyslog lebih populer sekarang (default untuk Fedora, Debian), dan tidak menggunakan klogd terpisah. Sepertinya syslog-ng juga tidak (menurut preferensi).

— sourcejedi

@sourcejedi Saya belum mengikuti Linux dengan saksama dalam lebih dari beberapa tahun sekarang, tetapi IIRC rsyslogtidak digunakan klogd(8)karena akarnya kembali, bukan karena baru-baru ini membuat keputusan eksplisit untuk menghapusnya. Ingatan saya bisa gagal. Lagi pula, seperti yang saya katakan, saya hanya mencoba untuk menutupi penebangan "klasik".

— lcd047

@ lcd047, @sourcejedi, Terima kasih atas balasan! Saya punya satu sistem Debian 7 dengan rsyslogdmenjalankan dan satu Ubuntu 12,04 dengan syslog-ngmenjalankan dan mereka berdua memiliki file /proc/kmsgterbuka sesuai lsof, yaitu klogdtidak digunakan. Hal lain yang menarik yang saya perhatikan adalah bahwa pesan log disimpan dalam /proc/kmsgfile jika tidak ada daemon syslog yang berjalan dan orang dapat melihatnya dengan contoh catatau editor teks. Namun, itu hanya mungkin untuk melihat pesan-pesan itu sekali saja karena mereka menghilang setelah melihatnya. Last but not least, mengeksekusi dmesgtidak menghapus konten /proc/kmsgfile.

— Martin

@ Martin /proc/kmsgbukan file biasa, tidak ada yang "disimpan" di sana, melainkan hanya tampilan buffer cincin kernel. Anda dapat membacanya dengan cattepat karena Anda tidak memiliki klogd(8)menjalankan (harus Anda jalankan klogd(8), cat /proc/kmsgakan memblokir). dmesg(1)membaca pesan dari /dev/kmsgdaripada /proc/kmsg; dan itu juga dapat menghapus buffer jika Anda menyuruhnya.

— lcd047

systemd has its own logging mechanisms, but that story would have to be told by somebody else. :)- Tolong katakan, Anda punya bakat :-)

— Flavius

Jawaban lainnya menjelaskan, seperti yang dikatakan penulisnya, "logging klasik" di Linux. Itu bukan cara kerja banyak sistem saat ini.

Kernel

Mekanisme kernel telah berubah.

Kernel menghasilkan output ke buffer dalam memori. Perangkat lunak aplikasi dapat mengakses ini dengan dua cara. Subsistem logging biasanya mengaksesnya dengan nama pseudo-FIFO /proc/kmsg. Sumber informasi log ini tidak dapat dibagi secara bermanfaat di antara pembaca log, karena ini dibaca sekali. Jika beberapa proses membagikannya, mereka masing-masing hanya mendapatkan sebagian dari aliran data log kernel. Ini juga hanya baca.

Cara lain untuk mengaksesnya adalah /dev/kmsgperangkat karakter yang lebih baru . Ini adalah antarmuka baca-tulis yang dapat dibagikan di antara beberapa proses klien. Jika beberapa proses berbagi, mereka semua membaca aliran data lengkap yang sama, tidak terpengaruh satu sama lain. Jika mereka membukanya untuk akses tulis, mereka juga dapat menyuntikkan pesan ke aliran log kernel, seolah-olah dihasilkan oleh kernel.

/proc/kmsgdan /dev/kmsgmenyediakan data log dalam bentuk non-RFC-5424.

Aplikasi

Aplikasi telah berubah.

Fungsi pustaka GNU C syslog()dalam upaya utama untuk terhubung ke AF_LOCALsoket datagram bernama /dev/logdan menulis entri log untuk itu. (Fungsi pustaka BSD C syslog()saat ini menggunakan /var/run/logsebagai nama soket, dan mencoba /var/run/logprivterlebih dahulu.) Aplikasi tentu saja dapat memiliki kode sendiri untuk melakukan ini secara langsung. Fungsi perpustakaan hanyalah kode (untuk membuka, menghubungkan, menulis, dan menutup soket) yang mengeksekusi dalam konteks proses aplikasi sendiri, setelah semua.

Aplikasi juga dapat mengirim pesan RFC 5424 melalui UDP ke server RFC 5426 lokal, jika seseorang mendengarkan pada soket AF_INET/ AF_INET6datagram pada mesin.

Berkat tekanan dari dunia daemontools selama dua dekade terakhir, banyak dukungan demon berjalan dalam mode di mana mereka tidak menggunakan syslog()fungsi pustaka GNU C, atau soket UDP, tetapi hanya memuntahkan data log mereka ke kesalahan standar di mode Unix biasa.

manajemen log dengan nosh dan keluarga daemontools secara umum

Dengan rangkaian alat keluarga daemontools, ada banyak fleksibilitas dalam pencatatan. Tetapi secara umum di seluruh keluarga idenya adalah bahwa setiap demon "utama" memiliki dikaitkan "logging" demon. "main" demon bekerja seperti halnya proses non-demon dan menulis pesan log mereka ke kesalahan standar (atau output standar), yang diatur oleh subsistem manajemen layanan untuk terhubung melalui pipa (yang dipegang terbuka agar data log tidak hilang lebih dari restart layanan) ke input standar dari "logging" dasmon.

Semua dasmon "logging" menjalankan program yang mencatat suatu tempat . Secara umum program ini adalah sesuatu seperti multilogatau cyclogyang membaca dari input standar dan menulis (catatan waktu nanosecond) file log dalam direktori ukuran-capped, otomatis diputar, eksklusif-menulis, eksklusif. Secara umum, semua demon ini berjalan di bawah naungan akun pengguna khusus yang tidak memiliki hak pribadi.

Jadi seseorang berakhir dengan sistem logging yang sebagian besar didistribusikan, dengan data log masing-masing layanan diproses secara terpisah.

Seseorang dapat menjalankan sesuatu seperti klogdatau syslogdatau di rsyslogdbawah manajemen layanan keluarga-daemontools. Tetapi dunia daemontools menyadari bertahun-tahun yang lalu bahwa struktur manajemen layanan dengan "logging" dasmon cocok untuk melakukan berbagai hal dengan cara yang lebih sederhana. Tidak perlu mengipasi semua stream log menjadi satu mash mash-mash, mengurai data log, dan kemudian mengipasi stream kembali ke file log yang terpisah; dan kemudian (dalam beberapa kasus) membaut mekanisme rotasi log eksternal yang tidak dapat diandalkan di samping. Struktur daemontools-family sebagai bagian dari manajemen log standarnya sudah melakukan rotasi log, penulisan logfile, dan pemisahan aliran.

Selanjutnya: Model pemuatan rantai untuk menjatuhkan hak istimewa dengan alat-alat yang umum di semua layanan berarti bahwa program logging tidak memerlukan hak pengguna super; dan model UCSPI berarti mereka hanya perlu peduli tentang perbedaan seperti transport stream versus datagram.

Toolset nosh mencontohkan ini. Sementara seseorang dapat berjalan rsyslogddi bawahnya, di luar kotak, dan hanya mengelola kernel /run/log,, dan input log UDP dengan cara lama; ini juga menyediakan lebih banyak cara "daemontools asli" untuk mencatat hal-hal ini:

sebuah klogdlayanan yang membaca dari /proc/kmsgdan hanya menulis bahwa aliran log kesalahan standar. Ini dilakukan oleh sebuah program sederhana bernama klog-read. Log logging terkait memberi aliran log pada input standarnya ke /var/log/sv/klogddirektori log.
sebuah local-syslog-readlayanan yang bertuliskan datagram dari /dev/log( /run/logdi BSD) dan hanya menulis bahwa aliran log kesalahan standar. Ini dilakukan oleh sebuah program bernama syslog-read. Log logging terkait memberi aliran log pada input standarnya ke /var/log/sv/local-syslog-readdirektori log.
sebuah udp-syslog-readlayanan yang mendengarkan pada port syslog UDP, membaca apa yang dikirimkan kepadanya dan hanya menulis aliran log itu ke kesalahan standarnya. Sekali lagi, programnya adalah syslog-read. Log logging terkait memberi aliran log pada input standarnya ke /var/log/sv/udp-syslog-readdirektori log.
(pada BSD) local-priv-syslog-readlayanan yang membaca datagrams dari /run/logprivdan hanya menulis aliran log itu ke kesalahan standarnya. Sekali lagi, programnya adalah syslog-read. Log logging terkait memberi aliran log pada input standarnya ke /var/log/sv/local-priv-syslog-readdirektori log.

Toolset ini juga dilengkapi dengan export-to-rsyslogalat yang dapat memantau satu atau beberapa direktori log (menggunakan sistem kursor log yang tidak mengganggu ) dan mengirim entri baru dalam formulir RFC 5424 melalui jaringan ke server RFC 5426 yang ditunjuk.

manajemen log dengan systemd

systemd memiliki program manajemen log monolitik tunggal systemd-journald,. Ini berjalan sebagai layanan yang dikelola oleh systemd.

Bunyinya /dev/kmsguntuk data log kernel.
Bunyinya /dev/log(tautan simbolik ke /run/systemd/journal/dev-log) untuk data log aplikasi dari syslog()fungsi pustaka GNU C.
Ia mendengarkan pada AF_LOCALsoket aliran di /run/systemd/journal/stdoutuntuk data log yang datang dari layanan yang dikelola sistem.
Ia mendengarkan pada AF_LOCALsoket datagram di /run/systemd/journal/socketuntuk data log yang berasal dari program yang berbicara protokol jurnal khusus sistem (yaitu sd_journal_sendv()et al.).
Ini mencampur semuanya.
Itu menulis ke satu set file jurnal seluruh sistem dan per-pengguna, di /run/log/journal/atau /var/log/journal/.
Jika itu dapat terhubung (sebagai klien) ke AF_LOCALsoket datagram di /run/systemd/journal/syslogsitu menulis data jurnal di sana, jika penerusan ke syslog dikonfigurasi.
Jika dikonfigurasi, ia menulis data jurnal ke buffer kernel menggunakan /dev/kmsgmekanisme yang bisa ditulis .
Jika dikonfigurasi, ia juga menulis data jurnal ke terminal dan perangkat konsol.

Hal-hal buruk terjadi di seluruh sistem jika program ini macet, atau layanan dihentikan.

systemd sendiri mengatur output standar dan kesalahan (beberapa) layanan yang harus dipasang ke /run/systemd/journal/stdoutsoket. Jadi demon yang masuk ke standard error dalam mode normal memiliki output mereka dikirim ke jurnal.

Ini sepenuhnya menggantikan klogd, syslogd, syslog-ng, dan rsyslogd.

Ini sekarang harus spesifik sistemd. Pada sistem systemd mereka tidak bisa menjadi server akhir /dev/log. Sebagai gantinya, mereka mengambil satu dari dua pendekatan:

Mereka bisa menjadi ujung server /run/systemd/journal/syslog, yang (jika Anda ingat) systemd-journaldmencoba untuk terhubung dan menulis data jurnal. Beberapa tahun yang lalu, seseorang akan mengkonfigurasi imuxsockmetode input rsyslogd untuk melakukan ini.
Mereka membaca langsung dari jurnal systemd, menggunakan perpustakaan systemd-spesifik yang memahami format jurnal biner dan yang dapat memonitor file jurnal dan direktori untuk entri baru yang ditambahkan. Saat ini, seseorang mengkonfigurasi imjournalmetode input rsyslogd untuk melakukan ini.

— JdeBP
sumber