ha korbáccsal vernének, se tudnék bonyolultabb megoldást.

Te hogy csinálnád? Van egyébként erre valami szögegyszerű megoldás?

VPN-t nem tud a routered?

Mert ha igen, akkor beállítod pl a telefonodra, konnektálsz, majd utána eléred a kamerákat ugyanúgy mintha otthon lennél.

az biztos, hogy docker nem lenne benne.

Jó leírás, azonban ha már docker, akkor wireguard vpn és meg is vagy + szerintem biztonságosabb is.

Vettem egy Dahua ip kamerát, a gyári appon keresztül mobilneten is elérem bárhonnan. Később vettem Xiaomi beltérit is, de szétvertem úgy kiidegelt.

Köszi!

A VPN nem játszik, mert más is el szeretné érni, aki semennyire nem jártas az informatikában. Ráadásul így akár TV-n is lehet nézni . Ha más nem, akkor a YT-n keresztül.

Felhasználói szemmel nézve ez a legegyszerűbb megoldás.

Szinte biztos, hogy igazad van. Ha lesz egy kis időm, akkor utánajárok és frissítem a cikket.

Érdekelne a megvalósítás. A gyári apphoz jelszó kell, nyiván feltörhető. Kérdés kit érdekel az udvarom pl., hogy ezzel vesződjön. Viszont másik eszközzel belépve a kamerába kiléptet az előzőről a bejelentkezésig. Tehát rögtön látom, ha illetéktelen belépett. Hogyan máshogy kerül ki a kamerám képe?

Ez feltételezi azt, hogy nem lehet az autentikációt teljesen megkerülni, és csak a jelszó végigpróbálgatása az egyetlen lehetőség. A valóságban ezekre a kamerákra lebutított, sérülékenységekkel teli szoftverek (pl. webszerver) kerülnek, amiket aztán senki sem foltoz. Ez azért is rosszabb, mert nem kell, hogy valaki pont a te udvarodat akarja nézni, és időt áldozzon a te jelszavad kitalálására. Helyette keres egy sérülékenységet, ami érinti 3 gyártó 5-5 termékét, majd a megfelelő keresők segítségével böngészget több ezer kamera képe között.
Érdemes belenézni ebbe a videóba: Black Hat 2013 - Exploiting Network Surveillance Cameras Like a Hollywood Hacker

Vpn. De csatlakozom én is az #1-hez.

A VPN nem egyszerű, mert kliensoldali hekkelést igényel, ami ráadásul nem is feltétlenül megoldható, lásd a TV esetét.

Egyébként nem nagyon látom, hogy egyetlen csomag felrakása meg egy reverse proxy beállítása az hol "bonyolult" és hogy mennyivel egyszerűbb ennél felrakni egy VPN-t, amit utána X darab kliensen is be kell állítani.

Igen, így semmilyen módon semmihez sem vagyunk kötve. Van egy URL, ami bárhol működik és kész. A szó szoros értelemben semmi mást nem tud, mint video streamelni. Ennyi pontosan elég. Az már csak hab a tortán, hogy a DNS szolgáltatómnál van lehetőség a web forwardra, amivel elég annyit beírnom, hogy cam1.domain.hu és már ott a video stream.

Nem kell sehol, semmin és senkinél sem beállítani meg elmagyarázni a VPN-t. Akkor még nem beszéltünk arról, hogy akkor mindenkinél be kellene állítani az appot. Vagy ha webes elérés kell, akkor pedig állandóan beírni a felhasználónevet és jelszavat, mert azokat a böngésző nem jegyzi meg. Ráadásul a kamera natív webje nem is megy mindenhol és a settings elég nagy helyet foglal ki a képből.

Végre valaki megértette. Köszi!!!

úgy érted, hogy egy szerencsétlen reverse proxy csomaghoz felrakott egy csomagot, úgymint:
- teljes docker futattó környezet
- abba egy docker image, amiben volt a html streamer
- egy apacs reverse proxy
- meg még a fene tudja, mi minden

