「Mountain Lion Server」カテゴリーアーカイブ

またphpが動いていない

OSXサーバで、また、php で構成したページ(ownCloudとかWebメールのroundcubeなど)が動いていない。CGI は問題ない。OSをアップデートしたからだ。

/Library/Server/Web/Config/apache2 の

httpd_server_app.conf の110行目の

LoadModule php5_module modules/libphp5.so

がコメントアウトされている(#が頭に付いている)からだ。この# を削除すればいい。apache が php モジュールを読み込んでないからだ。削除して

$ /usr/sbin/apachectl restart でapachを再起動しておしまい。

もう何回目かなこのトラブルは。どうやって直したか、覚えていないんだよね。

ちゃんと記録してあってよかったね。毎回このメモを見るんだよな。なさけない。

Mountain LionサーバのEl capitanへ更新ー未完

Macでサーバを構築しているのだが、自宅の方のサーバがこの夏調子悪かった。OSX 10.8.6 Mountain Lionでサーバ管理.appは10.6.5 なわけで、現在の最新がOSX 10.11 El capitanなので3世代前なのだ。調子悪いし、遅いから…そろそろ新しい機器に更新かな、と思ったわけだ。んでEl capitanのダウンロード開始前のYosemiteのMac Mini を購入しちゃったわけだ。

結局、不調の原因はHDDが壊れたからで、一気に壊れてくれればいいのに、うじうじ壊れて行ったので、解決に時間がかかってしまった。

んで、現在のサーバをOSX 10.11 El capitan、OSXServer5.0 にするのだ。その方法としては

(1)新しいMac Mini のSDDに現在のサーバのTimeMachinで バックアップした外付けHDDからTimeMachineで復元する。つまり新しいMac Mini を古いOSで動かすわけだ。その後El Capitanなどにアップデートしていく。これが一番楽なのでは?

(2)新しいMacMiniをOSX 10.11 El capitan、OSXServer5.0にして、TimeMachinで バックアップした外付けHDDから移行アシスタント.app で吸い上げる。

(3)現在のMacMini をOSX 10.11 El capitan、OSXServer5.04にアップデートして、これをTimeMachine でバックアップし、このTimeMachine で記録したHDDを使って、TimeMachine で新しいMacMini のSDDに復元する。

(1)はだめだった。TimeMachineで新しいMacMiniのSSDに復元しようとしたら、適応できないと拒否された。

(2)はデータはともかく移動することができそうだが、これをシコシコ再設定しないといけない。Mailman とかWordpress のデータベースの再設定はうまくいくのだろうか?試しに移行アシスタント.appを動かしたら、ユーザが一杯できた。そりゃそうだな、adminとかmailman とか一杯あるからな。これじゃ面倒だな。全てを新しく設定し直すのと大差ない。

(3)は、現在のMacMiniが最新のバージョンにアップデートできるかどうかが問題だ。調べたら、現在のMacMiniは2010年3月に購入している。注文書のメールに記載してある製品番号がMC408J/AだからLate 2009 ということになる。 OSX 10.11 El capitanはMac Mini の場合 Early 2009以降だったらインストールできるようだ。だからできる可能性が高い。

OSXServer5.04はOSX10.10.5 Yosemite 以降ならOKだ。いまさらOSXServer 4 は手に入らないし。多分El Capitan に上げることができたら、その後インストールできるだろ。だから、次回のトライは(3)だ。

(3)の手順は

1)現行のMachineを起動できるUSBメモリーにEl capitanインストーラをコピーして、このUSBメモリーから起動できること・ユーティリティが使えることを確認する。TimeMachine で復元するのに必要だ。

2)ネットから切り離し、現行のMacMiniのバックアップをTimeMacine とCarbonCopyCloner でそれぞれ別HDDにバックアップしてから始めないと連続性が保たれない。失敗したら復元できないと最悪な結果になるからな。

3)そんで、El capitan OSXServer5.04 にアップして、ネットに接続するが、localだけでテスト*1)して、うまくいくことを確認する。だめだったら、潔く2)で作成したTimeMachieHDDから復元して、もとに戻して再考する。

4)local ネットからも切り離し、TimeMachine で別HDD にコピーし、このHDDから新しいMacMini のSDDに復元する。復元できて起動できて、local net でテストし問題なかったら、入れ替えて、本来のTimeMachine とCarbonCopyCloner でそれぞれ別のHDDにバックアップして、ネットに接続する。

*1テストとはメール(PostFix)、Webメール(Squirrel Mail/Round cube)、メーリス(Mailman)、ブログ(WordPess)だな。php の設定とか引き継がれているのかしらん?

 

アプリを開けない

CarbonCopyCloner (CCC)を無料の時(つまり開発時)から愛用しているのだ。このバックアップアプリはイメージファイルとして保存するのではなく、そのままバックアップ(クローン)するので、ファインダーレベルで、昔のファイルを取り出すことができる。

仕事で使っているMacも、管理しているMacサーバも、TimeMachine と併用してバックアップしている。つまり異なった方法でのバックアップHDDが2台あるのだ。

