ストレージがないSurface Pro 4を手に入れた


秋葉原のPC SHOP OraOrA!でSurface Pro 4の内蔵ストレージなし、液晶が微妙なものが5千円で売っていた

USBメモリから起動できるのかな?と許可をもらってから持っていたWindows10インストール用USBメディアをさして電源を入れてみたところ、ちゃんと起動するし、液晶は左右がなんか黄色がかっている、というぐらいでまあ許容範囲だな、と買ってみた。

Surface Pro 4の仕様と機能

USBコネクタが1つしかないというのが難点なので、USBハブを用意していろいろセットアップ試行開始

Linux編

GPD Pocket用にArchlinux+Steam環境を作ったUSBメモリがあったので、それで起動してみた

・・・標準状態ではタッチパネルもWiFiも使えない状態でした。

Linux Surface を確認すると、WiFiはArchlinux標準の「linux-firmware-marvell」をインストールすると対応すると

タッチパネルはLinux Surfaceで提供しているパッケージ群をインストールすることで対応できる、と

で・・・インストールしてみると、kritaで筆圧が使える形で使えるようになった。

Chrome OS編

Google純正Chrome OS Flexで起動を試みるんですが、起動に失敗しました

\EFI\BOOT\mmx64.efi - Not Found

EFI\BOOTには boot〜.efi と grub〜.efi の2種類がある。

boot〜.efiをmmx64.efi にコピーして試すと変なループになった

grub〜.efi をmmx64.efi にコピーしたら起動が始まった。

WiFiとオーディオ出力はちゃんと動いているもののタッチパネルは動かない状態。

仕方がないので純正Google OSリカバリイメージを改造するbrunchを使ってみたら、初期状態では同じものの、edit-brunch-config で iptsモジュールを追加することでタッチパネルが使える状態となりました。

Androidアプリも使える状態でまあ普通に使える感じでした。

というわけで、ひとまずChrome OS+brunchでしばらく使うようにします。

液晶の問題

しばらく使ってると液晶が上下にぶるぶる揺れる、という感じになる、という問題が・・・

調べてみるとSurface Pro 4のよくある症状であるようです。

Surface Pro 4の画面揺れをSurface Pro 5の液晶と交換して修理と再発防止をする方法」によると液晶パネルが熱をもつと発生するもので、根本対処は問題がでない液晶パネルに替えるしか無いらしい。

Surface Pro 5の液晶に替える、という手もあるらしい

いまは無い内蔵ストレージは M.2 NVMeストレージ が使えるらしいので、一緒に作業してみてもいいのかな・・・と

さて、どうしていくかなと


2023/07/10追記

ジャンクでマザーボードが抜かれているSurface Pro 5というのが1000円だったので2枚買って、解体チャレンジしてみましたが、2枚とも液晶が割れていました。

このため、手持ちのNVMe SSDをさしてから元のぶれぶれ液晶に戻して使っています。

VisionFive 2のU-boot/SPLをv2.5.0からv2.11.5にアップデートする話


Vision Five 2を最近使っていなかったので、SDK v2.5.0のU-boot/SPLのままで、OSも「Welcome to Armbian 23.05.0.0070 Lunar with bleeding edge Linux 5.15.0-starfive2」といわれてる感じになってた。

いまのU-Boot/SPLバージョンを https://github.com/starfive-tech/VisionFive2/releases で確認するとSDK v2.11.5というバージョンだった。

そして、https://debian.starfivetech.com/ で配布しているDebianも202303版でHDMIディスプレイに起動メッセージが出力されるようになった模様。

なので、U-boot/SPLを最新にしてみるか、とv2.11.5をダウンロードしてきて実行!

osakanataro@visionfive2:~/v2.11.5$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~/v2.11.5$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
u-boot-spl.bin.normal.out won't fit into /dev/mtd0!
osakanataro@visionfive2:~/v2.11.5$

・・・「u-boot-spl.bin.normal.out won’t fit into /dev/mtd0!」とはどういうこと?

