Sửa tên người dùng khi theo dõi / etc / trong kho git và cam kết là root

13

Chúng tôi sử dụng git để theo dõi các thay đổi /etc/trên máy chủ của chúng tôi.

Quản trị viên làm việc với quyền root khi thay đổi tệp trong / etc /, và do đó, cam kết của họ có tác giả

root <root@machinename>

Điều này không thỏa mãn lắm vì bạn không thể thấy quản trị viên nào thực sự thay đổi.

Chúng ta có thể làm gì để có được tên quản trị viên thực sự trong nhật ký git? Tôi không nghĩ rằng việc giữ một bản sao cục bộ của kho lưu trữ là khả thi vì chúng ta thường thay đổi tương tác cho đến khi một cái gì đó hoạt động và một chu trình thay đổi-cam kết-đẩy-thấyError-lặp lại sẽ không giúp ích ở đây.

— cweiske
nguồn

Là root thực sự, hay sudo'd để root?

— Decado

Hiện tại là root thực tế (ssh root @ hoặc "su", không sudo)

— cweiske

Sử dụng etckeeper, nó sẽ chăm sóc các vấn đề kỳ lạ như thế này trong phiên bản / vv. Cũng bắt đầu sử dụng tài khoản trên mỗi người dùng và sudo.

— Caleb

12

Tác giả git và tên committer thể bị ảnh hưởng với các biến môi trường GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_AUTHOR_NAMEvà GIT_AUTHOR_EMAIL.

Bây giờ mẹo là gửi các biến đó đến máy chủ từ xa khi kết nối qua SSH:

Xác định và xuất các biến trong ~/.bashrctệp của bạn :
```
export GIT_AUTHOR_NAME="Christian Weiske"
```
Tự động gửi chúng bằng kết nối SSH bằng cách điều chỉnh ~/.ssh/config:
```
SendEnv LANG LC_* GIT_*
```
LANGvà LC_*không cần thiết, nhưng Debian có trong ssh_config mặc định của họ, vì vậy tôi nghĩ tôi cũng nên gửi chúng
Trên máy chủ từ xa, điều chỉnh cấu hình sshd/etc/ssh/sshd_config để chấp nhận GIT_*các biến môi trường:
```
AcceptEnv LANG LC_* GIT_*
```

Voila - một git commitgốc trong /etc/dẫn đến:

commit 8a4654f13241f05361283a88ce041a0fc24b8ac6
Author: Christian Weiske <christian.weiske@netresearch.de>

Trong trường hợp serverfault bị lỗi một thời gian trong tương lai: http : // cweiske.de/ voltbuch / car-git-sinstall.htmlm

— cweiske
nguồn

5

Đầu tiên, và không liên quan đến câu hỏi của bạn, tôi khuyên bạn nên khẩn trương dừng sử dụng thông tin rootđăng nhập suvà sử dụng thông tin đăng nhập của người dùng và sudothay vào đó. Hạn chế rootđăng nhập của bạn để chỉ bàn điều khiển, hoặc thậm chí không.

Điều đó nói rằng, git commitcó một --authortùy chọn có thể giúp bạn ở đó:

# git commit --author='Author Name <author@email.address.com>' -a

Bạn cũng có thể cẩn thận sử dụng các biến môi trường cho mỗi người dùng để đặt GIT_AUTHOR_NAMEvà GIT_AUTHOR_EMAILcác biến. Trong nhật ký, nó sẽ xuất hiện các tác giả khác nhau và cùng một commiter ( root@host), nhưng nó sẽ cung cấp cho bạn nhiều kiểm toán hơn. Tất nhiên điều đó có nghĩa là bạn tin tưởng quản trị viên của mình để giữ nguyên các biến. Vì mỗi người đang sử dụng một trình bao cụ thể, họ có thể sudoroot và nguồn một tệp với các gitbiến cụ thể của họ , xác định từng tệp khác nhau trên các cam kết. Không thực tế lắm, nhưng bạn thậm chí có thể tự động hóa điều đó với các tập lệnh.

EDIT: Tất nhiên một cách tiếp cận thậm chí tốt hơn theo chỉ định của @ScottPack sẽ là sử dụng hệ thống quản lý cấu hình như Puppet hoặc Chef và sử dụng git để theo dõi các thay đổi trên máy chủ trung tâm chứ không phải trên máy chủ thực để mỗi quản trị viên có thể có một bản sao hoạt động. của cấu hình.

— coredump
nguồn

--authortất nhiên là có thể nhưng mọi người không sử dụng nó trong quy trình làm việc bình thường của họ vì nó quá nhiều để viết. Về ý tưởng thứ hai của bạn để sử dụng sudo: Tôi là một trong những người cho rằng sudo có hại và thay vào đó chỉ sử dụng quyền truy cập ssh với các khóa ssh. Và vâng, chúng tôi tin tưởng quản trị viên của chúng tôi.

