Popravek v desetih minutah, namestitev prihodnji teden: od lastnega zaganjalnika do Bootstrapperja

Petek, 15.40. Poročilo o zalogah, ki ga skladišče potrebuje v ponedeljek zjutraj, od zadnje različice napačno sešteva. Napako ste našli, popravili in preizkusili. Trajalo je deset minut. Nova datoteka ACCDE je pripravljena.

Pri uporabnikih je s tem še ni. Zunanji vzdrževalec, ki pri stranki skrbi za računalnike, namešča programe ob torkih, in ta torek je že zaseden. Popravek, ki je trajal deset minut, bo čakal teden dni, skladišče pa bo zaloge medtem preštevalo kar na roko.

Če vzdržujete aplikacijo v Accessu, ta petek poznate. Delo je opravljeno, njegova vrednost pa še ni prišla do ljudi, ki jo potrebujejo. Ta teden je izgubljen, čeprav ga ni nihče zapravil.

Zapis ima dva dela. Prvi opisuje, kako smo težavo videli in rešili aprila 2016. Drugi je dopisan oktobra 2026: kaj je iz tega prvega zaganjalnika nastalo in zakaj na koncu najtežje vprašanje ni bila hitrost.

Zapis je dolg, ker je bila pot dolga. Če vas zanima samo en del, skočite naravnost tja:

• 2016: kaj je bilo na voljo in zakaj smo napisali svoj zaganjalnik
• 2026: kaj je nastalo iz štirih odprtih vprašanj
• Kako preprečiti, da bi razdeljevanje postalo vstopna točka za napad
• Isti petek z Bootstrapperjem
• Bi ga napisali sami?

Kdo tu pravzaprav zavira? Nihče. Za razvijalca je stvar končana. Skladišče hoče samo poročilo, ki pravilno sešteva. Za skrbnika teden ni ovira, ampak previdnost: vsaka sprememba na računalnikih pri stranki je tveganje, in ko kaj ne deluje, pokličejo njega.

Prav imajo vsi trije. Ne ujemata se le dva ritma. Poslovna aplikacija se spreminja vsak teden, včasih vsak dan. Pot, po kateri programi pridejo na računalnike, pa je narejena za programe, ki se spremenijo enkrat ali dvakrat na leto.

Za aplikacije Access, ki jih uporablja več ljudi, Microsoft priporoča zbirko podatkov na strežniku in datoteko front-end, ki jo vsak računalnik dobi v svoji kopiji. Vsaka nova različica mora torej na vsak računalnik, datoteka front-end pa je odvisna tudi od stvari zunaj nje: od registriranih komponent COM, od gonilnikov ODBC in od zaupanja vrednega mesta, zapisanega za vsakega uporabnika in vsako različico Officea posebej. Office 2016 je na voljo od septembra 2015, na mnogih računalnikih pa še teče Office 2010. Kar je nastavljeno tam, za Access 2016 ne velja.

MSI in SCCM marsikaj rešita prav. Paket je sledljiv, zapisan v popisu in ga je mogoče čisto odstraniti; skrbniške pravice ostanejo pri tistih, ki zanje odgovarjajo. Configuration Manager od različice 1511 iz decembra 2015 dobiva mesečne posodobitve. Paket pa je narejen za namestitev izdelka. Aplikacija, ki se spreminja vsak teden, s tem postane paket na teden.

Prijavni skript in tabela različic, rešitvi, ki so si ju razvijalci Accessa izmislili sami, vsaka rešita del težave. Skript kopira samo ob prijavi in odneha, če je datoteka odprta. In odprta je vedno pri nekom: v vsakem podjetju je računovodkinja, ki aplikacije ne zapre že od torka, ker bi sicer morala znova nastaviti vse filtre. Tabela različic pa sili aplikacijo, da zamenja samo sebe, medtem ko teče. To je približno tako sproščeno kot menjava stola, na katerem ravno sedite.

