ASP.NET 練習帳

国内の ASP.NET サーバーに関して

指輪がね、不要になったから処分しようと思ったの。

Q&A | 一般社団法人日本ジュエリー協会

なお、古くなったり不要の貴金属はお店によっては、地金として相場価格で買い取るか、商品お買い上げのときに下取りをしてくれますので、お尋ね下さい。


2019/1/15 の昼休みに、ミキモトに電話して尋ねてみたよ。

お問い合わせ|カスタマーサービス|MIKIMOTO - ミキモト

買取はしていないって。
残念!

時系列を整理するとこんな感じ。

2018/12/1 に互いに購入した。
2018/12/24 の 15 時頃に商品を受け取って、二人ともその場で身に着けた。
2019/1/4 の朝 7 時、電話で婚約破棄を言い渡される。

身に着けたのは 12/24 だけ!
溶かす・溶けたってギャンブルの用語があるらしいけど、まさにそんな感じだよね。

OpenSSH in Windows | Microsoft Docs に記載の OpenSSH を試してみた。
リモートは Windows 10 1809 と Windows Server 2019 の二種類を使用。
Cygwin で sshd を使うと、何かの拍子で Ctrl+C を押下してしまった際に、リモートの cmd.exe が終了してしまうので大きなストレスを感じるのだが、今回はそういったことにならないので心地よい。
次に公開鍵認証を試す。
いちいちパスワード入力するのは馬鹿げていると思うので、公開鍵認証ができることは必須である。
・・・色々試してみたが、成功せず。
2019 年になっても相変わらず Windows の管理はハードルが高い。

ラテ S サイズ * 2 枚
ハズレ * 12 枚

⇒ 14 枚のうち 2 枚が当たり

2018 夏の成績は こちら

ニュース

キャンペーンの案内

CentOS 5, CentOS 6 では SLAAC で v6 アドレスを割り当てると、Modified EUI-64 な v6 アドレスが付く。ところが、CentOS 7 では謎な v6 アドレスが付く。この謎な v6 アドレスは RFC 7217 で説明されているらしい。

昔ながらの慣れたタイプにするには ipv6.addr-gen-mode を eui64 にする。謎タイプにするには ipv6.addr-gen-mode を stable-privacy にする。

[root@cent7f ~]# ip link show dev eth0
2: eth0:  mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:59:74:16 brd ff:ff:ff:ff:ff:ff
[root@cent7f ~]# ip addr show dev eth0
2: eth0:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:59:74:16 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.6/24 brd 192.168.3.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1:0:9af6:7ae:fd48:6a6c/64 scope global noprefixroute dynamic ●謎な v6 アドレス
       valid_lft 86347sec preferred_lft 14347sec
    inet6 fe80::b2bf:3b93:6f5b:24bc/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
[root@cent7f ~]#
[root@cent7f ~]#
[root@cent7f ~]# nmcli connection modify eth0 ipv6.addr-gen-mode eui64 ●変更する
[root@cent7f ~]# nmcli connection up eth0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)
[root@cent7f ~]#
[root@cent7f ~]#
[root@cent7f ~]# ip addr show dev eth0
2: eth0:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:59:74:16 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.6/24 brd 192.168.3.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1:0:215:5dff:fe59:7416/64 scope global noprefixroute dynamic ●Modified EUI-64 な v6 アドレス
       valid_lft 86395sec preferred_lft 14395sec
    inet6 fe80::215:5dff:fe59:7416/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
[root@cent7f ~]#

https://developer.gnome.org/NetworkManager/stable/settings-ipv6.html

https://developer.gnome.org/libnm/stable/NMSettingIP6Config.html#NMSettingIP6Config--addr-gen-mode

+----------+           +----------+           +----------+
|  client  | ========= |  squid   | ========= |  httpd   | 
+----------+           +----------+           +----------+

httpd が 平文でページを提供してくれる場合において client-squid 間を保護(暗号化)するには?

squid の設定にて http_port ではなく https_port を使う。

  • squid は CentOS 7.5 に付属の 3.5.20 を使用
  • curl は Fedora 29 に付属の 7.61.1 を使用 ⇐ これ重要。CentOS 付属のバージョンだと HTTPS proxy に対応していない。

いつもの設定

これだと client と squid の間を保護しない

[root@cent7g ~]# diff /etc/squid/squid.conf.000 /etc/squid/squid.conf
0a1
> visible_hostname CENT7G
59c60
< http_port 3128
---
> http_port 0.0.0.0:3128

squid を起動すると /var/log/squid/cache.log には Accepting HTTP Socket connections と記録される。

Accepting HTTP Socket connections at local=0.0.0.0:3128 remote=[::] FD 11 flags=9

client と squid の間を保護する設定

http_port の代わりに https_port を使う。

