- Fejhallgató erősítő és DAC topik
- Milyen egeret válasszak?
- OLED TV topic
- Megérkezett a Razer új csúcsegere, a Viper V3 Pro
- Azonnali informatikai kérdések órája
- 5.1, 7.1 és gamer fejhallgatók
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Projektor topic
- Hobby elektronika
- Exkluzív funkcióval tenné vonzóbbá az ARM-os PC-ket a Microsoft
Hirdetés
-
Megjelent a Moondrop audio-fókuszú telefonja Kínában, lesz globális verzió is
ma Középkategóriásak a specifikációk, ha az SoC-t és a kamerákat nézzük, de itt a kiemelt figyelem a hangra összpontosul, abban pedig egyedi dolgokat kínál a készülék.
-
Játékosbarát frissítést kapott az ASUS ROG Ally
ph A vállalat engedélyezte az AMD Fluid Motion Frames eljárását.
-
Lopják az LG akkutitkait
it Inkább licenceli ezentúl az akkumulátoros szabadalmait az LG Energy Solution, mert túl sok a jogsértés. Az LGES mellett az UMC is az autóipar egyre lassuló keresletére figyelmeztet.
Új hozzászólás Aktív témák
-
haddent
addikt
válasz szuszinho #236 üzenetére
Ahogy írta a kolléga, nginx többek közt erre is kiváló: reverse proxy. Ráadásul ha esetleg veszel 1 domaint ami nem vészes, akkor nem portokkal meg ip -kel kell szenvedni, hanem emby.te.hu, cloud.te.hu stb. Sokkal kifinomultabb ráadásul biztonságosabb is, https/ssl endpoint stb.
Ahogy samujózsi írta, külön ip -re is kötheted, de mindenképp az első megközelítés az elegáns. Valamennyire nézz utána szerintem, hogy az alapok, működési elv legyen meg, utána szívesen segítek és vagyunk itt páran akik nem először vágnának bele, ha elakadnálPl.:
https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
https://www.scaleway.com/en/docs/how-to-configure-nginx-reverse-proxy/[ Szerkesztve ]
-
haddent
addikt
válasz samujózsi #238 üzenetére
Az nginx fog listenelni a 80, 443 porton (80 -> 443 átirányítás, ssl/https miatt ugye), és a http(s) requestből eldönti, hogy hova irányítson át. Tehát a gyakorlatban best practice szerint úgy néz ki, hogy:
kliensek --- (https app protocol, 443 port, fqdn) --- > nginx (ssl bontás, fqdn értelmezése, 80 -> 443 redirect, headerek csatolása stb..) ---- http (vagy https, de itt már nem indokolt az ssl) ---> valódi szerver
Vagyis a kliensek az nginx -szel beszélnek és az nginx beszél az aktuális szerverekkel. Kívülről biztonságos, belülről akár sima http is lehet, így különböző layer7 analizálók is benézhetnek a forgalomba, it security stb.
Nagyjábol ilyen elven lehet egyetlen ip címen hosztolni lényegében végtelen számú domaint, szervert.
Pl. egyszerűség kedvéért legyen a publikus cím 1.2.3.4 és van egy Teszt.hu meg egy Valami.hu cím, aldomainekkel. Ekkor
Teszt.hu meghívod a böngészőben, resolveolódik 1.2.3.4 -re, de a requestben benne lesz, hogy te "Teszt.hu" címen keresed, nginx fut 80,443 -on, elkapja, látja a Teszt.hu, ezért a 192.168.1.123:1234 szerverre továbbít, tetszőleges, bármilyen porton (így egy szerveren futhat akár 100 másik nginx, apache bármi is, más-más portokon)
Valami.hu -t meg mondjuk a 10.20.30.40:80 -ra, emby.valami.hu meg a 10.20.30.41:8096 -ra.
Ebből kívülről semmit nem fogsz látni, zökkenőmentes, https kapcsolatod lesz.
Kb így lehetne jellemezni konyhanyelven rövidenA felhasználóbarát kényelmen óriási előnye, hogy igazából csak 80,443 van nyitva az internet felé, nem kell 5-10-100 portot megnyitnod
[ Szerkesztve ]
-
haddent
addikt
-
haddent
addikt
válasz instantwater #245 üzenetére
Azta, menő cucc. Mondjuk ez meg elég erős egy reverse proxy -hoz (mindenhez, de van amihez indokolt/nem tudod máshogy):
/var/run/docker.sock:/tmp/docker.sock:ro
Okéro
, de ehh..[ Szerkesztve ]
-
haddent
addikt
válasz instantwater #248 üzenetére
Ja félreérted, egyáltalán nem azt vonom kétségbe, hogy legit a cucc, egyértelmű, hogy az. Csak én pl. egyetlen esetben mountoltam be a docker sockot, a Jenkins CI alá, hogy saját magát újra tudja rántani a konténereket. És csak lokál elérhető és így is elég szürke terület, szerintem.
De valamit valamiért, ahogy mondod. Én személy szerint inkább írom vimmel a kis nginx configjaim, bár a múltkor napokat szotyiztam, hogy ssllabs teszten A+ minősítést kapjon a domainem minden tagja
Néha scannelgetnek meg próbálkoznak egyébként nálam pl, de pfSense + egy hányásnyi IPS szabály azért elég szépen pofánveri őketsamujózsi de, épp ez a "baj" (ami nem baj, csak ésszel..). RO -ban max reconnaissance lehet belőle, de rendes mount esetén már elég ocsmány dolgokat lehet, pl ugye többek közt bemountolod egy új konténerbe a host rootot rw -ben
[ Szerkesztve ]
-
haddent
addikt
válasz szuszinho #253 üzenetére
Elöljáróban: ne értsd félre, nem fölényeskedés/kioktatás, épp ellenkezőleg, viszont sokkal szebben, részletesebben leírják mások direkt cikknek szánva, mintha itt elkezdek/ünk hadoválni.
Szóval kérlek nézz kicsit utána a DNS működésének, pl https://ns1.com/resources/dns-types-records-servers-and-queriesDe röviden/konyhanyelven megint: a "duckdns.org" egy TLD, az xyz.duckdns.org már egy subdomain A rekord, ami a te ip címedre mutat. A qbittorrent.xyz.duckdns.org nem mutat sehova, mivel nincs regisztrálva. Ehhez a DNS rekordokat kellene tudnod szerkeszteni, amit nem fogsz tudni duckdns esetén.
Tippként pár "gány" megoldás, ami működhet: xyz.duckdns.org/qbittorent (ez sok esetben körülményes, sok app úgy van megírva, hogy kb. csak rooton tud futni folderben nem, stb.), xyz-qbittorrent.duckdns.org (és minden másra külön-külön subdomaint kérsz)
Az elegáns és profi megoldás (olyannyira, hogy tényleg cégek, mindenki IS ezt és így használja, nincs feljebb) az lenne, ha lenne egy fizetős (de van 1-2 ingyenes is, pl .tk) TLD domained, pl xyz.hu és szerkeszthetnéd a rekordokat, ekkor tudsz létrehozni A, CNAME stb. rekordokat és fel fognak oldódni a címedre
Javaslatként én a Google Domains szolgálgatást javasolnám, nekem pl. egy .org címem van, valami éves szinten 3000Ft kb, lehet API -val frissíteni az IP -t (ergo dynamic dns szolgáltatás is egyben) stb.[ Szerkesztve ]
-
haddent
addikt
válasz szuszinho #255 üzenetére
Az egyszerűbbel kezdek: azonos portot használó konténer esetén átmappeled. Pl.: 81:80, 82:80, így a hoszton (és az nginx konfigban) 81 és 82 portra irányítasz.
A valami-xyz.duckdns.org, valami2-xyz.duckdns.org stb.. jó tesztelgetni, viszont arra figyelj, hogy ugye nyilván mindegyikhez külön (letsencrypt) cert fog tartozniA másik, letsencryptes kérdésed nem igazán értem, illetve hát nincs konkrét kérdés/probléma. Ha elakadsz dobd fel valahova a konfigot, meg hogy mit szeretnél elérni, mi nem megy stb
-
haddent
addikt
válasz szuszinho #257 üzenetére
Persze. Illetve kivétel, ha mindent, összes konténert egyetlen compose -ba összerakod, akkor ki sem kell mappelni semmit. De ezt nem ajánlom.
Ehhez látnom kéne vagy a config fájlt vagy akár (lehetőleg) "élőben" a dolgot, nem teljesen értem hol akadsz el, ill. én nem használtam ezt az egyszerűsített nginx image -t amit itt linkeltek a srácok, gyárit használok.
De elméletben a képlet annyi, hogy mindkét duckdns mutasson az ip -dre, az nginx pedig figyeljen mindkettőn, egyiket ide másikat oda proxyzva
-
-
haddent
addikt
Nem, sőt! Egy compose yaml fájl egy stackhez tartozik. Egy stackben érdemes egy - egy teljes szolgáltatást üzemeltetni (pl.: esetedben a fényképalbum, a web szerver és az sql adatbázis), de több különbözőt nem. Tehát már egy nextcloud meg a fényképalbum meg egy emby nagyon keszekusza csúnyaság lenne egyben.
Teljesen mindegy hova rakod a yaml fájlt, rajtad áll a felépítés, ízlésed szerint hozd létre a struktúrát.#403: Na pont ezért jó egy stackbe rendezni az egy szolgáltatás elemeit, mert stacken belül container név resolvolodik belülről, azaz a fényképes appodban csak annyit adsz meg, hogy "db" vagy "database" vagy "mariadb", épp ahogy elnevezted a yaml fájlban a mariadb konténert Plusz így nem kell bindolni pl a mariadb portját kifelé, sőt el sem érhető kinntről (kinnt alatt a stacken kívült értem, tehát akár magát a hosztot)
Kicsit olvasgattam a hsz -eket, szerintem kicsit abuseoljátok a macvlant. Nem gondolom indokoltnak egyetlen említett esetben sem. Kicsit ízlés / best practice kérdése is, de szerintem a legelegánsabb a fentebb leírt módon minden szolgáltatást 1-1 stackbe összegyűjteni, csak az abszolut szükséges bindokat megtenni (ez jellemzően egyetlen port, legtöbbször ugye egy 80/443), majd egy nginx reverse proxy mögé rejteni mindent és a WAN oldalról is kizárólag 80/443 engedni
#417: miért szeretnéd ezt? Illetve a lan és a bridge ugyanaz "www" (azaz WAN?) -hoz pedig sehogy, ahhoz te magad sem csatlakozol, csak a routered/gateway -ed
[ Szerkesztve ]
-
haddent
addikt
válasz szuszinho #420 üzenetére
Nem kell. Swarm ahhoz kell, ha több instance akarsz futtatni 1-1 szolgáltatásból, pl. High Availability vagy load balance stb.. Az már a nagyon hardcore felhasználás, szerintem indokolatlan
Sima docker + docker-compose. Készítek én is egy leírást az én megközelítésemről, ha van rá igény -
haddent
addikt
válasz szuszinho #438 üzenetére
Pontosan milyen parancsokat / hogy / hol próbálsz?
mzsol igen, ha te magad csinálsz egy openvpn szerver konténert / van ilyen készen is, a grafikus felület nélkül. Illetve ez megint ízlés / egyéni vélemény kérdése, de a VPN -t én nem konténerbe tenném, nekem a tűzfal kezeli
-
haddent
addikt
Itt az én verzióm: https://cloud.rowra.org/s/fR4tD7p3DaBTiTr
Docker, compose, swarm, kubernetesről elméletben röviden, ill. reverse proxy beállítás példákkal
-
haddent
addikt
válasz szuszinho #440 üzenetére
Jaa, az normális, igaza van, ez nem stack, csak "szleng"' rá, gondolom.
docker stack
helyett próbálddocker-compose
utánstigma hát remélem segítség / hasznos lesz
gazso75 jó ez a wireguard? olvastam, hogy nagyon letisztult a kódbázis, minimál, gyors és biztonságos, de legutóbb még nagyon extra alfa-béta volt. Van már stable branch? Lehet kipróbálom majd, bár véglegesre bizotsan várnom (kell) amíg pfSense csomag érkezik, vagy implementálhatom én, ami nem jó móka
[ Szerkesztve ]
-
haddent
addikt
Kicsit túlbonyolítottad szerintem. Ami biztos, hogy a routereden DHCP -n amit oszt DNS az csak a pihole legyen: 192.168.69.200, semmi más fallback. IP6 (is) bekavarhat, ha a pihole ip6 -ot nem a semmire resolvolja, hanem amire kell.
Egyébként a pihole tök jó, csak semmire nem jó. Ha csak reklámmentesítésre használod, akkor pont annyit csinál kb. mint ez vagy tetszőleges repo: https://github.com/StevenBlack/hosts , ezért felesleges egy ilyen "komplex" megoldás. Ha DHCP -re is használnád, akkor megint kicsit overkill, mert egy sima dnsmasq fut továbbra is a háttérben. Szép meg cuki a felülete, de épp a plusz absztrakciók miatt ki tudja mi történik.. Persze beleáshatod magad a dnsmasq és egyéb syslogokba, de akkor ennyi erővel meg is csinálhatod magadnak ezeket az említett dolgokat manuálisan (szerintem)
stigma örülök, ha hasznos volt
-
haddent
addikt
válasz donat_sz #462 üzenetére
Elméletben te sehol. A portainer már nem biztos.. Épp ezért én deploymenthez elengedném, cli a biztos
https://docs.docker.com/network/host/
If you use thehost
network mode for a container, that container’s network stack is not isolated from the Docker host (the container shares the host’s networking namespace), and the container does not get its own IP-address allocated. For instance, if you run a container which binds to port 80 and you usehost
networking, the container’s application is available on port 80 on the host’s IP address.
Tehát mennie kéne, de mégsem.. -
haddent
addikt
Nézd át amit írtam pár hsz. -szel előrébb: https://cloud.rowra.org/s/fR4tD7p3DaBTiTr
Szolgáltatások publikálása / 8. pont főként, ha van még konkrét kérdés mondd nyugodtan
-
haddent
addikt
Azért ez nem ilyen egyszerű. A compose 2 és 3 közt van lényeges különbség, most fejből nem sorolom, de van, amit 2 -vel nem tudtam megoldani csak 3 -mal vált támogatottá.
footy ezt az inspectet őszinte leszek még sosem használtam. Költöztetni viszont már sokszor költöztettem különféle módokon. Kettő titka van: minden alkalmazás adatot/konfigot bindmountolj és tudj szállítani (bindmount nélkül is kikeresheted /var/lib/docker/volumes, mert lényegében ez is bind mount csak automatikus..), illetve a docker-compose is legyen meg. Ha ez megvan és rendszerezett, akkor az előbb említett adatokat (ergo az alkalmazás "merevlemezét") átmásolod meg a compose -t, tolsz egy docker-compose up -d --force-recreate és kész vagy, garantált a működés. Nyűgös appoknál érdemes odafigyelni, hogy költözést ne köss egybe frissítéssel, tehát kritikus alkalmazások esetén szokás a konténerek explicit verizóját használni a :latest helyett, így tényleg 100% -os garantált a siker bármiről bármire való költözés esetén
-
haddent
addikt
Lehet, hogy leegyszerűsítem a kérdésed.. de a cloudflare nem épp ezt csinálja? Beáll a kliens és a szerver közé proxy / "offline" (szerverre nézve) proxyként. Nyilván lassabb lesz. Biztos vagy benne, hogy ennek gyorsabbnak kéne lennie? Illetve tracertedből is látszik, hogy pattog ide-oda, mint kecskeszar a lécen. Nem vagyok otthon cf -ben, de ebből nekem nem úgy tűnik, hogy te rontanál el bármit
[ Szerkesztve ]
-
haddent
addikt
válasz szuszinho #587 üzenetére
A Portainer nem más, mint egy szépecske webes UI felület ami pontosan azt a Docker API -t hívogatja, amit te a "docker xyz" cli parancsokkal, tehát teljes átfedés kell, hogy legyen. Nyilván a CLI a biztosabb, így az van, amit az lát, minden mást a Portainer csak szeretne meg képzeleg Előző kommentedben említett dologra ugyanezt tudom mondani: Portainert önállóan nem igen létezik. Illetve ő is Compose -t (is) használ, csak egy régi szar 2.x -es verziót. Mivel több funkció is hiányzik az újhoz képest én személy szerint nem ajánlom. Én a Portainert csak arra használom / ajánlom, hogy átlássam egy szép felületen, hogy épp mi fut, max egy "restart" gomb megnyomásra, log nézésre, de ennyi.
Arch linuxot egyébként a közhiedelemmel ellentétben melegen ajánlom. Hosszú évek óta hibátlanul fut a barebone vason és lassan 1.5 éve a virtualizált KVM -en is. Utóbbin bevallom hősiesen, a telepítése óta épp tegnap adtam ki először a frissítés parancsot, semmi nem halt el A barebone -on is nagyon régen és nagyon ritkán voltak gondok, de akkor igen, valóban tud olyat, hogy őőő kösz én el sem indulok. Rendre linux firmware (kernel) frissítéskor illetve ennek elcseszésekor (bootloader seq stb.) történik ez, ami minden esetben faék egyszerű egyébként: vagy visszarakod a régi kernelt, vagy megjavítod kézzel a bootloadert és boot partíciót, egyik sem ördöktőlvaló, ha csináltad már. Sokat lehet vele tanulni, megéri
-
haddent
addikt
Egyébként az Arch Wiki egy elég komoly modernizált Unix Biblia is egyben. Nem ritka, hogy más disztrók vagy programok, appok linkelik be, hogy nehh, tanulj. Az meg még sokkal nagyon nem ritkább, hogy valami random hibát vagy azonnal meg nem fogható hibát úgy oldasz meg, hogy a google Arch fórumra és wikire juttat
Jóvan nem kenyérpiríton sincs időm ilyenekre na Érdekes kérdés egyébként. Nyilván (még) szimpatikusabb a Gentoo megközelítés, de én úgy látom, hogy az Arch az egy Gentoo csak precompiled csomagokkal. A mai procikkal, épp azért, mert nem kenyérpirítók, a gcc kapcsolók és optok variálásával és fél napnyi fordítással mit nyernék..? 0.01% -ot teljes system szinten?
-
haddent
addikt
Ahogy nézem az is egy nginx, csodák nincsenek, mindegy nginx
Ha Emby -t használsz akkor egy kósza javaslat: nézz rá a Jellyfin -re. Ugye az Emby anno open source volt, aztán lettek fizetős funkciók, aztán meg szépen sunyin zárt forráskódú lett, ami egy undorító lépés, szerintem, vagyis egyből kettő. Na, a Jellyfin a legutolsó open source Emby fork, minden fizetős feature ingyen, mostanra szerintem le is hagyta -
haddent
addikt
válasz Viktórrióó #625 üzenetére
A fő csapás így néz ki:
- kvm/qemu virtualizált pfsense
- kvm/qemu virtualizált Docker-Host, ami tovább bontva Docker stackekre:
* nginx reverse proxy minden előtt (csak 80, 443 van nyitva publikusan, ssllabs test alapján A+ 100% )
* 1db sajátkezű python script ami folyamatosan figyeli a wan ip -t és a google domains -en frissíti a @ rekordot. Ergo dyndns, csak a rendes .org domainemre
* Organizr, aki nem ismerné azt tudja, hogy kapsz egy fasza kis login felületet, illetve más, login nélküli oldalakat is tudsz vele védeni, néhány applikációhoz van SSO (single sign on), így egyetlen loginnal SSO módon elérem a teljes "media stackem": Jellyfin, Ombi, Radarr, Sonarr, QBittorrent (aki ismeri és bele akarna kötni, hogy a Jellyfinhez nincs SSO pluginja annak igazavanlenne, de épp tegnap küldtem a pull requestet, megírtam hozzá )
* Jellyfin (nem kell bemutatni remélem, az egyetlen free/open source, hardware gyorsított media streamer cucc. Már csak emiatt is veri nálam a Plex/Emby zártkódú hányást, de egyébiránt is érdemes kipróbálni)
* "Media crawler" stack: Ombi (Radarr+Sonarr frontend), Radarr, Sonarr, Jackett, QBittorrent
* Nextcloud
* Graylog a pfSense logoknak
* Néhány egyéb "csakúgy" amit nem is használok: BitWardenRS, Portainer, Grocy -
haddent
addikt
Egy tetszőleges mappában létrehozod a composet a kövekező tartalommal:
version: '3.2'
services:
digionline:
image: digionline
build: digionline
container_name: digionline
environment:
- DOMAIN=valami.local
- PASSWORD=jelszo
- EMAIL=a@b.hu
ports:
- 9999:9999
restart: unless-stoppedMajd tolj egy
git pull https://github.com/szabbenjamin/digionline.git
És innentől mehet a docker-compose up -d --force-recreate (ami egyből buildelni fog, de mehet előbb docker-compose build is)
-
haddent
addikt
válasz szuszinho #645 üzenetére
Nem, Jellynél ezt így nem. Amit lehet, hogy az Organizr -rel SSO -val lépsz be mindenhova, köztük Jellyfin -be is. (Ez újdonság, épp 2 napja fogadták el a pull requestem ahol implementáltam a Jellyfin SSO részét )
stigma Ombi kompatibilis mind a 3 -mal. Milyen kurzus egyébként?
gazso75 elkezdtem írni röviden, de akkor majd inkább egy doksiban
-
haddent
addikt
A devicesből csak azt mountold, amid van is, egyáltalán nem biztos, sőt valószínűtlen, hogy mind van. Illetve én azt javaslom, hogy amiből van official image, abból azt kell használni, jelen esetben nem linuxserver/jellyfin hanem jellyfin/jellyfin.
Ettől függetlenül, ha ugyanez a konfig más gépen megy, akkor ott nyilván a géppel lesz valami
-
haddent
addikt
1. Persze, pl. ssh vagy nem ismerem a Springet, de ha valami socketet használ azt be is mountolhatod
2. Alapvetően ez a best practice mindenféle konténerizálásnál, hiszen épp ez a lényege, más use-case -re ott a sima kvm/qemu. De ettől függetlenül úgy építed fel és azt raksz 1 kontlnerbe amit szeretnél, akár 10 szolgáltatást is
-
haddent
addikt
Mielőtt nagyon beleásod magad ellenőrizd, hogy van -e tcp/25 tcp/587 nyitott portod a szolgáltató irányából. Pl. a linux szerveren: nc -lvnp 25 aztán [link] -on ip -d, 25.
Kb. minden szolgáltató blokkolja, akkor meg kár vele szenvedni, sajnos .. Évek óta próbálom kikerülni... van ilyen "ghettosmtp (google)" megkerülés, de akkor meg valaki más proxyzza a forgalmat, nekem az meg nem szimpi.. Elvileg mivel tls titkosított nem para, de.. akkor ennyi erővel ott a gmail... -
haddent
addikt
válasz instantwater #701 üzenetére
Ugye egy ideje nem arány van, hanem h'n'r, és premiumnál nem számít
-
haddent
addikt
1. Pontra: nem ismerek vagy használok ilyet, csak a Nextcloudot. Az is tudja kb. ezt, meg van hozzá n+1 addon is, nézz rá esetleg
2. Ez nekem zavaros, de ami biztos, hogy kelleni biztosan nem kell 2 webserver. Oszd el subdomain, vagy folder szerint (photos.stigma.hu vagy stigma.hu/photos) az új alkalmazást és használj lehetőleg wildcard letsencryptet (*.stigma.hu), az a legegyszerűbb
Új hozzászólás Aktív témák
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Fejhallgató erősítő és DAC topik
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Magyar feliratozással jön a Senua's Saga: Hellblade II
- Milyen egeret válasszak?
- OLED TV topic
- Honor 90 - modellalkat
- Xbox Series X|S
- Építő/felújító topik
- PlayStation 5
- További aktív témák...