ようこそゲストさん

はんかくさい日報

2017/05/23(火) 権威DNS ― SOA レコードの記述方法

2017/05/23 4:51 サーバ運営・管理
どちらかというと自分メモです。。。
SOA とは Start Of Authority を略したもので、
よく「権威の開始」を意味すると説明されます。

このあたりが、日本語での感覚と英語圏での感覚が合わなくてピンとこないのですが、要するにここでいう「権威の開始」というのは、「ゾーン情報を管理する権限を持っていることを明示する」ということになります。

SOAレコードは、BIND の設定ファイルに従うと、下記のような書式になります:
@               IN SOA  ns.example.jp. postmaster.example.jp. (
                        17052301        ; Serial-No.
                        3600            ; Refresh
                        900             ; Retry
                        604800          ; Expire
                        1800            ; Minimum
                        )
以下、「マスターDNS」「スレーブDNS」「権威サーバ」等の用語は理解しているものとして記述していきます。これらの意味は1つ前の記事に全て記してあります。

ひとつひとつのパラメータを理解しているようでよく解かっていないのではないかなと。
SOA レコードは実に7つのパラメータで成り立っています。
個々に示してみます:

MNAME [ns.example.jp.]
 ・マスターDNSのホスト名。
 ・「完全修飾」という書式で通常、最後にもドットを付ける。
 ・CNAME レコードのホスト名は指定不可。IPアドレス自体も指定不可。

RNAME [postmaster.example.jp.]
 ・連絡先の電子メールアドレス。
 ・「完全修飾」という書式で通常、最後にもドットを付ける。
 ・DNSの動作上使われることはないが、管理者同士の連絡先として使われることがある。
 ・記述の際、@ マークは . に置き換える。

SERIAL [17052301]
 ・ゾーンシリアル番号。符号なし 32bit長整数で保持される。
 ・ゾーン内容を更新したら、必ずこの番号を+1以上更新する。
 ・0以上ならどのような値でも構わないのだが、更新日(作成日)を示す YYYYMMDDnn 或いは YYMMDDnn の形式が多い。
 ・4294967295 の状態で+1すると 0 になるが、こういう場合の正常な動作は基本的に考慮されていないことに留意。
 → この場合は、スレーブDNSを一旦停止し、該当ゾーンを含む保持データそのものを削除してから、スレーブDNSを再起動するしかありません。 SERIAL を前回より小さい番号にした場合も同様の対処です。

○ 以下3つはスレーブDNSの挙動を指定:
REFRESH [3600] 〔単位:秒〕
 ・当該ゾーン情報をリフレッシュする間隔。
 ・スレーブDNSは、マスターDNSからのゾーン転送処理を受け入れたあと、ここで指定した時間経過すると、マスターDNSへゾーン情報更新問合わせを行い、シリアル番号が更新されていたら適宜更新処理を行う挙動になる。

RETRY [900] 〔単位:秒〕
 ・リフレッシュがマスターDNSや回線障害など原因で上手く行かなかった場合、リトライを試みる間隔。
 ・従って、REFRESH で指定する値よりも小さな値でないと意味がなく、通常は、REFRESH の整数分の1の値とする。(この例では4分の1)

EXPIRE [604800] 〔単位:秒〕
 ・ゾーン情報のリフレッシュができない状態が続いた場合、スレーブDNSにて、ゾーン情報を最後にリフレッシュが成功してから保持を可能とする時間を示す。
 ・従って、REFRESH の整数倍で無いと意味がなく、2週間から4週間が適切とされている。(この例では7日=1週間)

○最後の1つはキャッシュDNSの挙動を指定:
MINIMAM [1800] 〔単位:秒〕
 ・このパラメータは Negative cache TTL とも呼ばれる。
 ・各レコードのデフォルトキャッシュ保持時間を指定する。
 ・値が小さいほど臨機応変に権威サーバにおける保持情報に追従できるが、DNSの負荷が上がるため、60 ~ 3600 の間で適宜指定されるのが実態である。
 ・また、レコードに存在しない情報の問い合わせを受けた場合、'NXDOMAIN' (情報なし)という回答をするが、キャッシュDNSは「情報なし」もここで指定した時間だけ保持する挙動になる。

 以上、参考にどうぞ。

 ダイナミックDNSを運用している場合、MINIMAM は 60 を指定するのが通例の設定のようです。ホストの増減が多い環境では MINIMAM は 600、比較的変化が少ない環境では 1800 や 3600 という設定が多いようです。

2017/05/15(月) 権威DNSとキャッシュDNSの分離をしました

