qmailの情報収集 2016/03/31


新しい情報があったので「qmailの情報収集 2019/08/26」で更新しました。


2012年に作成した「いまさらqmailのパッチ情報収集 2012/02/17」という記事に、いまでも時々アクセスがある。

あれから4年。何か変わったところがあるか調べてみた。

・新星 s/qmail登場
なんと「s/qmail」という新作が登場。

これまで普通のqmail向けに、SMTP Authentication, Spamcontrol(4年前の記事でも紹介)などを作成してきた開発者が提供するqmail 2016年版、的なもの。
IPv4,IPv6にちゃんと対応し、vpopmailなどのqmailを使用するソフトウェアがそのまま使用できるものとなっている。

SSL/TLS対応はs/qmail自身ではなく「ucspi-ssl」が提供しているようだ。
SPF,DKIMには対応していない。

・IndiMail
qmail, serialmail, qmailanalog, dotforward, fastforward, mess822, daemontools, ucspi-tcp, Courier IMAP/POP3, Bogofilter – A Bayesian Spam Filter, Fetchmailをまとめてパッケージングしている「www.indimail.org」にアーキテクチャ図あり
SPF,DKIM対応
各ディストリビューション用のレポジトリーが用意されている。(RHEL/CentOS5~7,Debian7~8,Ubuntu12.04~15.10,OpenSuSE11.4など)
安定版:http://download.opensuse.org/repositories/home:/indimail/
開発版:http://download.opensuse.org/repositories/home:/mbhangui/

基本的にパッケージとして使うためものであるため、qmail単独で使うにはちょっと厳しい感じがある。
vpopmailと組み合わせて使えるか、というと、結構謎。

qmail-isp
qmail-1.03に対するパッチをまとめたもの。netqmail-1.06相当のパッチも含まれている。
2013年6月に更新版が出ていた。
こいつはvpopmailと一緒に使えるらしい

CentOS5などの古い環境でLet’s Encryptを使う(2017/02/21更新)


フリーで90日有効のSSL証明書を取得できる「Let’s Encrypt

90日毎に更新する必要があるため、プログラムを実行して証明書の取得ができるようになっている。

公式のプログラム(クライアント)は「https://github.com/certbot/certbot」にあるが、CentOS6以降やUbuntu向けに作られており、古いPythonの環境であるCentOS5では動作させるのが大変である。

公式以外のクライアントを探すと、「List of Client Implementations」に互換クライアント一覧がある。

いろいろある中で、2016年1月時点では唯一のbash環境用のスクリプトだった「Shell script client: dehydrated (旧名letsencrypt.sh) 」を選択。(なお、2017年2月現在では他にも3つ出ている。)

dehydratedは、「opensslコマンド」「curlコマンド」「sedコマンド」「grepコマンド」があれば動作する。

— 2018/07/20 追記開始 —
CentOS7環境で公式のcertbotを使って運用しようとしたのですが、alias FQDNを増やす際に別の設定が作られてしまうとか、管理性があまりよろしくなかったので、CentOS7環境でも制御しやすいdehydratedを使ってます。
— 2018/07/20 追記終わり —

(1) 「git clone https://github.com/lukas2511/dehydrated.git」でプログラム取得

(2) SSL証明書発行時に使用する一時ディレクトリの設定

SSL証明書発行時、Let’s Encryptサーバから「http://ドメイン名/.well-known/acme-challenge/~」というアクセスが行われる。その際のファイルを置く場所を用意する。

ここでは/var/www/dehydratedディレクトリに置くことにする。

1. /var/www/dehydratedディレクトリ作成
2. Aapacheの設定で「/etc/httpd/conf.d/dehydrated.conf」を作成

Alias /.well-known/acme-challenge /var/www/dehydrated
<Directory /var/www/dehydrated/>
</Directory>

3. Aapacheの再起動

(3) configを作成

docs/examples/config を元にconfigを作成する。

基本的には初期状態のままで良いが、2で/var/www/dehydrated以外を指定した場合に下記の記述を変更する

WELLKNOWN="/var/www/dehydrated/"

