Neden çekirdeği hacklemiyoruz?

Bu sorunun bu sitede henüz yanıtlanmadığına inanamadım, ancak aradığımda bulamadım, bu yüzden ...

Çekirdeği kesmek neden doğaya karşı bu kadar kötü bir fikir suçudur?

• Temel sürümünüzü yükseltmek gerçekten bu kadar harika mı? Sitelerimin çoğu zaten korkunç güncel olmayan çekirdeklere sahip, bu yüzden neden rahatsız?
• Site sahipleri için bu kadar kötü olsa bile, topluluk neden bu kadar önemsiyor? Neden "yavru öldürme" olarak adlandırılır? Bu hiperbolik değil mi?
• Çekirdeği kesmek çok kolay, sorunların çözümüne daha kolay bir şekilde gitmekten hoşlanmıyor muyuz?
• Sadece çekirdeği hackleyerek çözülebilecek sorunlar yok mu? Sonra ne?

Genel olarak, Drupal çekirdek kodunu değiştirmemenin üç nedeni vardır:

• Gerekli adımları atmazsanız, Drupal'ı her güncellediğinizde değişiklikleriniz kaybolur. Kullandığınız geçerli Drupal sürümü için bir yama oluştursanız bile, yama daha yeni sürüme uygulanamaz ve yeni sürüm için de bir yama oluşturmanız gerekir.

• Güvenlik düzeltmeleri Drupal.org'da olduğu gibi Drupal çekirdeği için geçerlidir, ancak saldırıya uğrayan sürümünüz için geçerli değildir. Bu, sürümünüzün Drupal çekirdeğine karşı ortaya çıkan güvenlik sorunundan etkilenmediğini kontrol etmeniz gerektiği anlamına gelir.
  Saldırıya uğrayan sürümünüz farklı bir güvenlik sorunu ortaya çıkarsa, bulabileceğiniz tek kişi sizsiniz, çünkü Drupal çekirdek kodunda ve üçüncü taraflarda bulunan güvenlik kusurlarını araştıran güvenlik ekibinin desteğine sahip değilsiniz. Drupal.org'da barındırılan modüller.

• Yaptığınız değişiklikler Drupal'ın kendisi ile değil, aynı zamanda yaratabileceğiniz herhangi bir saldırı sürümü ile değil, Drupal çekirdeği ile çalışması gereken üçüncü taraf modülleriyle uyumlu olmayabilir.
  Drupal yeni bir özellik (Drupal 7'de ve Drupal 6'da daha az sıklıkta olmasına rağmen) veya yeni bir API değişikliği her tanıttığında, saldırıya uğrayan sürümün son değişikliklerle uyumsuz olma olasılığı vardır.

Bununla birlikte, saldırıya uğramış bir versiyon oluşturmak mümkündür, ancak tek bir geliştiricinin taşıyabileceği görev bu değildir, aynı şekilde Drupal tek bir kişi tarafından korunmaz. Aslında, Pressflow bir performans göz önünde bulundurularak oluşturulmuş ve bir Drupal sitesinin sahip olabileceği bazı performans sorunlarını çözmek saldırıya uğramış bir sürümüdür.

Sadece çekirdeği hackleyerek çözülebilecek sorunlar yok mu? Sonra ne?

Çoğu zaman, Drupal çekirdek kodunu düzenlemeden özellikleri / davranışı değiştirmek mümkündür. Her zaman Drupal'ın sahip olduğu özellikleri / davranışları değiştirmeye izin veren bir kanca vardır ve bu tercih edilen yöntemdir.

Burada büyük bir cevap yazabilirdim, ama sadece bu bağlantıyı göndereceğim : Asla çekirdek kesmek !

