2017/06/07(水)Win10 のマイナーアップデート？
2017/10/12 22:16
インストール完了直後の様子。
インストール完了直後の様子。
2017/05/23(火)権威ＤＮＳ ― SOA レコードの記述方法
2017/10/12 22:15
SOA とは Start Of Authority を略したもので、
よく「権威の開始」を意味すると説明されます。
このあたりが、日本語での感覚と英語圏での感覚が合わなくてピンとこないのですが、要するにここでいう「権威の開始」というのは、「ゾーン情報を管理する権限を持っているこ とを明示する」ということになります。
ＳＯＡレコードは、BIND の設定ファイルに従うと、下記のような書式になります：
@ IN SOA ns.example.jp. postmaster.example.jp. (
17052301 ; Serial-No.
3600 ; Refresh
900 ; Retry
604800 ; Expire
1800 ; Minimum
)
以下、「マスターＤＮＳ」「スレーブＤＮＳ」「権威サーバ」等の用語は理解しているものとして記述していきます。これらの意味は１つ前の記事に全て記してあります。ひとつひとつのパラメータを理解しているようでよく解かっていないのではないかなと。
SOA レコードは実に７つのパラメータで成り立っています。
個々に示してみます：
MNAME [ns.example.jp.]
・マスターＤＮＳのホスト名。
・「完全修飾」という書式で通常、最後にもドットを付ける。
・CNAME レコードのホスト名は指定不可。ＩＰアドレス自体も指定不可。
RNAME [postmaster.example.jp.]
・連絡先の電子メールアドレス。
・「完全修飾」という書式で通常、最後にもドットを付ける。
・ＤＮＳの動作上使われることはないが、管理者同士の連絡先として使われることがある。
・記述の際、@ マークは . に置き換える。
SERIAL [17052301]
・ゾーンシリアル番号。符号なし 32bit長整数で保持される。
・ゾーン内容を更新したら、必ずこの番号を＋１以上更新する。
・０以上ならどのような値でも構わないのだが、更新日（作成日）を示す YYYYMMDDnn 或いは YYMMDDnn の形式が多い。
・4294967295 の状態で＋１すると 0 になるが、こういう場合の正常な動作は基本的に考慮されていないことに留意。
→ この場合は、スレーブＤＮＳを一旦停止し、該当ゾーンを含む保持データそのものを削除してから、スレーブＤＮＳを再起動するしかありません。 SERIAL を前回より小さい番号にした場合も同様の対処です。
○ 以下３つはスレーブＤＮＳの挙動を指定：
REFRESH [3600] 〔単位：秒〕
・当該ゾーン情報をリフレッシュする間隔。
・スレーブＤＮＳは、マスターＤＮＳからのゾーン転送処理を受け入れたあと、ここで指定した時間経過すると、マスターＤＮＳへゾーン情報更新問合わせを行い、シリアル番号 が更新されていたら適宜更新処理を行う挙動になる。
RETRY [900] 〔単位：秒〕
・リフレッシュがマスターＤＮＳや回線障害など原因で上手く行かなかった場合、リトライを試みる間隔。
・従って、REFRESH で指定する値よりも小さな値でないと意味がなく、通常は、REFRESH の整数分の１の値とする。（この例では４分の１）
EXPIRE [604800] 〔単位：秒〕
・ゾーン情報のリフレッシュができない状態が続いた場合、スレーブＤＮＳにて、ゾーン情報を最後にリフレッシュが成功してから保持を可能とする時間を示す。
・従って、REFRESH の整数倍で無いと意味がなく、２週間から４週間が適切とされている。（この例では７日＝１週間）
○最後の１つはキャッシュＤＮＳの挙動を指定：
MINIMAM [1800] 〔単位：秒〕
・このパラメータは Negative cache TTL とも呼ばれる。
・各レコードのデフォルトキャッシュ保持時間を指定する。
・値が小さいほど臨機応変に権威サーバにおける保持情報に追従できるが、ＤＮＳの負荷が上がるため、60 ～ 3600 の間で適宜指定されるのが実態である。
・また、レコードに存在しない情報の問い合わせを受けた場合、'NXDOMAIN' （情報なし）という回答をするが、キャッシュＤＮＳは「情報なし」もここで指定した時間だけ保持する挙動になる。
以上、参考にどうぞ。
ダイナミックＤＮＳを運用している場合、MINIMAM は 60 を指定するのが通例の設定のようです。ホストの増減が多い環境では MINIMAM は 600、比較的変化が少ない環境では 1800 や 3600 という設定が多いようです。
2017/05/15(月)権威ＤＮＳとキャッシュＤＮＳの分離をしました
2017/10/12 22:13
ＤＮＳをいじるので、工程途上で作業ミスがあると傘下のネットワーク運用への影響が大きいため、１年近くやりたくてもできない状態だったので、出来る時にやってしまおうとい うことで。。
権威ＤＮＳとかキャッシュＤＮＳとか判らない方々も多いので、基礎的な解説を交えていきます。
変更前は以下のような単純な構成でした：
これは、弊社管轄ドメインのネームサーバとして、レジストラに登録しているサーバになります。
レジストラに登録するサーバは、「権威サーバ」となる種別のＤＮＳでなければなりません。
では、「権威サーバ」と「キャッシュサーバ」の違いは何？ というところですが・・
「権威サーバ」とは、ドメイン各種情報の原本を持つサーバ、
「キャッシュサーバ」とは、探索したドメイン情報の写しを持つサーバ
を言います。
従来のＤＮＳは、「権威サーバ」と「キャッシュサーバ」が一緒で、ＤＮＳのサーバソフトウェアで有名な BIND が以前は「権威サーバ」「キャッシュサーバ」と区別する概念が 無く、最初から両方使えるようになっているので、このあたりが混乱を来す要因になっています。
さて、「権威サーバ」には更に２種類あって、
かつては本当の原本情報を持たせるサーバを「プライマリＤＮＳ」
原本情報の複製を保持するサーバを「セカンダリＤＮＳ」と言っていました。
最近では、
「プライマリＤＮＳ」は「マスターＤＮＳ」とか「マスター権威ＤＮＳ」、
「セカンダリＤＮＳ」は「スレーブＤＮＳ」とか「スレーブ権威ＤＮＳ」とかいう言い方が主流になってきているようです。
ちなみに、「キャッシュＤＮＳ」には「プライマリ」「セカンダリ」あるいは「マスター」「スレーブ」の区別も概念もありません。
さて、「マスターＤＮＳ」も「スレーブＤＮＳ」も「権威サーバ」の位置づけなので、レジストラに「ネームサーバ」として登録できます。
「マスターＤＮＳ」か「スレーブＤＮＳ」かの種別は問いません。「権威サーバ」であることが重要です。
「マスターＤＮＳ」か「スレーブＤＮＳ」かの種別は問いません。「権威サーバ」であることが重要です。
弊社では、ＤＮＳ関係は下記のような構成にしました(2017/05/08より)：
最近はこのような構成がやや強めにお勧めされています。
使用するＤＮＳソフトウェアは何でも良いのですが、弊社での環境的事情や BIND の相次ぐセキュリティアラートに加え、常用の FreeBSD にて BIND が標準提供から外された(BIND 10 から Python ベースになったのが主たる理由）のに辟易して、PowerDNS,nsd,unbound という構成を採用した次第です。
「hidden マスターＤＮＳ」とは、その名の通り、マスターＤＮＳを公開ネットワーク上から隠しています。
こうすることで、ドメイン原本情報に「毒」が外部から入ることを防ぐセキュリティ対策が出来ます。
レジストラへのドメイン登録はネームサーバが最低２つ要るため、２つのスレーブＤＮＳを稼働させます。このスレーブＤＮＳは自前ですが、費用面さえ許す環境ならば、他社サー ビスの利用でも良いでしょう。
同じくキャッシュＤＮＳも２つ用意します。これは最低でも１つあればいいです。
逆に３つ以上キャッシュＤＮＳを指定できるアプリケーションはあまり見かけませんね。
キャッシュＤＮＳは「ドメイン情報探索専用」のサーバです。
「権威ＤＮＳ」とは物理的に別のサーバとし、利用を許可するネットワークを限定することがコツです。
「権威ＤＮＳ」はＣＰＵ負荷はあまり重くならないので、Raspberry Pi 等の活用も可能です。
キャッシュＤＮＳで特殊なのは google の 8.8.8.8 とか 8.8.4.4 とかで、これはオープンＤＮＳとかオープンリゾルバとか呼ばれ、誰でも使用できる代物ですが、負荷分散の意味 で、キャッシュサーバを用意しない場合や、用意できない場合、出来る限り加入しているプロバイダで指定されているネームサーバを使うことをお勧めします。
2017/04/12(水)今どきの和文Ｗｅｂフォント
2017/10/12 22:11
従来（結構昔話になってきている）は閲覧する側で表示できる文字フォントを考慮するのが一般的であり、制作側で使用したい文字フォントをデザイン的に強制出来ないという問題 があります。
筆者が制作したサイトもこんな感じで、クオリティにやや難を感じる状態です。。
最近は CSS の普及でこうした問題も解決し、ライセンスに注意する必要がありますが、制作側で意図した文字フォント一式をＷｅｂブラウザにダウンロードさせ、強制することができます。
これは、一般的に「Ｗｅｂフォント」と言うものです。
しかしながら、日本語環境でこの「Ｗｅｂフォント」を採用するには問題があります。先ず、
・英文フォントと違い文字種が多いので、フォントファイルも数ＭＢはザラである。フォントによっては、数１０ＭＢあり、ダウンロード → 表示に必然的に時間かかる。
という致命的ともいえる問題があり、更に、
・実際に表示させてみると、文字フォントによってはレンダリングが汚く、プロ品質の実用にやや難がある。
とりあえず、致命的な問題が何とかならないものかと色々調査していましたが、
有償のサービスもあるもののそれは弊社の環境にはオーバスペックなため、下記の手法で落ち着きました。
〔参考〕
10分で設定完了！Webフォントの使い方や軽量化・はてなブログでの設定手順、優良リソースなどまとめ【おすすめ日本語フォントも】
（http://brian.hatenablog.jp/entry/how-to-set-web-fonts ）
先ず、
「サブセットフォントメーカ」 というソフトウェアと、
「ＷＯＦＦコンバータ」 というソフトウェアをダウンロードしてインストールしておきます。
ちなみにこれら２つのソフトウェアは Win版とMac版両方あります。
両方ともいわゆるフリーソフトで、生成したフォントファイルは、元にしたフォントファイルでライセンス制限されていない限りは商用利用（有償で制作を請け負うなど）可能です。
インストール出来たら、「サブセットフォントメーカ」を起動し、以下のように入力しました。
因みに、元フォントは「モトヤＬマルベリ等幅３」というApache ライセンスのものを採用しました。
フォントに格納する文字のところは、テキストファイルであれば何でもよいようです。
筆者はそのまま対象のHTMLファイルを選択しました。
但し、Windows 環境において、UTF-8 では文字化けするようなので、予め UTF-16BOM(Windowsで言うところのUnicode形式) に変換しておくとよいです。
ここで「作成開始」をクリックすると、すぐに WOFF コンバータの画面が開きます。
以下のように入力します。（変換前ファイルの欄は自動入力される）
ここで「変換開始」をクリックすると、拡張子が .eof , .woff , .woff2 の３つのファイルが生成されます。
こうすることで、使用している文字のみをピックアップし、フォントファイルのサイズを大幅に削減できます。筆者の場合は最大で 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;
.... [中略] ....
}
これで、こうなりました：
レンダリングも問題なさそうです。(Cyberfox,chrome,IE11,edge で確認)
woff 形式は IE 以外で、eot 形式は IE のみでサポートする Ｗｅｂフォントファイルのようです。
2017/01/05(木)壊れたのと同じテスタを買ってみた
2017/10/12 22:10
１２月２９日、たまたま興味本位で寄った個人経営らしきリサイクルショップなのですが・・・
なんと、機械的損傷で数ヶ月前に壊れてしまった安物テスタと全く同型のものが平積みで売っていました。とりあえずというか、必要ではあるので思わず買ってしまいました。
３年くらい前にネット通販で980円で購入した記憶があるのですが、税抜き699円で売っていました。
しかしまぁ、リサイクルショップで安物新品テスタが売られているなんぞ、誰も考えないでしょうね。
本当は、もっときちんとしたプロの業務に耐えうるテスタが欲しいのです。
工事現場などで携帯目的で使うにもやや難があります。
この手のテスタは測定誤差が結構あるのですよ。。
2016/12/31(土)FreeBSD11 で OpenLDAP・Courier-Authlib・postfix3.1.x インストール時の注意
2017/10/12 19:46
年明けから、FreeBSD11 を使用したARM系ボードの試作の仕事が入りそうなこともあり、弊社管轄の幾つかのサーバを FreeBSD 11.0 にしてみました。
FreeBSD 9系 のサポートは本日で終了です。
FreeBSD10.3 は、少なくとも 2018年4月末までのサポート、
FreeBSD11系 は、少なくとも 2021年9月末までのサポートになっています。
FreeBSD10系 は微妙ですが、FreeBSD11系は、サポート期間が延びる可能性ありです。
FreeBSD 11 にすると、コンソール（画面表示）ドライバが変更されており、こんな表示になります。↓
フォントさえ設定できれば、日本語表示できるのですが、11.0 の時点ではまだデフォルトでは出来ないようです。
また、スクリーンセーバーは機能しません。今後の課題でしょうか。。
本題ですが、FreeBSD11にするにあたり、注意すべき気づいた点をメモ書きしておきます。
１）OpenLDAP 2.4.44 のインストール
FreeBSD10 まで普通に使い回しが出来たのですが、
どうやら、BDB 形式でデータベースクラスタを構築している場合、
FreeBSD11 上で OpenLDAP自体を構築し、FreeBSD10 で使っていた BDB を使用しようとすると、slapd 自体が起動しなくなるようなのです。
これをしなければ大丈夫ぽいですが、問題の先送りをするだけです。
このため、
○ FreeBSD 11 移行前に slapcat コマンドで LDIF をエクスポート
○ FreeBSD 11 移行後に openLDAPを再構築したら、slapadd コマンドで LDIF インポート
という手順で解決しました。
２）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 を更新インストール継続しているとこうなると思います。
３）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] ネットワークドライブのフォントファイルは何をしてもエラー
2017/10/12 19:45
該当のフォントファイルを右クリック → プレビュー(R) と操作すると、フォントの参照が出来るのですが、ネットワークドライブ上ではこうなります：
これをＰＣローカルのハードディスク上にコピーして操作すると、こんな感じ：
しばし、嵌まること５分。。バグなのか、仕様なのか、、不明です・・・
2016/12/10(土)perl 5.24 にしたら ports の XPDFJ は動作しない
2017/10/12 19:44
サーバのエラーログに
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エディタは、現場では使い物にならない。
2017/10/12 19:43
具体的なソフトウェア名を出すのは避けますが、
当方の周囲でＷｅｂデザイナーと呼ばれる方々で、この類のソフトウェアを多用している人は「皆無」です。
理由は聞かなくても判ります。
「余計なものが沢山入り、痒い所に手が届かない」
といったところでしょう。これ以外にも多くの理由がありますが。
素人が案件のサンプルで持ち込んだHTMLファイルが、こういったＨＴＭＬエディタで作成したもので、そのままでは全く使えない状態だったりするので、全面的に作り直しすることもありますね。
先月、サイト構築を手伝う案件があって、担当者は、ＨＴＭＬエディタソフトで作業を始めようとしていたのですが、当方はそれを止めさせました。
そのまま黙認していたら、担当者本人が大変なことになっていたからです。
有無を問わず、テキストエディタで一から作成するのがいいのです。
HTML は全く複雑な代物ではありませんし、そのほうが肝心要の基礎を習得できますのでね。
2016/11/26(土)jQuery は有害なのか・・・ 有害というより老害です。
2017/10/12 19:42
何気に jQuery の評価なんぞ調べていたら、こんな記事に出くわしました。
jQueryは有害なのか
８割～９割同意できる内容ですね。
jQuery って何？ 的な人に一言で言及するならば、
「JavaScript を使いやすく（することを目指す）したもの」
といったところでしょうか。やや専門的に言えば「フレームワーク」といった感じ。
あぁ、筆者を困らせる存在だ。。何故かというと「却って判りずらい」から。
jQuery も記述方法にクセがあり、判りにくさは一般のフレームワーク並み。
昨今では、何も考えずにこの jQuery を使ったＷｅｂアプリケーションが広く出回っているのです。近未来を考えればあまり良くない傾向。
昨今では JavaScript 自体の機能や性能が向上・ブラウザ間で統一されてきている(IE を除く) ので、使う必要性そのものが無くなってきている訳です。
Ｗｅｂ開発技術者ならば、jQuery のようなものは使うべきではありません。
将来の自分が要らぬ苦労を強いられるだけ。
こんなものに頼ると、技術の基礎が身につかなくなります。
そもそも、スキル的にそこそこ低くても高機能なものを実現するのが目的ですから、当然の帰結です。
当方では、端からこんなものは使わないようにしています。
ひとたびトラブルに見舞われると、肝心な部分がブラックボックス化されているため、トラブル内容にもよるが何が問題なのか解らなくなる。
そんなエセ職人が大量生産されても現場にしわ寄せ行くだけなんですよね。。
そういうことまで考えてプロジェクトを組ませないような中途半端なスキルが担っている上流工程や業界自体の認識も大きな問題ですけどね。
例えば、IE を使わせないようにして、まともな機能のあるＷｅｂブラウザを使うように顧客を指導していく。こっちのほうがメンテナンスのコストダウンが出来て、技術職人的には楽です。
jQuery が自然淘汰できれば何も言うことは無いですがね。