2014年6月11日水曜日

OpenSSL に発見されたChange Cipher Specの脆弱性を修正する。

脆弱性に関する概要と状況の確認

まず始めにこちら。 IPA「OpenSSL」における Change Cipher Spec メッセージ処理の脆弱性対策について


現在、インストールされているバージョンを確認します。

環境は、CentOS6.4となります。

[root@hostname ~]# openssl version
OpenSSL 1.0.1g 7 Apr 2014

前回のHeart Bleed脆弱性問題に対応したので、バージョンがOpenSSL 1.0.1gであることが確認できます。
今回は、このOpenSSL 1.0.1gにも脆弱性が確認されたとの事です。


( ´ー`)フゥー...

yumでパッチ適用済みのアップデートを利用する

既にパッチ適用済みのアップデートが、yumのアップデートで利用出来るようなので、こちらを利用させて頂きました。
【参考】 RedHat Important: openssl security update

[root@hostname ~]# yum check-update openssl
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: www.ftp.ne.jp
 * extras: www.ftp.ne.jp
 * updates: www.ftp.ne.jp

openssl.x86_64                     1.0.1e-16.el6_5.14                                              updates

脆弱性に対応済みの1.0.1e-16.el6_5.14となっていますね。
このままアップデートを実行します。

[root@hostname ~]# yum update openssl
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: www.ftp.ne.jp
 * epel: ftp.jaist.ac.jp
 * extras: www.ftp.ne.jp
 * updates: www.ftp.ne.jp
Setting up Update Process
Resolving Dependencies

  ~中略~

Updated:
  openssl.x86_64 0:1.0.1e-16.el6_5.14

Dependency Updated:
  openssl-devel.x86_64 0:1.0.1e-16.el6_5.14

Complete!

アップデートが完了したら、更新されたバージョンを確認して下さい。

[root@hostname ~]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

[root@tnxnet ~]# rpm -qa openssl*
openssl-1.0.1e-16.el6_5.14.x86_64
openssl-devel-1.0.1e-16.el6_5.14.x86_64


最後に、必ずOpenSSLを利用しているサービス またはサーバーを再起動して下さい。
お疲れ様でした。 ⊂⌒(。・ω・)っ お役に立てたら嬉しいです。

2014年4月8日火曜日

OpenSSLの脆弱性 への緊急対応 (1.0.1gへのアップデート : CentOS6.5)

OpenSSLの重大バグが発覚。インターネットの大部分に影響の可能性

以下、引用
セキュリティー研究者らが “Heartbleed“と呼ぶそのバグを悪用すると、
過去2年以内のあらゆるバージョンのOpenSSLが走るシステムで、システムメモリー上にある大量のデータを暴露することが可能だ。

問題のバグは、OpenSSLの “heartbeat” という機能の実装に存在する。そこから “Heartbleed” と名付けられた。

このバグは、OpenSSLに2年以上存在していたが(2011年12月以来、OpenSSL 1.0.1~1.0.1f)、今日初めて発見され公表された。
さらに悪いことには、このバグを悪用してもその痕跡はログに残らないようだ。
つまり、システム管理者は自分のサーバーが侵入されたかどうかを知る術がない。されたと仮定するほかはない。

元記事
IPA OpenSSL の脆弱性対策について(CVE-2014-0160)
IT media OpenSSLに脆弱性、クライアントやサーバにメモリ露呈の恐れ


これは大変ですね。

Can attacker access only 64k of the memory?

There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat.
Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary
number of 64 kilobyte chunks of memory content until enough secrets are revealed.

1回あたりは64KBのデータしか取れないようですが、繰り返し続けることでデータも盗り続けられるとの事です。

影響範囲は、(Affected 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1) 1.0.2-beta, 1.0.2-beta1

公式Fixed in OpenSSL 1.0.1gが既に公開済みとなっています。
というか、Heartbleedとか名前かっこいい……。中二心がくすぐったい。

以下、CentOS6.5で対応したログです。


openssl-1.0.1gのインストール

現在のバージョン確認

# openssl
OpenSSL> version
OpenSSL 1.0.1e-fips 11 Feb 2013

最新版のインストール

# cd /usr/local/src/

# wget https://www.openssl.org/source/openssl-1.0.1g.tar.gz

# tar -xzf openssl-1.0.1g.tar.gz

# cd ./openssl-1.0.1g

# ./config --prefix=/usr --openssldir=/etc/ssl --libdir=lib shared zlib-dynamic

# make

# make install 

最新版インストール後のバージョン確認

# openssl
OpenSSL> version
OpenSSL 1.0.1g 7 Apr 2014

あとは、リポジトリのファイルが最新になるのを待ちましょう。(・ω・´)


脆弱性のチェックツール

チェックツールのインストールと使用方法について。

インストール

# wget http://gobuild.io/github.com/titanous/heartbleeder/master/linux/386 -O output.zip

# unzip output.zip

# ls
heartbleeder LICENSE README.md

使い方

# ./heartbleeder www.fu*itv.co.jp
INSECURE - www.fu*itv.co.jp:443 has the heartbeat extension enabled and is vulnerable

あああああ。 フ○テレビさん ><;

(現在は修正済みです。[does not have the heartbeat extension enabled])

HP Proliant RAIDを監視する

RAIDステータスの取得(監視)

環境説明

最近、部室に設置したHP製のサーバー。ML350p Gen8

(画像はwww8-hp.comから)

ハードウェア(サーバー) HP Proliant ML350p Gen8
ハードウェア(RAIDカード) HP Smartアレイ P420
オペレーションシステム CentOS 6.5 (2.6.32-431.el6.x86_64)

ソフトウェアのダウンロード

HPサポートセンターから、P420(別のRAIDカードの場合は、その製品名)で検索。
検索結果から「この製品に対応するすべてのドライバー、ソフトウェア、ファームウェアを表示してダウンロードします。 」のリンクを押下。
対象となるオペレーションシステムを選択し、必要なソフトウェアをダウンロードします。
または、ProLiant Support Pack(PSP) v9.10から、Proliant Support Packをダウンロードして下さい。
今回は、こちらのパック(psp-9.10.rhel6.x86_64.en.tar.gz)を取得しました。

psp-9.10.rhel6.x86_64.en.tar.gzを解凍すると、カレントディレクトリにワサッっと大量のファイルが展開されてしまうので注意。
解凍後、必要なファイルを選んで直接インストールしました。

hpacucli

インストール

hpacucliコマンドを使う為、hpacucli-9.40-12.0.x86_64.rpmをインストールします。

# rpm -ivh ./hpacucli-9.40-12.0.x86_64.rpm

使い方

hpacucliコマンドを使って、現在のRAIDの状態を表示・確認することが出来ます。 (対話型でも可能)

// ディスクの確認
# hpacucli  ctrl all show config

Dynamic Smart Array B120i RAID in Slot 0 (Embedded)



Smart Array P420 in Slot 2                (sn: XXXXXXXXXXXXXXX)

   array A (SATA, Unused Space: 0  MB)


      logicaldrive 1 (1.8 TB, RAID 1+0, OK)

      physicaldrive 1I:0:1 (port 1I:box 0:bay 1, SATA, 1 TB, OK)
      physicaldrive 1I:0:2 (port 1I:box 0:bay 2, SATA, 1 TB, OK)
      physicaldrive 1I:0:3 (port 1I:box 0:bay 3, SATA, 1 TB, OK)
      physicaldrive 1I:0:4 (port 1I:box 0:bay 4, SATA, 1 TB, OK)

   SEP (Vendor ID PMCSXXXX, Model SRCXXXX) 380 (WWID: XXXXXXXXXXXXXXX)



// バッテリーの確認
# hpacucli controller all show status

Dynamic Smart Array B120i RAID in Slot 0 (Embedded)
   Controller Status: OK

Smart Array P420 in Slot 2
   Controller Status: OK
   Cache Status: OK
   Battery/Capacitor Status: OK


cciss_vol_status

インストール

cciss_vol_statusを使用するためには、kmod-hpahcisr-1.2.6-13.rhel6u1.x86_64.rpmをインストールする必要があります。
(こっち[2]もあったので入れておきました。kmod-hpahcisr-1.2.6-13.rhel6u2.x86_64.rpm)

# rpm -ivh kmod-hpahcisr-1.2.6-13.rhel6u1.x86_64.rpm

# rpm -ivh kmod-hpahcisr-1.2.6-13.rhel6u2.x86_64.rpm

使い方

# cciss_vol_status -V /dev/sg0
Controller: Smart Array P420
  Board ID: 0x9999999c
  Logical drives: 1
  Running firmware: 5.22
  ROM firmware: 5.22
/dev/sda: (Smart Array P420) RAID 1 Volume 0 status: OK.
  Physical drives: 4
         connector 1I box 0 bay 1          ATA     XXX XXXXXXXX-00L           XX-XXXXXXXXXXXX 01.01A01 OK
         connector 1I box 0 bay 2          ATA     XXX XXXXXXXX-00L           XX-XXXXXXXXXXXX 01.01A01 OK
         connector 1I box 0 bay 3          ATA     XXX XXXXXXXX-00L           XX-XXXXXXXXXXXX 01.01A01 OK
         connector 1I box 0 bay 4          ATA     XXX XXXXXXXX-00L           XX-XXXXXXXXXXXX 01.01A01 OK

こんな感じです。 cciss_vol_statusの方より、hpacucliの方が使い勝手良さそう。

SNMPエージェントもインストールして試してみたいですね!!(・ω・`)


