システムの設定

引き続きメールのエラーをチェックしているが、エラーがなくならない。

No record for user

参考

https://discussions.apple.com/thread/6382555?tstart=0

server.app ではないところの設定が重要。

ユーザがいるのに、見つけられていないということは、探す場所が間違っているということ、自分自身に問い合わせることも設定するというこかな。

server.app の変な場所に「127.0.0.1」を設定して大混乱を起こしてしまった。

メールサーバのエラーを注視

ある人より、エラーでメールが送れなかった。時間を置いて2度ダメだったとご指摘を受ける。エラーの内容は教えていただける間柄ではない。自分のメールサーバのことなのだし、ログなどから何とかするべき。

メールサーバのエラーログをチェックするも出現ポイントがわからない。大量のエラーログが記録されていることが、既に問題。

エラーを再現するために

  1. thunderbird の send later (後で送る:Mac)で10分間隔でメールを送信
  2. 送信元は別サーバ、受信側が自分のサーバ
  3. 1日目は起動中のウインドウズで、再現できず
  4. 24時間で監視できるようにサーバにメールクライアントソフトをインストール。
  5. 2日目にエラー出現 3回送信できずにいる
  6. エラーの時刻をたよりにエラーログを確認して、同じ3回のエラーを確認
  7. その直前のエラーから、心当たりのある設定を、変更してみる
  8. エラーが再度出現
  9. あらためて、別の設定にして見る。
  10. 今のところ、エラーは出ていない。(エラーログも激減)

エラーログに記録が多いのは、アカウントへの外国からのアタックもあるためと決めつけて、細かく見ていなかったのがいけなかった。

 

8月8日

無計画に進めるから困ることになるのに何度でも繰り返しちゃうんだ。

  1. 液晶モニターをコントロールするAPPを見つける。
  2. sierra で動くと書いてある。
  3. sierra にアップグレード
  4. server もアップデート
  5. Apache のログがまっさらになっている!(またやった!)
  6. 先週オーダーしたSSL証明書が届くも、秘密鍵が合わないと警告が出る
  7. それでも進めてみたら server webサイトが真っ白(なぜ!)
  8. サイトへはアクセスできるので、早朝の再設定を覚悟
  9. 証明書を再発行してもらおうと作業を始めると
  10. server webサイト 復活してる!(ほっ)
  11. さっきのエラーの出た証明書を削除
  12. SSL証明書再発行
  13. ウェブサイト 設定 (スムーズ)
  14. 結局、モニターをコントロール APP は動かず。(メーカーサイトは正しかった)

アップルのサポートに連絡しても、こういった流れは再現できないだろう。
タイムマシンくらいは用意しとかないとダメかな。
1日1回のフルバックアップはしてるんだけど。

Error establishing a database connection

MySQL のログを見る。

Your password has expired. To log in you must change it using a client that supports expired passwords.
あなたのパスワードは期限切れです。 ログインするには、期限切れのパスワードをサポートするクライアントを使用してログインする必要があります。

あれれ。

phpMyAdmin からパスワードを変更。

その他、変数 で確認すると「360」に戻っている?先回ちゃんと編集できていなかった模様。

default password lifetime = 0

どこかで、この方法では設定できないって読んだことがあるような。。。

www ありなし

www.***.jp と ***.jp は同じサイトである場合が多い。
レンタルサーバでは、ほぼ同じに設定することを想定して組まれている。
SSL の証明書も、www のサブドメインで証明書を取得すると、www なしでも使えるものがある。

そんな www ありなしで、わけて構築していたサイトをまとめ直したときにあまりに簡単にできたので、少しうれしかった。

  1. フォルダを移動
  2. webサイトのドメインを設定し直す

これだけだった。条件はあるけれど、手元でこれだけ。

MySQL設定 default password lifetime パスワードの有効期限を無期限にする。

phpmyadmin 4.5.3 の様子

phpmyadmin 4.5.3説明リンクがまだない。

phpmyadmin 4.7.1 の様子

phpmyadmin 4.7.1説明のリンクがある。

変更結果

 「0」に設定して無期限に。

昨年5月にインストールした MySQL は既に「0」になっていた。いつ設定したのか覚えがない。説明リンクをよく見れば、デフォルト値が変わってる。

バージョンによっては、昨年の日付でパスワードの期限切れを迎えていていいはずのところだった。(汗)

アクセス制限

Basic認証だとエラーログが大量に出るので、server の機能を試してみた。

設定の様子

結果

設定しても、すぐには反映されない。「webサイト」の再起動が必要。
フォルダのアクセス制限でもサービスの再起動が必要。

MySQL パスワード有効期限が過ぎた

朝、サイトを閲覧できないことに気付く。

2日後に予定していたパスワード再設定が原因とすぐに気づいたが、root 管理者が有効期限切れ。対処方法を調べたが、自分が行える方法が見つからない。

強引だけど、サーバの時間を1日前に設定

root でログインできた、同時にパスワードを変更。

サーバの時計を戻して、再ログイン。各サイトのデータベースユーザのパスワードも変更。

