1 2 3 4 5 6 7 次ページ / page 1 (7)

カテゴリ：Linux

2016-05-14 Sat

■ SiteGuard Lite の出力ログを Webalizerで解析 [Linux][Security]

もう１つ、会社のブログに記事が追加されてます。

SiteGuard Lite の出力ログを Webalizer で解析してみる
https://toe.bbtower.co.jp/20160428/191/

SiteGuard Lite って、機能縮退版って意味なのかと思ってたら違うんですね。ゲートウェイ型ではなく、ホストにインストールするやつを SiteGuard Lite って読んでるそうです。

SiteGuard Lite は、管理画面もついてて、ログも表示されるんですが、それを集計し、グラフ化する機能は別製品になってます。とは言いながらも、マニュアルに記載があるように、Webalizerで解析、グラフ化するためのパッチも用意されてます。

ただ、ベースが古すぎて、最新版の webalizer-2.23-08 では使えなかったので、使えるように書き換えてみました。動作保証無しですが、よろしければ、上記URLからパッチを入手してみてください。

とにもかくにも、パッチ公開をご快諾頂けたジェイピー・セキュアさんには、重ね重ね感謝です :-)

固定リンク コメント
このエントリーをはてなブックマークに追加

2016-05-14 Sat

■ 負荷テストツールの tsungについて [Linux]

こっちでお知らせするのを忘れてましたが、会社のブログに記事を追加しました。

負荷テストツールの tsung を使ってみる
https://toe.bbtower.co.jp/20160407/93/

tsung は、Erlang で書かれたマルチプロトコル対応の負荷テストツールで、結構気軽にクライアントを増やせるので、なかなかいいです。

固定リンク コメント
このエントリーをはてなブックマークに追加

2016-02-22 Mon

■ iptables-ext-dns を導入してみる [Linux]

iptables/ip6tables で DNS Query にマッチさせる extension が公開されてます。

Https://github.com/mimuret/iptables-ext-dns

Centos6/CentOS7 の場合のインストール方法は簡単。ドキュメントに書いてあります。

https://github.com/mimuret/iptables-ext-dns/blob/master/README.md

$ sudo yum install gcc make automake libtool \
iptables-devel kernel-headers kernel-devel
$ git clone -b kernel3 https://github.com/mimuret/iptables-ext-dns.git
$ cd iptables-ext-dns
$ ./autogen.sh
$ ./configure --libdir=/lib64
$ make
$ sudo make install


これで無事に入ります（kernel-devel も必要でした）

"--maxsize" のオプションがあることを期待させますが、これは qname の max size を指定するものだそうです。

なお、pull req 募集中だそうです :-)

＃本家にマージされたりするかな？

固定リンク コメント
このエントリーをはてなブックマークに追加

2016-02-17 Wed

■ (dnsmasq への追記あり) CVE-2015-7547 glibcのgetaddrinfo に stack buffer overflow の脆弱性 [Linux]

久々？に大きな脆弱性が出ました。glibc2.9 以降で発現する脆弱性です。

詳細は

CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow
https://googleonlinesecurity.blogspot.jp/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

に詳しいです。主な影響を受けるディストリビューションは下記の通り

Distribution Vuluneable
RHEL5/CentOS5 受けない
RHEL6/CentOS6 受ける
RHEL7/CentOS7 受ける
Debian squeeze 受ける
Debian wheezy 受ける
Debian jessie 受ける

この情報は下記から

CVE-2015-7547: Critical Vulnerability in glibc getaddrinfo
https://isc.sans.edu/forums/diary/CVE20157547+Critical+Vulnerability+in+glibc+getaddrinfo/20737/

getaddrinfo() を使ってる場合に、影響を受ける可能性があります。

すでに PoC は公開されていています。

https://github.com/fjserna/CVE-2015-7547

ここに公開されている CVE-2015-7547-proc.py とかを root 権限付きで実行すると、この手の buffer overflow を引き起こすパケットを返してくる DNSキャッシュサーバもどきになってくれます。

これをローカルで動かした状態で /etc/resolv.conf に

nameserver 127.0.0.1


とすると、

$ ssh www.example.jp
Segmentation fault


という感じで、落ちてくれます。

