named-chrootで「named.pid not readable」2014年07月29日 14時11分

久しぶりにFedoraをアップグレード(17→20)。

一通り終わってから確認してみると、named-chroot(bind-chroot)がエラーで終了している。エラー内容は

「PID file /var/named/chroot/run/named/named.pid not readable (yet?) 」

と出ていてPIDファイルが読めないということか?しかしアクセス権を確認してみても何が不足しているのかが分からない。

色々調べた結果、どうやら「named.conf」ファイルに「pid-file /run/named/named.pid」と追記すればいいらしい。
とりあえず言われた通りやってみたら立ち上がってはきたが、なぜこれが必要なのかが分からなかった。


しかし、後々よく見てみるとyumでアップグレードした際に、bindは正常に終了していたが、bind-chrootだけエラーでバージョンアップが失敗してfc17のままなのが分かった。一旦bind-chrootをremoveしもう一度インストールし直せば、先ほどのpidファイルの指定はなくても普通に立ち上がってきた。

どうやらfc17以降、いつかは分からないがpidファイルのデフォルトの保存先が変わったらしい。


いつもながら終わってみれば他愛もない原因ではある。しかし解決できれば気持ちのいいものでもある。

firewalldの代わりにiptables2014年07月23日 14時54分

Fedora18以降はデフォルトのファイアウォールサービスが「iptables」から「firewalld」に変わったらしい。


おそらく新しいfirewalldの方が使いやすく機能も優れているのだろうが、iptablesで登録してあるルールを設定しなおす時間がない。

とりあえずiptablesを継続して使うこととする。

1. 「yum install iptables-services iptables-utils」 でインストール。

2. 「systemctl disable firewalld」と「systemctl stop firewalld」でfirewalldサービスを止める

3.「systemctl start iptables」でiptablesサービスを起動。


なかなかlinuxに注ぐ時間がないが、その間にどんどん変化していってるなぁ・・・。

DVDからyum2014年07月18日 15時19分

久しぶりにFedoraをアップグレードしようとしたらできない。


知らないうちに17のサポートは終了していましたよっと。


インターネット経由でyumを使った更新ができないので、DVDから行う方法を探す。
yumがどこのサイトに更新を見に行くかは、「/etc/yum.repos.d/」ディレクトリにあるレポジトリファイル(.repo)に記述してある「baseurl」と「mirrorlist」で決まる。今回ver.17のサポートが終了してしまっているためこのアドレスから更新を取得することはできない。

まず既存のレポジトリを無効にする。レポジトリファイルにある「enable=」を「1(有効)」から「0(無効)」に変更。

次に更新に使用するDVDをマウントする(仮に mount /dev/CDROM /media/CDROM とする)

新規に/etc/yum.repos.d ディレクトリにレポジトリファイルを作成。ファイルの名前は「fedora-dvd.repo」とする。

ファイルの内容としては、

[fedora-dvd]
name=Fedora 17 DVD
baseurl=file:///media/CDROM
enable=1
gpgckeck=0

といった感じ。


注意するのは「baseurl=file:」の後のスラッシュ(/)は3本。たったこれだけの不注意のために無駄な時間を使ってしまった・・・。

Fedora17 postfix 起動せず2012年11月07日 15時30分

bindのトラブルが解決したと思ったら今度はpostfixが起動しなくなった。

エラーの内容としては、

open lock file /var/lib/postfix/master.lock: cannot open file: Permission denied

内容だけをみれば、このファイルにアクセス権がないということなので、 master.lockファイルにもposfixディレクトリにもアクセス権をフルコントロール与えてみたが、 同じエラーが出つづけた。

postfix をアンインストールし、/var/lib/postfixディレクトリや/etc/postfixディレクトリを削除してインストールしなおしてみても解決はしなかった。


最終的に分かったことは「/var/lib」ディレクトリのアクセス権が750(root:root)になっていたためだった。
アクセス権を755に戻したら正常に起動したわけだが、問題はなぜそのディレクトリのアクセス権が変わってしまったかだ。そんなところをいじった憶えはないのだが・・・


だが得てしてこういう時は、自分が覚えていないだけでやっているものだが・・・


Fedora17 bind-chroot が起動せず2012年11月07日 15時27分

bindの設定をいじっていたら、起動しなくなってしまった。

/var/run/named/named.pid does not exist


というエラーが出る。どうやら間違って/var/run のアクセス権を750から700に変えてしまったらしい。 (root:namedの場合)

まあ終わってみれば当たり前の事だが、焦っていると気付かないものだ。

Fedora17のdovecot2012年11月01日 12時49分

Fedoraを13から17にアップグレードしたわけだが、どうやらdovecotの設定がいままでとは違う。

メールをクライアントが受信しようとした際に、

Plaintext authentication disallowed on non-secure (SSL/TLS) connections

というエラーがでる。今まではdovecot.confに

 disable_plaintext_auth = no

という記述を追加すれば解決していたが、今回はどうもそれでは
うまくいかない。

 いろいろ調べたところ、「/etc/dovecot/conf.d/」以下にある設定ファイルを
いじる必要があるらしい。

 まずは「10-auth.conf」というファイルを編集する。

  # allow plain text auth
disable_plaintext_auth = no

# allowed authentication mechanism, at least these 2 options
auth_mechanisms = plain login

とする。最後の「login」はなくても可?
 次に「10-ssl.conf」というファイルを編集。

 ssl=no

