serial szam (vagy valami mas) program vedelemhez Linuxon

 ( sj | 2017. január 29., vasárnap - 16:31 )

Adott egy linuxos alkalmazas, amit egy (kulfoldi) ceg telepitene az altala forgalmazott dobozokra. Arra gondoltam, hogy mi lenne, ha ez a ceg minden telepites utan (=dobozonkent) jattolna a programert? Ehhez azt kene tudni, hogy hany dobozra telepiti ez a ceg a programot, ill. azt megoldani, hogy az egyszer generalt serial szam (vagy valami mas) csak 1 dobozon mukodjon.

Neheziteskeppen a program egyebkent docker kontenerben fut a dobozokon (ha ez jelent valamit, akkor sy**logy modellekrol van szo), igy az IP-cimhez / MAC cimhez kotes nem feltetlen jarhato ut.

Meg neheziteskeppen a forgalmazott doboz nem feltetlenul lat netet (lehet, hogy bizonyos helyen kilat a netre, de az is lehet, hogy masik helyen meg el lesz vagva a nettol). De lehet egy megoldas arra az esetre is, hogy a dobozok kilatnak a netre.

Hogyan oldanad meg a feladatot?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Egy jó szerződéssel.

+1, nem kell mindenre technológiai megoldást keresni, mert van, amire nincs.

Egyébként ha kényszeríthető, hogy legalább egyszer legyenek kinn a neten az eszközök, akkor pl. a Flexera-tól vehetsz kulcsrakész megoldást erre (MatLab, ArcGIS bizotsan ezt használja, ha jól tippelek az SPSS is).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem biztos hogy hard-limitre van szükséged, mert úgyis minden másolásvédelmet fel lehet törni.

Egy jó szerződés mellé elég ha ki tudod kötni hogy a programod valamilyen egyedi azonosítót hazaküldhet neked. Nem is kell minden eszköznek internetre csatlakozni, ha jellemzően interneten használják őket a vásárlók. Neked bőven elég a körülbelüli statisztikád, hogy a gyártó ne akarjon neked a valósnál kisebb számot bevallani.

-Egy ügyfél tipikusan egy dobozt vásárol vagy inkább többet is?
-Hogyan lesznek a szoftverfrissítések megoldva?
-Hogyan lesz a support?

Üdv,
Marci

-Egy ügyfél tipikusan egy dobozt vásárol vagy inkább többet is?

tipikusan 1-et. Tobb modell is van a dobozbol, igy nagyobb ugyfel nagyobb modellt vesz

-Hogyan lesznek a szoftverfrissítések megoldva?

a docker hub-ra toltom fel az ujabb image-et, onnan frissithet az ugyfel

-Hogyan lesz a support?

ez meg nincs kidolgozva, de 1. korben azt mondanam, hogy a doboz forgalmazo ceg megoldja. Legfeljebb majd kerdeznek tolem, ha valami nem vilagos.

Egyik lehetséges megoldás, hogy regisztrációhoz kötöd a frissebb verziók letöltését, ahol a Felhasználó a szoftver sorozatszámával 1:1 regisztrált e-mail-címmel kap hozzáférést. Az sem tűnik lehetetlennek, hogy minden vásárló számára egyedi docker image-et generálsz, amiben az ő licence van.

"tipikusan 1-et. Tobb modell is van a dobozbol, igy nagyobb ugyfel nagyobb modellt vesz" - kicsit fura nekem, hogy bármekkora dobozra ugyanakkora a Rád eső licencköltség, de nyilván nem ismerem a részleteket.

Üdv,
Marci

minden vásárló számára egyedi docker image-et generálsz, amiben az ő licence van.

maceras, es 2 gond is van vele: a docker hub-osok kinyirnak, ha feltolok hozzajuk 999 image-et (amit szorozz is meg a release-ek szamaval), ill. mi akadalyozza meg a forgalmazot, hogy ugyfel1 licencet ugyfel2...ugyfel999-nel is hasznalja?

kicsit fura nekem, hogy bármekkora dobozra ugyanakkora a Rád eső licencköltség, de nyilván nem ismerem a részleteket.

itt meg nem tartunk. Egyelore sikerult osszerakni egy PoC telepitest. Meg par technikai dolgot tisztazni kell, es addig is agyalok ezeken a kerdeseken.

Semmi gond nincs a sok image-el, ha csak az utolsó layer különböző. Vagy hostolj te egy registryt.

----------------------
while (!sleep) sheep++;

"docker hub-osok kinyirnak" - nem is mondtam, hogy docker hub-ra tedd. Simán el tudok képzelni egy olyan környezetet, amiben a regisztrált felhasználó, amikor le akar tölteni, akkor gyártódik le neki az image és kap egy letöltési linket rá, ami egy darabig érvényes.

