FC2ブログ
071234567891011121314151617181920212223242526272829303109

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
【 --/--/-- (--) 】 スポンサー広告 | TB(-) | CM(-)

フリーダム!

更新が超久しぶりになってしまった。


IT業界はブラック企業という言葉の発祥の地でありながら、最近は飲食業っていう一般的な方でニュースになったためにそっちの方にばかり注目が行ってる。
そのあいだ決してIT業界がその後改善されたというわけではない。業界的に残業・徹夜・休日出勤が常態になってるのは相変わらず。


(残念ながら?)IT業界ではあまりニュースになるような露骨な話を聞かないからなぁ...IT業界の著名人はその辺賢いからか、死ぬまで働くべきだなんて事はテレビでは言わないし。(笑)
現場では客の言葉にされてない要求という目に見えないプレッシャーで、それこそ死ぬまで働けモード全開なプロジェクトが多々あるんだが。w


エンドユーザー⇒IT部門⇒SI⇒二次受け設計者⇒三次受け開発者⇒...

という形で段階的に要求が具体化していく中で、文書化されてない要求の行間を読む中で、
  • 「一応」とか
  • 「念のため」とか
  • 「確認を文書要求すると間に合わない」とか

で、どんどん雪だるま式に作らないといけないものが膨れ上がっていき、性能などの非機能要求はどんどん厳しくなっていく。


こちらは別にマネージャーでないので毎日チェックしてるわけでも全然ないのだが、同じ部屋で見かける人で、いつ見ても死にそうな顔してる人とか、気が付いたら入れ替わってたりする。
担当範囲が片付いたのか、メンタルで降板したのか、駅でジャンプしたのか、その辺はよくわからないけど。


さて愚痴はこれくらいにしとくか。


 
スポンサーサイト
【 2015/03/20 (Fri) 】 未分類 | TB(0) | CM(0)

ちょっと戻って、Hyper-Vのインストール(というか有効化)について。

Hyper-VはWin8.1セットアップ直後には有効になっていない。BIOS上で仮想化機能を有効化し、そのうえでWindowsのHyper-Vを有効化する必要がある。

マシンの選択


まずハードウェアだが、仮想化対応のCPUを搭載している事が必要だが、最近売ってるPCだったら大抵は対応してるだろう。
Intel CPUの場合: Intel VT-Xおよび拡張ページテーブル機能を搭載したCPU
AMD CPUの場合: AMD-V機能を搭載したCPU
OS: 64ビット版Windows 8 ProもしくはEnterprise

超小型PCで仮想マシンサーバーを作ろうとした場合には困るかもしれないが。


BIOSの設定


CPUに関する各種設定の中から、Virtualization Technologyのような名称の項目を有効にする。

Intel CPUを搭載したマシンのBIOSでは、Intel(R) VirtualizationTechnology となってると思われる。


Windowsコントロールパネル上での有効化


コントロールパネルから、
[プログラム]->[Windowsの機能の有効化または無効化]を選択。

出てくるツリー形式のオプション一覧から、"Hyper-V"という名前の箇所を探し、以下の項目にチェックを入れる。
√ Hyper-V
  √ Hyper-V プラットフォーム
  √ Hyper-V 管理ツール
   √ Hyper-V GUI 管理ツール
   √ Windows Hyper-V用Hyper-Vモジュール

完了


再起動でHyper-Vを有効にした状態で立ち上がってくれる。


【 2014/08/22 (Fri) 】 未分類 | TB(0) | CM(0)

Bashで正規表現など使いデータの精査(数値データ)

先日のbashの中で直接正規表現を使いボロボロなデータファイルの精査をする件の続き。

[[ string =~ regex ]]と書けば、文字列stringが正規表現パターンregexにマッチするかどうかをbashの中で直接評価できると書いた。

じゃぁ、たとえばどんな正規表現を使えば、データの検証ができるか...

まずは数値をあらわす文字列について。


固定長整数、カンマ区切り・小数点・符号など一切なし




[[ ${FIELD} =~ ^[0-9]{8}$ ]] || BAD_DATA_FLAG=1


正規表現を既に使ってる人には耳蛸だけど、基礎をあらためて書くと...
・数字0~9のうち任意の1文字を表すパターンは、[0-9]というかたちであらわす。
・大カッコでくくると、大カッコの中の任意の1文字という意味。
 さらに、0-9と書くことで、「0から9までの」という意味。
・中括弧「{}」の中に数が一つだけ書いてあると、その文字数という意味。
・大カッコの前にあるキャレット(^)は、冒頭を意味し、大カッコの後ろにあるドルマーク($)は末尾を意味する。
 なので、^と$の間にパターンを書くと、そのパターン以外の文字は存在しない、というかたちになる。


