/Etc/apt/sources.list.d'nin /etc/apt/sources.list'e göre avantajı nedir?

Bu sorunun daha önce sorulduğunu biliyorum, ancak "özel eklemeleri açıkça görebilirsiniz" yanıtını kabul etmiyorum. Ppa'ları eklediğimde (yıllardır yapmadım), klavyemde yeni girişten önce boş bir satır eklememe izin veren "Enter" etiketli bir tuşa bastım (açıklayıcı bir yorum bile ekleyeceğim, ancak ben teknoloji yazarı, yani ....). sources.confTemiz ve düzenli olduğumu seviyorum .

/etc/apt/sources.d

Ayrıştırmak için bir yerine yarım düzine dosyam var demektir.

AFAIK, 6'ya karşı bir yapılandırma dosyasına sahip olmanın "kesinlikle" hiçbir avantajı yoktur (argüman uğruna, belki 3 veya hatta 2'ye sahipsiniz, önemli değil ... 1 hala 2 yener).

Birisi lütfen rasyonel bir avantaj elde edebilir mi, "açıkça özel eklemeler görebilirsiniz" fakir bir adamın mazereti.

Eklemek zorundayım, değişikliği seviyorum, ancak SADECE değişikliğin getirdiği faydalar olduğunda.

İlk yanıttan sonra düzenle:

Yinelenen girişler eklemediğinden emin olmak için kendi depolarına ihtiyaç duyan yeni yüklemelerin düz bir dosyada arama yapmasına izin vermez.

Şimdi, bir dizini düz dosya yerine dupe için aramak zorundalar. Yöneticinin bir şeyleri değiştirmediğini varsaymadıkları sürece ...

Sistem yöneticisinin, tek parça bir dosyayı düzenlemek zorunda kalmadan bir havuz kümesini kolayca devre dışı bırakmasını (yeniden adlandırarak) veya kaldırmasını (silerek) sağlar.

Yönetici, yeniden adlandırmak için uygun dosyayı bulmak için dizini grep gerekir, daha önce, bir dosya aramak ve herhangi bir yönetici "neredeyse" için bir satır, bir sed yorum.

Bir paket koruyucusunun, ilgisiz depolar için yapılandırmayı istemeden değiştirmekten endişe etmeden depo konumlarını güncellemek için basit bir komut vermesine izin verir.

Ben bunu anlamıyorum, ben paket sorumlusunun deposunun URL'sini bildiğini "varsayıyorum". Yine, sedtek bir dosya yerine bir dizine sahip .

Teknik düzeyde, birkaç büyük ve popüler sistem bilgi aracında bu değişiklikleri ele almak zorunda olan biri olarak, temelde bu aşağıya gelir:

Sources.list.d / için

# to add
if [[ ! -e /etc/apt/sources.list.d/some_repo.list ]];then
  echo 'some repo line for apt' > /etc/apt/sources.list.d/some_repo.list
fi

# to delete
if [[ -e /etc/apt/sources.list.d/some_repo.list ]];then
  rm -f /etc/apt/sources.list.d/some_repo.list
fi

Aşağıdaki ile aynı kontrolü yapmadıkları sürece, bir repo hattını yorumlamış olsaydınız, bu testlerin yanlış olacağını unutmayın. Aşağıdaki ile aynı kontrolü yapıyorlarsa, bir dosya değil, birçok dosya üzerinde yapılanlar dışında aynı karmaşıklıktır. Ayrıca, TÜM olası dosyaları kontrol etmedikçe, siz bunları silinceye kadar yinelenen bir öğe ekleyebilirler ve yinelenen bir öğe ekleyebilirler.

Sources.list için

# to add. Respect commented out lines. Bonus points for uncommenting
# line instead of adding a new line
if [[ -z $( grep -E '\s*[^#]\s*some repo line for apt' /etc/apt/sources.list ) ]];then
  echo 'some repo line for apt' >> /etc/apt/sources.list
fi

# to delete. Delete whether commented out or not. Bonus for not
# deleting if commented out, thus respecting the user's wishes
sed -i '/.*some repo line for apt.*/d' /etc/apt/sources.list

Google Chrome geliştiricileri, Chrome paketlerinin mevcut olması için oluşturduğu dosya adına bağlı olarak Google Chrome kaynaklarının varlığını kontrol etmedi. Diğer tüm durumlarda, sources.list.d dosyasında tam olarak istedikleri şekilde adlandırılan yeni bir dosya oluştururlar.

