/MEGOLDVA/ Jitsi logó eltávolítása leírás alapján.

Web, mail, IRC, IM, hálózatok

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?

  • 765 megtekintés

( _ventura_ v | 2023. 01. 22., v – 13:28 )

Szerkesztve: 2023. 01. 22., v – 13:28

 mit értek félre?

Mindent :D

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. 

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 41, Thinkpad x280

( zeller | 2023. 01. 22., v – 15:25 )

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.svg

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.

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...

É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...

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

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.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

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

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.

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 :)

Statikus, csak olvasható konfigurációt mindenképpen valamilyen szöveges fájlba tennék, nem adatbázisba.

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. :)

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... 

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.

Konfigfájlt nem baszkurálunk kézzel, vagy ha igen, azt verziózva, megfelelő change management folyamatok mentén.

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 :)

lehetőleg úgy, hogy verziókezelt, reviewzható legyen. Erre épül az egész IaC

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...

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...

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.

YAML-re van ilyened...?

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.