ログイン
ユーザ名:

パスワード:


パスワード紛失

新規登録
Main Menu
Tweet
Facebook
Line
« 1 (2) 3 »
スレッド表示 | 新しいものから 前のトピック | 次のトピック | 下へ
投稿者 スレッド
webadm
投稿日時: 2022-3-8 13:40
Webmaster
登録日: 2004-11-7
居住地:
投稿: 3004
Re: AWS Ubuntu20.04でMariaDBが起動しない訳
MariaDBの起動にものすごく時間がかかるんだが(´Д`;)

最初に起動成功した時は、sudo apt install mariadb-serverコマンドの一環として最後にmariadb.serviceを開始するところで固まったんだが、再接続したら起動成功していたという具合。

やっぱりメモリが足らないのか?

でもsshターミナルのエコーバックはあるので接続は死んではいない。

webadm
投稿日時: 2022-3-8 13:44
Webmaster
登録日: 2004-11-7
居住地:
投稿: 3004
Re: AWS Ubuntu20.04でMariaDBが起動しない訳
2GBメモリのインスタンスでMariaDB起動途中だけど、メモリ足らないかもな。

素ではUbuntuをPCにインストールした時のようにswapドライブは無いので、メモリが足らなくなるとOOM killerによって優先順位の低いプロセスが殺されて開放されたメモリを必要なプロセスに再利用するという動作が発生するので要注意。

なので時々端末がフリーズするのかも。

ubuntu@ip-172-26-8-53:~$ free
total used free shared buff/cache available
Mem: 2032760 240660 886608 816 905492 1626540
Swap: 0 0 0
ubuntu@ip-172-26-8-53:~$ jobs
[1]+ Running sudo systemctl start mariadb.service &
ubuntu@ip-172-26-8-53:~$
webadm
投稿日時: 2022-3-8 13:50
Webmaster
登録日: 2004-11-7
居住地:
投稿: 3004
Re: AWS Ubuntu20.04でMariaDBが起動しない訳
systemctlコマンドは完了しない状態だけど、MariaDB自体はもう立ち上がっていたぽい。

一応クライアントからの接続もできているぽい。

とりあえず条件付きだけど、PHP4ビルドしてCMSの動作テストするしかないな。

ubuntu@ip-172-26-8-53:~$ ps -e|grep mysql
4864 ? 00:00:00 mysqld
ubuntu@ip-172-26-8-53:~$ sudo mysqladmin status
Uptime: 762 Threads: 6 Questions: 1 Slow queries: 0 Opens: 18 Flush tables: 1 Open t
ables: 11 Queries per second avg: 0.001
ubuntu@ip-172-26-8-53:~$ sudo mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 11
Server version: 10.3.34-MariaDB-0ubuntu0.20.04.1 Ubuntu 20.04

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
+--------------------+
3 rows in set (0.000 sec)

MariaDB [(none)]>
webadm
投稿日時: 2022-3-12 2:42
Webmaster
登録日: 2004-11-7
居住地:
投稿: 3004
現行サーバーのwebコンテンツ転送
PHP4はビルドが通ったので、いよいよ現行サーバーのwebコンテンツを転送して、動作環境を構築することに。

まずは手初めに、apacheサーバーのデフォルトのコンテンツツリーを転送することに。

今までは単一ファイルの転送であれば、それぞれTeratermで接続してメニューのscpでWindows PCに一端転送し、そこからAWSに接続したTeraTermのscpで転送していたけど、今度はディレクトリツリー全体をコピーしないといけないので、

(1) rsyncコマンドを使用して現行サーバーからAWSにディレクトリツリー全体を同期させる
(2) 現行サーバーのディレクトリをtar ballに固めて、scpコマンドで現行サーバーからAWSに転送し、AWS上で展開する

(1)を試してみたところ、どうやらディレクトリツリーが大量過ぎるのか、メモリが足らずにrsyncが落ちてしまうことが判明。
(2)は問題なく完了。

(1)でも途中までは同期できていたみたいなので、現行サーバーで使用されるCGIバイナリがそのままAWSの64bit Ubuntu上で動作するかチェックしてみた。

結果はNG。

理由は現行サーバーは32bit Ubuntuなので実行バイナリはすべて32bit版である。デフォルトで64bit Ubuntuは32bitバイナリの実行をサポートしていないので、そのままでは実行できない。

64bit Ubuntuで32bit バイナリ実行をサポートするには、

sudo apt install lib32z1

を実行するだけで良いぽ。

確かに現行のCGIで32bit ELFフォーマットのものが実行できるようになった。

とりあえず64bitバイナリも一部はビルドしてあるけど、互換性を考えると現行サーバーのバイナリを実行した方がよさげ、必要メモリ量も少なくて済む?

あとはCMSのコンテンツを転送するだけ。

あ、データベースもdumpしてリプリケートしとかないと。
webadm
投稿日時: 2022-3-13 2:25
Webmaster
登録日: 2004-11-7
居住地:
投稿: 3004
XOOPS CMSの動作テスト
とりあえず、XOOPS CMSが使える環境が整ったので、現行サーバーのコンテンツをコピーして、Windows PCのetc/hostsファイルでwww.rainbowseeker.jpのIPアドレスを一時的にAWSのインスタンスの静的IPアドレスに変更してブラウザで開いてみた。

すると、いつまで経っても開かない。

良く考えたら、デフォルトでAWSのインスタンスには外部にはSSHとHTTPしかポートが開いていないのが敗因。

HTTPSポートを開くように追加したらなにやら表示された。

どうやらxoopsによるページレンダリングが出来ない時のエラーテキスト画面が出ることが判明。

懸念してはいたが、直接の原因はxoops内でmysqlサーバーに接続することが出来なかった場合の症状。

当初はmariadbがsystemctl start mariadb.serviceを実行すると起動してしばらくはアクセスできていたのが、systemctlコマンドがstart処理のタイムアウトで終了と同時にmariadbがシャットダウンされる問題によるものと思っていたが、そうではなかった。

mysqlコマンドではちゃんとデータベースが開ける。

mysqlとmariadbは基本的にパッケージ名称が異なる以外は本家と派生の違い以外ない。

systemdのスクリプトもmysqlの頃のコピーだし、サーバーのデーモンもmysqldと変わっていない。

mariadbを導入直後はrootユーザーが予め登録されていてそれを使用してパスワード無しでアクセスできるが、後でパスワードを設定することができるので、現行サーバーで使用しているのと同じパスワードを設定して、パスワード無しではアクセスできないようにしたが、それが良くなかったのか?いやmyqlコマンドでは問題なくアクセスできているし。

本当に接続しに行っているのか確認するために、tcpdump -i lo でローカルなパケット交換をキャプチャしてみると、問題なく動作しているmyqlコマンドの場合は、ちゃんとmyqlポートにtcpで接続しに行って送受信しているが、xoopsの方はページ表示させてもうんともすんとも言わない。ということは実際には接続を試みているわけではなく、PHP内部処理でエラー判定になっている模様。

P.S.

apache 2.4で古いphp4をmoduleとして使用する場合に、一部 apache 2.2以前とシンボル名が変更になっていることが判明。apache2起動時にphp4 moduleをロードする際に未解決シンボル unixd_configでhttpdが立ち上がらないことで発覚。

現行サーバーでは問題なく動作しているのは、構築時に忘れてしまっているが、ソースコードレベルでPHP4側を修正して解決してしまっていたからだった。

その時のソースツリーが残っているので、それをコピーして、ビルドとインストールをやり直したら解決した。

webadm
投稿日時: 2022-3-13 4:39
Webmaster
登録日: 2004-11-7
居住地:
投稿: 3004
PHP4からMariaDBに接続できない件
XOOPS CMSそのものを使用しないで、簡単なPHPスクリプトでデータベースに接続するだけのものを作成して試したところ、原因らしきものが判明。

どうやら最新のMySQL 8およびそこから派生したMariaDBは、クライアントとサーバー間のユーザー認証方式が単純なユーザー名とパスワードテキストではなくなったらしい。

まあ、パスワード文字そのものが流れていくのは望ましくはないのは確かなのでこの変更は良いとして、それ以前に開発されたクライアントの接続時の認証手順とは互換性がなくなったので、接続できないということに。

mysqlコマンドが正常に接続できるのは、同じリリースパッケージなので新しい認証方式に対応しているからということも納得が行く。

PHP4側を対応させるか、MySQL側を後退させるかどっちにするかだな。
webadm
投稿日時: 2022-3-13 5:04
Webmaster
登録日: 2004-11-7
居住地:
投稿: 3004
Re: PHP4からMariaDBに接続できない件
認証方式を旧式に戻す方法があるので試してみたら、困ったことになった。

mysqlデータベースのuserテーブルに関して古いパスワード方式のものを追加するのは良いとして、それと同時にmysqldサーバーも--old-passwordsオプションを指定して立ち上げ直す必要があった。

古い認証方式への後退手段が提供されているのは、あくまでも、新しい認証方式に対応していないクライアントしか使えないシステムのための救済処置であり、今後一切新しい認証方式は使わないという場合だけを想定している。

何が問題かというと、mysqldを--old-passwordsオプション付きで起動した場合、新しい認証方式は使えなくなるので、新しい認証方式しかサポートしていない最新のmysqlのクライアント(mysqlコマンドも含む)を使用して接続が出来なくなってしまう点である。

これは結構困ったことになったな。

古いMySQLをソースからビルドするか?

玄箱やPS3をサーバーにしていた時はそうやってた気がする。ARMやPowerPC Linux用バイナリとか無かった気がする。
webadm
投稿日時: 2022-3-13 15:23
Webmaster
登録日: 2004-11-7
居住地:
投稿: 3004
Re: PHP4からMariaDBに接続できない件
Oracleのダウンロードページからcommunity版(GPL)の古いMySQL 5.7というのがダウンロードできたので導入してみた。

最新のMySQLと違ってメモリフットプリントが小さいのかすんなり起動した。

しかし問題が、mysqlコマンドでさえも接続できないのである。

確か最初に導入した際にパスワード設定を求められた記憶があるけど、それを入力してもだめぽ。

ログを見るとなにやら不審な内容が、

022-03-12T20:43:02.880030Z 1 [Warning] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option.

2022-03-13T04:54:08.891746Z 0 [Warning] User entry 'root'@'localhost' has a deprecated pre-4.1 password. The user will be ignored and no one can login with this user anymore.

( ´゚д゚`)えーーー

