Firmware güncelleme için Amazon S3

[taydin]

Bir ürün ailesi için, çalıştığımız partner firmanın önerisi üzerinde firmware günelleme imajlarını Amazon'un S3 servisine yükledik. Yıllarca da sorunsuz kullandık. Ta ki birkaç hafta öncesine kadar. Amazon'dan bizim patrona eposta gelmiş, S3 servisimizde TLS protokolünün (https ile beraber kullanılan bir prokol) eski sürümlerini desteklememe kararı aldıklarını belirtmişler. Bir de not düşmüşler, sunucularda ŞU ANDA TLS 1.2 altındaki sürümlerin desteğini kaldırmaya başladık, elinizi çabuk tutun, sizin bölge etkilenmeden yeni protokole geçin diye.

Bu sistemin gömülü linux işletim sistemini ben hazırlamıştım. Baya eski sürüm. Girip kontrol ettim. curl programı ile TLS 1.2 kullanarak S3 e erişebiliyorum. Sıkıntı yok deyip bıraktım. Ama bizim partner firmanın kart üzerinde çalışan yazılımı meğer TLS 1.0 kullanıyormuş. Birden sahada yazılım güncelleme çalışmamaya başladı. Tabi klasik paslaşma başladı, onlar "sorun linux'tan kaynaklanıyor" diyor, ben "sorun uygulamadan kaynakanıyor" diyorum, öyle gidiyor.

Bir yandan da bir geçici çözüm araştırıyorum. Amazon S3 bucket'lerini başka bir sunucuya "redirect" yapmayı deniyorum, redirect sadece http için çalışıyor, https için çalışmıyor. Önüne amazon proxy server koymayı deniyorum (Amazon Cloudfront), bu sefer de proxy yeni URL üzerinden erişmek gerekiyor. Uygulama gene güncellenmesi gerekiyor.

Nasıl çözeceğiz şu anda belli değil, ama şimdi geriye bakınca şunu anlıyorum: Kesinlikle böyle standart dışı servisler ile çalışmamak lazım. Adamlar ne zaman kafalarına eserse birşeyleri değiştiriyorlar, sonra da sen uğraşıp dur. Keşke bir kiralık sunucuya, veya basit bir VPS e koysaydık firmware image larını. O zaman sunucu standart https sunucu olacaktı, ve biz birşeyi değiştirmedikte HİÇBİR ŞEY değişmeyecekti. VPS'i sağlayan firmadan bıkarsak da istediğimiz zaman başka bir firmaya geçebilecektik. Eğer Amazon S3 veya herhanbi bir başka Amazon servisi kullanacaksanız, her an herşeyi değiştirebilecekleri gerçeğini kesinlikle baştan hesap etmek lazım.

 

[Ahmet]

Bir ürün ailesi için, çalıştığımız partner firmanın önerisi üzerinde firmware günelleme imajlarını Amazon'un S3 servisine yükledik. Yıllarca da sorunsuz kullandık. Ta ki birkaç hafta öncesine kadar. Amazon'dan bizim patrona eposta gelmiş, S3 servisimizde TLS protokolünün (https ile beraber kullanılan bir prokol) eski sürümlerini desteklememe kararı aldıklarını belirtmişler. Bir de not düşmüşler, sunucularda ŞU ANDA TLS 1.2 altındaki sürümlerin desteğini kaldırmaya başladık, elinizi çabuk tutun, sizin bölge etkilenmeden yeni protokole geçin diye.

Bu sistemin gömülü linux işletim sistemini ben hazırlamıştım. Baya eski sürüm. Girip kontrol ettim. curl programı ile TLS 1.2 kullanarak S3 e erişebiliyorum. Sıkıntı yok deyip bıraktım. Ama bizim partner firmanın kart üzerinde çalışan yazılımı meğer TLS 1.0 kullanıyormuş. Birden sahada yazılım güncelleme çalışmamaya başladı. Tabi klasik paslaşma başladı, onlar "sorun linux'tan kaynaklanıyor" diyor, ben "sorun uygulamadan kaynakanıyor" diyorum, öyle gidiyor.

Bir yandan da bir geçici çözüm araştırıyorum. Amazon S3 bucket'lerini başka bir sunucuya "redirect" yapmayı deniyorum, redirect sadece http için çalışıyor, https için çalışmıyor. Önüne amazon proxy server koymayı deniyorum (Amazon Cloudfront), bu sefer de proxy yeni URL üzerinden erişmek gerekiyor. Uygulama gene güncellenmesi gerekiyor.

