トップ > IT

Redmine をバージョンアップしようとして rake db:migrate したら rake aborted! (uninitialized constant ActiveSupport::Dependencies::Mutex)

IT Linux

※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2011/03)です。
※ 情報が古い可能性もありますので、ご留意ください。


なんとかしたログ。

タイトル通り、Redmine を 1.1.2 へバージョンアップする際、DB のマイグレーションで↓のようなエラーが発生した。

$ RAILS_ENV=test rake db:migrate
(in /usr/local/redmine-1.1)
rake aborted!
uninitialized constant ActiveSupport::Dependencies::Mutex

色々と調べていたら、、、↓に辿りついた。

RubyGems 1.3.1 or higher is required (Rails 2.3.5 will fail with RubyGems 1.5.0 and later, stick to previous versions of RubyGems)

RedmineInstall - Redmine

むむっ。rubygems を 1.5.0 より古いバージョンにせよ、とな。

# gem -v
1.6.1

まさかの管理系の rubygems のバージョンが新しすぎて駄目フラグ・・・。

ということで、rubygems を以前使っていた "1.3.7" までバージョンダウンした後、"rake db:migrate" を再実行することで、問題なく DB マイグレーションできました。
(推奨としては、1.4.2 のバージョンがいいかも。)

ちなみに rubygems のバージョンダウン手順

# gem install rubygems-update -v=1.3.7

インストールしたいバージョンを指定し、rubygems-update を gem install する。

# gem uninstall rubygems-update

で、最新版の rubygems-update をアンインストール (削除)

# update_rubygems

で、rubygems-update のインストール済み最新版がインストール (アップデート) される。

と、こんな感じ。

“mount.nfs: Input/output error”

IT Linux

※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2011/02)です。
※ 情報が古い可能性もありますので、ご留意ください。


NFS マウントを試みるときに、下記エラーが出た場合。

# mount -a
mount.nfs: Input/output error

portmap が動いていなかった。というわけで、、、

# /etc/init.d/portmap start

で対応。

子供用のみまもりサービス、GPS BoT (Bsize) を使ってみた

IT お買い物

GPS BoT

学校や習い事など、子供が一人で出かけることが増えてきたので、9月くらいから Bsize 社の GPS BoT を使っています。

所謂、GPS 発信機的なやつですね。スマートフォンと連動して、現在位置を特定できる他、あらかじめ登録している場所に着いたり、または離れたりとか、いつもの行動範囲から外れたりすると、スマホに通知が来るようになります。
見守り携帯・キッズ携帯の代わりになるようなやつです。

せっかくなので、軽くレポートしておきます。

なぜ GPS BoT か

普通だと、キッズ携帯を使いたいよねー、となると思いますが、我が家には、所謂キャリアで契約している電話はないので、キッズ携帯は使えません。（正確には、使えるけど制約があって、目的が達成できるか微妙）

最初は、使わなくなった iPhone に LINE モバイルの SIM (500円/月のプラン) を刺すと、位置情報の特定や LINE でのやり取りができるようになるので、これが良いかと思ったのですが、学校への電話持ち込みの是非とか、故障リスクとか、それ自体で遊んでしまうこととかを考えると、もっとシンプルな機器が良いかなと考えました。

他、自分で作って、ソラコム社とかの IoT 向けの SIM を刺すという選択肢もあったのだけど、故障リスクを減らして安定運用したいのもあり、他の製品も比較した結果、機能性・携帯性・コスト感等で、一番バランス取れていそうな GPS BoT にしました。

GPS BoTは、端末価格4800円 (税抜) で月額価格480円 (税抜、定額通信料含)。縛りがないので、この費用バランス感なら使えなさそうな時に、途中でやめやすいので良いなと。

デバイスを買って使ってみる

Web サイトから GPS BoT を購入すると、モノが送られてきます。
ちなみに私は Amazon で購入しました。次の日に届きますしね。

GPS BoT お子様の現在地や行動履歴を教えてくれるAIみまもりサービス