Updating SPL and U-Boot of Flash を確認すると「Method 2 only supports versions equal to or later than VF2_v2.5.0.」と書いてあるので、サポートされてるはず?

とりあえずv2.6.0でやってみるか、と試すと、案の定成功

osakanataro@visionfive2:~/v2.6.0$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
Erasing blocks: 32/32 (100%)
Writing data: 124k/124k (100%)
Verifying data: 124k/124k (100%)
osakanataro@visionfive2:~/v2.6.0$ sudo flashcp -v visionfive2_fw_payload.img /dev/mtd1
Erasing blocks: 682/682 (100%)
Writing data: 2727k/2727k (100%)
Verifying data: 2727k/2727k (100%)
osakanataro@visionfive2:~/v2.6.0$

一回再起動

osakanataro@visionfive2:~/v2.11.5$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
u-boot-spl.bin.normal.out won't fit into /dev/mtd0!
osakanataro@visionfive2:~/v2.11.5$

まだ駄目なので、v2.8.0を適用

osakanataro@visionfive2:~/v2.8.0$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~/v2.8.0$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
Erasing blocks: 32/32 (100%)
Writing data: 127k/127k (100%)
Verifying data: 127k/127k (100%)
osakanataro@visionfive2:~/v2.8.0$ sudo flashcp -v visionfive2_fw_payload.img /dev/mtd1
Erasing blocks: 683/683 (100%)
Writing data: 2731k/2731k (100%)
Verifying data: 2731k/2731k (100%)
osakanataro@visionfive2:~/v2.8.0$

再起動しないでv2.10.4の適用も試してみたところ成功した。

osakanataro@visionfive2:~/v2.10.4$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~/v2.10.4$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
Erasing blocks: 32/32 (100%)
Writing data: 127k/127k (100%)
Verifying data: 127k/127k (100%)
osakanataro@visionfive2:~/v2.10.4$ sudo flashcp -v visionfive2_fw_payload.img /dev/mtd1
Erasing blocks: 684/684 (100%)
Writing data: 2734k/2734k (100%)
Verifying data: 2734k/2734k (100%)
osakanataro@visionfive2:~/v2.10.4$

もしやv2.11.5もいくか?と再チャレンジしてみたが駄目

osakanataro@visionfive2:~/v2.11.5$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~/v2.11.5$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
u-boot-spl.bin.normal.out won't fit into /dev/mtd0!
osakanataro@visionfive2:~/v2.11.5$

再起動してみても相変わらず駄目

osakanataro@visionfive2:~/v2.11.5$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~/v2.11.5$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
u-boot-spl.bin.normal.out won't fit into /dev/mtd0!
osakanataro@visionfive2:~/v2.11.5$

これはkernelもアップデートしないと駄目か?

しばらくarmbianのapt update/upgradeを実施・・・

osakanataro@visionfive2:~/v2.11.5$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~/v2.11.5$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
u-boot-spl.bin.normal.out won't fit into /dev/mtd0!
osakanataro@visionfive2:~/v2.11.5$ uname -a
Linux visionfive2 5.15.0-starfive2 #1 SMP Mon Feb 20 02:51:35 UTC 2023 riscv64 riscv64 riscv64 GNU/Linux
osakanataro@visionfive2:~/v2.11.5$

駄目かぁ…

RVspaceのフォーラム「Flashcp => /dev/mtd0 2.11.5」では/dev/mtdのパーテーション切り直せばなんとかなる?

githubのissue「Can not upgrade to firmware v2.11.5 #37」ではreleaseのとこにあるsdimageなどからブートすればアップデートできる、という話

とりあえずrvspaceのやつをやってみる

osakanataro@visionfive2:~/v2.11.5$ sudo mtdpart del /dev/mtd 2
mtdpart: error!: Cannot open /dev/mtd
         error 2 (No such file or directory)
