ラベル サーバー関連 の投稿を表示しています。 すべての投稿を表示
ラベル サーバー関連 の投稿を表示しています。 すべての投稿を表示

2014年2月18日火曜日

SixCoreサーバー 独自ドメインに届いたメールをスマホに転送する方法

SixCoreサーバーというレンタルサーバーを利用している環境で

独自ドメイン:example.comを運用、admin@example.comというメール

アドレスに着信したメールを

Biglobe SIM を挿したNexus5で使っている、Biglobeから付与された

メールアドレス、big@biglobe.ne.jpに転送する方法を掲載します。

SixCoreで提供されているメールシステムは、メールが到着しても

Push通知はしてくれません。

私の場合、WordPressを使ってNexus5に割り当てた

big@biglobe.ne.jp

にも発信する設定をしたのですが、このたび、サーバー上の

「メール管理ツール」上で、転送メール設定ができることを発見

しましたので、この機能を使い、サーバーに到着したメールが

来た時点で、Nexus5のメール宛に転送することで対応し

リアルにメール着信を探知できるようになりました。

以下、設定手順です。


SixCoreホームにアクセスし、メール管理ツールを呼び出します。

 

そして、転送させたい元メールアドレス・パスワードを打ち込み中に入ります。


赤丸で囲った、「転送設定」の「設定変更へ」をクリックします。


転送させたいメールアドレスを赤丸のテキストボックスに入力し、「追加する(確認)」
ボタンを押下。

登録が完了すると、赤丸の下欄「転送先メールアドレス一覧」に転送先メールアドレスが
表示されます。今回の場合は、big@biglobe.ne.jpが入ります。

以上で、転送設定は終わりです。

適当なメールアドレスから、SixCoreの独自ドメインメールアドレス宛にテストメールを
送信してみてください。

暫くすると、Nexus5のbig@biglobe.ne.jpにもメールが到着するはずです。
しかも、Push通知で。


Gmail等に転送したりしているケースもありますが、これがシンプルな気がします。

2013年8月18日日曜日

XAMPP 1.7.7 MySql 文字コードセットをUTF-8に変更する方法

文字コードの設定は重要です。

クライアントサーバ間の文字のやり取りをする場合、文字化けの虞のある場所です。

そこで、私の使っているXAMPP1.7.7のMySql設定を確認することにした。

コマンドプロンプトからMySqlにログインし、

mysql> show variables like 'char%';

を入力すると



このように、

character-set-client = cp932
character-set-conection = cp932
character-set-database = latin1
character-set-server = latin1
character-set-system = utf-8

ばらばらな文字コード設定になっていました。

そこで、この文字コードをUTF-8に統一することになりました。

変更方法は、MySqlの設定ファイル、My.iniに下記を設定することにより行います。

[mysqld]
skip-character-set-client-handshake
character-set-server = utf8
collation-server = utf8_general_ci
init-connect = SET NAMES utf8

MySql,Apacheの再起動を行い、先ほどのコマンドを入力すると変更結果が得られます。


character-set-client = utf-8
character-set-conection = utf-8
character-set-database = utf-8
character-set-server = utf-8
character-set-system = utf-8

このように、すべて、UTF-8に設定されました。

多くのブログに掲載されている、「default-character-set=utf8」を、My.iniの[mysqld][mysql][client][mysqldump]に設定する記述に応えてそのまま設定すると、MySqlが動きませんでした。

この、パラメータはxampp MySqlには使えません。


2013年8月9日金曜日

WordPress 固定ページ編集で、HTTP304発生

昨日まで編集できていたWordPressの固定ページの編集が、今日、いきなり、できなくなっています。


編集窓に変更を加えた後、更新ボタンを押すと、サーバーからアクセス拒否を表す、HTTP403

が返されてきます。

昨日、何やったかな?

1、変更をいっぱいくわえたので、WordPressのDBバックアップ、ファイルバックアップを実施。
2、レンタルサーバにある機能で、「WAFセキュリティー」設定を全部セット
  (XSS対策、SQL対策、ファイル、メール、コマンド、PHPの各対策)

この二つくらいでした。

具体的にどのような症状かというと・・・・

A.管理画面の固定ページを編集画面で特定のページは、更新ボタンを押すと、編集していても、い なくても、HTTP403が返される。

B.他のページは、編集していても、いなくても、更新ボタンを押すと更新できる。

A.について編集窓には、<iframe>タグを用いた記述をいている。
B.については、普通の文字列のみの記述をしている。

こんな感じでした。

まず、昨日行った「バックアップ」にエラーがないかログをチェックしたところ、DB,
FILE共にNORMAL ENDしていて特に問題となるようなことはありませんでした。

次にやったWAFセキュリティー設定。

これは、サーバー管理ツールのWAF設定の画面に行って、説明書きをよーく読んでみました。

-----------------------------------------------------------------
■ 検出時に動作について

検出された場合には、アクセスが拒否されエラーページが表示されます。
----------------------------------------------------------------

と書かれていました。

これって

HTTP403

のことだよね。

うんうん。

さっさとWAF設定を全部解除設定にしました。

暫くして、Aの編集は、滞りなく編集できるようになりました。(汗)

今回の場合、XSSの設定だけはずせばいいと思いましたが、念のため全解としました。

開発中は、こんなもの設定しないほうが良いですね。




2013年8月7日水曜日

WordpressにIE安全じゃないよ!と怒られる-IE10なのに・・・

Wordpressで開発していますが、突然、管理画面のダッシュボード画面に赤い警告が出ました。

------------------------------------------------------
お使いのブラウザは安全ではありません!


Internet Explorer の安全ではないバージョンをお使いのようです。
古いブラウザを使っていると、コンピューターを危険に曝してしまいます。
WordPress のすばらしさを実感するには、ブラウザーを更新してください。