GPS BoT お子様の現在地や行動履歴を教えてくれるAIみまもりサービス


開封して、まず充電して、デバイスが動き始めると、次はスマホにアプリを入れて（ダウンロードして）登録作業を行います。

GPS BoT

デバイスの側面に BOT ID の記載があるので、そいつをスマホに登録して決済の設定（クレジットカードの登録）を行うと、その瞬間から利用開始できます。割と簡単。


実際のアプリの画面は、マップが表示されて、ちょっと載せにくいw ので、公式サイトの動画から画像を拝借しますが、

アプリからは、複数のデバイスを管理できる他、デバイス自体が現在どこにあるのかをリアルタイムに把握することができます。
デバイス自体は移動しているとき（おそらく揺れの検知等）に発信している模様。

あとは、通知が欲しい場合は、その場所を登録しておくと、出発/到着した際に、スマホに通知が来ます。

スマホも複数登録できて、私と妻のスマホにアプリを入れて、チェックできるようにしています。特に追加料金はかかりません。

実際に使ってみてどうか

さて、実際使ってみてどうか、という点ですが、概ねやりたいことはできていて満足しています。所感を箇条書きしておきます。

  • うちの子供の使い方だと、バッテリーはざっくり約3日間ほどもつ感じです
    • 頻度優先（最短1〜2分間隔）で設定しています
    • バッテリー優先にすると、もっと長持ちするかと思いますが、使ったことないです
    • バッテリーが少なくなると通知が届きます
    • 保険として、小さめのモバイルバッテリーの常時接続を検討中
  • 位置の精度はそんなに悪くないです
    • もちろん位置等の場合によっては数メートルの誤差はありますが、道を一本外れているとかは無く、通っている道は概ねトレースできているように思います
  • 実際の居場所が、スマホのアプリで確認できるまでに1〜2分ほどラグがあります
  • アプリから位置の履歴が見れますが、過去7日分保存されています
  • 使い始めて1ヶ月くらい経つと、普段の行動範囲を学習してくれて、その行動範囲から外れると通知が来るようになります
  • 通知スポットの設定で、半径距離が設定できますが、最小でもそこそこ大きいので、もう少し小さめに設定できると良いかなー
    • ただし位置の精度にも依存するので、調整が難しいのは理解できる


とまぁ、こんなところでしょうか。
それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

参考リンク

GPS BoT お子様の現在地や行動履歴を教えてくれるAIみまもりサービス

GPS BoT お子様の現在地や行動履歴を教えてくれるAIみまもりサービス

Linux で "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!"

IT Linux

Fingerprint

某所の環境で、何もしていないのに、SSHでのログイン時に以下の警告が出るようになりました！と報告を受けました。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.

・・・・・以下省略・・・・・


ほうほう、と見てみると、

# ll /etc/ssh/ssh_host_rsa_key.pub
-rw-r--r--. 1 root root 401 Nov 15 06:47 /etc/ssh/ssh_host_rsa_key.pub

今朝方、SSH (v2) 用の RSA 公開鍵が変更されているような形跡があります。

通常、SSH でリモートホストにログインする際は、リモートホストの SSH 用公開鍵をクライアントの ".ssh/known_hosts" に登録するのですが、公開鍵が変わったりすると、こうして警告が出ます。

ログを見る感じ、

Nov 15 06:47:58 hostname instance-setup: INFO Generating SSH key /etc/ssh/ssh_host_ed25519_key.
Nov 15 06:47:58 hostname instance-setup: INFO Unable to write ssh-ed25519 host key to guest attributes.
Nov 15 06:47:58 hostname instance-setup: INFO Generating SSH key /etc/ssh/ssh_host_ecdsa_key.
Nov 15 06:47:58 hostname instance-setup: INFO Unable to write ecdsa-sha2-nistp256 host key to guest attributes.
Nov 15 06:47:58 hostname instance-setup: INFO Generating SSH key /etc/ssh/ssh_host_rsa_key.
Nov 15 06:47:59 hostname instance-setup: INFO Unable to write ssh-rsa host key to guest attributes.