Hangi kaynaklara sahip olduğunuzu görmek elbette o kadar hoş değil, çünkü okumak ve korumak daha kolay olamaz:

cat /etc/sources.list

Bu temelde otomatik güncellemeler ve kullanıcılara verebileceğim kadar kolay tek komutlar sağlamak için yapıldı. Kullanıcılar için, bir repo ekleyip eklemediklerini görmek için 1 dosya yerine birçok dosyayı okumak zorunda oldukları ve apt için de bir dosya yerine birçok dosyayı okuması gerektiği anlamına gelir.

Gerçek dünyada, eğer bunu iyi yapacak olsaydınız, isimleri ne olursa olsun, tüm dosyalara karşı kontrolleri desteklemeniz ve ardından gerçekleştirilecek eylemin gerekli olup olmadığını test etmeniz gerekir.

Ancak, bunu iyi yapmayacak olsaydınız, öğenin kaynaklarda bir yerde olup olmadığını görmek için kontrolleri görmezden gelir ve sadece dosya adını kontrol edersiniz. En otomatik şeylerin yaptığı şey olduğuna inanıyorum, ama sonunda, her şeyi kontrol etmek zorunda kaldım, böylece listeleyebildim ve bu dosyalardan birinin eşleştiğine göre hareket edebildim, tek gerçek sonuç çok daha karmaşık hale getirdi.

Toplu Düzenlemeler

Birçok sunucu çalıştırdığı göz önüne alındığında, sadece /etc/apt/sources.list.d/ adresinden geçen ve ilk önce öğenin kaynaklarda olmadığından emin olmak için kontrol eden her gece senaryo yazmam cazip olurdu. değil, bu öğeyi sources.list'e ekleyin, sources.list.d dosyasını silin ve zaten sources.list'de varsa, sources.list.d dosyasını silin

Sadece kaynakları kullanmak için HİÇBİR negatif olmadığından, basitlik ve bakım kolaylığı ötesinde, böyle bir şey eklemek kötü bir fikir olmayabilir, özellikle sys yöneticileri tarafından yaratıcı rastgele eylemler verildiğinde.

Yukarıdaki yorumda belirtildiği gibi, inxi -r, etkin depoları dosya başına düzgün bir şekilde yazdıracak, ancak elbette bunları düzenlemeyecek veya değiştirmeyecektir, bu yüzden çözümün sadece yarısı olacaktır. Eğer çok sayıda dağılım varsa, her birinin nasıl yapıldığını öğrenen bir acıdır, bu kesinlikle ve rastgele, ne yazık ki istisnadan ziyade kesinlikle kuraldır.

Her havuzun (veya depo koleksiyonunun) kendi dosyasında bulunması, hem elle hem de programlı olarak yönetmeyi kolaylaştırır:

• Yinelenen girişler eklemediğinden emin olmak için kendi depolarına ihtiyaç duyan yeni yüklemelerin düz bir dosyada arama yapmasına izin vermez.
• Sistem yöneticisinin, tek parça bir dosyayı düzenlemek zorunda kalmadan bir havuz kümesini kolayca devre dışı bırakmasını (yeniden adlandırarak) veya kaldırmasını (silerek) sağlar.
• Bir paket koruyucusunun, ilgisiz depolar için yapılandırmayı istemeden değiştirmekten endişe etmeden depo konumlarını güncellemek için basit bir komut vermesine izin verir.

Sunucularınızı manuel olarak yönetiyorsanız, işleri daha karmaşık hale getireceğini kabul edeceğim. Ancak, programlı yönetime yarar sağlar (yani "kod olarak yapılandırma"). Puppet, Ansible, Chef, vb. Gibi yapılandırma yönetimi yazılımlarını kullanırken, apt updatebelirli satırları eklemek veya kaldırmak için bir dosyayı ayrıştırmak yerine, bir dosyayı direk ve çalıştırmada bırakmak veya kaldırmak daha kolaydır .

Özellikle bu, tek bir 'dosya' kaynağının içeriğini, örneğin: /etc/apt/sources.listüçüncü taraflar tarafından yazılan çoklu bağımsız modüllerden yönetmek zorunda kalmamaktan kaçınır .

Bu özel nedenle Ubuntu'nun ".d" dizinlerinin geniş kullanımını takdir ediyorum, yani sudoers.d, rsyslog.d, sysctl.d., Cron.d, logrotate.d, vb.

