Hirdetés
- ZIDOO médialejátszók
- Milyen alaplapot vegyek?
- Vezeték nélküli fejhallgatók
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Házimozi haladó szinten
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- Milyen billentyűzetet vegyek?
- Kompakt vízhűtés
- Nvidia GPU-k jövője - amit tudni vélünk
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
Új hozzászólás Aktív témák
-
samujózsi
tag
válasz
instantwater
#150
üzenetére
Teszt, tanulás vagy mint a példa mutatja, építés
Ezt nagyon utáltam a windows-okban, hogy egy diszket nem lehetett csak simán áttenni egyik gépből a másikba (licenctől függetlenül)Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#153
haddent
addikt
instantwater
#150
haddent
addikt
válasz
instantwater
#150
üzenetére
Szeparáció. Biztonságos a Docker, de épp tegnap beszéltünk paranoiáról, nem?
Ezen felül részemről a Docker hoszt-guest kívülröl most egy sandbox, azt művel belül amit akar, kívülről úgyis csak 80,443/tcp van odaengedve. Illetve, részemről, ha külön vasam lenne szervernek, akkor azon natívan futna a Docker, de mivel 1 gép nálam a tűzfal, docker-szerverek + htpc, ezért tényleg indokolt, szerintem -
samujózsi
tag
Most kipróbáltam másik kvm-ben, az előzőben valami el lett... szóval ellett... izé el lett...
Megy a docker ufw mellett is a kvm guestben.
Csak azt utálom, hogy ha szabályozni akarom adott szolgáltatás elérhetőségét, akkor azt manuálisan kell, mert a docker ahogy korábban megtárgyaltuk, belepiszkál az iptables táblákba.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#156
huliganboy
addikt
huliganboy
addikt
Sziasztok!
Segítséget kérnék, nem áll össze a fejeben ez a konténerezés.
Van egy kiegészítőm ami dockerben "kell" futtatni.
A docker dokuja alapján feltelepült...
A kiegésztőt pull segítségével lehívtam, ezt kapom utána:
Digest: sha256:00000000000000000000000000000000855655af5
Status: Downloaded newer image for paradoxalarminterface/pai:latest
docker.io/paradoxalarminterface/pai:latestInnen hogyan tovább? Illetve van valami kimenet ahol látom a kiegészítő futását?
Köszi
szerk:
Ha végig akarom csinálni a kiegészítő wiki szerinti lépéseit ezt a hibát kapom?000@00000:~/docker$ docker-compose up -d paiERROR:Can't find a suitable configuration file in this directory or anyparent. Are you in the right directory?Supported filenames: docker-compose.yml, docker-compose.yaml[ Szerkesztve ]
-
#157
golya87
őstag
huliganboy
#156
válasz
huliganboy
#156
üzenetére
A pull csak letölti az image-et. Milyen paranccsal indítod a konténert?
-
#159
pelyib
tag
huliganboy
#156
pelyib
tag
válasz
huliganboy
#156
üzenetére
A hibaüzenet elég beszédes ("Can't find a suitable configuration file"): nincs ott a docker-compose.yml file.
Nézdmeg, h nincs e elírva a neve (ezeket támogatja: docker-compose.yml, docker-compose.yaml), vagy lehet máshol hoztad létre, akkor másold ide. -
samujózsi
tag
Fura dolog tűnt fel/nem találok valamit a doksiban:
Tényleg nincs rá mód, hogy a konténer leállításakor futtassak valamit?
Mert egy http szervert kilőni nem nagy szám, de mondjuk egy adatbázis szervernél azért bármennyire bolondbiztos, nem feltétlenül kockáztatnék ilyesmit, tekintettel arra, hogy láttam már kill -9 kapcsán összeomló és csak mentésből helyreállítható adatbázist.
(#160) huliganboy
A docker-compose.yml tuti, hogy jól van leírva? Nincs benne elírás? Jogosultsága van a docker-compose-t futtató usernek az olvasásához? (nem tudom, hogy az valóban saját néven fut vagy setuid-os és valójában más user nevében futtatod... ha korlátozottak rajta a jogok, esetleg kipróbálnék egychmod 0777 docker-compose.ymlparancsot.
Milyen rendszeren futtatod? Valami SELinux, apparmor vagy hasonló nem rondít bele az életedbe? Ezek jutnak hirtelen eszembe.Közben rákeresve a hibára, még ezt találtam: [link]
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#162
pelyib
tag
huliganboy
#160
pelyib
tag
válasz
huliganboy
#160
üzenetére
MI nem áll össze?
Wiki-ben max az nem tiszta, hogy egy service-nek minek composer. Arra egy sima dockerfile is eleg lenne.
Én arra mennék tovább ami a linkelt oldalon vannak samujózsi kommentjében -
#163
instantwater
addikt
samujózsi
#161
instantwater
addikt
-
#164
instantwater
addikt
pelyib
#162
instantwater
addikt
Akár csak egyetlen servicere is azért jó a compose, mert ha bonyolult az indítási parancs mondjuk több konfig flag, portok, környezeti változók, volumek, miegymás akkor sokkal egyszerűbb ezt az egészet egy yml fájlba elmenteni mint egy nagyon hosszú parancsot elindítani.
-
samujózsi
tag
válasz
instantwater
#163
üzenetére
Nem állítom, hogy értem: amit írsz, inkább workaroundnak tűnik, mint korrekt leállításnak.
Arra gondolok, hogy a konténer indításához megadhatok egy ENTRYPOINT sort és akkor az a konténerrel feljön. De ugyanitt nem adhatom meg, hogy mi történjen, amikor leállítanám a konténert, pedig esetenként nem ártana. (feltételezem, most nem túrtam fel a doksit, küld egy SIGHUP-ot vagy SIGTERM-t, csak ezt nem minden szoftver kezeli tisztességesen, én meg kívülről egyrészt milyen jogon avatkoznék bele, másrészt úgy rémlik, hogy a trap-ből korlátozottan lehet csak műveleteket indítani)[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#166
instantwater
addikt
samujózsi
#165
instantwater
addikt
válasz
samujózsi
#165
üzenetére
Pedig ez így működik: [link]
Valóban nem minden szoftver kezeli tisztességesen de azok Docker nélkül sem kezelik tisztességesen, így Docker nélkül is ugyanúgy megsérülhet az adatbázisod.
A hivatalos imagekben ez általában benne van.
Amiben nincs benne, ott használhatsz valami init rendszert ami lekezeli a signalt és leállítja megfelelően a benne futó alkalmazást. De írhatsz egy saját kis entrypoint scriptet is ami ezt kezeli.
-
#167
huliganboy
addikt
huliganboy
addikt
Köszönöm mindenkinek. Egyelőre félsiker.... Mielőtt írtam ma olvastam, tanultam.. Kezd tisztulni, de gyakorolni kell....
Most ott tartok, hogy a docker fut, benne van már két szükséges alkalmazás... A node Red tökéletesen megy, de ezt egyszerű ellenőrizni, hisz van webes felülete működik...
A másik viszont nem tiszta, nem logol, amire kitalálták sem megy, talán nem is fut? Bár azt mutatja a docker...
Ebben létezik olyan parancs, mint amikor egy Python parancsot futtatok, és végig írja a folyamatot?
-
#168
instantwater
addikt
huliganboy
#167
instantwater
addikt
válasz
huliganboy
#167
üzenetére
Ez composevel még egyszerűbb, mert nem kell container IDt keresned.
[ Szerkesztve ]
-
#169
haddent
addikt
instantwater
#168
haddent
addikt
válasz
instantwater
#168
üzenetére
Pont ezekért érdemes mindenre compose -t, akár 1 service-re is. Sokkal letisztultabb a config, és simán docker-compose logs -f, meg docker-compose exec <név> bash stb. Még sokkal szebb, ha container_name is def a composeban
-
samujózsi
tag
(ez inkább amolyan blogpost, mint kérés/kérdés, nem is arról szól, hogy jajjistenem, feltörik az itthoni gépem, ha valamelyik konténer nem kellőképp up-to-date, inkább csak általánosságban igyekszem gondolkodni, de hátha valakinek van hozzáfűznivalója...)
Minél jobban beleásom magam a docker témába, annál kevésbé látom az igazi előnyeit egy virtuális géppel szemben (pláne valami komolyabb vmware, esetleg xen telepítéssel szemben) - leszámítva a virtualizáció valamivel magasabb overheadjét.
Elvben el van szeparálva a konténer a host rendszerétől, de alapbeállításokkal (most kizárólag Ubuntu-s tapasztalatokról beszélek), ez nagyon kevésnek tűnik:
Például nincsenek beállítva processz limitek, így egy vicces kedvű felhasználó, ha valami módon shellhez jut egy konténerben, egy fork-bomb segítségével kifektetheti a hostot. (eredetileg korlátozva voltak, csak állítólag sok helyen okozott gondot a default ulimit, ezért unlimited-re tették)
Nincs default user mapping, ami a konténerben root, az a hoston is az. Ez nem tűnik jó ötletnek, ha már szeparáció és van is rá eszköz. Miért nem az az alapértelmezett, hogy használja a mappinget?
Ha jól értem, a Linux capabilities használata is beavatkozást igényel, mert alapjáraton a konténerben futó root-nak minden joga megvan (legalábbis kellett egy --caps-drop=ALL ahhoz, hogy a konténerből ne működjön pl a ping - erről tudtam, hogy a CAP_NET_RAW jog kell neki)
Akkor ott az update-ek kérdése, amit bevallom, továbbra sem tudtam feldolgozni: van egy működő konténerem, ha azt akarom, hogy a benne használt összes szoftver be legyen foltozva záros határidőn belül, akkor mi is a teendő? Lesni minden létező szoftvert és ha valamelyikhez jött security patch, akkor rebuildelem a konténert?
Nem teljesen tiszta, hogy mi is van a konténerben futó démonokkal, azok logolásával - utóbbi főleg akkor izgalmas, ha valahol üzemel egy log szerverem, ahol gyűjteném a logokat, de a konténerekben általában nincs syslogd, ami átküldené ezeket a log szerverre, bár ezen lehet, hogy segít a run --log-driver és --log-opt kapcsolójának megfelelő beállítása - ezt még meg kell néznem. Ezek most leginkább úgy jöttek elő, hogy nézegetem tegnap óta a squid és a freeradius futtathatóságát, előbbinél a logolás nem tűnik triviálisnak, mert valamiért csak a saját logját(/var/log/squid/*) hajlandó írni, hiába próbálnám a syslogba küldeni - ez még lehet az én hibám is, utóbbinál meg a szabályos leállás, meg egyéb signal kezelés tűnik problémásnak (korábban célozgattam adatbázisokra, na a radius egy ilyen sérülékeny valami, amennyire emlékszem rá), amit csak elég komoly munkával lehet megoldani, wrapper script írással és egyéb konfigurálgatással.
Akkor ott van a hálózat, elsősorban a szolgáltatásoknál szűrni a klienseket, amit szintén nem triviális megoldani, bár megoldható.
Ehhez képest nekem most egyszerűbbnek tűnik feltolni egy virtuális gépet, dinamikus memória használattal, abba beleszórni a szükséges szoftvereket - igaz, így egymástól nincsenek védve, ahhoz külön vm kell, viszont könnyű naprakészen tartani, bármi történik a vm-ben, elhanyagolható esélye van, hogy magával rántsa a hostot, a szoftverek init scriptjei működnek, nem kell wrapperekkel nyűglődni, a "tűzfalazás" megoldható a vm saját packet filterével stb.
Szóval mostanra elég sok kétség merült fel bennem, hogy jó-e, ha áttolok mindent docker-be?
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
válasz
samujózsi
#170
üzenetére
Bár nem értem minden szavad, DE. Én pl linuxserver konténereket használok. Van pl nginx konténerük. Felparaméterezve elindítom.
docker run --rm \ --name=nginx \ -e PUID=1111 \ -e PGID=1111 \ -e TZ=Europe/Budapest \ -p 80:80 \ -p 443:443 \ -v /path/to/appdata/config:/config \ linuxserver/nginx
Így az 1111 user és 1111 csoport nevében fut a konténer és csak a .../config mappába tud dolgozni. Ebből ha kijut, akkor szvsz egy vm se akadály annak a power user-nek. A konténereknek szintén tudsz erőforrás limitet állítani. Ha jön ki újabb image (minden pénteken vagy szombaton van friss build náluk), akkor kap egy docker stop-ot, majd docker pull linuxserver/nginx és végezetül a fenti parancs újra. Ez compose-ban még könnyebb, de most az lényegtelen. A frissítést lehet automatizálni is, de szvsz nem szerencsés éles környezetben.
Én kényszerűségből álltam át Docker-re az N40L-en, de nem bántam meg. A dependency hell nem vicces. Azóta RPi4-esen is így vannak a dolgaim.Remélem tudtam segíteni!
-
haddent
addikt
válasz
samujózsi
#170
üzenetére
Sok mindent nem látsz még megfelelően át, ebbe most nem mennék mélyebben bele, mert óriási téma és nyilván bőven van amit én sem meg senki sem, amikor épp kell, akkor felkeresi az ember a szükséges infókat. De a teljesség igénye nélkül:
Ami belül root, az kívül semmi, nagyon nem root, soha, semmiképp. Kivéve a privileged containerek.
Egy konténer frissen tartása rendkívül egyszerű feladat: pullolod az újat, vagy buildeled, ha nem official hanem saját image. Azért látod rosszul, mert "benne használt összes szoftvert" -ként emlegeted. Ez már itt rossz. Egy konténerben szinte csak egy szoftvert használsz, épp ez a lényege, microservices. Pl. egy weblap nem egy konténer egyben nginx mysql stb., hanem mind külön. Innentől az update is megoldott említett módon
Logolásra alapvetően nem-démonizáltan szokás mindent konténeren bleül futtatni foregroundban, így a log a compose logs streamre kerül, amit docker logger driverrel aztán bárhova IS küldhetsz, syslogként meg csomó log aggregátorhoz van előreírt driver
Óriási előnye, hogy az overhead kb. nulla, nagyon natívan fut minden. Illetve mivel microservicek vannak nem szerverek lényegében, ezért nem pazarolsz még sokkal többet külön szerverekre, vm -ekre.Végül pedig a kérdésedre az igazi válasz: nem kell mindent átpakolni Dockerbe! Helyén kell kezelni a dolgokat, tudni eldönteni, hogy mihez kell baremetal, mihez jó vm és mihez Docker.
Részben objektív, részben ízlés kérdése szintű példa: nem lenne elméleti akadálya, hogy a tűzfalat is Dockerizáljam, de k*#ra nagyon rossz ötlet lenne és nem oda való, de ugyanígy egy web szerver sem való vm -nek, ahogy a torrent "szerver" sem, ahogy egy Jellyfin (Emby/Plex) sem és egy Nextcloud sem.Röviden: ami nem kifejezetten biztonsági eszköz és egy, jól behatárolható feladtot lát el, vagy felbontható x kissebb konkretizálható feladatra, azt érdemes szétdobni konténerekbe és stacket építeni belőle, szerintem. Ez az én álláspontom jelenleg, nem mindig volt így és valószínűleg nem is lesz, de a mai tudásom és a napi szintű tájékozódás alapján én így lövöm be, most
-
samujózsi
tag
Csak a root vs nem root témára reagálnék, mert most mobilon vagyok.
Ubuntu 18.04:apt install docker.io
docker run --rm -v /tmp:/xxx -it alpine
#/ touch /xxx/valami
ctrl-d
ls -l /tmp/valamiLehet, hogy meg fogsz lepődni?
De ha még fut a konténer és nézel egy
ps xau
kimenetet, ott is root a user.Vagy... ha épp üres a géped, indíts el egy fork-bomb parancsot egy konténerben (valami dereng, hogy alpine konténerrel pont nem ment)
Csak előtte nem árt egy sync, mert esélyes, hogy a host is vele megy.Nem tudom, mindez mennyire ubuntu specifikus.
Ui: összes szoftver=bináris+függőségek+shell+... rengeteg dolog van még egy alpine konténerben is, hát még egy centos v. ubuntu konténerben...
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
A hangsúly ott van, hogy felparaméterezve.
A user mappingnek (szerintem) alapértelmezettnek kellene lennie.
Én a /etc/docker/config.json fájlba írtam bele, hogy ne a host usert használja. De miért nem lehet ezt defaultként?Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz
samujózsi
#174
üzenetére
Pardon (közben visszaültem a géphez) /etc/docker/daemon.json a fájl és egy ilyen kell bele:
{"userns-remap": "docker-user"}A docker-user egy létező user a hoston és nem árt, ha a /etc/subuid és /etc/subgid is tartalmaz róla szóló infót.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
No, szóval már a gép mellől.
Elindítottam egy nginx konténert, ez debian (vagy ubuntu?) alapú:root@aae537fa9531:/# dpkg -l | grep '^ii' | wc -l118Ez azt jelenti, hogy 118 telepített, karbantartandó csomag.
118 olyan csomag, amelyekben bárhol, bármikor felfedezhetnek valamilyen hibát. Pedig csak egy mezítlábas nginx, alkalmazás nélkül. Ha még mellé kerül valami keretrendszer, akár php, akár python (erről lehet vitatkozni, hogy az külön konténer vagy mehetnek egybe), az még több függőséget jelent.És amíg csak én játszom a saját gépemen, addig ez belefér, de ha valami érzékeny adatokat tároló szolgáltatásról van szó? Egy debian/ubuntu szerveren kiadok egy
apt-get update && apt-get upgradeparancsot, akkor látom, hogy jött-e update. Egy régi, stabil rendszeren ez nagyon sokáig úgy tér vissza, hogy nincs semmi update. Aztán hirtelen jön egy, amikor találnak valamit és javítják. Ezt dockerben hogy kezeled? Én eddig annyit találtam, hogy lesem az alap image dátumát és ha változik, akkor rebuild (a pull átírja a futó image-hez tartozó layereket is?). Nem túl szimpatikus.
És akkor még ott van a buildeléskor felrakott csomag és függőségei, amit (ez most jutott eszembe) a base image készítője nem is fog update-elni.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Jelzem, nálam a te módszered nem is működik, a -e PUID -e PGID csak a shell változókat állítja be, ettől még maga a user marad az eredeti, tehát alapjáraton a root.
(#172) haddent
Log: ha jól emlékszem, a squid a "-s" kapcsolóval a teljes logját átküldi a syslog démonnak. Ha konténerben futtatom, ragaszkodik hozzá, hogy a konténer saját /var/log/squid/access.log és cache.log fájljaiba írjon.
Vagy én írtam el valamit az imént, de így elsőre ezt kétlem.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
haddent
addikt
válasz
samujózsi
#177
üzenetére
#173: -ra: hát ha bemountolod neki a filesystemet, akkor nyilván tudja írni
lehet ro kapcsolóval is. User mapping, iptables nyulkapiszka alapból stb., lehet erről vitatkozni, de amíg van egyenes és nem gány workaround megoldás, addig nem gondolom, hogy baj. Konténeren belül nem root futtatja a dolgokat, az egy dolog, hogy te hosztról hozzáférsz a roothoz, de az alkalmazást feltörőnek ugyanúgy privescelnie kell, majd onnan még konténerből megszöknie, nem lesz könnyaű dolga.. De igen, nyilván vitatathatatlanu könnyebb, mint vm -ből szökni.A frissítéseknél pedig pull lehúzza a latest tagű imidzset, re-upnál már azzal indul. Official imidzseknél ergo megbízol a csomagolóban, hogy frissíti, ha van 0day hotfix, ami rendszerint meg is történik. Erről lehet vitatkozni, csak felesleges. Igen, +1 absztrakció, valóban. De ennyi erővel mindenféle csomagkezelő meg csomag is az, hiszen van sok dependencia, mi van, ha a láncban valahol valami hotfix kijön és egyik ráépülő meg nem reagál stb..? Ugyanez. De igen, ez is +1 absztrakció. Ellenkező esetben a "tökéletes" megoldás, hogy kizárólag saját imidzseket használsz, automatizálsz mindent, folyamatosan figyel, amint kijön valami buildel, deployol. Nekem van Jenkins CI -om erre, baromira nem használom
Ha ez még mind mindig nem elég, akkor egyetlen megoldás it-sec szempontból a teljesen saját implementáció teljesen saját, zárt forráskóddal, ami aztán telis tele lehet hibával és exploittal, mert senkinek fingja nincs róla és vaktyúk is talál szemet módszerrel jóval nehezebb feltörni valamit, mintha a kódot elemezgetve unatkozva játszanak a gyerekek
Log: de épp ezt mondom, hogy nem syslognak, hanem foreground non-daemon, stdout/stderr. Azt kapja el a docker log, azt tudja és továbbítja konténer névre és id -re szűkítve a host syslognak, gelf -nek vagy aminek akarod. Az official imagek így működnek. Ha ezen felül valami nem sztenderd elk*#!t logolása is van az appnak, akkor azt sajnos neked kell megoldani valamilyen más módon
[ Szerkesztve ]
-
samujózsi
tag
Nem értesz: a konténerben root vagyok, a /tmp-be írt fájl a host szerint is a root tulajdona.
Ha beállítom a user mappinget a /etc/docker/daemon.json fájlban, akkor már nem.
Ez így alapjáraton (nincs user mapping) elég necces számomra. De valami oka biztosan van, hogy a default szerint a hoston lévő user/group id-ket használja...Ahogy az update-tel kapcsolatos aggályaimat sem igazán. O.K., a base image-ben lévőkkel talán nincs gond, a pull lehúzza és egy restartnál már élhetnek. De mi van azokkal, amiket a build során telepítettem? Azok nem részei a base-nek, így a pull nem hozza a javítást rájuk.
Ha nem követem az általam telepített csomagok minden egyes update-jét, akkor hogyan fognak felkerülni? Mondjuk egy squid hoz magával 10-20 csomagot függőségként pluszban, a base image-en felül. Két build közt, ha egyáltalán van rajta csomagkezelő (többnyire van), akkor minden eddigi javaslattal szembe menve, kénytelen vagyok a csomagkezelő update funkcióját használni két rebuild között.squid - elvileg tud syslog-ba logolni (-s -l kapcsolók), a konténert --log-driver=journal-lal indítom, a logok mégis a /var/log/squid alá mennek. (most láttam, lehet, hogy a /dev/log-ot is mappelni kéne, majd megnézem)
Update: részben valóban a /dev/log mappelése hiányzott, bár így sem kerek a történet, mert miért írja a syslogba is? De ez már lehet, hogy a systemd hülyesége, nem a dockeré.
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Rimuru
veterán
válasz
samujózsi
#180
üzenetére
Az hogy a fajlrendszeren milyen uuid melyik rendszeren milyen userhez tartozik a rendszer dolga. A fajlrendszernek fogalma sincs arrol rendszerben milyen szintu a user csak szamokat (uuid/guid) irkal. (Tehat ami nalad geza az lehet hogy nalan jancsi lenne)
Amugy ajanlom hogy nezz utana az alapoknak is, namespaces, cgroups, stb.
Amugy2, cafoljatok meg ha valtozott, de legjobb tudomasom szerint amelyik user futtatja a dockert az root szintu userre valik, ergo nem less biztonsagosabb, max hamis biztonsagerzetet ad.
Vigyázat, csalok!
-
samujózsi
tag
Cáfolat: user mapping. Működik, ahogy írtam is, csak valamiért nem ez a default.
Ha használom, akkor a konténer rootja (0:0) által a külső, hoston lévő könyvtárban létrehozott fájlok a mappelt user tulajdonába kerülnek -> ami a konténerben root, az a hoston egy mezei user.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Márhogy mi a felszínes??
Baromi eccerű:Ha nincs mapping, futtatsz egy konténert és megnézed a hoston egy ps aux paranccsal, akkor jó eséllyel azt látod, hogy rootként fut.
Ha van mapping, akkor a mappeléshez használt usert fogod látni, míg ha belépsz a futó konténerbe, ott root leszel.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
-
samujózsi
tag
Na, kezdődik...
Bevallottan nem érted, miről beszélek, de máris kezded az arcoskodást.Ui: megmutatnád, hogy a te verziód hogyan, milyen konfiggal működik? Mondjuk egy alap alpine konténerrel, logolva a létrehozás, futtatás lépéseit.
Rögtön előszedem a laptopom és megmutatom, mire gondolok, mit szeretnék látni tőled.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Process owner tekintetében valamit elnézhettem: [link] - legalább egy processzem kénytelen rootként futni (a linken lévő tortúrát kihagytam ugyanis)
De... Ubuntun, alap konfiggal futtatva egy konténert (alpine)
$ docker run -it -v /tmp:/xxx --rm alpine/ # touch /xxx/valami/ # sleep 30# ps xau | grep sleeproot 10878 0.0 0.0 1548 4 ? S+ 11:36 0:00 sleep 30# ls -l /tmp/valami-rw-r--r-- 1 root root 0 dec 27 11:36 /tmp/valamiUgyanez, ha a /etc/docker/daemon.json-ba beírom, hogy { "userns-remap": "dockermapper" } ( a dockermapper usert én vettem fel e célra)
$ docker run -it -v /tmp:/xxx --rm alpine/ # touch /xxx/valamimas/ # sleep 30# ps xau | grep sleep165536 11255 0.0 0.0 1564 4 ? S+ 11:41 0:00 sleep 30# ls -l /tmp/valami*-rw-r--r-- 1 root root 0 dec 27 11:36 /tmp/valami-rw-r--r-- 1 165536 165536 0 dec 27 11:41 /tmp/valamimasHolott a konténerben a második esetben is rootként futott látszólag a touch és a sleep.
Ezt mennyiben váltja ki a konténernek átadott két környezeti változó?Szerk: próbáltam vastagítva kiemelni a lényeges értékeket, de sajnos a kódszínező belerondított.
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
-
samujózsi
tag
Miután én általában a dockerről beszélek, nem egy-egy image-ről.
Ez konkrétan melyik nginx, amelyikről te beszélsz?
Van egy olyanom, hogy maga a konténer ott is rootként fut a fenti mapping nélkül, a paramétereid az nginx-nek szólhatnak.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Nos, igen, ez azt teszi, amire tippeltem: maga a konténer, ahol root processzt futtat, pl. az nginx indító/szülő processze, ott root marad és ha nincs átmappelve, akkor az a host root-ja lesz (a host oldalról ps xau segítségével is látható).
Azok a -e PUID PGID paraméterek csak ennek a processznek a "gyerekeire" vonatkoznak.És mondom: itt a "rugózás" részemről azon megy, hogy miért az a default, hogy nincs saját usere a dockernek (legalábbis ubuntun)? Mert ha már biztonság, abba szerintem ez is beletartozna.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Az update-ekkel kapcsolatos problémázásomra találtam egy elérhetetlen választ (valami admin-magazine.com oldalon, amit nem lehet elérni) és a stackoverflow-n ezt: https://stackoverflow.com/questions/26423515/how-to-automatically-update-your-docker-containers-if-base-images-are-updated
Nem állítom, hogy örültem, mikor megtaláltamPrimadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Elég sokban, de most ha akarnám se tudnám részletezni.
Előtte mindenképp végig akarom nézni a fenti linken lévő válaszokat.
Csak egy kiragadott dolog: ezzel plusz munka van. Ha nincs konténer, akkor ott van készen a korrekt, működő update, itt meg továbbra is úgy értem, nekem kell gányolni, hogy minden naprakész legyen.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
Ezen felül részemről a Docker hoszt-guest kívülröl most egy sandbox, azt művel belül amit akar, kívülről úgyis csak 80,443/tcp van odaengedve. Illetve, részemről, ha külön vasam lenne szervernek, akkor azon natívan futna a Docker, de mivel 1 gép nálam a tűzfal, docker-szerverek + htpc, ezért tényleg indokolt, szerintem
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), de egy link is megteszi. 
Új hozzászólás Aktív témák
Hirdetés
- Jogtiszta szoftverek - 0-24 AZONNALI KÉZBESÍTÉS - GARANCIA - SZÁMLA
- Game Pass Ultimate előfizetések 1 - 25 hónapig azonnali kézbesítéssel a LEGOLCSÓBBAN!
- STEAM-en aktiválható maradék játékok baráti áron! - CSERE IS ÉRDEKEL! !FRISSÍTVE!
- Bitdefender Total Security 3év/3eszköz! - "Most igazán megéri... :)"
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
Állásajánlatok
Cég: ABT Hungária Tanácsadó Kft.
Város: Budapest