Nasıl çözeceğiz şu anda belli değil, ama şimdi geriye bakınca şunu anlıyorum: Kesinlikle böyle standart dışı servisler ile çalışmamak lazım. Adamlar ne zaman kafalarına eserse birşeyleri değiştiriyorlar, sonra da sen uğraşıp dur. Keşke bir kiralık sunucuya, veya basit bir VPS e koysaydık firmware image larını. O zaman sunucu standart https sunucu olacaktı, ve biz birşeyi değiştirmedikte HİÇBİR ŞEY değişmeyecekti. VPS'i sağlayan firmadan bıkarsak da istediğimiz zaman başka bir firmaya geçebilecektik. Eğer Amazon S3 veya herhanbi bir başka Amazon servisi kullanacaksanız, her an herşeyi değiştirebilecekleri gerçeğini kesinlikle baştan hesap etmek lazım.

bu kadar sık yazılım güncellemesi neden gerekiyor?
yeni özellik eklenmesi için mi? yoksa ortaya çıkabilecek bug'lar yüzünden mi.
Ağ üzerinden yapılan yazılım güncellemesi tamamen şans işi değil mi güncelleme yarıdayken elektrik kesilir veya mcu birşeyi kabul etmezsse dönüşü nasıl oluyor bu işin.

 

[taydin]

Karmaşık sistemlerde yazılım güncellemesi özelliğinin mutlaka olması gerekiyor, çünkü ne kadar iyi test etsen de, sistemi onbinlerce kişi kullanınca hiç öngörülemeyen buglar çıkıyor. Bir de yeni özelliklerin eklenmesi de gerekiyor. Mesela yeni bir müzik servisi çıkıyor, müşteriler onun için de destek eklenmesini istiyor. Bu ürün çıktığından beri tahminen 5 tane güncelleme çıkmıştır. Daha fazla güncelleme olan ürünler de var.

 

[taydin]

Ağ üzerinden yapılan yazılım güncellemesi tamamen şans işi değil mi güncelleme yarıdayken elektrik kesilir veya mcu birşeyi kabul etmezsse dönüşü nasıl oluyor bu işin.

Ağ üzerinde veri gönderimi, SPI, I2C gibi değil. Ağda 7 tabaka var ve bu tabakaların en altındaki (phsical layer) SPI ve I2C gibi hardware sinyallerle işliyor. Diğer üst tabakalar, hata kontrolü, kaçan mesajların tekrarı, yanlış sırada gelen mesajların diziliminin düzeltilmesi, mesaj sınırlarının belirlenmesi ve oturum başlatma/durdurma üzerine kurulu. firmware gücelleme image, TCP/IP protokolü ile indiriliyor ve tek başına bu bile verinin hatasız geleceğini garanti ediyor. Ama ekstra güvenlik anlamıda inen dosyanın CRC kontrolü de yapılıyor. Bunun dışında işletim sisteminin bulunduğu partition iki tane, yani yedekli. Güncelleme, o anda aktif olmayan partition üzerinden yapılıyor. Eğer programlama başarılı olursa da boot loader'a bildiriliyor artık bu yeni partition üzerinden sistemi başlat diye. Yani hardware arızası çıkmadıkça, hiçbir şekilde firmware bozulması sözkonusu olmuyor.

 

[czorgormez]

bunu ben de düşünüyorum. sistem güncellemeleri kesinlikle bana ait bir domain üzerinden dağıtılmalı. ileride ne olursa olsun cihazlar uyanıp güncelleme baktığında benim sunucuma ulaşabilmeli.

 

[Endorfin35+]

Hergün birşeylerin güncellenmesinden gına geldi artık...

 

[Ahmet]

Ağ üzerinde veri gönderimi, SPI, I2C gibi değil. Ağda 7 tabaka var ve bu tabakaların en altındaki (phsical layer) SPI ve I2C gibi hardware sinyallerle işliyor. Diğer üst tabakalar, hata kontrolü, kaçan mesajların tekrarı, yanlış sırada gelen mesajların diziliminin düzeltilmesi, mesaj sınırlarının belirlenmesi ve oturum başlatma/durdurma üzerine kurulu. firmware gücelleme image, TCP/IP protokolü ile indiriliyor ve tek başına bu bile verinin hatasız geleceğini garanti ediyor. Ama ekstra güvenlik anlamıda inen dosyanın CRC kontrolü de yapılıyor. Bunun dışında işletim sisteminin bulunduğu partition iki tane, yani yedekli. Güncelleme, o anda aktif olmayan partition üzerinden yapılıyor. Eğer programlama başarılı olursa da boot loader'a bildiriliyor artık bu yeni partition üzerinden sistemi başlat diye. Yani hardware arızası çıkmadıkça, hiçbir şekilde firmware bozulması sözkonusu olmuyor.

