カテゴリー: OS

投稿日:

SteamDeck疑似環境の構築方法

(2022/08/04追記:一番後ろに、SteamDeck用LinuxのSteam OSとそれを他機種でも使えるように細工したものの紹介を追加)

Steam Deckという手持ちゲーミング端末がリリースされる予定になっている。

現状は一部の開発者向けに実機の提供が行われているが、それ以外のPCでもSteam Deckで使われるManjaro Linux OSをインストールすることで検証ができるように公式の手順が公開されていた。

「Developing for Steam Deck without a Dev-Kit」

書いてある内容を要約すると・・・

ハードウェア構成

本体:MINISFORUM Elite Mini UM700 (日本代理店 Linksの製品紹介)の Ryzen 7 3750H 搭載モデル

AmazonのMINIFORUM直販より、日本代理店Links直販が安い場合も・・・


ディスプレイ:7インチで1280*800のカーナビ液晶を流用しているものを適当に調達

コントローラ: PS4コントローラかPS5コントローラが最適。XBOXやスイッチ用も使えなくは無いが、トラックパッドがないためフル機能が使えないことに注意。

以前売ってたSteam純正コントローラについては触れられてない・・・

OS設定について

Manjaro LinuxのKDE Plasmaエディションをインストールする。

注:実際にはGPD Pocketでインストールしてみたが、画面キャプチャが面倒だったので、以降の手順は仮想環境で行ったもので代用している。

インストーラで起動すると、下記の様に表示される

環境に合わせて「tz(タイムゾーン)」「keytable(キーボード配列)」「lang(表示言語)」を選び、「Boot with ～」を選ぶ。どっちがいいかは環境による？

しばらく待つとKDEデスクトップが表示される。

この状態でsteam導入もできなくはないのだが、起動ごとに毎回設定がやり直しになるので推奨しない。(OSアップデートがあると警告が表示されたりするが、再起動すると消えるので毎回表示される)

内蔵ディスクや、さらに別途用意したUSBメモリなどへインストールをした方が良い。

インストールはデスクトップ上の「Install Manjaro Linux」をクリックして、インストーラを進めていく。

標準では「スワップを使用しない」が設定されているが、どちらの方がいいんだろうか？(使用しないで進めた)

ゲーミング用途なら、パスワードなしの自動ログイン想定かなぁ？と

インストールを開始します。

…?

FAT32パーテーションを作成した後のLinuxパーテーション作成に失敗している？

パーテーション容量を最大サイズから少し減らしたらインストールが始まった・・・(パーテーション設定のキャプチャなし)

インストール完了

内蔵ディスクから起動しているのでデスクトップ上にInstallのアイコンが消えています。

つづいて、steamのセットアップを実施

左下の「m」メニューから「ゲーム」の「Steam (Runtime)」を選択するか

デスクトップ上で右クリックメニューにある「Show KRunnner」を選択

表示されるウィンドウに「steam」と入力して「アプリケーション Steam(Runtime)」を選択します。

そうするとデスクトップ上に「Steam (Runtime)」アイコンが追加され、Steam setupが開始されます。

セットアップではいろいろダウンロードが行われていきます。

いろいろ処理しているウィンドウが表示されなくなったらダウンロードが終わりなようで、改めてデスクトップ上の「Steam (Runtime)」をクリックすると、Steamのログイン画面が表示されます。

steamにログインすると、まあ、普通に表示されます。

最初に「Steam」の「Settings」を開きます。

「Interface」のlanguageを「日本語(Japanese)」に変更

「Steam Play」の「Enable Steam Play for all other titles」にチェックを入れて、Windowsエミュレーション機能を有効にします。

この設定でいろんなゲームがインストール可能な状態となります。

インストールを選ぶと選択したゲームの他に「Proton(Windowsエミュレーション機能)」と「Steamworks Common Redistributables」のダウンロードが始まります。

ダウンロードが終わり「プレイ」を選択します。

そうすると、「プラットフォーム互換ツールを使用して、このゲームをSteam Playで起動します」というメッセージが表示されます。

ゲームによっては起動前に Microsoft VC Redist Packageインストールなどの処理も実行されます。

