A Highly Available, Fault-tolerant, Clustered Version of Apache CouchDB

While it appears to the end-user as one Apache CouchDB instance, it is in fact one or more BigCouch nodes in an elastic cluster, acting in concert to store and retrieve documents, index and serve views, and serve CouchApps. BigCouch has been developed and is continually maintained by Cloudant. Clusters behave according to concepts outlined in Amazon’s Dynamo paper, namely that each BigCouch node can accept requests, data is placed on partitions based on a consistent hashing algorithm, and quorum protocols are applied for read/write operations.

Using IAM to Grant Access to Users Under Your AWS Account

Topics

• Creating an Admins Group
• What Your Users Need to Know

This topic shows you how to give access to your AWS resources by creating users under your AWS account. First you'll learn concepts you should understand before you create groups and users, and then you'll walk through how to perform the necessary tasks using the AWS Management Console. The first task is to set up an administrators group for your AWS account. Having an administrators group for your AWS account isn't required, but we strongly recommend it.

The following figure shows a simple example of an AWS account with three groups. A group is a collection of users who have similar responsibilities. In this example, one group is for administrators (it's called Admins). There's also a Developers group and a Test group. Each group has multiple users. Each user can be in more than one group, although the figure doesn't illustrate that. You can't put groups inside other groups. You use policies to grant permissions to groups.

In the procedure that follows, you will perform the following tasks:

• Create an Admins group

• Create the policy controlling permissions for the group

• Create or add the users who will be in the Admins group

• Create access keys for users who need them

• Create passwords for users who need them

You will grant the Admins group permission to access all your available AWS account resources. Available resources are any AWS products you use, or that you are signed up for. Users cannot access your AWS account information, including the following:

• Profile information

• Billing and metering information

• Security credentials

Tip

You should create a user for yourself and add it to your Admins group. Then, after you establish the Admins group and yourself as a user in the group, all interaction with your AWS account should be at the user level, not at the AWS account level. Limiting the use of your AWS account credentials will help ensure that when you want to rotate credentials for a user or for the AWS account, potential impact is limited. For more information about the credentials and the security benefits of rotating credentials, go to Managing User Keys and Certificates in Using AWS Identity and Access Management.

The Zeroconf Protocol

There are two specifications that define the Zeroconf protocol. First, there's a specification for running the Domain Name Service (DNS) protocol over multicast IP, instead of the more usual unicast IP. A second specification lays out the rules for discovering services through special DNS packets sent over multicast DNS.

mDNS + Discovery

Avahi [編集]

AvahiはLinuxとBSD向けのZeroconf実装である。IPv4LL、mDNS、DNS-SD を実装している。ほとんどのLinuxディストリビューションに含まれており、デフォルトでインストールするものもある。nss-mdns と連動して作動させるとホスト名解決機能を提供する^[14]。

AvahiにはBonjourおよび歴史的なmDNS実装であるHowlとのバイナリ互換性を提供するライブラリがあり、それらに対応したソフトウェアをAvahiを経由して利用することができる。

標準化 [編集]

2005年3月、アップル、サン、マイクロソフトなどからの参加者を含むIETFのZeroconfワーキンググループはネットワーク上のアイテムにアドレスを割り当てる標準として RFC 3927 を公表した^[7]。

LLMNR は公式採用に向けてIETFのDNSEXTワーキンググループに提出されたが合意には至らず、単なる情報RFCとして RFC 4795 が公表されるにとどまった^[8]。LLMNRがインターネット標準として採用されず失敗に終わった後、IETFはLLMNRより広く採用されている mDNS/DNS-SD の仕様を情報RFCとして公表するようアップルに依頼した。現在それらはインターネットドラフトとして公表されている^[9]。

サービス発見のためのSLPの仕様は RFC 2608 としてIETFのSVRLOCワーキンググループが公表した^[10]。

アップルのプロトコル: マルチキャストDNS/DNS-SD [編集]

マルチキャストDNS (mDNS) はユニキャストの Domain Name System と似たAPIを使うプロトコルだが、マルチキャストプロトコル上に実装されている。LAN上の各コンピュータはそれぞれDNSのリソースレコード（例えば、A、MX、SRVなど）のリストを持ち、mDNSのマルチキャストグループに参加している。あるmDNSクライアントがPCの名前からそのIPアドレスを知りたい場合、mDNSクライアントは既定のマルチキャストアドレスに要求を送信する。すると対応するAレコードを持つPCがそのIPアドレスを含めて応答する。IPv4でのmDNSマルチキャストアドレスは 224.0.0.251 で、IPv6のリンクローカル・アドレッシングでは ff02::fb である。

アップルの方式のもう半分は DNS-SD (DNS based Service Discovery) で、Domain Name Systemの上に構築されている。アップルの製品、多くのネットワークプリンター、様々なサードパーティ製品や各種OS向けのアプリケーションで使われている。アップルの方式ではDNSメッセージを使用しているが、対抗しているマイクロソフトの方式であるSSDPではHTTPメッセージを使用している。DNSのSRVレコード、TXTレコード、PTRレコードを使いサービスインタフェース名を告知する。サービスを提供しているホストは利用可能なサービスの詳細（インスタンス、サービスの種類、ドメイン名、オプションの設定ぽらメータなど）を告知（出版）する。サービスの種類は先着順で簡単に登録されている。DNS-SD.org がそのレジストリを保守・公表している。

SafariブラウザやiChatインスタントメッセンジャーなど Mac OS X の多くのネットワーククライアントは手近のサーバを特定するのにDNS-SDを使っている。Windows上では、一部のインスタントメッセンジャーやVoIPでDNS-SDをサポートしている。Unix系やLinuxディストリビューションにもDNS-SD機能を備えたものがある。

mDNS/DNS-SD を開発したのはアップルの従業員 Stuart Cheshire で、同社がAppleTalkからIPに方針転換したころである。

Some programming languages, like Erlang, support efficient preemptive processes with state isolation and built-in super-cheap super-fast queues to transfer immutable values.  (Some other languages call these "threads" anyway, even though I would agree with Erlang's classification as "processes".)  That's a different programming model entirely though, with its own advantages and challenges, which doesn't land neatly on this spectrum; if I'm talking about left and right here, Erlang and friends are somewhere above or below.  I'm just describing Python and its ilk, where threads give you a big pile of shared, mutable state, and you are constantly tempted to splash said state all over your program.

Personally I like Twisted's style best; the thing that you yield is itself an object whose state can be inspected, and you can write callback-based or yield-based code as each specific context merits.  My opinion on this has shifted over time, but currently I find that it's best to have a core which is written in the super-explicit callback-based approach with no coroutines at all, and then high-level application logic which wraps that core using yield-based coroutines (@inlineCallbacks, for Twisted fans).

The iBooks (version 2) format is an improved format created by Apple based on ePub 3, but with additions and changes specific to Apple. These additions are believed to add new functionality and interactivity to the format as shown during today’s media event.

例：@novが東京 (has Tokyo system) から京都 (has Kyoto system) に引っ越した。

Step 1. @novが京都の引っ越し届け窓口で手続きを開始

Step 2. KyotoがJRにJWT送ってaccess tokenを取得

Step 3. KyotoがUserInfoに@novの現住所（更新前）を問い合わせ

Step 4. UserInfoがTokyoのendpointとaccess tokenを返す

Step 5. KyotoがTokyoから@novの現住所を取得

Step 6. ??

Questions.

* Step 1では、マイナンバーを提示する？

* Step 2で使うJWTは、いつ誰がKyotoにあげる？

ISCライセンス (英: ISC license, ISCL) とは、許容的フリーソフトウェアライセンス（permissive free software license）のひとつ。Internet Systems Consortium (ISC) によって作成された。「ベルヌ条約によって不要となる言い回し」を取り除いた2条項BSDライセンスと機能上同等である^[1]。