2.1. If you are replacing the watermark, save and name the new logo in logo.svg file format.
2.2. If you are removing the watermark, create an empty logo and save and name it in logo.svg file format.
3. Edit the docker-compose.yml file
3.1. On your console, type:docker-compose stop web
3.2. Locate the docker-compose.yml file.
3.3. In the Volumes section, type:- ./logo.svg:/usr/share/jitsi-meet/images/watermark.svg
3.4. On your console, type:docker-compose up -d
Nem tudom jól értelmezem-e, de mintha létre kellene hozzak egy üres fájlt, aminek a neve logo.svg?
Megkerestem a docker-compose.yml fájlt, de azt ha megnyitom, tele van szöveggel, utasításokkal, nem értem, miért kellett megtaláljam. Amit nem értek még, hogy nem találom sehogyan sem ezt az útvonalat: /usr/share/jitsi-meet/images/watermark.svg , mit értek félre?
Hozzászólások
deepl.com
Mindent :D
Ezért: 3.3 as pontban leírja ...
Bár a leírásodból következik, azt se tudod mivel állsz szemben, így azt se tudjuk milyen telepítésed van egyáltalán a jistsiből. Szóval így nehéz lesz segíteni ...
Fedora 38, Thinkpad x280
Fogod a docker-compose.xml (a "recept" a konténer összeállításához) fájlt, és a Volumes részben megmondod, hogy a konténerben a ./logo.svg az mutasson ki a konténert futtató gépen a /ide/tettem/az/uj/logo.svg fájlra. Létrehozod ezt a fájlt, ahogy szeretnéd, aztán jöhet a docker-compose up -d.
nem
egyrészről .yml
másrészről a "
- ./logo.svg:/usr/share/jitsi-meet/images/watermark.svg" azt jelenti, hogy a host working dirjében levő logo.svg -je legyen a konténerben a /usr/share/jitsi-meet/images/watermark.svg4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
Kellett nekem háromszor átírni a mit hol hova miatt :-)
Ja, és ha már yaml, akkor ne felejtsük el figyelmeztetni a kérdezőt, hogy a világ egyik, ha nem a leginkább gusztustalan fájlformátumával van dolga, amiben a sorok elején lévő whitespace-ek száma kiemelten fontos...
Meg hogy ne üres fájlt, hanem üres svg-t csináljon. Bár esélyes hogy ugyanaz lesz a végeredmény, de na.
Én pythonos vagyok, ezt szépnek találom nem gusztustalannak.... :)
IMHO az xml nyitó/záró tagjei nekem gusztustalanabbak. Ám: de gustibus non est disputandum...
Ott látszik, hogy mi mivel tartozik össze, akkor is, ha közben van 1234 sornyi magyarázat/komment...
each his own. számomra ez egyik legszebb config formátum a yaml.
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
Emberi fogyasztásra alkalmatlan. Volt, hogy a kolléga mókolt picit (egy sort kikommetezett, és berakott helyette egy másikat (kivette előle a #-et...)), és órákig lehetett keresni, hogy miért nem működik az a fostorony, ami ebben a nagyszerű formátumban tárolja a paraméterezését (azt a 12 mélységű struktúrába rendezett 1234 darabot...). Ja, hogy ha a #-ot törli, akkor jó, ha felülírja egy szóközzel akkor nem jó... A fejlesztő/szállító természetesen sok magyarázattal látta el a konfigjamölt, úgyhogy még szemmel verni se nagyon lehetett, hogy hol "sántít" a behúzás...
Akkor jött a részemről a huha'nyázás, amikor kiderült, hogy tulajdonképp lehetne xml vagy épp json is, meg akár ini formátum is, nem muß a jamöl... Csak nekik így egyszerű legenerálni a kezdeti fájlt, amihez általában nem kell hozzányúlni...
Dockerfájlok, kisebb programok, alkalmazások konfigolására szerintem tökéletes formátum lehet. Nagyobb dolgokra pedig ott a mariadb, vagy más adatbázis. Az nem a yaml hibája, ha a fejlesztő fostornyot alkot. Avagy: szarból is lehet várat építeni, de az büdös lesz.
Nem beszélve arról, hogy okos ember a többszintű xml-t, illetve más formátumokat is behúzásokkal tagolja az átláthatóság miatt. Fogd fel úgy, hogy ez is ilyen.
Annyiban igazad van, hogy én mindig VsCode vagy más IDE alatt kezelem a yaml fájlokat. Ha nincs ilyen és egy szimpla text editorral kéne vele szarakodnom én is agyfaszt kapnék tőle.
Ha valaki 1000+ darab objektumot akar yaml-ben managelni arra nincs mentseg. De arra json-ben vagy xml-ben se lenne mentseg :D
Plane ha 12 melysegu faban teszi mindezt.
Ahogy irtak erre inkabb valo egy sql vagy nosql tarolas. Szoval ha en kalapaccsal akarom felszelni a tortat nem biztos hogy a kalapacs a szar, amiert nem vag szep szeleteket :D
+1
Bár ha úgy születnek architekturális döntések, hogy a YAML-t könnyebb generálni mint az XML-t, akkor túl nagy elvárásaim nincsenek. :)
Jajaja, bezzeg a "12 mélységű struktúrába rendezett 1234 darabot" XML-ből sokkal könnyebb fejben parse-olni, hát hogyne.
Mellette szól - bár őrült sokat nem segít - hogy az xml-t könnyebben lehet szemmel áttekinthető formára hozni. Meg talán a nyitó-záró tagok miatt könnyebb megtalálni, ha egy sorral lejjebb van a </userData> mint kéne.
A yaml meg alapvetően azon bukik el, hogy pár szóköz ide vagy oda, de valid marad, csak épp nem működik.
Már szerintem.
Ezzel egyetértek, ilyen szempontból sokkal hibatűrőbb az XML, de ekkora adathalmaz emberi feldolgozásakor (még ha van is túlzás a számokban) nem a formátum lesz a szűk keresztmetszet.
Mondjuk más egy konfigurációs fájl, meg más egy adatbázis. Másra való.
Konfiguráció általában olyan, amit egy backend alkalmazás csak olvas, nem változik futás közben.
Ha meg igen, akkor az user által megadható adat, és akkor tárolható lenne adatbázisban - mert akkor előjön, hogy minden user esetleg mást állíthat-e be, ki állíthatja egyáltalán be (jogosultságkezelés) stb.
Statikus, csak olvasható konfigurációt mindenképpen valamilyen szöveges fájlba tennék, nem adatbázisba.
Ebben igazad van, bár tulajdonképpen nem mond ellen annak, amit írtam. :)
Szerintem egy 1000+ változót tartalmazó konfigfájl már bőven nem optimális, de ha valami okból szükség lenne rá, nincs az az Isten, hogy kézzel hozzam őket létre. Azt gondolom, hogy ennyire részletes konfigurációra akkor van szükség, ha ténylegesen létezik/létezhet is legalább 1000+ különböző permutációjú instance az adott alkalmazásból. Ekkor viszont generálni kell a konfigfájlokat, nem kézzel szerkesztgetni.
Én ebből a yaml rossz, xml jó vitából csak azt látom, hogy a configuration management problémákat rossz absztrakciós szinten közelítjük meg. Onnantól kezdve, hogy van rendes config mgmt folyamat, már majdnem lényegtelen, hogy milyen formátumban tárolódik a tényleges adat. "De mi van, ha kézzel belekommentelek valamit a fájlba, és rossz helyen lesz whitespace, és emiatt bugos lesz a prod", te jó ég, mintha egy időutazás lenne ez a thread :)
Azért a fentebb emlegetett 12 szintes, csillió key-value párost tartalmazó konfig esetében már bőven elgondolkodnék egy sqlite-on, már csak azért is, hogy elvegyem a kedvét a plaintext-editor huszároknak, akik később ticketet nyitnak a vendornál, mert nem sikerült megszerkeszteniük egy txt fájlt. :)
Konfiguráltál már mondjuk Java EE alkalmazásszervert?
Ott is rengeteg subsystem rengeteg dolgát lehet konfigurálni, mégis plain text.
És működik. 20 éve is működött.
Ez oké, de ennek az a módja, hogy a kolléga kézzel "mókol picit" a fájlban, látszólag a fájlformátum ismerete nélkül, random karaktereket pluszban beleírva meg kitörölve? 20 éve működött, igaz, de nem haladtuk ezt meg? :)
Az éles és a teszt konfig között egy sorban, egy hash-nek az értéke volt a különbség. Erre az volt a kézenfekvő megoldás, hogy mindkét sor szerepel az egyébként yaml formátumú settings fájlba, és ami nem kell, az kap egy #-ot a sor elejére, ami meg igen, az meg nem. Ez azoknál, akik tudtuk, hogy ez egyébként egy yaml, annak minden f..ságával megfelelő is volt - sajnos nem mindenkinek, és mivel korábban az érintett kolléga sem tolta el (napi szinten kellett oda-vissza állítgatni...), de ő a reggeli átkonfigurálás után nem volt elérhető, így csak a sz..ás maradt, mire kiderült, hogy sikeresen elcsúszott az adott sor...
Napi szinten kapcsolgatott teszt/prod ugyanabból a config fájlból, kézzel, ez nekem egy borzasztó antipattern.
prod klónoz, teszten konfig átír, tesztelő örül. Antal vagy sem, így ment - ettől még a yaml kézi szerkesztése ordenáré copások melegágya...
Hiszen ezt mondom én is, csak kibővítettem mindenféle formátumra. Konfigfájlt nem baszkurálunk kézzel, vagy ha igen, azt verziózva, megfelelő change management folyamatok mentén.
Ha a saját hobbiprojektemre is ki tudok építeni sokkal megbízhatóbb folyamatot a kézi editálásnál, akkor egy üzletileg kritikus szolgáltatásnál szakmai igénytelenség ennyire letojni a kérdést.
Viszont VALAMIT baszkurálni fogsz kézzel. Legyen ez egy Gitlab CI/CD variable szekció, legyen ez Azure Devops variable, legyen ez egy dotenv fájl, bármi. Amit verziózol, az mindenképp valamilyen fájl. És akkor az a de facto konfigurációs fájl, akkor is, ha transzformációkon átesik, amíg a szoftver értelmezni tudja. Szóval magát a konfigurációt kézzel baszkurálod így is, csak esetleg még utána átesik pár folyamaton, mire a szoftver által is emészthető lesz.
Hát, a fájlban (valamilyen fájlban) valaki kézzel fog mókolni. Legyen ez konfig management leíró, legyen ez SQL script, amiből az SQLite fájl épül, legyen bármi más.
Mert szerintem a hangvezérléssel verziókezelt konfigmenedzsmentet még nem találták ki.
Mindennek a vége *valamilyen* fájl szerkesztése, lehetőleg úgy, hogy verziókezelt, reviewzható legyen. Erre épül az egész IaC.
Hogy ez a fájl közvetlenül a konfiguráció, amit utána csak el kell helyezni a fájlrendszeren, vagy egy másmilyen szintakszisú leíró, amiből generálni kell, az tök más kérdés. És minél kevesebb réteg van kihagyva, annál kisebb a hibalehetőség (a két szintakszis közötti transpilerben is lehet bug).
valaki --> valami :)
Most akkor olvasd el a kontextust, fentebb már arról szól a fáma, hogy emberünk ugyanabból a konfig fájlból lépkedett tesztből élesbe, és viszont, kikommentezett sorok cserélgetésével. Szerintem itt bőven nincs szó verziókezelésről, review-ról, akármiről. :)
Az adott konfig állomány más, jogos és érthető okból _nem_ volt verziókezelőbe rakható. Sajnos. By design sz@r volt az egész, de nagyon nem lehetett ugrálni, mert se a beszállítóz nem lehetett bacogatni, se a működést nem lehetett veszélyeztetni - és ezen az a pár órás hibakeresés és anyázás sem igazán változtatott, amibe a problémát okozó szóköz megtalálása került...
Az a valami is csak egy kézzel mókolt fájlból tudja, hogy mit kell mókolnia.
...amit lehet validálni, lehet template-ekből generálni, lehet rá egy UI-t csinálni, és még megannyi hunglish buzzword, amit mind arra találtak ki, hogy az ilyen PEBKAC hibákat kivédje. :)
Igen, XML-t például nagyon jól lehet validálni. YAML-re van ilyened...? Ugyanis az adott fájl mindkét "állapotban" valid, érvényes beállításokat tartalmazott, csak épp az egy szinttel beljebb/kintebb került sor miatt az azt használó kód nem működött. UI-t meg csináljon ilyenre az, akinek... megfizetik - a céget, amelyik ezt odatalicskázta, na azt nem egy ilyen UI megvalósításáért fizették, úgyhogy nem volt hozzá még tervben sem...
Ezért tudom, hogy kapni fogok a pofámra, de YAML Lint?
Mégegyszer... Mindkét állapot logikailag helyes/valid konfigurációt ad. Hogyan különbözteted meg őket? (azaz az abc=123 szerepelhet a struktúra két egymás alatti szintjén is - tudom, ez így más okból sz...r, de nem én írtam a kódot, ami megemésztette)
séma nélkül (yaml-ban nincs...) csak szintaktikát tudsz ellenőrizni, szemantikát nem
Gábriel Ákos
már hogy ne lenne? https://asdf-standard.readthedocs.io/en/1.5.0/schemas/yaml_schema.html
vscode-ban is csak így szerkesztek yaml-t.
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
Oh wow, szóval a "szabvány" elvileg megvan, ma is tanultunk valamit. Mondjuk én még nem találkoztam olyan projekttel aki adta volna a yaml-jaihoz a sémát is.
Gábriel Ákos
https://www.schemastore.org/json/
Van rengeteg elérhető JSON séma.
Szerkesztői támogatás is van hozzá rendesen: http://json-schema.org/implementations.html#editors
Az, hogy a random app fejlesztők nem figyelnek erre, az egy dolog.
Na, csak volt értelme a topicknak, köszi.
Miért ne lenne yaml-ben séma? A yaml egy JSON superset, és JSON-höz van séma.
Van. Pythonhoz: Schema, Cerberus, jsonschema (igen, igen, ne akadjunk fenn a json-on, bármihez jó kb)
Kb. negyed órás meló volt megcsinálni egy scriptet, ami megjelöli a PR-okat, ha rossz formátumú config fájl van benne. Ha ekkora befektetést nem ér meg, hogy ne kelljen órákig debuggolni, akkor nem is fontos az a rendszer. :)
És ez mind igaz egy XML-re is, csak éppen nem olyan fancy a UI, hogy mondjuk wizard alapú legyen.
Te hány olyan konfig menedzsment eszközt ismersz, ami:
1. verziózott/auditálható
2. reviewzható/engedélyezhető a változás más által
3. nem fájl alapon dolgozik, hanem fancy UI-ja van, ami validál és kivédi a PEBKAC hibákat?
A yaml is plain text :D
Most nem azert de szerkesztettel Te mar kezzel websphere config-okat? Egy sima kiszolgalohoz vagy 40 xml allomanyt kell szerkeszteni. Nem is javasoljak, klikkolgass inkabb a webes UI-n, mert akkor nem baszol el semmit sem (az UI backendje majd updateli neked mint a 40 file-t) :D
Amugy meg egy ekkora yaml file szerkeszteset meg mar tuti nem direkt fileszerkesztessel oldanam meg, hanem egy program/ui/akarmi/websphere-ui-like generalna le. De a legegyszerubb megoldas egy yaml/json schma hasznalata. Igy szol az ide ha nagyon nagy hulyeseget csinalsz, sot akkor is ha invalid lesz a yaml.
szoval most arrol beszelunk, hogy tobbezer soros allomanyban - amire tenyleg kurvara nem a yaml a legjobb adatszerkezet - kezzel mokol valaki, ezert szar a yaml??? :D
Akkor ha biciklivel akarok szantani, a ketkereku a szar, mert nem huzza az eket ugy ahogy akarom :D
Mondjuk tegyük hozzá, hogy a Websphere és a többi ilyen hasonló Java EE alkalmazásszerver az valójában nagyon sok rendszer egyben, azaz azért ilyen bonyolult a konfigja, mert egyben webszerver, message queue, egyfajta névszerver (JNDI), konténer-runtime és társai. Ha mondjuk ezeket szépen szétválasztod, akkor is ugyanilyen bonyolult lesz a konfiguráció, csak nem egyben, hanem külön-külön konfigolod a message queue szervert, a névszervert, a konténer runtime-ot stb. Ugyanúgy sok kis fájlod lesz, csak nem mind egy alkalmazás keretén belül.
senki sem használ normális szerkesztőt, ami ezeket lekezeli?
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
A vi pl. tökéletes erre, x-et nyomok a #-ra, és a kommentezendő sor elejére meg i#, escape, :wq, és rendben vagyunk... De leginkább nem szeretnék olyan állományokat látni/használni, ami a whitespace-ek kritikus fontosságú elemei a nyelvnek.
Szégyen,hogy VsCode-dal szerkesztem?
Félreérted a volume leíró működését, pont fordítva van. A konténeren belüli fixen adott path-ra bindolja rá a konténeren kívüli, a Compose leíró mellett lévő logo.svg-t a példa.
Amúgy nem, a konténer összeállításához a "recept" az a Dockerfile. A compose az a konténer runtime környezetét írja le.
Gábriel Ákos
Így értettem... (kell nekem kialvatlanul kommentelni...)
Köszönöm szépen mindenkinek a segítséget.
"https://hunvagyok.hu "