rootのパスワードを忘れた場合

rootのパスワードを忘れた!

MySQLを終了

# kill `cat /var/run/mysqld/mysqld.pid`

MySQLを設定テーブルをスキップさせて起動

# /usr/libexec/mysqld --skip-grant-tables &

ログイン(パスワードなしでログインできる)

# mysql -u root mysql

パスワードを再設定

> UPDATE user SET Password=PASSWORD('パスワード') WHERE User='root';
> FLUSH PRIVILEGES;
> \q

MySQLを終了

# kill `cat /var/run/mysqld/mysqld.pid`

通常起動

# /etc/rc.d/init.d/mysqld start

非同期通信$.ajaxの今と昔

非同期通信で色々調べていたら出てきたやつ

$.ajax({
	url:"http://xxxx/a.php",
	type:"GET",
	dataType:"json",
	success: function(data){
		console.log("OK");
	},
	error: function(XMLHttpRequest, textStatus, errorThrown) {
		console.log("ERROR");
	},
	complate: function(data){
		consolo.log("END");
	}
});

上記これはjQueryのバージョンが1.5以前の古いタイプ

新しいタイプは下記

$.ajax({
	url:"http://xxxx/b.php",
	type:"GET",
	dataType:"json",
})
.done(function(data){
	console.log("OK");
})
.fail(function(jqXHR, textStatus, errorThrown){
	console.log("ERROR");
})
.always(function(){
	console.log("END");
});

メモメモ

PostgreSQLのバックアップを取ってみる

PostgreSQLのバックアップを取ってみる

pg_dumpで実行する場合パスワードなしだと下記のエラーが出る
たぶんpg_hba.confでローカルならパスワードなしOKって設定ができると思いますが…

pg_dump: [archiver(db)] connection to database “hogehoge” failed: fe_sendauth: no password supplied

オプション -w でもスルーできない場合に困る。
cronで実行したいときとかにね。

そのときは「.pgpass」ファイルで回避可能ですよ。

上記ファイル名でファイルを作成し、パーミッションを600にします。
そうしないとエラーで怒られます。

.pgpassの中身は下記

ホスト名:ポート:DB名:ユーザ名:パスワード

パスワード以外はワイルドカード(*)のしてもありです。

ファイル作成後に下記のように実行するとOK

$ pg_dump -w -c DB名 > バックアップ.sql

MySQLのバックアップ(mysqldump)を使ってみる

MySQLのバックアップ(mysqldump)を使ってみる

データ量が多いDBだとphpMyAdminからはデータエクスポートに時間がかかるorタイムアウトになる。
そういうときはコマンドからdumpしちゃいましょうって話

コマンドもMySQLのバージョンで警告がでるみたい。

昔は下記のコマンドで行けてた

/usr/bin/mysqldump --opt --user=USER --password=PASSWORD DATABASE > bkup.sql

そうすると下記の警告が発生。
(バージョン5.6から出るようになりました)

Warning: Using a password on the command line interface can be insecure.

警告なので無視することもできるのだけど。
気分的に良くないのでちゃんと手直ししてみましょう。

警告文はパスワードをコマンド上に表示させるのはセキュリティ上よくないぜよ と言っております。

コマンドに出さないようにするためにはパスワードを保存しておくファイルを作成して
それを読み込んであげることで回避できます。

まずはパスワードを保存しておくファイルを作成します。
ファイル名:mysql.cnf

中身↓

[client]
user = hoge
password = hogehoge
host = 192.168.1.1

そしてコマンドは下記!
※–default-fileは一番最初に指定します。

mysqldump --defaults-file=mysql.cnf --opt DATABASE > bkup.sql

ちなみにmysql.cnfにdatabase=hoge とデータベース名を入れると下記の警告がでます。

Warning: Using unique option prefix database instead of databases is deprecated and will be removed in a future release. Please use the full name instead.
Warning: mysqldump: ignoring option ‘–databases’ due to invalid value ‘hoge’

設定ファイルにdatabaseは指定しないほうが良いですね。

【WordPress】メディア一覧が表示されない、アイキャッチの登録ができない

メディアライブラリで画像の一覧が表示できない問題に遭遇
グルグル回り続けるだけでいつまで経っても表示がされない。

表示切替で「リストビュー」なら一覧が表示された。
「グリッドビュー」だとグルグルするだけ・・・

ちなみにこの問題はadmin-ajax.phpの修正で直すことが可能です。

そして投稿でアイキャッチの登録ができない。
アイキャッチの選択まではできるが、OKを押しても適用されない。

原因不明

検索しても情報なし。

ローカルのXAMPPにファイルを全てダウンロードして設置してみたら両方ともOKだった。

ということはサーバーの設定に問題がありそうだ。
1個1個phpの設定を見ていく。

原因を発見

output_handler mb_output_handler

これが駄目でした。
これを.htaccessで下記へ修正

php_value output_handler none

文字コードが自動変換されることが影響をうけたようです。
通常だとnoneなので問題が起こる人がいないのかと思います。

解決できてよかった~

PostgreSQLのWhrere時の型チェックの厳密化

CakePHPでDBはPostgreSQLのサイトがある。
そちらを移転作業したときに起きた問題

動作チェック中に下記のエラーが発生

