ボリュームライセンス版 Office のインストール

Office 2019 からはいままでの Windows インストラー形式(MSI)でのインストールファイルは提供されなくなり、Office Deployment Tool(ODT)を使用したインストールのみになりました。

インストールファイルは ODT を使用して直接インターネットからダウンロードしてインストールする方法と、事前にファイルサーバなどへインストールファイルをダウンロードしておき、そこからインストールする方法があります。

ODT の取得

Office展開ツールは以下のURLより取得します。

https://www.microsoft.com/download/details.aspx?id=49117

たまにバージョンが変わるのでできるだけ最新版を使用する。
また Language は English のみだが、それで日本語の Office もインストール可能。
f:id:nao550:20190214114654p:plain

ダウンロードした officedeploymenttool_11306-33602.exe を実行すると使用許諾画面が表示されるのでチェックを付けて、Continue すると解凍先の選択になるので適当な場所に解凍する。
f:id:nao550:20190214114726p:plain

後ほど PowerShell などから実行する必要があるので、Cドライブ直下にフォルダを作成するなどしておくと後々使いやすい。

解凍すると、setup.exe ファイルと、configurationファイルのサンプルが展開される。
f:id:nao550:20190214114751p:plain

Configuration.xml の作成

setup.exe を実行するには Configuration.xml ファイルを作成しますが、直接メモ帳などで作成することもできますが、Office Customization Tool を使用すると楽です。

https://config.office.com/
f:id:nao550:20190214114812p:plain


ほぼ選択するかチェックをONにするかだけで必要な設定ができます。わかりやすい。

作成後に、エクスポートボタンをクリックして Configure.xml ファイルをダウンロードします。エクスポートボタンをクリックすると利用規約への同意を求められますのでチェックを付けて同意しておきます。
f:id:nao550:20190214114835p:plain


 ダウンロードした Configure.xml ファイルは ODT の setup.exe と同じフォルダにおいておきます。

Configure.xml の行を追加することで、MSI インストールした Office を削除できますが、すでに Office 365 などのクイック実行形式(C2R)でインストールされた Office は削除されないので、事前に手動で削除しておく必要があります。

setup.exe の実行

Configure.xml ファイルを作成してODTの setup.exe と同じ場所にダウンロードできれば、PowerShellコマンドプロンプトを管理者権限で開きます。

cd コマンドで setup.exe のあるフォルダへ移動します。

PowerShellの場合、setup.exe は実行パスを指定する必要があるので、「.\setup.exe」 で実行する。
f:id:nao550:20190214114855p:plain


オプションは以下の通り

 /download インストールソースファイルをダウンロード
 /configure configure.xml に従って削除やインストールを行う
 /packager  App-V パッケージの作成
 /customize Officeアプリケーションのカスタマイズ
 /help ヘルプの表示

「.\setup.exe /configure configure.xml」で Office のインストールが開始される。


参考:https://docs.microsoft.com/ja-jp/DeployOffice/office2019/deploy

git コマンドレット

自分がよく使う git のコマンドのまとめ

以前のコミットに戻す

git log  ← commit のバージョンを確認
git checkout xxxxxxx

以前のコミットに戻したブランチを最新のブランチに戻す

コミットナンバーを指定して戻した場合には仮のブランチになっているので、checkout しなおす

$ git branch
* (HEAD detached at 017b272)
  master
$ git checkout master

以前のコミットから新しいブランチを作成

$ git checkout xxxxxxx -b newbranch

gitからgitの管理ファイルを抜いてエクスポート

$ git checkout-index -a -f --prefix=export/ ←最後の'/' が大事

git status で管理外のフィアルを表示しない

$ git config status.showuntrackedfiles no 
$ git status -u  ← 管理外のファイルも表示する

直前のコミットメッセージを修正

$ git commit --amend

サーバ上のブランチの確認

$ git remote show origin

https で clone したリポジトリssh に変更する

$ git remote -v  ←現在の状況を確認
$ git remote set-url orign git@github.com:user_name/repo_name ←で変更

git remote -v で origin が git@github.comほげほげになっているか確認

Windows 10 でNASにアクセスできなくなる

Windows10でNASにアクセスできないというトラブルが発生。

PINGの通信はできるが、エクスプローラから開こうとすると「\\hoge にアクセスできません」というメッセージが表示される。
f:id:nao550:20190109163319p:plain


Windows 10 では Fail Creator Update(1709)以降で SMB プロトコルのバージョン1が標準で無効にされるようになったのでそれが原因だった。