egy program miatt egy full dockert? hová süllyedünk még?

A felhasználói követelményeket vettem figyelembe, amikor elindultam ebbe az irányba. Azok szerint ez a megoldás volt az egyszerűbb és kézenfekvőbb.

Igen, az általad minden felsoroltak kellettek, és? Azért vagyok én az IT-s, hogy a felhasználóknak legyen a lehető legegyszerűbb az életük és ne az életem legyen az. Bár összességében a saját életemen is könnyítek, hogy nem kell több embernek is elmagyarázni a VPN-t. 50+-os plusszos emberekről van szó, akik jó ha tudnak böngészni meg emailt olvasni.

Amennyiben megbízol az apacsodban, illetve a kamera szoftveredben, akkor nincs gond. Elöbbi még ok, a kamera szoftvered én nem ismerem.
Részemről nem teszek ki semmilyen publikus szolgáltatást az itthoni szerveremről, csak egy vpn kapcsolat végződését, az is évente lejáró certificate alapon, és a defaulttól eltérő porton, és bonyolult user/passwd kombinációval.
Én nem szeretek azzal pöcsölni, h az egyszerűségen, könnyen kezelhetőségen feláldozom a biztonságot.

De izlések kérdése. Itthoni kamerát meg max az asszonynak kellene nézni. Belefér egy másik eszközön is belőni.

értem, tehát a hsz-ben megfogalmazott érvrendszered szerint egy program miatt feltenni a dockert az sokkal hatásosabb és jobb, mint ugyanezen egy programot elindítani docker nélkül. és ugye azáltal, hogy dockerbe tetted azt az egy programot, sokkal kevesebbet kellett okítanod a felhasználókat, mintha natívan futtatnád.

szép példáját hozod annak, hogy mi a probléma az it-vel manapság.

1. Az "apt install docker" nem egy nagyon bonyolult dolog, de egyébként valószínűleg eleve volt nála.

2. Mivel docker image van, .deb meg nincs, ezért nyilván így a legegyszerűbb felrakni.

3. A reverse proxy megint tök alap dolog, sőt, ha már volt neki legalább egy, akkor kb. fél perc bekonfigurálni.

4. Más nincs.

Várom a te sokkal egyszerűbb és gyorsabb megoldásodat!

Vegyük ketté a dolgot.

Nézzük először a felhasználói szemszögből. Abban megállapodhatunk, hogy egy cam1.domain.hu beírásnál, majd _egyszeri_ user/password beírásnál nincs egyszerűbb? Mindezt úgy, hogy a user csak a videót szeretné látni és semmi mást nem.

Most nézzük a technológia oldalát. Abban egyetérthetünk, hogy a fentebbi egyszerű UI úgy a legegyszerűbb megoldani, ha egy szerver streameli a videót a felhasználóknak egy reserve proxyn keresztül? Így nem számít hányan lépnek be, stb.

Hogy miért dockerben fut? Mert a restreamer kitalálója így álmodta meg és szerintem ezzel az égegyadta világon semmi gond nincs. Sőt, ezzel megtettem az első lépést afelé, hogy minden service-t dockerben fusson itthon, amit mondjuk egy kubernetes foghatna össze. De ez még egy távoli dolog.

oké, nézzük.
1. elfogadom bizonyítás nélkül, hogy szerinted egy domain név meg egy user/pass páros a legegyszerűbb az user szemszögéből.
vagy inkább azt fogadjuk el, hogy minimális user interakció a kívánatos. ezt most ne fejtsük ki bővebben.

2. nézzük a technológiai oldalát. itt muszáj kétfelé bontani a történetet: általános és specifikus részre.