ClickOnce, ki je del ogrodja .NET Framework 2.0 od leta 2005, ima skoraj natanko zamisel, ki jo iščemo: podpisana manifesta, namestitev za vsakega uporabnika brez skrbniških pravic, preverjanje ob zagonu, prejšnja različica pa ostane shranjena. Vendar ClickOnce namešča aplikacije .NET, za spremembe sistemske konfiguracije pa Microsoft napotuje na Windows Installer.

S seboj smo vzeli troje. Kar teče na računalniku, mora biti znano. Posodobitev sodi pred zagon aplikacije, ne vanjo. Izdaja in namestitev sta ločena koraka.

Iz tega je nastal naš zaganjalnik, majhen program med bližnjico na namizju in Accessom. Uporabnik, ki želi odpreti aplikacijo, zažene zaganjalnik, ne datoteke ACCDE. Access se ne zažene več sam.

Ob vsakem zagonu zaganjalnik prebere konfiguracijsko datoteko, ki je poleg njega. V njej so skupna mapa, lokalna mapa in datoteke aplikacije, vsaka s časovnim žigom in dejanjem: samo kopiranje ali registracija z regsvr32 oziroma regasm. Če je datoteka v skupni mapi novejša od zapisa v lokalni mapi, jo prekopira in registrira. Nato odpre lokalno kopijo. S parametrom /GUI odpre vmesnik, v katerem se ureja konfiguracija.

Mimo skrbnika to ne gre. Skrbnik določi, iz katere mape se dostavlja in kdo sme vanjo pisati, ter zaganjalnik razdeli enkrat. Založnik v to mapo odlaga preizkušene različice. Zaganjalnik v tem okviru opravi, kar se ponavlja ob vsakem zagonu.

Za naš petek to pomeni: ob 15.50 je popravek v skupni mapi, v ponedeljek skladišče že dela z njim. Na torek ni treba čakati, zalog ni treba šteti na roko.

Zaganjalnik teden skrajša na konec tedna. Na štiri vprašanja pa nima odgovora.

• Komponente potrebujejo skrbniške pravice. regsvr32 piše v del registra, ki je skupen vsem uporabnikom. Vsaka različica z novimi komponentami zato ostaja delo za skrbnika.
• Časovni žig ni dokaz izvora. Zaganjalnik prevzame, kar je v skupni mapi novejše. Mapi zaupamo, ker je v notranjem omrežju. Prav to predpostavko postavljata pod vprašaj John Kindervag z modelom Zero Trust pri Forresterju (2010) in Google z BeyondCorpom (2014).
• Prepis ni pot nazaj. Če je nova različica pokvarjena, vodi pot nazaj čez ročno kopiranje.
• Zaupanja vredno mesto ostaja ročno delo, s pravilnikom skupine ali ročno, za vsako različico Officea posebej.

Razdeljevanje je dokončano šele, ko zna ravnati tudi s ponesrečeno različico. Aprila 2016 tako daleč še nismo.

Od tu naprej stanje oktobra 2026.

Zaganjalnik iz prvega dela je bil pri strankah v uporabi do leta 2025, nazadnje vzdrževan leta 2021 v različici 1.1. Pri dveh velikih podjetjih nekateri njegovi deli tečejo še danes. Naslednika nismo dobili s krpanjem starega, ker so štiri vprašanja spremenila nalogo. Leta 2016 je šlo za to, da nova datoteka pravočasno pride do uporabnika. Danes gre za to, da je vsaka izdaja nadzorovana, preverljiva in obvladljiva tudi takrat, ko gre kaj narobe.

Iz tega sta nastala dva programa: Bootstrapper, zaganjalnik na vsakem računalniku, in Bootstrapper Manager, v katerem založnik opiše, kaj zaganjalnik namesti. Na štiri vprašanja in na tri, ki so se jim pridružila na poti, danes odgovarjata takole:

Zaganjalnik piše le v uporabnikove mape in pod HKEY_CURRENT_USER; povišanih pravic ne zahteva nikoli. Tudi gonilnike ODBC, vire podatkov in zasebno izvajalno okolje .NET namesti za uporabnika in šteje, katera aplikacija jih potrebuje. Kar zares zahteva skrbniške pravice, ostane pri skrbniku: gonilniki za ves sistem, okolje Access Runtime, registracije za ves računalnik. Če kaj od tega manjka, zaganjalnik to sporoči s kodo napake, za vsako kodo pa obstaja stran z vzrokom in rešitvijo.

Zaganjalnik ničesar več ne prepisuje. Vsaka različica dobi v uporabnikovem profilu svojo mapo, tista, ki teče, pa ostane nedotaknjena. Računovodkinja lahko staro kopijo torej mirno pusti odprto; novo dobi ob naslednjem zagonu. Za vsakega uporabnika je zapisano, katera datoteka in katera vrednost v registru je nameščena.

Če je izdaja pomanjkljiva, vodita nazaj dve poti. Uporabnik, ki mora takoj delati naprej, zažene prejšnjo različico iz okna z nastavitvami. Založnik pa prejšnjo izdajo znova objavi in pomanjkljivo izrecno umakne (/publish /withdraw). Ob naslednjem zagonu so vsi spet na prejšnji različici.

Leta 2016 je bil opis različice datoteka XML, urejena v vmesniku zaganjalnika. Danes je to projektna datoteka, založnik pa jo ureja v programu Bootstrapper Manager, aplikaciji Access, ki se namesti z Office SDK. Na posameznih straneh določi, katere datoteke gredo kam, katere bližnjice, vrednosti v registru, vrste datotek in pogoji sodijo zraven ter kaj se na koncu zažene.

• Preveri (Prüfen): projektno datoteko oceni zaganjalnik sam, po istih pravilih, po katerih bo pozneje delal pri uporabniku, in vas napoti na polje, v katerem težavo odpravite.
• Predogled (Vorschau) pokaže okno, ki ga uporabnik vidi med namestitvijo. Poskusni zagon (Probelauf) za vsako datoteko pokaže, kam bi bila nameščena, ne da bi karkoli spremenil.
• Ustvari MSI (MSI erstellen) izdela paket, s katerim skrbnik zaganjalnik in projektno datoteko enkrat uvede, s pravilnikom skupine, Intune ali Configuration Managerjem. Nov paket je potreben šele, ko se spremeni zaganjalnik ali projektna datoteka.
• Prevzemi (Übernehmen) iz konfiguracije zaganjalnika iz prvega dela naredi projektno datoteko. Povezave SQL in gesla namenoma izpusti: ne sodijo v datoteko, ki se kopira na vsak računalnik.

S tem smo odgovorili na štiri vprašanja. Na poti pa se je pojavilo peto, ki tehta več kot vsa štiri skupaj.

Petek, 15.50: popravek shranite v skupno mapo, v ponedeljek ga imajo vsi računalniki, ne da bi kdo mignil s prstom. Prav za to zaganjalnik obstaja. In prav zato je zanimiv tudi za druge: kdor mu podtakne napačno datoteko, z enim korakom doseže vse računalnike, napaka pa se razširi enako hitro kot popravek. Kako torej preprečiti, da bi orodje za hitro razdeljevanje samo postalo šibka točka?

Oktobra 2026 smo zaganjalnik zato preverili po katalogu CWE organizacije MITRE, skupnem seznamu znanih razredov programskih slabosti. Kar pišemo o starem zaganjalniku, temelji na njegovi ohranjeni kodi iz leta 2021.

