湿気高すぎて死にそうです。あづいぃぃぃぃぃ
ブログのお引っ越しを敢行しましたが、見事に記事の作成日時が反映されずに、インポート時の日時となってしまいました。
そんなに記事の数も多くないし、そこのトラブルシュートに費やす時間もないのでこのままでいきたいとおもいます。ｸﾞｰﾀﾗ
以上、明日からまたよろしくです。
// nagamee
2015/06/24
yum-cronでyum updateを自動化してみた
パッケージの脆弱性が発表された場合、運用顧客のサーバが該当しているとアップデートをかけて脆弱性には早め早めで対応する。最近だとglibcの脆弱性(GHOST)が記憶に新しい(そこまで騒がなくても、という内容ではあったけど）。その場合は、もちろん該当するパッケージのみアップデートしてやる。ほかのパッケージをアップデートしてサービスが動かなくなったりしたら恐いわけで。
自宅環境の場合、正直にいうとパッケージ管理まであまり意識できていない。気づいたら都度あげる程度。そもそも自分で定期的にチェックして必要なパッケージを更新するなんて面倒くさい。ただ、それでも脆弱性のあるパッケージを放置しているほうがよろしくない。せめて、インターネットからアクセス可能なサーバは最新状態を維持しましょう、というのが今回の主旨。
yum-cronのインストール
そんなわけで、今回はyum upateをcronで定期実行してくれるyum-cronを導入してみた。
インストールはコマンド一発！
# yum install yum-cron
��略～
================================================================================
Package Arch Version Repository
Size
================================================================================
Installing:
yum-cron noarch 3.2.29-60.el6.centos base 42 k
Installing for dependencies:
yum-plugin-downloadonly noarch 1.1.30-30.el6 base 23 k
Transaction Summary
================================================================================
Install 2 Package(s)
��略～
依存パッケージも1つインストールされた。更新対象のパッケージに対してダウンロードのみ実施する、なオプションがあるのかな。
yum-cronの設定
関連する設定ファイルをみてみる。
# rpm -ql yum-cron
/etc/cron.daily/0yum.cron
/etc/rc.d/init.d/yum-cron
/etc/sysconfig/yum-cron
/etc/yum/yum-daily.yum
/etc/yum/yum-weekly.yum
/usr/share/doc/yum-cron-3.2.29
/usr/share/doc/yum-cron-3.2.29/COPYING
/usr/share/man/man8/yum-cron.8.gz
設定ファイル、スタートアップスクリプト、cron用スクリプト等。
設定ファイルは/etc/sysconfig/yum-cronとなるので、この中身を見てみる。
cat /etc/sysconfig/yum-cron
# Pass any given paramter to yum, as run in all the scripts invoked
# by this package. Be aware that this is global, and yum is invoked in
# several modes by these scripts for which your own parameter might not
# be appropriate
YUM_PARAMETER=
# Don't install, just check (valid: yes|no)
CHECK_ONLY=no
# Check to see if you can reach the repos before updating (valid: yes|no)
CHECK_FIRST=no
# Don't install, just check and download (valid: yes|no)
# Implies CHECK_ONLY=yes (gotta check first to see what to download)
DOWNLOAD_ONLY=no
# Error level, practical range 0-10, 0 means print only critical errors which
# you must be told, 1 means print all errors, even ones that are not important
# Level 0 is the default
# ERROR_LEVEL=0
# Debug level, practical range 0-10, higher number means more output
# Level 1 is a useful level if you want to see what's been done and
# don't want to read /var/log/yum.log
# Level 0 is the default
# DEBUG_LEVEL=1
# randomwait is used by yum to wait random time
# default is 60 so yum waits random time from 1 to 60 minutes
# the value must not be zero
RANDOMWAIT="60"
# if MAILTO is set and the mail command is available, the mail command
# is used to deliver yum output
# by default MAILTO is unset, so crond mails the output by itself
# example: MAILTO=root
MAILTO=
# you may set SYSTEMNAME if you want your yum emails tagged differently
# default is output of hostname command
# this variable is used only if MAILTO is set too
#SYSTEMNAME=""
# you may set DAYS_OF_WEEK to the days of the week you want to run
# default is every day
#DAYS_OF_WEEK="0123456"
# which day should it do cleanup on? defaults to 0 (Sunday). If this day isn't in the
# DAYS_OF_WEEK above, it'll never happen
CLEANDAY="0"
# set to yes to make the yum-cron service to wait for transactions to complete
SERVICE_WAITS=yes
# set maximum time period (in seconds) for the yum-cron service to wait for
# transactions to complete. The default is 300 seconds (5 minutes)
SERVICE_WAIT_TIME=300
CHECK_ONLYとDOWNLOAD_ONLYの設定に応じて、更新はせずに更新可なパッケージを確認、またはダウンロードのみに留めることができるみたい。デフォルト設定のまま、更新まで実行させておく。冒頭の通り、逐次それを自分で確認して必要なものだけインストールするのは面倒この上ない。どうせ自宅環境だし、パッケージアップデートによって動かくなったサービスがあっても特に問題無い。
最後にyum-cronを起動して、chkconfigで自動起動を有効にする。
# /etc/rc.d/init.d/yum-cron start
Enabling nightly yum update: [ OK ]
# chkconfig yum-cron on
ps auxしてもそれらしきプロセスが存在しないので、デーモンプログラムでは無いみたい。
/var/log/yum.logにログが出力されるようなので、後日確認しよう。
あとは、メール通知させるくらいかなぁ。。。
IPv6化の準備してみた
今度はIPv6化に興味を持ち始めた。まずはその準備ということで、記録をまとめてみる。ひとまず、IPv6でインターネット接続できるようになるまでをゴールとしよう。流れとしては以下の通り。
前提として、足回りはNTTのフレッツ光ネクストを使用している。フレッツ光などの場合はまた方法が変わってくるので、注意すべし。
フレッツ・v6オプションの追加
とりあえずNTT西日本へ電話し、v6オプションの契約方法について案内してもらった。以下のURLから「フレッツ・v6オプション」を追加で契約すればよいとのこと。
サービス申し込み受付ページ：https://www.flets-west.jp/wso/
nagamee「やっぱオンラインで変更できるよね♪。なんだ簡単じゃん(ポチっ)。あれ、WEBページに繋がらない。。。」
電話かけなおす。
NTT担当「IPv6のアドレス割り当てられてますか？」
nagamee「ん？無いですね（それを今からやろうとしてるのに。。。）」
NTT担当「ではIPv6パススルーが有効化されていないのかと。そうでないと当WEBページにはアクセスできませんよ。一般的なブロードバンドでは有効になっていると思うのですが。ルータは何を使ってますか？」
nagamee「YAMAHAルータです。」
NTT担当「あ、弊社ではサポート外ですねぇ。。。」
nagamee「うす。こちらで設定します」
というわけで、IPv6パススルーの設定が必要なようだ。だがまてよ。ということはIPv6アドレスを持つクライアントと、IPv6をパススルーしてくれるルータが必要なる。そして、フレッツ・v6オプション契約前からIPv6アドレスは配られていることとなる。どういうことだ、誰か説明しろ。とりあえず、配られてるのならば、まず設定をしてみよう。この謎はあとで解消することとする。
IPv6パススルー
IPv6パススルーは、ルータ広告をプロキシする機能。すなわち上位回線(NGN網)からのルータ広告（RA）を、ルータで受けてLAN内にばらまく。LAN内のノードは広告されたネットワークアドレスから、自身のIPv6アドレスを決定する。RAについては、JPNICに記載されている説明がわかりやすい。
肝心のRTX1100に対する設定内容は、以下の通り。（自分の環境では、LAN2がWAN側、LAN1がLAN側となっているため、異なる場合は適宜読替えてもらえれば。）
ipv6 prefix 1 ra-prefix@lan2::/64
ipv6 lan1 address ra-prefix@lan2::1/64
ipv6 lan1 rtadv send 1
1行目。WAN側(LAN2)でNGN網からRAを受けるぞ
2行目。WAN側(LAN2)で受けたRAの情報から、LAN側(LAN1)インタフェースのアドレスを設定するぞ
3行目。受けとったRAは、LAN側(LAN1)にマルチキャストするぞ
手順自体は、YAMAHAのサポートページ]に記載されている。
最後に、IPv6アドレスが設定されたことを確認する。
[FCASTRUM]# show ipv6 address
LAN1 scope-id 1 [up]
Received: 155516 packets 34264064 octets
Transmitted: 9 packets 744 octets
global 2001:a452:xxxx:xxxx::1/64 (lifetime: 604779/2591979)
link-local fe80::2a0:deff:fe34:d39d/64
link-local ff02::1/64
link-local ff02::2/64
link-local ff02::1:ff00:1/64
link-local ff02::1:ff34:d39d/64
[global]の項目にアドレスが割り当てられていればOK。LAN内のノードについてもIPv6アドレスが割り当てられていたので、きちんとRAプロキシされているようだ。
この段階で、やっと先のフレッツ・v6オプション申し込みページを表示することができる。
サービス申し込み受付ページ：https://www.flets-west.jp/wso/
ログインにはお客様IDとアクセスキーが必要となる。契約書類に記載されているはず。別途準備しておくがよし。手続き自体は何も難しいことはなく無事完了。NTTの工事が完了次第メール通知がくるとのことなので、気長に待つことにする。
RTX1100をファームアップしてみた
YAMAHAのファームウェアリリースページからバイナリをDLする。
バイナリのアップロード
まず、RTX側でTFTPを有効化する。
アップロード元ホストのIPアドレスを指定
# tftp host xxx.xxx.xxx.xxx
バイナリをDLしたホストからRTXへバイナリをアップロードし、ファームを更新する。
$ tftp
tftp> connect xxx.xxx.xxx.xxx
tftp> mode binary
tftp> put rtx1100.bin exec
RTX側のログ
Update file receiving...
Testing received file...
Writing to Nonvolatile Memory...
done
Restarting...
��切断～
再度接続してファームのバージョンを確認する。TFTPはOFFっておく。
# show config
# RTX1100 Rev.8.03.94 (Thu Dec 5 19:06:16 2013)
��以下略～
# no tftp host xxx.xxx.xxx.xxx
以上、楽勝。これでL2TP/IPSecでリモートVPNに挑戦できるんさぁ♪
grepのオプションABC
先輩がコマンド打っているのを横で眺めていて、初めて知った。
grepの-A, -B, -Cオプション
$ rpm -qa | grep nginx -A 1
nginx-release-centos-6-0.el6.ngx.noarch
findutils-4.4.2-6.el6.x86_64
--
nginx-1.6.2-1.el6.ngx.x86_64
libselinux-utils-2.0.94-5.3.el6_4.1.x86_64
- -A n: ヒットした行から後n行を表示
- -B n: ヒットした行から前n行を表示
- -C n: ヒットした行の前後n行を表示
After, Before, Contextの略なり。
この次の行にアレがくるはず！！なんて時使えるね。
スキルを習得すること
めまぐるしく移り変わるIT業界において、エンジニアにはスキルの習得に終わりがない。
スキルというと、まず資格が思い浮かぶ。っで、勉強して、試験を受けて、合格して、満足してしまうのが王道パターンではなかろうか。
以前は自分もその傾向にあったので、今年に入ってからはなるべく短期一発は控えている。
少し長めのスパンで知識の定着を図りながら勉強に励んでいる。
けれども最近になって、ちょっと考えなおした。
「スキルを習得する」、「知識の定着」って言葉を使っているけど、どういう状態を以ってそういえるのか。
そして、最近読んでいる「ドラッカーさんに教わったIT技術者が変わる50の習慣」でそのもやもやが明確になった。
本書の中で、スキルの習得のステップについて記載があった。大きく四段階に分かれていて、
最初の状態は、知識があることを知らず能力も持っていない状態です。
スキルを習得する最初のステップは、それに「気づく」という段階です。
能力があるといえる状態になるには、実践と訓練が必要です。
スキルが身についたと言える状態は、無意識で能力を発揮できる状態ということです。
とてもシンプルなのだけど、非常に感銘を受けた。
まず、人はそれに気づいた時点で一歩成長しているのだ。
ここで「実践と訓練」を重ねれば当たり前になる。そうなったらスキルを習得したといえるんだ。
こうやってシンプルに考えると、自分がこれまで学んできた中で
習得できていること、できていないことが分類できる。指標になる。
これができている人、わかっている人からみればフツーのことかもしれないけど、
こんなん考えてみれば当たり前じゃんよーって思わなくなった素直な自分がいて、
これは一歩成長かとおもった次第。
//
nagamee
rsyslogでリモートサーバにログを送る(基本編)
前回、rsyslogの特徴を整理した。
今回はこれを踏まえてログをリモートサーバに送る基本的な設定をしてみたいと思う。
以下のような構成です。
本日のゴールは以下の2点
内容としては基本的ですが、一歩ずつ進める方針。
ファシリティ、プライオリティ、保存先ファイルの設定については
プロトコル別に分けてこんなかんじで。
サーバの設定
まずサーバ側の設定。
/etc/rsyslog.conf
(前略)
#### MODULES ####
$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imklog # provides kernel logging support (previously done by rklogd)
#$ModLoad immark # provides --MARK-- message capability
# Provides UDP syslog reception
<span style="color: #ff0000">$ModLoad imudp
$UDPServerRun 514</span>
# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514
(後略)
上記項目はデフォルトでコメントアウトされています。ModLoad im[tcp|udp]はそれぞれのプロトコルで待ち受けるためのモジュールをロードします。その際の待ち受けポートをInput[TCP|UDP]ServerRunで指定してやります。
最低限であればこれでOKです。
続いてクライアントから受け取ったログを出力先を指定してあげます。/etc/rsyslog.confに直接書き込むのでなく、外部ファイルを使います。
/etc/rsyslog.d/test.conf
# Save log from remote server
local1.* /var/log/local1.log
local2.* /var/log/local2.log
rsyslogをリロードしておきましょう。
# service rsyslog reload
これでサーバ側の設定はOKです。(ファイアウォールを設定している場合は514番のパケットを許可することを忘れずに)
クライアントの設定
クライアントでは、リモートサーバにログを転送するための設定をしていきます。
ファシリティ、プライオリティ、出力先の設定のみで済むので、こちらも外部ファイルに定義していきます。
/etc/rsyslog.d/test.conf
# Send log to remote server
local1.* @192.168.17.102 # UDP で送信する
local2.* @@192.168.17.102 # TCP で送信する
出力先の定義にて、@リモートホスト の形で指定するとUDPで送信、@@リモートホスト だとTCPでログを送信します。
# service rsyslog reload
以上で設定完了です。
動作確認
クライアントにてloggerコマンドを使い、手動でログを生成してみます。
# logger -p local1.debug TEST MESSAGE BY UDP
# logger -p local2.debug TEST MESSAGE BY TCP
サーバ側でパケットを確認してみます。
# tcpdump -nnn -i any port 514
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
14:04:28.471037 IP 192.168.17.101.55968 > 192.168.17.102.514: SYSLOG local1.debug, length: 58
14:04:42.289389 IP 192.168.17.101.47199 > 192.168.17.102.514: Flags [P.], seq 907178924:907178983, ack 264883602, win 115, options [nop,nop,TS val 52266550 ecr 51964458], length 59
14:04:42.289416 IP 192.168.17.102.514 > 192.168.17.101.47199: Flags [.], ack 59, win 114, options [nop,nop,TS val 52259941 ecr 52266550], length 0
UDP、TCPでログ転送の通信が確認できました。最近tcpdumpの使い方を覚え、これみよがしに使っています。
最後にサーバ側のローカルファイルを確認します。
# cat /var/log/local1.log
Sep 28 23:08:06 centlab1 nagamee: TEST MESSAGE BY UDP
# cat /var/log/local2.log
Sep 28 23:08:20 centlab1 nagamee: TEST MESSAGE BY TCP
以上で基本的なrsyslogの設定は終わりです。
次はマクロ・テンプレート機能についてやってみようかと思います。
rsyslogとは何者か
僕が初めてsyslogを知った時には既にrsyslogが広く利用されておりました。
設定の機会にあまり巡り合わなかったこともあり、syslogとrsyslogの違いをよくわかっていないので整理しておきます。
rsyslogの特徴
syslogdはリモート機器が吐くログを収集し、管理するためのデーモンです。syslogに対して、信頼性を向上させたものがrsyslog。"r"はReliableのイニシャルですね。以下、主な特徴になります。
- ログ転送の通信にTCPが使える
- 設定はsyslog互換
- syslogからの移行が簡単にできる
- ログ情報をリレーショナル・データベースに格納・管理できる
- MySQL、Postgreなどが使える。
- SSLによる通信の暗号化
- マクロ・テンプレート機能
今日はささっと調べてまとめることを目標にしているので、実際の設定については触れません。
が、特徴だけまとめただけだとすぐ脳みそからニフラムなので追々作業ベースでまとめていきたいと思います。
色々調べているとsyslogだけでも奥が深そうでした。プリオリティとかファシリティを設定してログ転送確認して終了なレベルの設定しか経験がないので、まずはsyslogについてやってみたいですね。
- -
nagamee
バックアップは大事だぜ！の巻
なーに当たり前のこと言っちゃってんだよって感じですね。
iPhoneのパスコードってデフォルトだと4桁ですよね。
これが怖くて、もう少しセキュリティ強度の高いパスワードを
設定したのですが、
忘却の彼方に。。。
あぼーんです。パスコードを忘れた場合は、
初期化した後にバックアップから復元するしか無いのです。
【パスコードを忘れた】iPhone本体のパスコードを忘れた時の対処
復元前でもバックアップの取得が可能らしいのですが、
パスコードを変更してからバックアップしてなかったので、
iPhoneをPCに接続して試してみると、
パスコードを求められます orz
というわけで諦めて前回のバックアップを使って復元しました。
最後に取得したバックアップは一ヶ月前。
普段はあまり写真等取らないのですが、今月に限って
2回ほどバイクでツーリングに行っており、結構良い写真が
あったのですよぉぉぉぉ。涙ながらに復元を敢行。
無事復元はできたのですが、もう今回のようなことは起こすまいと、
すぐにバックアップ環境を整えました。
自宅にはこれまで無線環境がなかったので、
AirMac Expressを買ってきて無線APとして鎮座。
これでiCloudへのバックアップはOKです。
ただ、課題が残ります。
iCloudはバックアップ容量に制限があるため、
コンピュータへのバックアップも定期的にしないと
いけません。手動で毎日バックアップなんて
めんどくさすぎてガッデムなので、どうにかしなくては。
こちらはまだ調査不足ですが、同じLAN内に入ったら、
PCがiPhoneを検知して自動でバックアップしてくれるような
設定ができたら最高です。調べないと。。。
教訓として得たのは「バックアップは重要」、ということです。
当たり前だけども。
CCENTを受験してみて
自らの三日坊主っぷりにほとほと呆ればかりorz
気を取り直して、今日からちょこちょこ更新がんばります。
ということで、タイトルの通りCCENTを受験してきました。
結果としては...
合格！！
スコアは920点でした。(90分50問で804/1000以上が合格基準です）
ぱちぱち！！
学習期間は3ヶ月程で、ベンダ資格学習サイトとしては定番のping-tを
使っていました。同サイトの他ユーザと比較すると、学習期間としては比較的長いほうだと思います。
スコアだけ見ると割りと高い得点で合格できましたが、自信を持って解答できたのは7割程度。
出題傾向について感じたところを並べてみます。
- アドレッシング計算系の出題が多い(4割弱はあったと思う)
- OSPF, IPv6の出題は1割程度
- シミュレーション3問の解答スピードが鍵
- コマンド入力形式の問題は出題されなかった
まず、アドレッシング計算の対策は必須だと思われます。
配点は高くないでしょうが、結構な頻度で出題されました。
ですが、ホスト数やネットワークアドレスの計算等、
典型的かつ易しい問題が多いので対策すれば稼ぎどころかと思います。
OSPFの出題はあまりなかったですね。
暗記に頼らずきちんと理解していないと解けない問題でした。
全体の配分からするとわずかなのですが。
残りの選択形式の問題はまんべんなく出題されたように感じます。
選択形式の場合、ピンポイントで正解を導けない問題が多かったですね。
消去法で絞り込めば案外特定できそうです。自分がそうでした。
そして、最後にシミュレーション形式について。
正直一番やっかいです。トポロジ図、問題、シミュレータ画面が
それぞれ別のウィンドウで開き、サイズが変えられない。
モニタもそれほど大きくないのでどうしてもウィンドウが重なって
しまい、解答の導出に時間がかかります。
CCXXの試験は一度解答した問題には戻れないので、
各問題に割り当てる時間の見積もりが難しいです。
シミュレーション問題は1問の中に小問が4つ出題されるため、
配点も大きいでしょうから、時間をかけても解いておきたいところかと思います。
以上から、対策としては知識系の選択問題、
アドレッシング計算問題をいかに素早く解けるかが
勝負の分かれ目になりそうです。
そこで、時間を稼いでシミュレーション問題を
じっくり解ければ合格できるんじゃないかなと。
いずれにもしても難解な問題は無いので落ち着いて臨むのが大事です。
以上、これからCCENT受験する方はぜひ頑張ってください！
次は、LPIC202とCCNAを目指します。
最大素因数を求める Project Euler Problem 3
最近寒かったり、汗ばむくらい暖かかったり、不安定な気候に体がついていけてない。なので、GWは室温が安定してるお家に引きこもって遊んでおります。
Project Eulerを利用して言語を学ぶ
というわけでrubyとhaskellの練習のために、ProjectEulerの問題を解いてます。この2つで同じ問題を解くことで、命令型と関数型プログラミングの違いを理解することが狙いです。このサイトはプログラミングのお題が豊富ですが、アルゴリズムに親しくない自分にとっては最初の3問目ですでに結構時間かかってしまう。
約数かつ素数で、最大の数は？
Project EulerのProblem3はこんな問題。
13195の約数のうち、素数である数は5,7,13,29。では600851475143の約数かつ素数のうち、最大の数は？
素数といえばお題としては定番なんでしょうね。
コーディング
今回はrubyで解いてみましたが、まず解き方の方針を以下のようにしました。
- 600851475143の約数を列挙する
- 1で求めた約数のうち、素数であるものを抽出
- 2の中から最大数を求める
それで作成したコードは次のようになりました。
def prime? n
return true if n == 2
return false if (n < 2) || (n & 1 == 0)
return (2**(n-1))%n == 1
end
def find_max_prime_factor n
head = (n/2).to_i
div_list = []
head.downto(2) do |i|
div_list.push(i) if n%i == 0
end
div_list.each do |x|
return x if prime?(x)
end
return false
end
p find_max_prime_factor 600851475143
find_max_prime_factorメソッドで最大素因数を求めます。素数の判定にはフェルマーの小定理を使い、prime?メソッドを作りました。この素数判定、当初はエラトステネスのふるいで行おうとしたのですが、計算量が多くて今回のお題のような桁の大きな数については時間がかかります。Project Eulerでは作成したプログラムに対して「処理時間が1分以内であること」が
定められています。フェルマー小定理については、こちらのサイト様を参考にしています。あとの工夫点としては、
- 約数のは0～n/2の範囲で降順に列挙
- 約数リストの先頭から素数判定を行い、最初に真となったものが最大値となる(1で降順に列挙しているため)
というかんじです。続いてhaskellで解いてみようと思うのですが、全然イメージがわかない残念な感じです。すごいH本を買ってきたので、まず言語自体の基本を抑えないといけませんねぇ。
参考
- Pythonを使って高速素数判定をしてみる http://d.hatena.ne.jp/pashango_p/20090704/1246692091
- エラトステネスの篩 http://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%A9%E3%83%88%E3%82%B9%E3%83%86%E3%83%8D%E3%82%B9%E3%81%AE%E7%AF%A9
HTTP 100-continue
いまお仕事でCephを触る機会をもらっている。検証環境の構築はこれからだけど、ドキュメントに目を通してたらApacheやらFastCGIのところで"100-continue"なる単語が見受けられる。
you must install the Ceph Object Gateway daemon. The Ceph Object Gateway supports 100-continue, but you must install Ceph builds of Apache and FastCGI for 100-continue support.
そっこうぐぐる。tkuroさんのブログに詳細があった。HTTP/1.1のリクエストの仕様なんですね。
WebRequestのExpectにデフォルトで100-continueがつく件 - 初学者の箸置
通常、HTTPリクエストはヘッダ+ボディをセットでサーバへ送る。そのリクエスト内容について、サーバ側で何らかの(400系の)エラーがあった場合、その旨をクライアントへ返す。HTTP 100-continueでは、「リクエストがエラーになるなら、ボディ送る時間が無駄だよね。じゃあ先にヘッダ情報だけ送って確認してもらおう。もし受け付けてもらえるんだったら、その時にボディを送りましょう。」という方針でHTTP通信を行う。つまり今までセットで送っていたヘッダとボディを分け、効率化しようということ。
クライアントはとりあえずヘッダ情報だけ送って、まずは返ってくるステータスコードを調べる。100系なら続けてボディ送信、400系なら送信やめる、といった具合。
ただし、注意すべきは
問題なのはこの 100-continueに対応してないサーバ（HTTP接続な認証サーバとか）がいるという事なのですね。この場合要求された時点で 417 を返してきます。
というわけで、Cephで扱うApacheとFastCGIはこれに対応しているらしい。
Rakeの基本的な使い方
RakeとはRubyで記述するビルドツールの一種。「タスク」という単位で特定の処理をひとまとめにすることができる。タスクの定義はRakefileに記述する。
Rakefileの記述方法
Rakeでは言語内DSLとして定義されたメソッド群を使ってタスクを定義する。試しに、簡単なタスクをRakefileに記述する。
desc 'Task1 description'
task :task1 do
puts 'task1 is executed'
end
desc 'Task2 description'
task :task2 => [:task3] do
puts 'task2 is executed'
end
desc 'Task3 description'
task :task3 do
puts 'task3 is executed'
end
descメソッドにはタスクの説明を記述する。'rake -T'を実行すると、タスク名とdescメソッドで記述した文字列の一覧が表示される
$ rake -T
rake task1 # Task1 description
rake task2 # Task2 description
rake task3 # Task3 description
taskメソッドにはタスクの処理を記述する。taskメソッドの引数としてシンボルを渡すとタスク名として扱われる。また、上記のtask2のように、taskメソッドにはHashを引数として渡すことができる。keyにタスク名、valueに依存するタスク名を指定することで、タスクに依存関係を持たせることができる。
結果を見たほうが早いので、'rake タスク名'でタスクを実行してみる。
$ rake task1
task1 is executed
$ rake task2
task3 is executed
task2 is executed
task2を実行すると,task2自身が実行される前にtask3が実行されている。task2の定義でtask3と依存にしていることを記述したため、その場合はtask2自身の実行前にtask3を実行する。
KVMでイメージファイルの置き場にNFSを使いたい
先日のNFSサーバ構築から今度はKVM+NFSの話。
KVMでゲストOSのイメージファイル置き場にNFSを使う場合は、SELinuxの設定変更を行う必要がある。設定内容を確認してみる。
$ getsebool virt_use_nfs
virt_use_nfs --> off
こんな感じでデフォルトではNFSの利用が許可されていない。なので、こいつを有効にしてやる。
$ sudo setsebool virt_use_nfs on
$ getsebool virt_use_nfs
virt_use_nfs --> on
これで仮想マシンを作成する時に、NFSマウントしたディレクトリを指定することができる。
# SELinux無効化するのが一番早いけどね。
NFSサーバ構築 CentOS6.4
KVMで仮想サーバを立てたのだけど、ゲストOSのイメージファイルを別サーバで管理したかったので、NFSを使うことにした。
なので、NFS設定に関するメモ書きを残す。
公開ディレクトリの設定
NFSとして外部に公開するディレクトリを指定する。サーバの都合上、/home以下の容量に余裕があったため、/home/exportディレクトリを作成し、これを公開ディレクトリとする。
# mkdir -p /home/exports/img
# chown -R nfsnobody:nfsnobody /home/exports
次に作成したディレクトリを公開するための設定を行う。/etc/exportsを以下の通り編集する。
# 書式
# export_directory
/home/export/img 192.168.17.0/24(rw,all_squash,sync)
固定ポートを使用するための設定
NFSをデフォルト設定のまま起動すると、portmapperが自動的に空いているポートを動的に割り当ててしまう。この場合、起動する度に使用するポートが変わってしまい、FWでポート開放ができない。このため、/etc/sysconfig/nfsの設定内容を編集し、使用ポートを固定する。具体的には以下の項目のコメントアウトを外せばよい。(ポート番号を変えたい場合は適宜変更する)
RQUOTAD_PORT=875
LOCKD_TCPPORT=32803
LOCKD_UDPPORT=32769
MOUNTD_PORT=892
STATD_PORT=662
STATD_OUTGOING_PORT=2020
RDMA_PORT=20049
サービス起動
nfslock、nfsの順番でサービスを起動する。
# /etc/init.d/nfslock start
# /etc/init.d/nfs start
FWを設定している場合はきちんと穴を空けておく。以上でサーバ側の設定は完了。
クライアントからのマウント設定
クライアント側ではmountコマンドでサーバのリモートディレクトリをローカルディレクトリにマウントしてやればよい。まずローカルディレクトリを作っておく。
# mkdir -p /export/img
これで準備は整った。マウントしてみる。
<i># mount -t nfs -o options host:/remote/export /local/directory</i>
# mount -t nfs -o rw 192.168.17.5:/home/export/img /export/img
これでエラーが特になければ成功している。mountコマンド使ったり、実際にマウントしたディレクトリにファイルを作ったりしてみて確認する。
以上でNFS接続は完了。ただし、このままだと再起動した際にマウントされないので、/etc/fstabにエントリを追加して、起動時にリモートディレクトリをマウントするよう設定する。
192.168.17.5:/home/export/img /export/img nfs defaults 0 0
これでイメージファイルを一元的に管理できて少し楽になりそう。
ruby - injectメソッド
普段からよく使うスクリプト言語っていうと，シェルスクリプトです．
もうちょい今流行りのスクリプト言語使えるようになって，サクサクっと簡単なアプリ作ってみたいなーと思ってはいたものの，めんどくさくて仕事が忙しくて手が出せずにいました．
この前の土日にフラっと本屋にいったら，Rubyの本達が大々的に並んでいたので，衝動買い．ruby使いになることにしました．
まだまだ基礎を勉強中ではありますが，とりあえず面白いなーって思ったことについてはちょっとずつ記録に残してこうと思います．
そこで今回はinjectメソッドです．(こっからいきなり"-である"調に変わります）
- -
injectメソッドは繰り返しまたは再帰処理に威力を発揮する．
例えば何かしらの計算するときに，結果を格納するためのテンポラリ変数を用意する必要がある．
そのためにどこかで定義して初期値を与えとかないといけない．
sum = 0
(1..10).each {|i| sum = sum + i}
injectメソッドではこれをひとまとめにすることで，簡潔な記述が可能となる．
(1..10).inject(0) {|sum,i| sum = sum + i}
これは，どういう仕組みになっているか．ポイントはinjectメソッド自体の引数とinjectメソッドのブロック引数の2点．
まず，injectメソッドではブロック引数を複数記述する．1つ目の引数は処理を格納するための変数．このブロック引数の初期値は，inject(0)のようにメソッド自体に渡した引数の値がセットされる．つまりブロック引数で処理結果を格納するための変数を定義し，メソッドの引数の値で初期化を行うイメージ．2つ目の引数は呼び出し元のオブジェクトの各要素が代入される．
数列を求める際も，簡潔に処理を記述することができる．
(1..10).inject([1,1]) {|fib,i| fib << fib[i] + fib[i+1]}
こういう簡単な例しか今のところ思い浮かばない（はやくruby初心者抜け出したい．．．）
//
quotaを使ったディスク容量制限
現在，LPIC101を勉強中なのですが，quotaを扱った経験が無かったのでお勉強がてらメモ書き．よくあるクラウドストレージサービスとかの容量制限も裏ではこれが動いているのかな．
quotaとは
クォータと読む．
特定のパーティションに対してディスクの使用容量に制限をかける仕組み．
ユーザ，グループ単位で設定可能．
制限の単位はサイズまたはファイル数(inode数)
制限の種類はソフトリミットとハードリミットの2つ(後術)
複数のユーザがサーバを共用する際に，特定ユーザがディスクを食いつぶしてしまうことのないよう，事前にユーザごとの制限を設けましょうっていうものです．
(これとは違う使い方あるのかな？ちょっと考えときます)
quotaの設定
要約すると，以下の通り．
- quotaが使えるようマウント時の設定変更 (/etc/fstab)
- quotaの初期設定 (quotacheck)
- quotaの有効化 (quotaon)
- quotaの設定 (edquota)
- quotaの設定一覧表示(repquota)
- quotaの設定コピー (setquota)
続きは後で更新しまーす．
N度目のブログ開設ですけれども
ブログ．．．今まで幾度と無く3日坊主を繰り返している．
今度こそはと気合を入れまして，
やったろーじゃないのブログ開設！
お仕事に関係してくるインフラ技術を中心に，
最近めっきり機会が減ったプログラミングなんかも勉強したいな．
社会人1年目！これからどうなるかわかりませんけども，
3年目までには自分の武器と呼べる技術を磨きあげたい．
と思う今日このごろです．
どうぞよろしく:-)
登録:
投稿 (Atom)