お絵描きCGIのBBSNOTEをLinux Mint 17 Qianaで使う方法。

bbsnoteとうとう、種明かしです。

BBSNOTEは、一般的に、Perlの最新版では、データーの書き込みの際に、エラーが出ます。

しかし、私のホームページではBBSNOTEは動いてますよ。

どうしてか? 知りたいですか? (;´∀`)

実は、XAMPP用のPerlを利用しているから、使えるのです。

[ こちらから、XAMPP Linux 1.7.1をダウンロード ]します。

さて、これをLinux Mint 17 Qianaに入れると使えます。どこにインストールするか。

/opt/に展開します。具体的には、

[crayon]

# tar -vzxf  xampp-linux-1.7.1.tar.gz -C /opt/

[/crayon]

とします。そうすると、

/opt/lampp/bin/perl

という所にperlが保存されているので、bbsnote.cgiのトップの所に記載されている部分を、次のようにします。

[crayon]

#! /opt/lampp/bin/perl
[/crayon]
これで、XAMPP用のPerlがBBSNOTEの動作の際に利用されて、動いてくれるわけです。

お試しあれ。と言いつつ、今ではBBSNOTEは配布されているかどうか、配布元の所は閉鎖されているのでしたよね。

今更感たっぷりの情報だったらごめんなさい。

そこで、この方法をelementary OSに適用しようとすると、上手く行きません。

最新版のFreyaのBeta 1版を使って挑戦しましたが、上手く行きませんでした。残念! 無理もないかな。

BBSNOTEはかなり古い感じのCGIだからなぁ。

PHP 5.5.15、MySQL 5.5.38にアップデートしました。そして私のMySQLの不具合はこんな感じになってます。

[crayon]
$ php -v
PHP 5.5.15RC1 (cli) (built: Jul 15 2014 11:14:55)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
$ mysql -V
mysql Ver 14.14 Distrib 5.5.38, for debian-linux-gnu (x86_64) using readline 6.3
[/crayon]
MySQLは昨日cron-aptによって、自動アップデートされました。
開発関係者に感謝します。
私のMySQLはどこがおかしいかと言いますと、mysqlをrestart1回目は正常にrestartされます。が、しかし、2,3回連続ですると必ず、
[crayon]
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)
* Checking for tables which need an upgrade, are corrupt or were
not closed cleanly.
[/crayon]
と、ズラズラと沢山表示されて、最後には、しっかりとMySQLが再起動されている模様ですが、こんな表示がされてしまいます。
これは何時からだったか? これって正常なのでしょうかね?
MySQLのsqlファイルをviで編集して読み込ませたりしているからかな? とも思いますが、まぁ、これで様子見ます。
MySQLのDUMPファイルは現在281MBの大きさです。

Linux Mint 17 Qianaで、MySQLの動作が何かおかしいと思って取った対策。

my.cnfのファイルは、サーバーのメモリ容量によりまして、変えたほうがいいのかな? と思って私も変えてみました。
my.cnfのファイルは下記を例に、変えたほうがいいかもしれませんね。

my-small.cnf
64MB以下のメモリ

my-medium.cnf
128MB以下のメモリ

my-large.cnf
512MB以下のメモリ

my-huge.cnf
1GB~2GB以下のメモリ

my-innodb-heavy-4G.cnf
4GBのメモリとInnoDBで作成されたデータベース
らしい。

私のHewlett-Packard社のサーバー専用機は4GBのメモリですが、一応、1GB~2GB用の”my-huge.cnf”を設定ファイルに選んでみました。

[crayon]
# cd /usr/share/doc/mysql-server-5.5/examples
# gunzip my-huge.cnf.gz
# cp my-huge.cnf /etc/mysql/
# /etc/init.d/mysql stop
# cd /etc/mysql
# mv my.cnf my.cnf.bak
# mv my-huge.cnf my.cnf
# /etc/init.d/mysql restart
[/crayon]
これで様子見ます。昨夜早朝はMySQLがストップしてご迷惑をお掛けしてすみませんでした。
参照:http://blog.quall.net/linuxserver/316/

Linux Mint 17で、debian-sys-maintを、expectを利用して、自動入力するスクリプト。

[crayon]
#!/bin/bash

echo “###################### MySQL ########################”
MYSQL_PASS=YOUR_MySQL_ROOT_PASSWORD
DEBIAN_MYSQL=`sudo tail -5 “/etc/mysql/debian.cnf” | grep “password = ” | cut -c 12-28`
sudo apt-get -q -y install expect
sudo /etc/init.d/mysql force-reload
expect -c ”
spawn sudo mysql -u root -p$MYSQL_PASS
expect \”mysql> \”
send \”SET PASSWORD FOR ‘debian-sys-maint’@’localhost’ = PASSWORD(‘$DEBIAN_MYSQL’);\n\”
expect \”mysql> \”
send \”flush privileges;\n\”
expect \”mysql> \”
send \”exit\n\”
interact

sudo /etc/init.d/mysql force-reload
exit
[/crayon]

GUM10_CL02004私のMySQLは、段々おかしな動作をするようになりましたよ。しかし、先ほどは、「/etc/init.d/mysql force-reload」を沢山使いましたが、エラーは出ないで、MySQLはしっかりと動いている様子で何よりです。

以上のスクリプトでdebian-sys-maintのパスワードは、自動的にインスコされますが、ご自分でご確認を、一応してみて下さいね。

おかしな動作になっても、私は免責ということで。自己責任でお願いします。

 

Linux Mint 17で、PHP+MySQLを動かしているのですが、どうも、最新バージョンでは不安定だと思ったので、対策を練りました。

対策を練るとしました。

やはり、MySQLの動作が不安定だなぁと思ってね。再起動させても、何か、腑に落ちない動作をしますので、

思い切ってイメチェン! しました。

つまり、PHPのバージョンを、PHP5.5.12からPHP5.5.9に下げましたよ。

具体的にどうしたかというと、

[crayon]
$ sudo add-apt-repository ppa:ondrej/php5-oldstable
$ sudo apt-get update
$ sudo apt-get remove php5 php5-common
$ sudo apt-get install php5 php5-common php5-cli php5-mysql php5-curl php5-gd php5-mcrypt php5-dev php5-gd php-pear php-apc
$ sudo /etc/init.d/apache2 restart
$ sudo /etc/init.d/mysql restart
[/crayon]
そうすると、Linux Mint 17の場合には、現在は、PHP5.5.9がインスコされますよ。
これで行こうと思います。

そして、MySQLが立ち上がらなくなったら、下記のサイトをご参考にして頂いて、対策を練るのが一番速いと思います。

この方法は、MySQLの全データを消す方法なので、MySQLデータのバックアップを取っていないと、基本的にやってはいけませんがね。

参照:なんかUbuntuのVMを強制終了させてMySQLが起動できなくなった話

私のサイト群のMySQLのデータは肥大化してきました。全体のバックアップも3Gを超えてます。どんだけ内容を詰め込んだのでしょうね。

この他にも、私の動画、音声を含めれば、もっと大きくなります。

最近は、いそいそそわそわしていて、そんなことでは落ち着きが無いなぁ。と思いまして、もう少し落ち着こうと思います。

せっかく、Linux Mint 17をインストールして、今後はOSのバージョンアップは楽になるのですからねぇ。

今後が楽しみな、Linux Mintですね! 😀

munin-nodeを再起動時、”Pid_file already exists for running process”となった場合。

GUM14_CL02012

/etc/init.d/munin-node restart
とした時、

Pid_file already exists for running process

と表示される事があります。

その時には、

[crayon]
# cd /var/run/munin
# rm munin-node.pid
# /etc/init.d/munin-node restart
[/crayon]

とやってみてください。この方法は正しいかどうかは、さておき、私は、これでうまく、エラーメッセージがなく、munin-nodeが再起動出来ましたよ。

iPad miniの16GBの容量の物を買って、とうとう、「空きが無くなった」と、iOSから言われました。

GUM03_CL13033とうとう、iPad miniの容量が無いとiOSに言われました(;´Д`)。