有料になって、最新バージョンを購入したとき(去年の10月だ)、端末のMacでアンインストールに失敗したのか、新しいのがインストールできない状況のまま放置しちゃったのだ。

最初のアンインストールを間違えたようなので、アンインストール方法のページにしたがって、フアイルを捨てたんだけど、新規インストールできないのね。よくわからないので放置していたのだ。

1年も立っちゃって、改めて、先週末に、開発元にHelp me メールを、Webページ経由で出したら、きちんと返信されてきた。開発元が英語圏なので、返事は英語と自動翻訳した日本語だ。Web サイトが日本語表示だったので、日本語で問い合わせたから、向こうも自動翻訳で英語にして解釈して返信してきたのだろう。自動翻訳の日本語は何をいっているかよくわからん。

私はあなたが持っているもののトラブルわからないんだけど、それはあなたがCCCをアンインストールしようとしたように聞こえる、と今あなたがCCCを開くことができません。次のことをお試しください:

最初の返信メールは、トラブルの状況の確認だった。多分、自動翻訳では不十分だったんだろうね。「起動すると、開けません。」というがトラブルだ。

20151006CCC_Boot

やっぱし、画面でみるのが早いのだろう。画面のコピーを添えろと指示されたので、この画面のハードコピーと英語と日本語の説明を付けた。

つぎのメールは、Mac本体のsystem.log を送付しろということなので、添付した。system.log の場所も示していたので親切だ、というか、普通はわからないから当たり前か。この日本語も自動翻訳でよくわからん。

おそらく、我々は、なぜOS Xの意志ではないオープンCCCを記録システムから決定することができます。あなたはここにSYSTEM.LOGファイルを添付することはできますか?あなたは/アプリケーション/ユーティリティ/コンソールアプリケーションでそれを見つけることができます。ファイルを明らかにするために、ファイルメニューの「Finderで表示」を選択した後、サイドバーにある「system.logに」をクリックします。

英語のほうは;

Perhaps we can determine from the system log why OS X will not open CCC. Can you attach the system.log file here? You can find it in the /Applications/Utilities/Console application. Click on “system.log” in the sidebar, then choose “Show in Finder” from the File menu to reveal the file.

なので、英語のほうがわかりやすい。

3回目のメールで「It looks like the application is getting quarantined by GateKeeper:」といってきて、「xattr -c -r “/Applications/Carbon Copy Cloner.app”」をターミナルで実施すればいいと指示してきた。 この日本語の指示は;

アプリケーションがゲートキーパーによって隔離きているように見えます

アプリケーションの「検疫」の属性を削除するには、ターミナルアプリケーションに次のように貼り付け、それを開くために、再試行してください:

だ。ま、Gatekeeper が何であるか知っているのならなんとなくわかるよ。

その通り実施して、新しいCCCを開くことができて、問題がなくなった。

ダウンロードしたアプリケーションはMacOSXが怪しいかどうかチェックする。そのアプリがGatekeeper で、普通のアプリではないからアプリケーションやユーティリティにはない。怪しいと隔離するわけだ。この隔離にあってしまったということだ。アンインストールに失敗したわけではなかった。隔離するとそのファイル(フォルダ)の拡張属性に隔離のタグがついてしまう。この拡張属性とは、ターミナルでファイル名を見ると権限属性のあとに@がついているやつだ。この@が拡張属性ついたファイル・ディレクトリで、MacOSだけが理解できるメタ情報なので、これをつけたまま、サーバにアップロードしたりWinに移すと読めなくなってしまう可能性がある。Macで作成したファイルをWin で見ると._hoge とかいうファイルが見える。これはこの拡張属性 が取り除かれた結果だ。

何故、隔離されちゃったのかは今となってはわからない。一度、隔離のフラグが立っちゃうと、これを捨てて新しいものをダウンロードしてもフラグが立ったままのようだ。「App Store から購入したものじゃないから開けないよ」というときはコントロールキーを押して開くと、開くことを選択できる。このとき開くのをやめると隔離されちゃうのかな?ちがうだろ。

ダウンロードしたアプリを開こうとしたとき、「壊れているから開けません」なんていうプロンプトがでてきたら、隔離されちゃったことを意味する場合がある。隔離を解除するかどうかは自己責任ですな。

この拡張属性を削除するコマンドがxattr なのだ。ターミナルで man xattr とすればコマンドの意味と使い方がわかる。

The xattr command can be used to display, modify or remove the extended attributes of one or more files, including directories and symbolic links.

というわけだ。extended attributes=拡張属性だ。オプションの -c は;

the -c option (“clear”), causes all attributes
(including their associated values), to be removed.

で、 全て削除だよということで、-r は;

If a file argument is a directory, act as if the entire contents of
the directory recursively were also specified (so that every file in
the directory tree is acted upon).

ということで、単一ファイルでなくdirectoryの場合は -r を付けなさいということだ。-R とかと同じ意味だ。CCC.app はアイコンになっていて、見かけ一つのファイルだけど実はdirectory(フォルダ)だからね。

まともと思われるアプリが開けなかったら、自己責任でやってみる価値がある。