とりあえず、サイトの閲覧が可能になった。

 

Server ヘルプを読んでみた。

https://help.apple.com/serverapp/mac/5.2/#/

何も知らずに、ヘルプを読んでも、設定できないんじゃないかな。できるのかな。

  • LAN内でのグループ利用
  • ホスティング(webサーバ・メールのサービスなど)
  • 開発
  • MAC OSX、iOS ユーザのサポート(バックアップ、カレンダーなど)

それぞれの利用シーンでストレートな解説の方がユーザを増やしやすいように思うんだけど、そんな考え方が日本人的なんだろうな。
RPGでも日本人の考えるシナリオは一直線でゴール。海外のRPGは雲の中を通ってゴール。というような解釈を小ネタ集のホームページで見た。

自分は、どちらかというと、これをしたらどうなる?みたいな迷い歩きをしてしまうから、スポーツでも仕事でも、他の人からは、「何やってるの?」ってなっちゃうんだけどなあ。
そして、同じことを何度もするのは、耐えられない。

Apple からの通知。この案内をユーザに通知するのは難しいかな。

20161204a

The following Apple Push Notification Service certificates, created for AppleID ****  will expire on January 02, 2017. Revoking or allowing this certificate to expire will require existing devices to be re-enrolled with a new push certificate. You can renew your certificates with your OS X server administration tools.

AppleID ****用に作成された以下のApple Push Notification Service証明書は、2017年1月2日に有効期限が切れます。この証明書を失効または期限切れにするには、既存のデバイスを新しいプッシュ証明書で再登録する必要があります。 OS Xサーバ管理ツールを使用して証明書を更新することができます。

20161204b

サーバ、メール 「通知をプッシュ」

20161204c

The following Apple Push Notification Service certificates have been created for AppleID ****** and will expire on December 03, 2017.

以下のApple Push Notification Service証明書がAppleID ******用に作成され、2017年12月3日に有効期限が切れます。

この操作をして、証明書の有効期限を延長したところ、メールアカウントで、
暗号化通信をしていると、メールアカウント作成時と同じように、「承認」するかどうかを問われるポップアップが出る。
これをユーザに前もって、通知してからでないと、有効期限を延長できないかな。
うーん。スケジュールするのが面倒だな。

ランダムな英数字でアカウントを表示されてもわかりません。→解決

server の通知に出てくるのだけれども。

Unassigned mail account scheduled for deletion in 30 days

An unassigned mail directory has been detected and is scheduled to be deleted.