2017/05/15 3:58 サーバ運営・管理
5月連休中は、専らこの作業をしていました。
DNSをいじるので、工程途上で作業ミスがあると傘下のネットワーク運用への影響が大きいため、1年近くやりたくてもできない状態だったので、出来る時にやってしまおうということで。。

権威DNSとかキャッシュDNSとか判らない方々も多いので、基礎的な解説を交えていきます。
変更前は以下のような単純な構成でした:
20170515_1.png

これは、弊社管轄ドメインのネームサーバとして、レジストラに登録しているサーバになります。
レジストラに登録するサーバは、「権威サーバ」となる種別のDNSでなければなりません。
では、「権威サーバ」と「キャッシュサーバ」の違いは何? というところですが・・

「権威サーバ」とは、ドメイン各種情報の原本を持つサーバ、
「キャッシュサーバ」とは、探索したドメイン情報の写しを持つサーバ
を言います。
 従来のDNSは、「権威サーバ」と「キャッシュサーバ」が一緒で、DNSのサーバソフトウェアで有名な BIND が以前は「権威サーバ」「キャッシュサーバ」と区別する概念が無く、最初から両方使えるようになっているので、このあたりが混乱を来す要因になっています。

さて、「権威サーバ」には更に2種類あって、
かつては本当の原本情報を持たせるサーバを「プライマリDNS」
原本情報の複製を保持するサーバを「セカンダリDNS」と言っていました。

最近では、
「プライマリDNS」は「マスターDNS」とか「マスター権威DNS」、
「セカンダリDNS」は「スレーブDNS」とか「スレーブ権威DNS」とかいう言い方が主流になってきているようです。
ちなみに、「キャッシュDNS」には「プライマリ」「セカンダリ」あるいは「マスター」「スレーブ」の区別も概念もありません。

さて、「マスターDNS」も「スレーブDNS」も「権威サーバ」の位置づけなので、レジストラに「ネームサーバ」として登録できます。
「マスターDNS」か「スレーブDNS」かの種別は問いません。「権威サーバ」であることが重要です。

弊社では、DNS関係は下記のような構成にしました(2017/05/08より):
20170515_2.png

最近はこのような構成がやや強めにお勧めされています。
使用するDNSソフトウェアは何でも良いのですが、弊社での環境的事情や BIND の相次ぐセキュリティアラートに加え、常用の FreeBSD にて BIND が標準提供から外された(BIND 10 から Python ベースになったのが主たる理由)のに辟易して、PowerDNS,nsd,unbound という構成を採用した次第です。

「hidden マスターDNS」とは、その名の通り、マスターDNSを公開ネットワーク上から隠しています。
こうすることで、ドメイン原本情報に「毒」が外部から入ることを防ぐセキュリティ対策が出来ます。
レジストラへのドメイン登録はネームサーバが最低2つ要るため、2つのスレーブDNSを稼働させます。このスレーブDNSは自前ですが、費用面さえ許す環境ならば、他社サービスの利用でも良いでしょう。

同じくキャッシュDNSも2つ用意します。これは最低でも1つあればいいです。
逆に3つ以上キャッシュDNSを指定できるアプリケーションはあまり見かけませんね。

キャッシュDNSは「ドメイン情報探索専用」のサーバです。
「権威DNS」とは物理的に別のサーバとし、利用を許可するネットワークを限定することがコツです。

「権威DNS」はCPU負荷はあまり重くならないので、Raspberry Pi 等の活用も可能です。

キャッシュDNSで特殊なのは google の 8.8.8.8 とか 8.8.4.4 とかで、これはオープンDNSとかオープンリゾルバとか呼ばれ、誰でも使用できる代物ですが、負荷分散の意味で、キャッシュサーバを用意しない場合や、用意できない場合、出来る限り加入しているプロバイダで指定されているネームサーバを使うことをお勧めします。

2017/04/12(水) 今どきの和文Webフォント

Webサイトを制作していて、悩みの種のひとつに文字フォントの問題があります。
従来(結構昔話になってきている)は閲覧する側で表示できる文字フォントを考慮するのが一般的であり、制作側で使用したい文字フォントをデザイン的に強制出来ないという問題があります。

筆者が制作したサイトもこんな感じで、クオリティにやや難を感じる状態です。。
20170412_before.png

最近は CSS の普及でこうした問題も解決し、ライセンスに注意する必要がありますが、制作側で意図した文字フォント一式をWebブラウザにダウンロードさせ、強制することができます。
これは、一般的に「Webフォント」と言うものです。

