Yama veya Çekirdek Hack

Bir sistem yükseltme projesindeyken, yaptığım şeylerden biri, bir müşterinin sistemini yeni bir Magento kurulumuna karşı dağıtmak. Önceki bir serbest çalışan, yüklenici, danışman veya ajans tarafından yapılan herhangi bir acımasız iş kritik iş yakalamak emin olmak için standart Magento parçası olmayan çekirdek kesmek veya ek dosyaları arıyorum.

Yine de beni her zaman zorlayan bir şey yamalar. Yıllar içinde Magento, genellikle bir güvenlik düzeltmesini veya bir gönderim / ödeme satıcısının API'sındaki değişikliği ele almak için "sürümler arası" düzeltme ekleri yayınladı.

Sorun, fark açısından bakıldığında, yamalar çekirdek saldırılardan ayırt edilemez - özellikle sisteme hangi yamaların (eğer varsa) uygulandığını bilmediğinizde.

Bu da soruma götürüyor.

Bir çekirdek kesmek ve bir yama arasında nasıl ayrım yapıyorsunuz?

Destek tarafından sağlanan Magento yamaları bir tür günlük ekler app/etc/applied.patches.list. Yama "komut dosyalarının" ne zaman veya ne kadar süredir bunu yaptığını bilmiyorum. CE yamaları da bunu yapıyor gibi görünüyor.

Bu sık sık uğraştığım bir şey (ve şu anda üzerinde çalışıyorum) ve ne yazık ki, şimdiye kadar tamamen manuel bir süreç - için ilk otomatik denetimimizin bir parçası olarak değiştirilebilecek her dosyayı işaretleyen otomatik bir işlemimiz var yeni bir destek istemcisi. Daha sonra birisinin bu dosyaları farklılaştırması ve bariz yanlış pozitifleri (yani boşluk değişiklikleri) dışlaması gerekir.

Daha sonra, eğlenceli kısım - ekibimizin bir süredir Magento ile çalışan kıdemli bir üyesi, değiştirilmiş dosyalardan herhangi birinin bir yama sonucu olup olmadığını belirlemek için sonuçlara bakmalıdır. Sistemimizin, farkında olduğumuz / ellerimizi tutabileceğimiz tüm yamalara karşı kontrol etmek için güncellemeye baktık ve bu CE için işe yarayabilir, ancak EE'de bazen daha zorlayıcıdır, çünkü EE desteği bazen doğrudan yamalar yayınlar asla başka bir şekilde piyasaya sürülmeyen veya tutarlı bir şekilde kataloglanan müşterilere.

Yani, bu inceleme seviyesini yaptığımızda, bu yamaları + sağduyu uygulama konusunda geçmiş deneyime güveniyoruz (yani, sadece bir API'nın uç noktasında bir değişiklik mi? Öyleyse, güncellenen sürümde bu değişen uç nokta mevcut mu? bir yamaydı ve göz ardı edilebilir).

CE indirme sayfasında bulunan tüm yamaları, CE'nin geçerli her sürümüne uygulamak ve bunlara karşı kontrol etmek teorik olarak basit olacaktır (FYI, ilk geçiş için fark kullanmıyoruz - hashing kullanıyoruz, çünkü bu teknolojiyi bir siteyi önce indirmeye gerek kalmadan uzaktan kontrol edebilen bir araca yerleştirdik). Bu, yamaların çoğunu ekarte eder, ancak CE için genel indirme alanına veya EE için istemci / korumalı indirme alanına gönderilmeyen CE veya EE yamalarına hala yardımcı olmaz. Bu, Magento'nun TÜM yamaların TÜM müşterilere sunulması için tutarlı bir politika yapmasını ve bunları alabileceğimiz yere gönderilmesini gerektirecektir.

Maalesef, Magento tarafında değişiklikler olana kadar bunu% 100 otomatikleştirmenin bir yolu olduğunu sanmıyorum.

Bir sürü yükseltme yaparken ve süreci sistematikleştirmeye çalışırken buna yaklaşmamın bir yolu, yamaları doğrudan karşı çıkmak için kullandığınız çekirdek kod deponuza koymaktı.

Bunun aslında iki faydası vardır:

1. Farklarınızda artık yanlış pozitifler görünmüyor.

2. Diyelim ki belirli bir yaması olmayan bir siteniz var. Bunun bir sorun olduğunu söyleyebilirsiniz, çünkü teknik olarak yeni bir eşlenmemiş indirme ile karşılaştırıldığında hiçbir şey eksik olmasa da farkınızdaki eksik kod olarak görünecektir. Ama aslında, bir yamayı kaçırmaları aslında çözülmesi gereken bir sorundur - bu yüzden yükseltme ile birlikte düzeltmeniz için farkınızda görünmesi mükemmeldir.

2-3'ten fazla müşteriyi yönetmeniz durumunda, proje deponuzda bir Magento bulundurmanın iyi bir fikir olduğunu düşünmüyorum. Uygulanan sistem yamalarını karotlarla karıştırmak her zaman daha kolay olduğu için.

En iyi seçenek, bence, olası resmi yamalar uygulanmış belirli bir Magento sürümüne işaret eden, sürüm etiketli bir besteci Magento depo aynasına sahip olmaktır.

Ayrıca, yüksek yüklü web siteleri ve diğerleri için Mage_Core_Model_Config gibi dosyalarda kendi yamalarınızı korumak, Magento taksitinizle eşleşen bir sürüm numarasıyla besteci aracılığıyla taksitlerini tanıtmak daha kolay olacaktır.

Bu durumda, tüm müşteri projelerini yamalanmış bir Magento koduna yükseltmeniz, besteci dosyanızın yalnızca sürüm yumruğuyla sonuçlanır. Ayrıca proje kodunu çekirdekten ayrı tutmak, geliştiricilerinizi çekirdeği hacklememeye zorlayacaktır.

Yama tanımı ve bir hack gelince, ben şöyle demeyi tercih ederim:

1. Resmi yama dosyasında orijinal çekirdek dosyada bir değişiklik - bu bir yama
2. Ekibiniz tarafından orijinal çekirdek dosyasında bir değişiklik - bu bir hack'tir.
3. Hata düzeltme amacıyla yerel kopyalanan çekirdek dosyada bir değişiklik - bu bir yama
4. Yeni işlevler sağlamak için yerel kopyalanan çekirdek dosyada bir değişiklik - bu bir hack

Çekirdeği ayrı bir repoya taşıyarak, 1. maddeye göre sadece yamalı sürümü kullandığınızdan emin olursunuz.Ve besteci üzerine kendi yamalarınızı yerel kod havuzuna kolayca kurabilirsiniz, böylece 3. noktaya göre her şeye sahip olursunuz. ve 4 bu dizinde herhangi bir kod taahhüdünü yasaklamak için proje deposunda bir git kesinleştirme kancası oluşturabilirsiniz.

Bu /app/etc/klasördeki yamalar uygulamasına bakıyorum ve geriye doğru çalışıyorum. Ancak yükseltme işleminden öğrendiğim gibi, dosyaları yamalanmış dosyanın bulunduğu bir sürümde silebilirim ve bir dahaki sefer yamalı temiz.

Magento'dan bir şey yama diyebilirim. Diğer her şey bir kesmek.