2019/04/17(水)新元号の対応

弊社の現在公開しているページ( https://www.basekernel.co.jp/ )にて確認作業していたので、ひょっとしたら見た人がいたかもしれませんが・・・
#限りなくゼロに近いと思っているが。。

20190417_1.png

20190417_2.png

20190417_3.png

20190417_4.png

20190417_5.png


ま、こんな感じにしました。西暦2019年は、4/30,5/2 も祝日法に基づくと、
西暦2019年限定で休日になります。

ちなみに今年と来年は、オリンピックもあり、特例の祝日が結構あるんです。

2019/03/01(金)ディジタル証明書の形式 pem と der

https:// 接続などでサーバ証明書を扱ったことがある方は、下記フォーマットを見たことがあると思います。
※現在、実運用で使っていませんが念のため一部端折っています。
-----BEGIN CERTIFICATE-----
MIIC4TCCAkqgAwIBAgIBADANBgkqhkiG9w0BAQUFADB4MQswCQYDVQQGEwJKUDER
MA8GA1UECBMISG9ra2FpZG8xGzAZBgNVBAoTEkJhc2UgS2VybmVsIENvIEx0ZDEg
MB4GA1UECxMXTmV0d29yayBPcHJhdGlvbiBDZW50ZXIxFzAVBgNVBAMTDkJhc2Ug
S2VybmVsIENBMB4XDTA4MDcxMzEzMTU0NVoXDTI4MDcxMzEzMTU0NVoweDELMAkG

・・・・一部省略・・・・

A1UEBhMCSlAxETAPBgNVBAgTCEhva2thaWRvMRswGQYDVQQKExJCYXNlIEtlcm5l
+6EEruiOlNKYnViRTdjEoAPRYfgM+eqjnfbVOxB0wEV7w5GjcqbGe9ePrEUs1wYS
ktnZC7H0p5H01z92udKE3BaCEACQ
-----END CERTIFICATE-----
これは、pem 形式と呼ばれるディジタル証明書で、通常はこの形式で管理します。
ところが、時々、 der 形式しか受け付けないディジタル証明書アプリケーションがあるのです。

今回、コントロールパネルのサーバ設定部分の一部が時代に合わなくなっていて、この部分の改良を施しているところで、その一環でサーバ証明書をある程度自力管理できるようにしているのですが、その過程でディジタル証明書の内容を解析する Perl モジュールに Crypt::X509 という便利なものがあってそれを使おうとしたら、このモジュールが der 形式しか対応していないのです。

もっと便利そうなものに Crypt::OpenSSL::X509 というのがあるが、今のところ、OpenSSL 1.x 系への対応があまり芳しくなく、避けざるを得ない状況。

der 形式はバイナリファイルなので扱いにくいのです。ただ、具体的中身まではよく知りません。
調べると、 pem 形式ファイルの -----BEGIN CERTIFICATE----- 行と、-----END CERTIFICATE----- 行を取っ払った残りの部分を、Base64 デコードしてあげればいいだけであることが判りました。

つまり、pem 形式は、der 形式で生成したディジタル証明書のデータ構造を Base64 エンコードして、-----BEGIN CERTIFICATE----- 行と、-----END CERTIFICATE----- 行を付け足しただけなのです。

ここまで判れば、ディジタル証明書の内容確認は、Perl でやる場合は以下の要領で出来ます:
#!/usr/local/bin/perl

use MIME::Base64 ;                                     # Base64ライブラリ使用宣言
use Crypt::X509 ;                                      # 証明書内容参照ライブラリ使用宣言

$csr_pem = "" ;
$status  = open (CSRPEM,"hoge.pem") ;
if ($status) {
  local $/ = undef ; $csr_pem = <CSRPEM> ; close(CSRPEM) ;
}

$csr_pem =~ /\-\-\-\-\-BEGIN\s+CERTIFICATE\-\-\-\-\-(.+)\-\-\-\-\-END\s+CERTIFICATE\-\-\-\-\-/s ;
$x509_tmp = $1 ;
%outstr   = {} ;

$x509_decode = Crypt::X509->new(cert => decode_base64($x509_tmp)) ;
@nb = localtime($x509_decode->not_before) ;
@na = localtime($x509_decode->not_after) ;
@jw = ('日','月','火','水','木','金','土') ;
$outstr{'not_before'}     = sprintf("%d/%02d/%02d(%s) %02d:%02d:%02d",$nb[5] + 1900,$nb[4] + 1,$nb[3],$jw[$nb[6]],$nb[2],$nb[1],$nb[0]) ;
$outstr{'not_after'}      = sprintf("%d/%02d/%02d(%s) %02d:%02d:%02d",$na[5] + 1900,$na[4] + 1,$na[3],$jw[$na[6]],$na[2],$na[1],$na[0]) ;

$outstr{'subj_country'}   = $x509_decode->subject_country ;
$outstr{'subj_state'}     = $x509_decode->subject_state ;
$outstr{'subj_local'}     = $x509_decode->subject_locality ;
$outstr{'subj_org'}       = $x509_decode->subject_org ;
$outstr{'subj_ou'}        = $x509_decode->subject_ou ;
$outstr{'subj_cn'}        = $x509_decode->subject_cn ;

$outstr{'issuer_cn'}      = $x509_decode->issuer_cn ;
$serial16 = sprintf("%X",$x509_decode->serial) ;
$serial16 =  '0' . $serial16 if (length($serial16) % 2) ;
1 while $serial16 =~ s/^([\da-fA-F]+)([\da-fA-F][\da-fA-F])/$1\:$2/ ;
$outstr{'issuer_serial'}  = $serial16 ;
$outstr{'issuer_country'} = $x509_decode->issuer_country ;
$outstr{'issuer_state'}   = $x509_decode->issuer_state ;
$outstr{'issuer_local'}   = $x509_decode->issuer_locality ;
$outstr{'issuer_org'}     = $x509_decode->issuer_org ;
$outstr{'sigalgo'}        = $x509_decode->sig_algorithm ;
上記サンプルにて、連想配列 %outstr に表示可能な文字列にて解析内容が入ります。
参考:https://metacpan.org/pod/Crypt::X509

2019/02/13(水)perl にて IPv4 と IPv6 のデュアルスタックサーバを作る

Perl において、この用途には IO::Socket::INET というコアモジュールが広く使われていて、
ちまたにはこれを、IO::Socket::IP に変えるだけで IPv4/IPv6 デュアルスタックが実現するかのような話が広く知られているようだが、実際はどうも違う模様。。

今まで IPv4 で動作していたこのコード:
#!/usr/local/bin/perl
#
use utf8 ; binmode(STDOUT, ":utf8") ;
use IO::Socket::INET ;                     # ソケットインタフェース使用宣言

$comm_queue  = 5 ;                         # コネクション待ち受けキューの数
$port        = 9999 ;                      # port no.

### 通信ソケット生成
# ソケットオープン
$reqsock = IO::Socket::INET->new (LocalPort => $port,
                                  Listen    => $comm_queue,
                                  Proto     => 'tcp',
                                  Reuse     => 1,
                                 ) ;
if (not $reqsock) {
  err_trap("通信ソケットが作成できません。",$!) ;
  exit ;
}

### サーバメインルーチン
for (;;) {
  $sock = $reqsock->accept() ;
  if (not $sock) {
    err_trap("クライアントの要求受け付けに失敗しました。(accept error)",$!) ;
    exit ;
  }

  if ($child = fork()) {
  # 親プロセスの実行コード
    $sock->close() ;
    waitpid($child,0) ;
    next ;                                 # 次のコネクション要求を待つ

  } elsif (defined($child)) {
  # 子プロセスの実行コード(メインルーチン)
    $reqsock->close() ;
    select($sock) ; $| = 1;                # 常に flash するようにする
    select(STDOUT) ;
    binmode $sock ,':encoding(UTF-8)' ;

  以下、サーバの処理プログラム・・・・
  }
}
IO::Socket:INET の部分を、IO::Socket::IP に書き換えても、IPv6 しか受け付けない状態になります。
もしかしたら、IPv4射影アドレスを使えばいいのかもしれないですが、現状環境には全く合わない。

試行錯誤の結果、以下で動作する模様:
#!/usr/local/bin/perl
#
use utf8 ; binmode(STDOUT, ":utf8") ;
use IO::Socket::INET ;                     # IPv4 Socket インタフェースライブラリ使用宣言
use IO::Socket::INET6 ;                    # IPv6 Socket インタフェースライブラリ使用宣言
use IO::Select ;

$comm_queue  = 5 ;                         # コネクション待ち受けキューの数
$port        = 9999 ;                      # port no.

### 通信ソケット生成
$select = IO::Select->new ;

# ソケットオープン[IPv6]
$psock6 = IO::Socket::INET6->new (LocalPort => $port,
                                  Listen    => $comm_queue,
                                  Type      => SOCK_STREAM,
                                  Reuse     => 1,
                                  Proto     => "tcp"
                                 ) ;
if (not $psock6) {
  err_trap("通信ソケットが作成できません。[IPv6]",$!) ;
  exit ;
} else {
  $select->add($psock6) ;
}

# ソケットオープン[IPv4]
$psock4 = IO::Socket::INET->new (LocalPort => $port,
                                 Listen    => $comm_queue,
                                 Type      => SOCK_STREAM,
                                 Reuse     => 1,
                                 Proto     => "tcp"
                                ) ;
if (not $psock4) {
  err_trap("通信ソケットが作成できません。[IPv4]",$!) ;
  exit ;
} else {
  $select->add($psock4) ;
}

### サーバメインルーチン
for (;;) {
  while (my @ready = $select->can_read) {
    foreach my $reqsock (@ready) {
      $sock = $reqsock->accept() ;
      if (not $sock) {
        err_trap("クライアントの要求受け付けに失敗しました。(accept error)",$!) ;
        exit ;
      }

      if ($child = fork()) {
      # 親プロセスの実行コード
        $sock->close() ;
        waitpid($child,0) ;
        next ;                                 # 次のコネクション要求を待つ

      } elsif (defined($child)) {
      # 子プロセスの実行コード(メインルーチン)
        select($sock) ; $| = 1;                # 常に flash するようにする
        select(STDOUT) ;
        binmode $sock ,':encoding(UTF-8)' ;

      以下、サーバの処理プログラム・・・・
      }
    }
  }
}
参考になったのは、これ → How best to support IPv4/v6 in Perl server

2019/01/25(金)FreeBSD 12.0 カーネルにバグか

弊社管理サーバ19台の内、5台のサーバを FreeBSD12 に更新したのですが、そのうちの1台だけ、不定期に時折 Panic を起こして再起動を繰り返すサーバが・・・

ログメッセージにこんな感じで現れます:
Jan 25 04:15:46 uranus kernel: Fatal trap 12: page fault while in kernel mode
Jan 25 04:15:46 uranus kernel: cpuid = 1; apic id = 01
Jan 25 04:15:46 uranus kernel: fault virtual address    = 0xd8
Jan 25 04:15:46 uranus kernel: fault code               = supervisor read data, page not present
Jan 25 04:15:46 uranus kernel: instruction pointer      = 0x20:0xffffffff8091527d
Jan 25 04:15:46 uranus kernel: stack pointer            = 0x28:0xfffffe00185b9560
Jan 25 04:15:46 uranus kernel: frame pointer            = 0x28:0xfffffe00185b96b0
Jan 25 04:15:46 uranus kernel: code segment             = base 0x0, limit 0xfffff, type 0x1b
Jan 25 04:15:46 uranus kernel:                  = DPL 0, pres 1, long 1, def32 0, gran 1
Jan 25 04:15:46 uranus kernel: processor eflags = interrupt enabled, resume, IOPL = 0
Jan 25 04:15:46 uranus kernel: current process          = 0 (if_io_tqg_1)
Jan 25 04:15:46 uranus kernel: trap number              = 12
Jan 25 04:15:46 uranus kernel: panic: page fault
Jan 25 04:15:46 uranus kernel: cpuid = 1
Jan 25 04:15:46 uranus kernel: time = 1548357259
Jan 25 04:15:46 uranus kernel: KDB: stack backtrace:
Jan 25 04:15:46 uranus kernel: #0 0xffffffff8077a8c7 at kdb_backtrace+0x67
Jan 25 04:15:46 uranus kernel: #1 0xffffffff8072e4b3 at vpanic+0x1a3
Jan 25 04:15:46 uranus kernel: #2 0xffffffff8072e303 at panic+0x43
Jan 25 04:15:46 uranus kernel: #3 0xffffffff80a6496f at trap_fatal+0x35f
Jan 25 04:15:46 uranus kernel: #4 0xffffffff80a649c9 at trap_pfault+0x49
Jan 25 04:15:46 uranus kernel: #5 0xffffffff80a63fee at trap+0x29e
Jan 25 04:15:46 uranus kernel: #6 0xffffffff80a3f825 at calltrap+0x8
Jan 25 04:15:46 uranus kernel: #7 0xffffffff808feb43 at tcp_input+0x1553
Jan 25 04:15:46 uranus kernel: #8 0xffffffff80876a55 at ip_input+0x145
Jan 25 04:15:46 uranus kernel: #9 0xffffffff8084f496 at netisr_dispatch_src+0xd6
Jan 25 04:15:46 uranus kernel: #10 0xffffffff80833d83 at ether_demux+0x163
Jan 25 04:15:46 uranus kernel: #11 0xffffffff80834ee6 at ether_nh_input+0x346
Jan 25 04:15:46 uranus kernel: #12 0xffffffff8084f496 at netisr_dispatch_src+0xd6
Jan 25 04:15:46 uranus kernel: #13 0xffffffff80834184 at ether_input+0x54
Jan 25 04:15:46 uranus kernel: #14 0xffffffff8084b646 at iflib_rxeof+0xa16
Jan 25 04:15:46 uranus kernel: #15 0xffffffff80846476 at _task_fn_rx+0x76
Jan 25 04:15:46 uranus kernel: #16 0xffffffff80779154 at gtaskqueue_run_locked+0x144
Jan 25 04:15:46 uranus kernel: #17 0xffffffff80778db8 at gtaskqueue_thread_loop+0x98
Jan 25 04:15:46 uranus kernel: Uptime: 4h16m16s
Jan 25 04:15:46 uranus kernel: ---<<BOOT>>---
どうも、これに似ている模様・・・:
Bug 234296 - FreeBSD 12.0-STABLE r342216 Fatal trap 12

IPv4,IPv6 を直接扱う部分のようです。どうやら解決をみたらしいのですが、まだリリースバージョンへの反映はなされていません。FreeBSD12 への更新は様子見したほうがよさそう。

〔2019/02/06(Wed)追記〕
 昨日、リリースバージョン向けの対策版(FreeBSD 12.0-p3) が公開されたので、早速、本日未明から午前中にかけてFreeBSD 12 を稼働させている5台のサーバに対し、この不具合対策を行いました。
 数日様子を見て、安定しているようであれば他のサーバも FreeBSD12 に更新予定。

〔2019/02/28(Thu)追記〕
 どうも根本解決には至らない模様。頻度は減ったものの、5~6日経つと、勝手にリブートを繰り返します。
 なので、FreeBSD12 を運用環境に持ってくるのはお勧めできません。当面 FreeBSD 11系でやり過ごすことにします。

〔2019/08/02(Fri)追記〕
 Patch 7(FreeBSD12.0R-p7) あたりで安定した模様。引き続き、しばらく様子を見ます。

2018/06/04(月)IPv6の基礎(6) - 機器設定時に必要と思われる知識

このあたりから徐々に佳境になっていきます。
この後、IPv6を理解するために、2進数や16進数の知識が必要になってきます。
といっても、この知識がある方にとってこの項目は冗長なので、ここは読み飛ばしても差し支えありません。
20180605_2.png


今までさり気なく、IPv6アドレスを例示してきましたが、アルファベットが混じっていることにお気づきかと思います。
これは、「16進数」という情報処理系分野でごく普通に使われている数理方式で、普段我々が使う10進数の0~9の10個の数字に加えて、a ~ f のアルファベット6文字を加えて16進数としているのです。
つまり、16進数において、a ~ f は数字なのです。尚、a ~ f のアルファベットは、大文字でも構わないのですが、現在では、一般的に小文字の使用が強く推奨されています。

16進数が多用される理由は、コンピュータ(情報処理機器)との相性が良いからです。
10進数と2進数・16進数との相互変換を使う場面は、IPv6設定においては多くありません。(たまに必要になる場合があるが。。)

コンピュータは、2進数で内部処理の一切を行いますが、0と1の2つの数字しか使わない(だから2進数)ため、大きな数字を表現しようとすると、必然的に桁数が多くなります。

IPv6 アドレスを2進数で表現すると、128桁(128bit)にもなります。2進数4桁をひとまとめにすると、16進数1桁に上手く収まるので、4分の1になる上に、相互変換もやりやすくなります。

尚、一般的に「1バイト」といえば、16進数2桁,8ビットですが、そうでない場合もあるらしく、通信関係では代わりに「オクテット」がよく用いられます。
同じく、16進数2桁,8ビットが「1オクテット」です。

2018/04/10(火)IPv6の基礎(3) - 機器設定時に必要と思われる知識

今回は、IPv6 対応の機器に IPv6 アドレスを設定するときの記述方法です。
20180326_2.png
IPv6 アドレスは記述自体が長くなるため、一定の省略記述ルールが決められています。
しかしながら、必ずしも省略記述をする必要はありません。
むしろ、慣れないうちは敢えて省略記述をしない方がよいのです。

ですが、実際には先駆者によって多用されているので、ここでは省略記述ルールを紹介します。
「省略記述」は全て、数字の'0' (ゼロ) を省略するルールが定義されています。

先ず、「各フィールドの上位桁の'0'は省略可能」です。ただし、'0000' だけは全てを省略せずに'0'を記述します。
次に、「'0000' のフィールドが連続する場合は、該当部分を '::'(ダブルコロン)で省略可能」です。
但し、これが使えるのは1回だけです。

また、'::'(ダブルコロン)は、最も長く省略できる部分に適用すべき、と規定されました。
なので、厳密には上記例の3番目も×です。
2番目の 2001:db8:0:3::1 のみが正解となります。

更に、IPv6 表記でしか設定できない環境下で、IPv4を表記する場合の記述法も定義されています。
現在は、「IPv4 射影アドレス」の記法がよく用いられており、「IPv4 組み込みアドレス」は淘汰方向現在は廃止(使用不可)です。[RFC6890] 参照。
ただし、「IPv4 組み込みアドレス」もたまにみかけるので、知っておくとよいです。

2018/03/28(水)IPv6 の基礎(2) - ネットワーク機器類の取扱説明書を見る時、得意になれそうな知識

不定期掲載のIPv6基礎ネタ第2号です。

今さら誰にも聞けないレベルになりつつある内容ですが、この「備忘録」が役立てば幸いということで。。
今後、従来からのIPプロトコルは、IPv6 と区別するために IPv4 と称することにします。
世の中での表記区別がそうなっているため、それらに倣うことにしました。

今回はIPv6 アドレスの形式です。
20180326_1.png
IPv4 では当初、クラスA,クラスB、クラスC、クラスD、クラスE というカテゴリ分けで、IPアドレスブロックの割り当てがされ、サブネットマスクは固定でした。
以下のような感じです:

クラスA  1 ~ 126 で始まるIPアドレス (サブネットマスク 255.0.0.0)
クラスB 128 ~ 191 で始まるIPアドレス (サブネットマスク 255.255.0.0)
クラスC 192 ~ 223 で始まるIPアドレス (サブネットマスク 255.255.255.0)
クラスD 224 ~ 239 で始まるIPアドレス (サブネットマスク 255.255.255.255)
クラスE 240 ~ 254 で始まるIPアドレス

このうち、クラスDはマルチキャスト通信専用で使われており、クラスEは各種実験・特殊用途向けで一般利用はできないことになっています。
0と255で始まるIPv4 アドレスは仕様的に使用不可、127で始まるIPv4アドレスは、ループバック専用で、これは用途が仕様として強制されています。

クラスDにサブネットマスクの概念そのものがなく、クラスEには、サブネットマスクの規定はありません。
#なので、クラスEの領域は実際は「IPv4 枯渇を無視して割り当てされずに温存されて」います。

クラスA,クラスB、クラスCのサブネットマスクは、1992年6月に RFC1338 で初めて CIDR(「サイダー」と称する模様) と言うクラス分けをバッサリと捨てる概念(=クラスレス化)が提唱され、 1993年9月の RFC1519 を経て、2006年8月に RFC4632 で現行のものになりました。

さて、IPv4 は、アドレスが4オクテット(4バイト)固定長で構成されます。
1オクテットずつ、ドット区切りの10進数で表記するのが通例です。
1オクテットで表現できる10進数の整数は0~255 なので、各ドット間の数字は必ず0~255の範囲になります。

これに対して、IPv6 は、アドレスが16オクテット(16バイト)固定長で構成されます。
実にIPv4アドレス総数(約43億)の 232倍 × 232倍 × 232倍 = 2128 個(約340澗 ≒3.4 ×1038) になり、『これだけあればアドレス枯渇問題は将来に亘ってほぼ皆無だろう』ということになっています。

アドレス表記も16進数表記です。これはエンジニアの間では常識ですが、16進数のほうがディジタル機器のあらゆる整数数値において親和性が非常に高いためです。
16進数表記の a ~ f は、基本的に小文字を使うように規定されています。[RFC5952, 2010年8月]

「16進数」がわからない方は、google などを使って各自調べてください。
合わせて「2進数と16進数」の関連を知ることで、何故16進数の方が親和性が非常に高いかが理解できるかもしれません。

IPv6 のアドレスは、2オクテット(2バイト)毎にコロンで区切って表記します。
そして、コロンで区切った各々の部分は「フィールド」と呼称します。
このフィールドは、省略表記(別記事にて後述)しない限り、桁数は4桁固定で必ず8個になります。

IPv6 には「サブネットマスク」という概念がありません。
その代わり、IPv4 のクラスレス化で導入した CIDR の考え方を踏襲して、「プレフィックス」「プレフィックス長」という概念が導入されました。

IPv6 における「プレフィックス」とは IPv4 で言うところの「ネットワークアドレス」、
この長さをビット長で示したものが「プレフィックス長」になります。

2018/03/25(日)やっと使えるレベルになった - IPv6 対応

一昨年秋から使い始めた某社向けの制御ボードですが・・・
20180325.jpg
昨年12月にこの制御ボードの IPv6 対応を決めてから、対応作業に結構キツイ4ヶ月でした。
3月に入ってすぐに色々あって、作業自体が専門知識を要する佳境に入っていたため、1週間ほど寝る時間があまり無かったorz..

あとはこの1~2週間で安定性向上と、取扱い説明書改訂などを行って完了です。

ここ最近、『働き方改革』と称してその中に「高度プロフェッショナル制度」という勤務時間ではなく、成果主義に基づく勤務体系が通常国会などで議論されていましたが、そんな言葉が無い時代から筆者自身の服務がそんな感じだったので、一言くらい物申すことが出来ると思うのですが・・(笑)

ハッキリ言いますと、勤務時間は減りません。
「勤務時間」という観点だけで言えばむしろ「増える」のですよ。

だが、短所だけを誇張して、「全て悪」みたいな印象操作は違和感をものすごく感じます。
実際、筆者のような研究・開発職は「労働時間」「出勤時間」「退勤時間」で一般職のように規制されると却って作業そのものがやりずらい上に作業効率が上がらない。
ハッキリ言って、夕方出勤・深夜退勤みたいな柔軟性が欲しい。
安倍総理が言っているのはこういう部分だと思うのですがね。

これが普通の日本人の感性からして「だらしない奴」とレッテル張りしたがるので、そういうことも違和感たっぷりですよ。

問題は過労死を助長する企業風土であったり、職場環境であり、
「カネのことや作業計画の点は面倒みるから、何日か休みなさい」
と(上司や責任者が)言える風土創りが最も必要なのです。ちょっと国会の論戦はズレているのだよね。。

つまらないことで、安倍政権叩きする暇があったら、北朝鮮と支那国の対応、地方疲弊対策を真剣にやってほしいと思ってしまいます。

2018/02/21(水)Windows版 の Chrome でmp4 動画がまともに観れなくなった時の対処・・

弊社サイトの IPv6 対応作業を地道に進めていて、動作確認して気づいたのですが・・orz
つい最近まで Chrome でのサイト埋め込み mp4 動画が再生できていたのに、軒並みまともに再生しなくなってしまったようで、、
google が積年の恨みでも果たしたのだろうか・・(数年前から google が推進中の webm 形式動画普及攻勢・・・)

こうなってしまうようになったのです ↓
20180221_1.png
音声は出るが、映像が全く駄目、、、しかし、Firefox では特段問題がありません。
もしかして、前述のとおり google が chrome で問題が出るように何かやからしたのではないか、と勘繰り、webm 動画形式の対応状況をオンライン調査で再確認します。。

もう webm ≫ mp4 という感じなんですね。動画サイトの大御所 Youtube が webm 形式(VP8,VP9) を本格採用したことの影響が想像以上に大きいようです。

不具合を起こしている mp4 形式動画を webm 形式にエンコードして、アップロード。
動画を表示する部分の HTML を以下のようにしてみました:
<video  width="800" height="490" controls>
 <source src='20170427_15.webm' type='video/webm; codecs="vp8,vorbis"'>
 <source src='20170427_15.mp4' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
 <p>動画を再生するには、videoタグをサポートしたHTML5対応ブラウザが必要です。</p>
</video>


こうすることで、以下のように Chrome での動画再生が復活しました ↓
20180221_2.png
各所で言及されているとおり、同内容の動画であれば、ファイルサイズは mp4 形式より小さくなるようです。3割減は結構大きいですね。
20180221_3.png
ここで、avi 形式のファイルサイズが少し小さいのは、音声トラックが入っていないためです。
問題は、エンコードにエラく時間かかるところですね。
当方のPCでは概ね動画再生時間の3~4倍かかります。30分動画なら2時間弱かかってしまう。。。

〔2018/02/22 追記〕 Libre office の更新インストールと共に、Microsoft Visual C++ 2015 Redistributable(x64) - 14.0.24215.1 というものがインストールされたのですが、これで上記の不可解な現象は直った模様。。

2018/02/20(火)IPv6 の基礎(1) - ネットワーク機器類の取扱説明書を見る時、得意になれそうな知識

今回から不定期にIPv6基礎ネタを備忘録的に残していこうと考えています。
あくまでも「備忘録」です。はい。

筆者がかねてから想像していたとおり、今まで嗜んできたIPv4 とは毛色が違うし、似て似つかないものがあります。なので、初心者から「志を持って」(何のだ・・)猛勉強中です。

そんな中、各種のネットワーク機器を家電量販店やICT機器専門店などで買うときや、買った後で知っておくと、周囲に威張ることができそうな理解がしやすくなるような基礎知識を先ずはまとめていきます。

IPv4 は、軍事・学術研究から行き当たりばったりで進化してきた技術ですが、
IPv6 は最初から民生用途が意図されていて、万人共通の定義づけがいくつかあります。
ここがまず IPv4 と違う世界ですね。
IPv6基礎(1)
IPv6 の世界で先ず使われる用語の基礎用語として、以下があります:
■ ノード
 IPv6 通信機能を持った機器全てを指す。
 具体的には、パソコン、ネットワークプリンタ、ルータ、サーバを指し、ハブやスイッチングハブなどはノードに含みません。
 図示していませんが、スマートフォン、タブレットも「ノード」です。
 ノードは「ルータ」と「ホスト」の2つに区別されます。

■ リンク
 ハブやスイッチングハブ、無線LANアクセスポイントなどを介して、ルータ超えしないで直接イーサネットやWiFiで通信可能な装置間接続を指します。
 ルータ同士の通信も「リンク」です。
 ルータ超えの通信は「リンク」ではありません。

■ サイト
 1つ以上のリンクからなるLANを指します。
 ルータが複数あっても、インターネットに出ていかずに別のリンクと接続するLANは、接続ルータ先のリンクもまとめて「サイト」になります。
 ただ、この概念は古い IPv6 の資料には出てくるのですが、現在は使いません。
 古い IPv6 の資料を読むときに必要となります。

■ ルータ
 ノードのうち、リンク外部との通信中継・リンク内部通信の取りまとめを行う機器を指します。
 インターネット接続には不可欠な装置になります。

■ ホスト
 ノードのうち、ルータ以外の全ての機器を指します。
 受信時、自ホスト宛は処理できるが、他ホストへ転送出来ない機器全てがホストです。
 パソコン、ネットワークプリンタ、サーバ、スマートフォン、タブレットなどは、典型的なホストの一例です。
 リンク内でも他ホストへの送信は、基本的にルータが取りまとめて処理します。

■ 近隣ノード
 リンク内で通信が直接到達可能なノード全てを指します。

これらは概念として理解しておくと、後々 IPv6 の理解が楽になります。
OK キャンセル 確認 その他