BLTC社製LEDランプ販売開始
(株)ラブテックではBLTC社(台湾)製LEDランプの販売を開始いたしました。
次世代の照明器具として注目されているLED。しかし、国内製品のほとんどが器具一体型であるため、取付には電気工事が必要です。唯一販売されている東芝製LEDランプも照度が低く、ダウンライトなどで使用するには暗すぎて実用的ではありません。
「既存の器具を生かしてLEDを使いたい」というのは誰しも考えることですが、開発途上の製品だけになかなか価格と性能の折り合いの良い製品が少ないというのが現状です。
そんな中で、十分に実用レベルの明るさを持ちながら既存の白熱用器具が使用でき、尚かつ価格も手の届く範囲である同社の製品はLED照明の普及に拍車をかけるものだと思っています。


BLT2026シリーズ
第一弾として6W~18Wまでの4製品ライン24種のLEDランプを販売いたします。
製品の詳しい情報は弊社の運営する「ECO照明情報サイト」で御覧下さい。
また、7月1日より同製品を含む省エネ照明専門ウェブショップもオープンいたしますので、こちらのほうもよろしくお願いいたします。
次世代の照明器具として注目されているLED。しかし、国内製品のほとんどが器具一体型であるため、取付には電気工事が必要です。唯一販売されている東芝製LEDランプも照度が低く、ダウンライトなどで使用するには暗すぎて実用的ではありません。
「既存の器具を生かしてLEDを使いたい」というのは誰しも考えることですが、開発途上の製品だけになかなか価格と性能の折り合いの良い製品が少ないというのが現状です。
そんな中で、十分に実用レベルの明るさを持ちながら既存の白熱用器具が使用でき、尚かつ価格も手の届く範囲である同社の製品はLED照明の普及に拍車をかけるものだと思っています。