まるっと更新されています。

instance-setup が何か思い出せないけど、おそらく事前にログに残っていた、以下のアップデート作業に影響されているのかなぁと予想。

Nov 15 06:47:53 hostname yum[18934]: Updated: python-google-compute-engine.noarch 1:20191112.00-g1.el7

なんとなく原因のアタリがついたので、今回はこの辺で良しとします。（雑

復習: CentOS 7 系での yum 関連の自動アップデート設定について

最近ほとんど CentOS 系を触らなくなったので、メモを残しておく。

自動アップデートの設定

"/etc/yum/yum-cron.conf" の以下項目で設定されている。

apply_updates = yes

こうなっていたら、自動アップデートは有効。

アップデート対象のスコープ

同じく "/etc/yum/yum-cron.conf" の以下項目を見る。

update_cmd = default

項目の意味は、設定ファイルに書いてある通りですが、以下のような感じ。

#  What kind of update to use:
# default                            = yum upgrade
# security                           = yum --security upgrade
# security-severity:Critical         = yum --sec-severity=Critical upgrade
# minimal                            = yum --bugfix update-minimal
# minimal-security                   = yum --security update-minimal
# minimal-security-severity:Critical =  --sec-severity=Critical update-minimal

実行

あとは、デーモンとして動いていればOKって感じみたいです。

# systemctl status yum-cron
● yum-cron.service - Run automatic yum updates as a cron job
   Loaded: loaded (/usr/lib/systemd/system/yum-cron.service; enabled; vendor preset: disabled)
   Active: active (exited) since Thu 2019-09-19 08:00:13 JST; 1 months 26 days ago


今日はここまで。
それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


[改訂新版]プロのためのLinuxシステム構築・運用技術 (Software Design plus)

[改訂新版]プロのためのLinuxシステム構築・運用技術 (Software Design plus)

Linux でメモリのパリティエラー

IT Linux

※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2011/02)です。
※ 情報が古い可能性もありますので、ご留意ください。


サーバが以下のエラーを残し OS ストール。

kernel: Uhhuh. NMI received for unknown reason b0.
kernel: You probably have a hardware problem with your RAM chips
kernel: Dazed and confused, but trying to continue

該当サーバには ECC メモリを積んでいたので、おそらく2つ以上のエラーが発生し、NMI (Non-maskable Interrupt) が検出したということか。

"trying to continue" と書いてあるが、実際は2分後くらいに Reboot してしまった。
とりあえず、メモリは交換して memtest 行きですな・・・。

参考

"innodb_flush_log_at_trx_commit" について

IT

※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2011/02)です。
※ 情報が古い可能性もありますので、ご留意ください。

設定値       ログバッファ→ログファイル  ディスクフラッシュ
======================================================================
0            毎秒                        毎秒
1 (初期値)   COMMIT時                    COMMIT時
2            COMMIT時                    毎秒

innodb_flush_log_at_trx_commit が0に設定された時は、ログ バッファは1秒に一回ログ ファイルに書き込まれ、ディスク操作へのフラッシュはログ ファイル上で行われますが、トランザクション コミットの際には何も行われません。この値が1(デフォルト)の時は、ログ ファイルは各トランザクション コミットの時にログ ファイルに書き込まれ、ディスク操作へのフラッシュはログ ファイル上で行われます。2に設定された時は、ログ バッファはコミット毎にファイルに書き込まれますが、ディスク操作へのフラッシュはそこでは行われません。しかし、値が2の時もログ ファイル上でのフラッシュは1秒に1回行われます。1秒に1回のフラッシュは、処理スケジュールの発行の為100% 保証された物ではないという事に注意してください。

