- XPEnology
- Videó stream letöltése
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Sweet.tv - internetes TV
- Otthoni hálózat és internet megosztás
- Xiaomi AX3600 WiFi 6 AIoT Router
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Milyen switch-et vegyek?
- Linux kezdőknek
- Hálózati / IP kamera
Új hozzászólás Aktív témák
-
samujózsi
tag
Nézegetem a docker hálózatkezeléssel kapcsolatos dolgait és egy dolog máris nem tiszta: ha kérem tőle, hogy publikálja a konténer által használt portokat, akkor ezeket ő berakja a netfilter (iptables) szabályok közé úgy, hogy minden, a hostnak a megadott portjára érkező csomag menjen tovább a konténerbe. Az csak nekem furcsa, hogy nem lehet paraméterezni, hogy milyen IP-kről fogadjon csomagokat ezeken a portokon?
A közös kernel miatt a konténerben nem tudok új szabályokat beállítani.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz instantwater #114 üzenetére
Előbbi. Utóbbi egyértelmű, nem nincs is köze a netfilterhez.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz instantwater #116 üzenetére
Miután a docker belepiszkál a netfilter szabályokba, ha publikálom a portjait, szerintem valahol hozzá tartozik.
Az alapfelállás, hogy minden tiltva van.
Amikor indítoknegy konténert, ami tcp/udp szolgáltatást nyújt és a létrehozásakor a -p vagy a -P kapcsolót használom, akkor mindenkinek megnyitja azokat a portokat, amiket publikál, nem tudom szabályozni, hogy mely IP-kről legyen elérhető.
Ha nem használom ezeket a kapcsolókat, akkor viszont elég macerás összekötni a netfilter szabályokat a.konténer indításával/leállításával.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Ha jár még erre valami kóbor lélek: ugye az az általános mondás, hogy egy konténer-egy service.
De... mi van, ha egy olyan webes alkalmazást futtatnék, ami használ adatbázist is?
Egy nginx, egy mysql konténer és valahogy megoldom köztük a kommunikációt?
Vagy ilyenkor mind mehet egy konténerbe?
Ha külön, akkor hogy szokás megoldani a konténerek közti kapcsolatot? Úgy vettem észre, az ip cím random, így elég nehéz akár név, akár ip cím alapján összekapcsolni őket, nem?Más: a konténerekben futó szoftver update-elését hogy szokás megoldani? Egyesével belépek és futtatok egy a konténer op.rendszerének megfelelő update-et? Vagy hogy?
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz instantwater #121 üzenetére
No várj, sima restartnál nem vész el semmi, csak ha újragenerálom az image-et, nem?
(docker run ... ; docker exec xxx /bin/sh ; ... itt létrehozok, módosítok ezt-azt ; docker restart xxx - megmarad amit az első exec alatt módosítottam)Ezt az update-elést továbbra sem értem: ha a felhasznált image létrehozója/kezelője nem update-eli, akkor akár a végtelenségig futhat nekem egy már ismert explitokat tartalmazó rendszer? Mert ilyen alapon mondjuk elkészítek mindent magamnak, de egy alaprendszer, például egy alpine akkor is kell. Ha ebben lyukas a libc, akkor az összes konténerem lyukas lesz, míg a hivatalos image-ben be nem foltozzák. Nem gáz ez így?
Viszont az is gondot jelenthet, hogy ha mondjuk (csak példa, de az életből ellesve ) adatbázis szerverem fut konténerben és upgrade-elni kell az adatbázist. Ugyanis ez esetenként járhat az adatbázis struktúrájának változásával, amit egy közvetlenül az op.rendszerbe telepített RDBMS upgrade procedúrája általában vagy elintéz automatikusan vagy le van írva a doksiban, hogy mikor kell futtatni ezeket az upgrade script-eket az upgrade során. De egy docker konténernél, ahol nincs igazán upgrade eljárás...
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz instantwater #121 üzenetére
Közben lejárt a szerkesztési idő: ha sok adatbázisom van, azokat a fentiek értelmében önálló konténerben kellene futtatni ezek szerint? (ezt kicsit erőforrás pazarlásnak tartom, legalábbis néhány esetben)
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz samujózsi #123 üzenetére
Illetve ehhez kapcsolódva: ha olyan szolgáltatást akarok üzemeltetni, ami az adott gépen futó konténereknek szolgáltat (mondjuk egy syslog-ng service), akkor annak a portjait odaadom a localhost-nak és a többi konténerekből a 127.0.0.1 megfelelő portjára hivatkozom?
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Bocs, félálomban írtam: a host saját lo interface-ére gondoltam a 127.0.0.1 kapcsán. Mert ha csak azon hallgat az adott port, akkor kívülről nem lehet elérni.
Az továbbra sem tiszta, hogy ha egymástól független alkalmazáscsomagoknak adnék közös szolgáltatást, azoknak hogyan illene ezt összerakni.
Mondjuk syslog szerver vagy pl adatbázis szerver, amiben a különböző szolgáltatások eltérő sémába dolgoznak közös szerveren.Restart: konkrétan kipróbáltam a fentieket, mielőtt leírtam:
docker run alpine
Kaptam egy promptot.cd root
touch x.x
ctrl-ddocker restart xxxx (fenti konténer)
docker exec -it xxxx /bin/sh
ls -l root
És ott az x.xLehet, hogy hibás az ubuntu 18.04 docker csomagja, de nálam így működik.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz instantwater #128 üzenetére
Köszi, csak... nem igazán ez volt a kérdésem lényege. Inkább arra vonatkozott, hogy hogyan illik megoldani, ha egymástól független alkalmazások/konténerek rendelkeznek közös ponttal, amilyen pl egy több sémát tartalmazó adatbázis vagy mondjuk egy syslog szerver. Ilyenkor a compose nem játszik, de valahogy mégis kapcsolódniuk kellene egymáshoz.
(Utcán vagyok, ha nem felejtem el, otthon próbálok valami ábrát készíteni, hátha érthetőbb lesz)Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
A best practice számomra az, hogy a közös pontot a futtató hoston a 127.0.0.1 címen publikálom és csak a portot kell megjegyezni, a host asszem, elérhető valamilyen névvel. Szóval kb amit írsz. Csak azt hittem, van valami más, "szabványos" mód is.
Még nem jutottam el oda, hogy beizzítsam a notebookon a konténereket. Próbálok majd logot készíteni a konténer létrehozásáról és a restartokról. Semmi szándékos perzisztencia nincs benne.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Hát ennél restartabb restartot már nem tudok produkálni.
Ubuntu 18.04, frissen telepítve egy virtuális gépbe, de ennek nincs jelentősége, csak annyi a lényeg, hogy semmi más nem történt, csak egyapt install docker.io
docker run -it --name alp1 alpine
Itt kapok egy root promptot a konténerben, ahol létrehozok egy addig nem létező fájlt:/ # touch root/root.txt
Ctrl-D, ezzel leáll a konténer.docker start alp1
docker exec -it alp1 /bin/bash
Ismét a konténerben vagyok, a /root/root.txt még mindig létezik.
docker stop alp1
docker start alp1
docker exec -it alp1 /bin/bash
A root/root.txt megvan.
Reboot a docker hostján.docker start alp1
docker exec -it alp1 /bin/bash
A fájl még mindig megvan.
Akkor most mi van?
Ennél alaposabb újraindítást már nem tudok összehozni.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz instantwater #133 üzenetére
Most csak az első mondatra reagálva (ébredés után megpróbálom megérteni a többit is )
Akkor ti itt milyen restartról beszéltetek?
Nem rebuildről?
Mert az tiszta, hogy ha saját app fejlesztéséhez használom, akkor minden módosítás után rebuild, és ekkor valóban eltűnik minden változtatás, de ez nem restart.
De én kész szoftvereket üzemeltetnék, amiket változtatni nem akarok élesítés után, így a rebuild ritka esemény lenne.És itt egy kicsit visszatérnék az eredeti kérdéshez is: készítek mondjuk egy nginx konténert. Kiderül valami zero day exploit.
A fejlesztők villámgyorsan befoltozzák.
De hogyan, mennyi idő alatt fog eljutni ez a javítás a konténerembe?
Mert ha nincs konténerben, akkor előbb az nginx forrás lesz kijavítva, ezt követően az alap OS csomagja, a disztribúció fejlesztői/maintainere által, de a docker image?
Ha nem dockerben fut, akkor (debian alapon) apt-get update && apt-get upgrade és kész. Ezt naponta megcsinálom az éles gépeken. De a dockerbe, ha ott nem illik ilyet csinálni, akkor hogy, pontosabban mennyi idő alatt jut el?Ui: gondolom, feltűnt, hogy csak ismerkedek a technológiával. Azt egyébként kár hangsúlyozni ennyiszer, hogy ez nem vm, eleve közös a kernel, nem is fut benne más, csak a legfontosabb alkatrészek, ettől kezdve kevés köze lehet virtuális gépekhez.
Ilyenkor kezdek rájönni, hogy az élőszóban folytatott kommunikáció akár gyorsabb is lehet, mint az írott
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz instantwater #135 üzenetére
Az nginx példa volt, helyettesíthető bármivel. A lényeg, hogy egy alaprendszeren én tartom kézben az update-eket, míg egy konténer esetében van egy plusz függőség, az image készítője. És tökmindegy, hogy egy hivatalos nginx-ről beszélünk vagy egy magam buildelte alpine alapú tákolmányról, ami nginx-t futtat. Utóbbi esetben az alpine készítője a plusz "réteg".
Nálam ennek nincs jelentősége, de egy netre kirakott szolgáltatásnál... nem aludnék nyugodtan, ha értesülnék egy aktívan használt exploitról és várnom kellene még arra is, hogy az image-ek készítőin átjusson.A szóbeli kommunikációval csak azt akartam mondani, hogy itt litániákat írok olyasmiről, amit munkahelyen, kollégákkal húsz másodperc megtárgyalni annak, aki nem olyan femedékeny, mint én.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz instantwater #133 üzenetére
Nem állítom, hogy most nem voltam felszínes, de átfutottam újra azon amit írtál.
Azt hiszem, ott van köztünk a nézetkülönbség, hogy te fejlesztő eszközként tekintesz a docker konténerre, én meg egy szimpla biztonsági rétegként, mint mondjuk a FreeBSD jail-ek.
Amikor elkezdtem nézegetni a dockert, az volt a cél, hogy egy szerveren futó akármilyen szolgáltatás (DNS, proxy, saját gyártású web app, RADIUS stb.) kellőképp el legyen szeparálva a szervertől, viszonylag könnyen tudjam menteni, mozgatni.
Erre elvileg megfelel egy, max. két kvm guest valami lájtosabb op.rendszerrel, plusz némi bűvészkedés a host-on a netfilterrel/routinggal.
Ezt viszonylag könnyen kézben tudom tartani, tudom menteni, adott esetben akár más gépre átvinni nagyobb macera nélkül.
Csak láttam pár éve, hogy kezdenek divatba jönni ezek a konténeres megoldások, mint lxc/lxd és a docker és egy ismerős anno azt javasolta, hogy hagyjam a fenébe az első kettőt, mert csak a szívás van velük, tanuljam meg a dockert.
O.K., megtanulom, de lásd fent: mi a biztosíték rá, hogy a dockerben ugyanúgy és ugyanolyan gyorsan megjelennek a security update-ek, mint egy komplett, virtuális gépként futtatott linux esetében?
(és akkor csak az official image-ek vannak használatban, a ki tudja, ki által összetákoltakat nagy ívben kerültem - ha azokat is belevesszük a buliba, akkor már a konténert sem tudom megbízhatóként kezelni)Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
válasz instantwater #141 üzenetére
És ez már sokszor igazolódott...
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Vajon az normális, ha egy kvm guestben (ami NAT-olt interface-t használ) indított docker konténer (most épp nginx, de próbáltam egy mezítlábas alpine konténert is) nem lát ki a netre?
Hogy a publikált portok nem érhetőek el a fizikai vasról?Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
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
-
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
-
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.yml
parancsot.
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
-
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
-
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
-
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 -l
118
Ez 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 upgrade
parancsot, 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
-
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
-
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 sleep
root 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/valami
Ugyanez, 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 sleep
165536 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/valamimas
Holott 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
-
-
-
-
samujózsi
tag
válasz stickermajom #208 üzenetére
Naprakészt ne úgy értsd, hogy amint bekerült a bugos szoftver forrásába a patch, már ugrik is fel az éles vasra.
Azért ennek jobb helyeken megvan a maga sorrendje.
De azt, hogy valami ismert lyuk hetekig tátong egy publikus szerveren, mert rajtam kívülálló ok miatt esélyem sincs felrakni a javítást... és sajnos van ilyen is...Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Egy kis trollkodás: [link] - google-n keresgélve találtam.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
szerintem ezt gondold àt újra, mert kb semmi köze ahhoz, amit írtam... épp azt írtam, hogy egy ilyen update/patch telepítésének megvan a maga rendje. Általában. Azért volt már olyan, ami akkora lyukat javított, hogy teszt nélkül fel kellett zavarni az éles szerverre.
IPS/IDS meg nem igazán arra van, hogy helyettesítse a biztonsági patch-ek telepítését.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
No, ez már érdekesebb: azon a vason, ahol most egy kvm-ben fut pár service, felraktam egy alpine alapú konténerbe egy squid-t, a konfig fájlt kimásolva a kvm-ből, hogy amennyire lehet, egyforma konfiggal fussanak.
Ha a kvm-ben futó proxy-t használom, akkor a négy magos CPU egy magja 100%-on pörög a kvm processzen dolgozva, plusz egy másik magon 40% körül egy vnet-xxxx processz.
Ha a konténerbe pakolt proxy-t használom, akkor egyedül a konténer eszi a processzort, max. 60-70%-on.Ez az a pont, ahol kezdek elgondolkodni rajta, hogy esetleg nekem is megéri a macera a konténerekkel...
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
tag
Hát ha sértetlen a rendszered ÉS a ps kimenetében a konténer egy privilegizálatlan user nevében fut, akkor pontosan annyit tud tenni, mint bármely más, nem admin/root jogú user.
------------------------------------------------------------------------------
A gond ott van, hogy alaphelyzetben a konténer processz is root jogú, ráadásul az összes joggal rendelkezik, nincs korlátozva (lásd man 7 capabilities).
Ha be van zárva kellőképp, akkor sem lehet 100%-os biztonsággal állítani, hogy ebből nem fog kitörni senki (mert szerintem csak idő kérdése, előbb-utóbb mindig találnak valamit, ahogy asszem idén tavasszal volt is valami ilyen gond a dockerrel), de akkor legalább elmondhatom, hogy a magam részéről mindent megtettem a biztonság érdekében.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM