Windows 10 でNASにアクセスできなくなる
Windows10でNASにアクセスできないというトラブルが発生。
PINGの通信はできるが、エクスプローラから開こうとすると「\\hoge にアクセスできません」というメッセージが表示される。
Windows 10 では Fail Creator Update(1709)以降で SMB プロトコルのバージョン1が標準で無効にされるようになったのでそれが原因だった。
クリーンインストールではインストールされないし、SMB v1 が有効になっていた状態から Fail Creator Update にアップデートされると、電撃を切れていた期間を除いて15日 SMB v1 を使用したアクセスがないと自動的に無効にされる。
古いNASにアクセスできなくなるのはこれが原因なので、SMB v1 を有効にすればNASにアクセスできるようになる。
「設定」から「アプリと機能」を開いて「関連設定」の「プログラムと機能」を開く
「プログラムと機能」の画面が開くので「Windowsの機能の有効化または無効化」をクリックして、「SMB 1.0/CIFS File Sharing Support」の下にある「SMB 1.0/CIFS Client」にチェックをつけて再起動すればNASへのアクセスができるようになります。 ついでに「SMB 1.0/CIFS自動削除」のチェックは外しておいてもいいかも。
さてこのSMBv1 は脆弱性があり、その脆弱性を身代金ウィルス WannaCry が感染手段として利用していたということがあり無効にされたという経緯がありますので、これを有効にすることにより、WannaCry、及びその亜種のウィルスに感染しやすくなります。 自己責任でどうぞ
根本的な対処としてはSMBv1でしか使用できないようなNASはすてて、SMBv2以降を使用しているNSAにするのが最適解なんだろうな。
現在接続しているSMBのバージョンを確認するには、NASなどをエクスプローラーで開いておいて、PowerShell を管理者モードで起動して、「Get-SmbConnection」コマンドを実行すると使用している接続情報が表示される。
下の画面の「Diarect」が「1.5」になっているが、これが WannaCry 対応されたSMBv1ということになる。「1.2」だと未対応かも?
トラブルを起こすKBをコマンドプロンプトで削除する
WindowsUpdateでインストールされたセキュリティアップデートなどでトラブルが起こることがある。
その場合はKBを削除して解決するまでインストールされないように設定する必要がある。
コマンドプロンプトを管理者として起動して、
wusa /uninstall /kb:xxxxxxx /quiet
xxxxxxx はKB番号、quiet はユーザの操作なしで実行。
その他のオプションは wusa をそのまま実行すれば表示される。
bitbucket の Pipeline をつかって、SSHでデプロイ
bitbucket の Pipeline を使って SSH 経由でデプロイする。 Pipeline で自動テストもできるようだけど、手元のマシンで編集して git push すればテストサーバに連動してデプロイしてくれる環境を目指す。
Piplelineの有効化とSSHの設定
bitbucket のリポジトリを開き「設定」→「PIPELINES」→「Settings」を開き、「Enable Pipeline」をONにすると、「Configure bitbucket-piplelines.yml」のボタンが有効になるけどこれは後回し。
deploy.sh
リポジトリの一番上のディレクトリに deploy.sh を作成して git add して commit して push
#!/bin/sh cd /home/hoge/testrepo git pull origin master
bitbucket-pipeline.yml
SSH の設定までできたら、PIPELINES の「Settins」に戻って、「Configure bitbucket-piplelines.yml」をクリック、bitbucket-piplines.ymlの編集画面が開くので
pipelines: default: - step: name: Deploy ssh. script: - ssh $SSH_UNAME@$SSH_HOST tcsh < deploy.sh
作成したら「commit file」
確認
問題なくできていれば、bitbucket 上でソースを編集して commit すれば Pipeline が実行されます。 さっきの bitbucket-pipeline.yml を編集した時点で pipeline は実行されるので、サイドメニューの「Pipelines」を開くと設定した Pipeline の実行状況が確認できます。
Fail になっている場合にはなにかが失敗しているので、そこをクリックして失敗している状況を確認できます。
raid-zのHDD交換
自宅サーバから変な音がしていたので調べるとzfsのドライブが壊れていたのでHDDを買ってきて交換作業。
root@mercury:~ # zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT tank 7.25T 3.36T 3.89T - - 46% 1.00x DEGRADED - root@mercury:/var/log # zpool status pool: tank state: DEGRADED ---略--- 16269517396372478662 UNAVAIL 1 6 0 was /dev/gptid/b1417f56-3666-11e0-9d07-001485f1161b ←これが壊れている ---略---
gpart list コマンドで壊れているドライブを確認
root@mercury:gpart list ---略--- Geom name: ada3 ---略--- rawuuid: b1417f56-3666-11e0-9d07-001485f1161b ---略--- Consumers: 1. Name: ada3 Mediasize: 2000398934016 (1.8T) ---略---
壊れているのは ada3、次に ada3 のシリアル番号をチェック
root@mercury:/var/log # cat /var/run/dmesg.boot ---略--- ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 ada3: <WDC WD20EARS-00S8B1 80.00A80> ATA8-ACS SATA 2.x device ada3: Serial Number WD-WCAVY3005042 ---略---
ということで、「WD20EARS-00S8B1」のHDDが壊れていることが確定
zfsから壊れているドライブを Offline にして
root@mercury:/var/log # zpool offline tank 16269517396372478662 root@mercury:/var/log # zpool status ---略--- 16269517396372478662 OFFLINE 1 6 0 was /dev/gptid/b1417f56-3666-11e0-9d07-001485f1161b ---略---
shutdown して、HDDの交換して再起動
root@mercury:/var/log # cat /var/run/dmesg.boot ---略--- ada3: Serial Number WD-WCC4M4FU46C3 ---略---
交換するときにHDDのシールに記載されているシリアル番号は確認しておいて、交換したHDDがどのデバイスとして認識されているか確認する。
追加されたドライブが ada3 になっている。 gpartでGPTパーティションを作成
root@mercury:~ # gpart create -s GPT ada3 ada3 created root@mercury:~ # gpart show ada3 => 34 3907029101 ada3 GPT (1.8T) 34 3907029101 - free - (1.8T)
zpool replace コマンドで壊れたドライブを新しいドライブに入れ替えるように指示
root@mercury:~ # zpool replace tank 16269517396372478662 ada3 root@mercury:~ # zpool status -v pool: tank state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Sun May 13 16:30:18 2018 12.3G scanned out of 3.36T at 89.0M/s, 10h57m to go 3.06G resilvered, 0.36% done config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 diskid/DISK-WD-WCAVY3131675p1 ONLINE 0 0 0 block size: 512B configured, 4096B native gptid/af791db4-3666-11e0-9d07-001485f1161b ONLINE 0 0 0 block size: 512B configured, 4096B native gptid/b05ed30a-3666-11e0-9d07-001485f1161b ONLINE 0 0 0 block size: 512B configured, 4096B native replacing-3 OFFLINE 0 0 0 ←リプレース作業中に表示される 16269517396372478662 OFFLINE 0 0 0 was /dev/gptid/b1417f56-3666-11e0-9d07-001485f1161b ada3 ONLINE 0 0 0 block size: 512B configured, 4096B native (resilvering) errors: No known data errors
zraidのパリティ計算などが終了したら、リプレース作業中に表示されていた replacing-3 の項目は消える。status 確認して消えていればリプレース作業は終了
root@mercury:/var/mail # zpool status pool: tank state: ONLINE status: One or more devices are configured to use a non-native block size. Expect reduced performance. action: Replace affected devices with devices that support the configured block size, or migrate data to a properly configured pool. scan: resilvered 860G in 9h33m with 0 errors on Mon May 14 02:04:16 2018 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 diskid/DISK-WD-WCAVY3131675p1 ONLINE 0 0 0 block size: 512B configured, 4096B native gptid/af791db4-3666-11e0-9d07-001485f1161b ONLINE 0 0 0 block size: 512B configured, 4096B native gptid/b05ed30a-3666-11e0-9d07-001485f1161b ONLINE 0 0 0 block size: 512B configured, 4096B native ada3 ONLINE 0 0 0 errors: No known data errors
このraidz、8年前の「サーバの更新で zfs にしてみるとか - 日々雑文」で作ったやつで、一度トラブルでデータをロストしかけてる。その時の名残がこのへんな状態になっているドライブIDだったりする。
gpartもなれてきたし、一度整理するかな。
視点、もしくは発想の立脚点について
様々な認識をもたらす視点、もしくは発想点について考えてみた。
第1の視点
これは主体としての本人からの視点。
普通の人が考えたり、常識だと思うことの出発点、ベースとなっている視点。
第2の視点
本人以外からの視点、本人にはどのようなものなのか完全に把握することはできないが、他社とコミュニケーションすることにより、他社が持っている視点を類推することにより得ることができる。
この場合の他者は他の人間である場合もあるし、誰かが書いた本やブログ、観測機器や理論など本人以外から送られてくる情報など全てを含む
第3の視点
第1の視点と第2の視点の複合としてうまくれてくる視点。
多くの場合会議やブレインストーミングなど、第1の視点と第2の視点が何度も重合することにより生まれてくる。 本人と観測機器からのデータから新しい理論が生まれてくるなども含む。
第4の視点
第1から第3までの視点の結果生じたものが本人に戻り、さらに内発的に生じる視点
ひらめきとか睡眠時に見る夢とか、前後の脈絡なく唐突に生じてくる視点
第5の視点
今までの視点すべて無視して外部からもたらされる視点
預言とか、託宣、憑依など
Twitterみていて、某プロの人がその業界の常識を世界の常識と思っていたようで、えらく驚いていたというのがあって、他者からの視点は大事だよなとおもったところからこんなことをつらつらと考えてみた。
常識的なことではあるけど、こういうふうに分類してるのあんまり見たことないな。
Let's Encrypt で SSL 化
https://letsencrypt.jp/:日本語のマニュアルサイトがあるので簡単だった。
それぞれのOSのパッケージがあるとおもうので、そこからインストールする
# python2 --version Python 2.7.13 # pkg search certbot py27-certbot-0.21.0,1 Let's Encrypt client py36-certbot-0.21.0,1 Let's Encrypt client' # pkg install py27-certbot ---- (中略) ---- This port installs the "standalone" client only, which does not use and is not the certbot-auto bootstrap/wrapper script. The simplest form of usage to obtain certificates is: # sudo certbot certonly --standalone -d <domain>, [domain2, ... domainN]>
ということで、パッケージからインストールしたときには、certbot-auto スクリプトは使用せず、standalone モードで使用する。
certbot-auto なら、ウェブサーバの設定もしてくれるのでそっちのほうが楽だったぞ…
standalone モードでは port 80, 443 が開いていないと
Problem binding to port 80: Could not bind to IPv4 or IPv6.
と怒られるので、apache などが動いているのなら、一旦停止させる。
# certbot certonly --standalone -d example.net Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): hoge@example.net ← 初回のみメールアドレスを入力 (A)gree/(C)ancel: a ← 使用許諾への同意 (Y)es/(N)o: n ← Electronic Frontier Foundation のMLへ参加するかどうか
証明書が /usr/local/etc/letsencrypt/live/example.net/cert.pem に
プライベートキーが /usr/local/etc/letsencrypt/live/kyo-to.net/privkey.pem に
保存される。
すでにhttpで公開していたのなら、mod_rewrite で http へのアクセスを https へ転送するために、ホストディレクティブに転送設定を追加して、
RewriteEngine on RewriteCond %{SERVER_NAME} =example.jp RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [L,NE,R=permanent]
ssl.conf に証明書の設定をする
SSLCertificateFile /usr/local/etc/letsencrypt/live/example.net/cert.pem SSLCertificateKeyFile /usr/local/etc/letsencrypt/live/example.net/privkey.pem SSLCertificateChainFile /usr/local/etc/letsencrypt/live/example.net/chain.pem
証明書の更新
Let's Encrypt の証明書は3ヶ月なので、期限が来るまでに更新が必要。
更新は
# certbot renew
とするだけ、cron で1月更新くらいに設定しておくといい
コマンドラインによるFreeBSD起動パーティションの作成など
fdisk, disklabel, はもう古いので、知識のアップデートを兼ねて。
MBR時代は fdisk コマンドでスライス切って、disklabel でパーティション分けていたが、GPTが主流になり、パーティションが128個つくれるようになったので、gpartで必要な数のパーティションにわけるのが主流になっているようだ。
新規のドライブなら必要ないが、以前に使用していたのを再利用するなら、以前に使用していたのを再利用するなら、残っているパーティション情報などを削除するために destroy する。
本来であれば、残っているパーティションを1個ずつ delete コマンドで削除して、最後に destroy しないと消すことができないが、destroy に -F オプションで強制削除もできる。
# gpart show ada1 # gpart delete -i 1 ada1 # gpart destroy -F ada1
パーティションを削除したら、新しくGPTでパーティションを作成してく。
# gpart create -s GTP ada1
ブートコードの書き込み
# gpart add -t freebsd-boot -b 40 -s 512 ada1 -t パーティションタイプ -b スタートブロック -s サイズ # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada1 -b ディスクのブートコード -p パーティションのブートコード -i パーティション番号
自分は gmirror にするので、gptboot をインストールしたが、zfsにしたければ、gptzfsboot をインストールする。 以前は freebsd-boot の領域は64kでもまにあっていたのだが、11-RELEASE になってから、gptzfsboot のファイルサイズが増えたりしているので、多めにしておくのがいいらしいが、最大サイズは 545Kまでという制限もある。
EFIブートコードのインストール
# gpart add -t efi -b 1m -s 100m ada1 # dd if=/boot/boot1.efifat of=/dev/ada1p2
EFI用のパーティションを作成して、EFI Application をインストールする。これをしておかないとEFIを使用して起動できない。
EFI Application の本体は /boot/boot1.efi で、EFI パーティションはFAT32にしておけば直接コピーすることも可能
# gpart add -t efi -b 1m -s 100m ada1 # newfs_msdos /dev/ada1p2 # mount -t msdosfs /dev/ada1p2 /mnt # mkdir -p /mnt/EFI/BOOT # copy /boot/boot1.efi /mnt/EFI/BOOT/BOOTx64.EFI
SWAP、UFSパーティションの作成
ここまでできれば後は普通にswapパーティションや、ufsパーティションを作成していく
# gpart add -t freebsd-swap -s 16G ada1 # gpart add -t freebsd-ufs ada1
- s で良を指定しなければ、取れる最大の領域で作成してくれる。