いますぐ実践! Linuxシステム管理
「いますぐ実践! Linux システム管理」はこちらです。 メルマガの解除、バックナンバーなども、以下からどうぞ。 https://www.usupi.org/sysad/ (まぐまぐ ID:149633) その他、作者に関するページは、概ね以下にございます。 https://www.usupi.org/kuri/ (まぐまぐ ID:126454) http://usupi.seesaa.net/ (栗日記ブログ) https://twitter.com/kuriking/ (twitter) https://facebook.com/kuriking3 (facebook) https://jp.pinterest.com/kuriking/pinterest) https://www.instagram.com/kuri_king_/ (instagram) [バックナンバーのトップへ
Linux Capability - ケーパビリティについての整理 - ローファイ日記
Man page of CAPABILITIES を読んで自分なりに整理する。メモ気分で書いているので言葉足らず/用語が曖昧 のところがあればご指摘ください。 3つのケーパビリティセット Inheritable execve(2) (以下、単にexecveと呼ぶこともある) の前後で引き継がれるケーパビリティ Permitted 実効ケーパビリティセットに追加することができるセット。ここから落ちたケーパビリティはどう頑張っても実効状態にできない Effectve 実効ケーパビリティセット。実際にそのスレッドで利用できるケーパビリティの集合 Permittedのセットの中から、実際に有効になっているEffectveのセットをピックアップするイメージ。 また、Inheritableはexecveしなければ関係することはない。 スレッドケーパビリティセット それぞれのスレッドは上述の三つのケーパ
Docker Privileged でできること - PolyPeaceLight
訳そう訳そうと思いつつ放置していたのを訳す docker 1.9.0 build 76d6bc9 Runtime privilege and Linux capabilities --cap-add: Add Linux capabilities --cap-drop: Drop Linux capabilities --privileged=false: Give extended privileges to this container --device=[]: Allows you to run devices inside the container without the --privileged flag. Note: Docker 1.10 以上では、 --cap-add がコンテナに渡されたかどうかにかかわらず、デフォルトの seccopm profile が syscal
ITエンジニアのCAPの定理 - from scratch
CAPの定理というのがある、 「ノード間のデータ複製において、同時に一貫性、可用性、分断耐性の3つの特性を同時に保証することはできない。」というもの。 説明をwikipediaにゆずると、 ・一貫性 (Consistency)： 全てのノードにおいて同時に同じデータが見えなければならない。 ・可用性 (Availability)： ノード障害により生存ノードの機能性は損なわれない。つまり、ダウンしていないノードが常に応答を返す。単一障害点が存在しないことが必要。 ・分断耐性 (Partition-tolerance)： システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。通信可能なサーバーが複数のグループに分断されるケース（ネットワーク分断）を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。ただし、そのような単一障害点のあるネットワーク設計
CAPの定理と分散データベースの話 - プログラマでありたい
前回、セッションストアについて悩んでいますという何も解決しないエントリーを書いたら、はてブやTwitterで非常に沢山のコメントを頂きました。色々な考え方があって、非常に参考になりました。ありがたい限りです。別途、考えを整理してまとめようと思いますが、下記の2つの考え方が多いようです。 共用セッションストアの格納先を分散データベースにすれば良いよ セッション設計をちゃんとすれば、クッキーストアを使ってもセキュリティや容量の問題はないよ 私も、どちらかと言えば上2つの方針で考えています。一方で、分散データベースは一貫性を保証しつつ可用性を高めるのは難しいという基本姿勢と、クッキーストアについては設計ミスや実装ミスが起こりうるという現実の中で、どう安全側に倒していけるかという点を考える必要があると考えています。今回は、分散データベースの一貫性について考えていることをまとめてみます。 CAPの定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