(4) domains.txtを作成

SSL証明書を発行したいドメインをスペース区切りで列挙する。

blog.osakana.net blog2.osakana.net

(5) dehydratedを実行して、まずはアカウント登録

# ./dehydrated --config /~/dehydrated/config --register --accept-terms
# INFO: Using main config file ./config
+ Generating account key...
+ Registering account key with ACME server...
+ Done!
#

実行すると下記の様にaccountsディレクトリが作成される。

# ls -F
CHANGELOG  README.md  config       docs/        test.sh*
LICENSE    accounts/  dehydrated*  domains.txt
# ls -F accounts/
~~~/
#

(6) もう一度、dehydratedを実行してSSL証明書を発行

# ./dehydrated --config ./config --cron
# INFO: Using main config file ./config
Processing ~ ~ ~
 + Signing domains...
 + Creating new directory ./certs/blog.osakana.net ...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for ~...
 + Requesting challenge for ~...
<略>
 + Responding to challenge for ~...
 + Challenge is valid!
 + Responding to challenge for ~...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!
#

下記の様にcertsディレクトリ以下にファイルが作成される。

# ls -F
CHANGELOG  README.md  certs/  dehydrated*  domains.txt
LICENSE    accounts/  config  docs/        test.sh*
# ls -F certs/
~/
# ls -F certs/~/
cert-xxxxxxxxxx.csr  chain-xxxxxxxxxx.pem      privkey-xxxxxxxxxx.pem
cert-xxxxxxxxxx.pem  chain.pem@                privkey.pem@
cert.csr@            fullchain-xxxxxxxxxx.pem
cert.pem@            fullchain.pem@
[root@niselog dehydrated]#

(7) Apache設定内のSSLファイルの指定では、作成されたファイルのうち、fullchain.pemとprivkey.pem,chain.pemを指定する。

SSLCertificateFile /~/certs/~/fullchain.pem
SSLCertificateKeyFile /~/certs/~/privkey.pem
SSLCertificateChainFile /~/certs/~/chain.pem

なお、最近は問題無いが、バージョンアップしていない古いブラウザでは、「SSLCertificateChainFile /~/certs/~/chain.pem」を抜いた2行で設定するとエラーが発生する場合があるので注意が必要。

(8) httpsアクセスをして問題無いことを確認

ブラウザからhttpsアクセスを行い、想定通りにアクセスできることを確認。

(9) crontabに、dehydratedを定期的に実行する設定を追加

毎月1日と15日に実行する処理

# crontab -l
0 3 1,15 * * /~/dehydrated/dehydrated --config /~/dehydrated/config --cron >> /tmp/ssl-update.log 2>&1
#

以下は旧バージョン

 


フリーで90日有効のSSL証明書を取得できる「Let’s Encrypt

 

90日毎に更新する必要があるため、プログラムを実行して証明書の取得ができるようになっている。
公式のプログラム(クライアント)は「https://github.com/letsencrypt/letsencrypt」にあるが、CentOS6以降やUbuntu向けに作られており、古いPythonの環境であるCentOS5では動作させるのが大変である。

公式以外のクライアントを探すと、「List of Client Implementations」に互換クライアント一覧がある。

いろいろある中で、一番制約が薄そうな「Shell script (and a little Perl) client: https://github.com/lukas2511/letsencrypt.sh」を選択。
「opensslコマンド」「curlコマンド」「sedコマンド」があれば動作する。
perlはこの一覧が作られた当初は必要だったようだが、2016/01/04時点では不要。公式のletsencryptコマンドから移行する場合に使用するimport-account.plコマンドを使う時だけ必要なようだ。

1. 「git clone https://github.com/lukas2511/letsencrypt.sh」でプログラム取得
2. SSL証明書発行時に使用する一時ディレクトリの設定
 SSL証明書発行時、Let’s Encryptサーバから「http://ドメイン名/.well-known/acme-challenge/~」という
 アクセスが行われる。その際のファイルを置く場所を用意する。
 ここでは/var/www/letsenryptディレクトリに置くことにする。
 (1) /var/www/letsencryptディレクトリ作成
 (2) Aapacheの設定で「/etc/httpd/conf.d/letsencrypt.conf」を作成