peki müşteri cihaza İnternet erişimi olmadan kullanmaya devam ederse bu güncelleme nasıl mümkün oluyor başka bir platformu bulunuyor mu bu güncellemenin

 

[taydin]

peki müşteri cihaza İnternet erişimi olmadan kullanmaya devam ederse bu güncelleme nasıl mümkün oluyor başka bir platformu bulunuyor mu bu güncellemenin

İnternet erişimi olmayan cihazlarda USB üzerinden güncelleme yapıyoruz. Bir tane Subwoofer var bu şekilde. Onun dışındaki bürün ürünlerde ethernet arabirimi var ve bunlarda ya cihaz doğrudan gidiyor internetten alıyor güncellemeyi, veya ADSL modemlerdeki gibi lokal ağ üzerinden alıyor.

 

[Sercan]

 

[ozkarah]

FW güncelleme ya da sunucuya erişme gibi işler için endpoint adresini doğrudan kullanmamak en iyisi.
Bir dinamik link ya da API gateway üzerinden ulaşmak bu tür durumlarda hayat kurtarabiliyor.

 

[taydin]

FW güncelleme ya da sunucuya erişme gibi işler için endpoint adresini doğrudan kullanmamak en iyisi.
Bir dinamik link ya da API gateway üzerinden ulaşmak bu tür durumlarda hayat kurtarabiliyor.

Zaten doğrudan IP adres kullanmıyoruz. O çok yanlış birşey olurdu tabiki. Amazon "bucket" lerin bir URL'i oluyor. Mesela

https://mybucket.s3.amazonaws.com

Ayrıca amazon'dan ayrılacağım dediğin zaman bu URL'i komple redirect edebiliyorsun, ama redirect sadece http için çalışıyor. https için çalışmıyor.

dinamik link dediğin nedir?

 

[ozkarah]

IP adres olması ya da DNS adı olması çok farketmiyor.

Dinamik link dediğim aslında bir redirect (forward) çözümü kullanmak. Bunun için siz basit bir web hizmeti geliştirip sabit bir DNS adında host edebilirsiniz. Ya da hedef adresi istediğiniz zaman düzenlemeye izin veren bir URL kısaltma servisi kullanabilirsiniz (onelink.to, short.io .. gibi). Asıl sunucu hizmetlerine ait tüm gerekli URL kayıtları kendi hizmetinizin içerisinde ya da URL kısaltıcıda tanımlanır ve gömülü kodda bunlar bulunur. Bu tür işler için çeşitli açık kaynak projeler de var: https://github.com/anitejb/boomerang

Ya da her zaman ulaşılabileceğine emin olduğunuz bir web sayfası adresinde key-value şeklinde oluşturulacak bir dosya içerisinde tüm gerekli URL verileri olur. Dilediğiniz zaman sadece o içeriği düzenlersiniz.

API Gateway ise aslında API hizmetleri için tasarlanmış bir tür proxy. Farkı istemci tarafını yeniden yönlendirmek yerine sunucu tarafında asıl kaynağa ulaşılmasını sağlamak. Bununla birlikte yük dengeleme, çeşitli kurallara göre farklı adreslere yönlendirme, loglama gibi işleri de yapabiliyorsunuz. Çok az kaynak istediklerinden hep ayakta duracak herhangi bir (ya da iki) yerde barındırmak mümkün. Örneğin Apache APISIX gibi açık kaynak gateway çözümlerine bakabilirsiniz.

 

[taydin]

Dinamik link için bir URL kısaltıcı kullanınca da o servisin riskini almış oluyorsun. Aslında özel sistemlere gerek yok. Bir tek dosya indirilecek, standart HTTP GET geterli oluyor.

API olayının belki şöyle bir avantajı olabilir: Firmware güncelleme alırken, o sistemin seri numarası, MAC adresi falan kaydedilebilir istatistik amaçlı.

 

[ozkarah]

Aynen öyle. O yüzden tercih sırası API Gateway, kendi geliştireceğiniz ve güvendiğiniz bir yerde host edeceğiniz bir web sayfasında URLleri yönetmek (redirect kodları ya da konfigürasyon dosyası ile), URL shortener servisi kullanmak şeklinde olmalı. Kolaylaştıkça risk artıyor.

Bir başka seçenek de dinamik DNS (ya da kesinti süresi kritik değilse normal DNS de olur) hizmeti kullanmak ama DNS adından sonraki tüm URL hiyerarşisi aynı olmak zorunda olduğundan pratikte uygulamak biraz zor olabilir. Bu daha çok mirror yapmak için mantıklı.