クリーンインストールではインストールされないし、SMB v1 が有効になっていた状態から Fail Creator Update にアップデートされると、電撃を切れていた期間を除いて15日 SMB v1 を使用したアクセスがないと自動的に無効にされる。


古いNASにアクセスできなくなるのはこれが原因なので、SMB v1 を有効にすればNASにアクセスできるようになる。


「設定」から「アプリと機能」を開いて「関連設定」の「プログラムと機能」を開く

f:id:nao550:20190109163904p:plain
プログラムと機能

「プログラムと機能」の画面が開くので「Windowsの機能の有効化または無効化」をクリックして、「SMB 1.0/CIFS File Sharing Support」の下にある「SMB 1.0/CIFS Client」にチェックをつけて再起動すればNASへのアクセスができるようになります。 ついでに「SMB 1.0/CIFS自動削除」のチェックは外しておいてもいいかも。
f:id:nao550:20190109164207p:plain


さてこのSMBv1 は脆弱性があり、その脆弱性を身代金ウィルス WannaCry が感染手段として利用していたということがあり無効にされたという経緯がありますので、これを有効にすることにより、WannaCry、及びその亜種のウィルスに感染しやすくなります。 自己責任でどうぞ

根本的な対処としてはSMBv1でしか使用できないようなNASはすてて、SMBv2以降を使用しているNSAにするのが最適解なんだろうな。

現在接続しているSMBのバージョンを確認するには、NASなどをエクスプローラーで開いておいて、PowerShell を管理者モードで起動して、「Get-SmbConnection」コマンドを実行すると使用している接続情報が表示される。

下の画面の「Diarect」が「1.5」になっているが、これが WannaCry 対応されたSMBv1ということになる。「1.2」だと未対応かも?
f:id:nao550:20190109170359p:plain

トラブルを起こすKBをコマンドプロンプトで削除する

WindowsUpdateでインストールされたセキュリティアップデートなどでトラブルが起こることがある。

その場合はKBを削除して解決するまでインストールされないように設定する必要がある。

コマンドプロンプトを管理者として起動して、

wusa /uninstall /kb:xxxxxxx /quiet

xxxxxxx はKB番号、quiet はユーザの操作なしで実行。
f:id:nao550:20190111115454p:plain


その他のオプションは wusa をそのまま実行すれば表示される。
f:id:nao550:20190111115538p:plain

bitbucket の Pipeline をつかって、SSHでデプロイ

bitbucket の Pipeline を使って SSH 経由でデプロイする。 Pipeline で自動テストもできるようだけど、手元のマシンで編集して git push すればテストサーバに連動してデプロイしてくれる環境を目指す。

Piplelineの有効化とSSHの設定

bitbucket のリポジトリを開き「設定」→「PIPELINES」→「Settings」を開き、「Enable Pipeline」をONにすると、「Configure bitbucket-piplelines.yml」のボタンが有効になるけどこれは後回し。

f:id:nao550:20190108125610p:plain

Repository variables

PIPELINE 設定の「Repository variables」で bitbucket-pipelines.yml で使用する変数を設定する。
今回は ssh 関係だけなので、SSH_UNAMESSH_HOST を設定

f:id:nao550:20190108131226p:plain

SSH Authkey

引き続き PIPELINES の今度は「SSH Keys」をクリック、画面にある「Generate Keys」をクリックするとキーペアが生成されて、Public Key が表示されるので、それを SSH でログインしたいサーバのユーザの ~/.ssh/authorized_keys に追記、

そのサーバのアドレスを「Known hosts」に入れて、「Fetch」すれば、そのサーバのキーを取得するので、「Add host」して登録。

f:id:nao550:20190108132121p:plain

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」
f:id:nao550:20190108130559p:plain

確認

問題なくできていれば、bitbucket 上でソースを編集して commit すれば Pipeline が実行されます。 さっきの bitbucket-pipeline.yml を編集した時点で pipeline は実行されるので、サイドメニューの「Pipelines」を開くと設定した Pipeline の実行状況が確認できます。

Fail になっている場合にはなにかが失敗しているので、そこをクリックして失敗している状況を確認できます。

f:id:nao550:20190108135907p:plain

raid-zのHDD交換

f:id:nao550:20180513160503j:plain
自宅サーバから変な音がしていたので調べると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みていて、某プロの人がその業界の常識を世界の常識と思っていたようで、えらく驚いていたというのがあって、他者からの視点は大事だよなとおもったところからこんなことをつらつらと考えてみた。

常識的なことではあるけど、こういうふうに分類してるのあんまり見たことないな。