Alias /.well-known/acme-challenge /var/www/letsencrypt
&lt;Directory /var/www/letsencrypt/&gt;
&lt;/Directory&gt;


 (3) Aapacheの再起動

3. config.shを作成
 config.sh.exampleを元にconfig.shを作成
 といっても、下記の行を書くだけ
 

WELLKNOWN="/var/www/letsencrypt/"

4. domain.txtを作成
 SSL証明書を発行したいドメインをスペース区切りで列挙する。
 

blog.osakana.net blog2.osakana.net

5. letsencrypt.shを実行

# ./letsencrypt.sh --config /~/letsencrypt.sh/config.sh --cron
Using config file /~/letsencrypt.sh/config.sh
Processing blog.osakana.net with SAN: blog2.osakana.net
 + Signing domains...
 + make directory /~/letsencrypt.sh/certs/blog.osakana.net ...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for blog.osakana.net...
 + Responding to challenge for blog.osakana.net...
 + Challenge is valid!
 + Requesting challenge for blog2.osakana.net...
 + Responding to challenge for blog2.osakana.net...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Creating fullchain.pem...
 + Done!
#

下記の様にcertsディレクトリ以下にファイルが作成される。

# ls -F
certs/             domains.txt          import-certs.sh*  private_key.pem
config.sh          domains.txt.example  letsencrypt.sh*   README.md
config.sh.example  import-account.pl*   LICENSE           test.sh*
# ls -F certs/
blog.osakana.net/
# ls -F certs/blog.osakana.net/
cert-xxxxxxxxxx.csr  chain-xxxxxxxxxx.pem      privkey-xxxxxxxxxx.pem
cert-xxxxxxxxxx.pem  chain.pem@                privkey.pem@
cert.csr@            fullchain-xxxxxxxxxx.pem
cert.pem@            fullchain.pem@
#

Apache設定内のSSLファイルの指定では、作成されたファイルのうち、fullchain.pemとprivkey.pem,chain.pemを指定する。

SSLCertificateFile /~/certs/~/fullchain.pem
SSLCertificateKeyFile /~/certs/~/privkey.pem
SSLCertificateChainFile /~/certs/~/chain.pem

ちなみに、「SSLCertificateChainFile /~/certs/~/chain.pem」を抜いた2行で設定するとChromeやIEでは問題無いが、Firefoxでのみ「sec_error_unknown_issuer」のエラーがでる。
(なお、fullchain.pemとprivkey.pemを指定しているのは、標準のletsencryptを使った場合に生成されるapache用cocnfigファイルで使われていたから)


おまけ:CentOS4で使用する場合に必要になること

 

・curlの証明書問題
 → /usr/share/ssl/certs/ca-bundle.crt を更新する
  → OpenSSLが古いためにエラーが発生
   「curl: (35) error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm」
・OpenSSLが古い
 → /usr/local/openssl1とかに新しいバージョンをインストールして回避
  letsencrypt.shの冒頭に、PATHとLD_LIBRARY_PATHを定義して、こちらを優先するように設定
 → こっちのOpenSSLを使うcurlをコンパイル
・trコマンドが古い
 letsencrypt.shを実行すると「tr: オプションが違います — _」というエラー
 → 新しいバージョンのtrが含まれるcoreutilsを/usr/localにインストール
・bashコマンドが古い
 環境変数操作で「SAN+=~」ということをやってるがCentOS4のBASHでは非対応
 letsencrypt.shを修正して、CentOS4でも使える操作に変更
 「SAN+=”DNS:${altname}, “」→「SAN=”${SAN}DNS:${altname}, “」

・下記のエラーでうまく行かない

# ./letsencrypt.sh --cron --config /~/letsencrypt.sh/config.sh
Using config file /~/letsencrypt.sh/config.sh
Processing xxxxxx with SAN: xxxxx
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for xxxxxx...
  + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 403)