— cweiske

5

@cweiske tại sao bạn lại coi sudo có hại?

— coredump

1

@cweiske Bạn đã xem xét một kịch bản bao bọc để thẩm vấn người đi làm về thông tin quan trọng (họ là ai, họ đã thay đổi gì, tại sao thay đổi được thực hiện, số vé nếu có)? Nơi tuyển dụng cuối cùng của tôi có một hệ thống tương tự (dựa trên CVS) để thay đổi DNS, với các trình bao bọc để thực thi chính sách - hoạt động rất tốt.

— voretaq7

4

@cweiske Tôi không đồng ý một chút với đánh giá của bạn. Bạn có thể sử dụng một tác nhân ssh để lưu mật khẩu khóa ssh và vô tư đăng nhập vào máy gốc hoặc chỉ sử dụng một cụm mật khẩu đơn giản hoặc cùng một mật khẩu trên máy của bạn so với mật khẩu gốc, trong khi với sudobạn buộc người dùng phải nhập mật khẩu (thậm chí nếu anh ta sử dụng khóa ssh để đăng nhập với tư cách là người dùng của anh ta) và bạn có thể kiểm soát những gì người dùng có thể thực thi và chủ yếu bạn có một bản kiểm toán xem ai đã làm gì. Nhưng mọi người đều có quyền theo ý kiến riêng của họ.

— coredump

2

Bạn cũng có thể định cấu hình sudođể buộc người dùng nhập mật khẩu cho mỗi và mọi lệnh ( timestamp_timeout = 0). Có lẽ không phù hợp để phát triển và dàn hộp nhưng chắc chắn phù hợp cho sản xuất. IMHO, dựa trên sự đồng thuận của SF, bạn nên suy nghĩ lại về quan điểm của mình sudo. Một trong những điều tuyệt vời về SF là có một cộng đồng đồng nghiệp thực sự biết sh * t :-).

— Belmin Fernandez

3

Với putty, bạn có thể đặt phần này trong "Kết nối -> Dữ liệu -> Biến môi trường".

Họ cũng có mặt sau ' su' để root.

— Cybot
nguồn

3

Nếu bạn tình cờ cung cấp tài khoản người dùng trên máy chủ của mình bằng các khóa ssh, bạn thực sự có thể đính kèm các biến môi trường với các khóa được ủy quyền tại thời điểm thiết lập - ví dụ: trong ~ bob / .ssh / ủy quyền

environment="GIT_AUTHOR_NAME=Bob Smith",environment="GIT_AUTHOR_EMAIL=bob.smith@megacorp.com" ssh-rsa AAAA.... bob.smith@megacorp.com

Theo cách này khi người dùng SSH trong họ tự động có các thiết lập envs này - không cần họ chuyển tiếp chúng từ máy khách cục bộ. Điểm thưởng nếu bạn đã có thông tin này và đang tạo các cấu hình ủy quyền từ hệ thống quản lý cấu hình.

Lưu ý: Yêu cầu ở trên PermitUserEnvironment yestrong sshd_config

— minaguib
nguồn

1

Nếu bạn đang sử dụng sudovà người dùng không phải root của bạn có thư mục chính của họ được gắn kết:

git -c include.path=<file>sẽ bao gồm cấu hình trong <file>.

Để tự động lấy các tệp cấu hình người dùng không phải root của tôi, tôi sử dụng bashbí danh:

alias gsudo='sudo git -c "include.path='"${XDG_CONFIG_DIR:-$HOME/.config}/git/config\" -c \"include.path=$HOME/.gitconfig\""

Sau đó, tôi sử dụng gsudothay vì gitcả hai:

Chạy bằng root
Có quyền truy cập vào tất cả các cấu hình git người dùng không root

Kiểm tra xem cấu hình thực sự đang được nhập:

gsudo config --list --show-origin --includes | less

— Tom Hale
nguồn

0

Ngoài câu trả lời của coredump, bạn cũng có thể đặt các tùy chọn này trong .git/configtệp trong bản sao làm việc của kho lưu trữ (bằng tay hoặc sử dụng git configlệnh.

Xem man git-configđể biết thêm thông tin về lệnh và những điều thú vị bạn có thể làm với nó.

— voretaq7
nguồn

Điều này chỉ hoạt động nếu một quản trị viên cam kết trong repo đó trên máy đó, nhưng nó không thành công với một số quản trị viên.

— cweiske

Đúng - nó phù hợp hơn cho trường hợp bạn có một kho lưu trữ trung tâm và mọi người nhân bản & kéo / đẩy vào repo đó.

— voretaq7