แก้ไขชื่อผู้ใช้เมื่อทำการติดตาม / etc / ในที่เก็บ git และคอมมิทเป็น root

13

เราใช้คอมไพล์เพื่อติดตามการเปลี่ยนแปลงใน/etc/เซิร์ฟเวอร์ของเรา

ผู้ดูแลระบบทำงานเป็นรูทเมื่อเปลี่ยนไฟล์ใน / etc / ดังนั้นคอมมิทจึงมีผู้เขียน

root <root@machinename>

สิ่งนี้ไม่เป็นที่น่าพอใจมากนักเนื่องจากคุณไม่เห็นว่าผู้ดูแลระบบคนใดทำการเปลี่ยนแปลง

เราจะทำอย่างไรเพื่อให้ได้ชื่อผู้ดูแลระบบที่แท้จริงในบันทึก git? ฉันไม่คิดว่าการเก็บรักษาโคลนโลคัลของที่เก็บเป็นไปได้เนื่องจากเราเปลี่ยนบ่อย ๆ จนกว่าสิ่งที่ใช้งานได้และวงจรการเปลี่ยนคอมมิชชัน - push-seeError จะไม่ช่วยที่นี่

— cweiske
แหล่งที่มา

ในฐานะที่เป็นรูทจริงหรือว่ารูตของ sudo

— Decado

ขณะนี้เป็นรูทจริง (ssh root @ หรือ "su", no sudo)

— cweiske

ใช้etckeeperมันดูแล gotchas แปลก ๆ เช่นนี้ใน versioning / etc sudoนอกจากนี้ยังเริ่มใช้บัญชีต่อผู้ใช้และ

— Caleb

12

คอมไพล์เขียนและ committer ชื่อสามารถมีอิทธิพลกับสภาพแวดล้อมตัวแปรGIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, และGIT_AUTHOR_NAMEGIT_AUTHOR_EMAIL

ตอนนี้เคล็ดลับคือการส่งตัวแปรเหล่านั้นไปยังเซิร์ฟเวอร์ระยะไกลเมื่อเชื่อมต่อผ่าน SSH

กำหนดและส่งออกตัวแปรใน~/.bashrcไฟล์ของคุณ:
```
export GIT_AUTHOR_NAME="Christian Weiske"
```
ส่งพวกเขาโดยอัตโนมัติด้วยการเชื่อมต่อ SSH โดยการปรับ~/.ssh/config:
```
SendEnv LANG LC_* GIT_*
```
LANGและLC_*ไม่จำเป็น แต่ Debian มีค่าเริ่มต้นเป็น ssh_config ดังนั้นฉันคิดว่าฉันควรส่งพวกเขาด้วย
บนเซิร์ฟเวอร์ระยะไกลปรับการกำหนดค่าsshdใน/etc/ssh/sshd_configเพื่อยอมรับGIT_*ตัวแปรสภาพแวดล้อม:
```
AcceptEnv LANG LC_* GIT_*
```

Voila - git commitเป็นราก/etc/นำไปสู่:

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

ในกรณีที่เซิร์ฟเวอร์เกิดข้อผิดพลาดในอนาคต: http://cweiske.de/tagebuch/carry-git-settings.htmในอนาคต

— cweiske
แหล่งที่มา

5

ก่อนอื่นและไม่เกี่ยวข้องกับคำถามของคุณฉันขอแนะนำให้คุณหยุดใช้การเข้าสู่ระบบอย่างเร่งด่วนและใช้การเข้าสู่ระบบของผู้ใช้แทน จำกัด การเข้าสู่ระบบของคุณเพื่อคอนโซลเท่านั้นหรือไม่แม้แต่นั้นrootsusudoroot

ที่กล่าวว่าgit commitมี--authorตัวเลือกที่สามารถช่วยคุณได้:

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

