できるだけ多くのユーザーアカウントを持つサーバーが欲しいとしましょう。最大はいくつですか?
何百万ものユーザーアカウントが必要です。クレイジーですか?他のすべてのデータは揮発性であると想定されている間、私は何十ものボックスの負荷分散ミラーをホストし、ユーザーデータは高可用性ストレージ共有に格納されます。
理論的には、ユーザーIDスペースがサポートするのと同じ数のユーザーを持つことができます。特定のシステムでこれを確認するには、uid_t
タイプの定義を確認してください。これは通常、unsigned int
またはint
として定義されます。これは、32ビットプラットフォームでは、最大で約43億のユーザーを作成できることを意味します。 64ビットプラットフォームでは、16e18を超える異なるユーザーIDを使用できます。
ただし、この制限に達する前に、他のリソースが使い果たされる可能性があります。ディスクスペース。ユーザーごとにホームディレクトリを作成すると、ユーザーごとに1 MBのスペースがあっても、4 PBを超えるストレージが必要になります。また、多数のユーザーがプロセスをバックグラウンドで実行したままにしたり、cronジョブをスケジュールしたり、ftpやsshセッションを開いたりすると、システムに深刻な負荷がかかる可能性があります。
UIDスペースがなくなるまで。現在のシステムは32ビットの符号なし整数を使用し、65535と4294967295は "any"/"unknown"/etc。のマジック値であるため、4294967294の異なるユーザーを同時に使用する余地があります。古いシステムでも、16ビットの符号なし整数が表示される場合があります。
他の回答は、特定の制限に関するOPの質問に文字通り回答しています。長期的な参照としてのSFの性質を考えると、私はあなたが考えているアプローチについて非常に重要な警告を指摘することが重要だと思います。
wantディレクトリサービスを使用して、この規模でユーザーアカウントを管理します。それはまさにディレクトリサービスの問題です[例: OpenLDAP、Active Directoryなど]は、のために設計されました。
「標準」[1]のUnixユーザーツールを使用して少数のローカルユーザーアカウントを管理することは、使い古した経路であり、苦痛を伴い、簡単に拡張できず、問題の説明を考えると、おそらく大きな複数のサーバーで実際に水平方向に拡張できない場合の、選択したソリューションの再構築。
[1]それらは一般に非常によく似ていますが、正確な呪文はプラットフォームごとに異なり、同様の遺産のLinuxディストリビューションでも時々異なり、OSリリースバージョンによって定期的に変更されます。買い手責任負担。
上記のように、理論的にはUIDのunsigned intサイズによって制限されますが、現在のところ、この制限に達する前にリソースによって制限される可能性があります。