よく見ると続きがあった。

2022-03-13T04:54:08.891779Z 0 [Warning] Some of the user accounts with SUPER privileges were disabled because of empty mysql.user.plugin value. If you are upgrading from MySQL 5.6 to MySQL 5.7 it means we were not able to substitute for empty plugin column. Probably because of pre 4.1 password hash. If your account is disabled you will need to:
2022-03-13T04:54:08.891785Z 0 [Warning] 1. Stop the server and restart it with --skip-grant-tables.
2022-03-13T04:54:08.891789Z 0 [Warning] 2. Run mysql_upgrade.
2022-03-13T04:54:08.891793Z 0 [Warning] 3. Restart the server with the parameters you normally use.
2022-03-13T04:54:08.891806Z 0 [Warning] For complete instructions on how to upgrade MySQL to a new version please see the 'Upgrading MySQL' section from the MySQL manual

ふむ解決方法があるぽいな。

やってみたら、ちょっとやり方が違った。

1. Stop the server

sudo systemctl stop mysql.service

これはいいとして次ぎの

and restart it with --skip-grant-tables.

簡単に一言で済ませているけど具体的にはもっと込み入っている。

sudo vi /lib/systemd/system/mysql.service

でエディタで開いて

ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid

という行を見つけて

ExecStart=/usr/sbin/mysqld --skip-grant-tables --daemonize --pid-file=/var/run/mysqld/mysqld.pid

