トップ «前の日記(2018-11-01) 最新 次の日記(2018-11-03)» 編集

ヨタの日々

2001|08|09|10|11|12|
2002|01|02|03|04|05|06|07|08|09|10|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|12|
2024|01|02|03|04|

2018-11-02 :-|

_

調査労

_ [OpenSSL][TLS]Different version TLS in record layer and handshake layer · Issue #1689 · openssl/openssl

TLS の ClientHello したときに record layer にある version (TLS 1.0) と handshake layer にある version (TLS 1.2)が一致しない件。

OpenSSL の仕様です。とのこと。というか実装依存。

TLS 1.2 は RFC 5246 なので仕様を読むと

RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2

record layer について。github の issue ではここが TLS 1.0 になっていると言ってます。

6.2.1. Fragmentation

   version
      The version of the protocol being employed.  This document
      describes TLS Version 1.2, which uses the version { 3, 3 }.  The
      version value 3.3 is historical, deriving from the use of {3, 1}
      for TLS 1.0.  (See Appendix A.1.)  Note that a client that
      supports multiple versions of TLS may not know what version will
      be employed before it receives the ServerHello.  See Appendix E
      for discussion about what record layer version number should be
      employed for ClientHello.

handshake の ClientHello について。github の issue ではここが TLS 1.2 もなっていると言ってます。

7.4.1.2. Client Hello

   client_version
      The version of the TLS protocol by which the client wishes to
      communicate during this session.  This SHOULD be the latest
      (highest valued) version supported by the client.  For this
      version of the specification, the version will be 3.3 (see
      Appendix E for details about backward compatibility).

_ [RAID]RAID

RAID ‐ 通信用語の基礎知識

RAID は 0 〜 6 ある。ストライピングはデータを分割するだけ。可用性はない。RAID6 がナウい。

  • RAID0 ‐ ストライピング
  • RAID1 ‐ ミラーリング
  • RAID2 ‐ ECCエラー検出訂正
  • RAID3 ‐ ストライピング(バイト)とパリティドライブ(固定)
  • RAID4 ‐ ストライピング(ブロック)とパリティドライブ(固定)
  • RAID5 ‐ ストライピング(ブロック)とパリティドライブ(分散)
  • RAID6 ‐ ストライピング(ブロック)とパリティドライブ(分散)

RAID - Wikipedia

RAID0。データを分割し、複数台のハードディスクに同時に分散して読み書きする。高速化が可能となる。最低 2 ドライブ必要

RAID0.png

RAID1。複数台のハードディスクに、同時に同じ内容を書き込む。最低 2 ドライブ必要。

RAID1.png

RAID3。最低 3 ドライブで構成され、1台を誤り訂正符号に割り当て、残りの複数台にデータを記録する。

RAID3.png

RAID4。RAID4 は RAID3 の I/O 単位をブロックに拡大し、I/O 効率の改善を図ったものである。最低 3 台で構成される。

RAID4.png

RAID5。水平パリティを使用して複数のハードディスクに誤り訂正符号データと共に分散させて記録することで、RAID3、RAID4のボトルネックを回避している。最低3ドライブが必要である。

RAID5.png

RAID6。任意の2つのハードディスクに障害が発生してもデータが復元できるRAIDである。冗長データを2種類作成し2つのディスクに記録することで、2重障害に対応でき、同時に2ドライブが故障しても復元できる。最低4ドライブを必要とする。

RAID6.png

_ [RAID][Linux]RAID の作り方

kernel.org 公式 RAID setup - Linux Raid Wiki

みんな大好き Arch Linux RAID - ArchWiki

atmarkit に 10 年以上前の記事があるけど HDDを2台追加してRAID 1を構成するには- @IT

fdisk で指定している値は 0xFD ですが、 Arch Linux によると現在は 0xDA が推奨されているとのこと。

MBR パーティションテーブルの HDD にパーティションを作成する場合、使用するパーティションタイプは以下になります:

