繋がらない。
確かに自宅のサーバがおかしくなっていたので、再起動。
しかし、
# nslookup ssiscirine.moe.hm
;; connection timed out; no servers could be reached
ie-serverも落ちている様だ。
暫くは家内サーバ。
この画面は、簡易表示です
繋がらない。
確かに自宅のサーバがおかしくなっていたので、再起動。
しかし、
# nslookup ssiscirine.moe.hm
;; connection timed out; no servers could be reached
ie-serverも落ちている様だ。
暫くは家内サーバ。
https:// techacademy.jp/ magazine/ 39548
を参考にVisual Studio Codeからダウンロードして、インスト。
画面が英語ばかりなので、以下の拡張機能を追加。
ps.2024/2/1
バージョン: 1.86.0 (user setup) コミット: 05047486b6df5eb8d44b2ecd70ea3bdf775fd937 日付: 2024-01-31T10:28:19.990Z Electron: 27.2.3 Chromium: 26495564 Node.js: 118.0.5993.159 V8: 18.17.1 OS: 11.8.172.18-electron.0 Sandboxed: Windows_NT x64 10.0.22631 |
今は最初から日本語になっている。
型番のゴロが良いから買った。
店員が「9900Xですね?」と値段もTDPも高杉るCPUに誘導してくるけど、
焼肉するつもりはないので「いや、ノーマルで」と答えた。
※この暑い時期、TDP65Wでも電源入れっぱなしにすると部屋の温度は34℃まで上がるのでTDP165Wは避けた。
しかし、CPU-ZのCPUイメージはX-Series。このことを云いたかったのかな?
CPUクロックや温度はベンチ中は4.8GHz、45℃まで上がるけど、通常は3.1GHz、20℃台とヌルい設定。これはマザボ(ASUS PRIME H310I-PLUS)のAUTO設定のせいなんだろう。
ベンチ結果は子供に取られたi5-9400Fの性能の1.5倍、でも値段は3倍でコスパは悪いがHyper-VのクライアントOSの動きは良いから無問題。
CineBench(R20)の最中のCPU温度は42℃前後。
これでPentium Gold G5500でHyper-Vするよりはマシになったハズ。
後は起動メニューに出てこない事が多いM.2 SSD (128GB)をどうするかだなぁ。
※とりあえず、電源ケーブルを抜き差しするとブートできるので、リセットがかかりぱなしらしい。
ps.
ブート時にSSDがブートマネージャに表示されない事が多いので、買い替え。
QLCとTLCの区別が付かなかったので店員に聞いたら、スペック上はQLCの方が寿命が短い(らしい)ということなので、TLCのKingstonのSA2000M8/1000Gを購入。Kingston製なので、寿命は案分(×Kingston係数)して考えた方が良さそう。
外すと元に戻せなさそうなIntel A200NGWはマザボに刺したまま。
ぱぱっとWindows10インスト
設定のプライベート・ネットワークでファイル共有OKになっているのを確認したが、うまく共有できない。再インストしてもダメだった。何となくExploreの左の「ネットワーク」をクリックすると、Exploreになぜか「ファイル共有が有効ではありません」バーが表示される。
ここで【有効】に変えることで、やっとファイル共有が使える様になった。ここでハマるとリモートデスクトップも使えないから非常に困る。
Hyper-Vを入れ、仮想スイッチマネージャーで「新しいスイッチLAN」を作成。
これってLANをブリッジ接続に切り替えるものなので、リモートデスクトップ接続が切れ、再接続。
メインPCからHyper-VのクライアントOSイメージをエクスポートしてみる。
他のPCの共有フォルダにエクスポートさせようとしたら失敗。ネットドライブを割り当てたら、参照ダイアログにネットドライブが出ないので、ローカルなフォルダにエクスポート。
この辺で、ブートしにくい128GBのM.2SSDが転がっているのに気が付き、M.2 SATA型SSD用のUSBアダプターをポチる。
ps.USBアダプターに動作が怪しいSSDを組み込んだ。
i7-3770のUSB3に繋ぐと、ドライブのアイコンが出たり消えたりを繰り返す。
壊れてるのかな?
i7-3770のUSB2に繋ぐとちゃんと動作する。
i9-9900のUSB3に繋ぐとちゃんと動作する。
どうやら、このUSBアダプターはしっかりと電力を供給できないUSB3では動作できないようだ。残念だが出先のPCでは動作できない気がする。
ps.WOL(Wake-on-Lan)
Windows10のソフトWOLではなくハードウェアWOLの方。
1.まず単純にデバイスマネージャのLANの設定でWONをONしようとしたが、
「電源の管理」タグが無かったので、ASUSからマザボ用のLANドライバをダウンロードしインストしなおした。
2.ASUS PRIME H310L-PLUSのUEFIの「APM」で
「PCIEによる電源ON」を「Enabled」にした。
しかし、これだけではダメで、
「ErP Ready」も「有効(S4+S5)」に変更した。
3.Vectorで見つけたWolアプリ「Wake up On Lan Tool」を使用し、
起動したPCで「このPC(AUTO)」で拾ってくる内容で、
別のPCから起動した。
IPv6のIPアドレスを拾ってしまうがコレでは起動できず、
IPv4に書き換えたところ無事起動できた。
ThermaltakeのM1の上蓋が壊れてたのでCore V1に変更。巨大なケースファンを一旦外し、ケース前面にファンを吸気に変更した簡易水冷を取り付け、ケースファンを戻す。
その際にWIFIアンテナのコネクタからリード線が外れた。コネクタの穴が小さくて半田ごての先が届かないから買いなおすしかないなぁ。
電源が350Wなのでちょっと心配だけど、GeForce750Ti(TDP60W)でFF-XIVベンチを完走したから大丈夫かもしれない。スコアが5000と低かったせいかベンチ中も熱くならない。
HDDは縦置きに変わったので寿命は短くなるかもしれない。
なんでも宇宙はできてすぐインフレしたらしい。
真空がエネルギーの高い状態から低い状態に相転移した際に、一気に膨張したそうな。真空の相転移とは、真空で作用する力場が変わったという事だろう。
当初の力場は、電磁気力、強い相互作用、弱い相互作用、重力は混ぜ混ぜ状態で、重力が一足速めに分離されたそうだから、主に重力が分家したせいでインフレしたんだろう。
そうならば、極小の始祖宇宙のエネルギーの揺らぎから宇宙の中心に回転しない点ブラックホールが偶然出来、その点ブラックホールの極小な表面に沿って極小真空の空間が平たく引き延ばされ、重力が宇宙から離脱し、宇宙自体は重力から解放されたのだろう。
背は曲がっているが、私の心は真っ直ぐである。
ゲームの中で劉塘が呟くセリフ。原典は不明。
ともあれ、その後、ブラックホール表面の近くで宇宙の最初の物質と反物質の対(どんな物質対かはこの際どうでもいい)がふらつき、うっかり、時空の境界線の越えて、点ブラックホールに反物質が落ち込み、宇宙へは物質が吐き出される。
無限小の真空と点ブラックホールによる無限大の時間遅延というその後に起こることは無い異常な状況下で現象が同じ方向に偏った現象のループが発生し次々にコピーされる。※宇宙へは物質が、ブラックホールへは反物質が×∞。
宇宙の中心であった座標に点ブラックホール、そして宇宙はその表面を覆う球面状の物質の皮。その皮もブラックホールに無限の時間をかけて回転しながら落ちていくが、先の現象のコピー速度が圧倒的に速いため、次第に分厚くなっていく。限界まで分厚くなれば自然とブラックホールになる。
結果、真空だけど物質性が高く故に回転してしまっている宇宙、物質で出来た回転するブラックホール、反物質で出来ているが点なので回転できないブラックホールの3構造となる。
宇宙自体が極小サイズとは云え、高いエネルギーの真空状態であり、また宇宙の内側にとんでもない超エネルギーの反応弾を抱えている様なものだ。
これなら、いずれ、光速度の制限を無視して宇宙がインフレしても支障は無いだろう。勿論、宇宙自体も只では済まず、ズタボロに引き裂かれ、今の立体網状態になっているのも十分に理解できる。また、宇宙が球体の表面(2次元状)だったから、宇宙の膨張が一様なものになったのだ。
但し、このモデルでは宇宙は物理的に球面状で、認識はできなくとも宇宙に表と裏は存在することになるが、極小サイズ下で膨張しながらズタボロに引き裂かれ、メチャクチャにされ、上下左右の区別が付かなくなっている可能性が高い。つまり、今、この宇宙と認識している空間は、パンクで破裂したタイヤの小さな断片(あるいは粉状の何か)の様なものだと考える。
また現在の重力は他の力場に比べ、到達距離は宇宙サイズと断トツだが、その力は地球の引力を小さな磁石で引き離せるくらいとても弱い。それも宇宙の中心にあった点ブラックホールから百数十億年が経て原初の重力源から遠く離れてしまったせいかもしれない。
こう考えると、
無の空間で釘を踏んでパンクしたタイヤの断片
それが宇宙
の様だ。
そうなると、物質の質量と重量は比例関係にあるが、数億年経つと、重力係数に変化が現れるかもしれない。
とっくに時計の針の進み方は場所によってバラバラだと判っているし・・・
何かのはずみで光速不変の法則も定説から外されるのかな?
実際、真空、大気中、水中、ガラスの中、いづれも外部から観測される光速度が異なるので、これらの境界線で屈折してるハズだもんね。
そもそも、真空中の光速度ってちゃんと測定できてるんだろうか?
また、理論値とかじゃなかろうか?(結構、コレで騙されてるからなぁ 爆
またアップグレードの催促があったので、【アップグレード】ボタンを押した。
なぜ、自動アップグレードしない。?
$nslookup {このサーバーのお名前}
するとグローバルなIPアドレスしか出てこない。
そりゃ無理です。
そのせいか?
編集画面・左上のW印の「記事一覧を表示」をクリックすると、WordPressの案内ページにジャンプするのでとても使いにくい。
ルータにループバックさせればいいけど、ルータ調整中に無限ループするとかなり面倒な事になるので、
127.0.0.1 {このサーバーのお名前}
にした。
これで自動的にアップグレードやバックアップが動くはず。
ついでに、dnf updateしたら、Listen 443 設定が被っているので停止になった。
あれこれ調べたら、/etc/conf.d/ssl.conf を消して、vhost.confの名前でVirtualHostの設定をしていたから、Updateで自動的に/etc/conf.d/ssl.confが復元されていたせいだった。消したのでOK。
$ httpd -t
Syntax OK
ついでにSELINUXもtargetedになっていたので、disableに直した。
まだ変だな?
AM/PM表記を、24時間表記に変更。
カレンダーの週の初めが月曜になっているので日曜に変更。
php 7.2 では古いらしい。
# dnf -y install https://rpms.remirepo.net/enterprise/remi-release-8.rpm
# # dnf module list php
最速のミラーを確定しています (41 hosts).. done. --- B/s | 0 B --:-- ETA
Remi's Modular repository for Enterprise Linux 182 kB/s | 576 kB 00:03
Safe Remi's RPM repository for Enterprise Linux 1.5 MB/s | 1.5 MB 00:01
CentOS-8 - AppStream
Name Stream Profiles Summary
php 7.2 [d][e] common [d], devel, minimal PHP scripting language
php 7.3 common [d], devel, minimal PHP scripting language
Remi's Modular repository for Enterprise Linux 8 - x86_64
Name Stream Profiles Summary
php remi-7.2 common [d], devel, minimal PHP scripting language
php remi-7.3 common [d], devel, minimal PHP scripting language
php remi-7.4 common [d], devel, minimal PHP scripting language
ヒント: [d]efault, [e]nabled, [x]disabled, [i]nstalled
# dnf module reset php
# dnf module install php:remi-7.4
# php -v
PHP 7.4.9 (cli) (built: Aug 4 2020 08:28:13) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.9, Copyright (c), by Zend Technologies
tarコマンドが使えない?
# dnf install tar
警告 オプションのモジュール imagick がインストールされていないか、無効化されています。
警告 オプションのモジュール zip がインストールされていないか、無効化されています。
# dnf install php-imagick
ImageMagick-libs-6.9.10.86-1.el8.x86_64
php-pecl-imagick-3.4.4-10.el8.remi.7.4.x86_64
他多数。
# dnf install php-zip
libzip-1.7.3-1.el8.remi.x86_64 php-pecl-zip-1.19.0-1.el8.remi.7.4.x86_64
残るはあと2つ
テーマはサイトのデザインを決定します。ブランドの一貫性とサイトの安全性の維持のため、常に更新することが重要です。
サイトのインストール済みテーマ5個はすべて最新版です。
サイトには WordPress のデフォルトテーマ Twenty Twenty と現在有効なテーマ Enough を除いて、3個の停止中のテーマがあります。 サイトのセキュリティ向上のため未使用のテーマは削除することをおすすめします。
※無視。パス!
予約したイベント inpsyde_phone-home_checkin の実行に失敗しました。サイトは動作しますが、予約した投稿や自動更新は正しく動作しないかもしれません。
※5.4.1の頃から原因不明らしい。
新型コロナをただの風邪とするデモがあった様なので、ググってみると、
発熱したり、セキをしたり症状は似ているし、「ただの風邪も肺炎を発病するウイルスが原因だったりすることもある様で、「ただの風邪」と新型コロナは素人目には区別は付きにくい。
ともあれ、自然免疫で防げない量(個人差有)の新型コロナを浴び、早々に獲得免疫を得られなければ、本当の病気になるハズだから、インフルパーティみたいなことをやって「ただの風邪」と証明でもしたのかな?と思ったら、
「新型コロナをただの風邪」と触れ回っているだけだった。
それで済めば、医者なんて要らないんだけどなぁ。
「ただの風邪」だと思って病院行って診てもらうと、医者が病気になって、その医者を診た医者も・・・とドミノ倒しになって病状を診る医者がいなくなったりそうだから、困って見よう見まねで対策中ってとこ。
これは「ただの風邪」では無い客観的な証拠じゃないのかな?
特効薬が開発された暁には
昔はどうだったのか知らんけど、
これは希望的憶測に基づく未来のお話。
PCR検査が陽性でも
「ただの風邪ですね。」
と医者に診断され薬局でお薬貰っただけだよ。
※故に、この引用元のリンクは実在しない。
となるんだろうけどね。
そして、今はとっても暑い、
暑いから「地球温暖化は正義」と簡単に思うのは早とちり。
太陽の黒点減少で放射熱総量が減少して10余年。
しかし、プチ氷河期はまだ来ない。
単にハズれならいいいが、外からの熱量が減った反動で南の海に溜め込んだ熱量(CO2も一緒に)を放出し、梅雨が明けると、いつもより暑苦しいくなっている気がする。
暫くはそれでもいいけど、とりあえず、熱放出が収まると、今度は冷え冷えになるので、困るな。困ったな。
と、ならないことを期待しよう。
地球の平均気温が40度ぐらいになっても、まだ生きていられると思うけど、
プチ氷河期が来たら、逃げ場は無いかもしれないからね。
MDBファイルのテーブルをMySQLにエクスポートしてみると、テーブルの構成に色々と問題が出てくる。
特にNULLを許可するかどうかが一番の問題。
作ったプログラムが許容できなかった場合を考慮して、フィールドが Not NULLだったり、初期値を設定してあれば、それと取り込んでALTER TABLEすれば大体問題は解消。
AutoNumberもNIQUE KEY扱いしてAUTO_INCRIMENT属性を付ければ何とかなる。
[MySQL]ODBC接続でフィールドの番号を振り直してみる
しかし、それでは気が付かないモノもあった。
Bit型のフィールドだ。
MS-ACCESSではYes/NoのフィールドがBit型(長さ1)のフィールドに変換されるがNULLはOKとなっている。でも大丈夫かと思ったら、そうでは無かった。
MS-ACCESSの連携フィールドではチェックマークになる。
このフィールドがある場合に「*」でレコードを追加する際に先のチェックを入れないと、何故かBit型のフィールドに NULL が入ってしまう。
それでも、MS-ACCESS上で支障がなければいいが、そうなっていない。
ビューの上では追加した行にDELETEマークが並ぶ。ビューを最新表示すれば消えるが、その行を編集や削除をすると、
と、いつもの頓珍漢なメッセージが出てしまい、何が原因か全く判らない状況に陥ってしまう。しかし、サーバやPCを再起動しても、リンクテーブルのビューでも編集や削除をすると、同じメッセージが出るので、
MSーACCESSが何かトチったことが判る。
PHPMySQLでBit型がNULLになっているとこを0に変えると問題は解消される。
つまり、INSERTで設定した(つもりの)値と違う内容がレコードに入っていたので、誰かが書き換えたに決まっている!とMS-ACCESSは判断をしたらしい。
実際にはINSERT時はBitフィールド型が未設定の様だ。それをやっちまっているのはMS-ACCESSなのかMySQLのODBCドライバなのかは判らないケドね。
SELECT * FROM テーブル名 WHERE Bitフィールド名 IS NULL;
なレコードをポチポチ直すものいいけど、
UPDATE テーブル名 SET Bitフィールド名 = 0 WHERE Bitフィールド名 IS NULL;
で焼き尽くしても、どうせ、すぐに増えるから・・・直ぐに!
ALTER TABLE テーブル名 CHANGE Bitフィールド名 Bitフィールド名 BIT( 1 ) NOT NULL DEFAULT b'0';
と、BitフィールドでNULLを禁止し、初期値も0にした方がいいだろう。
※bit(2)とかbit(3)に変換されるフィールドもあるのかもしれない。(ケド
一応、
SELECT table_schema, table_name, column_name FROM information_schema.columns WHERE data_type = 'bit';
で見ると、bitフィールドが意外にいっぱいあったりする。
エクスポートする際は、bitフィールド型も要注意。(ダナ
SET sql_mode='PIPES_AS_CONCAT'; select 'UPDATE `' || table_schema || '`.`' || table_name || '` SET `' || column_name || '` = 0 WHERE `' || column_name || '` IS NULL;',
'ALTER TABLE `' || table_schema || '`.`' || table_name || '` CHANGE `' || column_name || '` `' || column_name || '` BIT(' || NUMERIC_PRECISION || ') NOT NULL DEFAULT b''0'';'
FROM information_schema.columns WHERE data_type = 'bit';
これを実行すると全データベースのBitフィールドをサッパリにするSQLを吐き出す。ALTER TABLEは1行づつ整合性チェックが入るみたいなのでレコード数が多いと結構時間がかかる。(ッヨ!
※SETはconcatを使うとミスが見つけにくいので、 || を使ったから。
※UPDATEしてるのは、NULLデータがあるとALTER TABLEでNOT NULLが整合性エラーで弾かれるから。
さて、絶対安全?MS-ACCESSからMySQLへのエクスポートのVBAに手を入れなければ・・・
MS-Office 365をインストールすると32bit版か64bit版のどっちが入るのか?
どうやら32bit版のOfficeをインストール済みのPCにインストすると32bitになり、Officeが入っていない64bit版のWindowsでは64bit版が自動的に入るようだ。
32か64か?の確認は、ファイル⇒アカウント⇒***のバージョンの「ボタン」を押すと、ダイアログの上の右あたりに ***ビットって書いてある。
とりあえず、メインPCは古いバージョンから使い続けているので32bit、サブPCにインストしたら64bitになった。
そうなると、VBAからのWindowsのAPIの呼び方が変わるので
Public Declare PtrSafe Sub SubName Lib "LibName" Alias "AliasName" (argument list)
にしないといけないが、32bit版だと ptrSafe は未定義なので
#if WIN64 then
Public Declare PtrSafe Sub SubName Lib "LibName" Alias "AliasName" (argument list)
#else
Public Declare Sub SubName Lib "LibName" Alias "AliasName" (argument list)
#endif
とコンパイル・オプションで切り替えが必要。
ODBCでデータベースに繋いでいると、更に面倒なことになる。
32bit版のWindows10は今まで通りで、
1.データベースのODBCドライバを32bit版をインストして、
2.C:\Windows\System32\dbcconf.exeで登録するBATファイルを作る。
しかし、64bit版のWindows10は、ODBCが32と64の両方ある。Officeが32bit版ならODBCも32bit版、64bit版ならODBCも64bit版になるようだから、どっちに転がるか判ったものではないので、
1.データベースのODBCドライバを32と64bitの両方をインスト。
2.C:\Windows\System32\odbcconf.exeで登録するBATファイルを作る。
3.2のBATファイルのSystem32をSysWOW64したODBC-32bit専用を作る。
4.とりあえず、2と3の両方を管理者モードで実行しておく。
細かい事だけど、
C:\Windows\System32\odbcconf.exeがメモリに残骸として残っている間は、
C:\Windows\SysWOW64\odbcconf.exeと指定しても、
System32の方が動いてしまう情けないシロモノなので、
cd C:\Windows\SysWOW64 と
odbcconf.exe xxxx に分けた方がいい。
※パスが通っている逆もしかり。
データソース名は32bitと64bitで重複しても気にならない様なので、こうしておけば、メインPCのOfficeが急に64ビット版に変わってもなんとかなるだろう。
ちょっと変な気がするけど、SysWOW64は、64bitのWindowsで32bitのEXEを実行するためのモノが入っているので、ここのdbcconf.exeを使うと、32ビット用のODBCの設定をやってくれる。
参考:WikepediaのWOW64
いづれ、メインPCがクラッシュすれば、32bit版は消滅するハズだ。
しかし、これがエンタープライズなWindows環境なら、いくら新PCであっても、32bit版が100年くらい生きながらえる可能性は高い。
サーバで、foreverをグローバルでインストールしコマンドラインから使える様にする。
$ npm install forever -g
$ forever --version
v3.0.0
デバッグの準備
$ cd {node.jsアプリのフォルダ}
$ forever -c 'node --inspect=0.0.0.0:9229' app.js
warn: --minUptime not set. Defaulting to: 1000ms
warn: --spinSleepTime not set. Your script will exit if it does not stay up for at least 1000ms
Debugger listening on ws://0.0.0.0:9229/ad7164d6-5cb7-43bb-9585-7c95c6d24e28
For help, see: https://nodejs.org/en/docs/inspector
アプリがlisenに成功したら標準出力に
app listening on port http://{サーバー名}:{ポート} !
と表示させると便利。
Visual Studio Code の方の「実行」⇒「構成の追加」から
{} Node.js :Attach to remote program を選択し
lanuch.jsに追加されたブロックに
”address”: {サーバ名}
”port”: 9229
と編集して、【実行】すると、
(node:22749) [INSPECTOR_ASYNC_STACK_TRACES_NOT_AVAILABLE] Warning: Warning: Async stack traces in debugger are not available on 32bit platforms. The feature is disabled.
と出てくるので、lanuch.jsのAttach to remote programに設定を追加。
"showAsyncStacks": false
適当にソースでブレークポイントも追加しても〇になるので無効。
しかし、アプリの出力はサーバーのコンソールとデバッグコンソールの両方に表示され、VSCから再起動も出来る。
デバッグコンソールに何故かconsole.logしたソースのリンクが貼ってある。
これをクリックするとデバッグ中のプロセスと連携しているソースが表示されるので、ブレークポイントを設定できる。
しかし、次にその場所に来た場合に一時停止になる仕組みなので、
事前にブレークポイントを設定して実行!という訳にはいかないが、大抵のことはコレで十分だろう。
VSCからまだコミットが出来ないので git push も変だ。
OpenSSH Authentication Agent
を自動起動
> ssh-agent
> ssh-add
Enter passphrase for C:\Users\***/.ssh/id_rsa: {パスワード}
Identity added: C:\Users\***/.ssh/id_rsa (***@********)
まですると、コマンドラインからは git pushできる。
VSCは待機中になってしまう。
インストールしてみた。
$ sudo apt-get install git-all
$ git --version
git version 2.1.4
$ git config --global user.name "xxxx yyy zzzzzzz"
$ git config --global user.email xxxx@yyyy.zzz
$ git config --list
user.name=xxxx yyy zzzzzzz
user.email=xxxx@yyyy.zzz
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
$ mkdir /home/*****/www.git
$ cd /home/*****/www.git
$ git init --bare --shared
作業フォルダを作り、ベアと連携
$ mkdir <ソースのプロジェクトのフォルダ>
$ cd <ソースのプロジェクトのフォルダ>
$ git init
Initialized empty Git repository in /home/*****/*****/.git/
$ git clone /home/*****/www.git
コードを入れ、管理対象を追加。
$ git add *
$ git commit -m 'init'
いっぱい流れる
コピってみる。
$ mkdir /home/*****/test
$ cd /home/*****/aaa
$ git clone /home/*****/www.git
WindowsのPCにもコピってみる。
Git-2.27.0-64-bit.exeを初期設定で【Next >】ボタンを押してインストールすると何故か?コマンドラインから使えないので、コンポーネントは全振りにする。
適当なフォルダを作って、cloneすると
C:\適当なフォルダ>git clone {ユーザ名}@{ホスト名}:{ベアなリポジトリィのフルパス}
Cloning into 'www'...
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:*********************************************.
Please contact your system administrator.
Add correct host key in /c/Users/****/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /c/Users/****/.ssh/known_hosts:1
ECDSA host key for {ホスト名} has changed and you have requested strict checking.
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
(;゚Д゚)オレシラナイ と云うので観なかったことにする。
ssh-keygen -R {ホスト名}
C:\適当なフォルダ>git clone {ユーザ名}@{ホスト名}:{ベアなリポジトリィのフルパス}
Cloning into 'www'...
The authenticity of host '{ホスト名} ({ホスト名})' can't be established.
ECDSA key fingerprint is SHA256:*********************************************.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '{ホスト名}' (ECDSA) to the list of known hosts.
{ユーザ名}@{ホスト名}'s password:{パスワードを入れる}
remote: Counting objects: 2148, done.
remote: Compressing objects: 100% (1663/1663), done.
remote: Total 2148 (delta 376), reused 2148 (delta 376)
Receiving objects: 100% (2148/2148), 20.27 MiB | 39.77 MiB/s, done.
Resolving deltas: 100% (376/376), done.
Updating files: 100% (2611/2611), done.
見てみると
C:\適当なフォルダ>dir
ドライブ C のボリューム ラベルは ボリューム です
ボリューム シリアル番号は ****-**** です
C:\適当なフォルダ> のディレクトリ
2020/07/28 11:00 <DIR> .
2020/07/28 11:00 <DIR> ..
2020/07/28 11:01 <DIR> www
0 個のファイル 0 バイト
3 個のディレクトリ 568,894,787,584 バイトの空き領域
なぜか、www フォルダが出来、その中にソースが入っている。
とりあえず、サーバにあるNode.jsのアプリのソースをVisual Studio Codeで
デバッグする準備が出来た。
あ、SJISのファイルが、コンバートしたので、アップしてみる。
$ git commit -m 'memo utf8' -a
$ git push -u origin master
Windowsに取り込む
C:\適当なフォルダ> git pull
{ユーザ名}@{ホスト名}'s password:{パスワードを入れる}
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (3/3), 645 bytes | 1024 bytes/s, done.
From {ホスト名}:/home/****/www
5016d20..c2a658f master -> origin/master
Updating 5016d20..c2a658f
Fast-forward
"\343\203\241\343\203\242.txt" | 42 +++++++++++++++++++++---------------------
1 file changed, 21 insertions(+), 21 deletions(-)
ps. Visual Studio Code でGithubみたいに画面のボタンからgit push したい場合。
面倒だけど、方法はあった。
以下、参考にした記事。
gitのリモートプライベートリポジトリを公開鍵認証を使って環境構築する
この記事の通りにやればいいはず。
諸所の事情によりサブシステムをまともに使えないメインPCはこうなった。
多分、これでOKなハズ。
これで、sshコマンドもパスワード無しでログインできてお手軽だが、sudoする時は時々パスワードを入力しないといけない。
しかし手元のTeraTermは無関係で、しかもこれは認証情報を一切覚えられないので、起動の度に秘密鍵を指定するか、設定を保存し起動の度に「設定ファイル読み込み(R)」をするかの2択しかない。
とりあえず、この方法を試した後は必要な時だけSSHサービスを開けるか、
~/.ssh/authorized_keysを別の名前にしておく必要があるね。