röviddel az Y2K után viccelődtünk a ” next up, Y2038!”de akkoriban úgy érezte, egy örökkévalóság a jövőben, és valószínűleg valaki másnak a probléma. Most, hogy már félúton vagyunk, és már elértük azt a pontot, ahol az Y2038 problémák szoftverhibákat okozhatnak, jó lehetőség az Y2038 tervezésének megkezdésére. Például a szoftver, lehet, hogy már gondjai vannak munka 20 éves tanúsítvány élettartama vagy 20 éves jelzálog, illetve a frekvencia ezeket a problémákat csak fokozza, ahogy közeledik Y2038. Az Akamai-nál már stratégiailag célzott belső tervezést és tesztelést végzünk az Y2038-ra, és valószínűnek tűnik, hogy e munka hatóköre a következő 19 évben tovább fog növekedni, mivel ez a fontos erőfeszítés sürgősen növekszik.

Nagyon kevés volt a baj január 1-jén, 2000 nekünk (rövid néhány Javascript egy Akamai marketing oldal megjelenítése “19100”, mint az aktuális dátum!), de egy dolog, ami hiányzik, az az, hogy az este korlátozott globális hatása két tényezőnek köszönhető: 1) az elvégzett fejlett előkészítés mennyisége; 2) sok “Y2K probléma” valójában évekkel korábban történt, nem pedig maga a felborulás során. A Leap seconds bizonyos szempontból ijesztőbb, mint a dátumformátumú problémák, mivel nehezebb tesztelni őket, és sokkal kevesebb hatás történik előre. Fennáll annak a veszélye, hogy az Y2K hatásainak hiánya miatt a szervezetek és a technológusok alul felkészülhetnek az Y2038-ra. Az Y2K-nál nehezebb megmagyarázni az” Y2038 ” – ot is a laikusoknak, ami megnehezítheti a fejlett munka rangsorolását és összpontosítását. A beágyazott tárgyak internete (IoT) eszközök nagy száma, amelyek mindenütt jelen vannak a környezetünkben, szintén jelentősen megnöveli a valószínű kockázatot és a potenciális hatást az Y2038 esetében, mint az Y2K esetében.

az Y2038 tervezéssel kapcsolatos kezdeti tapasztalataink (amellett, hogy sokkot tapasztalunk az emberektől, amikor olyan aggodalmak merülnek fel, hogy az első hang 19 év múlva) az, hogy ebben a szakaszban inkrementális és fókuszált megközelítésre van szükség. Sokkal több érintettre és átfogó programokra biztosan szükség lesz néhány év múlva az úton. Ebben a kezdeti szakaszban néhány terület, amelyre összpontosítani kell: 1) a jövőbeli időkkel és dátumokkal foglalkozó szoftver; 2) on-the-wire üzenet és fájlformátumok; 3) hosszú élettartamú eszközök, valamint azok függőségei. Természetesen ahogy közelebb kerülünk, kritikus lesz a szélesebb rendszerkészletekre összpontosítani, ideértve annak biztosítását is, hogy biztonságosan tudják kezelni az Y2038 átmenetet.

A jövőbeli dátumokkal foglalkozó szoftver

talán a legfontosabb terület, amelyre kezdetben összpontosítani kell, olyan szoftver, amely a jövőben dátumokkal foglalkozik, például az X. 509 tanúsítványok kezelésére vagy pénzügyi tervezésre. Sok dátum – és időformátum-ábrázolás létezik, nem mindegyiknek lesz Y2038 problémája. Például az elmúlt évszázadok (jóval 1970 előtt) idejével foglalkozni kívánó szoftverek gyakran különböző dátum-és időábrázolásokat választottak. Az X. 509 tanúsítványok (például a HTTPS-hez használt) és a certificate authorities (CAS) eseteinek tesztelése során azonban számos szoftverproblémát találtunk a laborban, amelyek a tanúsítványokkal és a CAs-val kezdenek felmerülni y2038.

Az OpenSSL-nek különösen több időformátuma van, az ASN1_UTCTIME-nek y2049-ben van korlátozása (egy különálló probléma az Y2038-tól), ezért használja az ASN1_TIME funkciókat, amelyek kompatibilitást biztosítanak minden időtartományban. Konvertálása alkalommal ki a könyvtárból, mint OpenSSL ki a 32 bites time_t egy további terület valószínűleg problémák.

sok ilyen esetben a problémákat egyszerűen a 64 bites architektúrákhoz tartozó régi szoftverek portolásával és összeállításával lehetett megoldani (pl. egy 32 bites egész time_t-ről egy 64 bites time_t-re való áttéréshez). Más esetekben szélesebb körű változtatásokra volt szükség, különösen akkor, ha az idők matematikai egészekre kerülnek, vagy amikor az üzenethuzal-formátumok bekapcsolódnak, vagy amikor az értékeket adatbázisokban tárolják. A 20 éves CAs támogatásának tesztelése és rögzítése során egy dolog jelent meg, hogy a downstream függőségek is szerepet játszanak. Például, ha a jövőben egy 20 éves dátum bekerül egy naplózási rendszerbe vagy monitoringrendszerbe, és ha ezek viszont riasztórendszerekké, jelentési adatbázisokká vagy létesítési rendszerekké alakulnak, akkor ezeknek is javításokra van szükségük.

