迂闊にもMS Translatorがいけてることに気がついたので、ちょっと試してみる。

• Microsoft Translator APIを使ってみる
• Microsoft Translator Text APIをNode.jsから使ってみる
• Microsoft Translator テキスト API で、日本語を英語に翻訳するサンプル

しかし、MicrosoftのSubscriction関連の設定は面倒だった。

• Microsoft Translatorのページを開く
  • ここに色々情報がまとまっているので、頑張って見てみるといい
• Microsoft DataMarketのページを開き、右上からSign-Inする
  • 登録がない人は、ここから登録すること。
  • Skype使っていて移行した人はそのアカウントで良い。電子メールアドレスでも電話番号でも良い。
    • Skype IDでloginした
• アプリケーションの登録ページを開き、必要な情報を入力する
  • クライアントID: アプリケーションの識別子。他とぶつからない好きな文字列を入力
  • 名前: アプリケーションの名前
  • 顧客の秘密: 特に変更する必要はない
  • リダイレクトURI: Microsoft Translatorの場合、無効なURLを入力すれば良い
  • サブドメインアクセスを有効にする: オフのままで良い
  • 説明: 登録内容の説明など
  • クライアントID(client id)と顧客の秘密(client secret)は、APIを利用する際に必要になる。
• あとは、API使って普通に叩けばOK

何を血迷ったか、翻訳エンジンについてちょっとだけ調べてみたので、メモを。

かるーく（ゆるーく）調べた（ぐぐった）ところ、

• 英単語の平均文字数は 4.5文字とか5.1文字くらいらしい。まぁ、5文字と考えておけばいいか
• 英語1文章に含まれる単語数は、まぁ、色々違うらしい。
  • カジュアルな文章で20単語位
  • 一般的な文章で25単語位
  • 新聞で20単語位
  • 子供向け絵本で5単語位

ものすごく単純に RFC文書における単語数を数えて平均を取ってみると、52645文字、6718 単語と言われる。（7.836文字/単語) この数値は、単純にwcで見ただけなので、実際にはHeaderやFooter、Indexなどがある。 ちゃんと調べるのは単純に面倒なので、大雑把に考えて、平均で6500単語、8文字/単語くらいと近似できると 思う ので、1 RFCあたり5.5万文字と見ればそんなに外さないと思われる。

ちょっと面白かったのは、Plain English　読みやすさの指標（FKR/FKG/GFS）って一体何が基準なの！？の記事。 軽く眺めておくといいかも。

Google様で 翻訳 API で検索してみる

• Googleの翻訳API
  • 原則有料。
  • 言語検出および翻訳に関しては 1万文字/$20
    • RFCで考えると、5.5万/1万*20 = $120 として、$1=¥110とすれば、¥13,200位か。
  • google翻訳知らない人は google translateでぐぐれ
• MicrosoftのTranslator API
  • 個人利用と法人利用（ビジネス利用）がある
  • サービスとしても提供されている
  • 200万字まで無料。（文字数であり、単語数ではない）
    • RFCで考えてみると200万/5.5万≒36 だから、36本翻訳できる計算になる。
      • 個人の普段使いだと思えば十分だが、プロの翻訳者では少ないというあたりなんだろうな。
  • それ以降は段階的に料金が上がる。値段表が出るページ

実質で使える翻訳APIはMSとGoogleしかなさそうだが、翻訳精度がよほど高くない限りGoogleは使えないなぁ。 MSの翻訳エンジン、textで流し込むぶんには結構いい翻訳精度だったし。

ただ、どちらの翻訳エンジンも文脈は解釈しない（できない）から、どうしたって人様が手をかけてやる必要は（いまのところ）ある。

sudoを使っていて、

• あるアカウントに対して
• あるコマンドの実行権だけrootで動かせるようにしたい
• その際、引き継いで欲しい環境変数がある

という難しい状況が発生することがある。まぁvulsなんだが。

こういうときには、sudoersに、こんな風に設定すればよい

vuls ALL=(ALL) NOPASSWD:/usr/bin/yum --changelog --assumeno update *
Defaults:vuls env_keep="http_proxy https_proxy HTTP_PROXY HTTPS_PROXY"

これみて意味がわからなくて、manみてもわからなくて、ググれない人は、これ使っちゃダメですよw

さて、これでrbenvも設定し、Rubyも2.3が動くようになったので、やっとRedmine 3.2のInstallへ。

1. まず、必要そうなものを入れておく。
   • pkg install nginx ImageMagick mariadb100-client
   • gem install bundler –no-rdoc –no-ri
   • curl http://www.redmine.org/releases/redmine-3.2.0.tar.gz > redmine-3.2.0.tar.gz
2. Redmineを実行するアカウントを作る
   • ここでは、redmineとする
