Gitolite

 (gitolite.com)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Gitolite は中央サーバーで Git リポジトリをホスティングし、リポジトリごとに きめ細かなアクセス制御 を適用できるようにする
  • パッケージマネージャーでインストールする際は、一般に gitolite3 という名前が使われ、ソースコードは Codeberg と GitHub で提供されている
  • Unix と SSH に慣れているなら クイックインストール文書 を、段階的な案内が必要なら全体の文書フローまたはミス防止インストールガイドに従えばよい
  • インストール・設定エラーや鍵の紛失は emergencies 文書で扱っており、セキュリティ問題はメールで直接報告し、一般的なサポートはメーリングリストを利用する
  • ソフトウェアは GPL v2 で配布され、別管理の文書には原則として Creative Commons BY-NC-SA 3.0 が適用される

インストールと運用ドキュメント

  • Gitolite は中央サーバーに Git リポジトリを構成し、きめ細かなアクセス制御 を適用できるようにする
    • 代替のソースリポジトリとして GitHub も利用できる
    • パッケージマネージャーでのパッケージ名は一般に gitolite3
  • Unix と SSH に慣れているなら クイックインストール を参照できる
  • 段階的な支援が必要なら ミス防止インストールガイド をそのままたどり、インストール後の一般的な作業には cookbook の例を活用できる
  • emergencies ではインストール・設定の問題や 紛失した鍵の復旧、一般的またはまれなエラー、問題になりうる非標準構成を扱う

サポートチャネルとライセンス

  • セキュリティ問題 は sitaramc@gmail.com に直接報告する
  • 一般的なサポートと議論には Google Groups のメーリングリストを利用する
    • 新規メンバーの最初のメールは承認されるまで保留されるが、同じアドレスから送られた後続メールは保留されない
    • リリースとセキュリティ告知のための別の低頻度・一方向メーリングリストも提供されている
  • IRC サポートは libera.chat の #gitolite チャンネルで受けられ、Git チャンネル #git にも Gitolite に詳しい利用者がいる
  • Gitolite ソフトウェアは GPL v2 で配布される
    • 文書には原則として Creative Commons BY-NC-SA 3.0 が適用されるが、外部貢献部分には各ファイルで別ライセンスが示される場合がある
    • 文書のコード例と関連コメントは、公正利用に該当しないと判断される場合は GPL v2 とみなすことができる
  • GIT は Software Freedom Conservancy の商標であり、Gitolite の名称はライセンスに従って使用される

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rs のコメント

  • 2013年に Cambridge University で gitolite と gitweb ベースの Git サーバーを構築した。初期の GitLab や Gitorious より管理にかかる時間がずっと少なそうだったので選んだが、実際にも概ねその通りだった。
    gitolite は SSH でコマンドを実行し、精緻な設定ファイルでアクセス権を管理する独特の構造のため、Web 管理コンソールがなく、導入のハードルがあった。入門ガイドを作ったが、技術に自信のあるユーザーにしか向いていなかった。
    Git サービスに割り当てられた人員はまったくいなかったため、需要を証明して予算を確保する目的で、個人の時間を使って暫定サービスを作った。オープンソースのローカル変更を SVN に保管したり、誰にも見つけられないホームディレクトリに Git リポジトリを置いたりする状況は受け入れがたかった。大学の科学プログラミング需要に比べてソフトウェア工学支援は不足しており、中央 IT サービスは内部用途にとどまらず、大学全体の教育と研究を支援すべきだと考えていた。
    ユーザー管理の委任機能を活用し、各研究グループや学科の専門家にアカウント管理とサポートのほぼすべてを任せた。難解なツールだったおかげで、意図していた専門性の高いアーリーアダプターが集まり、ユーザー数はかなり多かったがサポート依頼はほとんどなかった。複数大学が参加するプロジェクトも、アクセスを Cambridge の構成員に限定しなかったため支援できた。
    最大の誤算は、暫定サービスが約8年も続くとは予想していなかったことだ。その後、専任スタッフが運用する GitLab に置き換えられた。最も時間がかかった作業は耐障害性の改善で、Git リポジトリを別サイトへほぼリアルタイムに複製する仕組みは、必要以上に複雑だった可能性が高い。

    • このサービスを引き継いだ当時は、継続的インテグレーションやパッケージリポジトリなどを提供するソフトウェアフォージへ移行しようとしていた。研究成果物としてのソフトウェアの価値が認められ始め、大学の中央サービスに予算を投入しようという雰囲気もあった。
      ちょうど Microsoft が GitHub を買収し、GitHub の衰退が初めて予測されていた時期だったが、歴史が繰り返される様子は興味深い。GitLab は非常に有利な条件でライセンスを提供してくれ、クラウドサービスに Kubernetes と Infrastructure as Code を適用する社内デモも必要だった。今は大学を離れているが、GitLab は現在も https://gitlab.developers.cam.ac.uk/ で運用されている。
    • 2012〜2013年に、地域の大学のある学科で gitolite を運用しており、主にソフトウェア工学専攻の学生が使っていた。ユーザー規模に比べると大げさだったが、単純さときめ細かなアクセス制御リストのおかげで、学科内の複数プロジェクトのチームと権限を管理するのに都合がよかった。
      数年後に運用を引き継ぐ人がいなくなり、GitHub が大流行したことで、ユーザーは大学内部サービスではなく外部ホスティングへ移っていった。プロジェクトはなくなったと思っていたが、今も継続的に保守されているようでうれしい。

  • gitolite のきめ細かなアクセス制御リストを使うと、あるキーには clone だけを許可して push は禁止したり、push は許可しつつ force push は禁止したりできた。軽量で便利だったし、今なら https://github.com/djmdjm/gitlimit を試してみると思う。

    • Gitlimit はソースコードが単純なので、ユーザー定義コマンドのような機能も簡単に拡張できそうに見える。

  • 個人プロジェクトなら Fossil も適している。小さなバイナリに Web サーバーが内蔵されていて簡単にサービス化でき、必要なら上流の Git リポジトリとも連携できる。

    • gitolite は、複雑なアクセス制御が必要な多数ユーザーと複数リポジトリのホスティングのためのツールだ。

  • NRAO でも gitolite をその場しのぎとしてしばらく使っていた。当時の公式サポート対象ツールは Subversion だったが、グループ責任者が Git を望む内部ユーザーのためにインストールしてくれた。機能は多くなかったが、必要なことは十分うまくこなしていた。
    現在は天文台全体で使われているGitLab インストール環境があり、GitHub や GitLab に移る可能性もあるが、最終決定は知らない。継続的インテグレーション・デプロイシステムの手直しに多くの時間を使っているが、gitolite でそれを支援したり、プルリクエストやマージリクエストのワークフローを実装したりする方法は思いつかない。ただし、そうした機能の有用性は誇張されているのかもしれない。

  • 極度の単純さを目指して作られた fugit(https://github.com/cbdevnet/fugit) を使い、Nix モジュールで設定ファイルを管理している。シンプルで効果的であり、gitolite はいつも少し使いづらかった。