2019-01-18

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ほげほげになっているか確認

2019-01-15

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

2019-01-11

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

windows

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

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

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

wusa /uninstall /kb:xxxxxxx /quiet

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

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

2019-01-08

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_UNAME、SSH_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

2018-05-15

raid-zのHDD交換

freebsd server

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もなれてきたし、一度整理するかな。

2018-02-18

視点、もしくは発想の立脚点について

雑話

様々な認識をもたらす視点、もしくは発想点について考えてみた。

第1の視点

これは主体としての本人からの視点。
普通の人が考えたり、常識だと思うことの出発点、ベースとなっている視点。

第2の視点

本人以外からの視点、本人にはどのようなものなのか完全に把握することはできないが、他社とコミュニケーションすることにより、他社が持っている視点を類推することにより得ることができる。
この場合の他者は他の人間である場合もあるし、誰かが書いた本やブログ、観測機器や理論など本人以外から送られてくる情報など全てを含む

第3の視点

第1の視点と第2の視点の複合としてうまくれてくる視点。
多くの場合会議やブレインストーミングなど、第1の視点と第2の視点が何度も重合することにより生まれてくる。　本人と観測機器からのデータから新しい理論が生まれてくるなども含む。

第4の視点

第1から第3までの視点の結果生じたものが本人に戻り、さらに内発的に生じる視点
ひらめきとか睡眠時に見る夢とか、前後の脈絡なく唐突に生じてくる視点

第5の視点

今までの視点すべて無視して外部からもたらされる視点
預言とか、託宣、憑依など

Twitterみていて、某プロの人がその業界の常識を世界の常識と思っていたようで、えらく驚いていたというのがあって、他者からの視点は大事だよなとおもったところからこんなことをつらつらと考えてみた。

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

2018-02-13

Let's Encrypt で SSL 化

server

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月更新くらいに設定しておくといい