関連する記事

mdadmを使ったソフトウェアRAID1+0の実装

2014年4月3日木曜日

日本語形態素解析(mecab + php)

日本語形態素解析の導入方法

日本語の形態素解析には、いくつかの方法があると思います。
今回は、PHPで作成された掲示板に実装されているNGワード判定処理への苦情が多く寄せられた為、急遽対応しました。


mecabのインストール

# cd /usr/local/src/

# wget http://mecab.googlecode.com/files/mecab-0.996.tar.gz
# tar xzf mecab-0.996.tar.gz
# cd mecab-0.996
# ./configure --with-charset=utf8
# make
# make install

mecabライブラリ(IPA)のインストール

# wget http://mecab.googlecode.com/files/mecab-ipadic-2.7.0-20070801.tar.gz
# tar xzf ./mecab-ipadic-2.7.0-20070801.tar.gz
# cd ./mecab-ipadic-2.7.0-20070801
# ./configure --with-charset=utf8
# make
# make install

PHP用ライブラリのインストール

# pear channel-discover pecl.opendogs.org
# pear remote-list -c opendogs
# pear install opendogs/mecab-beta
specify pathname to mecab-config [no] : /etc/mecab/mecab-config
...
You should add "extension=mecab.so" to php.ini

php.iniの設定

