読者です 読者をやめる 読者になる 読者になる

Logic Delight

明日のワシは忘れてしまうから、コードにはコメントを書くのです。

自習系GitHubリポジトリをひとつにまとめてみた

厳密には、"今日覚えたこと"を書いていくという、一部で流行りの気配を見せている til (Today I learned) リポジトリの真似をして、自習系リポジトリをまとめてみた、という記事ですな。

(切欠) GithubでTILというリポジトリが流行りつつあるのかもしれない - 生涯未熟

リポジトリ(4つ)

  • black-hat-python
  • electron-sample
  • GlibTraining
  • Python-handson

出来上がり状態

  • til
    • README.md
    • black-hat-python
    • electron-sample
    • GlibTraining
    • Python-handson

github.com

新設した til リポジトリに各リポジトリを内包させる形で git filter-branch していく。各リポジトリのコミット履歴は残り、元リポジトリの名称のブランチから master にマージされたかたちになる。

参考にしたサイト

qiita.com

コメント欄にあるとおり、本文中の git filter-branch の部分がMacだとエラーになってしまうので、コメントにあるコマンドを使った。

また、electron-sample リポジトリは、直下に同名のディレクトリが存在していたので、これを src にリネームしたうえで実施してみたが、「コミット履歴中にリポジトリ名と同名のフォルダが存在すると...」というこれまたコメント欄にあるとおりのエラーになったので、こちらもMac版のコマンドに修正したうえで実施した。

つまり、まとめると

#GitHub Account
ACCOUNT=shionit
#Source Repository
REPO=XXXXX

# at dest repository path
git remote add $REPO git@github.com:$ACCOUNT/$REPO.git
git fetch $REPO
git checkout -b $REPO $REPO/master
git filter-branch -f --tree-filter "mkdir __temp__ && git mv -k {,.[!.],..[!.]}* __temp__/ && mkdir $REPO && git mv -k __temp__/{,.[!.],..[!.]}* $REPO/"
git checkout master
git merge $REPO

結果、単一の自習リポジトリにまとめられてスッキリですな☆

Mac環境構築の自動化と設定バックアップ

以下の記事を参考に、Home BrewBrew Cask を使って環境構築の自動化(省力化)をしてみた。

qiita.com

他にも、Ansibleを使ったMac環境構築の記事はありましたが、AnsbileのバージョンUp時の仕様変更についていくのツライ、Brew Bundleがいい感じにメンテされていきそう、mackupもシンプルで素敵☆ということで上記の記事に沿って対応することにしました。

上記の記事では brew brewdle コマンドを使っていますが、GitHubの本家リポジトリを見る限り brew brewdler brew bundler といったコマンドとともに下位互換性を保つためのエイリアス実装となっており、今後は brew bundle が公式なコマンドとなっていくものと思われるので、これで実装しといた。

GitHub - Homebrew/homebrew-bundle: Bundler for non-Ruby dependencies from Homebrew

他にも参考にした記事、というかbrewで取得するアプリケーションの一覧を覗くだけでも、知らない便利アプリに出会うことができて有意義でした。

Mac の開発環境構築を自動化する (2015 年初旬編) - t-wadaのブログ

既存環境のMac でもansible で環境構築を自動化するには - snowlongの日記

2016/04/21追記

便利な mackup がバージョンアップしてオプション指定方法が変わったのか、パラメータを変えてあげないと動かなくなったのでメモ。

@daily /usr/local/bin/mackup -f backup

2016/07/28追記

Home brew cask の Caskroom のデフォルトロケーションが変更されたこと*1に伴い、crontabの内容を見直す必要ができたのでメモ。

@weekly cd /usr/local/bin/ && time nice -n19 brew update && time nice -n19 brew upgrade && time nice -n19 brew cleanup && for c in `brew cask list`; do ! brew cask info $c | grep -qF "Not installed" || time nice -n19 brew cask install $c; done && time nice -n19 brew cask cleanup && for c in /usr/local/Caskroom/*; do vl=(`ls -t $c`) && for v in "${vl[@]:1}"; do \rm -rf "$c/$v"; done; done; for c in /usr/local/Caskroom/*/.metadata; do vl=(`ls -t $c`) && for v in "${vl[@]:1}"; do \rm -rf "$c/$v"; done; done