Details:
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}  + Error: Can't retrieve challenges ()
#


 → 失敗した時のcertが悪さをしていた
  certsディレクトリの中身とprivate_key.pemを削除して再実行したところ成功

apt-get実行中にディスクがフルになったせいでapt-getができなくなった



apt-get upgrade中にディスクフルになってしまったために、
それ以後、apt-get upgradeが失敗するようになってしまった。

root@orangepiplus:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
5 not fully installed or removed.
Need to get 0 B/91.1 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]; y
dpkg: error processing package gvfs-libs:armhf (--configure):
 package is in a very bad inconsistent state; you should
 reinstall it before attempting configuration
dpkg: dependency problems prevent configuration of gvfs-daemons:
 gvfs-daemons depends on gvfs-libs (= 1.24.2-0ubuntu0.1); however:
  Package gvfs-libs:armhf is not configured yet.

dpkg: error processing package gvfs-daemons (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of gvfs:armhf:
 gvfs:armhf depends on gvfs-daemons (&gt;= 1.24.2-0ubuntu0.1); however:
  Package gvfs-daemons is not configured yet.
 gvfs:armhf depends on gvfs-daemons (&lt;&lt; 1.24.2-0ubuntu0.1.1~); however:
  Package gvfs-daemons is not configured yet.
 gvfs:armhf depends on gvfs-libs (= 1.24.2-0ubuntu0.1); however:
  Package gvfs-libs:armhf is not configured yet.

dpkg: error processing package gvfs:armhf (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of gvfs-backends:
 gvfs-backends depends on gvfs (= 1.24.2-0ubuntu0.1); however:
  Package gvfs:armhf is not configured yet.
 gvfs-backends depends on gvfs-daemons (= 1.24.2-0ubuntu0.1); however:
  Package gvfs-daemons is not configured yet.
 gvfs-backends depends on gvfs-libs (= 1.24.2-0ubuntu0.1); however:
  Package gvfs-libs:armhf is not configured yet.

dpkg: error processing package gvfs-backends (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of gvfs-fuse:
 gvfs-fuse depends on gvfs (= 1.24.2-0ubuntu0.1); however:
  Package gvfs:armhf is not configured yet.

dpkg: error processing package gvfs-fuse (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 gvfs-libs:armhf
 gvfs-daemons
 gvfs:armhf
 gvfs-backends
 gvfs-fuse
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@orangepiplus:~# 

解決方法
「apt-get –reinstall install 問題となってるパッケージ名」を実行する。

今回の場合、エラーとなったパッケージを全部指定すればいいのかな、と「apt-get –reinstall install gvfs-libs:armhf gvfs-backends gvfs-daemons gvfs:armhf gvfs-fuse」を実行してみたもののエラー

root@orangepiplus:~# apt-get --reinstall install gvfs-libs:armhf gvfs-backends gvfs-daemons gvfs:armhf gvfs-fuse
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 5 reinstalled, 0 to remove and 0 not upgraded.
5 not fully installed or removed.
Need to get 0 B/91.1 kB of archives.
After this operation, 0 B of additional disk space will be used.
E: Internal Error, No file name for gvfs-daemons:armhf
root@orangepiplus:~#

では、と「apt-get –reinstall install gvfs-libs:armhf」と実行してみると、今度は成功。

root@orangepiplus:~# apt-get --reinstall install gvfs-libs:armhf
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
5 not fully installed or removed.
Need to get 0 B/91.1 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 111013 files and directories currently installed.)
Preparing to unpack .../gvfs-libs_1.24.2-0ubuntu0.1_armhf.deb ...
Unpacking gvfs-libs:armhf (1.24.2-0ubuntu0.1) over (1.24.2-0ubuntu0.1) ...
Setting up gvfs-libs:armhf (1.24.2-0ubuntu0.1) ...
Setting up gvfs-daemons (1.24.2-0ubuntu0.1) ...
Setting up gvfs:armhf (1.24.2-0ubuntu0.1) ...
Setting up gvfs-backends (1.24.2-0ubuntu0.1) ...
Setting up gvfs-fuse (1.24.2-0ubuntu0.1) ...
root@orangepiplus:~#

で、これ以降は、エラー無く、「apt-get upgrade」が実行できるようになりました。

LTOテープをファイルシステムとして使うLTFSについて 2015/11/18版


LTOテープをファイルシステムとして使うLTFSについて 2020/05/11版」にて内容を更新しました。


LTO-8がリリースされたので、「LTOテープをファイルシステムとして使うLTFSについて 2018/01/04版」という記事を作成し、情報を更新しました。


LTOテープ1本を持ち運びができるファイルシステムメディアとして使用できるようにするLTFSについて、LTO7メディアが市販され始めたということもあり、最近の状況について確認した。

LTO7関連で規格修正があるかな?と確認してみたが、2015/11/18現在で公開されている規格およびソフトウェアで、LTO7について言及しているものが見当たらなかったので、基本各リンク情報の更新となる。

(過去の関連記事:「LTOテープをファイルシステムとして使うLTFS(2012/11/28)」「テープ装置メーカ純正のLTFS一覧(2013/12/20更新)」「IBM版LTFSをRHEL5で使ってみた(2013/05/20)」「LTOテープをファイルシステムとして使うLTFSについて 2014/06/09版」)

LTFSとは?

LTO-5/LTO-6からは、メディアを2つの領域に分割して利用することが可能になった。
その機能を活かし、1本のテープメディアの中に、メディア内データの管理情報と、実データを分割して保存することを可能とした。
これにより、これまで実現出来なかった、1本のテープメディアだけで可搬性のあるファイルシステム構築、というものが可能となり、その実装として、LTFS(Linear Tape File System)というのがある。

使用用途としては、バックアップ用ではなく、長期保存のためのアーカイブ用や、大容量データの持ち運び用として使用されている。

LTFSを実現するためのソフトウェアについては、基本的には、IBMが大本のベースを作り、それを各LTOドライブメーカが、自社ドライブ向けにカスタマイズして提供しているような形となっている。

LTFSのバージョン(フォーマット)

LTFSには、バージョンがいくつかあり、現状気にしなければならないのは、以下の4つ
・LTFS 1.0
・LTFS 2.0 : ファイルインデックス関連で機能をいろいろ追加
・LTFS 2.1 : 2012/05/18リリース。LTFS2.0+シンボリックリンク(現在draft版)
・LTFS 2.2 : 2013/12/21リリース。管理情報の改良

「LTFSのバージョン」と「LTFSソフトウェアのバージョン」は別物なので注意が必要。
たとえば、OracleのLTFSソフトウェアは「ver1.2.7」だが、「LTFS 2.2」に対応している。

とはいえ、2015/11/18現在では、どのLTFSソフトウェアもLTFS 2.2に対応しているので、新規導入分に関しては特に気にする必要はない。

LTFS2.2の規格書はSNIAの「Linear Tape File System (LTFS)」の「Linear Tape File System (LTFS) Format Specification」にてpdfで公開されている。

その他、いろんな情報は、LTOの規格団体の「LTFS Overview」にある。

LTFSソフトウェアの種類

LTFSの公式認証を取得しているLTFSソフトウェアについては、「LTFS Compliance Verification」にて紹介されている。

2015/11/18時点では以下の6個が登録されている。

 Company

 Product

 Version

 LTFS Version*

 LTO Generation

 Date tested

 Quantum

 Quantum Scalar LTFS Appliance

 2.0.2

 2.0.1

 LTO5 & 6

 9/11/13

 HP

 HP StoreOpen Standalone

 2.1.0

 2.1.0

 LTO5 & 6

 9/11/13

 IBM

 IBM Single Drive Version

 1.3.0

 2.1.0

 LTO5 & 6

 9/11/13

 IBM

 IBM LTFS Library Edition

 V1R3

 2.1.0

 LTO5 & 6

 10/2/13

 Quantum

 Quantum LTFS

 2.1.0

 2.1.0

 LTO5 & 6

 11/29/13

 HP

 HP StoreOpen Automation

 1.2.0

 2.0.1

 LTO5 & 6

 11/29/13

 Spectra Logic

 Spectra Logic Black Pearl

 1.1

 2.2

 LTO5 & 6

 9/11/15

Spectra LogicのLTFSが追加された以外、2014年時点のものから更新がないが、実際には各LTFSソフトウェアともにバージョンアップを行っている。
なお、LTFSソフトウェアのバージョンと、対応しているLTFSフォーマットのバージョンに直接の関連性は無いので注意が必要。

各ドライブメーカが出しているLTFSソフトウェアについて

まずは、上記のリストに載っているメーカのものから。

・IBM
公式: IBM Spectrum Archive(IBM Linear Tape File System)

IBMのLTFSは「IBM Spectrum Archive」という商品名となった模様。
テープベンダのSpectra Logicとは関係がないようだ。

ソフトウェアの入手は、「Fix Central」にて「製品グループ:System Storage」-「Tape Systems」-「Tape drives and software」の下にある「IBM Spectrum Archive Single Drive Edition(SDE) (旧名:LTFS Single Drive Edition)」や「IBM Spectrum Archive Library Edition(LE)(旧名:LTFS Library Edition)」「IBM Spectrum Archive Enterprise Edition(EE)」を選択して行う。
なお、LEとEEの方はアップデータのみの配布で、元になるソフトウェアについては、IBMから別途入手する必要がある。
基本的には、Single Drive Edition(SDE)が、他の全てのLTFSソフトウェアの原型になっているもの・・・という感じである。

2015/11/18時点での最新は、
IBM Spectrum Archive Enterprise Edition: ver1.1.2.0(2015/07/27)
IBM Spectrum Archive Library Edition : ver2.1.5.0(2015/10/02)
IBM Spectrum Archive Single Drive Edition: ver2.2.1.0(2015/10/02)

・HP
公式: HP StoreOpen
日本語情報: HP LTFS (Linear Tape File System)

単体ドライブ向けのみだが「日本語の導入マニュアル」が用意されている。

分社化の影響で、LTFS関連はHP Enterpriseに移籍したが、関連リンクが更新されていないので、いろんなところでリンク切れが発生している。
ソフトウェア関連は「HP StoreOpen and Linear Tape File System (LTFS) Software」からたどる事になる。

ソフトウェアの入手は、単体ドライブ向けの「HP StoreOpen Standalone」も、チェンジャー向け「HP StoreOpen Automation」も上記のページの「Get drivers, software & firmware.」から行う。

2015/11/18時点での最新は、
HP StoreOpen Standalone : ver2.3.0(2015/04/30)
HP StoreOpen Automation : ver2.0.0(2014/11/06)

・Quantum
公式: Linear Tape File System

ソフトウェア入手は上記の公式ページの「Software」タブから行う。
ソースコードについては、LTFS Open Source Filesから。

2014/06/09時点での最新は、
Linux/Mac : ver2.1.2(2014/10)
Windows: ver2.2.1(2014/11)

Linux版のReleasenoteには、Quantum LTOドライブのほか、IBM LTOドライブにも対応という記述がある。

・Quantum Scalar LTFS Appliance
公式:Scalar LTFSアプライアンス

こいつだけ、他のとは違って、ハードウェアがセットになったアプライアンス。
これの下にFC経由などでテープチェンジャーを繋いで使うもの。

・Spectra Logic
公式:Linear Tape File System (LTFS)

LTFSを紹介するページはあるものの、LTFSを利用するソフトウェアに関するページが見当たらない。
また、バージョンもわからず。

リストに載っていない、LTFS

・TANDBERG DATA
公式: LTFS for Big Data Storage

ソフトウェアの入手は「LTFS Documents and Downloadsから行う。

2015/11/18時点での最新は
バイナリ: ver2.3.0

ページは英語表記だが、ドキュメントアイコンが日の丸になってるとおり、ダウンロードできるドキュメントは日本語化されている。
一部TANBERGカスタマイズが入っているようだが、基本的にはHP StoreOpen相当品。

・Oracle
公式: Oracle’s StorageTek Linear Tape File System, Open Edition

ソフトウェアの入手は「https://oss.oracle.com/projects/ltfs/files/」から行う。

2015/11/18時点での最新は
ltfs-1.2.7(2015/10/07)

IBM LTFS 2.2.0.2とHP LTFS 2.2.1を組み合わせ、Oracle/StorageTek用の設定を入れたもの。
Oracle LTOドライブ,IBM LTOドライブ,HP LTOドライブに対応している。

RHEL/CentOS6でSolarisみたいなsyslog出力を行う



Solarisからの移行ユーザからこんなことを言われた。

Solarisだとログ出力にFacitilyとPriorityがあるのに、Linuxはなんで無いの?

Solarisの例

Aug 21 18:30:26 solaris hme: [ID 517527 kern.info] SUNW,hme0 : Internal Transceiver Selected.
Aug 21 18:30:26 solaris hme: [ID 517527 kern.info] SUNW,hme0 :   100 Mbps Full-Duplex Link Up
Aug 21 18:30:54 solaris savecore: [ID 570001 auth.error] reboot after panic: [AFT1] errID 0x00090886.6bd9286c UE Error(s)
Aug 21 18:30:54 solaris     See previous message(s) for details
Aug 21 18:30:54 solaris ntpdate[175]: [ID 558275 daemon.notice] adjust time server 158.211.134.200 offset 0.350887 sec
Aug 21 18:30:58 solaris xntpd[186]: [ID 702911 daemon.notice] xntpd 3-5.93e Mon Sep 20 15:47:11 PDT 1999 (1)
Aug 21 18:30:58 solaris xntpd[186]: [ID 301315 daemon.notice] tickadj = 5, tick = 10000, tvu_maxslew = 495, est. hz = 100
Aug 21 18:30:59 solaris xntpd[186]: [ID 798731 daemon.notice] using kernel phase-lock loop 0041
Aug 21 18:30:59 solaris last message repeated 1 time
Aug 21 18:31:09 solaris pseudo: [ID 129642 kern.info] pseudo-device: tod0
Aug 21 18:31:09 solaris genunix: [ID 936769 kern.info] tod0 is /pseudo/tod@0

Linuxの例

Aug 26 17:11:52 centos6 postfix/postfix-script[32480]: stopping the Postfix mail system
Aug 26 17:11:52 centos6 postfix/master[32414]: terminating on signal 15
Aug 26 17:11:52 centos6 postfix/postfix-script[32552]: starting the Postfix mail system
Aug 26 17:11:52 centos6 postfix/master[32553]: daemon started -- version 2.6.6, configuration /etc/postfix

ふむ・・・確かに

/etc/rsyslog.confを編集して実現してみた。
参考資料
・Red Hat Enterprise Linux 6導入ガイド :「第20章 ログファイルの表示と管理

さすがにデフォルト出力を変えてしまうと、Linux側のツールでsyslogを処理した場合に問題が生じるので
Solaris互換のログファイルは別ファイルで出力させることにした。

設定を行った「/etc/rsyslog.conf」のサンプルは以下。

$template FacilityTmpl,"%timereported% %HOSTNAME% %syslogtag% [ID %MSGID% %syslogfacility-text%.%syslogseverity-text%]%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n"
mail.*                                         /var/log/solaris-compati.log;FacilityTmpl

その出力例

Aug 26 17:11:52 centos6 postfix/postfix-script[32480]: [ID - mail.info] stopping the Postfix mail system
Aug 26 17:11:52 centos6 postfix/master[32414]: [ID - mail.info] terminating on signal 15
Aug 26 17:11:52 centos6 postfix/postfix-script[32552]: [ID - mail.info] starting the Postfix mail system
Aug 26 17:11:52 centos6 postfix/master[32553]: [ID - mail.info] daemon started -- version 2.6.6, configuration /etc/postfix

「%MSGID%」に具体的な値が出力されず、「-」になってしまうというのは、Linux側の仕様なのかどうなのか???

まぁ、とりあえず、おおむね実現できたのでよしとした。