"mi akadalyozza meg a forgalmazot, hogy ugyfel1 licencet ugyfel2...ugyfel999-nel is hasznalja" - az, hogy már ugyfel2 is reklamálni fog Nála, hogy a sorozatszámmal nem tud Nálad regisztrálni a frissítésekért, mert hibaüzenetet kap, hogy már regisztrálva van a kulcs.

Üdv,
Marci

hmm, akar mukodhet is a dolog. Meglatjuk, milyen megallapodast sikerul majd a forgalmazoval teto ala hozni. Thx.

Szívesen.

Üdv,
Marci

Amúgy működhet közös docker image-dzsel és docker hub-bal is a dolog, ha egy az adott Felhasználóhoz és licenckulcshoz kötött aktivációs kódot generálsz le minden felhasználónak, mely kódot -e-vel egy környezeti változóban át kell adni a docker image-nek. Aztán, amikor a programod a konfigurációt felolvassa, ellenőrzi, passzol-e az aktivációs kód (pl, ahogy lent javasolták, az engedélyezett maildomainek listáját ellenőrzi). Ha nem, nem indul.

Üdv,
Marci

Ennél akkor már elegánsabb egy licence fájlt kérni, amit megadott helyre volumeként kell becsatolni. A fájl tartalma az engedélyezett domainek RSA-val aláírt listája. Így nem kényszeríted internetre a felhasználókat egyetlen pillanatra sem, és - amíg a privát kulcsot őrzöd - biztosan nem lesz keygen sem a programodhoz.

Környezeti változó vagy licencfile: nem ugyanaz?

Üdv,
Marci

Egy aktivációs kódot általában kényelmes begépelhetőségre méreteznek, ezért rövid ahhoz, hogy PKI adatot tartalmazzon. Ettől eltekintve persze ugyanaz.

>> nem lesz keygen sem a programodhoz

csak patch

Ez így van, de egy 3. féltől származó patch használata sokkal kellemetlenebb, és jóval magasabb biztonsági kockázatot is jelent, mint "véletlenül" szürke forrásból licence fájlt szerezni. Nem utolsó sorban a licence fájl birtokában egyértelműen megállapítható a jogosultság, a vásárlást igazoló papírok nézegetése nélkül.

>> a licence fájl birtokában egyértelműen megállapítható a jogosultság

ha én lennék a dzsunka bt, amelyik sj dobozokat terít, felülpatchelném a pubkeyt, és csinálnék magamnak licgent

Hivatalos szerződéses viszonteladójaként valaminek, akkor sem mernék licensz szerződést szegni, ha patchelnem sem kell hozzá. Amúgy meg oda az update, mert SJ szerverén nem fogod megpatchelni a pubkeyt :-)

.

Rögtön van ellenpéldám. Több helyről tudok, ahol több célra és az adatmennyiség és elosztottság miatt több NAS dobozkát vettünk vagy vettek. Szintén S...y a gyártó. :)

És e-mail archiválásra használják?

Üdv,
Marci

(ha mar lebuktam,) a piler nem tamogat tobb dobozt. Ugy ertem, felteheted akarmennyi gepre, de az akarmennyi fuggetlen archivum lesz. (Reklam helye: kozben dolgozom egy szolgaltatokra kihegyezett verzion is, ami viszont tobb dobozt is tamogat, es egy plusz gui node-dal egyben latszik azok tartalma).

csinalsz magad sajat docker hubot, es oda toltod fel a frissitest.
ha jol ertem az archivalo cuccrol van szo. en a licenset a domainhez kotnem: a licensehez fel van sorolva a.com, b.com, c.com lista (lincensen belul ingyenes a bovites!), es az ahhoz tartozo leveleket elfogadja, minden mas megy a devnull-ba. persze ez nem ved meg attol ha cegen belul ket dobozt rendelnek de egy licenset hasznalnak (egyik a.com-ot tarolja, masik b.com-ot), de cegek kozott nem lesz atjaras igy.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

csinalsz magad sajat docker hubot, es oda toltod fel a frissitest.

meglatjuk, mekkorara novi ki magat a projekt

en a licenset a domainhez kotnem: a licensehez fel van sorolva a.com, b.com, c.com lista (lincensen belul ingyenes a bovites!), es az ahhoz tartozo leveleket elfogadja, minden mas megy a devnull-ba.

ez tetszik! Kosz a tippet. Sot, az smtp session soran az rcpt to utan csak az

cimet fogadja el. Aligha van olyan ceg, amelyik belemegy abba, hogy valami trukkos smtp route-olassal a @masikceg.com cimre kuldje az archivalando leveleit.