Sanırım asıl nedeni, ihtiyacınız olan bir şeyi yapmak için çekirdeği hack ederseniz ve sonra güncellerseniz ... BANG! Yaptığınız değişiklikler gitti. Kayıp. Daha sonra kodu VCS'nizden geri almayı deneyebilirsiniz, ancak veritabanı yükseltmelerini Drupal çekirdeğinden geri alamayacağınızı görün - VCS'den tüm kodu geri yüklemeye ve ardından yedeklemelerinizden veritabanlarını geri yüklemeye bakıyorsunuz. Kodunuzu geri almaya çalışırken, muhtemelen son güncelleme öncesi veritabanı yedeklemenizin başarısız olduğunu fark edeceksiniz ve daha önce yemin ettiğinizden daha fazla yemin edeceksiniz.

Ayrıca - en önemlisi - çekirdeği hack ederseniz, Dries ve Webchick her ikisi de bir yavru kedi öldürür: -o

"Çekirdek kesmek ne yapamaz benim için geliştirici?"

• Siteniz güvenlik sürümleri için yükseltilebilir
• Siteniz, can sıkıcı hataları düzeltmek için yeni sürüme geçirilebilir
• Siteniz yeni modülleri destekleyecek şekilde yeni sürüme geçirilebilir
• Temel raporunuzdaki ve katkıda bulunan hata raporlarınız ve destek talepleriniz yanıtlanabilecektir.
• Desteklenen bir CMS kullanmak istiyorsunuz, bu yüzden Drupal'ı seçtiniz. Çekirdeği hacklediğinizde , webchick'in sözleriyle , "Çekirdeği hack ederseniz, tebrikler! Kendi Drupal çatalını yarattınız ve şimdi siz ve tek başınıza korumakla sorumlusunuz!"

"Çekirdek kesmek ne müşteri için yapamaz?"

• Müşterinizi ateşledikten / piyangoyu kazandıktan / otobüsle vurulduktan sonra siteniz başka biri tarafından korunabilir

"Saldırı çekirdeği benim topluluğum için ne yapamaz?"

• Hata raporlarınız aslında çekirdek veya katkıda bulunan modüllerin bakımı için yararlı bilgiler sağlayacaktır.
• Çekirdekte yamanması gereken yasal bir hata bulursanız, 'saldırı çekirdeği' ve 'çekirdek katkıda bulunan olma' arasındaki çizgi, değişikliklerinizi basitçe dağıtmak ve ilgili bir sorun haline yama olarak yüklemek kadar iyidir. Viyola! Çekirdek çabalarınız için daha iyidir ve adınız topluluğa kod geri verme ile ilişkilidir.

Çekirdeği hacklemediğinizde herkes kazanır!

Şu anda saldırıya uğramış bir çekirdek web sitesinde çalışıyorum. Yazı tipi kadar basit bir şeyin nasıl kurulduğunu bulmakta zorlanıyorum. Ayrıca çekirdek hack tarafından tanıtılan bir hatayı düzeltmek için birkaç gün geçirdim. Bütün drupal kodunda bir dize arayarak buldum.

Drupal'da programlamanın standart yapısını takip etmiyorsanız, başkası tanıttığınız değişiklikleri nasıl bulabilir ve düzenleyebilir? Drupal'da her php dosyası bir kanca uygulayabildiğinden, bu özellikle acı vericidir. Hangisinin sorunlara neden olduğunu bulmaya çalışın.

"Sadece çekirdeği hackleyerek çözülebilecek sorunlar yok mu? Ne olacak?"

Bu soruyu cevaplamak için, evet, bazen üstesinden gelmek zorunda olduğunuz, çekirdeği (veya bir katkı modülünü) kesmek zorunda olduğunuz anlamına gelir.

Bu durumda, saldırıya uğramış kodunuza çok sayıda yorum koyduğunuz ve değiştirdiğiniz her şeyi belgelediğiniz sürece hacklemenin uygun olduğuna inanıyorum.

Örneğin, herhangi bir çekirdek veya katkı değişikliği için bir yama oluşturuyorum. Diğer insanlar için genel ve faydalıysa, bir konuda drupal.org'a gönderirim, aksi takdirde kendi kullanımım içindir.

Daha sonra yama dosyasını kod değişikliğiyle birlikte sürüm kontrolüme aktarıyorum.