# locate mecab.so
/usr/lib64/php/modules/mecab.so

# vi /etc/php.d/mecab.ini
extension=mecab.so


使用例・結果

ばか えろ の単語を含む文字列を指定してみました。

<?php
$mecab = new MeCab_Tagger();
var_dump($mecab->parse("君ばかりがバグを出している。環境を考えろと言われても困ります。"));
?≶

君ばかりがバグを出している。環境を整えろと言われても困ります。
君      名詞,代名詞,一般,*,*,*,君,キミ,キミ
ばかり  助詞,副助詞,*,*,*,*,ばかり,バカリ,バカリ
が      助詞,格助詞,一般,*,*,*,が,ガ,ガ
バグ    名詞,一般,*,*,*,*,バグ,バグ,バグ
を      助詞,格助詞,一般,*,*,*,を,ヲ,ヲ
出し    動詞,自立,*,*,五段・サ行,連用形,出す,ダシ,ダシ
て      助詞,接続助詞,*,*,*,*,て,テ,テ
いる    動詞,非自立,*,*,一段,基本形,いる,イル,イル
。      記号,句点,*,*,*,*,。,。,。
環境    名詞,一般,*,*,*,*,環境,カンキョウ,カンキョー
を      助詞,格助詞,一般,*,*,*,を,ヲ,ヲ
整えろ  動詞,自立,*,*,一段,命令ro,整える,トトノエロ,トトノエロ
と      助詞,格助詞,引用,*,*,*,と,ト,ト
言わ    動詞,自立,*,*,五段・ワ行促音便,未然形,言う,イワ,イワ
れ      動詞,接尾,*,*,一段,連用形,れる,レ,レ
て      助詞,接続助詞,*,*,*,*,て,テ,テ
も      助詞,係助詞,*,*,*,*,も,モ,モ
困り    動詞,自立,*,*,五段・ラ行,連用形,困る,コマリ,コマリ
ます    助動詞,*,*,*,特殊・マス,基本形,ます,マス,マス
。      記号,句点,*,*,*,*,。,。,。