やっかいな事に、こういった共有ライブラリが必須であるにも関わらず、特に設定されていないゲームの場合は、プレイボタンを押しても開始に失敗してしまいます。(そういうゲームで起動失敗した場合は何も表示されず、ただゲーム一覧のプレイボタンが再度押せるように戻っていることで察する、という感じ）

なお、仮想環境上での検証は下記の様な感じでDirectX11が上手く動かずに失敗となりました。

GPD Pocket 1で実験した所、FF3は実用的な速度で動作

A列車でいこう9は、かなり遅いものの動く

ライザのアトリエについては、タイトル画面までは出たものの、それ以後の画面は表示できず、という状態でした。

2022/08/04追記

SteamOSとその類似OS

Steam公式にある「自分だけのSteam Machineを組み立てる」はDebian 8ベースの古いSteam OSを使った説明

SteamOS 2.195 リリースノート(2019/07/18)

SteamDeck用のSteamOS 3.xはリカバリイメージとしての提供となっており「Steam Deckリカバリー手順」から入手可能

SteamOS 3.2リリースノート(2022/05/27)
SteamOS 3.3リリースノート(2022/08/03)

Steam Deckリカバリイメージは8GBのUSBメモリに書き込む形式のものとなっているが、vSphere環境上で起動してみようとしたが、うまくいかなかった。

Steam OSのバグについては https://github.com/ValveSoftware/SteamOS/issues から行える。

Steam Deckの内部構造について「Steam Deck Guide」にまとまっている。また、SteamOS相当の機能を他機種でも使えるようにしたLinuxについても紹介されている。

HoloISO

公式: https://github.com/theVakhovskeIsTaken/holoiso

Steam OS 3.xと同じArch Linuxをベースに作られているもの。

SteamDeckと同じAMD系GPUだけではなく、Intel UHD 630+ iGPUや、NVIDIA GTX 9xx GPUでも動く

Nobara Project

公式: https://gitlab.com/GloriousEggroll/nobara-images

こちらはFedora をベースにSteam OS的な機能を盛り込んだもの

ISO生成スクリプトを配布しているだけであるため、ISOファイルをつくるのは別のFedora OSが起動しているサーバで必要なパッケージをインストールした上でスクリプトを実行する必要がある。

winesapOS

公式: https://github.com/LukeShortCloud/winesapOS

USBメモリで起動して使うことを想定したもので、Intel Macでの動作もするらしい。

PlayStation4でLinuxを起動するプロジェクトと組んでPS4上でSteamゲームで遊ぶなんてこともできるらしい。→「WinesapOS 3, based on SteamOS 3 for PS4 with Mesa 22.0.3: PS4 Distro Release」

USBメモリから起動する、というあたりはBatocera Linux を使っているようだ

投稿日:

Firewall内のCentOSからhttps://mirror.centos.org/にアクセスできなかった件

FortigateによるFirewall内にあるCentOS9サーバから「dnf check-update」を実行してみたところ、失敗した。

[root@centos9 ~]# dnf update
サブスクリプション管理リポジトリーを更新しています。
コンシューマー識別子を読み込めません

このシステムは、エンタイトルメントサーバーに登録されていません。subscription-manager で登録できます。

CentOS Stream 9 - BaseOS                        0.0  B/s |   0  B     00:03
Errors during downloading metadata for repository 'baseos':
  - Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.centos.org/metalink?repo=centos-baseos-9-stream&arch=x86_64&protocol=https,http [SSL certificate problem: self-signed certificate in certificate chain]
エラー: repo 'baseos' のメタデータのダウンロードに失敗しました : Cannot prepare internal mirrorlist: Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.centos.org/metalink?repo=centos-baseos-9-stream&arch=x86_64&protocol=https,http [SSL certificate problem: self-signed certificate in certificate chain]
[root@centos9 ~]#

内容的には https://mirrors.centos.org/ へのアクセスでエラーになっていたので、curlコマンドで状況を確認してみることにした。

[root@centos9 ~]# curl -vvv https://mirrors.centos.org/publiclist/
*   Trying 13.125.120.8:443...
* Connected to mirrors.centos.org (13.125.120.8) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self-signed certificate in certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: self-signed certificate in certificate chain
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
[root@centos9 ~]#

同じ環境にあるCentOS7サーバやOracle Linux8サーバでも同じ結果になった。

他の環境にあるCentOS7サーバで実行してみると下記のような感じになった。

-bash-4.2$ curl -vvv https://mirrors.centos.org/publiclist/
* About to connect() to mirrors.centos.org port 443 (#0)
*   Trying 2620:52:3:1:dead:beef:cafe:fed6...
* Connected to mirrors.centos.org (2620:52:3:1:dead:beef:cafe:fed6) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*       subject: CN=mirrors.centos.org
*       start date: 10月 19 06:06:54 2021 GMT
*       expire date:  1月 17 06:06:53 2022 GMT
*       common name: mirrors.centos.org
*       issuer: CN=R3,O=Let's Encrypt,C=US
> GET /publiclist/ HTTP/1.1
> User-Agent: curl/7.29.0
> Host: mirrors.centos.org
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Fri, 12 Nov 2021 08:44:59 GMT
< Server: Apache
< X-Frame-Options: SAMEORIGIN
< X-Xss-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Referrer-Policy: same-origin
< Location: https://admin.fedoraproject.org/mirrormanager/
< Content-Length: 299
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://admin.fedoraproject.org/mirrormanager/">here</a>.</p>
<hr>
<address>Apache Server at mirrors.centos.org Port 443</address>
</body></html>
* Connection #0 to host mirrors.centos.org left intact
-bash-4.2$

Let’s Encryptの証明書使ってるな、ということで、同じ環境にあるブラウザからアクセスしてみると、Fortigateによるhttps周りの動作の問題であることが判明

解決方法は「FortiGate環境で”This Connection is Invalid. SSL certificate expired.”を食らった」にあるやつと同じでした。

投稿日:

LSILogic RAIDのディスク交換をMegaCliを使って行う場合の手順メモ

IBM x3650サーバに入っているLSILogic RAIDカードにて、構成しているディスクが故障したので、ディスクを調達して交換したい。という話があったので、交換手順を確認した。

ついでに一般公開

参考文献
・やっ太郎ブログ:「Megacli64でディスク交換太郎」
・チラシの裏的なBlog:「【備忘録】MegaRAIDでのエラーHDD交換手順」
・IBM Docs:「2073-720 で障害予知機能 (PFA) イベントを報告する、障害が発生したドライブの取り替え」
・Qiita:「HW保守で使いそうなTips 〜ディスク周り〜」

(1) コマンドがある場所に移動

標準では /opt/MegaRAID/MegaCli/ にインストールされていて、PATHは通っていないことが多いので、ディレクトリ移動しておくと以降のコマンドが実行しやすい。

# cd /opt/MegaRAID/MegaCli/
#

(2) コマンド名確認

/opt/MegaRAID/MegaCli/に MegaCliもしくはMegaCli64があるかを確認
移行の手順はMegaCliだったものとして記載している

# ls -F

(3) RAID構成の状態を確認

Stateの状態を確認

# ./MegaCli -LDInfo -Lall -aALL

(4) 物理ディスクの状態を確認

# ./MegaCli -PDList -aALL
# ./MegaCli -PD List  -aALL | egrep 'Slot|Firmware state|Inquiry|Enclo'
# ./MegaCli -PD List  -aALL | egrep 'Slot|state|Data|Raw'

「Firmware state」がディスクの状態でFailedとなっているものが壊れている。

そのディスクについての「Enclosure Device ID」と「Slot Number」の値をこの後の手順で使うので記録しておく。

また「Inquiry Data」にあるディスク型番とシリアルが抜いたディスクとあっているかを確認出来るので、それも記録しておく。

(5) 壊れているディスクの場所を確認

壊れているディスクのLEDを点灯させて交換するディスクと、コマンドで指定する「 physdrv 」の指定が一致していることを、スロットのランプを点灯させて確認する。

下記コマンドを実行すると該当ディスクスロットのランプが点灯

# ./MegaCli -Pdlocate start physdrv[Enclosure Device ID:Slot Number] -a0

下記コマンドを実行すると該当ディスクスロットのランプが消灯

# ./MegaCli -Pdlocate stop physdrv[Enclosure Device ID:Slot Number] -a0

たとえば、Enclosure Device IDが252, Slot Numberが2の場合下記の様に実行する。

  # ./MegaCli -Pdlocate start physdrv[252:2] -a0
  # ./MegaCli -Pdlocate stop physdrv[252:2] -a0

(6) 壊れているディスクをオフラインにする

壊れているディスクをオフラインにする。

# ./MegaCli -PDOffline -PhysDrv [Enclosure Device ID:Slot Number] -a0

Enclosure Device IDが252, Slot Numberが2の場合下記の様になる

# ./MegaCli -PDOffline -PhysDrv [252:2] -a0

なお、壊れ方によっては、すでにオフライン扱いになっていて、このコマンドでエラーとなる場合がある。

(7) 欠落マークがついたRAIDがあるか確認する

6でエラーとなっている場合は、下記コマンドを実行した際に 「Array」と「Row」 といった情報が出力される。このArrayとRowの値はあとで使用します。

# ./MegaCli -PDGetMissing -aALL

6がエラーとなっていない場合は、Array/Rowの出力はないと思われます。

また、MegaCliコマンドのバージョンによっては、このオプションが存在せず、エラーとなる場合があるようです。その際はこの手順を飛ばします。

(8) 壊れているディスクに欠落マークを付ける

まだ壊れていることがきちんと認識されていない場合、壊れていることを確定させます。

# ./MegaCli -PDMarkMissing -PhysDrv [Enclosure Device ID:Slot Number] -a0

Enclosure Device IDが252, Slot Numberが2の場合下記の様になる

# ./MegaCli -PDMarkMissing -PhysDrv [252:2] -a0

MegaCliコマンドのバージョンによっては、PDMarkMissingオプションがないようです
その場合はこの手順を飛ばします。

また、6ですでに欠落マークがついたRAIDが認識されている場合もこの手順は不要であるはずです。

(9) 欠落マークがついたRAIDが認識されたことを確認する

欠落マークがついたRAIDが表示されることを確認します。

# ./MegaCli -PDGetMissing -aALL

この出力中の「Array」と「Row」の番号はあとで使用します。
PDMarkMissingオプションが実行できなかった場合、これも実行できない
と思います。その場合は飛ばします。

(10) 壊れているディスクを抜くことをRAIDコントローラに通知します

下記を実行して、指定したディスクを取り外すことをRAIDコントローラに通告します。

# ./MegaCli -PDPrpRmv -PhysDrv [Enclosure Device ID:Slot Number] -a0

下記の様に実行する

# ./MegaCli -PDPrpRmv -PhysDrv [252:2] -a0

なお、たぶん(6)の段階で欠落マークがついているような場合は、このコマンドを実行するまでもなくディスクが完全に壊れている、と認識されて、すでに抜けるような状態になっているようです。

(11) 壊れているディスクを物理的に抜く

(12) 1分ぐらい待つ

ここで待つのは気休めです。

RAIDコントローラの情報更新間隔がよくわからないので入れてますが、たぶん、すぐに実行しても問題ないような気がします・・・

(13) RAID構成/ディスク認識の状態を確認

ディスクの認識を抜いたことにより、RAID構成の状態が変わっているかを確認します。

# ./MegaCli -LDInfo -Lall -aALL

Stateの状態を確認します。（変わるのかどうかは把握していません）

次に、物理ディスクの状態変化を確認します。

# ./MegaCli -PDList -aALL
# ./MegaCli -PD List  -aALL | egrep 'Slot|Firmware state|Inquiry|Enclo'
# ./MegaCli -PD List  -aALL | egrep 'Slot|state|Data|Raw'

先ほど抜いたディスクに関する表示が消えているはずです。

(14) 新しいディスクを入れる

(15) RAID構成/ディスク認識の状態を確認

RAID状態が変わっているかを確認します。

# ./MegaCli -LDInfo -Lall -aALL

Stateの状態を確認します。
また、RAID構成が新しく認識されていたりしないか確認します。（中古ディスクに情報が残っている場合に発生する可能性がある）

交換したディスクが認識されているかを下記のコマンドで確認します。

# ./MegaCli -PDList -aALL
# ./MegaCli -PD List  -aALL | egrep 'Slot|Firmware state|Inquiry|Enclo'
# ./MegaCli -PD List  -aALL | egrep 'Slot|state|Data|Raw'

(16) 再構築が開始されているかを確認する

RAIDコントローラの設定および交換したディスクの状態によっては、ディスクを交換した時点で、自動的に再構築が開始されます。

下記コマンドで状況を確認します。

# ./MegaCli -pdrbld -showprog -physdrv [Enclosure Device ID:Slot Number] -a0

実行例は下記のようになります。

# ./MegaCli -pdrbld -showprog -physdrv [252:2] -a0

再構築が始まっている場合は progressの数値が徐々に増加していくはずです。

(17) RAIDにディスク交換されたことを認識させる

交換したディスクがスペアディスクなどとして認識されなかった場合は、手動で設定します。

# ./MegaCli -PdReplaceMissing -PhysDrv [Enclosure Device ID:Slot Number] -Array0 -row0 -a0

手順7か手順9で確認したArrayとRowの番号を使ってコマンドを実行します。実行例は下記のようになります。

# ./MegaCli -PdReplaceMissing -PhysDrv [252:2] -Array0 -row0 -a0

PDMarkMissingオプションが実行できなかった場合、これも実行できない
と思います。その場合は飛ばします。

(18) 再構築開始

手動で再構築開始を実行する場合は下記コマンドを実行します。

# ./MegaCli -PDRbld -Start -PhysDrv [Enclosure Device ID:Slot Number] -a0


下記の様に実行します。

# ./MegaCli -PDRbld -Start -PhysDrv [252:2] -a0

(19) 再構築状況を確認

再構築の状況を確認します。

# ./MegaCli -pdrbld -showprog -physdrv [Enclosure Device ID:Slot Number] -a0

下記の様に実行します。

# ./MegaCli -pdrbld -showprog -physdrv [252:2] -a0

(20) RAID構成/ディスク認識の状態を確認

RAID状態が変わっているかを確認します。

# ./MegaCli -LDInfo -Lall -aALL

Stateの状態を確認します。おそらくrebuildなどのステータスになっているかと思います。

また、交換したディスクが認識されているかを下記のコマンドで確認します。

# ./MegaCli -PDList -aALL
# ./MegaCli -PD List  -aALL | egrep 'Slot|Firmware state|Inquiry|Enclo'
# ./MegaCli -PD List  -aALL | egrep 'Slot|state|Data|Raw'
投稿日:

Oracle Linux 8でリリースバージョン固定する方法

Oralce Linux 8.2で導入したい、という要請があった。

(AlmaLinux/RockyLinux/CentOSでの設定については「AlmaLinux /Rocky Linuxのリリースバージョン固定方法」を参照)

Oralce Linux 8.2メディアでインストールすればいい、とは言うものの、パッケージが足らない時にうっかり「dnf install xxxx」とかやってしまうと新しいバージョンを入れてしまう可能性が・・・

有限会社ルートリンクス「RHEL 8 リリースバージョンを指定してアップデート」という記事を見つけて試してみたが、なんか無視されて新しいバージョンを引っ張ってる気がする・・・RHEL8なら有効なのかな？

Oracle Linux 8のドキュメントを探してみる・・・

参考ドキュメント:Oracle® Linux 8 Oracle Linuxでのソフトウェアの管理の「Oracle Linux Yumサーバーを使用するためのシステムの構成」

固定手法について直接の記述はないが「ISOイメージを使用したローカルYumリポジトリの提供」というものがあり、ISOイメージをメインレポジトリとして設定し、それ以外を無効化する、という手法が書かれている。

この手法をそのまま使えば、配置したISOのバージョンで固定できる。

8.2で提供された更新だけ適用できないかな？というもくろみもあって、ISOイメージを使わないで実現する手法がないか試してみた。

なお、結論としては無償でできる範囲には無いようだった。

「使用可能なULNチャネル」の説明を読むとOracleのULNサブスクリプション購読者は「ol8_arch_u?_baseos_patch」というレポジトリでBaseOSに関してはリリースごとのパッチが適用できるようだ。AppStreamについては特に定義されていないようだ。

  1. ISOファイルをローカルディスクに配置
  2. /etc/fstabに「/ISOs/OracleLinux.iso /var/OSimage/OL_x86_64 iso9660 loop,ro 0 0」というようなエントリ追加
  3. /etc/yum.repos.d/ にファイル作成

ここから参考記録

ISOメディアを使わず、ULNサブスクリプションも登録しない状態で何かできるかを試してみたものが、下記の記述となる。

[root@oraclelinux ~]# dnf repolist --all
repo id               repo name                                         status
ol8_UEKR6             Latest Unbreakable Enterprise Kernel Release 6 fo enabled
ol8_UEKR6_RDMA        Oracle Linux 8 UEK6 RDMA (x86_64)                 disabled
ol8_addons            Oracle Linux 8 Addons (x86_64)                    disabled
ol8_appstream         Oracle Linux 8 Application Stream (x86_64)        enabled
ol8_baseos_latest     Oracle Linux 8 BaseOS Latest (x86_64)             enabled
ol8_codeready_builder Oracle Linux 8 CodeReady Builder (x86_64) - Unsup disabled
ol8_u0_baseos_base    Oracle Linux 8 BaseOS GA (x86_64)                 disabled
ol8_u1_baseos_base    Oracle Linux 8.1 BaseOS (x86_64)                  disabled
ol8_u2_baseos_base    Oracle Linux 8.2 BaseOS (x86_64)                  disabled
[root@oraclelinux ~]#

レポジトリリストを見てみたところ「Oracle Linux 8.2 BaseOS (x86_64)」などというそれっぽいものがあるので、ISOイメージの手法にならってまずは「dnf config-manager –disable *」を実行して全レポジトリを無効化

[root@oraclelinux ~]# dnf config-manager --disable \*
[root@oraclelinux ~]# dnf repolist --all
repo id               repo name                                         status
ol8_UEKR6             Latest Unbreakable Enterprise Kernel Release 6 fo disabled
ol8_UEKR6_RDMA        Oracle Linux 8 UEK6 RDMA (x86_64)                 disabled
ol8_addons            Oracle Linux 8 Addons (x86_64)                    disabled
ol8_appstream         Oracle Linux 8 Application Stream (x86_64)        disabled
ol8_baseos_latest     Oracle Linux 8 BaseOS Latest (x86_64)             disabled
ol8_codeready_builder Oracle Linux 8 CodeReady Builder (x86_64) - Unsup disabled
ol8_u0_baseos_base    Oracle Linux 8 BaseOS GA (x86_64)                 disabled
ol8_u1_baseos_base    Oracle Linux 8.1 BaseOS (x86_64)                  disabled
ol8_u2_baseos_base    Oracle Linux 8.2 BaseOS (x86_64)                  disabled
[root@oraclelinux ~]#

続いてOracle Linux 8.2で固定したいので、「ol8_u2_baseos_base」だけを有効化するために「dnf config-manager –enable ol8_u2_baseos_base」を実行

[root@oraclelinux ~]# 
[root@oraclelinux ~]# dnf repolist --all
repo id               repo name                                         status
ol8_UEKR6             Latest Unbreakable Enterprise Kernel Release 6 fo disabled
ol8_UEKR6_RDMA        Oracle Linux 8 UEK6 RDMA (x86_64)                 disabled
ol8_addons            Oracle Linux 8 Addons (x86_64)                    disabled
ol8_appstream         Oracle Linux 8 Application Stream (x86_64)        disabled
ol8_baseos_latest     Oracle Linux 8 BaseOS Latest (x86_64)             disabled
ol8_codeready_builder Oracle Linux 8 CodeReady Builder (x86_64) - Unsup disabled
ol8_u0_baseos_base    Oracle Linux 8 BaseOS GA (x86_64)                 disabled
ol8_u1_baseos_base    Oracle Linux 8.1 BaseOS (x86_64)                  disabled
ol8_u2_baseos_base    Oracle Linux 8.2 BaseOS (x86_64)                  enabled
[root@oraclelinux ~]#

この状態で「dnf check-update」を実行してみる。

[root@oraclelinux ~]# dnf clean all
23 files removed
[root@oraclelinux ~]# dnf check-update
Oracle Linux 8.2 BaseOS (x86_64)                 10 MB/s | 3.3 MB     00:00
Last metadata expiration check: 0:00:01 ago on Wed Oct 20 19:01:10 2021.
[root@oraclelinux ~]#

アップデートは取りに行かない。

が・・・phpをインストールしようとしたら見つからない・・・

[root@oraclelinux ~]# dnf module list
Last metadata expiration check: 0:08:47 ago on Wed Oct 20 19:01:10 2021.
@modulefailsafe
Name                     Stream        Profiles         Summary
satellite-5-client       1.0 [e]       common, gui      ULN client packages

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
[root@oraclelinux ~]# dnf search php
Last metadata expiration check: 0:09:10 ago on Wed Oct 20 19:01:10 2021.
No matches found.
[root@oraclelinux ~]#

phpはAppStreamレポジトリに含まれるものであるため、BaseOSしか登録していない現状では表示されません。

この他、AppStreamに含まれるパッケージで必要なものがいろいろあるため、この手法を取るには無理がある、という形となった。

では、RHEL8みたいにreleaseverという指定ができるか、というところについて /etc/yum.repos.d/oracle-linux-ol8.repo の内容を確認すると、$releasever という定義が使われてない。

[root@oraclelinux ~]# cat /etc/yum.repos.d/oracle-linux-ol8.repo
[ol8_baseos_latest]
name=Oracle Linux 8 BaseOS Latest ($basearch)
baseurl=https://yum$ociregion.oracle.com/repo/OracleLinux/OL8/baseos/latest/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=0
[ol8_appstream]
name=Oracle Linux 8 Application Stream ($basearch)
baseurl=https://yum$ociregion.oracle.com/repo/OracleLinux/OL8/appstream/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=0
[ol8_codeready_builder]
name=Oracle Linux 8 CodeReady Builder ($basearch) - Unsupported
baseurl=https://yum$ociregion.oracle.com/repo/OracleLinux/OL8/codeready/builder/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=0
[ol8_u0_baseos_base]
name=Oracle Linux 8 BaseOS GA ($basearch)
baseurl=https://yum$ociregion.oracle.com/repo/OracleLinux/OL8/0/baseos/base/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=0
[ol8_u1_baseos_base]
name=Oracle Linux 8.1 BaseOS ($basearch)
baseurl=https://yum$ociregion.oracle.com/repo/OracleLinux/OL8/1/baseos/base/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=0
[ol8_u2_baseos_base]
name=Oracle Linux 8.2 BaseOS ($basearch)
baseurl=https://yum$ociregion.oracle.com/repo/OracleLinux/OL8/2/baseos/base/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1
[ol8_addons]
name=Oracle Linux 8 Addons ($basearch)
baseurl=https://yum$ociregion.oracle.com/repo/OracleLinux/OL8/addons/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=0
[root@oraclelinux ~]#

yum.oracle.com にあるOracle Linux 8 RepositoriesでもAppStreamは1種類しか紹介されていない。Base OSアップデートされたパッケージについてはbaseos latest、AppStreamのアップデートされたパッケージはappstreamに配置されていた。

というわけで、Oracle Linux 8において、バージョン固定にする方法は、おとなしく 「1.8 ISOイメージを使用したローカルYumリポジトリの作成」 をつかっとけ、という話になるようだ。

投稿日:

NetAppでファイルのアクセス監査ログを取る

ファイルサーバで、誰かがエクスプローラーの誤操作で変なところにファイルを移動させてしまうことがある。

その時に、アクセス監査ログから誰が移動(削除)操作を行ったかなどを特定できないか、ということで、NetAppのStorage VMに対するアクセス監査の設定を行った。

CIFSアクセスとNFS v4アクセスで利用できる。

公式ドキュメント:SVMでのNASイベントの監査

まずは監査ログの出力先ディレクトリを作成する。これは設定するStorage VM配下のボリュームのどこかに作成する。

今回はvolume:testvolの中に「audit」というディレクトリを作成した。

Storage VMへの監査有効化は「vserver audit create -vserver SVM名 -destination /出力先ディレクトリ」で行う。

ontap98::> vserver audit show
This table is currently empty.

ontap98::> vserver audit create -vserver share225 -destination /testvol/audit

ontap98::>

設定されたことを確認する。

ontap98::> vserver audit show
Vserver     State  Event Types        Log Format Target Directory
----------- ------ ------------------ ---------- ----------------------------
share225    false  file-ops,          evtx       /testvol/audit
                   cifs-logon-logoff,
                   audit-policy-
                   change

ontap98::> vserver audit show -ins

                           Vserver: share225
                    Auditing State: false
              Log Destination Path: /testvol/audit
     Categories of Events to Audit: file-ops, cifs-logon-logoff,
                                    audit-policy-change
                        Log Format: evtx
               Log File Size Limit: 100MB
      Log Rotation Schedule: Month: -
Log Rotation Schedule: Day of Week: -
        Log Rotation Schedule: Day: -
       Log Rotation Schedule: Hour: -
     Log Rotation Schedule: Minute: -
                Rotation Schedules: -
          Log Files Rotation Limit: 0
            Log Retention Duration: 0s

ontap98::>

次にディレクトリに監査を設定する。

CIFSの場合

volume:testvolの中にある「test1」というディレクトリに設定を行うため、プロパティから「詳細設定」を選択

「監査」タブで設定を行う

今回はファイルやディレクトリの削除について記録したいので、「プリンシパル」を「Everyone」と指定し、「高度なアクセス許可」で「サブフォルダーとファイルの削除」と「削除」で設定します。

下記のような表示になります。

これで設定は完了です。

該当するファイルアクセスを行うと、指定したディレクトリ内に「audit_<vserver名>_last.evtx」というファイルにログが出力されていきます。

上記は毎日2:00にファイルをローテートする設定を追加しているので複数のファイルが存在しています。

ちなみに設定は下記の様に行いました。(-rotate-limit 3で設定しているのでファイルが日時入りのファイルが３つある)

ontap98::> vserver audit modify -vserver share225 -rotate-schedule-month all -rotate-schedule-dayofweek all -rotate-schedule-hour 2 -rotate-schedule-minute 0 -rotate-limit 3 -rotate-size 1M

ontap98::> vserver audit show -ins

                           Vserver: share225
                    Auditing State: true
              Log Destination Path: /testvol/audit
     Categories of Events to Audit: file-ops
                        Log Format: evtx
               Log File Size Limit: 1MB
      Log Rotation Schedule: Month: January-December
Log Rotation Schedule: Day of Week: Sunday-Saturday
        Log Rotation Schedule: Day: -
       Log Rotation Schedule: Hour: 2
     Log Rotation Schedule: Minute: 0
                Rotation Schedules: @2:00
          Log Files Rotation Limit: 3
            Log Retention Duration: 0s

ontap98::>

(1回設定した値を消すには 「-rotate-schedule-dayofweek -」などを行う)

で、どんなログが出るか、というあたりですが、ファイルを削除した場合には、イベントID:4656とイベントID:9999が出力されました。

イベントIDの詳細については「監査できるSMBイベント」を参照のこと…ただ、載ってないのもあるんですよね…

NFSv4の場合

NFS v4の場合はLinux上から nfs4_getfacl, nfs4_setfaclコマンドを使って設定する。

NFS v4でマウントして、「test3」というディレクトリのACLを確認

[root@linux mnt]# nfs4_getfacl test3/

# file: test3/
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
[root@linux mnt]#

上記には「U:」で始まるものがありません。

ファイルとディレクトリに関して成功した操作→「fdS」
対象は全ユーザ→「EVERYONE@」
ACLの変更と削除に関して記録→「Cd」

ということを行いたい場合は「nfs4_setfacl -R -a U:fdS:EVERYONE@:Cd 対象ディレクトリ」と実行します。

[root@linux mnt]# nfs4_setfacl -R -a U:fdS:EVERYONE@:Cd test3
[root@linux mnt]# nfs4_getfacl test3/

# file: test3/
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
U:fdS:EVERYONE@:dC
[root@linux mnt]#

で、ファイルを削除した場合、イベントID:4663 とイベントID:4658 が記録されました。

NFSで監査できるイベントについては「監査できるNFSファイルおよびディレクトリのアクセス イベント」に記載があるのですが、evtx出力した時にどういうイベントIDになるのか、という対応表はないようです。

また、どちらの場合でも、下記の様なエラーっぽいものが表示されています。この説明が見つかりませんは仕様で回避方法は無いようです。

ソース "NetApp-Security-Auditing" からのイベント ID 4658 の説明が見つかりません。このイベントを発生させるコンポーネントがローカル コンピューターにインストールされていないか、インストールが壊れています。ローカル コンピューターにコンポーネントをインストールするか、コンポーネントを修復してください。

イベントが別のコンピューターから発生している場合、イベントと共に表示情報を保存する必要があります。

イベントには次の情報が含まれています: 

172.17.44.87
EV_RenderedValue_2.00
false
Not Present
Not Present
Security
File
00000000000406;00;0000064f;046d016e
(nfsshare);/test3/test2.txt

メッセージ リソースは存在しますが、メッセージがメッセージ テーブルに見つかりませんでした。

The description for Event ID 4658 from source NetApp-Security-Auditing cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event: 

172.17.44.87
EV_RenderedValue_2.00
false
Not Present
Not Present
Security
File
00000000000406;00;0000064f;046d016e
(nfsshare);/test3/test2.txt

日本語メッセージリソースがないことが原因なのかと考え、英語UIに替えてみても表示は同じでした。

NetApp KB「The description for Event ID cannot be found in the EVTX logs generated by clustered Data ONTAP」があるので解決できるのかと思ったのですが、無理そうです。