n桁以内の整数、カンマ区切り・小数点・符号など一切なし




[[ ${FIELD} =~ ^[0-9]{,8}$ ]] || BAD_DATA_FLAG=1


先ほどの正規表現との違いは、中括弧が{,8}というようにカンマを使っている点。これは、カンマの右に書いてある数までの文字数、という意味。つまり、
{8} … 8文字
{0,8} … 8文字以内 (なぜか、{,8}と書くと正しく文字数を判定してくれない。)
{8,} … 8文字以上
{4,8} … 4文字以上8文字以内
というような使い方ができる。


整数もしくは小数、カンマ区切り・小数点・符号などあり、スペースも含む




[[ ${FIELD} =~ ^[\+\-]*[ ]*[0-9]{1,3}(,[0-9]{3})*(\.[0-9]{0,15}){0,1}$ ]] || DATA_ERROR_FLG=1


Excelなどからテキストファイルをエクスポートすると、凝った書式が残ったままの場合があり得る。
また、数値としても、現実世界には負の数もあれば小数もある。
そのようなデータを扱う正規表現パターン。


指数表記の数値



Float型の数値の場合、"-3.14159265758979E002"(-314.14159265758979という意味)のように、指数表記である事が多い。
そのような書き方をされた数値の場合


[[ ${FIELD} =~ ^[\+\-]*[1-9](\.[0-9]{0,15}){0,1}[eE][\+\-]{0,1}[0-9]{1,3}$ ]] || DATA_ERROR_FLG=1



数値の小数点より上の桁数、下の桁数を調べる



数値型としか定義書にかかれておらず、小数点の上、下それぞれ何ケタ必要か調べないといけない場合がある。
残念ながら説明レベルでとどまっていて構築可能なレベルに達していない仕様書も世の中には数多く存在する。

そういう場合に、実データをなめてDECIMAL型の小数点より上・下の桁数が何ケタ必要かを調べる方法。
(もちろん、仕様としては必要だけど「たまたま」そういうデータがなかったという理由で、必要分より少ない桁数をレポートする場合もあり得るけど...それは仕方のない話。ちゃんと文書に起こしておけ、ムカー。)