2014年3月31日月曜日

MySQL5.6でのレプリケーション設定 (複数のデータベース)

今回は、MySQL5.6がインストールされた環境で、複数のデータベースを指定したレプリケーション設定を行いました。
構成はマスター&スレーブの2台となります。
MySQL5.6からリリースされたGTID機能を試してみたかったのですが、今回は都合により通常のレプリケーション設定になりました。
通常のレプリケーション設定なので今更感がハンパないですが、一応ブログに残しました。

サーバーにインストールされているOSは、Centos5.8(x86_64)となります。
ここでは、マスター側のサーバーIPアドレスを192.168.1.40とし、スレーブ側のサーバIPアドレスを192.168.1.50としています。
(レプリケーション設定を行う際は、対象のMySQLサーバーでの作業は全て停止してください。)



マスター側の設定 (192.168.1.40)

マスター側のMySQL設定ファイル(/etc/my.cnf)の[mysqld]項目に設定を追加しました。
log_bin設定:バイナリログの出力先を指定します。
server-id設定:サーバーを識別するための一意な値を指定します。
    (ここでは、IPアドレスのホスト部をserver-idとして指定しました)

[root@192.168.1.40 ~]# vi /etc/my.cnf

[mysqld]

~中略~

# バイナリログの出力先設定
log_bin = /var/lib/mysql/mysql-bin

# レプリケーションサーバーIDの指定
server-id = 40


マスター側の設定が完了したらMySQLを再起動。

[root@192.168.1.40 ~]# /etc/init.d/mysqld restart


続いて、mysqldumpを使って現在のDBのスナップショットを作成。
(スレーブ側に作成したスナップショットのファイルを転送しておいて下さい)

[root@192.168.1.40 ~]# mkdir /home/tanaka/mysqldump/

[root@192.168.1.40 ~]# mysqldump -u root -p --lock-all-tables target_database_name_1 > /home/tanaka/mysqldump/target_database_name_1.sql

[root@192.168.1.40 ~]# mysqldump -u root -p --lock-all-tables target_database_name_2 > /home/tanaka/mysqldump/target_database_name_2.sql

スレーブ側からアクセスするためのユーザーを作成します。
(障害に備え、スレーブ側にも同様のユーザーを作成しています)
ユーザー名はrepl。 パスワードはpasswordに設定しました。
また、アクセスを許可するネットワークも192.168.1.0/24(192.168.1.%)で指定しています。

[root@192.168.1.40 ~]# mysql -u root -p -e "GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@192.168.1.% IDENTIFIED BY 'password';"


重要:最後に、SHOW MASTER STATUSを実行し、ファイル名と現在のポジションを取得しておきます。

mysql> SHOW MASTER STATUS \G
*************************** 1. row ***************************
             File: mysql-bin.000001
         Position: 1234
     Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)


[PR] MySQL関連書籍の紹介


