Jamano's Blog 2nd gen.
社内サーバーの共有ストレージ用にSambaを利用しています。しばらくはSMB1での運用でしたが、MicrosoftがSMB1を取り除くとの方針が発表されました。
SMB1->SMB2の時にはセキュリティ証明書が必要になると思い込んでいたので、判ってはいたのですが全く行動に移さずにいましたが、どうもそうではない模様。
単純に/etc/samba/smb.confに”min protocol = SMB2″の一文を追加するだけのことでした。実際にやってみましたが全く問題は起きません。
こんなことならもっと早くやっておくんだったな…
Windowsには標準でリモートデスクトップ接続の機能があります。職場でのサーバー管理に便利に使っていたのですが、3月の末頃から妙なエラーが発生して接続できない状態となりました。
ちょっとした作業なら定番のTeraTermを使ってコンソールで済ませることができるのですが、「GUIに頼るなんてトーシロだな」なんて声が聞こえてきますが、ファイルを大量に加工するとか中のゴミを大掃除するなんて作業の場合はGUIで楽にやりたいものです。
接続拒絶のダイアログに表示されるメッセージには「セキュリティレベル」がどうのこうのと出ます。Linuxサイドには特に変更を加えたつもりはないので、戸惑うばかり。WindowsのProでもHomeでも同じ問題が出て接続できせん。また、このリモート接続でのセキュリティレベル云々の問題はネットを漁っても情報がありません。
散々探してようやく突き当たったのが、なんと接続時の色数の問題。Linux側はxrdpなのですが、/etc/xrdp.iniの設定で色数設定を32から24にすると良いとの情報が見つかりました。で、ここを変更してやったところ無事に接続できるようになりました。
#hidelogwindow=true max_bpp=32 <- ここを24へ new_cursors=true
こんな設定いじったことは無いはずなのですが、どうにも妙。各種ログを確認したところ3月末にyumでxrdpが自動更新されてました。そのときにiniファイルも更新されてしまったのでしょうね。迷惑だな…
それにしても32bppだと問題になるセキュリティって何なのでしょうね。なんか闇だな。
エンジンを始動した途端になにやら不穏なメッセージが表示されました。
エレクトロニックパーキングブレーキとかありますが、要は電動のパーキングブレーキシステム。ギアセレクター横のボタンで掛けたり開放したりできます。
とりあえずこういう時には一旦システム再起動が鉄則なので、一旦OFFにして少し待機。再始動したところメッセージは消えたのでした。
実はこのメッセージが出るのは初めてではないのですが、毎回再始動で消えてしまうので放置していたのでした。が、さすがに3回も見ると穏やかでは居られませんのでディーラーに連絡。近々修理となる予定です。
まぁそれにしてもあれこれ電脳仕掛けになってきているので、いろいろとつまらないことが原因のエラーが多発するようになってきましたね。
昔の車なら、サイドブレーキのトラブルといったらワイヤーが伸びて効きが甘くなるとか、どこかに引っかかって戻らないといった単純な物が多く、その場でなんとかできることが多かったのですが、コントロールユニットがどこにあるかもよく解らないブラックボックス化している現代の車では下手に手出しができないので、こういった時には困ります。
LinuxとWindowsとを往復すると、RTCの取り扱いの問題で時間がずれます。
うっとうしいので、Linux側をいじったところ変な警告が出たという話は前回しました。なので今回はWindows側の対策の話。
まぁ難しいことは無くて、レジストリエディターで1項目追加するだけです。追加するのは次の項目
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
このレジストリエントリを追加してDWORDで1をセットします。あとは再起動するだけ。再起動すれば当然9時間ずれますので、時刻合わせを行っておきます。
それにしてもまだまだWindowsにもいろいろな機能が隠されていますね。みなさんどうやって見つけているんだろうか。Windows SDKあたりにヒントが隠されているのかな?
LinuxからWindowsに戻すと時刻が-9時間となって鬱陶しいです。
[xxxxx@localhost ~]$ timedatectl
Local time: 日 2022-03-13 12:15:19 JST
Universal time: 日 2022-03-13 03:15:19 UTC
RTC time: 日 2022-03-13 03:15:20
Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
それは上記のようにPCの内部時計(RTC)がUTCに同期してしまうからです。LinuxサイドではRTCのデーターから指定されたTimeZoneデータを元に現在時刻を出すので問題無いのですが、WindowsはRTCがローカルタイムであることが前提になっています。
これだとWindowsに戻ったときにいちいち時計合わせしなくてはならず、面倒なので、LinuxサイドのRTCをローカルタイムに合わせてみます。
[xxxxx@localhost ~]$ sudo timedatectl set-local-rtc 1
[xxxxx@localhost ~]$ timedatectl
Local time: 日 2022-03-13 12:21:18 JST
Universal time: 日 2022-03-13 03:21:18 UTC
RTC time: 日 2022-03-13 12:21:18
Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
NTP service: active
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
しかし、「いろいろと不都合が出るかもよ」と”脅されます”。ならばともう一度調べたところWindows側のRTCをUTCに合わせる方法もあるとのこと。普段はLinuxなので、Windowsの方を合わせることにしましょう。
本番環境はFedoraなので、そちらを起動。するとKDEのスクリーンになったところで固まってしまいGUIの反応がなくなります。ただし別に起動しておいたKonsoleは動いているので、システム全体が死んだわけでありません。
クリーンインストールが必要かと勘違いしてbootable mediaを作成。でもやっぱり同じく固まる。ならばとMint Desktopのbootable mediaを作成して試したところこらはOK。
しばらくMintで凌ぐかと考えたのですが、よく考えてみたらドライバーが不適合なだけと言うことに気がついてnVidiaのドライバーをインストール。rpmfusion-non-freeにドライバーがあるので、rpmfusion-non-freeをenableにしてインストール。ようやく全体が正常に動くようになったのでした。
[xxxxx@localhost ~] sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm [xxxxx@localhost ~] sudo dnf install akmod-nvidia
AMDならともかく、NvidiaのGeForceシリーズならデフォルトでカバーされているものとばかり思っていたのでこれは意外でした。もっともMintではそのままでOKでしたから、これはKDE特有の問題かもしれません。KDEの人はNvidiaが嫌いなのかな(笑)。
Videoカードの交換でドライバーが必要になったのは、2013年にAMDのカードに変えた時なので、9年ほど遭遇しなかった事態です。なのですっかり忘れてちょっと焦ったのでした。
3月21日追記
どうにも各ウィンドウの中身の表示がちらついたりして落ち着きません。Nvidiaの場合、cudaドライバーも入れないと駄目だとのことなのでインストール。
cudaってGPUで演算するための機構というイメージが強いので、別にいいかと思ったのでした。記事によっても「入れてもいいよ」から「入れないと問題が起きるかもね」まであっていろいろ。
[xxxxx@localhost mak]$ sudo dnf install xorg-x11-drv-nvidia-cuda ===================================================================================================================== パッケージ Arch バージョン リポジトリー サイズ ===================================================================================================================== インストール: xorg-x11-drv-nvidia-cuda x86_64 3:510.47.03-1.fc35 rpmfusion-nonfree-updates 1.8 M 依存関係のインストール: nvidia-persistenced x86_64 3:510.47.03-1.fc35 rpmfusion-nonfree-updates 34 k opencl-filesystem noarch 1.0-14.fc35 fedora 7.4 k トランザクションの概要 ===================================================================================================================== インストール 3 パッケージ
cudaを入れたところなんとなく落ち着いた感じ。まだ再起動していないので本当かどうかはわかりませんけど。
さらに追記
cuda入れても変わりは無し。なのでwaylandをあきらめてxorgにスイッチ。今のところ落ち着いている感じ。多少はパフォーマンスが落ちるんでしょうけど、安定がなにより第一!
自宅PCのVideoカード不調が悪化してしまい、WindowsでもLinuxでも突然に一面単色になって無反応となることが増えてきました。本当に突然落ちるので困ります。
現PCは現在8年目のi4770使用の物。一応内蔵グラフィック(HD4600)が使用できるので急場はしのげますが、どうしてもパフォーマンスはがた落ちです。また接続が15pinのVGAケーブルでの「アナログ」接続なので目にも厳しい…
PC入れ替えるかと考えて中古を探してみましたが、現状と変わらない第4世代CPUの品でも3～4万。せめて第7世代くらいにはしたいものだと思うのですが、物が有りません。
もちろん新品で同じような構成を取ると軽く10万に達してしまうのでこちらも現実的な方法ではありません。
と言うわけでバクチではありますが、Videoカードの交換を実施。それにしても選択肢が極端になってしまいましたね。今回選んだGT1030はかなりのロースペックなのですが、だからといってこの次はGT1050TiやGTX1650となって価格も3万近く。補助電源は必要だし、冷却も大変。1030と1050Tiの間のスペックの品が無いので、困ります。
結局は約10k円出してGT1030の安いやつを調達しました。
安いだけあって小さくてちゃちな品物です。
全体が真っ白のレジストに覆われているのは斬新かもしれません。
出力はHDMIとDVIだけ。Display Portは対応しません。
で、3D Mark11を走らせてみましたが、HD4600の3倍のパフォーマンスなので、一応交換しただけのことはあったという結果。ただし、前カードのRX550の70%程度なのでRX550の優秀さが光ります。価格もこちらは7.5k円でしたしね。とは言ってもまともに動かなければただのゴミですからこれはやむを得ないな。
後は壊れずに使えることを願うだけです。
どうにか時間が取れたので、本体のbuild開始。30分くらいで終わった気がします。
今回、VSでProjectを開くのにドキュメントと違う方法試したところドはまり。cmakesettings.jsonにswig.exeとpython.exeのありかを書いておけば、特に何も追加指定せずに実行できるはずと、あれこれやりましたがエラーが取れなくて一旦中止。cmakesettings.jsonの書式を勉強しないとだめですね…
今度はドキュメント通りにprojectを開き、ドキュメントにある通りにswig.exeとpython.exeの在処を書き込んでビルド開始。ビルドオプションは生成するオブジェクト毎に分かれています。x86-debug,x86-release,x64-debug,x64-release,MSYS2-x64-debugとあるのですが、x86とMSYS2は使用しないのでx86の2つにだけ追加。
出来上がったのはよいのだけど、何このバージョン表記。またnightlyからソースを引っ張ってきてしまったようだ… 進歩無いな。もう一度6.01のソースをとってくるところからやり直さなきゃ。
いろいろ情報を漁っていたところ、文字コードをUTF8にするオプションが有ることを発見。コントールパネルの「時計と地域」→「地域」→(管理タブ)と辿っていくとUnicode対応というチェックがあります。ベータと書いてあるのが気になりますが、デフォルトで用意されているのだからと、チェックを入れて再起動。再度vcpkgの作成に挑戦します。
その結果は大成功で、止まることなく進行していきます。嬉しいことにネイティブ環境なので、当たり前ですがVM環境下より早い。途中でlibiconvだったかがエラーになっていたのだけど、全体として停止せずに進んでいるので必要無いってことなんだろうか? これは後でどう影響するか気になります。まぁ実行する前にもう一度構築してみますかね。
さてVM環境下ではかなりの時間を要したvcpkgの構築、どの程度で終わるのか楽しみだ。
16:55追記
外出から戻ってきたら終わってました。所要時間は2.8hとのことですから2時間50分ほど。VMの時は7時間以上だったので大幅短縮です。buildもこの調子だと嬉しいな。
2月13日追記
vcpkgが更新されていたので、gitで取り直して更新。途中sqlite3の処理でエラーになったけど、再度実行したら止まることなく実行中。なんだったかな?
メインフィールドであるFedoraにRawideではありますが、正式に6.0が来たのでソースをチェック。いつもの所にお馴染みのnewstroke_font.cppを発見。ならばと早速ファイルを入れ替えてrebuild。結果は予想通りで、全部の文字を確認したわけではありませんが、ざっと見た範囲では幅の問題が解決しています。
と言うことは、Windows側でもまだRebuildはやる価値ありということで、再びがさごそ。
しかしMsys利用のWinbuilderは対応が5.12で止まっています。PKGBUILDの中身をいじれば良いのでしょうが、正規に提供していないということは何か問題があるんだろうと思わせます。
ならば丁度よいと思い英語環境のユーザーを追加してVisual Studio利用での作成に挑戦。
しかし、vcpkgの処理中にwxPythonの文字コード問題が発生してエラー停止。CP1251でも結果は一緒です。
普通に日本語環境で試した時と同じ結果で、使用言語を英語にしただけではベースの文字コードが変わらないので問題は解決しない模様なんだけど、全体の文字コードベースをUTF8にする方法が有るらしいので、いったんそちらを試してみますか。
それにしてもこのsh●tなパッケージを使い続けている理由が分からないなぁ。ベースのpythonでもV2からV3への移行で大問題が発生しているので個人的には関わりたくない言語です。とは言え人気が有り、高校の情報の授業でのプログラミングの題材として利用されていのをよく見かけますので、とっつきやすいんでしょうかね。
と言うわけで、またMSから英語版Windows11の開発環境イメージを落としてきてそちらの環境で試してみましょう。