2. általános: az általánosba az a történet tartozik, hogy jó-e, hogy minden vackot dockerrel meg saját csomagmenedzsmenttel (flatpack meg hasonlók, a nevüket se tudom, mert érdemtelenek arra is, hogy megjegyezzem) meg hasonló módon akarnak megoldani a linuxokon. válasz: NEM JÓ. gyakorlatilag minden rosszat el lehet mondani arról, amivel a docker jár. minek? nagy, behemót, stb. stb. ilyenek futtatására kitaláltak egy csodálatos operációs rendszert, aminek ez az alapfilozófiája, úgy hívják, hogy windows server edition. a linuxot arra találták ki, hogy kis programokat hatékonyan összekapcsolva működjön, meg arra, hogy minden program egy dolgot csináljon, de azt jól. ugyanezért totálisan téves felfogás kubernetessel oldani meg olyan dolgokat, amiket egyébként a linuxok szoktak tudni maguktól. pláne úgy, hogy ha dockerezik valaki, előbb-utóbb rászokik (mint te) a kubernetesre, lásd: kapudrog kifejezés a szótárban, aki kubernetesezik, az előbb-utóbb puppetet meg cefet meg mindenféle hasonló betegségeket is elkap, és a végén oda jut, hogy amit én egy pc-vel elfuttatok hibátlanul, ahhoz neki fél racknyi pc-ből összehordott cluster kell, terabájtnyi memóriával, 16-128 magos processzorokkal, nvme ssd-vel, minimum 25 gigás hálózattal, stb. stb.

alapszabály: minél több szoftver fut, annál több a hiba. pont. és amit megnyerhetnél elvben azzal, hogy docker konténerfájlt telepítesz, bőven elbukod azzal, amikor valamelyik szoftverrétegben hiba lesz (mert lesz, ebben ne legyenek kétségeid) és meg akarod találni, pláne javítani.

2 specifikus: én letöltöttem és megnéztem a forrását ennek a csomagnak. szerintem tedd meg te is, mert azt gyanítom, eddig nem történt meg. a forrásában van egy rakás js fájl, amiből te azt használod, hogy bekérsz egy usernevet meg egy jelszót, amit egyébként a jelszóvédett html-eknél az apacs meg a böngésződ simán megold. letölt egy csomó deb-et(!!!), majd patkol és fordít magának egy saját ffmpeg csomagot (ez önmagában normálatlan eljárás a szabad szoftver világban, az általa használt bitrate patchet illett volna upstream belejuttatni az ffmpeg stock gyári forrásába), majd letölt és telepít egy nginx-et.

Tehát azt, amit normálisan a kamera webszervere simán ki tudna szolgálni, de ha nagyon biztonság-mániás vagy, akkor egy reverse proxyval (ezt még el tudnám fogadni), azt ez a docker cucc HÁROM webszerverrel, egy rakás pluszban feltelepített cuccal és egy méretesebb javascript weboldallal oldja meg.

ha ez nem pazarlás, akkor semmi sem az.

összefoglalva: alapvetően docker ellenes vagyok, ÉS ennek a konkrét docker cuccnak a vizsgálata után azt is kijelentem, hogy ez a konkrét docker cucc még azon belül is a kirívóan silány módon összegányolt cuccok egyike.

de revideálom az első hsz-emben írtakat: ez egy sokkal nagyobb szemétdomb, mint amihez korbács kellene.

Tehát akkor te sem tudsz egyszerűbb megoldást.
Oké, köszönjük az értékes hozzászólásokat.

szerinted amit leírtam, abban nincs benne a sokkal egyszerűbb megoldás?
ráadásul mi az egyszerűbb megoldás? amit könnyebb telepíteni vagy amit könnyebb üzemeltetni? az biztos, hogy ha csökkented a webszerverek számát meg kihagysz minden réteget, ami nem kell, akkor az egyszerűbb megoldás lesz.

Pont ez a baj, hogy van. Nekem is olyan cumó kell majd, ami nem igényel semmilyen külső kapcsolatot, csak belső hálón működik.

Amúgy nekem is sok kicsit a Docker, tehát ugyanezt meg lehetne nélküle is, és nem is lenne hülyeség. De pl. nekem a home serverben 1GB RAM van, meg egy i3-330M. Ebből miért áldozzak egy Dockerre is?
Kicsit a cikk is kevés információt ad arról, hogy mi miért van úgy, de amúgy maga tömörségében nem rossz.