しかしながら、日本語環境でこの「Webフォント」を採用するには問題があります。先ず、
・英文フォントと違い文字種が多いので、フォントファイルも数MBはザラである。フォントによっては、数10MBあり、ダウンロード → 表示に必然的に時間かかる。

という致命的ともいえる問題があり、更に、
・実際に表示させてみると、文字フォントによってはレンダリングが汚く、プロ品質の実用にやや難がある。

とりあえず、致命的な問題が何とかならないものかと色々調査していましたが、
有償のサービスもあるもののそれは弊社の環境にはオーバスペックなため、下記の手法で落ち着きました。

〔参考〕
10分で設定完了!Webフォントの使い方や軽量化・はてなブログでの設定手順、優良リソースなどまとめ【おすすめ日本語フォントも】
http://brian.hatenablog.jp/entry/how-to-set-web-fonts

先ず、
「サブセットフォントメーカ」 というソフトウェアと、
「WOFFコンバータ」 というソフトウェアをダウンロードしてインストールしておきます。
ちなみにこれら2つのソフトウェアは Win版とMac版両方あります。

両方ともいわゆるフリーソフトで、生成したフォントファイルは、元にしたフォントファイルでライセンス制限されていない限りは商用利用(有償で制作を請け負うなど)可能です。

インストール出来たら、「サブセットフォントメーカ」を起動し、以下のように入力しました。
20170412_1.png
因みに、元フォントは「モトヤLマルベリ等幅3」というApache ライセンスのものを採用しました。
フォントに格納する文字のところは、テキストファイルであれば何でもよいようです。
筆者はそのまま対象のHTMLファイルを選択しました。
但し、Windows 環境において、UTF-8 では文字化けするようなので、予め UTF-16BOM(Windowsで言うところのUnicode形式) に変換しておくとよいです。

ここで「作成開始」をクリックすると、すぐに WOFF コンバータの画面が開きます。
以下のように入力します。(変換前ファイルの欄は自動入力される)
20170412_2.png

ここで「変換開始」をクリックすると、拡張子が .eof , .woff , .woff2 の3つのファイルが生成されます。
こうすることで、使用している文字のみをピックアップし、フォントファイルのサイズを大幅に削減できます。筆者の場合は最大で 15kB 余りとなりました。

これらをサーバにバイナリモードにて(FTP の場合)アップロードし、次にCSS ファイルで、これらフォントファイルを参照するように設定します。
こんな感じです:
@font-face {
  font-family: 'motoyasub3' ;
  src: url('/css/motoyasub3.woff') format('woff'),
       url('/css/motoyasub3.eot')  format('eot') ;
  font-weight: 100 ;
}

a.sidemenu  { font-family: 'motoyasub3',"MS Gothic",Osaka,monospace,sans-serif;
      .... [中略] ....
            }
これで、こうなりました:
20170412_after.png

レンダリングも問題なさそうです。(Cyberfox,chrome,IE11,edge で確認)
woff 形式は IE 以外で、eot 形式は IE のみでサポートする Webフォントファイルのようです。

2017/01/05(木) 壊れたのと同じテスタを買ってみた

2017/01/05 5:10 電子工作
早速、昨日から業務稼働しています。
20170105.JPG
12月29日、たまたま興味本位で寄った個人経営らしきリサイクルショップなのですが・・・

なんと、機械的損傷で数ヶ月前に壊れてしまった安物テスタと全く同型のものが平積みで売っていました。とりあえずというか、必要ではあるので思わず買ってしまいました。
3年くらい前にネット通販で980円で購入した記憶があるのですが、税抜き699円で売っていました。
しかしまぁ、リサイクルショップで安物新品テスタが売られているなんぞ、誰も考えないでしょうね。

本当は、もっときちんとしたプロの業務に耐えうるテスタが欲しいのです。
工事現場などで携帯目的で使うにもやや難があります。
この手のテスタは測定誤差が結構あるのですよ。。

2016/12/31(土) FreeBSD11 で OpenLDAP・Courier-Authlib・postfix3.1.x インストール時の注意

2016/12/31 4:05 サーバ運営・管理
今年最後の更新です。

年明けから、FreeBSD11 を使用したARM系ボードの試作の仕事が入りそうなこともあり、弊社管轄の幾つかのサーバを FreeBSD 11.0 にしてみました。
FreeBSD 9系 のサポートは本日で終了です。
FreeBSD10.3 は、少なくとも 2018年4月末までのサポート、
FreeBSD11系 は、少なくとも 2021年9月末までのサポートになっています。
FreeBSD10系 は微妙ですが、FreeBSD11系は、サポート期間が延びる可能性ありです。

