  |
はてなキーワード: WebSphereとは
それも開発したのは俗に言うスーパーハッカーとかスタープログラマとかではなく、当時全く無名だった大学院生。
だから開発の目的だって、勉強のためかお遊びなのかもよくわからない話だったり。
そこに来て、型落ちロースペックPCでも動かせるフリーのUNIXライクOSとなると、今だったら
みたいに冷笑されかねない話だ。
実際リリースされて間もない1990年代後半から2000年前後辺りまでは
「流行の追っかけしか能がない、ワナビーのクソガキ共が使うおもちゃ」
くらいの立ち位置だった。
当時流行っていたネットスラングに類似する煽り方をするなら「アンチMS厨御用達」みたいな感じだろうか。
「そんな事があったんだー」
で終わるくらい、Linuxは誰でも、どこでも使うOSになっているのは御存知の通り。
UNIX系OSで最もメジャーと言うだけではなく、システム開発やサーバ構築でWindowsサーバとともにほぼ必ず選択肢に挙げられるようになって久しい。
更に直近の10年で、気がつけば世界中で使われているスマホの殆どがLinuxベース(Android)になっている。
つまり誕生からの四半世紀で爆発的に発展・普及したというわけだ。
本当にLinuxを使うなんて今どき普通すぎて、特に取り立てて言うことではない。
一方でLinuxよりもずっとフリーUNIXとしての歴史があり、かつては定番だったBSD系なんて、今やAppleのお陰で辛うじて延命している状態なのだから、これまた隔世の感がある。
とはいえ気になるのは、何をどうやったらここまで信じがたい躍進をしたのか？という事情。
ホビー用途とビジネス用途では要求される信頼性のレベルが異なるので、誰かがそこに手を入れないとこのような発展は望めない。
そこでは大企業がきちんと専門家を入れる形で関わるならなお良い。
そうなるとやはり、まずIBMが白羽の矢を立て、次いでGoogleが積極的にコミットするようになった流れが大きいのだろうか。
このうちGoogleは「弊社はオープンソースにフリーライドしているわけではない」アピールや自社サービスのコストダウン、更にはモバイル分野への進出という諸々の目的に好都合だったのだと思う。
何しろ元々IBMはAIXという自社製UNIXを売ってる会社であり、これを用いた各種サーバ構築はお家芸だったわけで。
更にこのAIXにDB2やWebSphereを組み合わせる方式は、2000年代くらいまではエンタープライズアーキテクチャの2大巨頭だった。
(もう1つはSolaris+Oracle+WebLogic)
そんな会社がLinuxに手を出して、一体何の得があるんだ？という話なわけ。
一つ考えられるとすれば、AIXもDB2もWASも買えない貧乏人もとい中小規模の顧客から、せめて構築と運用の手数料だけでも取るためとか？
まあ確かに一時期流行ったLAMP(Linux+Apache+MySQL+PHP)なら、ライセンス料なしでハードも安価なPCサーバになるので、導入のハードルは低い。
というわけでLinuxの草創期を知ってる人間からしたら、今の状況は世の中が変わりすぎなくらい変わったという感覚が強い。
Androidの不具合がスマホのメーカー依存or機種依存だったり、そもそもLinuxのデスクトップ用途が未だに少数派なのは今後も変わらないだろうけど、逆に変わらないのは多分それくらい。
あとUbuntuは嫌い。
原文：https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題：Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日：2015年11月12日（午後にタイトルを日本語にしました）
－－－－
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者：Bernd Eckenfels（コミッター）, Gary Gregory（Apache Commons副責任者）
AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときのセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクト・シリアライゼーション（訳注：seriarization／シリアル化／直列化＝ネットワークで送受信できるようにメモリ上のオブジェクトデータをバイト列で吐き出すこと。シリアル化されたJava オブジェクトはRMIなどのリモート通信プロトコルで使用される。）を使用する際に任意のJava関数の実行や操作されたバイトコードの挿入さえもを行う方法の説明です。
Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereやJBoss、Jenkins、WebLogic、OpenNMSといった様々な製品を調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオを記述しています。
両者の調査活動は、開発者がJavaのオブジェクト・シリアライゼーションに信頼を置きすぎていることを示しています。認証前のシリアル化されていないオブジェクトにも。
Javaにおけるオブジェクトのデシリアライゼーション（訳注：de-serialization／非直列化＝ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと）が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効なオブジェクトツリーだけを保証しています。
不幸にも、型のチェックが起こるまでの間に既にプラットホームのコードが生成されて、重要なロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者のコントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまいます。脆弱性のあるアプリケーションのクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は（ローカルのOSのコマンドを実行するRuntime.exec()の呼び出しを含めて）機能を実行することができます。
これに対する最も良い防御は、信頼されていないピア（通信相手）とは複雑なシリアル化プロトコルを使うことを避けることです。ホワイトリストのアプローチ http://www.ibm.com/developerworks/library/se-lookahead/ を実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができます。しかしながら、これは常にできることではなく、フレームワークやアプリケーションサーバがエンドポイントを提供しているような時にはできません。簡単な修正方法がなく、アプリケーションはクライアント・サーバプロトコルとアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。
これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムや Springフレームワーク、 Apache Commons コレクションからのクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン）を見つけています(訳注：provided)。これはこの脆弱性のエクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日、攻撃者が簡単に得られるチェーンです。
(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c
この脆弱性のために利用される(訳注：blamed)ことができない確かな機能を実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的に修正していくことが要求されます。モグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。
Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題に対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています。議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能を提供するかどうかです。
これには前例があります。Oracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャーが定義されているとデシリアライゼーションを拒否します。
これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできます。Apache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャーの存在と独立したこの機能を無効化することを計画しています。
しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンの Apache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。
このブログポストのレビューのために Gabriel Lawrence に感謝したいと思います。
Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラスを提供する Java ライブラリです。InvokerTransformer はコレクションにあるオブジェクトを（特にリフレクション呼び出しを通じてメソッドを呼び出すことで）変換するために使うことができる Transformer ファンクションインターフェースの実装の一つです。
一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]
コメント：
Oracle は Weblogic にセキュリティアラートを発行しています：
CTC → A社の発注が 5000万で、B社に丸投げだったら、2500万くらいだろう。
A社のCTCへの見積もりは、見積単価が 120万/人月（ちょっと安いか？）で、40人月くらい。
A社の原価率を85% として、原価が 34人月。
B社の単価を 80万/人月としたら、マックスで 2720万。
多少駆け引きがあって、2400～2500万ってところが妥当では。
・ニトリは内製っぽいけど...
ニヨニヨするとか言われてたページには、こんなコメントが入ってる。
＜!-- Customize for NITORI start--＞
＜!-- Mod for Nitori End --＞
WebSphere をミドルウェアに決めたときに、カスタマイズも発注してたことは十分考えられる。
「これは仕様通りです」とかなんとか、そんなやり取りをいっぱいしたんだろうな...
・ベータ版なんて作らない
ウォーターフォールで一直線。
ニトリ社のレビューというか、受け入れ試験があったとして、そこで出されるのは
完成品、もしくシステムテストがある程度残っている本物。
リニューアルオープンが延期したのは、本当に間に合ってないだけ。
6月1日が延期したのも、ろくに動くようなものじゃなかったんじゃないか。
リニューアル後の性能問題も、何だかんだで一週間で復旧できたわけだし。
・表に出ないだけで...
ふわっとした仕様書を杓子定規に実装した、というよくあるパターンな気がする。
別ウィンドウで表示される「リニューアルオープンの遅れに関するお詫び」にまで販売サイトのヘッダ、フッタがきっちりと表示されている。
http://www.nitori-net.jp/store/ja/ec/%E3%81%8A%E7%9F%A5%E3%82%89%E3%81%9B6%E6%9C%8823%E6%97%A5
この硬直さもウォーターフォールっぽい。
css がど真ん中に挿入されているのも、さもありなん。
理由くらい書けよ糞が
他のWindowsプログラムがやっていて、多くの方が「できて当然」だと思っていることは、7割くらいであれば.NET(フレームワーク名)を叩けばできます。
.NET対応言語はC#、VB.NET、J#、F#、JScript.NET、C++/CLIなどがあり、実際の開発においてはこれらの中から自分に合った言語を選ぶことになります。
個人的な感想ですが、この中で最もゆとり仕様なのはC#です。StackOverflowなどのノウハウが一番蓄積されているのもC#だと思います。
「頻繁なアップデートを追跡しないといけない」「Visual Studioが必要」という問題はありますが、がんばってください
なお、.NETはメモリを食うので、数値計算みたいなことをしたいのであればC++が現状一番まともだと思います。がんばってください
昔のMacのプログラムのGUIはCarbonというライブラリで作っていました。今はCocoaというライブラリで作っています。
残念なことに、どちらも言語はObjective-Cです。がんばってください
ブラウザアプリは、ユーザのWebブラウザ(Chrome、Firefox、Opera、Safariなど)上で動作するシステムと、遠隔のサーバ上で動作するシステムが連携して成立します。
従って、ブラウザアプリを作る言語は、サーバ用言語とクライアント用言語の2種類を考えなければなりません。めんどくさいですね。
ひとたびそのめんどくささを突破してしまえば、Webブラウザさえあればどこでも動くようになります。素晴らしいですね。
クライアント用の言語は、まぁ、JavaScriptしかないと思います。がんばってください
JavaScriptも(正直なところ)あまり褒められた言語ではないので、近頃ではもうちょっとまともな言語を作って、それをJavaScriptに変換する方法が取られたりします。CoffeeScript、TypeScript、Haxeとかですかね。がんばってください
JScriptとかいう、名前が紛らわしい上にゴミブラウザ上でしか動かないゴミ未満言語もありますけど、そんなもんで作っても私の環境では動かせませんので悪く思わないでください。
そもそも選択肢が全くありませんので仕方がないです。がんばってください
Xamarinがあるじゃないかって？まぁそういうのもあるかもしれませんね。がんばってください
私の勉強不足で、Java以外の選択肢は知らないです。Java以外にあるんですかね？
Perlは使い捨てスクリプトを作るのに適しています。CPANクライアントは昔から安定して動きません。だいぶオワコン化してます。がんばってください 私は鞍替えしました
PythonはPerlより見た目がすっきりしたPerlです。easy_install・pipはすごく安定していてびっくりします(Windows除く)。3系とかいう邪念は捨てて2系教の悟りを開きましょう。がんばってください
RubyはPerl(の処理系のソースコード)より(処理系のソースコードが)綺麗なPerlです。私の手元のUbuntuで「ruby」と入力すると「Command not found.」と返ってくることからも解るとおり、多くの*NIXではOS標準でインストールされておりません。昔のgemは何故あんなにすごい時間をかけてrdocを作っていたのでしょうか。日本人が作ったのでムラ意識の強い日本人の仲間が大勢います。他の国は知りません。がんばってください
これ以上言語を増やすのはやめましょう。バベルの塔で大勢の人間が不幸になったのに、それを人間が自ら引き起こしてどうするんですか。
言語処理系を作るのであれば、BNFという言語で文法を定義して、yacc・bisonというツールに食わせればひな形ができます。ぶら下がりelseとの格闘が待ってますが、がんばってください
1からOSを作った方もいますが、デバイスドライバの流用などを考えると、だいたいはLinuxやBSDのソースコードを改変するお仕事だと思います。
昔はCGIと言っていました。所詮は80番ポートでlistenするだけのプログラムであり、BSDソケットをlistenできるライブラリを有する言語であれば何でもいいのですが、いくつかの宗教があります。
PHPはバンドネオンと同じくらい習得が困難な言語なのに、宣伝の仕方を間違えたために「自分はできる」と勘違いしたプログラマが暴徒と化し、イスラム教と同じくらい不当に低く評価されている言語です。きちんと勉強して使う分には、悪くない選択肢だと思います。がんばってください
Javaは、Eclipse・Netbeansといった超重量級IDEを起動して、Java EEやSpringといった超重量級ライブラリに依存したwarを、Jboss・WebSphereなどの超重量級アプリケーションサーバ上で動作させるため、メモリが貧弱な環境ではIDEとサーバを同時に起動すらできません。サーバのメモリが潤沢であれば悪くない選択肢だと思います。がんばってください
C#は、選択肢が全くないことを除けば、状況はJavaとあまり変わりません。Microsoftがお好きな方、何かの間違いでWindowsサーバを使わざるを得ない方であれば、悪くない選択肢だと思います。がんばってください
Goはよくわからないですがきっといい言語です。がんばってください
http://d.hatena.ne.jp/aike/20080615
この記事が面白かった。2008年のだけど、今でも変わらんと思う。
SI業界での即戦力とは「金融工学と財務会計に詳しくてCOBOLとABAPが読めてWebSphere上のJavaが書けます」といったような人なのだが
インフラ系の自分がSIerで最初のプロジェクトに配属されたとき、必要とされた知識は主にWindows Server(ActiveDirectory)だった。
人によっては、大学の情報センターの手伝いをしていたという学生が、ADなんか触っていたりするらしいが、情報系の学生でも
WindowsServerなんて触ったことがない人間がほとんどだと思う。
自分は、LDAPとDNSは知っていたけど、ADなるものはよくわからず、標準的な規格、テクノロジーと、マイクロソフトのプロダクトの間にあるギャップに当時かなり苦しんだ記憶がある。
LDAPもDNSもまともに知らないシステム管理者が、いっぱしの「エンジニア」ヅラして、仕事をしているのがSI業界なんだなあと知ったのは、そののちすぐのことだったけど。
http://ja.wikipedia.org/wiki/%E3%83%9D%E3%83%BC%E3%82%BF%E3%83%AB%E3%82%B5%E3%82%A4%E3%83%88
元々ポータルとは、港(port)から派生した言葉で、門や入口を表し、特に豪華な堂々とした門に使われた言葉である。このことから、ウェブにアクセスするために、様々なコンテンツを有する、巨大なサイトをポータルサイトというようになった。入口、玄関という意味でエントランス(entrance) を使わなかったのは、ポータルには「豪華、堂々とした」という意味合いが強かったためと思われる。
ポータルサイトは、検索エンジン、ウェブディレクトリ、ニュース、オンライン辞書、オークションなどのサービスを提供し、利用者の便宜を図っている。
ポータルサイトのビジネスモデルは、サイトの集客力を生かして広告や有料コンテンツで収入を得ることである。1996年以降のインターネットブームに乗じて、多くのポータルサイトが乱立したが、徐々に統廃合が進んでいる。
初期のポータルサイトは自前で検索エンジンやウェブディレクトリを運用していたが、情報の肥大化に対応しきれずアウトソーシングが多くなった。
生き残りをかけて、特定の地域サービスに特化した地域ポータルサイトや、インターネットサービスプロバイダ（プロバイダ）のサービス情報サイト、育児、環境、オルタナティブカルチャー、音楽、女性の生き方などにテーマを絞ったポータルサイトもある。不特定多数のアクセスがあるだけに、こうしたポータルサイトにアダルト情報を持ち込むことの是非を問う意見もある。
近年ポータルサイトから派生した、企業「ポータル」が関心を高めている。企業に散らばっている様々なデータや情報を効率的に探したり利用するためにパソコンの画面上にこれら情報やアプリケーションをポートレットとして集約表示する技術がでてきた。画面は利用者の要求によって自由にレイアウトを変更でき、例えば社長用の画面、部長用の画面、営業用の画面、技術者用の画面など、それぞれの職種・役割に応じた最適画面を作ることが出来る。代表的な「ポータル」製品としては、IBMのWebSphere PortalやMicrosoftのMicrosoft SharePointなどがある。
http://e-words.jp/w/E3839DE383BCE382BFE383ABE382B5E382A4E38388.html
インターネットの入り口となる巨大なWebサイト。検索エンジンやリンク集を核として、ニュースや株価などの情報提供サービス、ブラウザから利用できるWebメールサービス、電子掲示板、チャットなど、ユーザがインターネットで必要とする機能をすべて無料で提供して利用者数を増やし、広告や電子商取引仲介サービスなどで収入を得るサイトのことをいう。Yahoo!やExcite、Infoseek、Lycos、gooなどの検索エンジン系のサイトや、Netscape Communications社やMicrosoft社などのWebブラウザメーカーのサイト、AOLやリクルート、Walt Disneyなどのコンテンツプロバイダのサイト、So-netやBIGLOBE、ニフティなどのネットワークプロバイダのサイトなどがそれぞれ強みを生かしながら激しい競争を繰り広げている。
http://d.hatena.ne.jp/keyword/%A5%DD%A1%BC%A5%BF%A5%EB%A5%B5%A5%A4%A5%C8
portal site
番組的には簡単な表現のほうが良かったんじゃ？