Query failed: ERROR:  operator does not exist: date ~~ unknown
HINT:  No operator matches the given name and argument type(s). You might need to add explicit type casts.

HINTから情報を検索するとPostgreSQLのバージョンで検索(Where)のキャスト(型)のチェックが厳密化されたようです。

今回はPostgreSQL7.4.23 → 9.2.10

厳密化は8.3からのようです。
キャストの厳密化とは検索するときにフィールドの型を厳密にチェックするようです。
今までのバージョンは型を自動で変換してくれていたようですが、8.3からはそれを行わないとのこと

WHERE field_int = '1' // int型に文字列を投げるとか


WHERE field_text = 1// text型に数値をなげるとか

それらがNGとのこと

私のプログラムのエラーはdate型にLIKE検索をしているのがNGでした。

対策としてはFunctionとCastを作成してそれで型の変換をさせる方法があるようですが、
次の移転時にまた困るような気がしたので、今回はプログラム側の修正を行いました。
(プログラムの修正箇所が少なかったため)

CakePHPを使っているのですが下記の修正ではエラーでした。

array(“date::text”=>”2017-11%”)

ということで、ちゃんと関数で変換します。

array("to_char(date, 'yyyy-mm')"=>"2017-11")

エラーなく検索結果が返ってきたらOK

CakePHP Strict Standardsエラーの消し方

サーバー移転時に起きたエラー
PHP5.3→5.6になったのが原因なのかな。

Strict Standards: Redefining already defined constructor for class Object in /home/***/cake/libs/object.php on line 63

Strict Standards: Non-static method Configure::getInstance() should not be called statically in /home/***/cake/bootstrap.php on line 47

CakePHPのバージョンが1.2.5

PHP5.4からエラーレベルE_ALLにE_STRICTが含まれたのが原因です。

CakePHPはプログラム上でerror_reportingを行っているので、php.iniやhtaccessで変更しても×なのです。
修正するにはCakePHPのプログラムを直すということになります。

修正するのに若干手間がかかるので、私は下記の対応をしました。

CakePHPのバージョンアップ

1.2.5 → 1.2.18

バージョンアップの方法はcakeフォルダをまるごとごっそり入れ替えるだけです。

これでエラーがなくなりましたとさ。

Deprecated警告の消し方

Deprecated: Function ereg_replace() is deprecated in ~~~~

PHP5.3から上記警告が表示されるようになっています。
将来的にサポートされなくなる関数を使用した場合に表示される警告です。

その関数を修正するのが良いのですが、状況によっては修正に時間がかかる場合もありますね。

php.iniや.htaccess、ソースで表示をOFFの設定が可能です。

php.iniの場合(要Apacheのリロードor再起動)

error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED

.htaccessの場合

php_value error_reporting "E_ALL & ~E_NOTICE & ~E_DEPRECATED"

ソースの場合

error_reporting(E_ALL ^ E_NOTICE ^ E_DEPRECATED);

Ktai Library for CakePHP1.2の絵文字変換時の文字化け修正

CakePHP 1.2.18

携帯の絵文字変換のコンポーネント、ヘルパーで「Ktai Library for CakePHP1.2」を使っていました。
サーバー移転をしたときに動作しなくなったので、その修正記録

Ktai Libraryのバージョンは0.2.0
(2017/11時点の最新版は0.4.2です。)

auでの絵文字変換がうまくいかない。
バージョンアップも考えたが、色々変更点があって修正対応に時間がかかりそうだったため
0.2.0を修正することにした。

処理の流れとしては下記のような感じ

1.docomoの絵文字を退避
2.文字コード変換
3.docomoの絵文字をauのバイナリ絵文字へ変換

文字コードの変換はうまくいっているが絵文字でNGで文字化け

PHPの文字コード設定は下記
ソースはUTF-8
表示はSJIS

vendors/ecw/lib3gk.php
ソースを追ってみる。

755行目あたり

		if($output_encoding == KTAI_ENCODING_UTF8){
			if($carrier == KTAI_CARRIER_KDDI && $binary){
				$oekey = 2;
			}else{
				$oekey = 1;
			}
		}else{
			$oekey = 0;
		}

出力がUTF-8、KDDIなら処理になっている。
こちら側の出力はSJIS
フィーチャーフォンはUTF-8表示は一部端末のみ

ということでこちらを修正(2箇所)

#		if($output_encoding == KTAI_ENCODING_UTF8){
		if($output_encoding == KTAI_ENCODING_SJIS){
			if($carrier == KTAI_CARRIER_KDDI && $binary){
				$oekey = 2;
			}else{
#				$oekey = 1;
				$oekey = 0;
			}
		}else{
			$oekey = 0;
		}

これで絵文字も表示されるようになった。

プロセスの停止方法

PostgreSQLは使い慣れていません。

DB管理ツールからSQLを投げたらずっとウェイト状態になってしまいました・・・

SQLでプロセスの停止ができるようなので試してみました。

プロセスIDの確認

SELECT * from pg_stat_activity;

プロセスを停止させる。

SELECT pg_cancel_backend(プロセスID);

上で駄目なら

SELECT pg_terminate_backend(プロセスID);

上で駄目なら直接Kill

# kill -9 プロセスID

この場合はroot権限が必要だったりするので使えないことがあります。