Perbaiki nama pengguna saat melacak / etc / in repositori git dan lakukan sebagai root

13

Kami menggunakan git untuk melacak perubahan di /etc/server kami.

Administrator bekerja sebagai root ketika mengubah file di / etc /, dan karenanya komit mereka memiliki penulis

root <root@machinename>

Ini tidak terlalu memuaskan karena Anda tidak dapat melihat admin mana yang benar-benar melakukan perubahan.

Apa yang bisa kita lakukan untuk mendapatkan nama admin asli di log git? Saya tidak berpikir bahwa menjaga klon lokal repositori dapat dilakukan karena kita sering berubah secara interaktif sampai sesuatu bekerja, dan siklus perubahan-komit-tekan-lihat-Koreksi-ulang tidak akan membantu di sini.

— cweiske
sumber

Sebagai root aktual, atau sudo akan di-root?

— Decado

Saat ini sebagai root aktual (ssh root @ atau "su", no sudo)

— cweiske

Gunakan etckeeper, itu mengurus gotcha aneh seperti ini di versi / dll. Juga mulai menggunakan akun per pengguna dan sudo.

— Caleb

12

Nama git author dan committer dapat dipengaruhi oleh variabel lingkungan GIT_COMMITTER_NAME,GIT_COMMITTER_EMAIL , GIT_AUTHOR_NAMEdan GIT_AUTHOR_EMAIL.

Sekarang triknya adalah mengirimkan variabel-variabel itu ke server jarak jauh ketika terhubung melalui SSH:

Tentukan dan ekspor variabel dalam ~/.bashrcfile Anda :
```
export GIT_AUTHOR_NAME="Christian Weiske"
```
Secara otomatis mengirim mereka dengan koneksi SSH dengan menyesuaikan ~/.ssh/config:
```
SendEnv LANG LC_* GIT_*
```
LANG dan LC_* tidak perlu, tetapi Debian memiliki ssh_config default mereka, jadi saya pikir saya harus mengirimkannya juga
Di server jarak jauh, sesuaikan konfigurasi sshd di /etc/ssh/sshd_configuntuk menerima GIT_*variabel lingkungan:
```
AcceptEnv LANG LC_* GIT_*
```

Voila - git commitsebagai root di /etc/mengarah ke:

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

Dalam kasus kesalahan serverf beberapa waktu di masa depan: http://cweiske.de/tagebuch/carry-git-settings.htm

— cweiske
sumber

5

Pertama, dan tidak terkait dengan pertanyaan Anda, saya akan mendesak Anda untuk segera berhenti menggunakan rootlogin sudan menggunakan login pengguna dansudo sebagai gantinya. Batasi rootlogin Anda hanya untuk konsol, atau bahkan tidak untuk itu.

Yang mengatakan, git commitmemiliki --authoropsi yang dapat membantu Anda di sana:

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

Anda juga dapat dengan hati-hati menggunakan variabel lingkungan per pengguna untuk mengatur GIT_AUTHOR_NAMEdan GIT_AUTHOR_EMAILvariabel. Dalam log, akan muncul penulis yang berbeda dan komiter yang sama ( root@host), tetapi itu akan memberi Anda lebih banyak audit. Tentu saja itu berarti Anda mempercayai admin Anda untuk menjaga variabel tetap utuh. Karena masing-masing menggunakan shell tertentu, mereka bisasudo me-root dan sumber file dengan gitvariabel spesifik mereka , mengidentifikasi masing-masing berbeda pada komit. Tidak terlalu praktis, tetapi Anda bahkan dapat mengotomatiskannya dengan skrip.

EDIT: Tentu saja pendekatan yang lebih baik seperti yang ditunjuk oleh @ScottPack adalah menggunakan sistem manajemen konfigurasi seperti Wayang atau Koki dan menggunakan git untuk melacak perubahan pada server pusat dan bukan pada server nyata sehingga setiap admin dapat memiliki copy pekerjaan konfigurasi.

— coredump
sumber

--authortentu saja mungkin tetapi orang tidak menggunakannya dalam alur kerja normal mereka karena terlalu banyak untuk ditulis. Pada ide kedua Anda untuk menggunakan sudo: Saya salah satu dari orang-orang yang menganggap sudo berbahaya dan lebih suka menggunakan akses ssh root dengan kunci ssh saja. Dan ya, kami mempercayai admin kami.

