web-dev-qa-db-ja.com

ユーザー情報以外のものをFreeIPAに保存するのは悪い考えですか？

$ companyには、現在、いくつかの自家製^ Whomemutated階層と、MySQLに保存されている他のいくつかのデータを含むOpenLDAPに基づくセットアップがあります。

OpenLDAPサーバーには、内部ユーザー、クライアントの連絡先（内部ツールの一部にアクセスできるため、ユーザー/パスワード情報を持っているものもあります）、使用しているフリーランサー、アドレス帳などのデータが含まれています。 MySQL DBには、同じユーザーからの重複データと、クライアントの会社に関するデータ、会社に依存するプロジェクト、さらにはクライアントへの拡張などの補足情報が含まれています。

私の理想的な計画は、すべてを1つの真実の情報源に統合することです。

私たちにとってFreeIPAの興味深い部分は次のとおりです。

  • LDAPエントリポイントを提供します。使用するすべての内部サービスはLDAPサーバーにバインドできます
  • RESTエントリポイントを提供します。これは、社内開発に理想的です。
  • 基本的に承認の管理に必要なすべてのものが付属しているため、統合が容易です
  • どういうわけか標準的な（完全に自家製の反対による）階層

ドキュメントに記載されているように、FreeIPAは焦点が狭く、IdMであり、一般的なLDAPストアではありませんが、関係情報を拡張したい場合（たとえば、このプロジェクトの場合、これらの内部ユーザーとクライアント）別のツール（ユーザー名/ユーザーID、承認のためのFreeIPAのグループ、補完的なデータストア内のプロジェクトまたは会社の照合）でいくつかの重複が必要です。これは、両方のストアのデータ間で一貫性のない状態が発生する可能性があること、何らかの同期が必要であることなどを意味します。

ですから、FreeIPAを拡張して、たとえば会社やプロジェクト情報を保存するのは、そんなに悪い考えだろうかと思います。もしそうなら、なぜですか？

freeipa
1
Mayeu

それは悪い考えではありませんが、よく計画する必要があります。 FreeIPAマスターはその間にデータを複製するため、LDAPスキーマ拡張は、すべてのシステムに存在するようにパッケージツールで維持する方が適切です。同じことがフレームワークプラグインにも当てはまります。

FreeIPA 4.4.1までは、外部から提供されたスキーマ拡張機能に問題がありました。これらはインストールフェーズに含まれていなかったため、アップグレードコードが生成を実行する時点でオブジェクトクラス/属性が欠落しているため、拡張機能を最初からインストールできませんでした。プラグイン固有のACIのうち、後で追加できるのは後でのみです。詳細については、 https://www.redhat.com/archives/freeipa-devel/2016-August/msg00083.html のスレッドを参照してください。

FreeIPA 4.4.1で、この問題を修正し（上記の説明の結果）、完全に個別の拡張機能を使用できるようになりました。FleetCommander統合プラグインの例を参照してください https://github.com/abbra/freeipa-デスクトッププロファイル/ 。私は現在、FreeIPA 4.4.1以降の拡張性ガイドに取り組んでおり、多かれ少なかれ時代遅れになった古いガイド（ https://abbra.fedorapeople.org/guide.html ）を置き換えています。また、メンテナンス/配布の問題やアクセス制御の設計については説明していません。

FreeIPA 4.4.1以降の自己完結型のセットアップで追加を維持している限り、問題はありません。

2
abbra