スレーブ側の設定 (192.168.1.50)

スレーブ側のMySQL設定ファイル(/etc/my.cnf)の[mysqld]項目に設定を追加しました。
log_bin設定:バイナリログの出力先を指定します。
server-id設定:サーバーを識別するための一意な値を指定します。
    (ここでは、IPアドレスのホスト部をserver-idとして指定しました) ・relay-log設定:リレーログの出力先設定。名称を固定にするため、指定しておきます。
・他、log_slave_updates, read_only, replicate-do-db, replicate-ignore-db

[root@192.168.1.50 ~]# vi /etc/my.cnf

[mysqld]

~中略~

# バイナリログの出力先設定
log_bin = /var/lib/mysql/mysql-bin

# レプリケーションサーバーIDの指定
server-id = 50

# リレーログの出力先設定
relay-log=/var/lib/mysql/mysql-relay-bin

# レプリケーションサーバをチェーン状に構成する
#log_slave_updates=1

# レプリケーション スレーブ サーバで、この値を ON に設定すると、サーバが SUPER 権限を持つユーザ以外からの更新が出来ません。
# スレーブサーバは、マスタ サーバからの更新だけを許可し、クライアントからの更新を拒否します。
# この動作は TEMPORARY テーブルには使えません。 
#read_only=1

# レプリケーション対象データベース
replicate-do-db='target_database_name_1'
# レプリケーション対象データベース
replicate-do-db='target_database_name_2'
# レプリケーション対象外データベース
replicate-ignore-db='target_database_name_3'