という具合に --skip-grant-tables を挿入する。

これでエディタを閉じるだけでは不十分で、前の内容は現在動作しているsystemdが覚えて居るので、再度ファイルから読み直して覚えてもらう必要がある。

それをしないと、次ぎに mysql.serviceをstartさせると怒られる

Warning: The unit file, source configuration file or drop-ins of mysql.service changed on disk. Run 'systemctl daemon-reload' to reload units.

なので、systemd用のスクリプトを変更した場合には、それをバックグラウンドで走行中のsystemdに反映させるために、

sudo systemctl daemon-reload

を実行する必要があった。

この後で

sudo systemctl start mysql.service

を実行すると、mysqlで接続できることを確認。

root@ip-172-26-8-53:/home/ubuntu/rainbowseeker# systemctl start mysql.service
root@ip-172-26-8-53:/home/ubuntu/rainbowseeker# ps -e |grep mysql
171347 ? 00:00:00 mysqld
root@ip-172-26-8-53:/home/ubuntu/rainbowseeker# cat /proc/171347/cmdline
/usr/sbin/mysqld--skip-grant-tables--daemonize--pid-file=/var/run/mysqld/mysqld.pidroot@ip-172-26-8-53:/home/ubuntu/rainbowseeker# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.7.37 MySQL Community Server (GPL)

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> exit;
Bye
root@ip-172-26-8-53:/home/ubuntu/rainbowseeker#