osakanataro@visionfive2:~/v2.11.5$ sudo ls -l /dev/mtd*
crw------- 1 root root 90, 0  4月 18 22:29 /dev/mtd0
crw------- 1 root root 90, 1  4月 18 22:29 /dev/mtd0ro
crw------- 1 root root 90, 2  4月 18 22:29 /dev/mtd1
crw------- 1 root root 90, 3  4月 18 22:29 /dev/mtd1ro
crw------- 1 root root 90, 4  4月 18 22:29 /dev/mtd2
crw------- 1 root root 90, 5  4月 18 22:29 /dev/mtd2ro
brw-rw---- 1 root disk 31, 0  4月 18 22:29 /dev/mtdblock0
brw-rw---- 1 root disk 31, 1  4月 18 22:29 /dev/mtdblock1
brw-rw---- 1 root disk 31, 2  4月 18 22:29 /dev/mtdblock2
osakanataro@visionfive2:~/v2.11.5$

/dev/mtd というデバイスは無かった…

Updating SPL and U-Boot of SD Card and eMMC」だとオフィシャルdebianイメージだと起動に使うSDカードに直接新しいのを書き込んで更新という手も取れるらしい

armbianだとSDカードは1パーテーションであるため、この手法は使えなかった

また、Debian 202303イメージを直接ブートしてみる、というのをやってみたが、U-Bootのところで起動に失敗した。

で・・・結局のところv2.11.5のsdcard.img をmicrosdに書き込んで起動すると、mtdデバイスのパーテーション切り直しと、U-Boot/SPLの更新が自動的に行われて、HDMIディスプレイにもコンソール出力が出るようになりました

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
#
# ls -l /dev/mtd*
crw-------    1 root     root       90,   0 Jan  1 00:00 /dev/mtd0
crw-------    1 root     root       90,   1 Jan  1 00:00 /dev/mtd0ro
crw-------    1 root     root       90,   2 Jan  1 00:00 /dev/mtd1
crw-------    1 root     root       90,   3 Jan  1 00:00 /dev/mtd1ro
crw-------    1 root     root       90,   4 Jan  1 00:00 /dev/mtd2
crw-------    1 root     root       90,   5 Jan  1 00:00 /dev/mtd2ro
brw-rw----    1 root     disk       31,   0 Jan  1 00:00 /dev/mtdblock0
brw-rw----    1 root     disk       31,   1 Jan  1 00:00 /dev/mtdblock1
brw-rw----    1 root     disk       31,   2 Jan  1 00:00 /dev/mtdblock2
#

が・・・・armbianで起動しなおすと/proc/mtdの結果が違う

osakanataro@visionfive2:~$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~$

armbian内蔵のu-boot/splが更新されないと駄目??

APC Network Management Card のメモ 2023/04/13版


久しぶりにAPC Smart-UPS に Network Management Cardを入れて設定することになった。

しかしAPCのサイトにある「Network Management Card | よくあるお問い合わせ」にある「Network Management Card 2のAPC Device IP Configration Wizard 5.0.2 を使用したIPアドレス設定方法」に記載されているリンク先は軒並み機能していなかった。

そんなわけでメモ書き

1) Network Management CardのIPアドレスを振るのはシリアル接続かDevice IPソフトウェア

Network Management Card Device IP Configuration Utility v5.0.4

ただし、Java Runtime Environment 1.8以降が必要なのだが、何を使うかが悩みどころ・・・

APCのドキュメント的にはすなおにOracle Java SE Runtime Environmentのダウンロードを推奨で

他社をみるとQuestもOracle JRE「JRE(version 1.8 or above) Installation for Microsoft Windows (4229374)

キヤノンITソリューションはAmazon Correttoを使っていた「Q:【構築手順】Windows Server環境で、オープンソースJDKを利用してセキュリティ管理ツールをインストールするには?

とりあえず今回はjre-8u361-windows-x64.exeを使った

2) Network Management Cardのfirmware

UPS Network Management Cardsのfirmware からfirmwareをダウンロード

カードを挿すUPSの種類により適用するfirmwareも異なる

3) Device IP使っても出ない場合

dhcpで範囲内にいるはずなのにDevice IPで出てこなかった