dotfilesの整備

また、GitHub に公開されている dotfiles 系リポジトリを参考にシェルまわりの環境設定も合わせて整備した。

GitHub - mathiasbynens/dotfiles: .files, including ~/.macos — sensible hacker defaults for macOS

GitHub - yuku-t/dotfiles: My dotfiles

初期設定まわりが随分とスッキリして、バックアップも取れて安心安心☆というのもありますが、個人的には .gitconfig にgitコマンドのエイリアスを定義しまくって効率化!というのを色々とキャッチアップできたのが大変有用でした。最後に、出来上がったdotfilesはコチラ↓

github.com

Dockerのバージョンアップしたらコマンドがエラーになった

Dockerのバージョンアップ(1.9.1->1.10.1)したら、dockerコマンドがエラーを返すようになった。

$ docker ps
Error response from daemon: client is newer than server (client API version: 1.22, server API version: 1.21)

サーバーの再起動なり、アップグレードをすることで解消する模様。

$ docker-machine upgrade
Waiting for SSH to be available...
Detecting the provisioner...
Upgrading docker...
Stopping machine to do the upgrade...
(中略)
Restarting docker...

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

直った。良かった。

(参考URL)
Error response from daemon: client is newer than server with Docker 1.9 RC3 · Issue #2147 · docker/machine

情報セキュリティの体系化

偉い人からのデッカイボールに対応するためのメモメモ。。

情報セキュリティの目的

  1. 機密性(Confidentiality)
    • アクセス権を持つ者だけが、情報にアクセスできることを確実にすること
      • アクセス制御、パスワード認証、暗号化、入退室管理
  2. 完全性(Integrity)
    • 情報及び処理方法が正確であることおよび完全であることを保護すること
      • デジタル署名、メッセージダイジェストによる改竄防止
  3. 可用性(Availability)
    • 認可された利用者が、必要なときに、情報および関連する資産にアクセスできることを確実にすること
  4. 責任追跡生 / 説明可能性(Accountability)
    • システムが、いつ、誰に利用されたかを追跡できること
  5. 真正性 / 認証性(Authenticity)
    • 情報の作成者や送信者が(なりすまし/偽物ではなく)本物であることを保証すること
      • デジタル署名、パスワード認証
  6. 信頼性(Reliability)
    • システムやプロセスが矛盾なく動作すること、一貫して動作すること
      • ネットワークやシステムの2重化による呼称対策、サーバ室での温度管理、負荷監視

前半の3つを「セキュリティのCIA」と呼ぶ。最近は、後半の3つを追加して6大要素とすることもある。

セキュリティの機能

  1. 抑制
    • セキュリティの存在が、犯罪・事故などを牽制・抑止する
      • ホスティング、外部委託、不要なサービスの停止、監視カメラ、規則・契約書への明記
  2. 予防
    • 脅威の顕在化、拡大を防止する
  3. 検知
    • 事故・障害・不正などを速やかに発見・通知する
      • ログの監視、侵入検知システム、SNMPによるネットワーク管理
  4. 回復
    • 事故・障害から正常な状態に回復する
      • バックアップ、代替機の確保、復旧対応マニュアルの作成

セキュリティの対策

  1. 物理的対策
    • 建物・設備基準
  2. 技術的対策
  3. 運用管理対策

情報セキュリティの指す範囲

  • 情報セキュリティ
    • コンピュータ・セキュリティ
      • ネットワーク・セキュリティ
    • (建物・設備などの)物理セキュリティ

情報セキュリティの技術的対策

  1. 監査(Audit)
    • 他の5階層全体を指し、導入した製品自身に設定ミスがないか、利用者がルールどおりに使用しているかなどを監視し、監査証跡を記録する製品およびサービス
  2. 暗号化(Encryption)
    • IPsec技術を使ったVPN、ファイル暗号化など、機密漏洩対策としての製品およびサービス
  3. 特権定義(Priviledge Definition / Single Sign On)
    • 個人の属性に対して定義されたシステムへのアクセス権限を管理運営する認可の製品およびサービス
  4. 認証(Authentication)
    • ネットワークやサーバにアクセスする際の、本人性を確認する製品およびサービス
  5. 通信規制(Access Control)
  6. データ保護(Data Protection / Data Integrity)
    • アンチウィルスに関する製品およびサービス