[root@cent7e ~]# diff /etc/squid/squid.conf.000 /etc/squid/squid.conf
0a1
> visible_hostname CENT7E
59c60
< http_port 3128
---
> https_port 0.0.0.0:3128 cert=/etc/squid/TLS/service.pem key=/etc/squid/TLS/service-key.pem

squid を起動すると /var/log/squid/cache.log には Accepting HTTPS Socket connections と記録される。

Accepting HTTPS Socket connections at local=0.0.0.0:3128 remote=[::] FD 12 flags=9

case 1

curl http://example.com/ -x 192.168.1.57:3128
  • 192.168.1.57 は http_port を設定している cent7g
  • client と squid 間は平文
  • squid と httpd の間も平文

case 2

curl https://example.com/ -x https://192.168.1.55:3128 --proxy-insecure --insecure
  • 192.168.1.55 は https_port を設定している cent7e
  • client と squid 間は保護されている
  • squid と httpd の間も保護されている
  • --insecure は httpd がオレオレ証明書を使っているから必要
  • --proxy-insecure は squid がオレオレ証明書を使っているから必要

case 3

curl http://example.com/ -x https://192.168.1.55:3128 --proxy-insecure
  • client と squid 間は保護されている
  • squid と httpd の間は平文

case 4

curl https://example.com/ -x 192.168.1.57:3128 --insecure
  • client と squid 間は保護されている。ただし、最初の CONNECT の部分は平文
  • squid と httpd の間も保護されている

その他

気になったから試してみただけで、https_port を使うべきとは思っていません。 case 2 の場合は二重に暗号化されて無駄だ。 http_port で満足。

「プロキシの設定」ダイアログに入力欄が二つ、HTTP と Secure がある。この二種の使い分けに関して。 proxy 上の画像のように設定した場合は下記動作になった。
  • http://example.com/page1.html を要求するときは 192.168.1.55 に設置したプロキシを使う
  • https://example.com/page1.html を要求するときは 192.168.1.57 に設置したプロキシを使う

  • 謎なのが Firefox である。Windows の Firefox、CentOS 7 の Firefox、いずれも上記のような使い分けを行わないのである。

VirtualBox に Use Host I/O Cache (ホストの I/O キャッシュを使う) というチェックボックスがありまして、それをオンするとパフォーマンスが大きく向上しました。

use host io cache

私が使うホスト機は SSD ではなく HDD を使用しておりストレージの性能は低い。一方で、RAM は 64 GB 積んでおり、常に余っているという、そういうホストです。

最初にホストにて測定



host

ゲストにて測定



cache_nashi

ゲストにて Use Host I/O Cache をオンにして測定


cache_ari

おまけ、hyper-v ゲスト



hyper-v.guest

おまけ、VMware Player 15



w2016

ごちガストの戦果発表。
2018/7/19 から 9/26 まで。
53 回のうち、3 回が無料。
当選確率は 1/20 らしいので、上出来だ。


2018/10/8 月曜日、体育の日に合格。

以前から citrix のオンライン ドキュメントはクソだと思っていたが、最近はリンク切ればかりでクソさが増しているのが試験準備の際に腹立たしかった。

NetScaler と戯れるために Windows 10 の Hyper-V を使っている。 スナップショットに二種類あるのを見つけて困惑。 なにこれ? checkpoint type 動かして挙動を観察してみた…多分こういうこと(以下を参照)だろう。

運用チェックポイント / Production Checkpoints

  1. ゲストにてメモ帳を起動する。
  2. メモ帳に一行目を入力する。
  3. メモ帳に入力した内容をファイルに保存することなく、運用チェックポイントを作成する。
  4. メモ帳に二行目を入力する。
  5. チェックポイントを「適用」すると、ゲスト の Windows OS が起動するところから開始する。運用チェックポイント作成時に存在したプロセス (この例ではメモ帳) は存在しない。
  • 運用チェックポイントは Windows Server 2016 から利用可能な新機能らしい。
  • このチェックポイントには、メモリー上の情報は保持されないようだ。
  • ゲストの VSS (もしくは LVM スナップショット) を用いて、ファイルシステムとしては一貫性のある状態を作り出しているようだ。
  • チェックポイントを対象にバックアップを実行してよいのだろう。⇐ おそらくこれが運用チェックポイントの存在理由

標準チェックポイント / Standard Checkpoints

  1. ゲストにてメモ帳を起動する。
  2. メモ帳に一行目を入力する。
  3. メモ帳に入力した内容をファイルに保存することなく、標準チェックポイントを作成する。
  4. メモ帳に二行目を入力する。
  5. チェックポイントを「適用」すると、メモ帳に一行目があり、二行目が消えた状態で再開する。
  • 標準チェックポイントは馴染みのあるタイプだ。
  • ホストが力業で一貫性のある状態を作り出しているようだ。

↑このページのトップヘ