この変数のデフォルト値は1です。これは ACID 整合性に要求されている値です。より良い性能の為に1以外の値を設定する事もできますが、その場合1つのクラッシュの中で最大1秒分のトランザクションを失う可能性があります。もし値を0に設定すると、全ての mysqld プロセス クラッシュは最後の秒のトランザクションを消す場合があります。もし値を2に設定すると、OS のクラッシュか停電によって、最後の秒のトランザクションが消されてしまいます。 しかし、InnoDB のクラッシュ復旧は影響を受けないので、値に関係なくクラッシュ復旧は行われます。多くの OS といくつかのディスク ハードウェアはディスクへのフラッシュ操作を欺く事があると覚えておいてください。それらはフラッシュが行われていなくても、行われたと mysqld に伝える可能性があります。1の設定がしてあってもトランザクションの耐久力が保証されないという事になり、さらに悪い事に、停電によって InnoDB データベースが破損する可能性もあります。SCSI ディスク コントローラ内やディスク自体の中での、バッテリーに頼っているディスク キャッシュの利用はファイル フラッシュのスピートを上げ、操作を安全に行う事ができます。ハードウェア キャッシュ内でディスク書き込みのキャッシュを無効にする為に、Unix コマンド hdparm を利用してみたり、ハードウェア ベンダに対しての特定の別のコマンドを利用したりもできます。

注意:InnoDB とトランザクションを共に利用して複製設定内で最大の耐久力と一貫性を得る為に、お使いのマスタ サーバ my.cnf 内で innodb_flush_log_at_trx_commit=1 と sync_binlog=1 を利用しなければいけません。

http://dev.mysql.com/doc/refman/5.1/ja/innodb-parameters.html

1以外は危険ということだな。
1にしておけば、最悪OSクラッシュを招いても、ディスク上のログファイルにフラッシュされているということか。
(ログから復元できる、と。)

確認

mysql> show variables like 'innodb_flush_log_at_trx_commit';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+
1 row in set (0.00 sec)

設定

mysql> set global innodb_flush_log_at_trx_commit = 2;
Query OK, 0 rows affected (0.00 sec)

Linux で DHCP を利用するネットワークインターフェースを指定する

IT Linux

※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2011/02)です。
※ 情報が古い可能性もありますので、ご留意ください。


CentOS の話。
"/etc/sysconfig/dhcpd" に以下のような感じで指定する。

# cat /etc/sysconfig/dhcpd
DHCPDARGS=eth1

複数のインターフェースを指定するときは、

DHCPDARGS="eth1 eth2"

という感じで。

大容量ファイルのSCP転送を高速にする方法 (ver.2019)

IT Linux

Keys


9年ほど前にこういうエントリを書いたのですが、まだそれなりに見られているようなので、最近はどうなのかなーと、再検証・再計測してみたエントリーです。

↑の過去エントリにも記載しているのですが、SSH/SCP では暗号化方式（強度）によってファイル転送のスループットが変わります。

もちろん、オープンなネットワークでやるにはセキュリティがー、とか、インターナルでやるなら、そもそも netcat (nc) でいいやんー、とか、そもそも大量にファイル数あるなら、事前に固めてしまえー、とか色々あると思うのですが、本エントリではあくまで暗号化方式 の違いでスループットがどう変化するのか、それはどのくらいスループットが出るのか、を確認したログとなります。

ベンチマークで利用した環境

  • Google Compute Engine (GCE) の インスタンス (n1-highcpu-4) を2台準備しました
    • 同一リージョン、同一ゾーン、同一ネットワークに配置
  • ファイル転送時の読み出し/書き込みは、RAMディスク (tmpfs) 上に行っています
  • OS は Ubuntu 19.10
    • Linux version 5.3.0-1005-gcp (buildd@lgw01-amd64-001) (gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2))
    • OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c 28 May 2019
  • 転送するファイルは単一の2GBのファイルを使用
# iperf -c 10.xxx.xxx.12
------------------------------------------------------------
Client connecting to 10.xxx.xxx.12, TCP port 5001
TCP window size:  518 KByte (default)
------------------------------------------------------------
[  3] local 10.xxx.xxx.13 port 55778 connected with 10.xxx.xxx.12 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  9.81 GBytes  8.42 Gbits/sec