[ Szerkesztve ]

Pár éve volt egy nagy DDOS támadás, amit jórészt bugos IP kamerákkal viteleztek ki, amik kevés csomagot tudtak küldeni egy időszeletben, de rengeteg kamera tolta egyszerre. Senkit nem az udvarod érdekel kb., hanem pl. behúzni egy botnetbe a kamerád.
A jelszó semmit nem számít. Olvass utána, hogy hogyan történik egy-egy konkrét biztonsági rés kihasználása, és látszik, hogy pont az a lényeg, hogy semmilyen jelszót nem ad meg a támadó, egyszer csak bent van mondjuk service-ként a támadott gépen, vagy egyszer csak sima user helyett admin jogai lesznek.

@buherton : Ha félreérthető, nekem csak azért fura a Docker, mert a feladat nem indokolja, vagy nem látom benne, hogy miért muszáj. Mondjuk valamilyen szinten biztonságosabbá tehető a dolog anélkül is, az igaz.

Mondjuk ezt, hogy a kamera képe magában látszik másik eszközön, én wget-tel csináltam, csak az ugye nem srtream, hanem pár másodpercenként egy kép áthúzása, de nagyságrendekkel kisebb erőforrások voltak ott (TP-Link 841-en futott...).

[ Szerkesztve ]

szerinted 0,03 GB memóriahasználat a megtakarítás, szerintem meg egy rakás felesleges, de komplex alrendszer üzemeltetésének az elmaradása a megtakarítás.

"Egyikre se adtál megfejtést.": választ vártam, nem visszakérdezést. különös tekintettel arra, hogyha nem kötözködni akarnál, akkor pontosan tudnád, hogy mit gondolok erről.

"Nem, nincs.": előbb-utóbb kinyitnak a szemészeti szakrendelések.

Melyiket egyszerűbb egy 60+ éves informatikához nem értő rokonnak elmagyarázni?
1. Nyisd meg a böngészőt, írd be azt, hogy cam1.domain.hu, és tádá!
2. Csaltakozz a VPN-hez, telepítsd fel egy appot, vagy szintén böngészőben gépeljen be egy web címet + portot.

Őszintén úgy gondoltam, hogy legalább ebbe nem fog belekötni senki, hogy az 1. a jóval egyszerűbb megoldás felhasználói szempontból.

flatpack

A docker semmilyen módon nem köt meg. A restreamer image pont az aptt használja.

az általánosba az a történet tartozik, hogy jó-e, hogy minden vackot dockerrel meg saját csomagmenedzsmenttel (flatpack meg hasonlók, a nevüket se tudom, mert érdemtelenek arra is, hogy megjegyezzem) meg hasonló módon akarnak megoldani a linuxokon. válasz: NEM JÓ.

De igen, jó. A docker egyik célja az volt, hogy a virtuális gépeket végre le lehessen váltani. Bár kompromisszumokkal, de ez sikerült a dockerrel. Végre eltűnt egy jó vastag réteg, ami komoly erőforrásokat zabált. A docker ezzel szemben semennyire nem lassítja a program futását. Szinte semennyivel több memóriát használ (néhány 10 MB, nagyon max néhány 100 MB).

ugyanezért totálisan téves felfogás kubernetessel oldani meg olyan dolgokat, amiket egyébként a linuxok szoktak tudni maguktól.

A docker mögött az a filozófia, hogy a futtató környezetet én állíthatom be, ami aztán mindegy milyen hoston fut, mert futni fog, mert mindent biztosít magának.

A kubernetes mögött az a filozófia, hogy van egy microservice halmazom, ami valamilyen topológia/láthatóság/stb alapján rendezett + egyéb kiegészítő szolgáltatások is elérhetők, mint a domain, stb és ezeket egy clusteren futtatja, amiben aztán szinte bármilyen Linuxok lehetnek.

A végén úgyis működni fog, mert a docker + kubernetes mindent leír.