คุณยังสามารถใช้ตัวแปรสภาพแวดล้อมอย่างรอบคอบต่อผู้ใช้ในการตั้งค่าGIT_AUTHOR_NAMEและGIT_AUTHOR_EMAILตัวแปร ในบันทึกจะมีผู้แต่งและผู้แต่ง ( root@host) ที่แตกต่างกันแต่จะให้การตรวจสอบมากขึ้น แน่นอนว่าคุณเชื่อใจผู้ดูแลระบบของคุณเพื่อให้ตัวแปรยังคงเหมือนเดิม ในขณะที่แต่ละคนใช้เชลล์ที่เฉพาะเจาะจงพวกเขาสามารถที่sudoจะรูทและแหล่งไฟล์ที่มีgitตัวแปรเฉพาะของพวกเขาระบุแต่ละคนแตกต่างกันในการกระทำ ไม่ได้ใช้งานได้จริง แต่คุณอาจใช้สคริปต์นั้นโดยอัตโนมัติ

แก้ไข:แน่นอนวิธีที่ดียิ่งกว่าที่ได้รับการแต่งตั้งโดย @ScottPack คือการใช้ระบบการจัดการการกำหนดค่าเช่น Puppet หรือ Chef และใช้ git เพื่อติดตามการเปลี่ยนแปลงบนเซิร์ฟเวอร์กลางและไม่ได้อยู่บนเซิร์ฟเวอร์จริงเพื่อให้ผู้ดูแลระบบแต่ละคนสามารถทำงานได้ ของการกำหนดค่า

— coredump
แหล่งที่มา

--authorเป็นไปได้แน่นอน แต่ผู้คนไม่ได้ใช้สิ่งนั้นในเวิร์กโฟลว์ปกติของพวกเขาเพราะมันเขียนมากเกินไป ในความคิดที่สองของคุณที่จะใช้ sudo: ฉันเป็นหนึ่งในคนที่พิจารณาว่า sudo เป็นอันตรายและค่อนข้างใช้การเข้าถึงรูต ssh ด้วยคีย์ ssh เท่านั้น และใช่เราเชื่อใจผู้ดูแลระบบของเรา

— cweiske

5

@cweiske ทำไมคุณถึงคิดว่า sudo เป็นอันตราย?

— coredump

1

@cweiske คุณได้พิจารณาสคริปต์ตัวคลุมที่คอยสอบถามข้อมูลสำคัญ (พวกเขาคือใครสิ่งที่พวกเขาเปลี่ยนทำไมการเปลี่ยนแปลงที่เกิดขึ้นหมายเลขตั๋วถ้ามี)? สถานที่สุดท้ายที่ฉันจ้างมีระบบที่คล้ายกัน (อิงกับ CVS) สำหรับการเปลี่ยนแปลง DNS พร้อมด้วย wrappers เพื่อบังคับใช้นโยบาย - ทำงานได้ดีอย่างน่าประหลาดใจ

— voretaq7

4

@ cweiske ฉันไม่เห็นด้วยเล็กน้อยกับการประเมินของคุณ คุณสามารถใช้ตัวแทน SSH แคชรหัสผ่านที่สำคัญ SSH และเหตุผลเข้าสู่เครื่องรากหรือเพียงแค่ใช้รหัสผ่านง่ายหรือรหัสผ่านเดียวกันบนเครื่องของคุณมากกว่าข้อความรหัสผ่านรากขณะที่sudoคุณบังคับให้ผู้ใช้สามารถพิมพ์รหัสผ่าน (แม้ ถ้าเขาใช้คีย์ ssh เพื่อเข้าสู่ระบบในฐานะผู้ใช้ของเขา) และคุณสามารถควบคุมสิ่งที่ผู้ใช้สามารถดำเนินการและส่วนใหญ่คุณมีหลักฐานการตรวจสอบของผู้ที่ได้ทำอะไร แต่ทุกคนมีสิทธิ์ที่จะแสดงความคิดเห็นของตนเอง