時系列で見た考え方

  • 事前対策
    • ファイアウォール、ウィルス対策サーバ、安全なWebアプリ開発、ハードディスク暗号化、サーバ室での安定稼働、パッチ適用
  • 発生時の対策
    • ネットワークからの切り離し、社内への周知、ホームページ上での公表、政府機関への連絡、HDDやメモリ内の証拠保全作業
  • 発生後の対応、見直し
    • 発生したインシデントのレビュー、ポリシーの改定や新たな対応策の導入
  • 日常の運用
    • 社員の教育、ログの監視、定期的バックアップ、脆弱性情報の収集、アカウント登録削除の管理徹底

脅威の分類

  • 人為的かつ意図的な脅威
    • 直接的な脅威
      • 破壊
      • 漏洩
      • 改竄
      • 盗聴
      • 盗難
      • サービス停止
      • 不正利用
      • 踏み台
      • ウィルス感染
    • 取引に関わる脅威
      • なりすまし
      • 否認
  • 人為的かつ非意図的な脅威
    • オペミス、間違い・勘違い
  • 人為的かつ非意図的な脅威
    • H/W故障や自然災害

情報セキュリティのInputまとめ

この数年、情報セキュリティって何やった?を自分向けメモにまとめて振り返ってみる。

Dockerを使ったMongoDBの導入

前回に引き続きローカル開発環境で軽くMongoDBを導入して試したい、という場合にVagrant上でMongoDBをインストールしてゴニョゴニョってやってたけど、Dockerではデフォルトのインストールイメージが公開されているので導入がメチャ楽だ、というシリーズですウス。

MongoDB のDockerイメージ

MongoDB - Docker Hub https://hub.docker.com/_/mongo/

Dockerfileはこれ github.com

以下、公式ガイドのまんまですが解説。

MongoDB on Dockerコンテナーの起動

$ docker run --name my-mongo -d mongo

my-mongo という名称でバックグラウンドでDockerサーバが起動し、27017ポートでリッスン状態になる。

MongoDB shellで接続してみる

$ docker run -it --link my-mongo:mongo --rm mongo sh -c 'exec mongo "$MONGO_PORT_27017_TCP_ADDR:$MONGO_PORT_27017_TCP_PORT/test"'
MongoDB shell version: 3.2.0
connecting to: 172.17.0.2:27017/test
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see
    http://docs.mongodb.org/
(中略)
> show dbs
local  0.000GB
> use mydb
switched to db mydb
> db.createCollection('users');
{ "ok" : 1 }

ちゃんと使えていますね。終わるときは、Ctrl-Cで抜けます。

MongoDB on Dockerコンテナーの停止

$ docker stop my-mongo

以上!前回同様に便利だから、今後は意識した作業としての「ミドルウェアをインストールする」ということが少なくなっていくかもしれませんな。

Dockerを使ったRedisの導入

ローカル開発環境で軽くRedisを導入して試したい、という場合にVagrant上でRedisをインストールしてゴニョゴニョってやってたけど、Dockerではデフォルトのインストールイメージが公開されているので導入がメチャ楽だ、という話ですウス。

Redis のDockerイメージ

Redis - Docker Hub
https://hub.docker.com/_/redis/

Dockerfileはこれ github.com

以下、上記サイトのガイドのまんまですが解説。

Redis on Dockerコンテナーの起動

$ docker run --name my-redis -d redis

my-redis という名称でバックグラウンドでDockerサーバが起動し、6379ポートでリッスン状態になる。

redis-cli で接続してみる

$ docker run -it --link my-redis:redis --rm redis sh -c 'exec redis-cli -h "$REDIS_PORT_6379_TCP_ADDR" -p "$REDIS_PORT_6379_TCP_PORT"'
172.17.0.2:6379[1]> set key1 11111
OK
172.17.0.2:6379[1]> get key1
"11111"

ちゃんと使えていますね。終わるときは、Ctrl-Cで抜けます。

Redis on Dockerコンテナーの停止

$ docker stop my-redis

以上!チョー簡単で便利な世の中になったもんですな。