3. Redmineを/usr/local/wwwに入れる
   • mkdir /usr/local/www
   • cd /usr/local/www
   • tar xzf redmine-3.2.0.tar.gz
   • ln -s redmine-3.2.0 redmine
4. Redmineの初期設定を行う
   • cp redmine/config/database.yml.example redmine/config/database.yml
   • vi redmine/config/database.yml
     • 書き換えるのは、productionの部分だけで良い

   • production:
       adapter: mysql2
       database: redminedb
       host: xxx.xxx.xxx.xxx
       username: redmine_user
       password: "UltraSecret"
       encoding: utf8

5. RubyのGemを入れる
   • 今回はUnicornで動かすので、一手間かける。
     • vi redmine/Gemfile.local

       gem "unicorn"

   • bundle install –without development test postgresql sqlite
6. Redmineの初期設定を実行
   • sudo -u redmine /bin/sh
   • bundle exec rake generate_secret_token
   • RAILS_ENV=production bundle exec rake db:migrate
   • RAILS_ENV=production REDMINE_LANG=ja bundle exec rake redmine:load_default_data
7. Webrickでの試験
   • Rails 4.2以降、Webrickで通信を待ち受ける場合、defaultではlocalhostしかListenしなくなった。
   • ruby bin/rails server webrick -e production -b xxx.xxx.xxx.xxx と-bを指定してやれば、その引数のアドレスでListenするようになる。
8. NGiNXとUnicornの設定
   • /etc/rc.conf に nginx_enable=“YES”を追加
   • Unicornを設定
     • unicorn設定ファイル内after_fork内でuser,groupをredmine:redmineに設定しているので注意
     • ぐぐると、Process ownerのchown関係がちゃんと動かない(worker.userがなかった頃の)unicorn.rbが引っかかるので注意
     • vi redmine/config/unicorn.rb

       # cat config/unicorn.rb 
       # -*- coding: utf-8 -*-
       # Unicorn Configuration File for Redmine
       #       http://unicorn.bogomips.org/examples/unicorn.conf.rb
       
       $unicorn_user = "redmine"
       $unicorn_group = "redmine"
       
       @dir = "/home/www/rrrm.rusty-raven.net/redmine"
       working_directory @dir
       worker_processes 2
       
       listen "/var/run/unicorn_rrrm.sock", :backlog => 32
       # listen 8282, :tcp_nopush => true
       
       timeout 30
       
       pid "/var/run/unicorn.pid"
       stdout_path File.expand_path("log/unicorn.stdout.log", @dir)
       stderr_path File.expand_path("log/unicorn.stderr.log", @dir)
       
       preload_app true
       
       check_client_connection false
       
       before_fork do |server, worker|
         defined?(ActiveRecord::Base) and
             ActiveRecord::Base.connection.disconnect!
       
         old_pid = "#{server.config[:pid]}.oldbin"
         if old_pid != server.pid
           begin
             sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
             Process.kill(sig, File.read(old_pid).to_i)
           rescue Errno::ENOENT, Errno::ESRCH
           end
         end
       end
       
       
       after_fork do |server, worker|
         defined?(ActiveRecord::Base) and ActiveRecord::Base.establish_connection
         begin
           worker.user($unicorn_user,$unicorn_group)
         rescue => ex
           STDERR.puts "could not change user, oh well"
           STDERR.puts ex.to_s
           raise ex
         end
       end
       
       # 

     • sudo unicorn_rails -c config/unicorn.rb -E production -D でunicornが起動する。
   • NGiNXの設定
     • NGiNX.confを修正する

               upstream REDMINE {
                       server unix:/var/run/unicorn.sock;
               }
               server {
                       listen 80 sndbuf=16k
                       server_name     redmine.example.net;
                       location / {
                               proxy_pass                      http://REDMINE;
                       }
               }

これで、とりあえず、Redmineまでは動くはず。

• 参考: http://www.virment.com/ubuntu-nginx-unicorn-rails/

Last update: 2017/02/06 : Check on FreeBSD 11

VulsというToolが公開されている。https://github.com/future-architect/vuls/blob/master/README.ja.md

要するに、Linux(現時点ではUbuntu, Debian, CentOS, Amazon Linux, RHEL)及びFreeBSDに対する脆弱性検出ツールである。 誤解する人もいるみたいだが、このツールは脆弱性を「検出」するだけであって、対処(pkgのUpgradeとか)はしない。 対象のServerにsshでloginして、様々な情報を持ってくることでそのシステム内の脆弱性を検出する。 したがって、rootでsshするという操作になる。（ただし、これは現在改良中らしい)

Vulsは、Goで動作する。散々わがままを言った挙句、VulsはFreeBSD上でも問題なく動作した。

