2021-11-18

  今更だが、自宅に光インターネットサービスが開通した。ADSLを酷使していたのだが2021年9月末で遂にサービス終了のため、維持費が高くなるが仕方がない。

 今回、プロバイダ経由で屋内に光ファイバ敷設したが、敷設不可という珍しい体験をしたのでblog化。


 自宅は築40年の賃貸マンションで、元々は5-6Fに大家が居住、10年程前に1-4Fが事務所だったのを順次居住用に内装を変更している。室内は綺麗であり、電話線のモジュラーは居室A、食堂Bに設置されていた。光配線は敷設されていなかったが、MDFを開けてみたところ建物自体にファイバーは引込み済であり、光スプリッタ設置済で他のフロアへ配線済であった。また入居時に光ファイバ対応済の説明も受けていた。


 屋内の電話線はMDF-食堂B-居室Aの順で配線されていた。

 ONUは居室Aへ設置するので、工事会社は居室Aから食堂Bへガイドワイヤを通線したところ、こちらはOK。次に食堂BからMDFへガイドワイヤを入れるが、MDFへ出てこない。何と洗面所の洗濯機Cの裏辺りからガイドワイヤがぶつかっている様な音がする。


 どうも、内装工事をした時、洗濯機Cの場所にあった埋め込みモジュラーボックスを「洗濯機の裏だから使わないだろう」と内装壁で塞いでしまっている様である。モジュラーボックス内で電話配線を繋いでいるので、アナログ電話やADSLでは問題がないのだがメンテナンスをどうする気だったのだろうか?

 つまり屋内配線はMDF-洗濯機C(壁内)-食堂B-居室Aとなっていたのである。


 賃貸管理会社の不動産屋へ連絡。この不動産屋はビルなどの施工もしているのだが、賃貸部門の担当者は電設やインターネットは素人なのである。通線できるようにする対応はプロバイダだと思っていたりする。やれやれ。

 家主(元々このビルの5-6Fに住居していたが転居してしまっている)に連絡してくれたのだが、「MDFから共用部分の壁を伝って、共用部分から屋内へ穴を開けて光ファイバーを通せば良い。その工事費は大家が負担する」という凄い提案が。

 いや、躯体をコア抜きするのはマズイでしょと思うのだが、先ずは不動産屋が呼んだ電設屋と下見。流石に電設屋はプロだった様で、玄関上の40cm近い厚みの柱のコア抜きより洗濯機Cの内装壁を一部開口してメクラ葢(これって差別用語になるの?)を新設という常識的な工法が安いですよ、と不動産屋に説明してくれた。

 その後、不動産屋が家主をいろいろ説得。やっと工事OKとなって先程の電設屋が内装壁を開口とメクラ蓋新設してくれた。


 再度工事依頼をしたところ、今度は無事屋内配線敷設完了。工事会社に質問したところ「あまりこういうケースは無いですね」との事であった。

 今、光インターネット接続サービス経由でblogを書き込みの次第。

 

2021-08-12

 不祥事おかわり!

 とばかりにSBIソーシャルレンディングから連絡あり。取り敢えず手元の投資分には影響がないという追記はありましたが、8/10時点でこれですか。

 

 ---

各位

SBIソーシャルレンディング株式会社

貸付先の懸案事項として対処すべき事案について

 当社は、先般のソーシャルレンディング貸付先の重大な懸案事項に関して、金融商品取引法第39条第3項に基づき金融当局の確認を受け、投資家の皆様に対して未償還元本相当額の償還を開始しております。また、2021年6月8日付の業務改善命令にもとづき、7月7日には再発防止策等その対応に係る業務改善報告書を提出し、受理されております。
 こうした取り組みとともに、当社では、これまでに募集したファンド全件について、業務改善命令にもとづき、取得勧誘の状況等について網羅的に検証を行い、業務運営上の問題点の究明に努めてまいりました。
 しかしながら、上記各種対応の完了を目前とするなかで、誠に遺憾ではございますが、あらたに、先般の事案とは異なり規模は大きくないものの、同種の貸付先の資金使途違反の発生を確認いたしましたのでお知らせいたします。

 本事案について、当社ではすでに調査委員会を設置し、法令違反に該当する行為の有無をはじめ、事実関係の調査および原因究明に着手するとともに、当局への報告もあわせて行っております。最終的には調査委員会の調査結果を踏まえて改めて判断いたしますが、本事案についても、投資家の皆様への未償還元本相当額の償還に向けた取り組みを進めてまいりたいと考えております。

 投資家の皆様をはじめ関係者の皆様には、多大なるご迷惑とご心配をおかけしますことを深くお詫び申し上げます。

以上

2021-04-22

  docomo回線解約後、SIMロック解除をする際に2段階認証用のメールアドレスが登録できない事象の対応記録。

 

 docomo回線を契約するとMyDocomoのアカウント(dアカウント)が割当られ、このアカウントで購入した端末のSIMロックを解除できる。

 当方親族で以下1),2)前提でSIMロック解除を試行したところ、3)で必ず失敗する事象発声。

 

1)docomo回線を解約

2)MyDocomoの2段階認証用のメールアドレス未登録

 

3)2段階認証用のメールアドレスを登録するため、 解約したdocomo android端末(sharp製)でアプリからメールアドレス登録を試行するが、登録できない。

アプリでメールアドレスを登録操作すると、登録希望のメールアドレスへセキュリティコードは届くが、これを入力してもエラーになり、登録できない。

 

 仕方がないので、以下の手順で対応した。