Stari zaganjalnik je prevzel vse, kar je bilo v skupni mapi novejše. Novejše pa ne pomeni pristno: sodelavka doda nepreverjeno datoteko, program za sinhronizacijo pusti pol kopije, napadalec s pravico pisanja zamenja knjižnico. Danes ima vsaka izdaja seznam vseh datotek z velikostjo in vrednostjo SHA-256, podpisan s ključem za izdaje, ki ga ima založnik. Zaganjalnik vsako datoteko preveri pred kopiranjem in še enkrat na kopiji, preden jo karkoli odpre. Če se kaj ne ujema, ničesar ne namesti in zažene dosedanjo različico.

Veljaven podpis potem pove dvoje: datoteke so od tistega, ki ima ključ za izdaje (avtentičnost), in od takrat niso bile spremenjene (integriteta). Ne pove, ali je smel ta založnik izdajo sploh razdeliti. To odloči skrbnik, ko določi, kateri ključ je vpisan v projektni datoteki in kdo sme pisati v izvorno mapo (avtorizacija). Ne pove, ali poročilo pravilno sešteva (pravilnost delovanja); za to so preizkus, poskusni zagon in pot nazaj. In ne pove ničesar o varnosti kode same aplikacije; zanjo ostaja odgovoren njen založnik.

Zraven sodita dve meji. Brez ključa za preverjanje izvora zaganjalnik preveri le, ali se datoteke ujemajo s seznamom, ne pa, kdo jih je zapisal; brez seznama namesti, kar je v izdaji, tako kot leta 2016. Preverjanje projektne datoteke na to opozori, ne prepove pa, da obstoječe namestitve tečejo naprej. In s ključem lahko podpisuje vsak program, ki teče pod založnikovim računom. Ta račun naj zato služi samo objavljanju.

Pregled je v naši lastni različici 3.2 našel dve slabosti. Obe odpravlja 3.3.0.

Knjižnice iz napačne mape. Odkar je ključek USB predvideno mesto zagona, je stara navada sistema Windows postala tveganje: programi knjižnice najprej iščejo v lastni mapi. Do različice 3.2 je tako delal tudi zaganjalnik. Na ključku ali v skupni rabi, kamor lahko pišejo drugi, bi se primerno poimenovana knjižnica DLL, postavljena tja, naložila v uporabnikov proces. Različica 3.3.0 knjižnice sistema Windows nalaga samo še iz sistemske mape; prevzemni preizkus vsake različice poleg zaganjalnika postavi prave knjižnice sistema Windows in prešteje, ali se katera naloži.

Ime mape, ki ni ime. Iz oznake izdelka nastanejo imena map pri uporabniku. Do različice 3.2 je zaganjalnik sprejel tudi . in .., ki bi pomenila njegovo lastno mapo WKL ali profil nad njo. Od različice 3.3.0 oznaka izdelka sledi strogemu pravilu o dovoljenih znakih.

Obe je našel naš lastni pregled. Tak vrstni red je prijetnejši.

• Nekdo staro različico z znano luknjo vrne v skupno rabo. Podpisana je vendar. S ključem za preverjanje izvora zaganjalnik od različice 2.2.4 nikoli ne namesti nižje različice od najvišje, ki jo je uporabnik kdaj imel, razen če jo imenuje podpisan umik. Meja: nov uporabnik ali nov računalnik starejšo podpisano izdajo namesti.
• regsvr32 za registracijo izvede kodo iz knjižnice DLL, in to na vsakem računalniku. Danes registracija pride kot podatki (registration.json) pod HKEY_CURRENT_USER, programi pa se zaganjajo s fiksno potjo, brez lupine in brez iskanja po PATH. Meja: dejanja, na primer namestitveni program gonilnika, še vedno prihajajo neposredno iz izvorne mape, podpis pa jih ne zajema.
• Konfiguracija piše, kamor hoče. Danes so cilji samo v uporabnikovih mapah, poti s seznama izdaje pa ne vodijo iz mape različice. Meja: sidro zaupanja je mapa zaganjalnika s projektno datoteko; s paketom MSI sodi v Program Files, kamor uporabniki ne pišejo.
• Geslo je v konfiguraciji berljivo, pri starem zaganjalniku le kodirano v base64. Danes preverjanje zavrne vnose INI, ki so videti kot gesla, dnevnik ne vsebuje vrednosti povezav, prevzem pa gesla izpusti. Meja: za to, kar shrani aplikacija sama, odgovarja njen založnik.
• Zaupanja vredno mesto je preširoko. Danes se vpiše samo uporabnikova mapa aplikacije; če pravilnik to prepoveduje, se zaganjalnik ne zažene, namesto da bi pravilnik obšel. Meja: takrat odloči skrbnik.
• Prekinitev pusti stare in nove datoteke pomešane. Danes vsaka namestitev teče kot transakcija z dnevnikom; po izpadu elektrike jo zaganjalnik razveljavi ob naslednjem zagonu. Meja: dva zaganjalnika istega uporabnika, ki nameščata v istem trenutku, se ne uskladita.
• Izdaja ni dosegljiva ali je ni mogoče preveriti. Danes se zažene zadnja delujoča različica, vsak primer pa ima svojo kodo. Meja: uporabnik ne vidi obvestila, pokažeta ga le dnevnik in diagnostika.