これには、これまで使ってきた正規表現マッチとは異なる方法を用いる。

 
tmp_field=${FIELD//[,\.\-\+ ]/}
tmp_above=${FIELD%.*}
tmp_below=${FIELD#*.}
digits_above=${#tmp_above}
digits_below=${#tmp_below}


ちょっと長ったらしくて、一行で書き表せないのが残念なところ。
これら新たに出てきた表記法は、文字列に対してでなくパラメータ(変数)に対してしか使えないので、ひとつ処理するたびに代入し直さないと、凝った事ができないのだ。
(bashのメンテナーのみなさん、何とかしてもらえませんか?)

新たに出てきた表記法をざっくり説明すると、

${param//pattern/subst} … 変数paramの内容に対し、パターンpatternにマッチする部分をsubstの値に変換して表示する。
つまり、sedでよくやる's/pattern/subst/g' と同じような使い方。
ただし、凝った正規表現は書けない。せいぜいファイル名展開に使うパターンの程度。
${param/pattern/subst}とも書け、その違いは、'/'が一つだとパターンに1回マッチしたところまでで止め、2つ('//')だと変数のあらわす文字列全てに対して行う。
${param%pattern} … 変数paramの内容の末尾部分に対し、パターンpatternがマッチするかチェックし、マッチした部分を削除した内容を表示する。


【 2014/02/26 (Wed) 】 未分類 | TB(0) | CM(0)

あまり使われていない、bashの機能・コマンド--||, &&

コマンドリスト(条件に応じ後続処理を実行・無視)



ファイル操作など、うまく行った場合・または失敗した場合のみ特定の動作をさせたいという事は、シェルプログラミングではよくある話。そのたびに条件文を書いてもいいけど、簡単に記述する事もできる。


コマンドリストを使った書き方


たとえば、
command1 && command2
とすると、command1が正常終了時(終了コード=0)の場合のみ、command2が実行される。

また、
command1 || command2
とすると、command2が異常終了時(終了コード<>0)の場合のみ、command2が実行される。


私がよく使う方法は、スクリプト関数dieを用意して、コマンドがうまくいかない場合にエラーメッセージを出して終了させるという方法。
要は、Perlのdie関数と同じ簡潔な書き方をさせたいという。

$ cat show_die.sh
die ()
{
TMP=${?}
echo "${0}: ${@}"
exit ${TMP}
}

# This find command should fail…
diff /etc/profile /etc/pprofile || die "File comparison failed."

$ sh show_die.sh
diff: /etc/pprofile: No such file or directory
show_die.sh: File comparison failed.
$ echo $?
2


エラーで終わったという事を示す非ゼロの終了ステータスが、エラーメッセージ表示の成功で上書きされてしまいゼロになってしまわないよう、一度TMPでエラーコードを受けてるのもミソ。"|| echo …"でエラー対応してるスクリプトを呼んでるスクリプトがいた場合、誤動作を避けられる。


コマンドリストを使わない書き方



Bシェルでも同じ書き方はできる。あまり見ないけど。
/etcディレクトリ下の設定ファイル(多くはシェルスクリプト)を眺めてると、大抵はif文で条件判断・分岐をしてるので、大昔はそういう書き方ができなかったけど、途中からできるようになって、後方互換性のためにそのまま残してるんだろうか?

たとえば、||のかわりにif文を使って上記のようなdiffが失敗する場合のチェックを書こうとすると、

diff /etc/profile /etc/pprofile
RC=${?}
if [ ${RC} -ne 0 ]
then
echo "File comparison failed."
exit ${RC}
fi

のような形になる。die関数が定義してあったとしても2行減るだけ。何かファイル操作をしようとするたびに6行もエラー対応が続くと、動き的には行儀のよいコードでも、見た目的にはかなり行儀が悪い。


 
【 2014/02/11 (Tue) 】 未分類 | TB(0) | CM(0)

PostgreSQLのユーザー認証方法を変更--pg_hba.conf

PostgreSQLの認証方式を定義する設定ファイルは、pg_hba.confというファイル。
これを編集して、パスワード認証、LDAP認証などを設定する。

ただ...
"local all all trust"って...

無防備すぎるでしょw 
このマシンのOSにログインできたら、どんなユーザーでも無条件にデータベースへログインできるって設定になってる。


[root@localhost ~]# find / -name pg_hba.conf 2>/dev/null
/usr/local/pgsql/data/pg_hba.conf
[root@localhost ~]# ls -l /usr/local/pgsql/data/pg_hba.conf
-rw-------. 1 postgres postgres 4476 Jan 29 05:20 /usr/local/pgsql/data/pg_hba.conf
[root@localhost ~]# view /usr/local/pgsql/data/pg_hba.conf

# TYPE DATABASE USER ADDRESS METHOD

# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres trust
#host replication postgres 127.0.0.1/32 trust
#host replication postgres ::1/128 trust



ちょっとあんまりなので、パスワード認証を有効にする。

その前に、特権ユーザーpostgresに対して、あらためて明示的にパスワードを変えておく。
このユーザーでもログインできなくなったらシャレんならん。


まず、postgresユーザーのパスワード変更。


-bash-4.1$ psql postgres
psql (8.4.18, server 9.3.2)
WARNING: psql version 8.4, server version 9.3.
Some psql features might not work.
Type "help" for help.

postgres=# alter user postgres password 'postgres'; #実際には違うの入れてますがね。
ALTER ROLE



そして、認証方式設定ファイルpg_hba.confの編集。パスワード認証方式に、md5(パスワードハッシュ値での認証)とpassword(パスワードが平文で流れる)の2種類があるので、md5を使うことにする。
METHODがtrustの行をコメントアウトして、下記のように追加する。


local all all md5
host all all localhost md5
host all all 192.168.151.0/24 md5 # host os in home wifi network
host all all 192.168.230.0/24 md5 # vmware guests in virtual network


データベース再始動後、ちゃんとログイン時にパスワードを聞いてくるようになった。


-bash-4.1$ psql postgres
Password:
psql (8.4.18, server 9.3.2)
WARNING: psql version 8.4, server version 9.3.
Some psql features might not work.
Type "help" for help.




それにしても、PostgreSQLは、データベースとOSが何だかごっちゃになってるなぁ...
ユーザー追加コマンドがOSから起動できたり、認証方式の設定がOS上のファイルだったり、DBMSってそんな感じでいいんだっけ?

OSとは切り離された世界になってた方がいいんじゃないのという気もするが。


【 2014/02/09 (Sun) 】 未分類 | TB(0) | CM(0)
プロフィール

Ed U Song

Author:Ed U Song
社内ノマドなエンジニア。
仕事で触れる機会のないものを自宅環境作って実験。

スポンサーリンク
最新コメント
最新トラックバック
検索フォーム


                                         
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。