• FreeBSD 11.0をInstallする
  • いつもの通りで良い。難しいことはなに一つしない。
  • pkg install go git sqlite3
    • 2017/02/06時点では必要なかったが、場合によってはgccを入れておくこと。
• vulsを実行するAccountを作成し、sshの鍵を生成する(ここでは、仮にmonitorとする)
  • vuls関連のDBなどは全て~monitor下に配置する
  • adduserなどでアカウントを作成。
  • ssh鍵関連の設定
    • cd ~monitor
    • sudo -u monitor ssh-keygen -t ed25519
    • cat ~/.ssh/id_ed25519.pub » ~/.ssh/authorized_keys
    • chmod 600 ~/.ssh/authorized_keys
      • 公開鍵は、検査対象マシンのauthorized_keysにも転記しておくこと
  • vuls Install前の準備
    • mkdir /var/log/vuls
    • chown monitor /var/log/vuls
    • comod 700 /var/log/vuls
  • 環境の整備
    • .profileに以下を記述

    • export GOPATH=$HOME/go
      export PATH=$PATH:$GOPATH/bin

      • 注意点。$GOROOTは設定しないこと。迂闊に設定すると色々ハマるので、自分で何をやっているかわからない人は触らないのが吉
      • go関係の実行ファイルなどは、$GOPATH内に配置される。
  • go-cve-directonary をinstallする
    • mkdir -p $GOPATH/src/github.com/kotakanbe
    • cd $GOPATH/src/github.com/kotakanbe/
    • git clone https://github.com/kotakanbe/go-cve-dictionary.git
    • cd $GOPATH/src/github.com/kotakanbe/go-cve-dictionary
    • make install
      • cc関連でWarningが出る。これは、FreeBSDのccはclangであり、gccではないため。

    • for i in 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017; do
      go-cve-dictionary fetchnvd -years $i
      go-cve-dictionary fetchjvn -years $i	# もしJVNの情報が要らないならば、ここはskipしても良い
      done

      • 自分はbashを使わないのでこんな迂遠なことになるが、bashなら for i in {2002..2017}; do go-cve-dictionary fetchnvd -years $i; done で行ける
      • ここは時間がかかるので覚悟すること。（昔と比べると本当に早くなったけど）
        • 2017/02/06現在、作成されるDBファイルは、以下のようになった。

        • -rw-r--r--  1 monitor  staff  740999168 Feb  6 12:38 cve.sqlite3
          -rw-r--r--  1 monitor  staff      32768 Feb  6 12:39 cve.sqlite3-shm
          -rw-r--r--  1 monitor  staff   22956672 Feb  6 12:39 cve.sqlite3-wal

  • vuls をinstallする
    • mkdir -p $GOPATH/src/github.com/future-architect
    • cd $GOPATH/src/github.com/future-architect
    • git clone https://github.com/future-architect/vuls.git
    • cd $GOPATH/src/github.com/future-architect/vuls
    • make install
      • cc関連でWarningが出る。これは、FreeBSDのccはclangであり、gccではないため。
    • go get github.com/future-architect/vuls
    • vulsのdictionary serverを起動する。
      • go-cve-dictionary server
  • 設定ファイルを作成する
    • 設定ファイルをどこに置くかは少し問題になる部分だが、今回は、~monitor/vuls下にvuls関連のファイルを全部置く前提で行く。

    • config.toml

      [servers]
      
      [servers.example]
      host         = "192.0.2.1"
      port        = "22"
      user        = "monitor"
      keyPath     = "/home/vuls/.ssh/id_rsa"

  • 対象となるServerに必要な設定を突っ込む
    • 対象となるホストに、config.tomlに記載したアカウントを作成する(仮にmonitorとする)
    • ~monitor/.sshにauthorized_keysを設置する
    • visudoを実行し、monitorがno passwordでroot権限を取得できるように設定する
      • monitor ALL=(ALL) NOPASSWD: ALL
      • 将来的には、実行できるコマンドを制限するべきだが、とりあえず今はこれで。
    • vulsを動作させるServerから対象のサーバーにsshで接続でき、かつsudoを実行してpasswordなしでrootになれることを確認する
  • ここまでできたら、vuls prepareを実行する
    • エラーが出たら、何らかのpermissionがおかしいなどが考えられるので、対応する
      • どうしても分からなければ、vulsのslackに報告するか、gitでissueを上げる
  • で、最後にscanする。
    • vuls scan

まだまだ考える必要がある部分はあるが、なかなか素晴らしい。

• Issue
  • Dictionary Serverの扱い
    • daemon的に動かし続けるのがいいのか、vulsを実行する際に起動するのがいいのか？
      • dailyでauto scanかけるなら、動かし続けるのもいいのだが… localhostからしか接続を許可していないからよしとするか？
  • CPEの設定
    • これは、やはり様々なSampleが欲しいところ。