[linux]fedora 16 to 17 アップグレード

自分のブログからの転載
--------

先月末位にfedora 17のβがリリースされた。
もうそろそろ、fedora 17本リリースされるだろう。fedoraは過去2バージョンしか保証されない（リポジトリがなくなるかもしれない）ので、ベータ出たら一応アップグレードはしてる。
どうせ個人使用だし。

2012/5/13時点は、
#uname -r
3.3.4-4.fc17.x86_64
kernel は、たぶんfedora 16の最新版とメジャーバージョンは同じ、、はず。

非力なノートに入れてるF16が、最近無線LAN周りでエラー吐くようになった。
調べてみるとカーネルの問題みたいなので、ものは試しで入れることに。
うまくいけばサーバ用にも適用しようと。

いままでfedoraのアップグレードは何回かやってきてる
・f11→f12は、初体験でgnomeからやって(runlevel=5でやって)固まり結局いれなおし
・f12→f13は、サーバ側のccidのバグなのか何なのかでテレビ見れなくなってヒヤ汗
・f14→f15は、成功するもののアップグレードのgnome3に戸惑いまくり
・f15→f16は、kernel3で不安になって結局アップグレードではなく新規インスコ
と、さしてや難しくないアップグレードにはなんか恵まれない

今回
ノート 32bit
途中までうまくいったものの仕上げでrunlevel=2にするのを忘れてフリーズ。
中途半端でやったのでインスコ失敗。gnome3を捨てCentOS6に移行

デスクトップ 64bit
ノートの失敗を踏まえてこちらは成功。

----