FreeBSD 11 にすると、コンソール(画面表示)ドライバが変更されており、こんな表示になります。↓
20161231.JPG

フォントさえ設定できれば、日本語表示できるのですが、11.0 の時点ではまだデフォルトでは出来ないようです。
また、スクリーンセーバーは機能しません。今後の課題でしょうか。。

本題ですが、FreeBSD11にするにあたり、注意すべき気づいた点をメモ書きしておきます。
1)OpenLDAP 2.4.44 のインストール
 FreeBSD10 まで普通に使い回しが出来たのですが、
 どうやら、BDB 形式でデータベースクラスタを構築している場合、
 FreeBSD11 上で OpenLDAP自体を構築し、FreeBSD10 で使っていた BDB を使用しようとすると、slapd 自体が起動しなくなるようなのです。
 これをしなければ大丈夫ぽいですが、問題の先送りをするだけです。

 このため、
 ○ FreeBSD 11 移行前に slapcat コマンドで LDIF をエクスポート
 ○ FreeBSD 11 移行後に openLDAPを再構築したら、slapadd コマンドで LDIF インポート

 という手順で解決しました。

2)Courier-Authlib のインストール
 ソースコードからインストール作業する場合、以下のメッセージが出て configure に失敗することがあります。
 Shared object "libssl.so.7" not found, required by "courierauthconfig"
これは、 /usr/local/bin/courierauthconfig 、/usr/local/courier/bin/courierauthconfig をバッサリと削除し、 configure をやり直せば大丈夫です。
過去に Courier IMAP 等を使用したことがあって、FreeBSD を更新インストール継続しているとこうなると思います。

3)postfix 3.1.x のインストール
 現時点での最新バージョンは 3.1.3 ですが、これは FreeBSD11 には対応しておらず、ソースコードからの構築はそのままではできません。
 ですが、機能的には問題ないと思われますので、以下の修正を行ってから構築を行います。
・ makedef 260行目付近 ~ (行頭が + の行を挿入)
   FreeBSD.10*)  SYSTYPE=FREEBSD10
                 : ${CC=cc}
                 : ${SHLIB_SUFFIX=.so}
                 : ${SHLIB_CFLAGS=-fPIC}
                 : ${SHLIB_LD="${CC} -shared"' -Wl,-soname,${LIB}'}
                 : ${SHLIB_RPATH='-Wl,-rpath,${SHLIB_DIR}'}
                 : ${SHLIB_ENV="LD_LIBRARY_PATH=`pwd`/lib"}
                 : ${PLUGIN_LD="${CC} -shared"}
                 ;;
+  FreeBSD.11*)  SYSTYPE=FREEBSD11
+                : ${CC=cc}
+                : ${SHLIB_SUFFIX=.so}
+                : ${SHLIB_CFLAGS=-fPIC}
+                : ${SHLIB_LD="${CC} -shared"' -Wl,-soname,${LIB}'}
+                : ${SHLIB_RPATH='-Wl,-rpath,${SHLIB_DIR}'}
+                : ${SHLIB_ENV="LD_LIBRARY_PATH=`pwd`/lib"}
+                : ${PLUGIN_LD="${CC} -shared"}
+                ;;
  DragonFly.*)   SYSTYPE=DRAGONFLY
                 ;;
   OpenBSD.2*)   SYSTYPE=OPENBSD2
・ src/util/sys_defs.h 25行目付近~ (行頭が + の行を挿入)
 #if defined(FREEBSD2) || defined(FREEBSD3) || defined(FREEBSD4) \
     || defined(FREEBSD5) || defined(FREEBSD6) || defined(FREEBSD7) \
     || defined(FREEBSD8) || defined(FREEBSD9) || defined(FREEBSD10) \
+    || defined(FREEBSD11) \
     || defined(BSDI2) || defined(BSDI3) || defined(BSDI4) \
     || defined(OPENBSD2) || defined(OPENBSD3) || defined(OPENBSD4) \

2016/12/22(木) [Windows] ネットワークドライブのフォントファイルは何をしてもエラー

2016/12/22 5:19 はんかくさい
以前はこんなことは無かったような。。。Windows10 Ver 1601[2016/08/02 提供開始] になってからでしょうか。(Ver 1507 だった頃は未確認)

該当のフォントファイルを右クリック → プレビュー(R) と操作すると、フォントの参照が出来るのですが、ネットワークドライブ上ではこうなります:
20161222_1.png