やっぱり、余裕こいてどんどんダウンロードしてましたからね。

しかし、音楽データのmp3は、LinuxのMediatombを使って、LANDISKからデータを読み込んで、音楽を聴いているので、iPad miniには音楽データは無しですよ。

これで、大変助かっていると思いますよ。Mediatombは、一階の地デジテレビでもネットワークテレビなので、音楽がLANDISKと繋がって聴くことが出来ますよ。

重宝しております♪

さて、話は戻しまして、iPad miniの容量を空けるために、どんどんアプリを削除しました。そして、Podcastのデータも全消ししましたよ。

そしたら、容量が2GBか3GB位空きまして、ホッとしております。

Linux Mint 13 Maya – MATEで、Terminal(端末)にAscii Art(フォーチュン・クッキー)を表示させる方法。

人によっては、この、Ascii Artが好きなんです。という人も居るであろう。

私もその一人で、Linux MintにはこのAscii ArtがTerminalで表示されなければっ! と、思って居りました。

このほど、Cinnamonなど、他のバージョンでは知りませんが、Linux Mint 13 Maya MATEバージョンだけ確認しました。

次の方法を採れば、Ascii Artが表示されるようになります。

下記をご覧下さい。

Menu → コントロール・センター → デスクトップの設定 → 左欄の「端末」をチョイス → フォーチュン・クッキーを表示するをチェックする。

そして、一回、Puttyなどの端末をログインし直した方が確実です。

fortune
下記のような、Ascii Art(フォーチュン・クッキー)が表示されればおkです。

fortune2

お目出度うございました。

運用中のVPSサーバーであるelementary OSは、バーチャルホストの数を80から11に変更したら、鯖落ちしなくなった。

GUM14_PH07040運用中のVPSのサーバーである、elementary OSは、以前までは、何と、80個のバーチャルホストを使って運用していた。しかも、メモリはそれで2Gで運用していたのですよね。

しかし、それでは結局無理があったのか、3日とか5日おきに鯖落ちを良くしておりました。

そして、Apacheが落ちているときに、自動的に再起動させ復活するシェルも使っていたが、

この度、バーチャルホストの数を11個に激減させまして、Apacheを動かしていたら、もう10日以上経ちますが、まだ鯖落ちはしてません。

そして、Apacheが落ちているときに、自動的に再起動させるシェルも現在では一切使っておりませんが、それでも鯖落ちしません。

これは?! と思って、嬉しくなりました。原因はきっと、バーチャルホストの数が多すぎて、鯖落ちを良くしていた模様ですね。

今後も、鯖落ちしないか、確認しながら、ホームページを進めていきたいと思います。

サーバーが、PHP 5.4.28 + MySQL 5.5.37になりました。

[crayon]
# php -v
PHP 5.4.28-1+deb.sury.org~precise+1 (cli) (built: May 5 2014 09:32:44)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
with eAccelerator v1.0-dev, Copyright (c) 2004-2012 eAccelerator, by eAccelerator

# mysql -V
mysql Ver 14.14 Distrib 5.5.37, for debian-linux-gnu (x86_64) using readline 6.2
[/crayon]

お蔭様で有り難うございます。バージョンアップも出来ました。ホームページの動作は順調のようです。

1 129 130 131 132 133 136