— cweiske

5

@cweiske mengapa Anda menganggap sudo berbahaya?

— coredump

1

@cweiske Sudahkah Anda mempertimbangkan skrip pembungkus yang menginterogasi committer untuk informasi penting (siapa mereka, apa yang mereka ubah, mengapa perubahan itu dilakukan, nomor tiket jika berlaku)? Tempat kerja terakhir saya memiliki sistem serupa (berbasis CVS) untuk perubahan DNS, dengan pembungkus untuk menegakkan kebijakan - secara mengejutkan bekerja dengan baik.

— voretaq7

4

@cweiske Saya tidak setuju sedikit pun dengan penilaian Anda. Anda dapat menggunakan agen ssh untuk menyimpan kata sandi kunci ssh dan masuk tanpa berpikir ke mesin root, atau cukup menggunakan kata sandi sederhana atau kata sandi yang sama pada mesin Anda daripada kata sandi root, sementara dengan sudoAnda memaksa pengguna untuk mengetikkan kata sandi (bahkan jika dia menggunakan kunci ssh untuk login sebagai penggunanya) dan Anda dapat mengontrol apa yang dapat dijalankan pengguna dan terutama Anda memiliki jejak audit tentang siapa yang telah melakukan apa. Tapi semua orang berhak atas pendapat mereka sendiri.

— coredump

2

Anda juga dapat mengonfigurasi sudountuk memaksa pengguna memasukkan kata sandi untuk setiap perintah ( timestamp_timeout = 0). Mungkin tidak cocok untuk pengembangan dan pementasan kotak tetapi tentu cocok untuk produksi. IMHO, berdasarkan pada konsensus SF, Anda harus memikirkan kembali pandangan Anda sudo. Salah satu hal hebat tentang SF adalah memiliki komunitas teman sebaya yang benar-benar tahu sh * t :-).

— Belmin Fernandez

3

Dengan dempul Anda dapat mengatur ini di bawah "Koneksi -> Data -> Variabel Lingkungan".

Mereka juga ada setelah ' su' root.

— Cybot
sumber

3

Jika Anda kebetulan menyediakan akun pengguna di server Anda menggunakan kunci ssh, Anda sebenarnya dapat melampirkan variabel lingkungan ke kunci yang diotorisasi pada waktu setup - misalnya di ~ bob / .ssh / official_keys

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

Dengan cara ini ketika pengguna SSH di dalamnya secara otomatis memiliki pengaturan envs ini - tidak perlu bagi mereka untuk meneruskannya dari klien lokal. Poin bonus jika Anda sudah memiliki info ini dan menghasilkan konfigurasi otor_keys dari sistem manajemen konfigurasi.

Catatan: PermitUserEnvironment yesPersyaratan di atas memerlukan sshd_config

— minaguib
sumber

1

Jika Anda menggunakan sudo dan non-root Anda memiliki direktori home mereka terpasang:

git -c include.path=<file>akan menyertakan konfigurasi dalam <file>.

Untuk secara otomatis menarik file konfigurasi pengguna non-root saya, saya menggunakan bashalias:

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

Lalu saya gunakan gsudosebagai ganti dari gitkeduanya:

Jalankan sebagai root
Memiliki akses ke semua konfigurasi git pengguna non-root

Periksa apakah konfigurasi memang sedang diimpor:

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

— Tom Hale
sumber

0

Selain jawaban coredump, Anda juga dapat mengatur opsi-opsi ini dalam .git/configfile dalam copy pekerjaan repositori Anda (dengan tangan, atau menggunakan git configperintah.

Lihat man git-configuntuk info lebih lanjut tentang perintah dan hal-hal keren yang dapat Anda lakukan dengannya.

— voretaq7
sumber

Ini hanya berfungsi jika satu admin melakukan repo itu di mesin itu, tetapi gagal dengan beberapa admin.

— cweiske

Benar - ini lebih cocok untuk situasi di mana Anda memiliki repositori pusat dan orang-orang mengkloning & menarik / mendorong repo itu.

— voretaq7