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 Server」カテゴリーアーカイブ
Mountain LionサーバのEl capitanへ更新ー未完
Macでサーバを構築しているのだが、自宅の方のサーバがこの夏調子悪かった。OSX 10.8.6 Mountain Lionでサーバ管理.appは10.6.5 なわけで、現在の最新がOSX 10.11 El capitanなので３世代前なのだ。調子悪いし、遅いから…そろそろ新しい機器に更新かな、と思ったわけだ。んでEl capitanのダウンロード開始前のYosemiteのMac Mini を購入しちゃったわけだ。
結局、不調の原因はHDDが壊れたからで、一気に壊れてくれればいいのに、うじうじ壊れて行ったので、解決に時間がかかってしまった。
んで、現在のサーバをOSX 10.11 El capitan、OSXServer5.0 にするのだ。その方法としては
（１）新しいMac Mini のSDDに現在のサーバのTimeMachinで バックアップした外付けHDDからTimeMachineで復元する。つまり新しいMac Mini を古いOSで動かすわけだ。その後El Capitanなどにアップデートしていく。これが一番楽なのでは？
（２）新しいMacMiniをOSX 10.11 El capitan、OSXServer5.0にして、TimeMachinで バックアップした外付けHDDから移行アシスタント.app で吸い上げる。
（３）現在のMacMini をOSX 10.11 El capitan、OSXServer5.04にアップデートして、これをTimeMachine でバックアップし、このTimeMachine で記録したHDDを使って、TimeMachine で新しいMacMini のSDDに復元する。
（１）はだめだった。TimeMachineで新しいMacMiniのSSDに復元しようとしたら、適応できないと拒否された。
（２）はデータはともかく移動することができそうだが、これをシコシコ再設定しないといけない。Mailman とかWordpress のデータベースの再設定はうまくいくのだろうか？試しに移行アシスタント.appを動かしたら、ユーザが一杯できた。そりゃそうだな、adminとかmailman とか一杯あるからな。これじゃ面倒だな。全てを新しく設定し直すのと大差ない。
（３）は、現在のMacMiniが最新のバージョンにアップデートできるかどうかが問題だ。調べたら、現在のMacMiniは2010年３月に購入している。注文書のメールに記載してある製品番号がMC408J/AだからLate 2009 ということになる。 OSX 10.11 El capitanはMac Mini の場合 Early 2009以降だったらインストールできるようだ。だからできる可能性が高い。
OSXServer5.04はOSX10.10.5 Yosemite 以降ならOKだ。いまさらOSXServer 4 は手に入らないし。多分El Capitan に上げることができたら、その後インストールできるだろ。だから、次回のトライは（３）だ。
（３）の手順は
１）現行のMachineを起動できるUSBメモリーにEl capitanインストーラをコピーして、このUSBメモリーから起動できること・ユーティリティが使えることを確認する。TimeMachine で復元するのに必要だ。
２）ネットから切り離し、現行のMacMiniのバックアップをTimeMacine とCarbonCopyCloner でそれぞれ別HDDにバックアップしてから始めないと連続性が保たれない。失敗したら復元できないと最悪な結果になるからな。
３）そんで、El capitan OSXServer5.04 にアップして、ネットに接続するが、localだけでテスト*1)して、うまくいくことを確認する。だめだったら、潔く２）で作成したTimeMachieHDDから復元して、もとに戻して再考する。
４）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が２台あるのだ。
有料になって、最新バージョンを購入したとき（去年の１０月だ）、端末のMacでアンインストールに失敗したのか、新しいのがインストールできない状況のまま放置しちゃったのだ。
最初のアンインストールを間違えたようなので、アンインストール方法のページにしたがって、フアイルを捨てたんだけど、新規インストールできないのね。よくわからないので放置していたのだ。
１年も立っちゃって、改めて、先週末に、開発元にHelp me メールを、Webページ経由で出したら、きちんと返信されてきた。開発元が英語圏なので、返事は英語と自動翻訳した日本語だ。Web サイトが日本語表示だったので、日本語で問い合わせたから、向こうも自動翻訳で英語にして解釈して返信してきたのだろう。自動翻訳の日本語は何をいっているかよくわからん。
私はあなたが持っているもののトラブルわからないんだけど、それはあなたがCCCをアンインストールしようとしたように聞こえる、と今あなたがCCCを開くことができません。次のことをお試しください：
最初の返信メールは、トラブルの状況の確認だった。多分、自動翻訳では不十分だったんだろうね。「起動すると、開けません。」というがトラブルだ。
やっぱし、画面でみるのが早いのだろう。画面のコピーを添えろと指示されたので、この画面のハードコピーと英語と日本語の説明を付けた。
つぎのメールは、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.
なので、英語のほうがわかりやすい。
３回目のメールで「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 を入る 出る 両方にチェックを付けるといいと思うけど、いいのかな。
いいはず。
この動的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)番ポートでデータの送受信を行いますよとパッシブモードでトライしたんだけど、接続できなく、ポートモードで接続したら成功したということのようだ。この場合サーバのポートは２０番である。つまりパッシブモードで接続できない、自動的にアクティブ（ポート）モードになってデータの送受はできるようになる。
入 にチェックが入っていると；
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となったわけだ。
アクティブ（ポートモード）からパッシブモードに自動的に変化してだめならアクティブモードにもどりデータのやり取りを行うらしい。この間の時間が無駄だからパッシブでできるようにしておくのがいい。
アクセス元のファイヤーウオールでポート２０を閉じているとアクティブモードが通らないから、アクセス先のサーバのファイヤーウオールはパッシブモードが通るようにしておいたほうがいい。
この解釈でいいのかしらん？
アクティブFTPとパッシブFTPというサイトが参考になった。
なんでこんな昔からのFTPのよくあるトラブルになったのかというと、職場のファイヤーウオール機がこの連休に交換されたわけだ。それ以来FTPが使えなくなってしまった。つまり、交換以前はポート２０番が開いていたのだ。ひょっとして、管理者がここに赴任したときFTPを使うために２０番を開けろと依頼したのではないだろうか。憶えていない。PASVモードだと途中にNAT変換などがあるとうまくいか無いことが多い。クライアント側もサーバ側もNAT変換をやっているわけで、うまくいなかのでアクティブモードでやるのが一番楽だったのだ。で、ファイヤーウオールが交換されて２０番が塞がっちゃって、PASVでないとできなくなったのだ。でサーバ側のファイヤーウオールでFTPは動的フィルタで対応したらできるようになったのだと思う。しかし、FTPが通らないという管理者のクレームに対して、こっちのネットの管理者は委託業者に何か依頼してファイヤーウオールの設定を変えたらしいのだが、なにを変えたのかはわからない。
証明書の有効期限がまもなく切れます
MacOSXサーバだ。
「証明書の有効期限がまもなく切れます – mike.md.tsukuba.ac.jp コード署名証明書」てのが。期限切れ１ヶ月前から毎日朝８時に来る。
更新するのは面倒なので、「プロファイルマネージャで新しい証明書を使う」にしたけどいいのかな？
[ 追伸 ] ９月２９日
だめだった。
[ 追伸 ] １０月１日
コード証明書というのを見たら、どうやら、もう１台の一時的なサーバに関する証明書のようなので、キーチェーンからその証明書を削除した。どうなるだろ。自身で作った自分自身の証明書ではないし、捨ててもsshやメールは問題ないからな。この一時的なサーバは存在しないしね。
証明書を削除したんだから、警告メールは来なくなった。当然だな。いつこの証明書を作って、どうして維持してきたのかよくわからない・覚えていない。ひどいもんだ。
CarbonCopyClonerのトラブル
CarbonCopyCloner（CCC）をつかっているわけだが、大学オフィスのMac では最新版に変更しようとして、なにか間違えたアンインストールをおこなったのか、最新版をインストールできなくなってしまった。
１台のサーバにインストールしたやつは、バックアップ終了後、メールで連絡するように設定したのだが、不安定なのだ。
成功したとき
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)
昨日の８日は成功しているのに、そして何も変更していないのに今日９日は失敗なのだ。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交換でトラブルは解消した。
サーバの引っ越し
このサーバが設置してある建物の耐震工事が始まるので、研究室等は一時避難場所に引っ越しになるのだ。研究室の引越し先は遠いので、そこにこのサーバを持っていくのはちとしんどい。耐震工事が既に終了した続きの建物の一室へ居候することにした。
今朝がその引越である。同じフロアの２０ｍ位しか離れていない場所なので、３０分もあれば終わると踏んでいたわけだ。移転先にLANケーブルは用意したし、電源も確保した。だから、UPS、サーバ本体、ファイヤーウオール、モニタだけ移動するのだ。一人で３０分で終わる。UPSが重いけどなんとかなる。というわけで朝７時に始めた。予定通り、移動して、サーバを起動した。
んが、動いているように見えない。モニタに何も出てこない。順調に動いている機器を移動させる、ケーブルを差し替えて再起動する、などを行うと、隠されていたトラブルが出てくることがよくあるのだ。弱った。モニターになにも出てこないとどうしようもない。外からログインもできない。なんじゃ？？？
このサーバ機にはLANポートが２つある。どっちを使っていたかマークしていない。管理者がいい加減だからだ。モニタに出てくれば、すぐどっちのポートだったかわかるわけだが、それができない。多分接続ポートが違うんだろということで、ポートを変えたら、外からログインできた。サーバ機能も問題なさそうだ。というわけで問題はモニタだけだ。ビデオカードがこわれたとは考えにくい。
あとからみたら管理者宛のメールにip addressが変わったという警告メールがきていた。７時３分に間違ったip address、７時３０分に正しいip addressに変更になったというメールが発信されていた。つまり移動して誤ったポートにLANケーブルさして起動したのが７時３分。おたおたして、正しいポートにつなぎ変えて再起動したのが７時３０分というわけだ。３０分余計にかかってしまったわけだ。
モニタを交換してみたが、同じだ。シグナルが来ていないということだ。どうやら問題なく動いているので、コネクタの接触不良だろ。しっかり挿して、ネジを回して固定したら見えるようになった。
というわけで、移動してもなにも問題はなかったわけだ。１時間つぶれてしまった。朝、早いからユーザはまだ寝ているにちがいないから、ユーザに連絡することもしなかった。３０分とちょっと止まっていたけど、多分わからなかっただろ。そもそも、この８月末から、本幹のネットワークのスイッチの更新がおこなわれていて、２０分位とぎれることがあったのだが、誰も何も行ってこないからな。ヘビーユーザは管理者だけだし。
TimeMachine が遅い件
TimeMachine が遅いのは
１）アンチウイルスソフトがうごいているから
２）Spotlight の検索範囲が大きいから
ということのようで、１）はサーバ機で、定時にアンチウイルスソフトを止めてからTimeMachineを動かすなど不可能じゃないけど面倒なので、まず２）をデフォルトから変更してみた。
TimeMachineEditor で一日午前３時だけバックアップするように設定してある。Spotlightの変更前の本日の朝３時からのバックアップは；
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.
というわけで１時間かかっている。
Spotlightの検索範囲は、デフォルトではすべてにチェックがついているけど。これを
と、３つだけにした。さらに、バックアップHDDは検索範囲外とした。
どうなるだろ。10.7 ではTimeMachineの宛先HDDをここで指定しては行けないという記事がある。
HDDのアクアス権修復、CCCのバックアップ先HDDの修復とアクセセス権の修復、TimeMachineのHDDの修復とアクセセス権の修復を実施した。
これで今晩はどうなるか、明日早朝チェックしてみる。
[ 追記 ] 次のバックアップは２０分に縮小した。Spotlight検索範囲を減らすというのは効果があった。２０分だったら、ま、いっか。次の日は１８分だった。
サーバ機なので、ファイルの検索なんかやらないということで、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サーバがこけた
自宅サーバがこけた。原因は不明。リモートログインできないから、なんともしがたく、２１日（金）日に帰宅して再起動してなんとか動くことになったのだが、ものすごく遅い。
今朝、DVDから起動して、とりあえず、アクセス権の修復とデイスクの修理だけを実施したら早くなったのでこのままにしておく。
今晩、バックアップが実施されるからそのバックアップがすぐに終わるようだったら、このままにする。
CarbonCopyCloner（CCC）のバックアップは通常十数分で終わるのに、１７日〜１９日は２５分以上もかかっている。２０日、２１日は失敗。
今晩、２０分以内だったら修理は終了したとする。
どうやらもういっちょのバックアップアプリTimeMachineのせいのようだ。TimeMachineがバックアップ動作を行うと、著しく処理が遅くなる。これはデフォルトの設定で１時間毎に行うことになっていて、その間隔を変更することはできない。
CCCは夜中の１時に実施しているわけだが、TimeMachineの実施時刻とたまたまぶつかってしまったのではないだろうか。TimeMachineの１時間毎というのは、開始時刻が１時間毎なんだろうか、それとも終了してから１時間後なんだろうか。後者のような気がする。最新のバックアップの時刻と次のバックアアップ時刻はちょうど１時間ではない。だいたい１時間でだんだんずれていくのではないだろうか。だとすると２つのバックアップが同時に動作開始になって、おかしくなってしまったことが考えられる。
TimeMachine の動作間隔は自由に設定できないので、これを変更できるアプリが必要だ。
TimeMachineEitor というのがある。現在のバージョンは4.2.1でOSX10.8以上で動作する。しかしこのサーバは10.6なのだ。
探したらOSX10.6 で動作するバージョン2.5.3 というのがあった（ここにも置いた）。[wpdm_package id=’6581′]
こいつをインストールして毎朝３時にTimeMachineを動作させることにした。これで、２つのバックアップ・アプリがぶつかることはないだろう。
このTimeMachineEitorはオリジナルのTimeMachineを停止しておかないとまずい。さらにスリープ状態になっていても困るので、スリープしないと省エネルギーで設定するか、あるいは動作開始直前にスリープ解除するようにしないとまずいだろ。サーバだからスリープしないという設定になっているからこの点は問題ない。
１時間毎にTimeMachineが動作して処理速度が遅くなってはたまらないしね。朝３時だったら、メールが送られてくることくらいしかないだろう。
そろそろサーバ機も更新だな。５年たっているな。
[ 追記 ] 2015.8.25
２３日〜２５日の３回のTimeMachineによるバックアップは１時間１３分、４５分、１時間とものすごく遅い。一方、CCCによるバックアップは２３日エラー、２４日エラー、２５日成功１７分という結果だ。２４日にエラーが出ていたので、２４日にアクセス権の修復を行い、その後動作確認したので、２５日は成功したようだ。CCCは順調に行けば２０分以下、一方、TimeMachineは１時間近く。あまりにも遅すぎる。なにがおかしいんだろ？
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 になっていて配信停止などの情報はなく、リストにあれば全て出力されてしまう。