4)ドコモショップ店頭でメールアドレス登録を依頼したがドコモショップでも登録できず


5)ドコモショップで新規dアカウントを作成

6)新規dアカウントへアプリから2段階認証用のメールアドレスを登録

7)新規dアカウントでMyDoCoMoから解約済docomo端末のSIMロック解除


 アプリの操作ミスであれば4)は成功しそうなのだが。これはdocomo端末アプリではなく別途社内のオンライン端末でメールアドレスを登録する様なので。

 

 兎に角謎が多いのだが、この情報が役立つことを。


(参考)

dアカウント設定アプリのセキュリティ強化のため、アプリからの連絡先メールアドレスの追加・変更機能を一時削除しております。

なお、現在登録されているメールアドレスが正常にご利用可能な場合は問題ございません。

※2021年3月31日(予定)のアプリアップデートにより機能提供を再開します。
(2021/2/26追記)

セキュリティコードが受信できずアプリやWebから連絡先メールアドレスが変更できない方は、以下をご確認いただきドコモショップで手続きをお願いします。

2021-03-02

  一寸悩んだので備忘録。

 

 VMware ESXi 6.7以降をHP製UPSで保護する場合の遮断方法。

  HP製UPS&Network Management Cardの環境ではUPSとHPEPPとが通信を行い、商用電源断に遷移した時に、指定コマンドを実行可能である。

 この時、指定コマンドとして、ESXi shellに対して、POWEROFFを指示すれば良い。

 sshで接続する際に初回はfingerprintの確認が発生するのでHP手順書では一度sshで接続しろ、とある。 しかしながら、この時のユーザは何で実行するのか不明である。

 HPEPPをインストールしたホストとユーザでssh接続するとESXiを正常に遮断できる。しかし、HPEPPから同一コマンドを実行させてもauth.logを確認すると接続が途中で切れている様である。

 サポートにHPEPPはESXi 7.0に非対応等と回答して、質問しても不明瞭なので、


ssh -o 'StrictHostKeyChecking no'

 

 の様に明示的にfingerprint確認を省略させると正常に動作した。

 

VMware ESXi Server 6.7 以降と組み合わせたHPE PP の使用
HPE PP のインストールが完了したら、以下の手順に従ってHPE PP を使用します。
手順
1. Linux 仮想マシン(Debian)をESXi の下に展開します。
2. Open VM Tools をLinux 仮想マシン上に展開します。
3. sshpass ソフトウェアをインストールして(apt-get install sshpass)、SSH デーモンが実行されていることを確認してください。
4. ESXi でSSH コマンドを有効にします。
5. Linux 仮想マシンのターミナルからSSH を使用してESXi に接続します。この手順は、Linux 仮想マシンとVMWare ホスト間の接続証明書を取得するために必須です
6. SSH 接続を終了して、Linux シェルに戻ります。
7. Linux 仮想マシンにHPE PP をインストールし、電源の設定を行います。
8. [設定] メニュー > [シャットダウンパラメーター] > [構成を編集]に移動します。
9. シャットダウン構成の編集を選択して、シャットダウンのタイプをスクリプトに設定し、シャットダウンスクリプトのフィールドに次の情報を入力します。
sshpass -p 'password' ssh root@ESXi_IP_address poweroff

2020-11-25

  各所に記載されていますがWindows 10 1909で内蔵日本語キーボードと外付け英語キーボードとを併用するときの諸設定。

  まずToday's nonsense紹介されている手法を試したところ、 プランAは目的の動作をしなかった。内蔵、外付け共に日本語キーボードとして認識された。

 プランBの通り、言語設定のキーボードはPC101、内蔵キーボードは日本語キーボード、特定のHIDを英語キーボードとして

OverrideKeyboardType:4(0x00000004)

OverrideKeyboardSubtype:0(0x00000000)

 を設定したところ、目的の動作となった。


 しかしながら、1点問題がある。

  RDP接続後、接続先のOS上で内蔵キーボードが英語キーボードとして動作してしまう。例えば「Shift + 2」を打鍵すると「@」が入力される。

 よく観察すると、完全に英語キーボードとして動作している様なので、概ね以下の様な対応となっている。幸いながら日本語キーボードは英語キーボードより鍵数があるので、機能しないキーがあるものの、入力は一式可能な様である。

 

「む」→「\」

「@」→「[」

「[」→「]」

「円」→機能せず

「ろ バックスラッシュ」→機能せず 


 なお、以前使用していた環境(2016頃のLTSB)ではRDP問題がなった気がするので、1909以降で発生していると思われる。

2020-11-12

 pacman -Syu --disable-download-timeout

2020-10-26

 最近は在宅勤務なので証券取引場が開いている時間帯に自宅に居ます。

 9月のある日、居間から奇声が。「イナゴ来てくれー」


 「イナゴが何故居間に?」


 どうも株主優待評論家の桐谷さんお勧め銘柄であるヤーマンで良い材料があり、株価が上昇しており、株主である嫁様が売り抜けようとしていたのでした。


 「やった!イナゴに売りつけた!」





 実際に売り抜けた日が最高値であり、長期保有の筆者と異なり嫁様の方が株が上手なのかも知れない。

自己紹介

自分の写真
東京都, Japan
憂鬱な凍死家です。こちらではmixiとは異なり固めの話題中心です。

Total Page View

Categories

Powered by Blogger.

Popular Posts

Blog Archive