read_only値については、(テンポラリ)テーブルを作成するようなアプリケーションでは使用出来ないとの事。
セキュリティ的にはONにしたい値ですが、今回のアプリケーションではテーブル作成処理も発生するので未指定にします。(´・ω・`)


設定ファイルの準備が出来たら、スレーブ側のMySQLサーバーにレプリケーション対象となるデータベースを作成して下さい。
先程、マスター側で生成したmysqldumpのファイルを流し込みます。
(マスター側で生成したファイルをスレーブ側に転送しておいて下さい)

[root@192.168.1.50 ~]# mysql -u root -p

mysql> CREATE DATABASE `target_database_name_1`;

mysql> CREATE DATABASE `target_database_name_2`;


mysql> exit

[root@192.168.1.50 ~]# mysql -u root -p target_database_name_1 < /home/tanaka/mysqldump/target_database_name_1.sql

[root@192.168.1.50 ~]# mysql -u root -p target_database_name_2 < /home/tanaka/mysqldump/target_database_name_2.sql


スレーブ側の設定が完了したら、こちらもMySQLを再起動。

[root@192.168.1.50 ~]# /etc/init.d/mysqld restart


障害時に、このスレーブがマスターに昇格した際、新たなスレーブ側からアクセスされるためのユーザーを作成しておきます。

[root@192.168.1.50 ~]# mysql -u root -p -e "GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@192.168.1.% IDENTIFIED BY 'password';"


準備が出来たら、レプリケーション設定を完了させます。
スレーブ側のMySQLにログインをし、次の項目を指定しました。
MASTER_HOST 接続先(マスター)サーバーのIPアドレス(またはホスト名)
MASTER_PORT 接続先(マスター)サーバーの接続ポート番号
MASTER_USER, MASTER_PASSWORD マスター側に作成したアクセス用ユーザーの名前とパスワード
MASTER_LOG_FILE 接続先(マスター)サーバーで生成されたバイナリファイルのファイル名を指定します。
MASTER_LOG_POSには、マスター側でSHOW MASTER STATUSを実行した際に確認したポジション値を入力します。(ここでは1234としています)

設定が完了したら、START SLAVEを実行してレプリケーションを開始させて下さい。

[root@192.168.1.50 ~]# mysql -u root -p
mysql> CHANGE MASTER TO
  MASTER_HOST='192.168.1.40',
  MASTER_PORT=3306,
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=1234;


mysql> START SLAVE;



レプリケーション動作の確認

レプリケーションが正常に動作しているかは、マスター側のデータを更新することで確認出来ます。
(SHOW MASTER STATUSSHOW SLAVE STATUSを実行することによって得られるポジションの同期が取られているかなど)


お役に立てましたら幸いです c(・ω・´c⌒っ


Master

mysql> SHOW MASTER STATUS \G
*************************** 1. row ***************************
             File: mysql-bin.000001
         Position: 35854
     Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set:



mysql> SHOW PROCESSLIST \G
*************************** 1. row ***************************
     Id: 3
   User: repl
   Host: 192.168.1.40:36811
     db: NULL
Command: Binlog Dump
   Time: 1277
  State: Master has sent all binlog to slave; waiting for binlog to be updated
   Info: NULL


Slave

mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.40
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 35854
               Relay_Log_File: mysql-relay-bin.000001
                Relay_Log_Pos: 36017
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: target_database_name_1,target_database_name_2
          Replicate_Ignore_DB: target_database_name_3

~略~


mysql> SHOW PROCESSLIST \G
*************************** 1. row ***************************
     Id: 1
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 1327
  State: Waiting for master to send event
   Info: NULL
*************************** 2. row ***************************
     Id: 2
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 41
  State: Slave has read all relay log; waiting for the slave I/O thread to update it
   Info: NULL


2014年3月13日木曜日

OpenVPN+Sambaによる拠点間通信(ルーティングモード)でのファイル共有 - その1

OpenVPNを使った拠点間接続を実現する

拠点間VPN接続を用いた別ネットワークとの接続。
今回は、オープンソースソフトウェア(Open Source Software)であるOpenVPNを使用して、環境の構築に挑戦しました。
この記事はシリーズ記事となります。

[Section1] 要件概要と簡単な構成予定のネットワーク図

ネットワーク1(システム開発部)とネットワーク2(ゲーム開発研究部)とのネットワークをVPN接続させ、ネットワーク2内のクライアント(Windows-PC)からもネットワーク1に設置されたファイル共有サーバーを利用可能にします。

ネットワーク1をホスト(固定のグローバルIP)。 ネットワーク2をリモートとしてネットワークを構築します。

192.168.0.0/24
(ネットワーク1)
VPNサーバー
(ホスト)
CentOS 6.4 (x86_64)
192.168.0.10
openvpn 2.3.2-1
共有サーバー CentOS 5.8 (x86_64)
192.168.0.20
samba 3.0

192.168.5.0/24
(ネットワーク2)
VPNサーバー
(クライアント)
CentOS 6.4 (x86_64)
192.168.5.10
openvpn 2.3.2-1

下図では
192.168.0.0/24のネットワークを、ネットワーク1(システム開発部)
192.168.5.0/24のネットワークを、ネットワーク2(ゲーム開発研究部)
として説明しています。

次回は、ネットワーク1のVPNサーバー(ホスト)の設定を行います。

2014年2月5日水曜日

Postfix2.10以降で発生するリレー接続エラー (454:Relay access denied)

554ではないRelay access denied

Postfixを2.9以前のバージョンから2.10以降のバージョンへ更新すると、 次のようなエラーが発生してリレー接続が出来なくなってしまう場合があるようです。
軽くハマったので残しておきます。(・ω・`)

said: 454 4.7.1 <xxxxxxx@xxxxxxxx.xxx>: Relay access denied (in reply to RCPT TO command)

どうやら2.10以降では、パラメータとデフォルト値などに少し変更があったようです。
以下はpostfix.orgのマニュアルから抜粋。

smtpd_relay_restrictions (default: permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination)

Access restrictions for mail relay control that the Postfix SMTP server applies in the context of the RCPT TO command, before smtpd_recipient_restrictions.

This feature is available in Postix 2.10 and later.

smtpd_relay_restrictions (RCPT TOコマンドの場面で適用するメールリレー用のアクセス制限設定)
2.9以前はsmtpd_recipient_restrictionsパラメータで設定されていたものが、このパラメータで設定するようになったとの事です。