Internet Explorer をアップグレードするか ブラウザの選択肢を知る
Browse Happyサイト を訪れてみてください。


非表示にする
-------------------------------------------------------

こんな文言が入っていました。

おかしいな?

IE10なのに・・・

それと、テンプレートとか崩れていることも発覚。

パンくずリストも、「○○>■■>△△」というように横並びに表示されるはずが、

「○○>
■■>
△△」

このように、縦になっている。

そこで、

Google先生にお尋ねしてみました。

「wordpress ie10 安全ではない」

すると、

シロップ さんのパソコン修理日誌パソコン修理日誌にたどり着きました。

中身を拝読すると

むむむ!

おんなじ現象あるね。

解決方法は、なんと、IEのアドレス窓に虫眼鏡、南京錠、紙がち切れたイメージとリロードマーク
が並んでいるうちの

「紙がちぎれたイメージ」

これが原因でした。

現状、「青くなっている」

これをクリックすると

あら不思議

私意図したもとの状態に戻っているではありませんか。

これを押すと互換表示されるようです。

あまり深い意味は探りませんでしたが、不具合解消ということで

先に進むことにしました。

シロップ さん、感謝です。(^^)

2013年8月1日木曜日

SSL環境下でWordPressの管理画面、ログイン画面を使う

SSL環境でWordPressを運用するには、公開ページに対してSSL運用が可能となって

ホットするのもつかの間で、ログイン画面、管理画面に入れなくなります。

私、あせりました。

そもそもの間違いは、SSL申請中にWordPressを導入し、チョコチョコイジッテイタこと

でした。

WordPressの導入時は、http://example.comで運用中で、何の問題もありませんでした。

しかし、SSLの申請上、WWW.あり、なしを決定したり、.htaccessの設定を変えたりで

サーバーの環境が刻々と変わり、挙句、SSL用にIPが変わった。

(1)www.wxample.com IP:nnn.nnn.nn.nn

(2)example.com       IP:mmm.mmm.mm.mm

となっていました。

まづこれを上の(2)のIPを(1)のIPに合わせるようにDNS設定を変更する。

次に、WordPressのインストール先をexample.comだったのでwww.example.comにするため、

一度

WordPress本体をサーバーからUninstallする。また、MySql DB を削除する。

こうして、サーバーからWordPressとMySqlを削除した上で、再度WordPressをインストールする。

(DBも新規作成したうえで)

こうして、作成しなおした環境下で本題の「WPのログイン・管理画面をSSL環境下で稼動するよう設定変更を行う」

これを実現するには、WordPressの環境設定ファイル「wp-config.php」を修正する。

サーバのドキュメントルートし下にWordPressを導入した場合

www.example.com/

以下に当該ファイルは存在するはずです。

このファイルの適当な箇所に以下のパラメータを設定することで、うまくいきました。

--------------------------------------------
/** SSL ログイン・管理画面アクセスを強制する */
define('FORCE_SSL_ADMIN', true);
--------------------------------------------

この環境変数設定は、管理画面、ログイン画面に対し、強制的にSSLアクセスする
パラメータです。

このほかにログイン画面だけ強制的にSSLアクセスするパラメータがあります。
-------------------------------------------
define('FORCE_SSL_LOGIN', true);
-------------------------------------------

参照

http://wpdocs.sourceforge.jp/Administration_Over_SSL

やっと、SSL環境下での開発が始められます。


2013年7月30日火曜日

SSL環境下で301リダイレクトを使って「WWWあり」と「WWWなし」を統一する

レンタルサーバを借りて、ドメイン登録をしました。

私の入ったレンタルサーバは、www.example.comと「www.あり」

example.comの「www.なし」いずれの指定でもアクセス可能な設定でした。

今回、SSLを設置するにあたり、コモンネームというのをSSLに指定する

必要に迫られました。

????

SSL通信を行うには、サーバー証明書というのが必要で、この証明書に

コモンネームという設定があり、ここにURLを指定する必要があります。

すなわち、

コモンネームに指定されたURLによるアクセスでなければ、SSL通信

ができないということだそうです。

ということは、ドメインの指定で上記のように「www.あり」「www.なし」の

いづれでもアクセス可能な設定であっても、SSL通信をするには、いづれか

一方に決めないとコモンネームに登録されていないURLでアクセスすると

SSL通信が確立されないのです。

たとえば、

コモンネームが、www.example.comと指定されている環境で、

example.com

と指定してアクセスすると、SSL通信できません。

ということらしいのです。

そこで、

SSL導入にあたり、ドメイン「example.com」に「www.あり」「www.なし」

いづれか一方に統一する設定、http://でアクセスしても、https://にリダイレクトする設定
をすることになりました。

方法を以下に示します。

ドメインのルート直下にある「.htacsess」ファイルに以下の設定を追加記入します。

★「www.あり」に統一かつ、コモンネームのアドレスにリダイレクトさせる場合

▼設定例(example.com)
-----------------------------------------------------
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^example.com
RewriteRule (.*) https://www.example.com/$1 [R=301,L]
-----------------------------------------------------

★「www.なし」に統一かつ、コモンネームのアドレスにリダイレクトさせるする場合

▼設定例(example.com)
-----------------------------------------------------
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^example.com
RewriteRule (.*) https://example.com/$1 [R=301,L]
-----------------------------------------------------

じゃあ、どちらに統一すべきか?

という議論がありますが、私見では、どっちでも、お好きなほうを

選べば良いと思います。

※この手法は、サイト移転したときに、アドレス転送をする場合にも使うそうです。

引越し前サイトに新サイトのアドレスを埋めればOK。