に変更。

 とりあえずこれだけの設定でサービスを再起動すればエラーは出なくなりメールの受信ができるようになった。
どうやら今までは「dovecot.conf」という1つのファイルで設定していたが、これからは、
「conf.d」ディレクトリにある個別のファイルで設定するようになったらしい。

 ちなみにMaildirの設定は直接「dovecot.conf」に記述してもうまくいったが、本来は、
「conf.d」以下の「10-mail.conf」ファイルに

  mail_location = maildir:~/Maildir

を記述するのが正しいらしい。

Fedora17でCtrl+Alt+Deleteを無効にする2012年10月31日 11時36分

関連: http://sakanade.asablo.jp/blog/2008/07/08/3616246

Fedora17において「Ctrl+Alt+Delete」で再起動するのを防ぐ方法。

/lib/systemd/system/ctrl+alt+delete.target

の名前を変える。これしか思いつかない。

Fedora13→17にupgrade2012年10月30日 19時14分

Fedoraを13からいっきに17へバージョンアップ。
パーティションも切りなおしたいので、クリーンインストールした。

その際に確認した設定の違い。


1.サービスの起動・終了 及び 自動起動

 今までは

  /etc/rc.d/init.d/サービス start(stop)

 で起動(終了)していたが、今度からは

  systemctl start(stop) サービス

 になった。同様に自動起動も

  /sbin/chkconfig  サービス  on(off)

 から、

  systemctl  enable(disable) サービス 

に変更。ちなみに「chkconfig --list」は「systemctl --full list-unit-files」

2.iptablesの設定保存方法が変更

 従来は、

  /etc/rc.d/init.d/iptables save

 だったが、

  /sbin/iptables-save > /etc/sysconfig/iptables

 になった。

3.SELinuxの設定ファイル変更
 SELinuxを止める際の設定ファイルの場所が、

  /etc/sysconfig/selinux

 から、

  /etc/selinux/config

 に変更。


4.dovecotの設定ファイル変更

 FC13からdovecot.confをそのままFC17にコピーしたがエラーが出て起動しない。
 調べるのもめんどくさいので、そのまま新しいdovecot.confを編集して使用。

 ・・・が、どうやら大きく設定がかわっていたらしい。
 http://sakanade.asablo.jp/blog/2012/11/01/6620467


5.デュアルブートでデフォルトのOSを変更
 「/etc/grub2.conf」を編集。

6.IBMサーバーのRAID管理ソフトバージョンアップ
 IBMのHPから最新版のApplicationCDをダウンロード&インストール

とりあえず気付いたのは以上。

メールユーザー一括登録 注意点2012年10月25日 17時30分

関連 http://sakanade.asablo.jp/blog/2008/07/01/  
    http://sakanade.asablo.jp/blog/2008/07/03/3607821


1.既存のサーバーの受信済みメールを移行するために、USBメモリを用意する。USBメモリは「ext3」でフォーマットする。FAT形式では、「/Maildir/cur」ディレクトリにあるファイル名が長すぎてバックアップできない。

「cp: cannot create regular file `/mnt/usb/Maildir/cur/**********************.2,S': Invalid argument」

 というエラーがでる。

 fdisk /dev/sdb1 で「d」で削除、「n」で作成(プライマリp1)、「w」で書込み、「p」で確認。
 mkfs.ext3 /dev/sdb1 でフォーマット
 (*再度「fdisk -l」で確認しても表示はFATのままだが、普通にEXT3として使える)


2.サーバーのデータ「/home/ユーザー名/Maildir」はアクセス権を維持したままバックアップ

  cp -rp /home /mnt/usb/

3.Windows上で作るユーザーリストは2つ必要

 list1.txt  アカウント名1:ユーザーID1 
        アカウント名2:ユーザーID2 

 list2.txt  アカウント名1:パスワード1 
       アカウント名2:パスワード2 

  という形にする。
 ユーザーIDは新旧サーバーで一致させないと、データを移行したときに
 正しくアクセス権が反映されない。



4.Windows で作成したリストは2つともlinux上で改行コードを変更

  dos2unix ファイル名

5.ユーザーを一括で取り込むシェルスクリプト

for line in `cat list1.txt`

do

user=`echo $line |cut -d: -f1`
id=`echo $line |cut -d: -f2`

/usr/sbin/useradd -g mailuser -u $id -s /sbin/nologin $user
echo $user 
echo $id

/usr/sbin/setquota $user 20480 20480 0 0 -a

done

/usr/sbin/chpasswd < list2.txt

6.「2」でバックアップしたデータを新しいサーバーにコピー

  cp -rp /mnt/usb/* /home/

fedora upgrade 13 → 142010年11月12日 09時39分

ついでにテスト環境のFedoraを13から14にアップグレードしてみた。アップグレード自体はそれほど問題なく完了した。

一通りサービスが動いていることを確認。すると、メールが受信できない。dovecotは正常に動いているようなのだが、受信をしようとすると、

Disconnected (tried to use disabled plaintext auth):

というエラーが出て受信できない。
Dovecotの設定ファイルを確認してみると今までは「/etc/dovecot.conf」だったと思うが、「/etc/dovecot/dovecot.conf」に変わっている。どうやらコンフィグファイルの保存場所が変わり新しいものに置き換わってしまったらしい。そしてplaintext(平文?)の認証が許可されていないのが原因らしい。

disable_plaintext_auth = no

の記述を追加したら正常に受信が可能となった。

その他Maildir等個別の設定をしている場合は、mail_location等の再設定が必要と思われる。