0xDA (ファイルシステム以外のデータ用 -- 現在 kernel.org によって推奨されています)
0xFD (raid の自動検出アレイ -- initrd を起動してカーネルモジュールをロードするようになるまでは使われていました)

_ [NAS][btrfs]btrfs

NAS で利用されるファイルシステムとして ZFS, btrfs で覇権を争っているという話題があるとかないとか(ext4? 知らない子ですね)

「ばたーえふえす」と読むらしい。

Btrfs - Wikipedia

Btrfs(B-tree file system : バター エフエス、またはB木 『ビーツリー』 エフエスと読む[1][2])

いくつかのRAIDアルゴリズム (RAID-0, RAID-1, RAID-5, RAID-6, RAID-10) とともに、複数のデバイスをサポートするためのデバイスマッパとの強い統合

この辺りの特徴により NAS として使いやすいんでしょうか。分からん。

Btrfs の公式 wiki btrfs Wiki

参考までにみんな大好き Arch Linux のページ Btrfs - ArchWiki

Synology は Btrfs を採用しています Btrfs が大切なデータを保護する方法 - Synology Inc.

_ [Apache][nginx]Apache と nginx

高速・軽量・高機能……Nginxの基礎知識 (1/2):これから始める人のためのNginx(1) - @IT

Nginxの名前が知られるようになったのは、C10K問題(クライアント1万台問題、注2)が叫ばれるようになった2000年代後半です。当時、いくらハードウェアスペックが高くなっても、Apache HTTPのように、1つのリクエストを処理するのに1プロセスや1スレッドを割り当てていると、プロセス番号やスレッドスタックのようなソフトウェアリソースが枯渇し、万単位のクライントを処理できなくなるといった問題が現実味を帯び始めていました。その解決策の1つとしてNginxが注目されるようになりました。

NginxはこうしたWebサイトの潮流にも対応しており、リバースプロキシとして動作させることができます。フロントにNginxを、バックエンドにアプリケーションサーバーを複数台用意し、Nginxでバランシングさせれば「ロードバランサー」として機能させることも可能です。

NiginxはHTTPSのSSL/TLSにも対応しているため、HTTPSに対応していないアプリケーションサーバーの替わりにHTTPSリクエストを終端し、「SSL/TLSアクセラレーター」として使用するこもできます。

他に、画像やHTMLテキストといった静的コンテツをキャッシュすることも可能です。その上、HTTPやHTTPS以外にも、SMTP、IMAP、POP3といったプロトコルのバランシングも可能。HTTPの次世代版として注目を集めている「SPDY」にも早速対応しています。

nginx は

  • クライアントからのリクエストの 1 次切り分けとしての役割を担う。
  • HTTP だけでなく SMTP など多様なアプリケーションプロトコルにも対応できる。
  • 「SSL/TLSアクセラレーター」というのは、ようするにプロキシです。クライアントとの SSL/TLS 通信を nginx で終端します。だからパケットキャプチャするとクライアントとの SSL/TLS 通信は nginx とやりとりされる(と思う。知らんけど)

_ [形態素解析][mecab][ruby][natto]mecab の ruby バインディング natto を使う

和布蕪に納豆とな。ネバネバ

環境

Arch Linux です。

% uname -rsm
Linux 4.18.10-arch1-1-ARCH x86_64
% ruby -v
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]

mecab

mecab は言わずもがな形態素解析器です MeCab: Yet Another Part-of-Speech and Morphological Analyzer

インストール。pacman には在りません。とりあえず IPA 辞書を使う。

% yaourt -S mecab
% yaourt -S mecab-ipadic

動作確認します。

形態素解析。

% echo 吾輩は猫である | mecab                                       
吾輩	名詞,代名詞,一般,*,*,*,吾輩,ワガハイ,ワガハイ
は	助詞,係助詞,*,*,*,*,は,ハ,ワ
猫	名詞,一般,*,*,*,*,猫,ネコ,ネコ
で	助動詞,*,*,*,特殊・ダ,連用形,だ,デ,デ
ある	助動詞,*,*,*,五段・ラ行アル,基本形,ある,アル,アル
EOS