amit én egy pc-vel elfuttatok hibátlanul, ahhoz neki fél racknyi pc-ből összehordott cluster kell, terabájtnyi memóriával, 16-128 magos processzorokkal, nvme ssd-vel, minimum 25 gigás hálózattal, stb. stb.

A docker + kubernetesnek ehhez semmi köze. Az hogy az a program ami ebben fut az ekkora erőforrást igényel az nem a docker + kubernetes hibája. Ezek szinte nulla overheaddel operálnak.

alapszabály: minél több szoftver fut, annál több a hiba. pont. és amit megnyerhetnél elvben azzal, hogy docker konténerfájlt telepítesz, bőven elbukod azzal, amikor valamelyik szoftverrétegben hiba lesz (mert lesz, ebben ne legyenek kétségeid) és meg akarod találni, pláne javítani.

Ezt mond azoknak a tudósoknak és researchereknek is, akik az 5G-t (és gyakorlatilag minden új dolgot) clould-only-ban fejlesztenek.

2 specifikus: én letöltöttem és megnéztem a forrását ennek a csomagnak. szerintem tedd meg te is, mert azt gyanítom, eddig nem történt meg. a forrásában van egy rakás js fájl, amiből te azt használod, hogy bekérsz egy usernevet meg egy jelszót, amit egyébként a jelszóvédett html-eknél az apacs meg a böngésződ simán megold. letölt egy csomó deb-et(!!!), majd patkol és fordít magának egy saját ffmpeg csomagot (ez önmagában normálatlan eljárás a szabad szoftver világban, az általa használt bitrate patchet illett volna upstream belejuttatni az ffmpeg stock gyári forrásába), majd letölt és telepít egy nginx-et.

Ennek semmi köze sincs a dockerhez.

Tehát azt, amit normálisan a kamera webszervere simán ki tudna szolgálni, de ha nagyon biztonság-mániás vagy, akkor egy reverse proxyval (ezt még el tudnám fogadni), azt ez a docker cucc HÁROM webszerverrel, egy rakás pluszban feltelepített cuccal és egy méretesebb javascript weboldallal oldja meg.

A kamera legutolsó frissítését 2012-ben kapta. A HTTPS-t bár ismeri, de a self-signed certen kívül mást nem. Ez minden tekintetben egy nem biztonságos mód. Az már csak a hab a tortán, hogy a böngésző nem ismeri fel, hogy a bejelentkező ablakon user/password van így mindig be kellene írni a user/password-t. Ez nem user-friendly, de ezt már legalább háromszor leírtam. Többet nem fogom.

Azt látom, hogy teljesen alaptalan dolgokkal dobálózol mindenféle komoly háttértudás nélkül és végül jössz a végítéleteddel.

Ezen fut [ASROCK J3455-ITX] két restreamer is. 3 Mb/s a stream és nincs konvertálás, így 2-4% a CPU usage/process. A memória használat is minimális.

Köszi a visszajelzést!

Mindent érdemes dockerben futattatni, amit az adott Linuxon használsz. Itt nincs olyan, hogy "nem indokolja".

A docker egy eszköz, hogy host független lehess. Azt kell eldöntened, hogy kell-e ez a host függetlenség. Ez a gyakorlatban azt jelenti, hogy az otthoni szerveredet leírod dockerben + kubernetesben, akkor egy esetleges szerver csere/upgrade minimális beavatkozást fog igényelni, mert nem fogsz ezektől függeni. Mindegy hogy Redhat, Debian, Ubuntu, a rendszered fut a maga világában.

Sőt tovább megyek. Ha mondjuk újabb/régebbi verziójú packaget szeretnél használni, mint ami a package managerben elérhető, akkor a docker a megoldás.

[ Szerkesztve ]

te tényleg egy olyan állításommal vitatkozol, ami úgy kezdődik, hogy elfogadom a tiédet? rotfl.

