投稿

社員(正社員・契約社員)募集のお知らせ | ライタス株式会社

弊社では、一緒に働いてくださる社員を募集しています。 ・システム開発エンジニア(Web/オープン系システム開発) ・インフラ構築エンジニア(クラウド/オンプレミス) ・インフラ保守エンジニア(クラウド/オンプレミス) ・事務(総務・経理・庶務・その他) 待遇については、ご経験や経歴等から話し合いで決定させていただければと考えています。 ご応募については、弊社オフィシャルページの問い合わせフォームよりお寄せください。

2016-2017年の年末年始の営業のお知らせ | ライタス株式会社

お客様各位 弊社の年末年始の営業予定は、以下のとおりとなります。 ご不便ご迷惑をおかけしますが、ご理解の程、よろしくお願いいたします。 2016年 12月 28日 通常営業 2016年 12月 29日 ~ 2016年 1月  4日 休業 2017年 1月  5日 通常営業 お問い合わせ等ございましたら、弊社ホームページのお問い合わせフォームよりお寄せください。 休業期間中は、何かとご不便をお掛けいたしますが、ご了承のほど、何卒よろしくお願いいたします。 本年中のご愛顧に心よりお礼申し上げますと共に、来年も変わらぬご指導ご鞭撻のほど、よろしくお願い申し上げます。

AWS VPCでのネットワークACLとセキュリティグループのハマリポイント | ライタス株式会社

AWSでVPCを扱うとき、セキュリティポリシーとして、通信制御を行うと思います。 通信制御をするときは、ネットワークACLとセキュリティグループを活用して設定しますが、ここで幾つかハマりポイントがあります。 1. ステートレスとステートフル ネットワークACL ステートレスインスペクション セキュリティグループ ステートフルインスペクション ステートレスとは、指定したポートのみを通すもので、他のポートは通信を拒否します。 ステートフルは、指定したポートを通しますが、その通信の戻り通信も許可します。 http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Security.html 2. 設定単位 ネットワークACL サブネット単位 セキュリティグループ ENIおよびグループ単位 ネットワークACLは、VPC内に定義されたサブネット単位で作成できます。 セキュリティグループは、サーバーごとに設定するイメージですが、実態としては、ネットワークカードに対して設定するイメージと捉えています。 3. ネットワークACLとセキュリティグループを両方使う ネットワークACLとセキュリティグループを両方使う場合、両方許可されないと通信ができなくなります。 ネットワークACL セキュリティグループ 結果 許可 許可 許可 許可 拒否 拒否 拒否 許可 拒否 拒否 拒否 拒否 4. ハマリポイント 上記ルールに従って通信制御を行うことができますが、ネットワークACLがステートレスのため、ちゃんと通信ポートが開いてると思っているのに、開いていなかったということがよくあります。 また、戻りの通信ポートがダイレクトポートを使っている場合、ネットワークACLで拒否されてしまって、通信できなかったということが 検証方法としては、ネットワークACLかセキュリティグループを一瞬フルオープンにして通信できるかどうか確認する方法をよく使います。 他にも、AWS全体に言えることですが、設定上限になっているものが結構あります。 事前に把握しておくと良いかと思います。

AWS APIで通信がうまくいかない | ライタス株式会社

AWS APIを実行する時に、APIエンドポイントへのアクセスをする必要があります。 この時に、HTTP/HTTPSのポートを開けておけばいいのかと思ったのですが、うまくいきませんでした。 いろいろ調べたところ、NACLのインバウンドで 49152-65535 の範囲でポートを開けておく必要があると記載があったので、設定してみたところ、うまくいきました。 http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Appendix_NACLs.html このポートのことをエフェラメルポートと言い、リクエストを効率良く処理するためのポートとして使われます。 AWS APIエンドポイントもこちらのポートを使うようですので、うまくいかないようであれば、ここも疑ってみる必要がありそうです。

IISが停止! iisresetをしても回復しない! | ライタス株式会社

 =環境=  Windows Server 2003 R2 SP2  IIS 6.0 + .NET 2.0  =現象=  HTTPアクセスが全滅  iisresetを実行しても回復せず iisresetをしても回復しないあたり、かなりの重症ですね。 ログをあさっていたところ、以下の様なログを発見 Logfiles/HTTPERR/某ログ 1_Connection_Refused という記載がありました。 なんのことかわかりませんでしたが、どうもカーネル周辺のメモリアロケーションに失敗している模様。 http://www.osas.co.jp/magmag/2011/20110703.html http://blogs.msdn.com/b/amol/archive/2012/02/29/troubleshooting-quot-connections-refused-quot-errors-seen-httperr-logs.aspx 対処法は、「OS自体の再起動しかない + 定期的に再起動することで予防」 ってことなので、皆様ご注意を・・・