Nemo'nun bir yorumda belirttiği gibi , bir dizinin en önemli avantajlarından biri "sahiplik" kavramına izin vermesidir.

Modern Linux dağıtımları ve kurucuları, paketler fikrine dayanır - mümkün olduğunca atomik olarak eklenebilen ve çıkarılabilen bağımsız yazılım parçaları. dpkg(Ve bu nedenle apt) ile bir paket yüklediğinizde , sistemde hangi dosyaların o yükleyici tarafından oluşturulduğunu izler. Paketi kaldırmak daha sonra büyük ölçüde bu dosyaları silmeyi içerebilir.

Şu anda kabul edilen cevap , bir Google Chrome yükleyicisinin yalnızca beklediği yerde bir giriş oluşturması veya silmesi gerektiğini varsayması kötü bir şey olarak kabul etmektedir, ancak başka bir şeyi otomatikleştirmek her türlü korkunç kenar durumuna yol açar; Örneğin:

• sources.listYükleme sırasında satır varsa , ancak yorum yapılmışsa, yükleyici bunu kaldırmalı mı veya bir kopya mı eklemeli?
• Kaldırıcı satırı kaldırır, ancak kullanıcı yanına yorumlar eklediyse veya düzenlediyse, dosya kırık yorumlarla bırakılacaktır.
• Kullanıcı satırı manuel olarak eklediyse, yükleyici eklemeyi bilmeyebilir; ancak kaldırıcı kaldırmamayı nasıl bilebilirdi?

Sahiplik için ayrı dosyalar gerekli değildir; örneğin, yükleyici belirli bir satır kümesine "sahip olduğunu" belirten bir yorum bloğu içerebilir. Bu durumda, dosyada her zaman aynı depodan başka bir söz için değil, tam olarak bu blok için arama yapılır.

Diğer her şey eşit olduğunda, tek bir yapılandırma dosyasında düzenlemeleri otomatikleştirmek, ayrı bir dosyanın oluşturulmasını ve silinmesini otomatikleştirmekten her zaman daha karmaşık olacaktır. En azından, çizgilerin kaldırılması gibi bazı desen eşleştirme araçlarının kullanılmasını gerektirir sed. Daha karmaşık bir dosyada, satır ekleme ve çıkarma, uygun bir bölüme eklemek veya çevredeki biçimlendirmeye zarar vermeden kaldırmak için dosya biçimi bilgisine sahip bir komut dosyası aracı gerektirebilir.

Bir yükleyicinin yine de elle düzenlenen yapılandırmayla uğraşmaktan kaçınması gerektiğinden, otomatik, alete ait yapılandırmayı otomatik araçların yönetmesi kolay bir biçimde koymak mantıklıdır.

Bu, paketlerin komut dosyalarına başvurmadan ek kaynaklar eklemesine izin verir.

Örneğin, Microsoft'un Skype paketini yüklediğinizde, güncellemeleri indirmek için skype.com için bir kaynak otomatik olarak yapılandırılır; Skype paketinin sistemden kaldırılması da bu paket kaynağını tekrar devre dışı bırakır.

Düz bir dosyayla aynı etkiye sahip olmak istiyorsanız, Skype için kurulum komut dosyalarının, muhtemelen birçok sistem yöneticisinin biraz sinir bozucu bulacağı kaynaklar.listinizi değiştirmeniz gerekir.

Modaya uygun görünmekten başka iyi bir neden olduğuna ikna olmadım. Benim için, bir dizinin bir yaprak veya düğüm olması gerektiği kuralını ihlal ediyor - yani her ikisinin bir karışımını değil, yalnızca dosyaları veya dizinleri içermesi gerekir.

Dosyaları daha küçük, okumayı çok daha kolay hale getirdiğini düşünüyorum - örneğin, oldukça uzun olabilen sudo kuralları durumunda, bir kullanıcı türü için standartlaştırılmış bir kurallar kümesine sahip olmayı kolaylaştırır (bir geliştirici söyleyin) ) ve geliştiricilerin bu makinede sudo yapmasına izin verilmesi gerekiyorsa bunları config dizinine ekleyin; bu nedenle daha az dosya tutmanız gerekir - bunların olası her birleşimi yerine devs, yöneticiler, sysops vb. için bir dosya.

Orada kendimle çeliştim.