分かち書き。

% echo 吾輩は猫である | mecab -O wakati
吾輩 は 猫 で ある 

natto

buruzaemon/natto: A Tasty Ruby Binding with MeCab

インストール

% gem install natto

なお natto は libmecab.so を要求するので libmecab.so の PATH を環境変数に設定などする必要がありんす。

使ってみる

require 'natto'

txt = '吾輩は猫である'

ENV['MECAB_PATH'] = '/usr/lib/libmecab.so'
nm = Natto::MeCab.new
puts nm.parse(txt)
% ruby natto00.rb
吾輩	名詞,代名詞,一般,*,*,*,吾輩,ワガハイ,ワガハイ
は	助詞,係助詞,*,*,*,*,は,ハ,ワ
猫	名詞,一般,*,*,*,*,猫,ネコ,ネコ
で	助動詞,*,*,*,特殊・ダ,連用形,だ,デ,デ
ある	助動詞,*,*,*,五段・ラ行アル,基本形,ある,アル,アル
EOS

分かち書き。mecab へのオプションは new に渡す。

require 'natto'

txt = '吾輩は猫である'

ENV['MECAB_PATH'] = '/usr/lib/libmecab.so'
nm = Natto::MeCab.new('-O wakati')
puts nm.parse(txt)

実行

% ruby natto01.rb
吾輩 は 猫 で ある 

_ [Azure][感情分析][ruby]Microsoft Azure の Text Analytics を使ってみる

Text Analytics とは - Azure Cognitive Services - Microsoft Docs

Text Analytics API は、未加工のテキストに対して高度な自然言語処理を実行できるクラウドベースのサービスであり、主要な機能として感情分析、キー フレーズ抽出、言語検出、エンティティ リンク設定の 4 つを備えています。

制限は以下のとおり。String.Length とは何か。

制限
1 つのドキュメントの最大サイズString.Length で測定される 5,000 文字。
要求全体の最大サイズ1 MB
1 件の要求での最大ドキュメント数1,000 ドキュメント

ただ、Azure の無料アカウントを今すぐ作成しましょう - Microsoft Azure にAzure Cognitive Services が含まれてないので、たぶん 12 ヶ月の試用だと思う。

Azure アカウントを作成する

Azure は手順通りにアカウントを作ります。

API を使ってみる

今回は感情分析を使ってみます。

クイック スタート: Ruby を使用して Text Analytics API を呼び出す - Azure Cognitive Services | Microsoft Docs

とりあえずコードをコピペします。テキストは、アニソンでも最高にエモい歌詞を作る畑亜貴作詞の「ユメ語るよりユメ歌おう」(Aqours)。なお畑亜貴本人はけっこう退廃的な感じです。

require 'net/https'
require 'uri'
require 'json'

accessKey = 'アクセスキーを記載する'

uri = 'https://japaneast.api.cognitive.microsoft.com'
path = '/text/analytics/v2.0/sentiment'

uri = URI(uri + path)

documents = { 'documents': [
    { 'id' => '1', 'language' => 'ja', 'text' => '大好きなメロディーのつながりだよね もう逃げないで 進む時だよ 新しい場所へ' },
    { 'id' => '2', 'language' => 'en', 'text' => 'Singing my song for my dream!' },
  ]
}

puts 'Please wait a moment for the results to appear.'

request = Net::HTTP::Post.new(uri)
request['Content-Type'] = "application/json"
request['Ocp-Apim-Subscription-Key'] = accessKey
request.body = documents.to_json

response = Net::HTTP.start(uri.host, uri.port, :use_ssl => uri.scheme == 'https') do |http|
    http.request (request)
end

puts JSON::pretty_generate (JSON (response.body))

実行してみます。

% ruby azure-textanalyze01.rb
Please wait a moment for the results to appear.
{
  "documents": [
    {
      "id": "2",
      "score": 0.9770480990409851
    },
    {
      "id": "1",
      "score": 0.4914383888244629
    }
  ],
  "errors": [

  ]
}