開けないときCCC.appに @ が付いていたかどうか確認して見ればよかったが、

Mac:Applications hoge$ ls -al

を実施すると @ のついたアプリがいっぱいある。だからCCC  にも@がついていたのだろう。xattr を実施したあとだから、今はついていない。@が付いているほとんど全部が購入後にインストールしたアプリだ。でも隔離したというフラグが立っているわけではない。App Store から購入したアプリ(OSのインストーラなど)には付いていない。

こいうことはトラブルになって、始めて知ることになる。

例えば ImageJ をダウンロードし、解凍してできた ImageJ というフォルダをApplications 内に置き、su になって

sh-3.2# pwd
/applications
sh-3.2# xattr -c -r ImageJ
sh-3.2#

とすればいい。

FTPのパッシブ(PASV)モード接続。

考えてみたら、YAMAHAのルータ(NVR500)のファイヤーウオールでFTPでパッシブモード(PASV)接続ができないようになっていた。動的フィルタのftp を入る 出る 両方にチェックを付けるといいと思うけど、いいのかな。

20150929FirewallpassiveFTP

いいはず。

この動的IPフィルタのftp の設定で 入 にチェックがついていないと;

Mac$ ftp user@example.com
Connected to example.com.
220 example.com FTP server ready.
331 Password required for user.
Password:
230 User user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
227 Entering Passive Mode (123,123,123,123,246,156)
ftp: Can’t connect to `123.123.123.123′: Connection refused
200 PORT command successful.
150 Opening ASCII mode data connection for directory listing.
total 48
drwx—— 13 user staff 442 Sep 9 07:05 Desktop
drwx—— 13 user staff 442 May 5 2010 Documents
226 Transfer complete.
ftp>

これはサーバの(246*256+156)番ポートでデータの送受信を行いますよとパッシブモードでトライしたんだけど、接続できなく、ポートモードで接続したら成功したということのようだ。この場合サーバのポートは20番である。つまりパッシブモードで接続できない、自動的にアクティブ(ポート)モードになってデータの送受はできるようになる。

入 にチェックが入っていると;

Mac$ ftp user@example.com
Connected to example.com.
220 example.com FTP server ready.
331 Password required for user.
Password:
230 User user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
227 Entering Passive Mode (123,123,123,123,246,156)
150 Opening ASCII mode data connection for directory listing.
total 48
drwx—— 13 user staff 442 Sep 9 07:05 Desktop
drwx—— 13 user staff 442 May 5 2010 Documents
226 Transfer complete.

パッシーブモードで、サーバは(246*256+156)番ポートでデータを送受信しますよということで、(246*256+156)番ポートがファイヤーウオールの動的フィルタで開いたのでそのままOKとなったわけだ。

アクティブ(ポートモード)からパッシブモードに自動的に変化してだめならアクティブモードにもどりデータのやり取りを行うらしい。この間の時間が無駄だからパッシブでできるようにしておくのがいい。

アクセス元のファイヤーウオールでポート20を閉じているとアクティブモードが通らないから、アクセス先のサーバのファイヤーウオールはパッシブモードが通るようにしておいたほうがいい。

この解釈でいいのかしらん?

アクティブFTPとパッシブFTPというサイトが参考になった。

なんでこんな昔からのFTPのよくあるトラブルになったのかというと、職場のファイヤーウオール機がこの連休に交換されたわけだ。それ以来FTPが使えなくなってしまった。つまり、交換以前はポート20番が開いていたのだ。ひょっとして、管理者がここに赴任したときFTPを使うために20番を開けろと依頼したのではないだろうか。憶えていない。PASVモードだと途中にNAT変換などがあるとうまくいか無いことが多い。クライアント側もサーバ側もNAT変換をやっているわけで、うまくいなかのでアクティブモードでやるのが一番楽だったのだ。で、ファイヤーウオールが交換されて20番が塞がっちゃって、PASVでないとできなくなったのだ。でサーバ側のファイヤーウオールでFTPは動的フィルタで対応したらできるようになったのだと思う。しかし、FTPが通らないという管理者のクレームに対して、こっちのネットの管理者は委託業者に何か依頼してファイヤーウオールの設定を変えたらしいのだが、なにを変えたのかはわからない。

証明書の有効期限がまもなく切れます

MacOSXサーバだ。

「証明書の有効期限がまもなく切れます – mike.md.tsukuba.ac.jp コード署名証明書」てのが。期限切れ1ヶ月前から毎日朝8時に来る。

更新するのは面倒なので、「プロファイルマネージャで新しい証明書を使う」にしたけどいいのかな?

[ 追伸 ] 9月29日

だめだった。

[ 追伸 ] 10月1日

コード証明書というのを見たら、どうやら、もう1台の一時的なサーバに関する証明書のようなので、キーチェーンからその証明書を削除した。どうなるだろ。自身で作った自分自身の証明書ではないし、捨ててもsshやメールは問題ないからな。この一時的なサーバは存在しないしね。

証明書を削除したんだから、警告メールは来なくなった。当然だな。いつこの証明書を作って、どうして維持してきたのかよくわからない・覚えていない。ひどいもんだ。

CarbonCopyClonerのトラブル

CarbonCopyCloner(CCC)をつかっているわけだが、大学オフィスのMac では最新版に変更しようとして、なにか間違えたアンインストールをおこなったのか、最新版をインストールできなくなってしまった。

1台のサーバにインストールしたやつは、バックアップ終了後、メールで連絡するように設定したのだが、不安定なのだ。

成功したとき
09/08 01:15:58 Everyday: Posting an email notification…
09/08 01:15:58 Everyday: Suppressing the task finished panel as requested.
09/08 01:15:58 Client: Attempting to connect to server at: localhost:25 [kCFStreamSocketSecurityLevelNone]
09/08 01:15:58 Everyday: Scheduling for 2015年9月9日水曜日 1時00分00秒JST
09/08 01:16:01 Everyday: Carbon Copy Cloner v. 3.5.7 is up to date
09/08 01:16:05 Successfully sent an email notification to admin@exanple.com

失敗した時
09/09 01:16:23 Everyday: Posting an email notification…
09/09 01:16:23 Everyday: Suppressing the task finished panel as requested.
09/09 01:16:23 Client: Attempting to connect to server at: localhost:25 [kCFStreamSocketSecurityLevelNone]
09/09 01:16:23 Everyday: Scheduling for 2015年9月10日木曜日 1時00分00秒JST
09/09 01:16:26 Everyday: Carbon Copy Cloner v. 3.5.7 is up to date
09/09 01:16:31 Client: Attempting to connect to server at: localhost:465 [kCFStreamSocketSecurityLevelNegotiatedSSL]
09/09 01:16:39 Client: Attempting to connect to server at: localhost:587 [kCFStreamSocketSecurityLevelNone]
09/09 01:16:39 Server: 530 5.7.0 Must issue a STARTTLS command first
09/09 01:16:39 Failed to send an email notification to admin@exanple.com: Relay rejected. (530)

昨日の8日は成功しているのに、そして何も変更していないのに今日9日は失敗なのだ。CCCが自らのSMTPサーバに送付するとサーバが受け付けてくれない。テストメールを送信すると成功するのだ。原因がわからん。

SMTPのログを見ると

成功したとき
Sep 8 01:16:05 www postfix/smtpd[8825]: connect from localhost[127.0.0.1]
Sep 8 01:16:05 www postfix/smtpd[8825]: BC77AC75BF: client=localhost[127.0.0.1]
Sep 8 01:16:05 www postfix/cleanup[8829]: BC77AC75BF: message-id=
Sep 8 01:16:05 www postfix/qmgr[168]: BC77AC75BF: from=, size=2249, nrcpt=1 (queue active)
Sep 8 01:16:05 www postfix/smtpd[8825]: disconnect from localhost[127.0.0.1]

失敗したとき
Sep 9 01:16:31 www postfix/smtpd[80513]: connect from localhost[127.0.0.1]
Sep 9 01:16:31 www postfix/smtpd[80513]: lost connection after CONNECT from localhost[127.0.0.1]
Sep 9 01:16:31 www postfix/smtpd[80513]: disconnect from localhost[127.0.0.1]
Sep 9 01:16:39 www postfix/smtpd[80552]: connect from localhost[127.0.0.1]
Sep 9 01:16:39 www postfix/smtpd[80552]: lost connection after EHLO from localhost[127.0.0.1]
Sep 9 01:16:39 www postfix/smtpd[80552]: disconnect from localhost[127.0.0.1]

というわけでログみても同じことが書いてあるだけでわからん。
ちなみに「lost connection after EHLO」は認証に失敗したときのメセージだ。認証を使ってない。CCCの方で最初は認証無しで、失敗したらポート465、587で接続をためしているわけだ。
それにしてもログを見ると、あちこちからリレー要求がある。ホワイトリストで自分のネットからしか通してないから全てリジェクトだ。

[ 追伸 ] 不安定なのはHDDが壊れかけていたからだ。HDD交換でトラブルは解消した。

サーバの引っ越し

このサーバが設置してある建物の耐震工事が始まるので、研究室等は一時避難場所に引っ越しになるのだ。研究室の引越し先は遠いので、そこにこのサーバを持っていくのはちとしんどい。耐震工事が既に終了した続きの建物の一室へ居候することにした。

今朝がその引越である。同じフロアの20m位しか離れていない場所なので、30分もあれば終わると踏んでいたわけだ。移転先にLANケーブルは用意したし、電源も確保した。だから、UPS、サーバ本体、ファイヤーウオール、モニタだけ移動するのだ。一人で30分で終わる。UPSが重いけどなんとかなる。というわけで朝7時に始めた。予定通り、移動して、サーバを起動した。

んが、動いているように見えない。モニタに何も出てこない。順調に動いている機器を移動させる、ケーブルを差し替えて再起動する、などを行うと、隠されていたトラブルが出てくることがよくあるのだ。弱った。モニターになにも出てこないとどうしようもない。外からログインもできない。なんじゃ???

このサーバ機にはLANポートが2つある。どっちを使っていたかマークしていない。管理者がいい加減だからだ。モニタに出てくれば、すぐどっちのポートだったかわかるわけだが、それができない。多分接続ポートが違うんだろということで、ポートを変えたら、外からログインできた。サーバ機能も問題なさそうだ。というわけで問題はモニタだけだ。ビデオカードがこわれたとは考えにくい。

あとからみたら管理者宛のメールにip addressが変わったという警告メールがきていた。7時3分に間違ったip address、7時30分に正しいip addressに変更になったというメールが発信されていた。つまり移動して誤ったポートにLANケーブルさして起動したのが7時3分。おたおたして、正しいポートにつなぎ変えて再起動したのが7時30分というわけだ。30分余計にかかってしまったわけだ。

モニタを交換してみたが、同じだ。シグナルが来ていないということだ。どうやら問題なく動いているので、コネクタの接触不良だろ。しっかり挿して、ネジを回して固定したら見えるようになった。

というわけで、移動してもなにも問題はなかったわけだ。1時間つぶれてしまった。朝、早いからユーザはまだ寝ているにちがいないから、ユーザに連絡することもしなかった。30分とちょっと止まっていたけど、多分わからなかっただろ。そもそも、この8月末から、本幹のネットワークのスイッチの更新がおこなわれていて、20分位とぎれることがあったのだが、誰も何も行ってこないからな。ヘビーユーザは管理者だけだし。

TimeMachine が遅い件

TimeMachine が遅いのは

1)アンチウイルスソフトがうごいているから

2)Spotlight の検索範囲が大きいから

ということのようで、1)はサーバ機で、定時にアンチウイルスソフトを止めてからTimeMachineを動かすなど不可能じゃないけど面倒なので、まず2)をデフォルトから変更してみた。

TimeMachineEditor で一日午前3時だけバックアップするように設定してある。Spotlightの変更前の本日の朝3時からのバックアップは;

15/08/27 3:00:01: Starting standard backup
15/08/27 3:00:01: Backing up to: /Volumes/TimeMachine/Backups.backupdb

15/08/27 4:01:08: Backup completed successfully.

というわけで1時間かかっている。

Spotlightの検索範囲は、デフォルトではすべてにチェックがついているけど。これを

20150827Spotlight

と、3つだけにした。さらに、バックアップHDDは検索範囲外とした。

20150827Spotlight-2

どうなるだろ。10.7 ではTimeMachineの宛先HDDをここで指定しては行けないという記事がある。

HDDのアクアス権修復、CCCのバックアップ先HDDの修復とアクセセス権の修復、TimeMachineのHDDの修復とアクセセス権の修復を実施した。

これで今晩はどうなるか、明日早朝チェックしてみる。

[ 追記 ] 次のバックアップは20分に縮小した。Spotlight検索範囲を減らすというのは効果があった。20分だったら、ま、いっか。次の日は18分だった。

サーバ機なので、ファイルの検索なんかやらないということで、Spotlightを止めちゃうことが考えられる。

Spotlightの動作停止は

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

再開は

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

らしい。まだためしていない。

もういっちょのMacサーバがこけた

Notice: Undefined index: post_content in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 42 Notice: Undefined index: post_excerpt in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 45 Notice: Undefined index: post_author in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 46 Notice: Trying to get property of non-object in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 47 Notice: Undefined index: post_author in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 48 Notice: Trying to get property of non-object in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 49 Notice: Undefined index: post_author in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 50 Notice: Undefined index: post_modified in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 60 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 65 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 69 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 73 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 74 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 80 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 98 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 152 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 159 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 192 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 331 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 1043 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 1132 Notice: Undefined index: ID in /Users/sigh/Sites/blog/wp-content/plugins/download-manager/libs/class.Package.php on line 1133

自宅サーバがこけた。原因は不明。リモートログインできないから、なんともしがたく、21日(金)日に帰宅して再起動してなんとか動くことになったのだが、ものすごく遅い。

今朝、DVDから起動して、とりあえず、アクセス権の修復とデイスクの修理だけを実施したら早くなったのでこのままにしておく。
今晩、バックアップが実施されるからそのバックアップがすぐに終わるようだったら、このままにする。

CarbonCopyCloner(CCC)のバックアップは通常十数分で終わるのに、17日〜19日は25分以上もかかっている。20日、21日は失敗。
今晩、20分以内だったら修理は終了したとする。

どうやらもういっちょのバックアップアプリTimeMachineのせいのようだ。TimeMachineがバックアップ動作を行うと、著しく処理が遅くなる。これはデフォルトの設定で1時間毎に行うことになっていて、その間隔を変更することはできない。

CCCは夜中の1時に実施しているわけだが、TimeMachineの実施時刻とたまたまぶつかってしまったのではないだろうか。TimeMachineの1時間毎というのは、開始時刻が1時間毎なんだろうか、それとも終了してから1時間後なんだろうか。後者のような気がする。最新のバックアップの時刻と次のバックアアップ時刻はちょうど1時間ではない。だいたい1時間でだんだんずれていくのではないだろうか。だとすると2つのバックアップが同時に動作開始になって、おかしくなってしまったことが考えられる。

TimeMachine の動作間隔は自由に設定できないので、これを変更できるアプリが必要だ。

TimeMachineEitor というのがある。現在のバージョンは4.2.1でOSX10.8以上で動作する。しかしこのサーバは10.6なのだ。

探したらOSX10.6 で動作するバージョン2.5.3 というのがあった(ここにも置いた)。

こいつをインストールして毎朝3時にTimeMachineを動作させることにした。これで、2つのバックアップ・アプリがぶつかることはないだろう。

このTimeMachineEitorはオリジナルのTimeMachineを停止しておかないとまずい。さらにスリープ状態になっていても困るので、スリープしないと省エネルギーで設定するか、あるいは動作開始直前にスリープ解除するようにしないとまずいだろ。サーバだからスリープしないという設定になっているからこの点は問題ない。

1時間毎にTimeMachineが動作して処理速度が遅くなってはたまらないしね。朝3時だったら、メールが送られてくることくらいしかないだろう。

そろそろサーバ機も更新だな。5年たっているな。

[ 追記 ] 2015.8.25

23日〜25日の3回のTimeMachineによるバックアップは1時間13分、45分、1時間とものすごく遅い。一方、CCCによるバックアップは23日エラー、24日エラー、25日成功17分という結果だ。24日にエラーが出ていたので、24日にアクセス権の修復を行い、その後動作確認したので、25日は成功したようだ。CCCは順調に行けば20分以下、一方、TimeMachineは1時間近く。あまりにも遅すぎる。なにがおかしいんだろ?

mailman リストの登録アドレス一覧をテキストで

メーリングリストに登録してあるメールアドレスを、ともかくテキストとして得る方法。
このMacではmailman は /usr/local/ にインストールしたので
su になって
sh-3.2# pwd で
/usr/local/mailman/bin にいることを確認して

sh-3.2# ./list_members [メーリングリスト名]  とすれば
abca@example.com
hogehoge@sample.co.jp
pqrsta@univ.hoge.ac.jp
…..
…..
xyz@hoge.ne.jp
sh-3.2#
と出力されて来るからコピペで写す事ができる。ただし A とか B になっていて配信停止などの情報はなく、リストにあれば全て出力されてしまう。

phpソースコードが表示され….情けない…..とほほ 

日曜日、このブログの表示がphp のコードを表示するようになってしまったのに気がついた。二日酔いだし、眠いし、という本来の怠惰な生活を日曜日には実施したいので、うーんとか言ってなんもしなかった。

んで、月曜日、こっちの大学にきて、サーバもこっちの大学にあるので、本格的なトラブルだったら、月曜日中に処理しないといけないな、と面倒だなと思いつつ、解決を試みたわけだ。症状はブログを含めWebMailやownCloud  がだめ、つまりapache がphpを動かしてくれていないということだ。

ネットには、原因となるような現象とその解決方法が必ずあるので検索した。

「php ソースコードが表示されてしまう」で検索だ。なんとGoogleでは4番目にこのブログの記事があるじゃん。上位3つのうち1つは、我がブログを含めたリンク集だから実質3番目だ。

我がブログであるリンクをclickしても当然読めない。動かないブログだからな。最も参考になる記事なのに読めないわけだ。ありがたいことにGoogle様はキャッシュに保存しておいてくれて、そのキャッシュを読んで直した。

/Library/Server/Web/Config/apache2 の httpd_server_app.conf の 111行目が

#LoadModule php5_module libexec/apache2/libphp5.so

とコメントアウトされているので、この# を削除して、この行の記述=moduleを有効にすればいいのだ。

このブログ記事の最後に「トラブル解決方法をブログに書いたらブログが動かない時読めないから役立たずだ。紙ベースの記録を残せ。」と書いてある。

はい、おっしゃる通りです。2013年7月31日の記事だから2年弱前だ。記憶力がどんどん失われている。

情けない。トホホです。

WordPress 4.1.1へのアップデート

WordPress 4.1.1 が利用可能です ! 更新してください。
というわけだが、2台のサーバで何故か更新できない。同じサーバの英語バージョンのWordpressは更新できた。
これまで問題なくできていたわけで、今度の日本語のバージョンだけが自動的にできないのだ。どうしたもんかな。
手動はめんどうだし….

Postfix の main.cf はどこに?

Mac OSX Server はいろいろな設定ファイルがオリジナルから変更されて別のdirectoryにあるんだよね。本来の設定ファイルはそのまま残っているからまた分かりにくいいのさ。

Postfix のmain.cf は、普通は /etc/postfix にあるんだけど、そして現にあるのだけど、これは使われないのだ。

Mountain Lion 10.8.5 の場合 /Library/Server/Mail/Config/postfix にあるmain.cf がアクティブな設定ファイルだ。

GUIで設定した結果は、このmain.cf の最後の方に書かれている。
メールリレーサーバーをFQDNで指定するときは
relayhost = [mail.example.com] と[  ] で囲んでFQDNを記入する。maruko2の情報だ
ip address で指定するときもつけるのかな?。つけてないけどMXレコードを参照に行ってない。

GUIでの設定だが、Server → メール → ISPを経由して送信メールをリレー → 編集 → 送信メールのリレー の欄で FQDN を [ ] 付きで入力しようとすると、[ ] が入力できない。だからmain.cf の方で書き換えないといけない。面倒だから、そしてリレーを依頼しているサーバのip address は変わらないと思うので(規模が大きくなってきたのでip address を変更すると丸1日くらい使えなくなっちゃう)このままip address で設定しておいてかまわない。

しかしFQDNを使うべきなので main.cf で relayhost = [mail.example.com] と書き換えた。
GUIでの設定画面に[mail.example.com]と [ ] 付きで表示されている。

cf.
Google を使うときは  relayhost = [smtp.gmail.com]:587 らしい。ポートを指定するときはコロンをつけて指定だ。

メールリレーサーバーの設定

メーリスの遅延で書いたようにメールの遅延がなぜか発生したわけだ。その理由を調べるためあちこちに聞いた結果、どうやら本来の中継サーバではないサーバが中継していたのが理由だ。

メールサーバで中継サーバをFQDN(Fully Qualified Domain Name)で指定していたのだが、なぜかこの中継サーバがバージョンアップを繰り返しているうちにメールをリレーしてくれなくなってしまったのだ。その代わりなぜかDNSのMXレコードを引きにいき、その結果に従って別のサーバに転送してしまったようだ。これを防ぐために中継サーバをip addressで指定することにしたら解決した。この別のサーバは中継を本来の業務としているわけではないのだ。だから本来の仕事をしていたので遅延してしまったようだ。本来の仕事とは受信メールのゲートウエイのようだ。なぜ遅延したのかはわからない。エラーが頻発していたらしい。ともかくメールを中継してくれていたので、いつから中継するようになったのかはもはやわからない。メールが届いているから問題にしなかったわけで。

サーバを更新するとこういうことが発生するんだよね。一部書き換えた設定がもはや使えなくなったりするのさ。

メーリングリストが動かない…

突然メーリングリストが動かなくなった。

25日(火)17:43の投稿は動作した。

26日(水)18:04の投稿は配信されていない。

この24時間に何が発生したんだろ?mailman のトラブルかと思ったが、違っていた。

上流のDNSサーバでもあるサーバを26日午前2時からアップデートするという連絡を受けていたことを思い出した、というか思い出すのに時間がかかったのだ。

26日午前0時ころのメールはメールサーバに届いている。それ以降のメールがメールサーバにとどいていないのだ。このメールサーバはメーリングリストが主な役割なので、メーリングリストしか見てないので、mailman の設定フィアルがこわれたのかな?という先入観の下にいろいろ調べてしまったのだ。その結果mailmanはきちんと動作していることがわかり、このサーバにメールが届いていないから配信されないということがわかったのだ。

ここまで分かるのにエライ時間がかかった。問題のサーバをSMTPサーバに指定すればメールはこのサーバにあるメールアカウントに届くが、他のサーバをSMTPに指定した場合このサーバにあるアカウントにメールが届かないのだ。このことに気づくのに時間がかかりすぎた。つまりサーバはなんともないがサーバにメールがこないのだ。

原因は上流にあるファイヤーウオールか?と思ったが、何も変更していない。再起動したが変化はない。

多分このサーバを登録しているサーバのMXレコードが消えちゃったんだ。まだ管理者さんに連絡した段階で返事がないからわからない。この推定が正しければいいのだが。

きたきた、これまでテストで送ったメールがどっと来たぞ。上流のDNSサーバ管理者さんが設定したんだ。きっと。

まだ管理者さんから連絡がないが、設定したんだろ。メーリスも動く。問題なくなった。

管理者さんからメールが来た。アップデートしたとき、メール転送の記述が昔のまま(当然だが)で、今度はキチンと記述しないといけなくなったのが原因だったようだ。

従来は
example.com:[123.123.123.123]
でよかったのが
example.com smtp:[123.123.123.123]
ときちんと明示する必要になったんだそうな。

実は、この上流のDNSサーバは、もうやめようということになっていて、DNSは大学中央のサーバを指定することになっているのだ。でも、いっぺんにDNS機能を削除すると、連絡はしたのだが、まだDNSサーバに指定しているユーザがかなりいるので、まだ動かしているのだ。これらを決めたのは、何を言おうかこのワタクシなのだ。どじだなぁ。大学にメールサーバとして新たに届けて大学のDNSにMXレコードを登録してもらえばいいのだ。この上流のサーバは昔はワタクシも管理者だったのでここに登録するのが一番簡単なので登録していたのだ。今はこのサーバの管理を他のヒト(業者)にまかせているのでワタクシはDNSやMXレコードの変更はできないのだ。自業自得というもんだ。

証明書の有効期限が切れました

Mac OS X srever でサーバ example.com の以下の証明書の有効期限が切れました: 名前:APSP:4e…..20 有効期限:August 21, 2014 10:12:20 AM GMT+09:00

というメールが毎日きて、というか期限切れの前からだけど、問題は特にないんだけど、煩わしいので削除した。。renew するのが正しいんだろうけど、また自動的にできるだろうからいいや という でたらめな サーバ管理者なのだ。

1)ユーティリティからキーチェーンアクセスを起動する。
2)メニューの表示から「有効期限の切れた証明書を表示する」を選ぶ
3)キーチェーンのペインから「システム」を選択
4)期限切れ(赤い☓がついている)の証明書を選び
20140925expire_certification
5)メニューの編集から削除を選択

これでいいかな? ま、だめならメールが来るだろ。
 

 

OSX 10.9 Mavericks用リカバリー用USBメモリーを作る

OSX 10.9 Mavericks用リカバリー用USBメモリーを作ることにした。Mavericksはネットから落としてインストールするだけで、例えばディスクユーティリティでこれまでの起動HDDを修理するなんてことができないからね。

1)ディスク・ユーティリティーでUSBメモリーをMac OS拡張(ジャーナリング)でフォーマットする。

2)OS X 復元ディスクアシスタント をダウンロードする。

RecoveryDiskAssistant.dmg でこれを解凍すると、復旧ディスクアシスタント.app となる

20140918RecoveryOSX-1

起動して、USBメモリーが表示されたら選択して続ければ、おしまい。

 20140918RecoveryOSX-2

3)起動時に Option キーを押し続けていると、起動ディスク選択画面になるから、このUSBを選択して起動すればいい。

TimeMachineからの復旧、OSX再インストール、ディスクユーティリティが使える。

同じOSXでも異なるMacでは使えない。それぞれで作成する必要があるようだ。ちがうかな?

S.M.A.R.T. 状況エラー

仕事で使っているMac OSX10.9.4 の内臓のHDD(Hard Disk Drive)の一つが、「S.M.A.R.T. 状況エラー」とメッセージを出して、お亡くなりなったようだ。

S.M.A.R.T. とはSelf-Monitoring, Analysis and Reporting TechnologyのことでHDDに内蔵された機能らしい。要するにHDDを検査すると幾つかの項目二エラーがありますよというレポートをHDDが発しているということだ。エラーによっては記録されたデータをコピペできるから、試みなさいということだ。

HDDそのものより記録されているデータのほうが高価(使用者にとって、他のひとにはゴミだが)で、このようなメッセージがいずれ出るのが当然なのでバックアップを自動的にとっておくのが当たり前なのだ。今回はゴミデータしか残ってない HDDだったはず。

昔はHDDが高価だったので、なんとか回復させる努力をしたのだが、最近はそのような努力は無駄で新規のHDDにするのが一番良い。でも記録を回復したいとなるとかなりの出費となる。

今回のトラブルは、マウントしているんだけど中身をほかにコピペできない状況だ。捨てる。データも捨てる。何を記録していたかと思ったらPrevious Mac となっていたので、現在のMachineの前のMachineのデータなので3年以上前の記録だ。必要なデータは別途保存されてるはずだ。捨てる。過去に未練はないのだ。

証明書をいじったら

とほほ。サーバの証明書なんか購入していない。自己証明だけだ。1年間有効だ。

で期限がきたので、いい加減に削除したり更新したりしているうちにおかしくなってしまった。

Server Fallback SSL Certificateを削除していまったようで、再構築できない。メールソフトからの POP, IMAPアクセスに失敗するのだ。なんとか平文パスワードと暗号化なしにして受け取れることまで戻した。

なぜか、今度は〜(チルダ)無しでWebページにアクセス可能にした設定がうまくいかず、〜無しでもいいブログと〜がないと接続できないブログができてしまった。シンボリック・リンクは別にこわれていないようなのだが。

直さないと。どこがおかしいのかまだわかっていない。

[ 追記 ] 6月30日

証明書を新規に作成し、その利用範囲を web .. メール..とすべてに対応させることができるようになった。それまではうまく行かないところがあったのだが、何故か時間が経過したらできるようになった。

〜も問題なくなったようだ。

 

wordpress の更新

WordPress はFTPの設定さえできていれば、マニュアルで新しいバージョンをダウンロードせず、勝手にやってくれる。しかし、上書きするファイルのパーミッションがうまく設定されていないと、書き換えることができない。

正しいかどうかわからないけど、ssh で入ってパーミッションを変えたら、アップデートできた。

sh-3.2# chmod -R 777 wp-content
sh-3.2# chmod 777 update-core.php
sh-3.2# chmod 777 license.txt
sh-3.2# chmod 777 readme.html
sh-3.2# chmod 777 wp-activate.php
sh-3.2# chmod 777 about.php
sh-3.2# chmod -R 755 wp-admin
sh-3.2# chmod 777 wp-comments-post.php
sh-3.2# chmod 777 wp-config-sample.php
sh-3.2# chmod -R 777 wp-includes
sh-3.2# chmod 777 wp-login.php

sh-3.2# chmod -R 755 wp-content
sh-3.2# chmod -R 755 wp-includes
sh-3.2# chmod -R 755 wp-admin

これでいいのかしらん?