その場合はarp -aの結果からMACアドレスが「28:29:~」(Network Management Card 3/AP9640Jの場合)で始まるものを探して総当たりでhttpsアクセスしてみるとよい

4)Network Management Card 3の言語表示

Network Management Card 2では追加言語ファイルを導入しないと日本語表示がなかったりした。

Network Management Card 3は標準状態で多言語対応しているのだが、デフォルト表示が基本Englishとなっている。

ログイン画面の言語設定変更は[Configuration]-[Security]-[Local Users]-[Default Settings]

ここのLanguageを「English」から「日本語」に変えるとログイン画面の表示が日本語になります。

ログイン画面は日本語になったものの「apc」ユーザでログインすると英語表示。

これはユーザ特有設定の方にあるため、[Configuration]-[Security]-[Local Users]-[Management]でユーザ一覧を表示する

「apc」をクリックしてLanguageを「English」から「日本語」に変える

4)PCNSのコマンドファイルの指定について

シャットダウン時にバッチファイルを実行させるべく「コマンドファイルのパス」に指定しようと文字を入力しはじめたら下記の様に言われた。

コマンドファイルを読み込めませんでした。ファイルはPowerChuteインストールディレクトリのuser_filesフォルダーにある必要があります。詳細については、ヘルプを参照してください。

ということは、C:\Program Files\APC\PowerChute\user_files にファイルを置いて、ファイル名だけ指定すればいいのかと思ったが、相変わらず上記のエラー

フルパスで指定したら通った・・・

5) ssh接続がうまく行かない

PowerChute Network Shutdown のv4.4にはsshで他のサーバにログインしてコマンドを実行する機能がある。

これを利用してNetAppにログインしようとしたのだがうまくいかない

SSH アクションとして2種類登録を作ってみた

1つはユーザ名とパスワードを入力してログインするタイプ

もう1つはsshキーを使ってログインするもの。

ここで指定したsshキーは C:\Program Files\APC\PowerChute\user_files\ssh_id_rsa.txt という形でWindows Server標準のssh-keygenコマンドを使って作成したやつをコピーしたもの。

アクセス権については特に調整していない。

どちらの設定でも実行するコマンドを列挙した「SSHコマンドファイルのパス」は C:\Program Files\APC\PowerChute\user_files\netappshutdown.txt とした。

内容は以下の確認なしでNetAppを停止する手法を記載した。

set -confirmations off; system node halt -node * -inhibit-takeover true -ignore-quorum-warnings true

で・・・これだけでは動かなかった。

PowerChute Network Shutdownのヘルプにある「SSH設定」の説明で以下がある。

認識されているコマンドプロンプトは次のとおりです。
 ・$ (Linux)
 ・# (Linux admin/root)
 ・> (Windows または RPDU)
ssh_prompt_regex」設定を[SSHAction]セクションに追加することにより、カスタムコマンドプロンプトは、PowerChute構成ファイル (pcnsconfig.ini) を介して追加できます。例えば: 「~」のカスタムコマンドプロンプトを追加するには、「ssh_prompt_regex = ~\s」を追加します。

NetAppのコマンドプロンプトは「クラスタ名::> 」なので、WindowsまたはRPDUの「>」で通るものかと思っていたのですが、違ったようです。

C:\Program Files\APC\PowerChute\group1\pcnsconfig.iniの[SSHAction数字]に以下のように「::>」プロンプトを追加することで動作するようになりました。

ssh_prompt_regex = \::>\s

Windows 11 on ARMをRK3588SのOrange Pi 5で動かす


しばらく前から、Rockchip RK3588を積んだRock 5B上でWindows 11 on ARMを動かす、というものが公開されていた。