SCOM監視エージェントが暴走中 | ライタス株式会社

イメージ
本末転倒とはこのこと。 と言わんばかりの現象に遭遇しました。 今回の現象について、解説します。 Active Directory(WS2008)に、リモートデスクトップ接続しようとしたところ、 以下の様な画面になりました。 ターミナル接続が現在、接続、切断、リセット、または削除の操作の処理でビジー状態であるため、要求された操作を完了できません。 なんでかなーと思いつつ、別ルートのコンソールツールで実機に直接ログインを試みたところ、 ようこそ画面で止まってしまい、応答がありません。 2chのスレで「ようこそ画面のまま、1時間ほど放置したらログインできた」との 報告があったので、そのとおりにしてみると、15分後あたりでログインできました。 とりあえず、タスクマネージャーを見たところ、CPU / メモリー共に上限まで振り切っていました。 振り切ってる原因のプロセスを確認したところ、MonitoringHost.exeが5個ほど立ち上がっていたので、とりあえず、バッサリと停止しました。 この時点で、リモートデスクトップが復旧したので、ほっと一息です。 さて、今回の原因の、MonitoringHost.exeですが、何者かというと、 SCOMのエージェントプログラムでした。 監視エージェントが暴走するなよ(苦笑 詳細については、以下のとおりです。 http://support.microsoft.com/kb/974051/ja どうも、XP/Vista/WS2008で発症するみたいです。 MSXML6.0のコンポーネントがよろしくないみたいですね。 WindowsUpdateすれば治るようですが・・・確認していないので、よくわかりません(^^; 結局、当該サーバーについては、エージェントレスで監視することにしました。 リモートデスクトップが繋がらないことがあれば、大体CPUかメモリーが いっぱいいっぱいになっていることが考えられるので、 同様の状態になったら、疑ってみてはいかがでしょうか。 本記事は、弊社代表のブログ記事 なんでもIT屋の宿命 からの記事を加筆修正したものです。

IIS SMTPなんて嫌いだー! | ライタス株式会社

IISのSMTPで困ったことになっているので、解説がてら整理。 IISのSMTPは、Windowsを利用していれば、簡単に利用できるSMTPサーバーで、 結構利用されているケースが多いように感じています。 テストケースに使うにはもってこいですし。(なんで本番につかうのかなー) というか、そもそもIIS SMTPなんか使うなというお叱りはごもっともだと思います。 のっぴきらない理由はお察しください。・゚・(ノ∀`)・゚・。 さて、今回の現象ですが、RFCに関わる部分なので、多少前提知識が必要です。 ここをお読みの方は、きっとハイエンドな方ばかりだと勝手に信じて話をすっ飛ばすと・・・ メールヘッダーにMessage-IDという項目があります。 Message-IDに関しては、ここのサイトが詳しい解説をしています。 http://www.emaillab.org/essay/message-id.html この値は、インターネット的にユニークな値であることを保証される必要があるのですが、 IIS SMTPを使ってメールを出すと、条件によっては、重複したものが生成されるケースが あるようです。 その条件は、よくわかっていないのですが、現象が起きている環境をちょこっとだけ書くと、 Windows Server 2003 R2 + IIS + ASP.NET 2.0で、メールをIIS SMTPに対して短い間隔で出す と、現象が発生するようです。 IISのMessage-ID の形式は、 [サーバー名][よくわからない文字列9文字][8桁の数字(連番?)]@[DNSサフィックス] のようですね。 重複するのは、[8桁の数字(連番?)]の部分が原因みたいで、 予想では、マルチスレッドで動作している場合に、同じIDが出ることがあるとか、 そんなんじゃないかなとおもいます。 ASP側で、Message-IDを生成して送るように設定したはずなのですが、 どうも、IIS側でMessage-IDを付け替えてくれているようです。 余計なことしやがって 親切なのはうれしいのですが、ちゃんと動いていないのが残念でなりません。 で、その対策を探しているのですが、なかなか見つかりません。 レジストリをい...