ただ、普通のDNSキャッシュサーバは、この手の malformed packet は、リゾルバには返さず SERVFAIL が返ります。
なので、影響を受ける Linux が参照している DNSキャッシュサーバが、自分が管理しているunbound だったり bind だったりする場合には、直近影響を受けないといっていいと思います（追記：後述しますが、残念ながらこれだけでは攻撃の可能性を完全に排除できないそうです）。aws では影響がないとのコメントが出されています。

CVE-2015-7547 Advisory
https://aws.amazon.com/jp/security/security-bulletins/cve-2015-7547-advisory/

EC2 customers using the AWS DNS infrastructure are unaffected and don’t need to take any action.


とは言いながらも、脆弱性は残っているので、ちゃんとアップデートしておきましょう。アップデート後は、古いライブラリを読み込んだままだったということがないように、サーバを reboot しておくといいと思います。

# lsof -d DEL


して、かたっぱしから該当する daemon を再起動するってのでもいいかもしれませんが。

ちょっと不安なのは





このあたりですかね。環境によっては、偽造パケットというかたちで差し込まれたりする可能性もあるので、注意が必要です。
そういった不安がある環境で、どうしてもすぐにはアップデートできないなら dnsmasq を仕込んでこいつにリゾルバを向けて、応答を受けてもらいましょう。これも有効な workaround となります(追記：後述しますが、どうもこれも怪しそうです。workaround探している間にアップデートしてしまいましょう。）

ps. どうでもいいですが、unbound の do-not-query-localhost が default で yes になっていることに気づかずに(というか、そもそもそういう設定があることに気づかずに）、なかなかテストができずにハマりました……

追記その１: 2016/02/18 02:17 JST



との情報が。

https://access.redhat.com/articles/2161461

には、下記のような記載があります。

2. Can a trusted DNS resolver protect against this issue?
A trusted resolver, in a default, protocol-compliant configuration,
cannot mitigate this issue because potential exploits could involve
syntactically well-formed DNS responses.


つまり、DNSキャッシュサーバでは仕様に沿ってないパケットは SERVFAIL で落とせるけど、仕様に沿ったパケットはリゾルバに返してしまうので、そういったパケットを通じて攻撃可能だということのようです。

なので、Google Online Security Blog の内容も加味してまとめると

(1) DNSキャッシュサーバでは、完全には攻撃を防げない
(2) getaddrinfo() の脆弱性を付くには 2048バイトを越えるレスポンスである必要がある
(3) dnsmasq のように(追記：どうやら後述するように、dnsmasqでは十分な制限を掛けられない可能性があります）、レスポンス長に制限(2048バイトを越えさせない）が掛けられるものだけを使えば緩和策として使える

ということのようです。aws が自身のDNSキャッシュサーバを利用している限りにおいては影響がないといっているのは、スタブリゾルバへの返信が2048バイトを越えないようにしているぜ！ということなのかもしれません。

ともあれ、ここに至っては下手に回避策を探るより、素直にパッケージをアップデートしてサーバを再起動しておいた方が無難ですね……

追記その２: 2016/02/18 15:50 JST

dnsmasq が緩和策として使えるとありますが、これはおそらく 2.73 から導入された

/* src/config.h */
#define SAFE_PKTSZ 1280 /* "go anywhere" UDP packet size */


これを指しているんだと思います。ハードコーディングで 1280バイトに制限されているので、攻撃パケットは届かなくなります。

On CVE-2015-7547 - glibc/getaddrinfo
http://lists.ipfire.org/pipermail/development/2016-February/001545.html

ちなみに、最新の dnsmasq-2.75で実行するとこんな感じです(+ignore をつけることで、TCPのフォールバックを起こさないようにしています）

$ dig +dnssec hiv dnskey +ignore

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.2 <<>> +dnssec hiv dnskey +ignore
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25086
;; flags: qr tc rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;hiv. IN DNSKEY

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: 実行した日付
;; MSG SIZE rcvd: 32


ですが、TCPにフォールバックさせると

$ dig +dnssec hiv dnskey +short
;; Truncated, retrying in TCP mode.
256 3 7 AwEAAaaV7VJUrPL0rN5/eMz3l4v9ur0xPYz0+DWpioxK7hqSmsV18oGW Zq3mHfKH8fSAkaMIlmWvqT64m60hthhdW5YZC3GQ0HzI8mwAebEkiDuc WjKME3Lk3ktC0mhlTMWjsF8MwAF2cE+1CczLHeHWrgkR2Y5qPgd14fwo 474g2Nuf
257 3 7 AwEAAYM1Sl/orr8SqlvM6ShxKBdJMSOeD7HcTFP+TTDpVJpSHBhmAsMb 30JtMRo68dsG4rIBBpc69718m0j1l8zK1uNxoJx5UkfNWG0GoOp6EKur LkLTk3luzDNmj3jrgS4oz6ztb6QYsj0hnKgMA7HW335Cb14J+vSATDpj 79cnMa4h0Ik7pIufPmAYFmQWBZeOr+99QOdzqP5zX9j5nyOEbGv82+xD 4bcFstecZ6In8WdscwoglhXdPCY1ZEtbEGiIS21ENx+o2CWAaFHpiIua sjbYVQd6+HzNSBLagDx7+aRHqDCqux6ezHGw3wbVxkHB7OP1sAcRTJX+ 85rOjmXCJss=
257 3 7 AwEAAY/iJlahfRMvTBe89WI1KnkyOzhOapyM790ybtDXYd0Uf2C7T2VN DyMabc8mUaZA36F6aUpMmQW21SzoxtrJgzvJFgrxuhkU0reyczS/bOx7 lgH10VXdaFj2mDVeXJALl1P6JQ3gwMjD6O4+z/su2C6vrtIrSfexeI4o HWZxdMQ2Y123lq1nz1ZgIbJSWJOQbaFf3cZm1qETK4R8yEATgCfnZCQP rxb424FNsR8KgNsVNUevXDgbbzwVYY3y4dMqsDXMXj2pekJgzY2h2dAZ h50NvjXbWOcbcsurv5qEiY6lZ2F59KN6vn9zYiICE5c7BUbI6MgskRQ7 Ny53Oj4pMdk=
256 3 7 AwEAAa6bxHsMEnf15WewlIH4t8rtq2kFfk7XsOp78U+wRHfE5ycPx7WS hqNQ8lpcAQyEtob0GERdaaSA56pDVhBUt7FWgS0UKejhe/NUBEFXZ0J0 X2KzH25BNO0VFDutRbk9lbcv3jO9Is//mxRdFm3qQbdSXjyh7AGRWs/9 Bi8EhXBcX/bFnfdQDw6K5dsJTCzF5cp2+dUQ79ZAGlVacURkvvIPXd8N TJfuOgdNArXKbnEvUATuxwPM3rtnjWNTMIl5ONk5kn24eCpjyfzrOVVb KxvvhetNN9znv4xlZIQaLw+ybPfz4BgbKKwDjQr62H4E0fSyqRCBONaa 9sN+5TwV/i8=
256 3 7 AwEAAW+TjE1zmCMfjLHfwz0OlPh4daGbN50xIEFsXRmlPNQN8pVJHIpf 7NMooeg9yUj607O3cMN/T2I8TL2cjqOL+eLvepNc3Fp+J2ohlEI6tHmL C5mTZkU1xGD7myygnX/XelU7eAaHNdIkghRuzo3KSg0zvCBSeslCON4H 0xDYWYEr
257 3 7 AwEAAbwvxlNQlQoVmdOKIA6Mb3EpOCXFZicDnNEAkAz3I7xHmOm3kCbf Z/w2vY9VMiTLBafXqjFVgxH33+fKlOKL0gR5iwTLC6W3boH8up1icAZp X2wMcYhS2Mauj/MGBUtQokXoBuM758K7+rq2r3Or9KX5fHYbk6bNi8cH 6ThCWcmXEptAb1vLjYaIyJtj6IYjnkt0LOrUUOCDrj+oOkYXXvUX1ZP3 kVvS677Ch00jjDQuooTQ+l/AgI2cU7wIl2peTu/ZnaFzFVsvzD2vTD0d g0lzwMCa78smO/WLJpTtmptbPnK8ct1QdWbquALlrQ51bOOrjVaU32KU uAws7EgLnnE=
DNSKEY 7 1 86400 20160319061524 20160218061524 43515 hiv. odss/n3ue7l0Omba5suryXMZoRZiLZ9Qhq6Nv/az/y4HvrSqpRiB69XD /lVQGjKf44iNFtoxaL+K8qZxvDvHrWwVGpvGZjG8utB9Qhs0kaUUKnkT fbz1PamWT5BSvG6gSB2JSsN2BKlwBSuo8yQfgXNSNjO3Hf+mEVWzOB5i z6GRRohA9YjwdsRV3ZHqQMVhzCN3wTEH5fNg+cVunr41Kenx/glMOyjc nJseFXEiZJo3J3ejzerswYWMUcqjf62Yo81Kv47SLVa6pHHuUjA58Fhp z2btvLHy77YKOViYMzBIuiNluShjcnWJTWkeUGGZ4hpYE8dYYq4529VE wLLRMw==
DNSKEY 7 1 86400 20160319061524 20160218061524 56208 hiv. JtWLdWOmsDvis1P4kZad+CafHR/bLnY1u4vMe4ytqmOrvftqGidv3CYw n7cff13fusjBdnuoHpT/JP0NIpPg/W6gkNyF1iwLCAzFwFCYjb8mtOIc bWOYuJTdtY/aO0XngVr0QDTOLEUfns5NcXsqu82Ne40VOAhm+zo08CeY V66ex21CMgt33scYT9c8HzCloDn14ltAeG3aZcb9C7wCBOUnmRYvFDZZ t1eLsGBER+2pScQlhXTsx/+gmDphCULzvjoRUCzWw3gQ4+Bfk3AiLIqn aaSIJSLRhr+5Ak0XoVKCtYFaVhk9fyd2U7YGAUlF0pbng+WMGbe1KY2k QX4gGw==


のように、普通に制限しているはずの1280バイトを越えるレスポンスを受け取ってしまっています。なので、緩和策としては不十分じゃないでしょうか？(間違っていがら指摘願います。ちなみにTCPなので関係はないんですが念のため edns-packet-max も設定してみましたが、ダメでした）
もちろん、UDP／TCPともに制限が掛けられるものをお使いならばそれでいいとは思いますが、そうでなければ workaround は諦めて、可及的速やかに該当パッケージをアップデートすることをお勧めします。

あと、iptables/ip6tables で制限を掛けようとしている方もおられますが、UDPはいいんですが TCPは MSSでぶった切ってるだけなので、パケット長で引っ掛けようとしても、マッチしませんでした（これは私も気付かず、詳しい方に教えていただきました）。なのでこれも対応としては不十分だと思われます。

ということで、重ねての結論ですが、さっさとアップデートしましょう……

追記その３: 2016/02/18 18:15 JST

bind や unbound の max-udp-size による制限も、オプション名から考えても、UDP限定です。残念ながら、これ自体は実際に検証しませんでしたが、TCP には無力のはずです。改めて RedHat さんの

Critical security flaw: glibc stack-based buffer overflow in getaddrinfo() (CVE-2015-7547)
https://access.redhat.com/articles/2161461

を読むと

The TCP-based vector could be mitigated by a trusted recursive resolver
on a trusted network which limits the size of individual DNS responses to
1023 bytes and below. However, such a capability is not common in DNS resolver
implementations because it breaks the DNS protocol. (The buffer size
configuration option offered by most resolvers only applies to UDP, not TCP.)
Rejecting AAAA responses, without also limiting the size of A responses, does
not mitigate the vulnerability.


とあるように、やはり TCPへの対策にはならないよと書いてありました。

追記その４： dnsmasq に関する dig のコピペミスがあったので、直しました。

追記その５： 2016/02/19 19:46 JST

IIJさんより詳細な解説情報が出てきました。流石IIJさんですね！

CVE-2015-7547 glibcにおけるgetaddrinfoの脆弱性について
https://sect.iij.ad.jp/d/2016/02/197129.html





という懸念も確かに気になるところですが、IIJさんの考察による結論にはすごく納得がいくところです。

悩ましいところですが、どっちが正しくても glibc を上げとけば問題ないので、やっぱり上げておくことをお勧めしたいです。

固定リンク コメント
このエントリーをはてなブックマークに追加

2015-10-26 Mon

■ sitecopy の sftp で、port番号を変える [Linux]

リモートとローカルの間で、コンテンツを同期してくれる sitecopyですが、マニュアルにはきちんと書かれていませんが、sftp にも対応しています。

ただし、port番号が 22番に固定で .sitecopyrc に

protocol sftp
port 2222


とか書いても、22番ポートに接続しに行きます。なので、22番ポート以外で運用していると

ssh: connect to host ftp.example.jp port 22: Connection refused
Connection closed


のように弾かれます。

逃げ方は用意されていて

protocol sftp
rcp "sftp -oPort=2222"


と掛けば、2222番ポートを使って接続してくれます。

Subject: Re: sftp on different port than 22?
http://osdir.com/ml/web.sitecopy/2005-03/msg00007.html

もう 8年も前の記事なんですねぇ。ちなみに sitecopyは ftps には未対応です。残念……

固定リンク コメント
このエントリーをはてなブックマークに追加

2015-10-22 Thu

■ 本番サーバと検証サーバの混同防止策 [Linux]

下記のようなツイートを見かけた。



ほぅ……/etc/motd にエスケープシーケンスを埋め込んで実現してるみたいですね。
さっそくやってみました。

Image

おお！このインパクトはすごい。本番サーバに設置しておくと、いい感じ。本気でいいかも……

固定リンク コメント
このエントリーをはてなブックマークに追加

2009-09-02 Wed

■ mondorescue 2.2.8 [Linux]

久しぶりに、mondorescueを使ってみる。CentOS用のパッケージは古いみたいなので、rhel からダウンロード。

ftp://ftp.mondorescue.org/rhel/5/

CentOS5 を、mondorescue でフルバックアップして再インストールしようとすると、なんか、LVM の初期化に失敗したとか言われてうまくいかない。

Failed to Initialize LVM...


shell に落ちて、初期化しようとすると、すでに system で使われてるからと言われて初期化できない。なにこれ？ググると、バックアップしようとしているサーバが、SELinux を有効にしているとダメらしいよと書いてあるけど、なんか違う気がする。

で、いっそ LVM 止めるか！と思って、初期化しようとすると、やっぱり該当のデバイスの初期化ができない。mount されているわけでもないし、わけわからん。busyboxに lsof もないので、なにがデバイスを掴んでいるのかもよくわからない。

散々悩み通したんだけど、どうやらバグの模様。次のバージョンで修正予定とのこと。

http://trac.mondorescue.org/ticket/327

デバイスを dmsetup が掴んじゃうみたいなので、インストーラの起動時に

nuke nompath


を入力するか(上の例だと、dmsetup を起動しない＆自動インストール）、mondorescue のインストーラで shell に落ちてから

/sbin/dmsetup remove_all


すれば、デバイスが解放されるので、あとは

# mondorestore


で、バックアップリストアを再開すれば OK。あー以前はもっとさくっとバックアップできたのになぁ......でも今回のトラブルを別にすれば、やっぱりいいバックアップツールですね :-)

と、万々歳かと思いきや、再インストールしたサーバにログインできない orz
どうも bash に実行権限がないとか起こられている模様。そんなバカな！と思ったら、今渡こそ SELinuxが原因だったみたい。どういう動作原理なんだろう......悩んでいる時間もなかったので、grub の boot option に、

enforcing=0


として回避。SELinux で幸せになれる日は来るんだろうか。

関連:
[2006-12-26]

固定リンク コメント
このエントリーをはてなブックマークに追加

2009-09-01 Tue

■ クラウド製品 [Linux][仮想化]

自分の中で、クラウドの定義が揺らいでるので、ちょっと時間を取って整理しなおさないといけないなぁ...

Xen Cloud PlatformとVMware vCloud ExpressがVMworldで発売へ
http://www.virtualization.info/jp/2009/08/xen-cloud-platformvmware-vcloud.html

OVFの動向やOpen vSwitch も気になるところ。それより VMAN。これ、読まないとだめかなぁ。日本語訳があるといいのに......まぁ読むか。

http://www.dmtf.org/initiatives/vman_initiative/

固定リンク コメント
このエントリーをはてなブックマークに追加

2009-08-31 Mon

■ Internet Conference [Linux][仮想化]

今日は、Internet Conference で仮想化について話してきます。

固定リンク コメント
このエントリーをはてなブックマークに追加

2009-03-01 Sun

■ 鳥取環境大学でお話　 [Linux][IPv6]

固定リンク コメント
このエントリーをはてなブックマークに追加

2009-02-02 Mon

■ rdesktop が便利！ [Linux]

rdesktop での日本語入力について


オプション -k ja をつけても日本語配列のキーボードにならない
特に、半角／全角キーでIMEの切り替えができない


http://blog.goo.ne.jp/sito1980/e/aa3d332020243e47544f3a5d2b24d8c2

固定リンク コメント
このエントリーをはてなブックマークに追加

2008-12-22 Mon

■ CentOS の古いパッケージアーカイブ [CentOS][Linux]

社内のミラーサーバは最新のものが sync されているので、古いパッケージが欲しくなった時に困る。
古いパッケージは

http://vault.centos.org/

からダウンロードできる見たい。ありがたい......

固定リンク コメント
このエントリーをはてなブックマークに追加

2008-12-22 Mon

■ TOMOYO Linux [Linux]

TOMOYOを入れるためのI/Fがkernelに入ることになったみたい
http://d.hatena.ne.jp/kinneko/20081217/p10

おお？ちょっと注目だな。

固定リンク コメント
このエントリーをはてなブックマークに追加

2008-12-12 Fri

■ Virtuozzo メモリ管理 [Linux][仮想化]

http://kawa.at.webry.info/200812/article_1.html

各社のサービスにおける設定が見え隠れしていて、興味深いですね:-)

固定リンク コメント
このエントリーをはてなブックマークに追加

2008-12-12 Fri

■ KeePassX [Linux]

http://journal.mycom.co.jp/column/softwares_for_macosx/041/index.html

Linux/MacOS/Windows で動作するパスワード管理ツール。いいかも？

固定リンク コメント
このエントリーをはてなブックマークに追加

2008-12-09 Tue

■ セキュアOSの落し穴 [Linux]

http://kumaneko-sakura.sblo.jp/article/23840947.html

via セキュリティmemo

む？

固定リンク コメント
このエントリーをはてなブックマークに追加

2008-11-13 Thu

■ dbench を使ってみる [Benchmark][Linux]

ふと気になって、



と



で HDD を mount した際に、スピードに差異があるのか気になったので dbench を使って、調べてみました。共に USB接続です。

# dbench -c client.txt -t 60 40


で測定。1回だけしか測りませんでした。mount pointは同じ場所。

Throughput
これdo台MASTER 77.6407 MB/sec 40 procs
裸族の頭 IDE+SATA 87.2758 MB/sec 40 procs

繋いだ HDD は、



です。あまり意味がある benchmark ではありませんが、取ってみたということで。

＃外付で使ってるのは、うっかり、IDE じゃなくて SATA端子のHDDを買ってしまったから…

固定リンク コメント
このエントリーをはてなブックマークに追加

2008-11-12 Wed

■ CrossOver for Linux で Office2007 を使う [Linux]

が、インストールの時点でエラー orz

ググったところ、

http://www.codeweavers.com/support/tickets/browse/?ticket_id=6840

まさにこのエラー。どうやら X の色が 24bit じゃないとだめらしい。以前 xorg.conf で 24bit 決め打ちで書いたけどなぁ思ってたんだけど、確認したら、たしかに 16bit で動いてた。

DefaultDepth 24


に修正して、Xを再起動。今度はうまく動いた。

固定リンク コメント
このエントリーをはてなブックマークに追加

2008-11-06 Thu

■ 全バージョン？の Kernel Source [Linux]

LXR / The Linux Cross Reference
http://lxr.linux.no/

via http://slashdot.jp/~okky/journal/457580

単純だけど、こういうのはありがたい

固定リンク コメント
このエントリーをはてなブックマークに追加

2008-10-23 Thu

■ zSeries [Linux]

http://enterprise.watch.impress.co.jp/cda/hardware/2008/10/22/14132.html?ref=rss
http://enterprise.watch.impress.co.jp/cda/foreign/2008/10/22/14130.html?ref=rss

最近、妙に zSeries のニュースが目に止まる気がする。そういう時期？

固定リンク コメント
このエントリーをはてなブックマークに追加