元々は2022年11月にRock 5の販売元であるradxaのフォーラムの「Windows / UEFI on Rock 5 (Mega thread)」(https://github.com/edk2-porting/edk2-rk35xx)で公開されていたものが、2023年3月にtwitterでMario BălănicăさんがROCK 5B向けで動かしているツイートをしてから開発が加速(https://github.com/mariobalanica/edk2-rk35xx)

そこにOrange Pi公式が乗っかったことでOrange Pi 5向け対応も行われるようになった形です。

しばらくは具体的な導入手法はなく、UEFIのみ提供されている状態でしたが、3月下旬にWoRプロジェクトのWebに「Preliminary installation guide for RK3588 boards」と手順が公開され試しやすくなりました。

2023/04/12現在でのOrange Pi 5での制限事項

全体的なもの

・M.2コネクタ利用不可
・HDMI出力のみ対応(Type-C出力は使用できない)
・オンボードNICが使えない

USBコネクタに関する制限事項

・USB 3.0(青コネクタ)の上側のポートはUSBストレージ用に使う
・USB 3.0(青コネクタ)の下側のポートはキーボードなどで使えると書いてあるのだがうまく動かず
・USB 2.0(縦配置のやつ)にUSBハブをつなげてキーボード/マウス/USB NICをつなげると良い
・Type-CコネクタもUSB 2.0扱いで使えるらしいのだがうまく動かず

Windowsのインストール先について

・microSDから起動することもできるっぽいのだが成功せず
・USB 3.0(青コネクタ)の上側ポートにつけたUSBストレージからの起動には成功
・速いストレージを使わないと起動がすごく遅い

セットアップ手法について

WoRの「Preliminary installation guide for RK3588 boards」のWindows手順ではメディア作成関連がいまいち分かりづらかったので、Ubuntu 20.04環境で設定を行った

用意するもの
・USB接続で速いディスク
・UbuntuマシンとOrange Pi 5を繋ぐUSB-A/Cケーブル(SPI書き込みの際に使用)
・USB NIC(Windows11標準で認識するもの)
・USB ハブ(キーボード/マウス/NICをつなぐにはポートが足らないので)

手順概要

1) Ubuntuに前提条件パッケージをインストール

以下のworkliが要求しているパッケージをインストール

# apt install gawk xmlstarlet jq wget wimtools ntfs-3g curl cabextract chntpw genisoimage zenity 

rkdeveloptoolが要求するパッケージをインストール

# apt install libudev-dev libusb-1.0-0-dev dh-autoreconf

2) rkdeveloptool をコンパイルしてインストール

基本としてはrockchip wikiのRkdeveloptool に記載のやりかたで https://github.com/rockchip-linux/rkdeveloptool のレポジトリをcloneしてコンパイルするんだけど、実はwikiは記載が足らないので、githubの方に記載のコマンドでコンパイルして、 /usr/local 以下のインストールする。

$ git clone https://github.com/rockchip-linux/rkdeveloptool.git
$ cd rkdeveloptool
$ aclocal
$ autoreconf -i
$ autoheader
$ automake --add-missing
$ ./configure
$ make
$ make install

3) workli.sh を入手

githubの https://github.com/buddyjojo/worklireleases から workli.sh をダウンロード

ver 1.0時点では、GUIダイアログで選択させる系のつくりになっているためX-Window環境が必要

4) workli.shを実行してSPI/SD選択まで進める

まず、日本語でメッセージが出力されていると、デバイスが識別できなかったので英語で動作させる

$ export LANG=C
$ sudo bash workli.sh

また、sudoを実行する必要があるので、環境によっては下記の様な実行が必要となる

$ export LANG=C
$ xhost +
$ sudo  XAUTHORITY=~/.Xauthority  bash workli.sh

ブートローダ/UEFIをSPIかSDのどちらかにするところまできたら、SPIを選択

5) Orange Pi 5をUbuntuマシンにつなげる

Orange Pi 5に電源ケーブルを繋がない状態で、HDMIコネクタの右側のType-CをUbuntuマシンにつなげ

Orange Pi 5の基盤上にあるMaskromボタンを押しながら、HDMI左側の電源用Type-Cコネクタに電源をつなげる

そうすることで、Ubuntuマシン上にOrange Pi 5がデバイスとして認識される

6) workli.shのプロセスを進める

windowsイメージのダウンロードも自働で行ってくれる

