ジョブスケジューラ「Rundeck」を試してみる | DevelopersIO
森永です。 最近は大逆転裁判をやりながら寝落ちするという毎日を送っています。 サーバ構築する上で、ジョブをどうするかというのは考慮が必要な点です。 簡単に実現するにはcronを使えばいいのですが、要件によってはジョブスケジューラを使わないと厳しいということがあります。 かと言って、エンタープライズで使われている本格的なジョブスケジューラを使うのも大げさすぎる、というのもわかります。 そこで今回は、簡単に構築ができてそれなりに痒いところには手が届くジョブスケジューラ「Rundeck」を試してみます。 Rundeckとは OSSのジョブスケジューラです。 特徴として以下の様なものがあげられます。 エージェントレス SSH接続できればジョブを実行できます。 なので、別サブネットはもちろん、別VPCでも別AWSアカウントでもはたまたオンプレでもRundeckサーバからSSH接続とジョブを実行できる
Windows Server 2008 のきめ細かなパスワードポリシー
『MVP for Windows Server-Directory Services』著者、コンサルタント、スピーカー、トレーナー Active Directory のフォレストに複数のパスワードポリシーを展開する場合、その境界は常にドメインです。このことが多くの顧客に混乱を招いていました。なぜなら、すべてのGPO（Group Policy Object ：グループポリシーオブジェクト）でパスワードを変更できるからです。 しかし、パスワード設定（およびアカウントロックアウト設定）はGPO のコンピュータ設定部分に構成されていることに注意してください。コンピュータ設定はコンピュータオブジェクトにしか適用されません。したがって、コンピュータオブジェクトのローカルアカウントにしか適用されません。 ただし、この例外として、ドメインヘッド（ドメインの最上位のノード）にリンクされるポリシーがあります。
Active Directory-GPO編～細かい設定が可能なパスワードポリシー : オラクる。
GPOで設定することの出来るパスワードポリシーはDefault Domain Policyにリンクした場合のみ有効です。 各OUにリンクしたGPOの場合は有効になりません。 ただし、Windows Server 2008以降では各ユーザーもしくは各グループごとに異なるパスワードポリシーを適用することが可能です。 まずは「ファイル名を指定して実行」からadsiedit.mscを起動 ADSIエディターが起動するので右クリックで接続を選択します。 名前のドメイン名をFQDNで入力してOKボタンを押下します。 ドメインに接続されました。 「CN=System」→「CN=Password Settings Container」で右クリックして、「新規作成」→「オブジェクト」を選択 「msDS-PasswordSettings」が選択されているのを確認して「次へ」をクリックします。 新しいパスワード
マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
naoyaのはてなダイアリー - 負荷とは何か
調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱されてるコマンド) などのツールです。 top ではシステム統計のスナップショットを見ることができます。今システムがどういう状態かなーというときは top が便利。 top - 08:16:54 up 3 days, 14:43, 6 users, load average: 0.18, 0.07, 0.03 Tasks: 43 total, 2 running, 41 sleeping, 0 stopped, 0 zombie Cpu(s): 18.2% us, 0.0% sy, 0.0% ni, 81.8% id, 0.0% wa, 0.0% hi, 0.0% si一方の sar では10分ごとのシ
「複数CPUならload averageはCPU数で割れ」は正しいか？
【この記事の所要時間 ： 約 3 分】 「複数CPUで稼動するlinuxのload averageの目安はいくつだ？」という前から気になっていた疑問をLivedoor Knowledge で見つけたので、読んでみた。 snmpの.1.3.6.1.4.1.2021.10やuptimeやwで取得できる load averageで機器の負荷を監視しています。 昔どこかで、「搭載CPUの個数を目安に監視する」と聞き、 2CPUの機器は2.00を目安に監視していたのですが、 CPUの数にかかわらす1を超えてはいけないという 反論を頂きました。 複数CPUのload averageの目安に関する信頼できる団体によるソースを教えてください。 複数CPUで稼動するlinuxのload averageの目安に関する信頼できるソース つまり、 「2CPUならLoad Avarageの監視目安は2.0で、3CP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer