さまざまなシステム情報を表示するプログラムを作成しています（CentOSシステム上）。たとえば、プロセッサのタイプと速度（から/proc/cpuinfo）、最後のブート時間（から計算/proc/uptime）、IPアドレス（ifconfig出力から）、インストールされているプリンターのリスト（lpstat出力から）。
現在、dmidecodeプログラムからいくつかのデータが取得されています。
dmidecode -s system-product-name）dmidecode -s bios-version）dmidecode -t17 | grep Size）これらは、プログラムがルートとして実行されている場合にのみ使用可能です（そうでない場合、dmidecodeサブプロセスは/dev/mem: Permission deniedエラーで失敗します）。通常のユーザーがアクセスできる、この情報を取得する別の方法はありますか？
回答:
私は、ユーザーとしてDMI情報を読み取ることができます/sys/class/dmi/id/。シリアル番号は含まれません（読み取りにはルート権限が必要です）。
これは、プライバシーを意識したカーネル開発者が意図した動作だと思います。
dmesg：に関してdmesgは、カーネルリングバッファにアクセスするためのコマンドです。リングバッファは、バッファが「オーバーフロー」しているときに、古い情報が新しい情報によって上書きされることを意味します。また、これはカーネルモジュールのデバッグ出力を読み取っていますが、これは解析可能なものではありませんでした。
systemdrunでカーネル出力にアクセスするには：
journalctl --quiet --system --boot SYSLOG_IDENTIFIER=kernel
デビッド・ホーマーのとNILS'答え：ファイルは/dev/mem、単純にメモリ情報を与えるものではありませんが、ユーザー空間に全体の物理メモリをマッピングします。したがって、それを介してDMIメモリアドレスにアクセスできます（さらに多くの厄介なことを行います）。
chgrpとchmod g+sのdmidecodeでNILS'答え：意図したとおりにGIDを保存するので、私は、これではないでしょう仕事を推測するchmod g+sことはありませんdmidecode、それは新しい特権だ利用を。dmidecodeにsetegidアクセスする前に、有効なグループIDを設定するために呼び出す必要があります/dev/mem。そのソースコードから判断すると、それdmidecodeはしません。
systemd読み取りのみを行わずに、システム上のカーネル出力にアクセスします/var/log/kern.log。システムがまだ使用している間にそのようなファイルがない場合syslogd、kern.*エントリ/etc/syslog.confを探してその場所を見つけてみてください。
DMIDecodeを使用して、リモートLinuxシステムから情報を読み取りますが、これに対する回避策はまだ見つかりません。私はこれについて尋ねるdmidecodeホームページで呼び出しを記録しました...
コマンドdmidecode -t systemを使用すると、「/ dev / mem：Permission denied」というエラーが表示されます。これは、メモリ情報（製造元、モデル、シリアル番号のみ）が不要なため問題です。
SunOSで実行されているsmbiosコマンドは、root権限を必要とせずにこの情報に対して正常に機能することに気付きました。
今のところ、「最低限必要な特権を持つ特定のアカウントを使用する」というドキュメントを「ユーザールート認証情報」に置き換えます。
lshal 同じ情報が多く含まれており、ルート権限は必要ありません。
lshal | grep system.productとシステム名のために、さらにはDellのサービスタグをlshal | grep smbios.system.serial
lshal最終的にRHEL7で完全に消滅sudo cat /sys/devices/virtual/dmi/id/chassis_serialし、Dellサービスタグを取得するために使用していますが、これはcatsudoers を介してアクセスできる場合にのみ機能します。
@mtneagleが投票された理由は定かではありません。
OPが望んだ3つのアイテムは次のとおりです。
プラットフォームの種類（dmidecode -s system-product-name）
BIOSバージョン（dmidecode -s bios-version）
物理メモリの量（dmidecode -t17 | grep Size）
これらのそれぞれをこのようにして取得できます。
dmesg | grep "DMI:" | cut -c "6-" | cut -d "," -f "1"
dmesg | grep "DMI:" | cut -c "6-" | cut -d "," -f "2"
dmesg | grep "Memory:" | cut -d '/' -f '2-' | cut -d ' ' -f '1'
（または少なくとも、私が持っている4つの異なるハードウェアサーバーで動作し、XenゲストのBIOSまたはサーバータイプについては何も返されません。）
明らかな何かを見逃していませんか？
更新：見逃したことを指摘してくれた@Ruslanに感謝します。
引用：
はいあなたが持っています。カーネルメッセージはリングバッファに保存されます。印刷された行が多すぎると、最初の行が削除されます。
そのため、マシンが数週間稼働しており、少なくとも毎日それを中断/再開した場合、ここでgrepを実行した情報がバッファーに存在しなくなる可能性が高くなります。
（私はここで18日間の稼働時間でこのような状況にあります。）
/var/log/kern.log何かのようなもの
grep DMI: /var/log/kern.log | tail -n1
grep、ここでの情報がバッファになくなる可能性が高くなります。（ここで18日の稼働時間でこのような状況にあります。）を調べる方が良いかもしれません/var/log/kern.log。のようなものgrep DMI: /var/log/kern.log | tail -n1。
物理メモリの総量を取得するには、解析することができ/proc/meminfo、free、vmstatそれは0時間でそれを語ることから、などまた、カーネルメッセージバッファを解析することができます。
BIOSバージョンはもっと難しく、これが非rootユーザーとして可能だとは思わないが、間違っているかもしれない。/sys/または（またはシステム製品名）がどこかで公開されている可能性があります（おそらくまたは/proc/）ですが、何も見つかりません。
dmesg、ログがいっぱいになっていないかどうかを調べてください。例の行：[ 0.000000] DMI: CLEVO CO. B7130 /B7130 , BIOS 6.00 08/27/2010
cat /sys/devices/virtual/dmi/id/bios_version...ボイラ！しかし、YMMV。すべてのアーキテクチャにこのパスがあるわけではありません。x86_64 Intelが必要です。
/sys/devices/virtual/dmi/id。プラットフォーム固有の情報がたくさんあります。便利なスクリプトについては、unix.stackexchange.com / questions / 75750 /…を参照してください。システム情報については、他の文も適切です。ユーティリティのようなたくさんのがありますfreeかさえもhtop何をしたいあなたを得ることができます。