CentOS8では、搭載されたセッション記録ツールを使えば、ユーザが利用する端末の入出力情報は、すべて収集可能である。
また、CockpitのWeb管理画面を使えば、記録されたセッションデータを簡単に管理できる。
tlog-rec -o ファイル名で録画を開始でき、exitコマンドで抜けたタイミングで終了できる。
tlog-play -i ファイル名で録画した内容を再生ができる。
なお、P196のコラムにある様に、監査目的に残したいというのは古くからscriptコマンドにて実現ができている。
CentOS8では、sosreportコマンドを使う事で、システム全体のログと設定ファイルを簡単に一括取得できる。
インストールされていない場合は、sosパッケージというのをインストールする事で利用できる。
[実行方法]
sosreport --all-logs --batch
--all-logs：すべてのログを取得
--batch：非対話形式のバッチ処理で動作
journalctl -b
journalctl --since="2020-03-01 01:23:45" --until="2020-03-31 23:59:59"
journalctl --since=today
なお、yesterdayやtomorrowも指定可能
journalctl -u sshd.service
journalctl -f
journalctl -pwarning
[プライオリティ一覧]
| ログレベル | 略記法 |
|---|---|
| emerg | -p0 |
| alert | -p1 |
| crit | -p2 |
| err | -p3 |
| warning | -p4 |
| notice | -p5 |
| info | -p6 |
| debug | -p7 |
[テストログの生成]
logger -p daemon.alert "test hogehoge"
journalctl -k
journalctl _PID=1234
journalctl /usr/sbin/crond
・ログの保存方法
CentOS8では、デフォルトは揮発する設定になっている。
そのため、/etc/systemd/journald.confのStorage=persistentをコメントアウトしている箇所を活性化させ、journaldを再起動すればログが保存される様になる。
なお、その場合は/var/log/journalディレクトリ配下に生成される様になる。
| モード | init.d | systemd |
|---|---|---|
| システム停止 | 0 | systemctl isolate poweroff.target |
| シングルユーザモード | 1 | systemctl isolate rescue.target |
| マルチユーザモード | 3 | systemctl isolate multi-user.target |
| グラフィカルログイン | 5 | systemctl isolate graphical.target |
| OSの再起動 | 6 | systemctl isolate reboot.target |
| 緊急モード | - | systemctl isolate emergency.target |
・シングルユーザモードと緊急モードの違い
シングルユーザモードではネットワークが使えないが、緊急モードでは利用可能
・各モードがターゲット切替可能かどうかの確認方法
cd /usr/lib/systemd/system grep AllowIsolate 対象のターゲット
AllowIsolate=yes or noで表示される
CentOS8における主なリポジトリは、BaseOSとAppStreamです。
[BaseOS]
・従来のCentOS7までのベースリポジトリに相当する。
・従来通りCentOSのバージョン単位にrpmが用意されており、管理する必要がある。
[AppStream]
・従来のCentOSにおけるSoftware Collectionsリポジトリ、Extrasリポジトリで提供していたアプリケーションなどが含まれる。
・ストリームという呼称で新たに定義されている。これは、(開発元の提供形式に依存はするが)複数のOSバージョンに跨れ、またalternativesコマンドみたいな複数バージョンの切替が可能になる。
画面が何も見えない状態でありつつも、過去2度ほどグラボが駄目になったことある経験から、今回は確実にグラボが逝ってしまったと判断した。そのため、以前よりGoogleリモートデスクトップで別マシンから接続できる状態にしていたので、そちらからリモート接続をしたところ無事接続が行えた。そして、デバイスマネージャーで確認したところ、ディスプレイアダプタのとこがビックリマーク&上記に記載したメッセージが発生していた。この時点では、グラボ自体は認識している状態を確認できていた。筐体自体の中を開けたところ、グラボのファン自体も正常に動作していたことから、物理障害ではなく論理障害が発生しているという線で調査を進めることにした。
2020年3月版WIndows Updateの調子が悪いニュースは耳にはしていたが、こちらの影響の可能性はあるかなと思い、怖いながらもWindowsUpdateを実施したが何も変わらなかった。
PCI Expressの認識が正しく行えていないという路線と考えていたので、以下の記事を参考に実施を行った。当ブログの記載されているとおり、WIndows7ではこの方法で良かったが、Windows10では公式なやりかたではないためか、このコマンドを投入して再起動を行うとグラボ自体も認識しなくなり、オンボード側のディスプレイアダプタが表示されるようになってしまった。。なお、ForceDisabled→Defaultにパラメータを元に戻したが認識されることはなかった。そのため、試す際には覚悟をもって(バックアップなどを取得してから)コマンドを投入する必要がある。
4CoreDual-VSTAでWindows 10：でっかいひとりごと：SSブログ
同じくWIndows7などで使われていた手法でレジストリの値を書き換える対応というのが存在したが、何も変化は発生しなかった。
https://support.microsoft.com/ja-jp/help/942959/error-message-when-you-attach-a-pci-express-expansion-chassis-to-a-com
もしかしたらこれをやればすぐ解決したのかもしれないが、Windows側でそもそもこのカードが刺さっている事自体を認識していなかったので、PCI Expressの差し込み部分が問題あると考え、対応を行わなかった。
購入してからそもそもどこのマザーボードからも把握していなかったので、以下のコマンドでマザーボードの型番を確認した。私の場合は、dxdiagでは確認は行えず、systeminfoでASUSのH110I-PLUSが使われている事が分かった。その後、BIOS Updateを実施したが、結果何も変化は無かった。なお、このタイミングより、Chromeリモートデスクトップ接続からオンボード表示(VGA)に切り替えた。
自分のPCのマザーボードの型番を確認する方法6選！ | Aprico
確認を行った後にBIOS UpdateによってPCI Express関連の設定初期値が変わっている、設定項目が増えている可能性があると考え、以下サイトを参考に色々PCI Express周りの設定値を変えながら再起動を繰り返した。しかし、特に有用な設定は存在しなかった。但し、画像ディスプレイを優先的にPCI Expressを設定する値を設定しても、次確認するとAutoになっていた。ただ、これはPCI Expressが刺さっていないと誤認識されているため、自動で設定をAutoに戻されたのかと解釈した。
ASUSマザーのAdvanced Modeを徹底解説 ～Advancedメニュー詳細編～ - AKIBA PC Hotline!
この設定作業を行う前にキーボードの入力を受け付けなくてBIOSもといUEFI画面に入れないという事象に見舞われたが、通常Bluetooth版ThinkPadキーボードを使っていた事にはたと気がついた。進んでいるUEFIであればBluetooth接続を認識するかもしれないが、昔のBIOSであればPS/2しか認識しなかったし、現代においても有線USBでないと認識は行われない可能性が高い。当方は、有線版ThinkPadキーボードも保持しているので、そちらに切り替える事で設定を行えた。
上記対応行っても一向に変化ないため、同じ構成で動いていた実績はあるので、壊れてない限りは物理レベルでは問題ない構成と考え、一度マシンから切り離して新しく付けた形で認識させるという方法にチャレンジしてみた。
結果は最初に記載通り、何事もなくうまく認識を行ってくれた。正直UEFI/Windows側でどの様にこの行為が解釈されたのか分からないが、特に新たなドライバを求められることもなく認識を行ってくれた。
マザーボードとグラボの関係が一番関連しそう。
CPUは内部GPUの設定に影響与える場合もあるので参考程度に記載を行った。
Windowsの部分は、Windows10である事、Homeである事を示すために記載を行った。
【事象】
ゲストOSからyumを実行しようとしても、yumが止まった状態になってしまい、アップデートが行われない。
なお、ホストOSからゲストOSに対して、SSHやゲストOS内に環境構築しているWebサーバーには問題なくアクセスできる。
(NATのポートフォワードの設定は正しく行えている)
【原因】
プロキシの設定が正しくなかった。
【環境】
ホストOS：Windows10
仮想環境：VirtualBox6
ゲストOS：CentOS7
ゲストOSのネットワークアダプター：NAT
その他：HTTPなど通信する際にプロキシが存在(会社)
【対応方法(の一例)】
１．VirtualBox自体のプロキシの設定変更
[ファイル] - [環境設定] より、"プロキシー"カテゴリを選択し、インターネットに直接接続を設定する。
２．ゲストOS内部のプロキシ設定
(CentOSで一時的に通信を行う場合)
以下を実行し、環境変数を宣言すれば通信を行える。
export HTTP_PROXY=http://<プロキシのユーザー名>:<プロキシのパスワード>@<プロキシのサーバー名>:<プロキシのポート番号>/ export HTTPS_PROXY=https://<プロキシのユーザー名>:<プロキシのパスワード>@<プロキシのサーバー名>:<プロキシのポート番号>/
【その他】
・VirtualBox6の環境であれば、ゲストOS→インターネット、ホストOS→ゲストOSの通信を実現したいのであれば、ネットワークアダプタはNATのみで問題ない。
・環境によっては、Windowsファイアーウォールや、ウイルスソフトに通信が止められている可能性があるので確認する必要がある。
【参考リンク】
社内Proxyに阻まれていろいろ捗らない人のためのTips - Qiita
CentOS 7で作るネットワークサーバ構築ガイド 1804対応 第2版 (Network Server Construction Guide S)
![DOS/V POWER REPORT (ドスブイパワーレポート) 2020年春号[雑誌]](https://m.media-amazon.com/images/I/51TCf2sTNQL._SL500_.jpg "DOS/V POWER REPORT (ドスブイパワーレポート) 2020年春号[雑誌]")