Tako ali podobno se zgodi povsod: v petek ob 15.50 je različica 3.2.1 podpisana in objavljena. V soboto sodelavka v izvorno mapo neposredno postavi popravljeno predlogo poročila, ne da bi izdajo znova objavila. Dobronamerno, hitro, nepodpisano.

Ponedeljek, 7.30: datoteka se ne ujema s podpisanim seznamom. Zaganjalnik ničesar ne namesti, zažene nameščeno različico 3.2.0 in v dnevnik zapiše kodo 51. Nihče ne dela z mešanico dveh različic, a tudi nihče s petkovim popravkom. Skrbnik aplikacije vidi kodo v diagnostiki, založnik preveri datoteko in izdajo znova objavi.

Sreda: 3.2.1 teče povsod, podpisana in nespremenjena, in v redko uporabljenem poročilu napačno sešteva. Te napake ne prepozna noben podpis, saj je datoteka natanko tista, ki je bila objavljena. Kogar to zadeva, zažene 3.2.0 iz okna z nastavitvami; založnik 3.2.0 znova shrani v izvorno mapo in 3.2.1 umakne z /publish /withdraw 3.2.1. Ali se vrnemo, odloči človek. Zaganjalnik poskrbi, da je pot nazaj varna.

Razmejitev pristojnosti iz leta 2016 velja naprej, danes pa je tudi del zaščite: vsak del sme manj. Bootstrapper Manager nima lastnih pravil, o veljavnosti projektne datoteke odloči zaganjalnik. Založnik ima ključ za izdaje, kateri ključ velja, pa piše v projektni datoteki, ki jo uvede skrbnik. Ukraden ključ brez pravice pisanja v izvorno mapo je zato enako malo vreden kot pravica pisanja brez ključa; izjema so dejanja.

Takole je danes videti pot izdaje, od priprave do zagona ali vrnitve:

Zato jedro Bootstrapperja ni kopiranje datotek. Kopirati je znal že zaganjalnik iz leta 2016. Jedro je nadzorovan življenjski cikel izdaje, v katerem so izvor, pravice, napake in pot nazaj od začetka del arhitekture.

Nazaj k skladišču in njegovemu poročilu, tokrat z Bootstrapperjem. Recimo, da vašo aplikacijo Access uporablja 40 ljudi, nove izdaje pripravite večkrat na mesec, za računalnike pa skrbi zunanji vzdrževalec.

Enkrat, pred prvo izdajo. V programu Bootstrapper Manager ustvarite projekt, vnesete izvorno mapo, datoteke in cilj zagona, ga preverite, opravite poskusni zagon in izdelate paket MSI. Ključ za izdaje ustvarite enkrat in njegov javni del vpišete v projekt. Vzdrževalec paket uvede ob enem od svojih torkov in določi, kdo sme pisati v izvorno mapo. Pozneje torek potrebujete le še za nov zaganjalnik ali novo projektno datoteko, ne za izdajo.