BLT2026シリーズ
第一弾として6W~18Wまでの4製品ライン24種のLEDランプを販売いたします。
製品の詳しい情報は弊社の運営する「ECO照明情報サイト」で御覧下さい。
また、7月1日より同製品を含む省エネ照明専門ウェブショップもオープンいたしますので、こちらのほうもよろしくお願いいたします。
Tips!--LDAP利用についてのいろいろ
バーチャルドメイン環境をLDAPを利用して構築してきたわけだが、LDAPを使用する上で思い通りの動作にならずに悩んだ点がいくつかあったのでそれについて少し触れておく。
・phpldapadmin使用でのLDAPアクセス制御設定
まずはLDAPのアクセス制御についての記述だ。LDAPを利用するサービスと参照すべき内容、項目に対する権限などを事前に精査してまとめておく必要があるだろう。今回の場合、
・postfix →メールの配送制御で使用
・Smtp Auth →認証で使用
・dovecot →pop、imapの認証に使用
と基本的には3つなのだが、ウェブからLDAPエントリーの書き換えを行うためにphpldapadminも使用しているので、
・phpldapadmin →アカウント管理に使用
となる。サービスに関しては管理者をバインドで接続して全ての情報取り出しをしているので問題ないが、アプリケーションであるphpldapadminについては各アカウント管理ユーザーの接続とするつもりだった。
この場合のLDAPサーバーアクセス制御記述なのだが、参考にしたサイトにあった記述を弊社用に置き換えると
access to dn=".*,ou=mailsys,dc=lavtec,dc=JP" attribute=userPassword
by self write
by dn="cn=Manager,dc=lavtec,dc=JP" write
by dn="uid=admin, name=
・phpldapadmin使用でのLDAPアクセス制御設定
まずはLDAPのアクセス制御についての記述だ。LDAPを利用するサービスと参照すべき内容、項目に対する権限などを事前に精査してまとめておく必要があるだろう。今回の場合、
・postfix →メールの配送制御で使用
・Smtp Auth →認証で使用
・dovecot →pop、imapの認証に使用
と基本的には3つなのだが、ウェブからLDAPエントリーの書き換えを行うためにphpldapadminも使用しているので、
・phpldapadmin →アカウント管理に使用
となる。サービスに関しては管理者をバインドで接続して全ての情報取り出しをしているので問題ないが、アプリケーションであるphpldapadminについては各アカウント管理ユーザーの接続とするつもりだった。
この場合のLDAPサーバーアクセス制御記述なのだが、参考にしたサイトにあった記述を弊社用に置き換えると
access to dn=".*,ou=mailsys,dc=lavtec,dc=JP" attribute=userPassword
by self write
by dn="cn=Manager,dc=lavtec,dc=JP" write
by dn="uid=admin, name=
連載--ホスティングサーバーの再構築(番外編)
前回までの行程で一通りのサーバー構築を完了し、実際に運用を始めている。
追加の機能としてメーリングリストを作りたいと思ったのだが、バーチャル環境での構築に関しての情報がこれまた少ないわけだ。
メーリングリストサーバーにはmajodomo、fml、Mailmanなどいろいろあるわけだが、使用するサーバーによってはかなりややこしい仕込みをしないとバーチャル環境では動いてくれないようなのは解ってきた。
かかる手間が同じなら運用がわかりやすいほうがいいかと思い、管理をウェブ上から行えるMailmanを使用してみることにした。
インストールマニュアルを参考にインストールと初期セットアップは普通に終了した。MTAにpostfixを使う場合の基本的な設定もmain.cfには書き込んだが基本的にメーリングリストサーバーはローカルで配送するのでマニュアルに書かれている内容だけの記述では配送でエラーが出てしまう。
Debianなどは専用にカスタマイズしたものが用意されていてmaster.cfのパイプを使って配送できるようなのだが、あいにくとRedHat系のOSにはそういった便利なものは入っていなかった。
要はMailmanで使用するMLのアドレスをローカル配送するようにすればいいわけなので、配送方法を指定するtransport_mapsディレクティブを使用することにした。
まずはpostfix側に設定した内容。
#マニュアルに書かれている内容の追記
owner_request_special = no
recipient_delimiter = +
#エリアスマップの追加
virtual_alias_maps = ldap:/etc/postfix/forward.cf
ldap:/etc/postfix/virtual-alias.cf
hash:/etc/mailman/virtual-mailman ←追加行
#トランスポートマップの設定
trransport_maps = hash:/etc/mailman/transport
次に/etc/mailman/transportファイルを作成する。内容はMLのアドレスをローカル配送にするという単純なもの。
#MLトランスポートの設定
ml@domain1.net local
これをハッシュファイルに変換する。
# postmap /etc/mailman/transport
先にメールサーバー構築で使用したテストアカウントをメーリングリストに登録してテストしてみると、うまく配送された。試しに外部プロバイダのアカウントをメーリングリストに登録してみるとここでエラー発生。ログを確認するとリレーアクセスではねられている。
postfixのリレー制御を調整しなければならないようだ。送信はローカルからなので問題ない。問題は受信者アドレスにあるようだ。
現在のmain.cfで設定している受信者リレー制御は、
smtpd_recipient_restrictions = permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
確かにこのままではローカルからの送信だとはねられてしまう。majodomoのようにリストユーザーが単純なテキストファイルで保存されていればよかったのだが、Mailmanの場合そんな単純な形式では保存されていない。
ちょっと面倒だがリストメンバーを記述したアクセスマップを作成してそれを使うことにした。具体的には /etc/postfix/ 配下にrecipientというファイルを作成し、accessファイルと同じ形式でメールアドレスを許可リストとして登録した。
つまり、
メールアドレス1 OK
メールアドレス2 OK
のように書いたファイルを作成しハッシュしておく。次にmain.cfの smtpd_recipient_restrictions に一行追加する。
check_recipient_access hash:/etc/postfix/recipient
postfixをリロードして再度送信してみると今度はうまくいった。
メーリングリストの運用もこれでできるようになって一通りの機能は網羅できた。次回から今回の構築で直面したいくつかの問題について、どのような手法で解決したかをTipsとして掲載することにする。
追加の機能としてメーリングリストを作りたいと思ったのだが、バーチャル環境での構築に関しての情報がこれまた少ないわけだ。
メーリングリストサーバーにはmajodomo、fml、Mailmanなどいろいろあるわけだが、使用するサーバーによってはかなりややこしい仕込みをしないとバーチャル環境では動いてくれないようなのは解ってきた。
かかる手間が同じなら運用がわかりやすいほうがいいかと思い、管理をウェブ上から行えるMailmanを使用してみることにした。
インストールマニュアルを参考にインストールと初期セットアップは普通に終了した。MTAにpostfixを使う場合の基本的な設定もmain.cfには書き込んだが基本的にメーリングリストサーバーはローカルで配送するのでマニュアルに書かれている内容だけの記述では配送でエラーが出てしまう。
Debianなどは専用にカスタマイズしたものが用意されていてmaster.cfのパイプを使って配送できるようなのだが、あいにくとRedHat系のOSにはそういった便利なものは入っていなかった。
要はMailmanで使用するMLのアドレスをローカル配送するようにすればいいわけなので、配送方法を指定するtransport_mapsディレクティブを使用することにした。
まずはpostfix側に設定した内容。
#マニュアルに書かれている内容の追記
owner_request_special = no
recipient_delimiter = +
#エリアスマップの追加
virtual_alias_maps = ldap:/etc/postfix/forward.cf
ldap:/etc/postfix/virtual-alias.cf
hash:/etc/mailman/virtual-mailman ←追加行
#トランスポートマップの設定
trransport_maps = hash:/etc/mailman/transport
次に/etc/mailman/transportファイルを作成する。内容はMLのアドレスをローカル配送にするという単純なもの。
#MLトランスポートの設定
ml@domain1.net local
これをハッシュファイルに変換する。
# postmap /etc/mailman/transport
先にメールサーバー構築で使用したテストアカウントをメーリングリストに登録してテストしてみると、うまく配送された。試しに外部プロバイダのアカウントをメーリングリストに登録してみるとここでエラー発生。ログを確認するとリレーアクセスではねられている。
postfixのリレー制御を調整しなければならないようだ。送信はローカルからなので問題ない。問題は受信者アドレスにあるようだ。
現在のmain.cfで設定している受信者リレー制御は、
smtpd_recipient_restrictions = permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
確かにこのままではローカルからの送信だとはねられてしまう。majodomoのようにリストユーザーが単純なテキストファイルで保存されていればよかったのだが、Mailmanの場合そんな単純な形式では保存されていない。
ちょっと面倒だがリストメンバーを記述したアクセスマップを作成してそれを使うことにした。具体的には /etc/postfix/ 配下にrecipientというファイルを作成し、accessファイルと同じ形式でメールアドレスを許可リストとして登録した。
つまり、
メールアドレス1 OK
メールアドレス2 OK
のように書いたファイルを作成しハッシュしておく。次にmain.cfの smtpd_recipient_restrictions に一行追加する。
check_recipient_access hash:/etc/postfix/recipient
postfixをリロードして再度送信してみると今度はうまくいった。
メーリングリストの運用もこれでできるようになって一通りの機能は網羅できた。次回から今回の構築で直面したいくつかの問題について、どのような手法で解決したかをTipsとして掲載することにする。