7) USBストレージをUbuntuマシンにつなげる

UbuntuマシンにつなげていたOrange Pi 5を外して、代わりにWindowsをインストールするUSBストレージをつなげる

8) workli.sh でUSBストレージにWindowsをインストールする

9) 書き込んだUSBストレージをOrange Pi 5につなげてOrange Pi 5を起動

まずは下記のようなOrange PiのロゴのUEFIが表示される

しばらくすると下記のようなコマンドプロンプトが表示されて再起動

Orange Piのロゴが表示されたあと、下記の様なブルースクリーンが表示され、再起動する・・・というのを2回くらうと、先に進むのでしばらく放置する

しばらく待つと下記の様な「準備しています」表示になる。

そのうち下記の様なWindows 11の初期セットアップ画面が表示される

Windows 11の場合、Proであってもインターネット接続が必須とされているのを回避するため、Shiftキー+F10キーでコマンドプロンプトを開いて「oobe\bypassnro」を実行する。

実行すると再起動がかかるので、しばらく待ってWindows 11の初期セットアップを進める

Windows 11が起動する

2023/04/12時点ではデバイスマネージャの認識は以下の様な形となっていた

Windows のarm64ビットとして動作していることが確認できる。

また、ラズパイ4の時と同様に古い32ビットWindowsアプリも動作することが確認出来る。

Rstudio Serverの設定で分からなかったことのメモ


Rstudio ServerをRHEL9環境にインストールした際に悩んだことのメモ

その1: 新規作成プロジェクトでのpythonパスを指定したい

ユーザのホームディレクトリに「.Renviron」というファイルを作って 環境変数 RETICULATE_PYTHON を定義する。

RETICULATE_PYTHON="/usr/local/python3/bin/python"

なお、今回は~/.Renviron ファイルを使ったが、「Managing R with .Rprofile, .Renviron, Rprofile.site, Renviron.site, rsession.conf, and repos.conf」の記述を見ると、いろいろある。

システム全体の設定としては $R_HOME/etc/Renviron がある。

検証環境の場合 /opt/R/4.1.3/lib/R/etc/Renviron にあった

### etc/Renviron.  Generated from Renviron.in by configure.
###
### ${R_HOME}/etc/Renviron
###
### Record R system environment variables.

## As from R 4.0.0 the C code reading this follows the POSIX rules
## for parameter substitution in shells, section 2.6.2 of
## https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18
## In earlier versions ${FOO-bar} was interpreted the same as ${FOO:-bar}

R_PLATFORM=${R_PLATFORM-'x86_64-pc-linux-gnu'}
## Default printer paper size: first record if user set R_PAPERSIZE
R_PAPERSIZE_USER=${R_PAPERSIZE}
R_PAPERSIZE=${R_PAPERSIZE-'letter'}
## Default print command
R_PRINTCMD=${R_PRINTCMD-'/usr/bin/lpr'}
# for Rd2pdf, reference manual
R_RD4PDF=${R_RD4PDF-'times,hyper'}
## used for options("texi2dvi")
R_TEXI2DVICMD=${R_TEXI2DVICMD-${TEXI2DVI-'/usr/bin/texi2dvi'}}
## used by untar(support_old_tars = TRUE) and installing grDevices
R_GZIPCMD=${R_GZIPCMD-'/usr/bin/gzip'}
## Default zip/unzip commands
R_UNZIPCMD=${R_UNZIPCMD-'/usr/bin/unzip'}
R_ZIPCMD=${R_ZIPCMD-'/usr/bin/zip'}
R_BZIPCMD=${R_BZIPCMD-'/usr/bin/bzip2'}
## Default browser
R_BROWSER=${R_BROWSER-'xdg-open'}
## Default editor
EDITOR=${EDITOR-${VISUAL-vi}}
## Default pager
PAGER=${PAGER-'/usr/bin/less'}
## Default PDF viewer
R_PDFVIEWER=${R_PDFVIEWER-''}
## Used by libtool
LN_S='ln -s'
MAKE=${MAKE-'make'}
## Prefer a POSIX-compliant sed on e.g. Solaris
SED=${SED-'/usr/bin/sed'}
## Prefer a tar that can automagically read compressed archives
TAR=${TAR-'/usr/bin/gtar'}

