  |
はてなキーワード: Jbossとは
２０１９年６月を持ちまして、大学新卒入社後約７年勤務した会社を退職しました。
良い機会なので記録に残したいと思います。
地方国立大学の工学部情報科卒。保有資格は基本情報、応用情報技術者。
日立製作所の子会社としてシステム開発、運用、保守、構築を担う会社。
社員数は２～３０００人。
入社してから運用、構築業務を行い、開発は未経験。担当したシステムの分類は公共系のみ。
基本的には「客先常駐」で、システムが安定稼働に入った段階で別のプロジェクトに参画し、構築を行った。
サーバ構築（オンプレミス）業務としてOS、MWの導入に携わることで、構築に必要な知識を得られた。
ちょっと残念だったのが日立製品（JP1、uCosminexus Application Server）に携わる期間が長かったこと。
他社のAPサーバ（Weblogic、Jboss等）も触れ、インフラ屋さんとしての価値を高めたかった。
力不足ではあったが５年目ごろから小さいチームのリーダになり、進捗管理、顧客調整等を行った。
協力会社のメンバーは全員年上で、コミュニケーションにおいて苦労した部分もあったが、
人に恵まれ、大きな問題なくプロジェクトを遂行できた。若いうちにリーダーを経験できたことはとても良かったと思う。
最終年度で約５６０万。
◆内訳
・基本給 ：２６万
・賞与 ：約６０万（年２回で業績により若干増減あり）
そのため、仕事がないのに残業するという所謂「生活残業」をする人も少なからずいる。
また、最近は働き方改革で定時退社を励行しているため、残業についてはかなり厳しくなっている。
昇給は若干ではあるが、たぶん毎年した。
昇格については、早い人で８年目から主任、１５年目くらいで課長になる。
主任の年収が６００～８００万（残業による）、課長の年収が９００～１０００万。
主任まではある程度の実績とポイント（資格等）があれば誰でもなれる（はず）。
ただ、課長以上になると「上が詰まっている」＆「製作所から下ってくる」ため、相当優秀でない限りはハードルが高いと思う。
劇的に仕事が増えて部＆課が新しく作られれば話は別だが。
プロジェクトに合わせる形になるが、フレックスのため勤務体系が自由。
上述の通り、残業についても働き方改革で定時退社を励行しており、男性の育休取得も推進している。
環境についてはシンクラ端末が一人一台支給され、インターネットがつながる場所であればどこでも仕事ができるという状態。
どこでも仕事ができてしまうため、公私のバランスがとりずらいという方もいるかもしれないが、私にとっては最高でした。
これさえあれば在宅勤務も可能なので、娘が熱を出し保育園に行けないときは重宝した。
また、複数拠点にサテライトオフィスがあり、社員証があれば使用できるため、打合せで移動が多い日はよく利用した。
働きやすい環境作りにはかなり投資されているため、恵まれた環境で仕事ができたと思う。
・残業しないと給料低い。また、担当レベルだと成果を出した人とそうでない人で給与の差がほとんど付かない。
・新しい技術に関する感度が低い。
・意識低い系がそこそこ多い。そしてその人たちは決して辞めない。優秀な若手はどんどん辞めていく。
・SIerあるあるかもだが、協力会社に丸投げのプロジェクトがけっこうある。
転職先は事業会社のIT企画部です。次が身の丈があった環境かどうか不安もありますが、新たな環境にワクワクしています。
原文：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 にセキュリティアラートを発行しています：
エディタで。vimのキーバインドで。teratermの背景色で。ログファイルの名称で。変数名で、タブの桁数で。spfileの設定で。jbossの設定のおまじないで。stratsの継承方法で。エラーのクラス名で。プロパティ名で。セッター、ゲッターを付けるかつけないかで。コンストラクタで。newを上書きするかしないかで。jreのeditionで。eclipseの見た目で。javadocのエディションで。クラウンのドキュメントIDで。githubにいくつ持っているかで。tryのインデントで。タブを表示するかしないかで。エディット中の飲み物で。待ち合わせはスタバなのかエクセルシオールなのかで。セブンイレブンのコーヒーのサイズで。そのコンビニのコーヒーが一番うまいかで。IDカードは伸びるストラップがいいのか悪いのか。寝るときは机の下か椅子を並べるのか。デスクの上にフィギュアは置いていいのか悪いのか。めんまかつるこか。
理由くらい書けよ糞が
他の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はよくわからないですがきっといい言語です。がんばってください
Eclipseがemacsやvimより優れている点を挙げてみよう。
・CVSリポジトリの構成を直接覗ける →redmineとかを使ったほうがいいんじゃないのか
・設定できる警告メッセージの種類が豊富。→警告そんなにいるのか
・復元機能が非常に充実している。 →バージョン管理ソフトがあれば普通だし
CVSのように以前の状態に復元すること、以前の状態の →diffじゃダメか、というかなんでいまどきCVSなの
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・プラグインの数が豊富、膨大。 → 数があってもつかえるのは少ない
・プラグイン開発環境もEclipse自体に用意されている。 →開発環境を使って作る程のものでもなく、バッチファイルとかスクリプトでよくね
・ライセンス形態がCPLであり商用利用もしやすい。 →eclipse組み込んで出荷するの？
・上位版にWSADが存在する。 →WSDADってなに、WebSpereの残骸？
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。→Jenkinsのほうがよくね
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力！→コマンドラインから実行するsvnコマンドを覚えておくとはターゲットでも動いて便利だよ
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ！→スタック見るだけのことじゃないの
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。→勝手に変わったら怖くない
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。→えー、今頃Tomcat
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。→それ開発ツールじゃなくて携帯でやったほうがよくね
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
他言語プラグインが充実している。→Java以外は所詮おまけだけどね
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。→それぞれ単機能のソフトのほうが充実してるんじゃないの
どうしてもeclipseというなら止めないけど
Eclipseがemacsやvimより優れている点を挙げてみよう。
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・上位版にWSADが存在する。
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力！
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ！
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
などを即座に実現できる。
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。
jboss2.4.3で、entitybeanに対してremoveメソッドを呼んだ場合、 <<
なぜかbeanのキャッシュにobjectが残存していて、さいど同じprimarykeyで
create後removeすると、remove内でDBへのconnectionを解放している
場合にSQLExceptionが発生する。やはりjbossのエラーだそうな。
一番最初のremoveでconnection.close()を呼んだままになってるから
当然。SunのEJB仕様によれば、ejbRemoveとejbPassivateはともに
beanをプール状態に移行するもので(つまり同じ動作)かつejbRemoveでは
日本語じゃねえ。