The unassigned mail directory located in:
/Library/Server/Mail/Data/mail/*****
is not associated with any user account and is scheduled to be deleted in 30 days.

****** はランダムな英数字。削除した過去のアカウントなのか、現在のアカウントなのか、わからない。

11/12 追記

server ユーザ より、カギマークから、「ユーザを書き出す」すると、文字列とIDの関係がわかる。今回は、書き出されたユーザにはないので、以前に削除したユーザのフォルダのようだ。

Sierra server 5.2 DNS 逆引き

また、忘れていた。

てっきり、GUI 設定でOK と思いこんで、何度も設定と見直しを繰り返していた。
ほかの、サーバで、メールの設定項目がないのに、逆引きの情報に、メールの情報があったりして、確実に設定ファイルをいじっているはずになのにぃ。

逆引き情報が特有の指定方法だけど、それが入力できるようになっただけでもましか。

mysqld.local.err 外部からのアクセスを遮断、エラーが記録されなくなる。

server のアクセスの項目にて、カスタムで、MySQL のポートを追加したら、エラーが記録されなくなった。

20161108

WordPress の設定では localhost なのだから、外部からの通信を許可しなくてもOK。
ブラウザのポートは別で、同じローカルにある php が MySQL のデータを使っているだけ。

MySQL データベースだって、ローカルのみの設定。それでも、MySQL 自体は、外部からの通信にこたえられないエラーを記録し続けていたということ。攻撃なのね。7メガも溜まってた。

ユーザの追加

20161103a

server で新規ユーザを追加するときに、デイレクトリの選択項目がある。デフォルトは「ローカル・ネットワーク・ディレクトリ」。
で、「ローカルデイレクトリ」を選択してユーザを追加すると、

20161103b

環境設定の「ユーザとグループ」に表示されるようになり、ログイン画面にも表示されるようになる。

通常は、デフォルトの「ローカル・ネットワーク・ディレクトリ」で。

ユーザ、メールアカウントへの攻撃回避になるか?

レンタルサーバのメールアカウントに不正アクセスされる事案があって、サーバサービスにて強制的にパスワードを変更された。(2度目)

メールサーバには、サーバのアカウント(メールサービス ON)とメールアドレスで接続が可能。

自分のサーバーならこの攻撃を回避できるかな。

20161019a

受信の流れ

  1. 送信者から、メールアドレスAAAへ送信
  2. メールサーバでは、AAAが設定されたアカウントで受信
  3. TTT が設定されたアカウントへ転送
  4. ユーザは、TTT へ接続してAAA のメールを受信

送信の流れ

  1. ユーザは、メールクライアントソフトの、送信アドレスAAAに設定
  2. 送信アカウントは、TTT に設定
  3. 普通に返信

これで、送信アカウントのメールアドレスやサーバアカウントの情報は伝わらないので、攻撃対象にはなりえない?

  • メールクライアントソフトの設定は、ハードルが高くなる。
  • メールアドレスの存在性をアカウント接続で調べる機能を利用しているサイトでは、「無効なメールアドレスです。」という警告が出る可能性がある。

 

汗った。知らないアカウントがユーザにいっぱい。

20161013a

safari のアップデートをかけ再起動された後に、server ユーザに追加した覚えのないユーザがいっぱい出現!何が起こった?

どこで、いじっていまったのか、いろいろ憶測してしまったが、寝起きのぼんやり操作で偶然発見。(いつもぼんやり操作しているから表示設定変えちゃったのかも)

20161016a

表示>「システムアカウントを隠す」 で解決。

Sierra server 5.2 にて SSL証明書インストール

新規にインストールした Sierra 、server 5.2 に SSL証明書をインストール

  1. server SSL証明書 信頼できる証明書を取得
  2. サブドメインまで含めた comon ネームのドメインで発行依頼用の csr ファイルを保存
  3. SSL 証明書を発行してもらう
    ここでは、以前発行してもらった証明書の再発行手続き。
    ホームページから依頼して、メールとブラウザのやり取りで、数分で再発行できた。
  4. server の証明書の該当ドメインをクリックして、証明書ファイルをドラッグ&ドロップ
    20161009c
    信頼できる証明書としてアイコンが青ベースになる。
  5. webサイトで、証明書を選ぶ
  6. Apache の設定ファイル確認
    /Library/Server/Web/Config/apache2/sites/****
  7. 証明書のインストール先
    /etc/certificates/***.cert.pem (証明書)
    /etc/certificates/***.chain.pem (中間証明書)
  8. 中間証明書を、キーチェーンにドロップ
  9. 判定サイトで、「B」をもらう。中間証明書に不備があるとでる。
    他のサーバでは「A-」
  10. 内容を比較すると同じなので、中間証明書を ***.chain.pem へ上書き
  11. Apache 再起動も判定変わらず行き詰まる。
  12. 1日置いて、別件で サーバーマシンを再起動。
  13. もしやと思って判定をうけたら「A-」になっていた。

後は、逆引きの設定を試して、OKならほかの server もSierra と5.2へアップグレードできるかな。

Sierra に インストールした server に Roundcube と MySQL 追加

Roundcube

  1. Roundcube_for_OS_X_Server_1.1.4.zip をインストール。
  2. サイトの詳細設定で、topickdesk-Roundcube にチェックを入れるだけ。再度感謝。
  3. ブラウザからサイトの /webmail/ にアクセス。
  4. メールサービスを有効にしているアカウントでログイン
  5. 受信、送信をテスト

MySQL

mac 用のインストーラーから、まっさらなサーバにインストールのは初めて。
今までは先にインストールしたものがあった。
ソケットでパスを通すとか、起動項目とかすっかり忘れていて、途中うろうろしたけど、手順は以下の通り。

  1. mysql-5.7.15-osx10.11-x86_64.dmg にてインストール
    20161009初期パスワードをコピーしておく。
  2. インストールの確認
    ファインダーで隠しファイルを表示する状態で目視
    /usr/local/mysql、mysql-5.7—
  3. システム環境設定から start MySQL server
    20161009b
  4. root のパスワードを変更。
    ターミナルにて
    /usr/local/mysql/bin/mysql -u root -p (自動でふられた初期パスワード)
    SET PASSWORD FOR root@localhost = PASSWORD(‘****’);
  5. ローカルサーバへパスを通す
    ターミナルにて
    sudo mkdir /var/mysql;
    sudo ln -s /tmp/mysql.sock /var/mysql/mysql.sock
  6. phpMyAdmin をwebサイトにドラッグ&ドロップ
  7. ブラウザから接続、ユーザ:root パスワード:****
  8. ログインできた。

mysql のエラーログとシステム環境設定に不安材料あり。少し様子見。

ここまでで、Apache や php の設定ファイルはいじっていない。
Sierra server 5.2 では、SSL 証明書のインストールがまだ不十分(判定B、中間証明書を認識できていない)なので、ほかの server を Sierra にアップグレードできないでいる。

Apache log

server 5.1.7 の Webサイト サービス。

  • log は2種類保存されていて、Proxy と、Proxy でないもの。これらの差分を比較したけど、ほぼ同じ(数行の違い)なので、アクセス解析には、Proxy でないものを利用している。
  • log は21メガ程度になるとアーカイブされる。
  • アーカイブは直近の10個まで。

10.6 server では1週間ごとのアーカイブで、1ギガを超えるログが記録されたこともある。これでいくと、1日に300メガのログに相当するので、1日に1回以上はログのバックアップが必要になる計算。
アクセスが多くなるシーズンに向けて準備が必要だ。