まてよこのままでもよくね?

セキュリティ上は良くないが。

とりあえずPHP4から試してみたが、結果は変わらず(´Д`;)

やっぱ新しい認証方式にPHP側を対応させないと無理ぽい。

とりあえず残りの手順

2022-03-13T04:54:08.891789Z 0 [Warning] 2. Run mysql_upgrade.

root@ip-172-26-8-53:/home/ubuntu/rainbowseeker# mysql_upgrade
Checking if update is needed.
Checking server version.
Running queries to upgrade MySQL server.
Checking system database.
mysql.columns_priv OK
mysql.db OK
mysql.engine_cost OK
mysql.event OK
mysql.func OK
mysql.general_log OK
mysql.gtid_executed OK
mysql.help_category OK
mysql.help_keyword OK
mysql.help_relation OK
mysql.help_topic OK
mysql.innodb_index_stats OK
mysql.innodb_table_stats OK
mysql.ndb_binlog_index OK
mysql.plugin OK
mysql.proc OK
mysql.procs_priv OK
mysql.proxies_priv OK
mysql.server_cost OK
mysql.servers OK
mysql.slave_master_info OK
mysql.slave_relay_log_info OK
mysql.slave_worker_info OK
mysql.slow_log OK
mysql.tables_priv OK
mysql.time_zone OK
mysql.time_zone_leap_second OK
mysql.time_zone_name OK
mysql.time_zone_transition OK
mysql.time_zone_transition_type OK
mysql.user OK
The sys schema is already up to date (version 1.5.2).
Checking databases.
sys.sys_config OK
Upgrade process completed successfully.
Checking if update is needed.

ふむなんとも無いみたいだけど。

これでmysqldの起動パラメータを元に戻してもいいのかな?

root@ip-172-26-8-53:/home/ubuntu/rainbowseeker# vi /lib/systemd/system/mysql.service
root@ip-172-26-8-53:/home/ubuntu/rainbowseeker# systemctl daemon-reload
root@ip-172-26-8-53:/home/ubuntu/rainbowseeker# systemctl stop mysql.service
root@ip-172-26-8-53:/home/ubuntu/rainbowseeker# systemctl start mysql.service
root@ip-172-26-8-53:/home/ubuntu/rainbowseeker# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.7.37 MySQL Community Server (GPL)

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> exit;
Bye
root@ip-172-26-8-53:/home/ubuntu/rainbowseeker#

ああ、直ったわ。

しかし依然として、PHPからは接続できないな。

022-03-13T06:34:07.559020Z 4 [Note] Bad handshake

まあ、これはPHPのバージョン如何に関わらず共通するらしい。

だからPHPはもうだめだと言われているのかも。

対策考え中...

webadm
投稿日時: 2022-3-13 17:15
Webmaster
登録日: 2004-11-7
居住地:
投稿: 3004
Re: PHP4からMariaDBに接続できない件
幾つか対策案を考えた、

(1) MySQL側を変更して旧認証方式を復活させる
これ自体は技術的には可能だと思われるが、既に最新では旧認証関連の実装はソースコードから取り除かれているし、簡単には復活できそうもない。
しかもAPIの仕様そのものが変更になっている可能性すらあるのだ。
それ以前の課題として最新のMySQLをソースからビルドできるのかという問題もある。
やってみたが難しそうすぎて却下。

(2) 現行サーバーで使用しているMySQLのバージョンを導入する
現在公式サポートされているMySQL 8に次いで古いMySQL 5.7.37でも旧認証方式は廃止されているので、現行サーバーで使用している動作実績のある、MySQL 5.5.52が導入できれば問題解決なはずだが。

やってみたが、MySQL 5.5.52が依存する他のパッケージが新しすぎて導入すらできないことが判明。

そもそもdebianベースのUbuntuにrpmパッケージを導入すること事態に無理があったかも。

(3) PHP側を新認証方式に対応させる
元々の問題はPHP4の頃のmysql_connection等の古いmysql関数を最新のMySQLに使うこと自体にあった。
最新のPHPではmysqliというまったく新しいAPIに切り替わったために、それをバックポートして使うか、その他の選択肢として、PDOというのをバックポートして使うという手もある。
しかしPHP4とそれ以降のPHPバージョンとは言語仕様そのものが違っているので、バックポートの難易度は高い。
自分で作ったほうが早いかもしれない。

また検討中。
webadm
投稿日時: 2022-3-13 19:17
Webmaster
登録日: 2004-11-7
居住地:
投稿: 3004
遂にAWS上で現行サーバーのXOOPS CMSが動いた
結局のところ、原点に戻って

(1) 現行サーバーで動作実績のある Mysql 5.5.52のLinux generic binaryをダウンロードして導入

といってもこの頃のMysql Linux generic版はすべてのファイルが単一ディレクトリツリー配下にアーカイブされたものなので、それを展開してインストールスクリプトを実行して、/usr/local/mysql に移動するだけで導入の99%は完了。

あとは、mysqlサーバーデーモンを起動するスクリプト(mysql.server)があるので、それを起動するか、システム立ち上がり時に自動起動するように/etc/init.dにコピーするだけ。

この頃のMySQLは初期データベースのrootパスワードは無しなので、インストールスクリプト実行時にコンソールにパスワードの設定方法が出力されるので、その通りにやるだけ。

(2) 現行サーバーのMySQLデータベースダンプから必要なデータベースをリストアする

これも、問題なくできた、mysqlコマンドでmysqlデータベースを開いて、create database xxxx; を必要なデータベースに関して実行して exit;で終了。

リストアは、mysql -u root -p xxx < alldump.spl

予め現行サーバーでmysqldump -A コマンドでダンプしたデータベースのリストア用SQLファイルを転送してあるものをリダイレクトするだけ。複数のデータベースがある場合は、それぞれに関して実行。

(3) MySQL認証方式を旧式に変更

現行サーバーのMySQLも実はそのままではPHP4では接続できなかったみたいで、PHP4がサポートする旧認証方式にmysqlデータベースを変更する必要があった。

これは mysql -u root -p mysql

でmysqlデータベースを開いて、以下のSQL文を実行するだけ。

UPDATE user SET Password = OLD_PASSWORD('hogehoge')
WHERE Host = 'localhost' AND User = 'root';
FLUSH PRIVILEGES;

これで古いPHP4でもMySQLに接続できるようになった。

あとは、ブラウザーでxoopsのトップページを開くと、あらまあ、新旧の見分けが付かないわ。

たぶん現行サーバーのようなサービス遅滞は発生しないはず。

あと残りのコンテンツとかをチェックして現行サーバーと同水準に表示されるか確認する予定。

あとメールも受信できるようにしたいな。

« 1 (2) 3 »
スレッド表示 | 新しいものから 前のトピック | 次のトピック | トップ

投稿するにはまず登録を
 
ページ変換(Google Translation)
サイト内検索