Bu, bir şey saldırıya uğradıysa yama dosyalarını arayarak görebildiğim anlamına gelir.

Buna ek olarak, site için geliştirici belgelerine de bir liste ekledim (gerçekten kaçınılmaz bir şekilde unutduğunuzda sitede ve kendiniz için çalışabilecek başkalarının uğruna geliştirici belgelerine sahip olmalısınız).

Bu hack belgelerinde, her hack'i hack'in ne yaptığı ve nedenleri, modülleri / dosyaları etkiledi, hack kodunu içeren yama dosyasının adı ve varsa ilgili drupal.org sorununa bir bağlantı (neredeyse her zaman benim durumumda var).

O zaman siz ve gelecekte başka kim çalışıyorsa, korsanların tam bir listesine sahipsiniz ve yanlışlıkla bir güncellemeyle bir şeyleri kırmaktan endişelenmenize gerek yoktur.

Sonra güncelleme işlemi için kesmek listemi kontrol ediyorum ve güncellediğim tüm modüllerde yama dosyalarını hızlıca inceliyorum. Bir saldırı varsa ve bir drupal.org sorunu varsa, en son sürümde düzeltme ekinin bulunup bulunmadığını görmek için sorunu kontrol ediyorum, bu durumda hack'i güncellemeyle patlatıp hack listemden kaldırıyorum ( drupal.org taahhüt mesajlarına bakarak, taahhüt edilen şeyin kullandığınız yamanın sürümü ile aynı olduğunu veya en azından işlevsel olarak aynı olduğunu unutmayın).

Yama yapılmadıysa, tek yapmam gereken modülleri güncellemek ve yamaları yeniden uygulamak. Birçok durumda yamalar yine de temiz bir şekilde uygulanır ve işlem kolaydır, ancak bazen yamaları yeni sürüm için yeniden kaydetmeniz ve ardından yamanın yeni sürümünü yerel havuzunuza taahhüt etmeniz gerekir. varsa drupal.org sorunu).

Bir modülün temel işlevleriyle (veya yalnızca drupal.org modülünün üzerine uzanan özel modüllerle) etkileşime giren daha önemli yamalar veya yamalar varsa, yapmak istediğim başka bir şey, güncellenen modülün sürüm notlarını ( bu, geçerli sürümünüzle güncellemekte olduğunuz sürüm arasındaki tüm sürüm anlamına gelir) ve kodunuzu kırabilecek hiçbir şey olmadığından emin olun. Not: Pek çok modül koruyucusu bugünlerde tam sürüm notları vermekle iyidir, ancak yine de çöp sürüm notları yapan çok şey vardır. Bu durumda bazı durumlarda geçerli sürümümden bu yana tüm taahhüt mesajlarını inceliyorum (bu genellikle sadece başka bir modülle derinden etkileşen karmaşık kodlara sahip olduğum durumlarda). Not:

Ardından, güncelledikten sonra (sitenin geliştirme kopyasında) iyice test edin. Sonunda birkaç hata geçtikten sonra ne anlama geldiğini öğreneceksiniz.

Ardından, yeterince test edildiğinde, canlı siteyi yükseltin veya yerel güncellemelerinizi veya dağıtım işleminiz ne olursa olsun yükseltin.

Daha kolay olsa bile herkesin bunu yapmadığını söylemesinin nedeni: Çoğu insanın benim özetlediğim gibi bir sistemi olmadığı için, güncelleme yapma zamanı geldiğinde veya site çalışmak için başka birine teslim edildiğinde Bu, bir kabus haline gelir ve çok fazla zaman (bazen çok büyük bir zaman), hataları çözmek ve kesmek izlemek ve neden orada olduklarını araştırmak için harcanmalıdır.

Eğer böyle bir siteyi devralmışsanız, tam olarak anlayacaksınız :)

Drupal web sitelerini kurarak ve oluşturarak geçimini sağlıyorsanız, onları güncel tutmak gerekir. Sitelerinizin çoğu korkunç bir şekilde eskiyse, o zaman profesyonel değilsiniz.