2台のサーバで iperf かけるとクラウド上の 10Gbps ネットワーク内にいるかなー、という感じ。

試してみた暗号化方式

"man ssh_config" した感じ、Ubuntu 19.10 では以下をサポートしているみたい。

The supported ciphers are:

       3des-cbc
       aes128-cbc
       aes192-cbc
       aes256-cbc
       aes128-ctr
       aes192-ctr
       aes256-ctr
       aes128-gcm@openssh.com
       aes256-gcm@openssh.com
       chacha20-poly1305@openssh.com

The default is:

       chacha20-poly1305@openssh.com,
       aes128-ctr,aes192-ctr,aes256-ctr,
       aes128-gcm@openssh.com,aes256-gcm@openssh.com

The list of available ciphers may also be obtained using "ssh -Q cipher".


"ssh -Q cipher" してみると、若干違うようですが。

$ ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com


今回は検証目的ということで、上記でサポートしている Cipher を使って SSH/SCP 通信できるように、受け側（サーバ側）の sshd (/etc/ssh/sshd_config) に以下の設定を一時的に入れています。

Ciphers 3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

# 良い子のみんなは真似しないでね...!!

ベンチマーク結果

さて、前回同様、以下のような感じでコマンドを実行しました。

$ scp -c ${cipher} ./filename username@hostname:/ramdisk/


暗号化方式ごとの結果は以下の通りです。
（ざっくりで申し訳ないですが、3回転送して中央値を取っています。）

暗号化方式 (cipher) スループット
3des-cbc 20.7MB/s
aes128-cbc 304.8MB/s
aes192-cbc 271.3MB/s
aes256-cbc 243.6MB/s
rijndael-cbc@lysator.liu.se
(aes256-cbc と同じ)		 249.9MB/s
aes128-ctr 353.3MB/s
aes192-ctr 381.4MB/s
aes256-ctr 355.4MB/s
aes128-gcm@openssh.com 503.4MB/s
aes256-gcm@openssh.com 421.7MB/s
chacha20-poly1305@openssh.com 153.2MB/s


さすがに9年前からは、かなり進化が見られる結果となりました。CPU で AES-NI がサポートされた恩恵もあるのでしょう。

上述しましたが、経路のセキュリティ要件にあわせて暗号化方式を選んでいただければとは思いますが、純粋な単一ファイルの転送スピードを見た場合は、こちらの結果となります。

暗号化強度が気になる方は、基本的に OPenSSH のデフォルト設定順である

chacha20-poly1305@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm@openssh.com,aes256-gcm@openssh.com

を意識すればいいのではないかと思います。インターナル (LAN) 内はご自由にどうぞ。

元エントリでは、scp コマンドの圧縮転送 ("-C" オプション) の検証もしていたのですが、個人的に十分な数値が出ているので、一旦割愛しますw


ということで、今日はこの辺まで。本エントリが何かの参考になれば幸いです。

それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

参考


OpenSSH[実践]入門 (Software Design plus)

OpenSSH[実践]入門 (Software Design plus)

"virsh console" 実行時に "error: Failed to get local hostname"

IT Linux

※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2011/02)です。
※ 情報が古い可能性もありますので、ご留意ください。

# virsh console vm-name
error: Failed to get local hostname

"/etc/hosts" に物理ホストのhostnameを追記したらエラーが解消された。

127.0.0.1    localhost.localdomain localhost hostname-dayo

こんな感じで。

環境変数 "http_proxy" はポート番号もちゃんと指定しないといけない

IT Linux

※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2011/01)です。
※ 情報が古い可能性もありますので、ご留意ください。


今まで、3128 とか 8080 ポートの Proxy しか使ったことなかったから、あまり気にしたことなかった。

http_proxy="http://xxx.xxx.xxx.xxx"

80 ポートへの接続だからといって、↑のようにポート番号を省略せずに、

http_proxy="http://xxx.xxx.xxx.xxx:80"

という感じで、クライアントに依存する話ではあるけど、ポート番号を明示的に指定しておいた方が良さそうだ。