Petek, 15.40. Popravek je gotov. Izdajo shranite v izvorno mapo in jo podpišete z /publish. Ob 15.50 je objavljena: brez zahtevka, brez novega paketa in brez čakanja na torek.

Ponedeljek, 7.30. Ko uporabnik odpre aplikacijo, za trenutek vidi okno zaganjalnika, medtem ko se nova različica namešča v svojo mapo. Nato se aplikacija odpre s pravilnim poročilom, in zalog ni treba šteti na roko. Računovodkinja ima staro kopijo še vedno odprto in s tem ne moti nikogar. Če kdo dela od doma brez povezave do skupne rabe, se zažene nameščena različica, izdajo pa dobi ob naslednjem zagonu s povezavo.

To vidijo vaši uporabniki ob prvem zagonu nove različice, nato se odpre aplikacija. Predogled iz programa Bootstrapper Manager z nemškimi vzorčnimi podatki.

Četrtek, telefon: »Pri meni se aplikacija ne odpre.« Namesto obiska skrbnik aplikacije skupaj z uporabnikom odpre okno z nastavitvami (/settings). Tam piše, ali je aplikacijo mogoče zagnati in katere različice so nameščene. Koda napake vodi na stran z vzrokom in rešitvijo. Če manjka kaj, kar sme zaganjalnik namestiti sam, to dopolni /repair. Če manjka kaj, kar zahteva skrbniške pravice, na primer gonilnik ODBC za ves sistem, koda pove, kaj mora zagotoviti vzdrževalec.

Napisano, objavljeno, pri uporabniku: med prvim in tretjim stanjem ni več tedna ročnega dela, ampak naslednji zagon. Vzdrževalec pri tem ni izgubil nadzora. Še vedno določa, iz katere mape se namešča, kdo sme vanjo pisati in kateri ključ velja. Njegov torek pa ostane za delo, ki ga res potrebuje. Zaganjalnik vašo aplikacijo namešča, ne gradi je; zgradite jo na primer z Office SDK. Kaj pričakuje od vaših računalnikov, je natančno opisano v dokumentaciji.

Prvi zaganjalnik gotovo: bil je majhen program, kakršnega napiše vsak izkušen razvijalec v Accessu. Zahtevno je vse, kar je prišlo pozneje: registracija za vsakega uporabnika v pravi bitni različici, transakcija z vrnitvijo tudi po izpadu elektrike, štetje skupnih komponent, podpisi z zaščito pred vračanjem starih izdaj, kode napak s svojo stranjo pomoči, paket MSI za skrbnika in varnostni pregled, ki kaj najde tudi v lastni različici. Ta seznam je tisto, kar je deset let uporabe naredilo iz majhnega programa, in vsako točko na njem je treba vzdrževati.

Vašo aplikacijo Access uporablja nekaj deset ali nekaj sto ljudi, izdaje pripravljate večkrat na mesec, vsaka nadgradnja pa pomeni usklajevanje, kopiranje in preverjanje na posameznih računalnikih? Kaj bi vam pomenilo, če bi skrbnik okvir postavil enkrat, vsako naslednjo objavljeno izdajo pa bi uporabniki dobili ob naslednjem zagonu, s preverljivim izvorom in potjo nazaj?

Če imate podobno okolje, lahko skupaj preverimo, ali Bootstrapper ustreza, katere predpogoje potrebujejo vaši računalniki in kolikšen bi bil obseg uvedbe.

Bootstrapper: funkcije, zahteve in dogovor za pogovor · Raje se kar pogovorimo

Za nadaljnje branje: Aplikacija v Accessu ni za odpis pokaže, kaj se na posameznih računalnikih zalomi v ponedeljek po izdaji. Zgodba o Office SDK pove, od kod prihajajo izdaje, ki jih zaganjalnik namešča.