これをPCローカルのハードディスク上にコピーして操作すると、こんな感じ:
20161222_2.png

しばし、嵌まること5分。。バグなのか、仕様なのか、、不明です・・・

2016/12/10(土) perl 5.24 にしたら ports の XPDFJ は動作しない

2016/12/10 18:36 サーバ運営・管理
提起の通りです。
サーバのエラーログに
Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at /usr/local/lib/perl5/site_perl/XPDFJ.pm line 757.
と文句を垂れますので、XPDFJ.pm の 757行目を以下の要領で直接修正します。

《変更前》
    if( defined %{$tab->{$name}} && $name !~ /::$/ ) {
《変更後》
    if ((%{$tab->{$name}})  && ($name !~ /::$/ )) {
こうすると、perl 5.24 でも動作するようです。
筆者がメンテナンスを請け負っている企業のサーバでは動作確認できました。

原因は、perl 5.24 にて defined(%hash) の構文を致命的エラーとするように変更されたためです。何故こうするのかはよく判りませんが。。。

2016/11/27(日) HTMLエディタは、現場では使い物にならない。

2016/11/27 17:01 雑多なトピック
ここで言う「HTML エディタ」というのは、ワープロソフトのようなオフラインで使うものを指し、ブログを書くためのエディタは除いています。

具体的なソフトウェア名を出すのは避けますが、
当方の周囲でWebデザイナーと呼ばれる方々で、この類のソフトウェアを多用している人は「皆無」です。

理由は聞かなくても判ります。
「余計なものが沢山入り、痒い所に手が届かない」
といったところでしょう。これ以外にも多くの理由がありますが。

素人が案件のサンプルで持ち込んだHTMLファイルが、こういったHTMLエディタで作成したもので、そのままでは全く使えない状態だったりするので、全面的に作り直しすることもありますね。

先月、サイト構築を手伝う案件があって、担当者は、HTMLエディタソフトで作業を始めようとしていたのですが、当方はそれを止めさせました。
そのまま黙認していたら、担当者本人が大変なことになっていたからです。

有無を問わず、テキストエディタで一から作成するのがいいのです。
HTML は全く複雑な代物ではありませんし、そのほうが肝心要の基礎を習得できますのでね。

2016/11/26(土) jQuery は有害なのか・・・ 有害というより老害です。

2016/11/27 16:32 雑多なトピック
やっと H8/3069F 関係のシステム開発が一段落したので、うんちく記事などを。。
何気に jQuery の評価なんぞ調べていたら、こんな記事に出くわしました。
jQueryは有害なのか

8割~9割同意できる内容ですね。

jQuery って何? 的な人に一言で言及するならば、
「JavaScript を使いやすく(することを目指す)したもの」
といったところでしょうか。やや専門的に言えば「フレームワーク」といった感じ。
あぁ、筆者を困らせる存在だ。。何故かというと「却って判りずらい」から。
jQuery も記述方法にクセがあり、判りにくさは一般のフレームワーク並み。

昨今では、何も考えずにこの jQuery を使ったWebアプリケーションが広く出回っているのです。近未来を考えればあまり良くない傾向。

昨今では JavaScript 自体の機能や性能が向上・ブラウザ間で統一されてきている(IE を除く) ので、使う必要性そのものが無くなってきている訳です。

Web開発技術者ならば、jQuery のようなものは使うべきではありません。
将来の自分が要らぬ苦労を強いられるだけ。

こんなものに頼ると、技術の基礎が身につかなくなります。
そもそも、スキル的にそこそこ低くても高機能なものを実現するのが目的ですから、当然の帰結です。

当方では、端からこんなものは使わないようにしています。
ひとたびトラブルに見舞われると、肝心な部分がブラックボックス化されているため、トラブル内容にもよるが何が問題なのか解らなくなる。
そんなエセ職人が大量生産されても現場にしわ寄せ行くだけなんですよね。。
そういうことまで考えてプロジェクトを組ませないような中途半端なスキルが担っている上流工程や業界自体の認識も大きな問題ですけどね。

例えば、IE を使わせないようにして、まともな機能のあるWebブラウザを使うように顧客を指導していく。こっちのほうがメンテナンスのコストダウンが出来て、技術職人的には楽です。

jQuery が自然淘汰できれば何も言うことは無いですがね。

2016/09/15(木) H8/3069F ROMライタの制作(2)

割り込み作業などで少し遅れているのですが、
基板がやっとできた。今回はこの工程は上手くできました。
この後、穴あけと部品付けを行います。
20160915.jpg