## System and compiler types.
R_SYSTEM_ABI='linux,gcc,gxx,gfortran,gfortran'

## Strip shared objects and static libraries.
R_STRIP_SHARED_LIB=${R_STRIP_SHARED_LIB-'strip --strip-unneeded'}
R_STRIP_STATIC_LIB=${R_STRIP_STATIC_LIB-'strip --strip-debug'}

R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/4.1'}
#R_LIBS_USER=${R_LIBS_USER-'~/Library/R//4.1/library'}

### Local Variables: ***
### mode: sh ***
### sh-indentation: 2 ***
### End: ***

しかし、これを直接編集はしてはいけない。

/opt/R/4.1.3/lib/R/etc/Renviron.site というファイルを新規で作成し、 「RETICULATE_PYTHON=”/usr/local/python3/bin/python”」とか書くことで全体適用となる。

これは、/opt/R/4.1.3/lib/R/etc/Renviron の方は、Rのバージョンアップで設定値が変わる可能性があるので、特有の設定はファイルを分離しておく、というものになっている。

その2: アクセスログ

Rstudio ServerのWeb UIから誰がログインしたのか、というログがどこに出るのか?

どうやら、Pro版のみの機能の模様で、 /etc/rstudio/rserver.conf に「server-access-log=1」と設定するようだが、ライセンスがないと、この設定が入っているとRstudio serverが起動しない。

わざとパスワードを間違えたりすると /var/log/secure にログがでるので、/etc/pam.d/rstudio の内容を/etc/pam.d/sshd と同じにすれば、rstudioでログインに成功した場合でも同じようにログイン成功時もログ出力があるかと思ったのですが、出力されず。

・・・ただ、pamtesterコマンドで動作検証してみたところ、rstudioでもsshdでもログイン成功時に出力していない・・・もしかしてsshでログイン成功した時に/var/log/secureに出力しているのはpamd経由ではない??

rstudioでパスワード間違え

[root@rhel9 rstudio]# pamtester -v rstudio testuser authenticate
pamtester: invoking pam_start(rstudio, testuser, ...)
pamtester: performing operation - authenticate
Password:
pamtester: Authentication failure
[root@rhel9 rstudio]#

/var/log/secureの出力内容

Apr  5 17:50:51 rhel9 unix_chkpwd[41719]: password check failed for user (testuser)
Apr  5 17:50:51 rhel9 pamtester[41717]: pam_unix(rstudio:auth): authentication failure; logname=root uid=0 euid=0 tty= ruser= rhost=  user=testuser

rstudioでパスワード正しく

[root@rhel9 rstudio]# pamtester -v rstudio testuser authenticate
pamtester: invoking pam_start(rstudio, testuser, ...)
pamtester: performing operation - authenticate
Password:
pamtester: successfully authenticated
[root@rhel9 rstudio]#

/var/log/secureへの出力は無い

sshdでパスワード誤り

[root@rhel9 rstudio]# pamtester -v sshd testuser authenticate
pamtester: invoking pam_start(sshd, testuser, ...)
pamtester: performing operation - authenticate
Password:
pamtester: Authentication failure
[root@rhel9 rstudio]#

/var/log/secureへ出力あり

Apr  5 17:51:09 rhel9 unix_chkpwd[41726]: password check failed for user (testuser)
Apr  5 17:51:09 rhel9 pamtester[41724]: pam_unix(sshd:auth): authentication failure; logname=root uid=0 euid=0 tty= ruser= rhost=  user=testuser

sshdでパスワード正しく

[root@rhel9 rstudio]# pamtester -v sshd testuser authenticate
pamtester: invoking pam_start(sshd, testuser, ...)
pamtester: performing operation - authenticate
Password:
pamtester: successfully authenticated
[root@rhel9 rstudio]#

/var/log/secureに出力無し