カテゴリー: めも

クロスパーク勝沼に行ってきた話

kifuyu

　特に予定がなくなったGWの暮、大学の知人達がオフロードバイクで遊ぶというので同行してきました。
なお、2輪の免許は持ってないので見てる専もとい撮影オンリーです。

撮影機材はNikon D7200+Sigma 17-50mm/F2.8（35mmフルサイズ換算で25.5~75mm）のみ…。行っても帰ってからも望遠レンズ持っていけばと後悔。結局トリミングで誤魔化せたから難は逃れたけど…。

　
　遊び場はクロスパーク勝沼。近くには中央道勝沼ICがあり、アクセスしやすそうな立地。（どこ…？）
畑が立ち並ぶ細い道を経て林道へ。その先は鋪装があったりなかったりする道をゴリゴリ進みます。道中は前方車両がスタックしかけたりと、なかなかなもの。十数分揺られ続けて到着。駐車場は三つあり、この日は第1と第2駐車場が開放されていました。


　走り始め前の調整開始。2ストロークの場合はエンジンオイルをガソリンに混ぜるらしいです。（確かに燃焼サイクルからすれば潤滑油張るタイミングないよね…）
混合燃料を準備して、難儀する掛かりを調整した末に吐き出される白煙とそれに満足気な人。暖気を開始して駐車場に響くアイドル音。ピット場のような喧騒な雰囲気はないけど、こういう準備時間好きだなぁ。各々がセッティングのうんちくとか苦労話とかしてくれるからなおさら面白い。よくわからんけど。


　準備を終え受付へ。コースのオーナさんから「撮るだけですか？」と聞かれ、「沼(底のない趣味の世界にようこそ！)にはまるのでやめときます」と答える。一人あたり3000円の会計を済ませると、知人たちは林間コースへ消えていきました。



　コース内への立入りが禁止されていること、安全に近づける場所はあったかもしれないが、こういう施設には慣れていないため、後追いは避けて大人しくオフロードコース内を走るバイクを追いました。
モトクロスと呼ばれる競技らしく、跳んだり滑ったりと荒い荒い　(；´∀｀)


　今日の天気は悪いという話でしたが、予想を裏切るピーカン。F2.8開放、ISOは200、SSは1/2000~1/1000くらいで安定してました。絞りは2段階くらい上げても全然よかった。風がないため、土埃がいい感じに宙を舞う。
この日なんかはフルサイズ換算で70-200mmがあればちょうど良さそう（あれれ、70-200/F2.8がこちらをミている…）。大会規模であれば100mm~が必要そうかな？


　ほとんどバンク側で撮ってたけど、ザ・オフロードスポーツみたいな画が切り撮れたので満足。
何がいいって、カーブに合わせて土埃が弧を描き残し、速度回復のために吹かすから砂・土が余計に飛ぶんだよね。。走る側としては抑えたいのだろうけど、撮る側としては迫力があって面白かった(*‘ω‘ *)

P.S
2022/5/7 10~12時くらいに走行していた方（車体色：緑、青、赤、灰色の方？）へ
拙い撮影技術で恐縮ですが、走行中の写真を何枚か撮ったのでコメントでご連絡頂ければ写真のリンク先をお送りします。承認するまでコメントは公開されません。

Jupyterlabの起動に失敗する(2022/4/17起動した)

kifuyu

webスクレイピングがしたくてPythonの勉強を始めることにした。
実行環境はjupyter labと呼ばれるソフトがwindowsでも使えるクロスプラットフォーム仕様だと知り、さっそく環境を整え始めてみたところ下記のようなエラーが登場。。

Jupyter Server Initialization Failed
Error; Jupyter Server process terminated before the initialization completed

起動直後に”Jupyter Server Initialization Failed”なんていう画面が出る羽目に…。

Change environmentを触っても改善できないし、なんでだ？？


(2022/4/17追記) 結局原因は分からず、Jupyterlabの再インストールで解決したという全くもって間抜けな幕引きとなった。
当初、エラーの原因は”nativeWindowsOpen”なる関数の値かと思っていたが、調べてみると単にNot recommendedを警告してるに過ぎないことがわかった。
”The default of nativeWindowOpen is deprecated and will be changing from false to true in Electron 15.”

このあとに“Jupyter Server initialization message: Traceback (most recent call last)~”ってのが続き、最終的には”ImportError: DLL load failed while importing _ssl”として、DLLのインポートがうまくできなかったと表示される。画像の通り、肝心のDLL名あるいはその内容は文字化けしている。日本語環境由来のエラー？


