参照するDNSサーバの変更 2台目のドメインコントローラとなるWindowsサーバは、最初のドメインコントローラが作成したフォレスト/ドメインの名前解決が出来る必要があります。なので最初のドメインコントローラをDNSサーバとして参照するように設定を変更します。 [コントロールパネル]を開き、[ネットワークの状態とタスクの表示]をクリックします。 [アダプターの設定の変更]をクリックします。 [ネットワーク接続]画面が開きますので、ネットワークインターフェースを右クリックし、[プロパティ]をクリックします。 [(ネットワークインターフェース)のプロパティ]画面が開きます。[インターネットプロトコルバージョン4(TCP/IPv4)]をクリックして選択し、[プロパティ]ボタンをクリックします。 [インターネットプロトコルバージョン4(TCP/IPv4)のプロパティ]画面が開きます。[次のDNSサ
はじめに 初期のScutumはUNION SELECTという文字列があると単純にSQLインジェクションであると判断して、通信をブロックしていました。現在はもっとインテリジェントな検知エンジンを搭載しており、UNION SELECTだけではブロックしません。 実は、私は5年前には、UNIONだけでもブロックしてよいのではないかと考えていました。というのも、通常の(特に日本語が使われている)ウェブサイトにおいて、ブラウザから「UNION」という文字列が送られてくるケースは非常に稀だろうと思っていたからです。 最近になって、ふと「実際にUNION SELECTが通常の文章の中でどのくらい使われているか、大量の英文のデータを処理してみたいな」と思い、情報収集を開始しました。するとまさにこの用途にぴったりのデータセットが見つかりました。Google BooksのNgram Viewerです。 Goo
Google の企業向けソリューションに関する公式な情報やユーザーの事例などを、いち早く皆さんにお届けします。
はじめに 先日、弊社渡辺が「プログラムではアクセスキー/シークレットキーを使わずにRoleを利用する」の記事を書きました。今回は、AWS SDKを使用するプログラムをローカルマシンで開発する場合、どのようにアクセスキー/シークレットキーを保持するかについて書きたいと思います。 Credentialsファイル 結論から書くと、Credentialsファイルを用意し、そこにアクセスキー/シークレットキーを記述します。以下、そのCredentialsファイルについての説明です。 1.環境について .NET用SDK以外の、全てのAWS-SDKにてCredentialsファイルを参照するようです。 All the SDKs except the .NET SDK now can automatically look for credentials in the same environment va
Elasticsearchのインデキシングに関するパフォーマンス検討 原文:performance considerations for elasticsearch indexing Elasticsearchユーザは様々な楽しいユースケースを持っています。小さなログを追加することから、Webスケールの大きなドキュメントの集合をインデキシングするようなことまでです。また、インデキシングのスループットを最大化することが重要で一般的な目標となります。 「典型的な」アプリケーションに対して良いデフォルト値を設定するようにしていますが、次のちょっとした簡単なベストプラクティスによってインデキシングのパフォーマンスをすぐに改善することができます。それらについて記述します。 第一に、制御できないならば、巨大なJavaヒープを使用しない:必要なサイズ(マシンの持つRAMの半分以下)のheapだけを設定し
Latest Entries 【みからぼナレッジ】Juniper SRX100でポートをL2冗長(LACP)する(2014/9/10/cloudpack) クラウド雑技団物理担当の、cloudpackの津村です。SRXシリーズを構築して早n台目、junos界ではVLANのインターフェース権が上がっていてなんでも構成できるので、これはこれで好きなプロダクトです。... 書籍レビュー:AmazonWebService基礎からのネットワーク&サーバー構築(2014/9/8/AWS) にゃんぱすー。 cloudpackの津村なのん。うち、駄菓子屋で本買ったのん。ねぇね、VPC教えて欲しいなん。... ブログが無いから、ブログを自力で作ってみた。(2014/9/5/AWS) cloudpack新人のAkira Tsumuraです。技術支援チームというところで、王子の右側をやっています。... Pa
本番環境で RDS を運用して数ヶ月。いろいろ試して RDS のパフォーマンスを上げるコツがわかってきたのでまとめたいと思います。 ここで取り上げるコツは以下を前提にしています。 データベースは PostgreSQL (Multi-AZ 配置) Read よりも Write が多い 夜間のバッチ処理がピーク 1 レコードは小さいが、一度に書き込むレコード数は多い アプリケーションの特性によっては当てはまらないこともあるでしょうし、他の RDBMS では結果が違ってくると思います。そこを踏まえたうえで参考にしてください。 Availability Zone はどちらかに寄せる RDS の Multi-AZ は耐障害性を上げるために欠かせない機能で、本番環境では Multi-AZ 配置が推奨されています。 Multi-AZ 配置にすると物理的に独立した AZ (Availability Zon
Amazon EC2 は世界各地の場所でホスティングされています。これらの場所はAWS リージョン、アベイラビリティーゾーン、Local Zones、AWS Outposts、および Wavelength Zones で構成されます。 リージョンは別々の地理的エリアです。 アベイラビリティーゾーンは、各リージョン内の複数の独立した場所です。 Local Zones を使用すると、コンピューティングやストレージなどのリソースをエンドユーザーに近い複数の場所に配置できます。 Wavelength Zone を使用すると、5G デバイスやエンドユーザーに非常に低いレイテンシーを提供するアプリケーションを構築できます。Wavelength は標準の AWS コンピューティングおよびストレージサービスを通信事業者の 5G ネットワークのエッジにデプロイします。 AWS Outposts ではネイティ
AWS CLIを使って、以下のように割り当てられたインスタンスのTagの値のみ(今回はWordPress)を取得します。 今回はAmazon Linuxを使うので、AWS CLIのインストール方法は割愛します。 # Amazon Linux 2013.03に入っているデフォルトのaws-cliを使いました。バージョンは以下です。 $ aws --version aws-cli/0.9.3 Python/2.6.8 Linux/3.4.43-43.43.amzn1.x86_64 #バージョンが異なると、オプションの指定が異なる可能性があります。 まず以下の環境変数を設定します。 export AWS_DEFAULT_REGION=ap-northeast-1 export AWS_CREDENTIAL_FILE=/opt/aws/credential-file credential-file
前回に続いてSynergy Researchの7月28日付リリースが出たので2012Q1から2014Q2までのプロバイダー別クラウドシェア推移をグラフにしてみました。相変わらず解読しにくい発表です。 同社のリリースは、ついにMicrosoft、Salesforce、IBM、Googleの4社シェア合計がAWSを越えたと注目していますが2-5位が束にならないとかなわない1位って凄いものだと感心してしまいます。 ちなみにSalesforceだけは2012Q3からしか数字が判明しなかったので2012Q3起点となっています。こうしてみるとAWSの成長速度はすなわちクラウド市場の成長速度となっていることがよくわかります。市場開拓者として先行者利益の貯金を取り崩すことなく巡航速度で成長しているようです。対して、MicrosoftとIBM、googleがキャッチアップするために猛烈な追い上げをかけている
これです。 ちゃんと社労士チェックを入れて、2014年時点の法運用Validな感じにしてあるので、下手な中小企業はおろか、ろくにメンテされていない大企業の就業規則よりマトモな内容になっているはずです。 なんで就業規則を公開したのか マトモな規則が作ってあれば公開しても特にデメリットはない むしろマトモな会社アピールができてよい 個人的には「無限RedBullです!!!!」みたいな事をアピールする会社よりマトモな広報・求人活動の一環だと思っている 自分で就業規則を作ろうにも、良いサンプルがなかった(後述あり) いわゆるOSS的な話。就業規則にも再利用性が合っても良いはず これを書いてて、就業規則にライセンスを明示するのを忘れていたことに気が付いた GitHubだと、就業規則の改定にプルリクを飛ばせて楽しいし、改定履歴も一目瞭然 零細企業に就業規則って要らないんじゃないの? 従業員が10人未満
AWS アカウントを複数人で使ってシステムを作っていく時に、 セキュリティの面からやるべきことについて。 主に Web アプリケーションを想定した内容ですが、特に書いてあることは特殊ではないと思います。 各所の Blog にも記事書かれてますが思っていることをつらつらと書いてみます。 なんか変なこと言ってたらご指摘ください。 参考: AWSのセキュリティが気になるなら読んでおくべきAWSセキュリティのベストプラクティス - yoshidashingo はじめに (AWS アカウントと IAM ユーザ) 前提というか用語の話。 AWS アカウント アカウント作成時のメールアドレス、パスワードでログインして使うユーザ IAM ユーザ AWS アカウントから発行できる、ユーザ名とパスワードでログインして使うユーザ AWS アカウント周り AWS アカウント (ルートユーザ) で作業できないように
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く