- Gitolite cho phép lưu trữ các kho Git trên máy chủ trung tâm và áp dụng kiểm soát truy cập chi tiết theo từng kho
- Khi cài đặt bằng trình quản lý gói, gói thường có tên
gitolite3; mã nguồn được cung cấp trên Codeberg và GitHub - Nếu quen thuộc với Unix và SSH, có thể dùng tài liệu cài đặt nhanh; nếu cần hướng dẫn từng bước, hãy theo luồng tài liệu đầy đủ hoặc hướng dẫn cài đặt tránh lỗi
- Các lỗi cài đặt/cấu hình và mất khóa được đề cập trong tài liệu emergencies; vấn đề bảo mật nên được báo cáo trực tiếp qua email, còn hỗ trợ chung dùng mailing list
- Phần mềm được phát hành theo GPL v2; tài liệu được quản lý riêng về nguyên tắc áp dụng Creative Commons BY-NC-SA 3.0
Tài liệu cài đặt và vận hành
- Gitolite cho phép thiết lập các kho Git trên máy chủ trung tâm và áp dụng kiểm soát truy cập chi tiết
- Cũng có thể dùng GitHub làm kho mã nguồn thay thế
- Tên gói trong trình quản lý gói thường là
gitolite3
- Nếu quen thuộc với Unix và SSH, bạn có thể tham khảo cài đặt nhanh
- Nếu cần hỗ trợ từng bước, hãy làm theo nguyên văn hướng dẫn cài đặt tránh lỗi, và sau khi cài đặt có thể dùng các ví dụ trong cookbook cho các tác vụ thông thường
- emergencies đề cập đến các vấn đề cài đặt/cấu hình, khôi phục khóa bị mất, các lỗi phổ biến hoặc hiếm gặp, và những cấu hình không chuẩn có thể gây vấn đề
Kênh hỗ trợ và giấy phép
- Vấn đề bảo mật nên được báo cáo trực tiếp tới
sitaramc@gmail.com - Hỗ trợ và thảo luận chung dùng mailing list trên Google Groups
- Email đầu tiên của thành viên mới sẽ được giữ lại cho đến khi được phê duyệt, nhưng các email tiếp theo gửi từ cùng địa chỉ sẽ không bị giữ lại
- Cũng có một mailing list một chiều, tần suất thấp riêng cho các bản phát hành và thông báo bảo mật
- Có thể nhận hỗ trợ IRC trên kênh
#gitolitecủa libera.chat; trong kênh Git#gitcũng có người dùng quen thuộc với Gitolite - Phần mềm Gitolite được phát hành theo GPL v2
- Về nguyên tắc, tài liệu áp dụng Creative Commons BY-NC-SA 3.0, nhưng các phần đóng góp bên ngoài có thể ghi giấy phép riêng trong từng tệp
- Các ví dụ mã trong tài liệu và chú thích liên quan có thể được xem là GPL v2 nếu bạn cho rằng chúng không thuộc phạm vi sử dụng hợp lý
- GIT là nhãn hiệu của Software Freedom Conservancy, và tên Gitolite được sử dụng theo giấy phép
1 bình luận
Các ý kiến trên Lobste.rs
Năm 2013, tại Đại học Cambridge, chúng tôi đã dựng một máy chủ Git dựa trên gitolite và gitweb. Chúng tôi chọn nó vì có vẻ sẽ tốn ít thời gian quản trị hơn nhiều so với GitLab hay Gitorious thời kỳ đầu, và thực tế nhìn chung cũng đúng như vậy.
gitolite có cấu trúc độc đáo: chạy lệnh qua SSH và quản lý quyền truy cập bằng các tệp cấu hình tinh vi, nên không có console quản trị web và có rào cản gia nhập. Chúng tôi đã viết hướng dẫn nhập môn, nhưng nó chỉ phù hợp với người dùng tự tin về kỹ thuật.
Vì hoàn toàn không có nhân sự được phân bổ cho dịch vụ Git, tôi đã dùng thời gian cá nhân để tạo một dịch vụ tạm thời nhằm chứng minh nhu cầu và xin ngân sách. Việc lưu các thay đổi cục bộ của mã nguồn mở trong SVN, hoặc đặt kho Git trong các thư mục home mà không ai tìm thấy được, là điều khó chấp nhận. So với nhu cầu lập trình khoa học của trường, hỗ trợ kỹ nghệ phần mềm còn thiếu; tôi cho rằng dịch vụ CNTT trung tâm không nên chỉ phục vụ nội bộ mà còn phải hỗ trợ giảng dạy và nghiên cứu của toàn trường.
Chúng tôi tận dụng tính năng ủy quyền quản lý người dùng để giao gần như toàn bộ việc quản lý tài khoản và hỗ trợ cho các chuyên gia ở từng nhóm nghiên cứu hoặc khoa. Nhờ đây là một công cụ khó dùng, nó thu hút đúng nhóm early adopter chuyên môn như dự định; số người dùng khá đông nhưng yêu cầu hỗ trợ gần như không có. Chúng tôi cũng có thể hỗ trợ các dự án có nhiều trường đại học tham gia vì không giới hạn quyền truy cập chỉ cho thành viên Cambridge.
Sai lầm lớn nhất là không lường trước rằng dịch vụ tạm thời này sẽ tồn tại tới khoảng 8 năm, trước khi được thay thế bằng GitLab do nhân sự chuyên trách vận hành. Công việc tốn nhiều thời gian nhất là cải thiện khả năng phục hồi, và kiến trúc sao chép gần thời gian thực các kho Git sang một site khác có lẽ đã phức tạp hơn mức cần thiết.
Đúng lúc đó Microsoft mua lại GitHub, thời điểm mà sự suy tàn của GitHub lần đầu được dự đoán; thật thú vị khi thấy lịch sử lặp lại. GitLab đưa ra điều kiện cấp phép rất có lợi, và chúng tôi cũng cần một buổi trình diễn nội bộ về việc áp dụng Kubernetes và hạ tầng dưới dạng mã cho dịch vụ đám mây. Hiện tôi đã rời trường, nhưng GitLab vẫn đang chạy tại https://gitlab.developers.cam.ac.uk/ .
Vài năm sau không còn ai phụ trách vận hành, và khi GitHub trở nên rất phổ biến, người dùng chuyển từ dịch vụ nội bộ của trường sang hosting bên ngoài. Tôi tưởng dự án đã biến mất, nên rất vui khi thấy nó vẫn được duy trì đều đặn.
Có thể dùng danh sách kiểm soát truy cập chi tiết của gitolite để cho một số khóa chỉ được clone mà không được push, hoặc cho phép push nhưng cấm force push. Nó nhẹ và tiện lợi; nếu là bây giờ, có lẽ tôi sẽ thử dùng https://github.com/djmdjm/gitlimit .
Với dự án cá nhân, Fossil cũng phù hợp. Nó có web server tích hợp trong một binary nhỏ nên có thể phục vụ đơn giản, và khi cần cũng có thể tích hợp với kho Git upstream.
Ở NRAO, chúng tôi cũng từng dùng gitolite như một giải pháp tạm thời trong một thời gian. Khi đó công cụ được hỗ trợ chính thức là Subversion, nhưng trưởng nhóm đã cài đặt nó cho các người dùng nội bộ muốn dùng Git. Nó không có nhiều tính năng, nhưng xử lý đủ tốt những việc cần làm.
Hiện nay có một bản cài GitLab được cả đài thiên văn sử dụng, và cũng có khả năng chuyển sang GitHub hoặc GitLab, nhưng tôi không biết quyết định cuối cùng. Tôi dành nhiều thời gian để chỉnh sửa hệ thống tích hợp/phân phối liên tục, nhưng không nghĩ ra cách hỗ trợ việc đó bằng gitolite hay triển khai workflow pull/merge request. Dù vậy, có thể lợi ích của các tính năng đó đã bị thổi phồng.
Tôi dùng fugit(https://github.com/cbdevnet/fugit), được tạo ra với mục tiêu cực kỳ đơn giản, và quản lý tệp cấu hình bằng module Nix. Nó đơn giản và hiệu quả; gitolite thì lúc nào cũng hơi phiền khi sử dụng.