— coredump

2

คุณสามารถกำหนดค่าsudoเพื่อบังคับให้ผู้ใช้ป้อนรหัสผ่านสำหรับแต่ละคำสั่งและทุกคำสั่ง ( timestamp_timeout = 0) อาจไม่เหมาะสำหรับการพัฒนาและการจัดเตรียมกล่อง แต่ก็เหมาะสมสำหรับการผลิต IMHO บนพื้นฐานของฉันทามติ SF sudoคุณควรคิดใหม่ในมุมมองของคุณ หนึ่งในสิ่งที่ยอดเยี่ยมเกี่ยวกับ SF คือการมีชุมชนเพื่อนที่รู้จัก sh * t :-)

— Belmin Fernandez

3

ด้วยสีโป๊วคุณสามารถตั้งค่านี้ภายใต้ "การเชื่อมต่อ -> ข้อมูล -> ตัวแปรสภาพแวดล้อม"

พวกเขายังอยู่หลังจาก ' su' เพื่อรูต

— Cybot
แหล่งที่มา

3

หากคุณเกิดขึ้นกับการจัดเตรียมบัญชีผู้ใช้บนเซิร์ฟเวอร์ของคุณโดยใช้คีย์ ssh คุณสามารถแนบตัวแปรสภาพแวดล้อมกับคีย์ที่ได้รับอนุญาต ณ เวลาที่ติดตั้งตัวอย่างเช่นใน ~ bob / .ssh / authorized_keys

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

วิธีนี้เมื่อผู้ใช้ SSH มีการตั้งค่า envs เหล่านี้โดยอัตโนมัติ - ไม่จำเป็นต้องส่งต่อจากไคลเอ็นต์โลคัล คะแนนโบนัสหากคุณมีข้อมูลนี้อยู่แล้วและกำลังสร้าง authorized_keys configs จากระบบการจัดการการกำหนดค่า

หมายเหตุ: ข้างต้นจำเป็นต้องใช้PermitUserEnvironment yesใน sshd_config

— minaguib
แหล่งที่มา

1

หากคุณกำลังใช้งานอยู่sudoและผู้ใช้ที่ไม่ใช่รูทของคุณได้ติดตั้งโฮมไดเรกทอรีไว้แล้ว:

git -c include.path=<file><file>จะรวมถึงการกำหนดค่าใน

หากต้องการดึงไฟล์ปรับแต่งของผู้ใช้ที่ไม่ใช่รูทโดยอัตโนมัติฉันใช้bashนามแฝง:

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

จากนั้นฉันใช้gsudoแทนgitทั้งสอง:

เรียกใช้เป็นรูต
สามารถเข้าถึงการกำหนดค่า git ของผู้ใช้ที่ไม่ใช่รูททั้งหมด

ตรวจสอบว่าการกำหนดค่ากำลังถูกนำเข้าจริง:

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

— ทอมเฮล
แหล่งที่มา

0

นอกจากคำตอบของ coredump คุณยังสามารถตั้งค่าตัวเลือกเหล่านี้ใน.git/configไฟล์ในสำเนาการทำงานของพื้นที่เก็บข้อมูล (ด้วยมือหรือใช้git configคำสั่ง

ดูman git-configข้อมูลเพิ่มเติมเกี่ยวกับคำสั่งและสิ่งดีๆที่คุณสามารถทำได้

— voretaq7
แหล่งที่มา

สิ่งนี้จะทำงานได้ก็ต่อเมื่อมีผู้ดูแลระบบคนหนึ่งที่ทำธุรกรรมซื้อคืนบนเครื่องนั้น แต่ล้มเหลวเนื่องจากมีผู้ดูแลหลายคน

— cweiske

จริง - มันเหมาะสำหรับสถานการณ์ที่คุณมีที่เก็บส่วนกลางและผู้คนโคลน & ดึง / ดันไปที่ repo นั้น

— voretaq7