amikor azt írtam, hogy rakás pc kell a futtatáshoz, akkor nem a benne futó programról beszéltem, hanem a docker meg az orchestration cuccokról. azért kell egy rakás cuccot futtatnod, hogy legyen mire dockert telepíteni. miközben a dockerben levő programot magát simán futtathatnád natív linuxon is.

a dockernek minimálisan kevesebb az erőforrásigénye, mint egy virtualizált rendszernek. de ezzel a feltételezéssel nem az a baj, hogy több vagy kevesebb, hanem az, hogy csúsztatásként a dockert egy teljesen virtualizált hoszthoz hasonlítod ahelyett, amit én írtam róla, hogy natív linuxhoz hasonlítanád. a natív linuxszal szemben a docker mindig veszít.

a docker meg a kubernetes körül az a filozófia, hogy lusták kijavítani az alapszoftver hibáit, inkább csináltak egy teljesen másik rendszert (lásd: docker, kubernetes, puppet, chef, stb) ami arra jó, hogy a hibákat elfedje, de legalább rakás újabb hibát hoz a rendszerbe.

"Ez nem user-friendly, de ezt már legalább háromszor leírtam. Többet nem fogom.": ne azért ne írd le többször, mert már háromszor megtetted, hanem azért, mert ezzel nem vitatkoztam.

"Azt látom, hogy teljesen alaptalan dolgokkal dobálózol mindenféle komoly háttértudás nélkül és végül jössz a végítéleteddel.": én meg azt látom, hogy amikor valaki beszaladt az erdőbe tátott szájjal, akkor a vége mindig az, hogy annak a tudását kritizálja, aki bebizonyította neki, hogy marhaságot csinált. valahogy a tisztelt vitatkozópartnerek mindig összekeverik a nem érti kifejezést a nem ért vele egyet kifejezéssel.

"Ha mondjuk újabb/régebbi verziójú packaget szeretnél használni, mint ami a package managerben elérhető, akkor a docker a megoldás.": jaja, a wanabe newcomer unixosok ezt az egy megoldást ismerik, mert a többit nem. de ne érezd magad rosszul emiatt, nálad sokkal szakképzettebb linuxosok se ismerik a többit.

OK, de mennyi az annyi? Mert amikor nincs kihasználva, akkor elég sok minden el tud futni minimális terheléssel.

Hogy mindent Dockerben : Igen, az a kényelem. Az a része is jó, hogy költöztethető, és pont biztonságilag is lehetne inddokolni amúgy, hogy akkor azon az imagen jobban tudod korlátozni a műsort, de úgy különben én nem tennék mindent Dockerre. Jó dolog az, de pl. itthonra nekem tök indokolatlan. Meg így elsőre nekem arra is indokolatlan, hogy ott fusson benne 1db szoftver, ami kiküld egy adatfolyamot. És ilyen szinten, ami itthon van? 1 webszerver három virtualhost-tal, egy TFTP, ezeket azért nem különösebb nehézség áttenni máshová, ha kell. Openwrt-s eszközök között sem volt az a kifejezett macera, amikor azon futott.

Eltérő csomagverziók - mondjuk library-k natívan is telepíthetők több verzióban, de pl. leforgatni a régebbit külön könyvtárba, ilyesmik. Azért ehhez nem kell helyből virtualizáció.

[ Szerkesztve ]

Ezeken a nagy vasakon mi is fut pontosan? Oké docker meg kubernetes, de milyen célból/melyik része?

Mi a problémája az alapszoftvernek? Egyáltalán melyik alapszoftverről van szó?

Milyen toolról van szó? Teljesen komolyan kérdezem.

Ezek az értéket úgy mértem, hogy közben streamelt és néztem egy másik fülön a műsort.

A nem nehéz áttenni és a semmit nem kell csinálni (a docker-t azért fel kell tenni) között van azért különbség.

Mindent meg lehet oldani a docker nélkül, de egyszerűbb a dockerrel.

te most úgy vitatkozol, hogy azt se érted, mit kapsz válasznak?

Úgy _kérdezek_, hogy a válaszodból indultam ki.