on-the-wire üzenet és fájlformátumok

mint már említettük, amikor 32 bites időbélyegek kerülnek üzenetek, Adatbázisok, vagy fájlformátumok a hatás jóval túlmutat egy adott rendszer. Ezek olyan külső függőségekkel rendelkező rendszerek is, ahol gyakran szükség van fejlettebb tervezésre, mivel az interakciók átlépik a rendszer határait. Az interoperábilis rendszerek ezen gyűjteményei esetében előfordulhat, hogy a változásokat egy meghatározott sorrendben kell kiadni, és a visszafelé való kompatibilitás gyakran szóba kerül. Továbbá, ha vannak formálisan vagy informálisan szabványosított protokollok, amelyek 32 bites epoch időbélyeg értékeket használnak az üzenetekben, bármilyen áttelepítés vagy javítás kiszámítható a szabvány rögzítésére. Mint olyan, ezek fontossá válnak aggódni, mint egy függőségi lánc, mint például:

1. protokoll / szabványok frissítése az Y2038 utáni időbélyegek támogatására.
2. támogatja a frissített szabványt a szoftverkönyvtárakban.
3. szerezd be a szoftvercsomagokba beépített könyvtárak új verzióját.
4. szerezzen szoftvercsomagokat az új szállítási termékben.

akkor, ha ezek mindegyike néhány évet vesz igénybe, és a szállítási terméknek hosszú élettartama van, akkor a hosszú átfutási idő itt már problémát jelenthet.

Eszközök hosszú telepített életünkben, a függőségek

egy Másik területre koncentrálni a korai készülékek hosszú telepítés életünkben. Mint már említettük, a külső függőségeken keresztül ezek az eszközök is fontosak. Előfordulhat, hogy a 32 bites hardverrel szállított beágyazott eszközök nem rendelkeznek könnyű javítással a “csak 64 bites time_t-hez” szoftverfrissítéssel, vagy ennek elfogadhatatlan teljesítményhatással járhat.

a csatlakoztatott autók és más IoT eszközök valószínűleg különös aggodalomra adnak okot, de biztos vagyok benne, hogy sok más hasonló típusú eszköz és alkalmazás is létezik. A jelenlegi tendenciák alapján például valószínű, hogy a ma eladott autók több mint 10% – a továbbra is Y2038-ban fog üzemelni, és a jármű életkorának és az úton lévő járművek számának növekedésével ez még magasabb lehet. Ha vesz egy pár év szállítási autók általában Y2038 megfelelő, a jelenlegi (növekvő) megoszlása gépjármű korosztály számára lehet, hogy a végén egy jelentős része autók a lehetőség, hogy komoly problémák tizenkilenc év. Ugyanez a minta valószínűleg más iparágakban is létezik, például a fogyasztói elektronikában (például az otthoni játékkonzolokban és az intelligens televíziókban), ahol az eszközöket előre telepített 20+ éves CA tanúsítványokkal szállíthatják.

a hosszú élettartamú eszközök átfogóbb tesztelést igényelhetnek mind az eszközről, mind annak függőségeiről, mint például annak tesztelése, hogy az operációs rendszer és a szoftver továbbra is megfelelően működik-e az Y2038 átmeneti pont előtt, alatt és után.

Boldog Új Évet!

az Y2038 probléma hasonló kategóriába tartozik, mint az IPv6: ez egy több évtizedes roll-out, hogy az általános esetben fontos, de még nem sürgős (per az Eisenhower mátrix). Ebből a szempontból, most van olyan jó idő, mint bármely kezdeni tervezés, triaging, tesztelés előtt válik sürgős (vagy túl késő). Először a jövőbeli dátumokkal, on-the-wire üzenettel és fájlformátumokkal foglalkozó szoftverekre, valamint a hosszú élettartamú eszközökre összpontosítson. Ezután használja a kezdeti fókusz tapasztalatait egy átfogóbb program felépítéséhez az elkövetkező években. Ettől függetlenül, meghatározott minimum bár kezdeni, ügyelve arra, hogy új szoftverek, rendszerek, előírások, valamint a termékeket, épület telepítése nem mutatod be Y2038 kérdések, valamint a zászló vonatkozik, amikor látod, hogy a 32 bites időbélyegek-hiszen-a-unix-korszak szereplő, új tervek.

Erik Nygren az Akamai Platformmérnöki szervezet munkatársa és főépítésze. Idén júniusban ünnepli 20. évfordulóját az Akamai.

Köszönjük, hogy több ember Akamai azok hozzájárulását ezt a cikket.

míg óvintézkedéseket tettek a dokumentum elkészítése során, Akamai Technologies, Inc. nem vállal felelősséget az itt található információk használatából eredő hibákért, mulasztásokért vagy károkért. Az itt szereplő információk előzetes értesítés nélkül megváltozhatnak. Az Akamai és az Akamai Wave logó bejegyzett védjegy vagy szolgáltatási védjegy az Egyesült Államokban (Reg. U. S. Pat. & Tm. Ki). Megjelent Január 10, 2019.