f17は、アップグレードは難しい(単純にfedora-release / yum upgradeじゃできない）。
そもそものファイルシステム構成を変更してアップグレードの必要がある。
カーネルが2系→3系になった、fedora15 -> 16より多分インパクトあると思う。

基本的には
Upgrading Fedora using yum fedora 16 to 17
ここにすべては集約されてます。
（以下、例によって自己責任で）

前準備：
（筆者は、fedora 16 -> 17のアップグレード中に（rpm -Uhv fedora-release | yum upgrade の後にやって成功しました。以下手順の6. から開始して、失敗して1. に戻った。）やって、特に問題なくできました。が、多分前もってやった方がスジとしては正しいんだろうと思う。）

まずは、Fedora 16 -> Fedora 17　の欄を参考にして、まずはファイルシステムを移行する必要があります。
（この作業は慎重にやってください。たぶん、失敗したら起動しなくなると思います）
こここでの記載によると、fedora 15で導入された systemd という、/etc/init.d/xxx に変わる各サービスの起動方法の変更を本格採用するらしい。
例：sshdだったら
過去：/etc/init.d/sshd restart
今後：/bin/systed start sshd.service
/etc/systemd/system 以下にスクリプト(のショートカットがある）ので、これを参照するようになる。

それと関係して（と言ってるけどホント？）、ファイルシステムが大きく変わる。
具体的には以下のパスがこんな風になる。
/bin → /usr/bin
/sbin → /usr/sbin
/lib → /usr/lib
/lib64 → /usr/lib64

これをやらないと、fedora 17にはできません。

もちろん、ファイルを手動マージなんてしたら多分怖いので、参考のファイルシステム変更方法が書いてある。
dracut パッケージを使う
（これは今でも入ってて、カーネル起動時とかに使ってるはず。これのインスコの失敗で、過去アップグレードに失敗したことがある）

ちなみに以下をやると、fedora 16のままにはできない。
ファイルシステム変更したら即fedora 17にしないといけないので注意。


1. 次回起動時に、file systemの変更をしてくれるようにと依頼する。
# dracut -H --force --add convertfs

2. カーネル起動時のパラメータの修正
　/etc/grub2.cfg を修正する。

- remove “ro” (read only)
- append “rw” (read write) to let dracut mount your root filesystem writeable
- remove “rhgb” (Red Hat graphical boot) to disable the graphical bootsplash
- append “rd.info” to get a more verbose output from dracut
- append “rd.convertfs” to enable the /usr-move conversion script in dracut
- append “enforcing=0” to disable SELinux enforcement

とあるので、以下の"linux "で始まる文（要するにgrubメニューの一番上（もしくはカスタムカーネルにしてるならその行を探して））以下のように変更。

linux /boot/vmlinuz-3.X.X-XX.fc16.x86_64 root=UUID=6e966b10-b03a-4a9c-8df3-c35e2744b3ae ro rd.md=0 rd.lvm=0 rd.dm=0 quiet rhgb rd.luks=0 LANG=ja_JP.UTF-8 KEYTABLE=jp106
↓
linux /boot/vmlinuz-3.3.4-4.fc17.x86_64 root=UUID=6e966b10-b03a-4a9c-8df3-c35e2744b3ae rorw rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 LANG=ja_JP.UTF-8 KEYTABLE=jp106 rd.info rd.convertfs enforcing=0

要するに
・グラフィカルの起動をやめて
・カーネルの起動を読み書き可能にして
・dracutにパラメータを与えて
・selinuxを無効化する。
（グラフィカルの起動云々は別にしても、まぁ、一度失敗したら起動しなさそうな感じなので、十分な気を遣うこと）

3. 恐る恐る再起動
# reboot

起動時に、dracutがファイルシステムの移行をしてくれる。
/bin -> /usr/bin
に移行したりする旨が出てくる。
エラーがなく終了して、起動すればOK。
心配なら↓のコマンドを打って（カーネル起動メッセージ）、エラー出てなければOK。
# dmesg | grep dracut

（この先は慎重にやってください）
4. カーネルパラメータを戻す。
　→これをやらないと、次回起動時にまたdracutによりファイルシステム移行が走るので多分ぐちゃぐちゃになると思う。絶対やること。

2. でやったうちの、
- append “rd.info” to get a more verbose output from dracut
- append “rd.convertfs” to enable the /usr-move conversion script in dracut

これは消さないとダメ。他はどっちでもいいと思う。

linux /boot/vmlinuz-X.X.X-X.fc16.x86_64 root=UUID=6e966b10-b03a-4a9c-8df3-c35e2744b3ae rorw rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 LANG=ja_JP.UTF-8 KEYTABLE=jp106 rd.info rd.convertfs enforcing=0

5. ファイルシステムの確認
/bin/
//sbin/
/lib
/lib64
とかがシンボリックリンクになってれば、無事成功。
ただし、fedora 17へのアップグレード（以下6. ）をやらないで起動すると多分起動しない。

6. fedora 16 -> 17へのアップグレード
　ファイルシステム変更して、再起動する前にやることを強く推奨。
　　1. から順にやってきた場合は、前もって、fedora-release-17xx.rpmはとってきておいた方がよいです。

6-1. 本体バージョンアップ
# rpm -Uhv fedora-release-17(取ってきたやつ).rpm
# rpm -Uhv fedora-release-rawhide(取ってきたやつ).rpm
　fedora-release-17
　fedora-release-rawhide
　は、技研とかから取ってきてください。

6-2. ランレベルの変更
普通は起動時にctrl + alt + F2 で変更できる
（みたいだけど、私はなんか無理だったので、/etc/inittabを参考にシンボリックリンクを変更した。）
※runlevel=5とかでやると今回は固まった。リモートsshか、ランレベル２でやることを強く推奨します。


6-3. ファイルアップグレード
コンソールから以下を打つ。
# yum update yum
# yum --releasever=17 disableplugin=presto --skip-broken distro-sync
だいたいβはリポジトリまとまってないので、--skip-broken をつける

※ファイルシステムを変更してない場合、
rpmlib(X-CheckUnifiedSystemdir)is needed by filesystem-3-2.fc17.x86_64
rpmlib(X-CheckUnifiedSystemdir) is needed by setup-2.8.48-1.fc17.noarch
と出ると思うので、この場合は1. からファイルシステムを変えて、再度実行すればできます。（私はその方法でうまくいきました。）

一応これで、fedora 16 -> 17(64bit)は成功。
# cat /etc/redhat-release
Fedora release 17 (Beefy Miracle)
# uname -r
3.3.4-4.fc17.x86_64
で、OK。

＃起動画面は 花火が上がってる。和風な感じがしたのは私だけだろうか。

もちろんfedora 17がもうすぐリリースされるのでそれ待ってもいいかもしれません。
が、ファイルシステムの移行は必須です。
個人的には、大きなリスクを追ってまで、無理にすることもないような気はします。

fedoraは15くらいから（たぶんUbuntuも11.04くらいから（？））gnome3の採用 -> kernel3 の採用 -> /usr/以下のファイルシステムの移行、などあまりにも急進的なことやってるので、無理にアップグレードしないでCentOSに移行してしまうのも一つの手です

プログラマーの仕事について回る「文書作成」�@

ブログの更新もすっかり久しぶりになってしまいました。。。

私も１０年近くこの業界におり、ベテランといわれるような年になってきたわけです。
そこで、今回から、プログラマーの仕事ってどんなものなの？といったようなことについて、
後輩の方々に参考になるような記事を書いていこうかと思います。

今回は、プログラマーの経験に必ずついて回るような、「ドキュメント」について
少し書いてみようと思います。


＜プログラマーは、ただプログラムを書いているわけではない？＞

ＳＥやプログラマーの仕事というのはいつもプログラムを作成しているようなイメージがありますが、そうでもありません。
実は、「文書作成」のウエイトがかなり大きいものです。
（我々の間では「ドキュメント」という形で言うことが多いです。以下、「ドキュメント」という言葉を使っていきます）

ドキュメントといっても、いろいろ種類があります。
たとえば我々の仕事で言うと、このようなものがあります。
（職場によって、いろいろ言い方には差異があると思います）

・議事録
　→お客様との間での打合せや、社内での打合せでの決定事項をまとめたもの。
　　だいたい、駆け出しのころは必ず書く資料ですね。

・設計書、仕様書
→最終的にプログラムを作成して動くものを提供する、という過程で、各工程のインプット資料／アウトプット資料になるもの。
　プログラムを作成するときのインプットになる資料です。
　工程によって記述内容はかなり変わってきます。　

（※設計書・仕様書という言葉の使い方については、かなり人それぞれです。
　　たとえば自分では、
　　　・プログラムがどう動くのか、画面にはどう表示されるのか、という「使う人から見たふるまい」を定義したもの→仕様書
　　　・仕様書をもとに、内部的なつくりを記述したもの→設計書
　　という感じで使い分けていますね。

　例：「画面仕様書で、画面でどう動くのかを打合せで決定し、お客様の了解を得た」
　　　「画面設計書で、画面仕様書をもとに画面におけるプログラムのインプット・アウトプットを定義した」

・要求定義書
　→お客様のやりたいことを、文書レベルで記載したもの
　　「こうしたい、ああしたい」というような、お客様の頭の中で思っているような「絵に描いたもち」を、 文書にしたものと考えるとよいでしょうか。
　　よく絵や図を使用することが多くなる設計書だと思います。
　　（システムのことがわからないお客様にも直観的にわかるようなものにするため）

　　文章の性質的に、そのためある程度の経験がないと、作ることが難しい資料だったりします。
　　お客様と仕様を詰める力が必要になってきます。

・プロジェクト報告書
　→上で書いてきたものがお客様に対してのものであれば、これは社内の人への説明資料となります。
　　だいたい、今月（年だったり週だったりします）に、どんなプロジェクト運営がなされていたか、ということを
　　社内の上司や先輩に報告するための資料です

　　・このプロジェクトは今月何パーセントの黒字だった（赤字だった）
　　・このプロジェクトの状況は今月どんな感じだったか
　　・プロジェクトの人員の稼働はどれくらいか（残業が多すぎないか？士気は？）
　　・全体としてどれくらいの進捗率か。

　といったことが書かれてくると思います。
　（来年度から、工事進行基準による会計が我々の業界でも使われますが、その際月単位で見たときどうなのか
　ということののウエイトが非常に高くなってくると思います。また機会があれば調べて、説明したいと思います）

・・・などでしょうか。

実は「プログラム」も、ソースコードは人にわかりやすく記述する必要があるので、「ドキュメントの一種である」 ということをいう人も結構いらっしゃいます。
そういう意味では、常に「ドキュメントを作っている」という業種であるともいえるでしょうか。


＜ドキュメントってどんなものを書くの？＞

では上の中から、今回は「議事録」についてピックアップして、どんなことを書くのかを経験をもとに書いてみようと思います。
（経験のある方はいくつか意見があると思いますが、コメントなどで残していただければうれしいと思います）

・議事録

　　上でも書きましたが、「だいたいのプログラマーが最初に作成する資料」だと思います。

　　何が決まったかということを記録に残すというのは、われわれの業界でも一つの技術でもあります

　　例：
　　たとえばプログラムを作成するとき、お客様とやり取りをしていて、
　　「何がきまったの？これは言ったの？言わないの？こういう動作じゃなかったの？」
　　と突っ込まれたとき、
　　「いやいや、これはここでこう決まった（決めていただいた）じゃないですか」
　　というためのいわば「証拠」になるわけです

　　また、お互いに議論に夢中になり、結局何が決まったか、ということが落ちてしまうことも多々あります。
　　そういうときに、「ああ、こう決まったんだよな」ということが残る「資料」ともなるわけです。

　●記述するレベル
　　どこまで書くの？というと、打合せの性質しだいにもよりますが、だいたいが
　　上にあげたような性質から「決定事項だけ」、を簡潔に残すというのが多いのではないかと思います

　　また、少し砕けた会合の場合は、雑談レベルまで残すという場合もありますし、
　　誰が何を発言した？ということまで詳細に残す方もいらっしゃいます

　　いずれにしろ、
　　　・決まった事項は何か？
　　　・誰が、いつまでに、何をやるのか？（その後のアウトプットにも関連してきます）
　　　・後になって、出席者間で「言った、言わない」ということを防ぐ
　　　・出席していない人でもわかるようにする

というような位置づけがあるのではないかと思います。


今回は、
　・ドキュメントと言われるものの種類
　・ドキュメントのうち「議事録」にピックアップ
して説明してみました。

次回は、プログラムを作成するためにインプットとなってくる、「設計書／仕様書」について、書いていこうと考えています。
それでは。

柳下＠Mcube

PHPから各種ウェブサービスにアクセスするためのライブラリ集 2008年2月版

覚書
http://phpspot.org/blog/archives/2008/02/php_20082.html

簡単にWebサービスにつなげるＡＰＩがあるのは便利デスネ。

ちなみにPEARライブラリとしてなので、すこし敷居は高いですが。

20080130-01 開発自動化

【特選フリーソフト】生産性の高いWeb開発環境 Ruby on Rails 
http://itpro.nikkeibp.co.jp/article/COLUMN/20060424/236113/
最近巷で噂のruby on rails。

設計即ソース吐き出し、実行できる、というのは開発者の永遠の望みだったりするし、
管理する側でもコストダウンを図れるため効率的な方法だとされています。

この点で少し社内で話していたときに、こんな記事がありました。

カテナ、旧システムをソフト開発方法論『Lyee』のプログラム構造に自動変換する体系などを発表
http://ascii24.com/news/i/soft/article/1999/11/09/605453-000.html

これは２０世紀の記事です。
だいぶ前から開発自動化の考えがあったのですね。

しかし、いまだに新開発手法がどんどん生まれているということは、自動化というのが
いかに難しいか、ということをある意味婉曲的に示しているともいえるでしょう。

実際開発をやってみるとわかりますが、自動化というのはなかなか難しいものです。
作る過程でも複雑な業務ロジックを組み込まなければならないわけですし、
さらに作った後でも追加要望や拡張などは当然あるものです。
そこまでカバーしていく、というのはなかなか簡単な開発自動化ツールだけでは
難しいでしょう。

そんなことから、開発自動化には、必ず限界がある、というのが私の考えです。
（前に所属していた会社でもよく言いきかされてきました。）
しかしだいぶ前からこれほどの自動化プロジェクトがあったのだとしたら、
業務知識をバリバリに蓄積することにより、ビジネスチャンスはあるのかもしれない、
のですかね。

。。実際に適用するのはかなり難が必要だとは思いますが。

Mr.Kappa@mcube

20080129-01 受験戦争

http://www.chunichi.co.jp/article/living/life/CK2008012902083200.html

公立の中高一貫教育校ができた、というのはずいぶん前に話は聞いていましたが。。。
最高二十七倍。軒並み五−十五倍　とはすごい人気ですね。

しかし今の時代少子化になり、大学ももう無受験時代が近づいているというのにもかかわらず
これだけ人気が集中する学校が出てしまうと、学校間の格差が大きくなっているのではないかと気になります。
公立の中高一貫が私立の中高一貫に刺激を受けてできた、というのにも関わらず、
かえってそれが受験戦争を白熱化させているというのは、なんとも皮肉なものですね。

お役所としても、受験というものについて、考える時期が来ているのではないでしょうか。
いっそのこと、少子化が進んで最終的に無受験になるのだとしたら、入学枠をもっと広げて、
大学でしっかり学ばせ、大学の卒業を厳しくする、などの手段をとるようにする、ということに力を入れることの
ほうが、国にとっても良いことだと思うのですが。

寒い日々が続き、会社に来てお湯を沸かして暖を取るような感じです。
受験生の皆さんも風邪にはくれぐれも気を付けてください。

柳下＠ＭＣ

20080121-01 受験シーズン

1/19. 1/20はセンター試験でした。受験生の方々はお疲れ様でした。

私は東大とかの大手大学には全く無縁でしたが、やはり気にはなるみたいで。
そこでこんなのを調べてみました。やはり今の世代の学力というのは気になるので。また後輩ともなる人の力も遠まわしに知ることもできるし。
http://ja.wikipedia.org/wiki/%E6%9D%B1%E4%BA%AC%E5%A4%A7%E5%AD%A6%E3%81%AE%E5%85%A5%E5%AD%A6%E8%A9%A6%E9%A8%93

東大の入試ですが、文系にも数学を重視している点は私は妥当だと思いました。
数学的思考（論理構成力ともつながってくるはず。高校数学レベルの論証問題は良問だと思う）を重要視しているところはさすがだなと思います。
（まぁわれわれプログラマーでは当然の技量なので、こういう試験は重要だと思いますが）

＞短時間で多量の情報を処理させ、簡潔に表現させる。
＞一部の私大で問われるようなマニアックな単語や知識を問われることは少ない。むしろ易しい英語の運用能力を試される。

これはいかにも情報化社会を反映する良い試験ですね。

仕事をしているとよくわかりますが、今はネットワークの整備により昔とは雲泥の差で通信が行きかう。
それにより、いろんな人が得られる情報量がはるかに多い。
これは一般にも言われていますが、ビジネスの世界に立っているとそれがよくわかります。
やはり、目指す人材は大学でも振り分けているものなんですね。

少し話は逸れますが、学生の皆様もそうですが、今後社会を目指す方々は、この「情報の見極め技術」を身にぜひつけておいてほしい。

もちろん、これから入試シーズンでもある上に、就職活動シーズンでもあります。
就職を乗り切ったあと、さらに待ち受けているのはこの「大量の情報量」。
就職を乗り切っただけではなく、そのあとのビジネスマンとしての生活も充実させていくためにも、身につけておいてほしい。

私はいいなと思うのは、ひとつのニュースをピックアップして、ブログなどで紹介し、さらにコメントを自分なりにつけること。

ニュースをピックアップするというのも一つの技術です。
今世間では、何が重要になっていることか。かつ、それを自分でくみ上げられるか。
それを見極めるだけでもかなりのトレーニングになると思います。
おまけですが、それに対する意見を自分でつけるという訓練にもなりますので、プレゼンテーション技術の向上にもなります。
もしよかったら実践してみてください。
＃私も結構やったりしています。最近はサボってますが。

寒くなりますが、受験生、就職を目指す皆さん、がんばって。

＃久しぶりに書く内容は意外と普通ですね。もう少し頻繁に書きたいところです。

柳下＠ＭＣ

20080117-01 RAID

http://storage-system.fujitsu.com/jp/term/raid/01.html

メーカーサイトですが、RAIDについての説明記事がなかなかわかりやすい動画があったので紹介。

特にRAID4〜6のパリティの構造についての説明がなかなかわかりやすいので良いと思う。

20080107-1 去年の@ITの年間ランキングを見てて。

http://www.atmarkit.co.jp/news/200710/31/ipa.html

この記事が、去年の@ITニュースの年間のランキング２位だったとか。

"7K"など、突っ込みどころは満載な記事で、よく現役学生でIT業界志望の人間にも読ませたことがある。

 

＞イメージを聞かれても、そのイメージ自体が何もないという皮肉な答えだ。

。。反論すれば、学生にもある程度調査してほしい、という気もするが。。

とはいえ、我々が発信する側にならなければならない、というのは確かではあるがね。

 

もっとわかりやすく、我々の興味が何を向いているのか。

といったことを示すというのも、ひとつの手ではあったりすると思います。

何か作ってみたとか、何か調査してみたとか、OSをインストールしてみたときの導入記を書いてみるとか。

 

このブログを見ている人たちに、私の向いている方向は何か、といったことを示せるような場にしていければ

おもしろいかもしれません。