取り敢えず、2.9以前のsmtpd_recipient_restrictionsパラメータのデフォルト値を確認してみました。

[root@localhost ~]# postconf smtpd_recipient_restrictions
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

2.10以降ではsmtpd_relay_restrictions パラメータのデフォルト値は以下。
(下位互換の確保として、smtpd_recipient_restrictionsのパラメータ自体も使えはするみたいですが、でも値は空になっています。)

[root@localhost ~]# postconf smtpd_relay_restrictions 
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination 

[root@localhost ~]# postconf smtpd_recipient_restrictions
smtpd_recipient_restrictions =  

今回の場合では、アップデートによってpermit_sasl_authenticated値が追加された事で、SMTP:454の応答が返却されていたんですね。

2014年1月29日水曜日

Subversion - Could not open the requested SVN filesystem

svn checkoutが出来ない場合

試験用に突貫構築した環境で、svnリポジトリからチェックアウトを行った際、次のようなエラーに遭遇しました。

[Wed Jan 1 00:00:00 2014] [error] [client 192.168.13.125] Could not open the requested SVN filesystem  [500, #2]



[root@localhost ~]# getenforce
Enforcing

SELinuxが有効のままでした(゚ω゚;)


SELinuxを無効にする ①

現在のSELinux設定を無効にする方法。その1。

[root@localhost ~]# setenforce 0


SELinuxを無効にする ②

現在のSELinux設定を無効にする方法。その2

[root@localhost ~]# echo 0 > /selinux/enforce


起動時のSELinuxを無効に設定する

起動時のSELinux設定を無効に設定します。
以下の作業を行うことで設定可能です。

[root@localhost ~]# vi /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
#SELINUX=enforcing  ← コメントアウト
SELINUX=disabled  ← 追記した行
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted



結果の確認 (再起動前)

[root@localhost ~]# getenforce
Permissive

[root@localhost ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          disabled
Policy version:                 21
Policy from config file:        targeted


結果の確認 (再起動後)

[root@localhost ~]# getenforce
Disabled  

[root@localhost ~]# sestatus
SELinux status:                 disabled

2014年1月23日木曜日

【活動議事録4】 報道しない自由

明かされる真実

昨年末から更新が滞っているじょしかい!!
その理由(わけ)が今、明かされる!?

じょしかい!!トーク【活動議事録】シリーズ 第四弾です。
>第三弾はこちら


鈴木 和音

「どうしたんですか? 今日もやけにドヤ顔で」

田中 雪菜

「ンフー! 見るのだ和音!!

    2014年1月17日(金)に行われた裁判で、言論・表現の自由を保障する合衆国憲法修正第1条に関して
    ブロガーはジャーナリストと見なされる、という判決が下されました。
    この判決によると、例え正式な報道機関に属していない人でも、憲法上はジャーナリストと同じ権
    利が保障され、例えば家に帰って趣味でブログを書いている人でも法律上はジャーナリストとして
    扱われることになります。

  じょしかい!! ジャーナリズム宣言!

鈴木 和音

「また意味の分からない斜め上な発言ですね。
  ただそれを言いたかっただけですよね。 先輩
  というか、ここは日本ですよ」

田中 雪菜

「え。 じゃあ、『じょしかい!!』も言える事、少なくなるね……」

鈴木 和音

「じゃなくて、そもそもこの判決は憲法上はジャーナリストと同じ権利が保障されるって事ですよね。

  それに、言えることが少なくなるも何も、最近は『言いたいこと』も無いんじゃないですか?
  ブログもずっと更新してないですし」

田中 雪菜

「……。
  ………。
  過ぎた言論や表現の自由は炎上につながるからね! 更新は慎重に♪(・ω<)」

鈴木 和音

言い訳かよ!




話題元

GIGAZINE ブロガーはジャーナリストとして権利が保障されるという判決が下される