でもローカルユーザ名はアルファベットにしているしなんでだろう…。あるとすれば、ユーザ名Public（パブリック）を2バイト文字で認識して読み込んでいるため、ファイルパスが読み取れていない？

…うーんよくわからん、、DLLも手動で入れたくない、、
ということでクリーンインストールに至り、結果として無事にJupyterが起動してしまった。。（インストール先はgeneralな場所じゃなくて、2バイト文字が含まれないpersonalな場所）

以下参照先、
・Jupyter Server Initialization Failed · Issue #381 · jupyterlab/jupyterlab-desktop · GitHub
・[Bug]: Webview is causing the warning “default of nativeWindowOpen is deprecated” · Issue #31784 · electron/electron · GitHub
・「Electron 14」が正式公開 ～次のバージョンからリリース間隔は12週間→8週間に – 窓の杜

WAN/LANのインバウンドが恐ろしく低下した話

kifuyu

自宅サーバはAsus H370 F gamingにwindows server 2019をインストールしています。最近、WAN側のインバウンド経路で通信速度が7~8Mbps(平時500mbpsを平気で出す）程度に留まってしまう現象に陥りました。

思い浮かぶ原因はルータやL2スイッチ、LANケーブルやNICの物理的故障、設定的なところ、VPNやプロキシを挟んでしまうなど挙げられます。しかし、今回どれを試しても状況は変わりません。

しまいにはWAN側だけでなく、LAN側 のインバウンドも超絶速度低下してしまいました。
現像PCから写真を１枚送ったらエクスプローラがフリーズするほどです…

 

トラブルシューティングを進めるにつれて、NICに原因があることはわかりました。
ただNIC自体の物理故障に直面したことは経験になく、もしも修理になるのであれば、１年のメーカー保証が切れてしまう前につくもへ駆け込む必要がありました。（昨年7/9購入）
引っ越し以来触っていないレシート箱をひっくり返し…

ところが物理故障の確信を持つためLinuxから確認してみると、問題なく速度がでます。
そこでようやくドライバが悪さしていることに気づきました(´・ω・`)

そもそもこのマザーボード。windows serverに対応していないのです（添付ドライバCD的な意味で）
なので組立時はいろいろな所からドライバをかき集めたのでした。
特にLANのドライバはwindows server の場合、少しコツが必要で「windoows server lan 無理やり」なんてやや卑猥なワードで調べると似たような事例がぽんぽん出てきます。
私の場合はこれすら面倒で、ドライバインストール時に汎用ドライバ一覧から近そうな名前のデバイスをインストールしたのでした…（Intel I219-Vに対してI219-LMをねじ込む）

 

今回もドライバを適当に当て直してみたところ、元通りの速度が出てくれたのでした。。。
というわけで、WANやLANの速度が恐ろしく低下してしまった場合は、ドライバの再インストールをしてみる必要ありますね。
結局正規ドライバいれずにいるけど、とりあえず動いてくれてるからいっかー、という状況(´ε｀；)

サーバ証明自動更新のエラー修正ほか

kifuyu

・エラー修正
サーバ証明の更新時にエラーメールが届く。
エラーは以下の通り

Attempting to renew cert (email.domain) from /etc/letsencrypt/renewal/email.domain.conf produced an unexpected error:
Problem binding to port 443: Could not bind to IPv4 or IPv6.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/email.domain/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)
完了しました。

letsencrypt導入時の設定が問題だった。certbot-auto renewal実行時にnginxが443ポートを使っているためエラーが生じていた。
認証方式をstandaloneからwebrootへ設定変更。/etc/letsencrypt/renewal/email.domain.confに以下を記述

#authenticator = standalone
authenticator = webroot
[[webroot_map]]
mail.domain = /usr/share/nginx/html

 

・本サイトのSSL化
諸事情で本サイトは SSL化せずにいた。wordpressのプラグイン修正で問題解決したためSSL化した。
調べればわかるが証明書発行は以下のコマンドでできる。

/usr/local/certbot/certbot-auto certonly --webroot -w /usr/share/nginx/html -d domain.name

リダイレクトの設定などはtsuchikazuさんという方のブログを参照

証明書を nginx へ設定

nginxの設定を変更してSSLを有効にしましょう。設定ファイルはこんな感じになります。

# httpはhttpsへリダイレクト
server {
  listen 80;
  server_name tsuchikazu.net;
  rewrite ^ https://$server_name$request_uri? permanent;
}
server {
    listen 443 ssl;

    server_name tsuchikazu.net;

    ssl_certificate /etc/letsencrypt/live/tsuchikazu.net/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/tsuchikazu.net/privkey.pem;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets on;
……

参照 Let’s Encryptの証明書をnginxに設定してhttps化した | tsuchikazu blog