八甲田 小岳～高田大岳 2014.07.29
2014/7/29。
平日の休暇を利用して八甲田登山をしてきました。
今回はいつもの大岳ではなく、小岳、高田大岳を。
スタートはいつもの酸ヶ湯温泉登山口。
さすがに登山道に雪はなく、夏真っ盛りな青々とした木々。
地獄湯の沢着。
平日ということもあり、天気は良いのですがそれほど人はいません。
地獄湯の沢の硫黄コケ。
先のところが鮮やかな赤色をしています。
さらに進み、仙人岱。
高田大岳方面、いつもは行かないこの仙人岱避難小屋のほうから行くと思っておりました。
仙人岱避難小屋。
ここから小岳方面にも行ける？と思ったのですが道がありませんでした。
おかしいな、と思いつつ引き返し。
戻って大岳方面に少し進んだところ、小岳＆高田大岳方面に向かうルートは別にありました。
そちらから小岳を目指します。
す
小岳を少し登って振り返ると、残雪が見えました。
8月になろうかという時期でも雪残っているんですね。
どこかに万年雪もあるのでしょうか。
この日見たきのこその１。
この日見たきのこその２。
舌みたいなキノコ。毒がありそう。なんて名前かな。
小岳山頂から下ると高田大岳との中間にのどかな場所があります。
ここにワタスゲも自生しているようでした。(もう種になっていた)
そしていよいよ高田大岳が見えてきました。
トリ。望遠持ってなかったのでこのサイズ。なんのトリかなあ。キノコ同様調べてみなくては。
そしてようやく高田大岳山頂。
大岳に行くよりも、小岳を経由して行く分時間もかかりますが、ここからの眺めもなかなか。
360度パノラマです。
(たしか)南部側。もう少し澄んでいたら良かったのですが、それでも素晴らしい眺望でした。
また、景色も凄かったですがトンボの量が凄まじかった。
ここまでの写真を拡大してみてもらうとわかりますが、トンボが写ってない写真はないほどｗ
山頂での眺望を満喫したところで引き返します。
帰りも小岳を経由しなければならないのがなかなかハードなルートです。
この日見たきのこその３。
下山し、酸ヶ湯温泉につかり。
ちょうど丑湯祭りということでなんか踊っておりましたよ。
岩木山でミチノクコザクラに出会う 2014.07.13
またもやしばらく更新をサボってしまっておりますね。はい。
お出かけネタやら写真をブログにすることだけを考えても10エントリーは軽く超えるほど、たまっております。あ、いや写真だけたまっていて記事は全くためておりません(汗)
年末までにネタをひと通り捌きたい、とか思ってますが…
そんなところでまた数ヶ月前のネタから。
2014/7/13。岩木山登山。
この日の天候は少々曇り。雨が少し心配されるような雲行きの中、獄温泉から登山開始です。
今回の登山の目的はここ岩木山にしか咲いていない固有種「ミチノクコザクラ」を観る、です。
いつもの入り口近くにある神社。
無事に登山が終わることを祈ります。
途中の森林。
湿度もありなんか天然のアロマを感じる、そんな景色の中を進みます。
八合目までが結構長い。
2時間30分ほどかかったでしょうか、八合目着。
山頂方面を眺めると霧が濃い。
かろうじて山頂が見えている感じです。
八合目の休憩所にて腹ごしらえなどをしつつ休憩。
30分ほど休んだでしょうか、いよいよ山頂に向けて出発時、休憩所前の足洗い場の排水口に違和感が。
なにやら泡…？
なんと中にか、カエルが！
この泡の正体はカエルのタマゴだったようです。
休憩所の売店の方に聞くと毎年ここに棲み着くそうです。
不思議ですね…。来年ももし行くことがあれば覗いてみようかと思います。
ちょっとしたサプライズがありつつも山頂へ向けて進行。
九合目あたりに来ると、火口に残雪が。
7月でも残ってるんですねえ。
そして名物の九合目からの急な崖。
天候が悪いのでいつもより一層急に見えました。
そして…
初めて鑑賞することができました、ミチノクコザクラ！
九合目から少し先の種蒔苗代近辺に咲いております。
今回はこれを見たくて登りました。
レアな白いミチノクコザクラも！
ただ少し花が傷んでました。
雨風にやられたのでしょうか。
それでも元気に咲いておりましたよ。
山頂からの眺めは霧が濃くイマイチ、さらに下山途中にかなり雨が降ってきまして、帰りは八合目まで降りたところで徒歩での下山は諦めバスにより獄温泉まで下山。こんな日もあります。
まあ今回の登山の目的が達成できてよかったです。
田舎舘田んぼアートと革秀寺の蓮の花とインドリアと倉崎
2014/07/26。
弘前方面に軽くドライブ。
途中、田舎舘田んぼアート(第一会場)に立ち寄り。
今年は天女と富士山？なかなか見事なものです。
ここ数年のものに較べると、ずいぶんとシンプルに感じました。
そして田んぼアート側から見た、田舎舘城天守(役場ですけどｗ)
田舎舘田んぼアートは第二会場もあるのですが今回はほかに行きたいところがありましたのでスキップ。
今回はお寺ではなく、その前にある蓮池見学が目的。
蓮の花。ちょうど見ごろに見ることができたようです。
白い蓮も綺麗ですね。
後日(八月のお盆頃)も通りかかったので見たのですが殆ど蓮の花が終わってしまい、種になっていました。
お盆前のこの季節がちょうどいいかと思います。
しかし蓮の葉の緑が眩しいくらいの日差しでした。
一気に汗だくに。
弘前市紙漉町にあるインドリアさんで昼食。
肉を一切使わないべじごはんが売りのお店です。
玄関にはこんなねこちゃん？がお出迎え。
店内のメニュー。
このべじごはんがメインです。他にもロコモコなどもありました。
店に置いてあったブッタの本が面白かったｗ
べじごはん。
個人的に気に入ったのはおからハンバーグ。ほんと、おからだと言われないとヘルシーなハンバーグだな？くらいにしっかりとハンバーグしてました。
また白菜をポタージュにしたスープも胃にやさしいぞ～、なお味でなかなか。
これらの料理は真似してみたいですね。
プラス300円くらい？でデザートとアサイードリンクもつけることができます。
このデザートがなかなかしっかりしていて食べ応えあり。逆にデザートを付けないと男性だと少々物足りないかな？です。
晩御飯にはこれまた弘前市の倉崎でラーメンを。
きびだんごも売ってるちょっと変わったラーメン屋さんです。
ただ新米ができるまできびだんごはおやすみだそう。
ももつながりでこんなやつも店内にいたり。
はたまたビクターの犬？インテリアがちょっと面白い。
これがお店の看板メニューの白菜ラーメン(の、辛いやつ)。
かなりボリューム感たっぷりでした。味も白菜のうまみが出ていてなんともいえない独特な感じ。
近場にいたら通っちゃうかもしれません。
以上、ぷらからドライブ報告でした。
(タイトルがそのまま過ぎて申し訳ありませんでしたｗ)
HD PENTAX‐DA 21mm F3.2 AL Limited
カメラレンズを追加しました。
HD PENTAX‐DA 21mm F3.2 AL Limited
K-01持ち歩きにコンパクトで広角なレンズが欲しくて。
手持ちのレンズが標準～中望遠なレンズしかなく街ぶらぶら撮影にはちょっと使いづらいと思ってましたので…
これをつけっぱなしにして、必要に応じてDA40㎜XSやDA50㎜F1.8を懐に忍ばせておこうと思います。
広角で使いやすい画角で、AF速度もそこそこ、マクロほどではないですが近寄っての撮影もできますのでこれ一本で結構いい感じなのでは、と思います。
しばらくこれを持ち歩きたいと思います。
浅虫花火大会観てきた
2014/8/1。浅虫の花火大会を観てきました。
青森ねぶた祭り最終日の花火は何度か観たのですが、浅虫のは初めてです。
行きはスムーズに行けましたし、観る場所を選べばゆったり観れて良い感じです。
また来年も観れたら良いな。
Redmine0.9.1(CentOS5.8上)→Bitnami Redmine Stack2.5.1(Windows)に移行＋Bitnami添付のSubversionへのデータ移行まとめ
※はてなブログの見たまま編集モードで記事投稿した後にはてな記法に変更しようとしたら、どうやらできないらしい！ひどい。。。
整形がぐちゃぐちゃだったので新規エントリで投稿しておく。この前の記事と順番が前後しているけど気にしないことにしよう。備忘録的なもんだし。
サーバ退役を契機にRedmine(on CentOS)をBitnami Redmine Stack(for Windows)というAll-in-oneなパッケージに移行しました。
移行の際、文字化けやらログインできない問題やらいろいろ遭遇しましたので、メモとしてまとめておきます。
自分用メモ(と言って整形するのめんどいなあというのをさらっと言ってみるｗ)。
１．データベースバックアップ
CentOS上でcronバックアップを1週間ごとに実施していました。
mysqldump -u root -h localhost redmine > $backups_dir/$today_str/redmine_mysql.dump;
しかし、このバックアップダンプ、中身をテキストエディタで見ると日本語が化けている。
そのため以下のようにして「--default-character-set=binary」オプションを付加してバックアップするようにしたところ、テキストエディタで日本語がきちんと読める状態になりました。
mysqldump -u root -h localhost --default-character-set=binary redmine >$backups_dir/$today_str/redmine_mysql.dump;
２．(注)リストア時の文字化け
ただこのダンプデータを新サーバのMySQLに突っ込んだところ見事に文字化け。
C:\Bitnami\redmine\apps\redmine\htdocs>mysql bitnami_redmine --user=bitnami --password=xxxxxxxx --default-character-set=utf8 < redmine_full-backup.dump
日本語は問題なく書き込まれているのになんで？
と思ってダンプの中身を見てみると、こんな記述がありました。
CREATE TABLE `attachments` ( (中略) ) ENGINE=InnoDB AUTO_INCREMENT=1549 DEFAULT CHARSET=latin1;
テーブルのCHARSETにlatin1を指定している。。
これはいかにも文字化けしそうです。
http://www.goodpic.com/mt/archives2/2009/01/mysql_41_50mysq.html
参考にしてLinuxサーバ上で
$ perl -pi -e 's/latin1/utf8/' redmine_full-backup.dump
をかましてlatin1という文字列を無理やりutf8に変更。
この変換したダンプファイルをBitnamiのMySQL上に突っ込んでやったら文字化けが解消しました。
※詳しく調べていませんが、移行元のLinuxのサーバ上のMySQLの設定がおかしいためにそんな挙動になっているのではないかと。
移行元のMySQLの設定
mysql> show variables like '%char%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | latin1 | | character_set_connection | latin1 | | character_set_database | latin1 |←これ | character_set_filesystem | binary | | character_set_results | latin1 | | character_set_server | latin1 |←これ | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+
このあたり？このまま運用していた私が悪かったのかもです…。
そして移行先(Bitnami Redmine)のMySQLの設定
mysql> show variables like '%char%'; +--------------------------+------------------------------------------+ | Variable_name | Value | +--------------------------+------------------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | C:\Bitnami\redmine\mysql\share\charsets\ | +--------------------------+------------------------------------------+
移行元のDBのcharacter_setをutf8にしていればこんな問題はおきないんじゃないか？と思います。
３．マイグレーション実行
データベースを流してやったらマイグレーションの実行です。
C:\Bitnami\redmine\apps\redmine\htdocs>ruby bin\rake db:migrate RAILS_ENV=production
しかしここでもハマりポイントが。
なんか既にテーブルがある系のエラーが3種類ほど出ました。
changeset_parents
custom_fields_roles
queries_roles
あたりが既に存在するエラー。中身が空であることを確認してdrop tableし、再度マイグレーション実行でOK。
(参考)
http://d.hatena.ne.jp/rabbit2go/20140309/1394374120
その後、上記サイトの通りにセッション情報をクリアしました。
ruby bin\rake tmp:cache:clear ruby bin\rake tmp:sessions:clear
４．移行先のRedmineにログイン出来ない…
素の状態でのBitnami Redmine Stackではadminユーザでログインできたのですが、上記マイグレーションを実行したところ、移行元のadminユーザのパスワードではログインできない状態となってしまいました。これは原因がよくわからないのですが、パスワードのHash値生成の仕組みが異なるから？
よくわかりません。
とにかくログインできないと先に進めませんので、adminパスワードを初期化する方法を検索。
http://redmine.jp/faq/administration/reset-admin-password/
上記にありました。
Bitnamiの場合は以下のようにしてコンソールを起動。
C:\Bitnami\redmine\apps\redmine\htdocs>ruby bin\rails console production
irb(main):001:0>admin_user = User.find_by_login('admin')
irb(main):002:0>admin_user.password = 'xxxxxxxx'
irb(main):003:0>admin_user.save!しかしさらにここでもエラー。。
ROLLBACK ActiveRecord::RecordInvalid: Validation failed: Email notifications is not included in the list
正直このエラーもまったくわかっていないのですが、Railsのバリデーションという値チェックで引っかかっているようです。
C:\Bitnami\redmine\apps\redmine\htdocs\app\models\user.rb
の中にある
MAIL_NOTIFICATION_OPTIONS = [ ['all', :label_user_mail_option_all], ['selected', :label_user_mail_option_selected], ['only_my_events', :label_user_mail_option_only_my_events], ['only_assigned', :label_user_mail_option_only_assigned], ['only_owner', :label_user_mail_option_only_owner], ['none', :label_user_mail_option_none] ]
のリストに含まれていないということらしいです。
(Redmineのメール通知設定のあれでしょう)
そして
validates_inclusion_of :mail_notification, :in => MAIL_NOTIFICATION_OPTIONS.collect(&:first), :allow_blank => true
このmail_notificationはblankを許容する、ということで
irb(main):004:0>admin_user.mail_notification = '' irb(main):005:0>admin_user.save!
とすることで無事にadminのパスワード初期化が出来ました。。
(Rubyに詳しいお方にだいぶ助けていただきました。。)
これでようやくadminでRedmineを利用することができるようになりました。
admin以外のユーザも何故かログインできない状態になっていました(上記のメール通知の仕組みが引っかかっているのか、パスワードのHash値が合わないのかはわかりません…)ので、各ユーザのパスワード設定をRedmineの管理画面から初期化し、無事に移行完了。。
半日くらいハマってしまいましたが、MySQLの文字コードには気をつけなければ、など良い経験になりました。
(おまけ)
Subversionのデータ移行(Subversion 1.6.5 Linux→Subversion 1.8.5 Windows Bitnami添付版)
Bitnami Redmine Stack上のSubversionデータ移行も合わせておこないました。
こちらはそれほどハマることもなく行きました。
１．データバックアップ
データバックアップ、Subversionはデータがデカいので
・週次：フルバックアップ
・日時：差分バックアップ
としていました。
svnadmin dumpコマンドを利用します。
Subversion実践入門の書籍に書いてあったそのままなので割愛します。
Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版)
- 作者: Mike Mason,でびあんぐる
- 出版社/メーカー: オーム社
- 発売日: 2007/04/21
- メディア: 単行本（ソフトカバー）
- 購入: 35人 クリック: 672回
- この商品を含むブログ (103件) を見る
２．間引き
長年Subversionを利用していたのでかなりデータが肥大化していました(tar.gzで6GB…)Subversionは履歴も全て保存されますので、データは増えることはあっても減ることはない。これではバックアップも大変だ、ということで大きなデータを探って間引くことにしました。
-bash-3.2# du -m /home/svn/repos/db/revs/* |sort -nr | head -n 20 473 /home/svn/repos/db/revs/1234 ... ...
これでデータのデカいコミットベスト20が出てきます。
そのコミットのリビジョン番号(上記だと1234)に相当するコミットおをsvn logコマンドなどで確認し、どこが大きいのか突き止めます。
大抵どこかのプロジェクトが大半をしめているのですよ。
(バイナリを登録していたりね…あほかｗ)
今回の場合、1プロジェクトがリポジトリの半分を食っていることがわかりました。
間引きはこのあたりを参考に。
http://dqn.sakusakutto.jp/2012/06/subversion_svndumpfilter.html
>svndumpfilter exclude /trunk/images/dekaiyatu < old.dump > new.dump
これでdekaiyatu配下のコミットはごっそり消えてなくなります。
(消した部分のリビジョンは空コミットとなりますのでリビジョン番号が若返ったりはしませんでした)
３．データリストア
> svnadmin load E:\SVN_Repo < svnYYYYMMDD.dmp
でリストアの途中、エラーでコケました。
svnadmin: E125005: Invalid property value found in dumpstream; consider repairing the source or using --bypass-prop-validation while loading. svnadmin: E125005: Cannot accept non-LF line endings in 'svn:ignore' property
ググってみると同じ現象の人発見。
http://shinsuke789.hatenablog.jp/entry/20120713/1342162178
改行コードで引っかかっている模様。たしかにリストアでコケたリビジョンのコミットを元サーバで検索してみるとコミットのコメントに改行コードが使われていた。
このエラーに出ているまんま「--bypass-prop-validation」設定して
> svnadmin load --bypass-prop-validation E:\SVN_Repo < svnYYYYMMDD.dmp
としたら無事貫通。
ユーザ認証などはいろいろなスタイルがあるので割愛しますが、私の場合httpasswdによる認証をとっていたのですが、Linux:crypt Windows:MD5となっており、htpasswdファイルを流用できなかったようです。
結局パスワードは全て設定しなおしました。
htaccess認証などはほぼそのま流用できました。
やるとわからないことが結構あるのと、グーグル先生に聞けば結構ヒントが得られるなあ、と改めて感じました。
