Linux-haladó

Traefik mint reverse proxy - Mit rontok el? --Megoldva--

Fórumok

Sziasztok, 

 

adott az alabbi pelda conf, ami a test.labor.local-ra 404-et dob...

Biztos valami bagatell dolgot cseszek el, de nem tudom mit..  

 

(Ami meg nem latszik itt, h a network az egy overlay, a swarm miatt)

 

version: '3.7'

services:
  traefik:
    image: traefik:v2.6
    command:
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.swarmMode=true"
    ports:
      - "80:80"
      - "8080:8080"
    deploy:
      placement:
        constraints:
          - node.role == manager
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"

  whoami:
    image: containous/whoami
    labels:
      - "traefik.http.routers.whoami.entrypoints=web"
      - "traefik.http.routers.whoami.rule=Host(`test.labor.local`)"
      - "traefik.http.services.whoami.loadbalancer.server.port=80"
    networks:
      - traefik-public

networks:
  traefik-public:
    external: true

A log ennyi:

time="2024-02-15T07:35:04Z" level=error msg="service \"test-whoami\" error: port is missing" providerName=docker container=test-whoami-tkdbgepz8eprikt0pfuawc9x5

gfs2 fájlrendszer - dlm gond

Fórumok

Sziasztok!

 

Adott egy 3 node-os Swarm cluster, amihet strorage-ot akarok csatolni iSCSI-val. Ott tartok most, hogy a 3 nodehoz sikeresen beallitottam az iSCSI initiatort. A fajlrendszerre ket otletem volt, gfs2 vagy ocfs2. Eloszor ocfs2-vel probalkoztam, de sajnos ugy nez ki, bugos egy kisse...(2. node ot mar nem birom felmountolni, ismert hiba, csomo helyen irjak, Ubuntu, Debian, etc... rendszerek alatt) lenyegeben kernele valogatja epp, hogy megy-e, vagy nem... (nyilvan az enyemmel nem, meg amugy sem biznak igy ra semmit...)

Maradt a gfs2. Fontos, hogy HA meg hasonlok nem kellenek, csak egy shared-disk fájl rendszer. folraktam a gfs2-t , meg a dlm-et (kernel modulok + toolok) de nem akar osszejonni... A hiba lenyegeben ugyanaz, mit ezen a linken:

https://www.linux.org/threads/how-to-set-up-shared-gfs2-filesystem-with…

 

A hibam:

Feb 09 09:12:20 hun25-04v kernel: gfs2: fsid=gitlab:data: Trying to join cluster "lock_dlm", "gitlab:data"
Feb 09 09:12:20 hun25-04v kernel: dlm: no local IP address has been set
Feb 09 09:12:20 hun25-04v kernel: dlm: cannot start dlm lowcomms -107
Feb 09 09:12:20 hun25-04v kernel: gfs2: fsid=gitlab:data: dlm_new_lockspace error -107

Igy formaztam meg a particiot:

mkfs.gfs2 -p lock_dlm -t gitlab:data -j 4 /dev/sdb1

 

probaltam en is egy  /etc/dlm/dlm.conf -ot letrehozni, de nem segitett az sem.

 

Valami otletetek van erre?

OpenVPN egyedi felhasználói szabállyal

Fórumok

Adott egy teljesen jól működő OpenVPN szerver Leap 15.5-ön. (IP: 10.66.4.3)
Alapból a hozzá csatlakozó felhasználók (ez csak én vagyok jelenleg) látják a teljes hálózatot.
Ehhez engedélyeztem az ip továbbítást és az openvpn szerver konfig vonatkozó része így néz ki:

server 10.8.5.0 255.255.255.0
ifconfig-pool-persist /var/run/openvpn/ipp.txt
push "route 10.66.4.0 255.255.255.0"

Felvettem egy tűzfal szabályt:

ipv4 -t nat -A POSTROUTING -s 10.8.5.0/24 -o eth0 -j MASQUERADE

Mint írtam, a vpn így teljesen jól működik.


Viszont felmerült az igény, hogy külső felhasználók hozzáférjenek a belső hálózaton futó samba fájlszerveren (IP: 10.66.4.5) megosztott mappákhoz.
Ezt én úgy gondoltam megoldani, hogy beállítok egyedi felhasználói hozzáférést az OpenVPN szerveren és onnan csak a samba irányába engedem tovább az adott felhasználókat.
Ehhez felvettem az opnvpn szerver konfigba egy új virtuális IP tartományt és megadtam a felhasználói konfig fájlok helyét:

route 10.8.55.0 255.255.255.0
client-config-dir ccd

A ccd mappában létrehoztam egy konfig fájlt a felhasználónak az alábbi tartalommal:

ifconfig-push 10.8.55.1 10.8.55.2
iroute 10.8.55.0 255.255.255.0

Majd hozzáadtam egy tűzfalszabályt:

ipv4 filter FORWARD 0 -i tun0 -s 10.8.55.0/24 -d 10.66.4.5 -j ACCEPT

A felhasználó és az openvpn szerver között hibátlanul létrejön a kapcsolat, a felhasználó gépe megkapja a 10.8.55.1 ip címet.
Ennek ellenére a felhasználó nem éri el a fájlszervert (10.66.4.5)

A tűzfal logban nem látszik, hogy a tun0 csatolón megjelenne eldobott forgalom.

Íme a szerver routing táblája:

# ip -4 route show
default via 10.66.4.254 dev eth0
10.8.5.0/24 via 10.8.5.2 dev tun0
10.8.5.2 dev tun0 proto kernel scope link src 10.8.5.1
10.8.55.0/24 via 10.8.5.2 dev tun0
10.66.4.0/24 dev eth0 proto kernel scope link src 10.66.4.3


Vajon mit szúrtam el vagy néztem be?
Minden ötletet szívesen fogadok.


Köszi:

 

Szerk.:

A hálózatban lévő eszközök:

10.66.4.254 - Router

10.66.4.3 - VPN szerver - Virtuális alháló: 10.8.5.0/24 és 10.8.55.0/24

10.66.4.5 - Fájlszerver

Az eredeti leírás, ami alapján az egészet elkezdtem/összeraktam.

Flattened Device Tree generálás

Fórumok
Üdv, Van itt olyanvalaki, aki jártas az FDT (.dtb) generálásban? Próbálom kihámozni a specifikációból, de egyre inkább az az érzésem, hogy ez egy förtelem. Specifikáció itt (PDF), ez próbálom összevetni ezzel: linux dts. Ebben ilyent látok:
	soc {
		/*
		 * Defined ranges:
		 *   Common BCM283x peripherals
		 *   BCM2711-specific peripherals
		 *   ARM-local peripherals
		 */
		ranges = <0x7e000000  0x0 0xfe000000  0x01800000>,
			 <0x7c000000  0x0 0xfc000000  0x02000000>,
			 <0x40000000  0x0 0xff800000  0x00800000>;
		/* Emulate a contiguous 30-bit address range for DMA */
		dma-ranges = <0xc0000000  0x0 0x00000000  0x40000000>;

		/*
		 * This node is the provider for the enable-method for
		 * bringing up secondary cores.
		 */
		local_intc: interrupt-controller@40000000 {
			compatible = "brcm,bcm2836-l1-intc";
			reg = <0x40000000 0x100>;
		};
Első számú kérdés, a spec-ben az áll:
2.3.5 #address-cells and #size-cells ... The #address-cells and #size-cells properties are not inherited from ancestors in the devicetree. They shall be explicitly defined.
Hát a fenti példában ez nyilvánvalóan nem így van. Nincs egyik "-cells" property se, szóval szinte biztos, hogy a szülőtől kellene örökíteni, szemben azzal, amit a spec állít, nem? A másik kérdés a "ranges" és "dma-ranges" property-kre vonatkozik, na itt aztán végképp se füle, se farka az egésznek. A spec szerint:
2.3.8 ranges ... The format of the value of the ranges property is an arbitrary number of triplets of (child-bus-address, parent-bus-address, length)
Illetve
2.3.9 dma-ranges ... The format of the value of the dma-ranges property is an arbitrary number of triplets of (child-bus-address, parent-bus-address, length). ... The child-bus-address is a physical address within the child bus’ address space. The number of cells to represent the address depends on the bus and can be determined from the #address-cells of this node (the node in which the dma-ranges property appears). The parent-bus-address is a physical address within the parent bus’ address space. The number of cells to represent the parent address is bus dependent and can be determined from the #address-cells property of the node that defines the parent’s address space.
Namost a "ranges"-ben eleve négyesek vannak, ami sehogy sem jön ki, még akkor se, ha az "#address-cells" 2 és "#size-cells" 1 (és egyébként is, ha igaz, hogy öröklődnek ezek, akkor az "interrupt-controller@40000000" alnode-beli "reg"-nél hogy lehet az "#address-cells" és a "#size-cells" is egyértelműen 1?). Ugyancsak a "dma-ranges"-nél, ott sem hármasok vannak, hanem négyesek. Ez mégis hogy? Nincs is külön "#address-cells" a node-on, mint ahogy a specifikáció állítása szerint kéne lennie. És különben is, ha az "#address-cells" 2 a "#size-cells" meg 0, akkor is hogy kezdődhetne a számsor a címmel, hisz ez esetben két u32 érték a cím (és a DTB big-endian), szóval az nem 0x0 0x7e000000 lenne? Ha pedig az "#address-cells" és a "#size-cells" is 1, akkor a méret hogy lehetne már 0 és hogy lesz a két cím egy hossz elemből négyes? És végül az értékek, na ezek sem jönnek ki sehogy se. A specifikáció szerint az alnode-okban a "reg"-beli címek a "ranges"-hez képesti relatív címek.
The ranges property provides a means of defining a mapping or translation between the address space of the bus (the child address space) and the address space of the bus node’s parent (the parent address space).
Namost ez sem jön ki sehogy sem, mert a "interrupt-controller@40000000" node-ban a "reg" propertyben egyértelműen "parent address space"-ben van direktben a cím, és ha hozzáadnám a 0xff800000-át (ugye az utolsó nem-éppen-triplet vonatkozik erre a child címre), akkor hibás eredmény jönne ki.

x_forwarded_for Squid HTTPS

Fórumok

Sziasztok!

Kérem segítsetek az alábbi problémában, miként lehetne megoldani.

Adott egy vállalati belső hálózat, ahol userek eszközzel csatlakoznak egy alkalmazás szerver web felületéhez(https). Köztük van beiktatva egy Squid proxy server.

Az a gond, hogy az alkalmazásszerver alkalmazásának ismernie kellene a kliens IP címét. A proxy nem küldi tovább, hiába van beállítva az x_forwarded_for paraméter. Egy tapasztaltabb kollégám szerint a Squid csak http-n tudja a headerben továbbítani a kliens ip címét. Miként lehetne megoldani ezt, esetleg más proxy alkalmazást tudnátok javasolni?

Köszönöm előre is!

Zentyal Linux 7.0.9 - PPPOE Bug?

Fórumok

Sziasztok!

Adott egy Zentyal 4.2 rendszer futtató "szerver" amely levelező / tűzfal szerver funkciót tölt be, már közel 6 éve egy "kommersz" pc-ben, így ezt cserélnem kellene pár héten belül.

A csere szerver már megvan, Zentyal 7.0.9 fut rajta, mert a 7.1 folyton lefagyott telepítést követően.

Gyakorlatilag be van konfigurálva, annyi hiányzik, hogy pppoe kapcsolaton kapjon internetet a jelenlegi 4.2 Zentyal pppoe accountjával és a mail fiókok fel legyen töltve a migrált tartalommal.

A cégnél van egy másodlagos ISP kapcsolat is, amely ugyancsak pppoe accounttal működik, gondoltam kipróbálom, hogy a szerver kap-e internetet a pppoe vonalon, hogy legközelebb már csak a fiókok migrációja maradjon hátra.

Beírtam a login adatokat majd alkalmaztam, de nem kaptam ip címet, kizárólag az átjárót állította be a rendszer a pppoe kapcsolathoz.

Reboot után a boot processnél már látszódott, hogy nem tudja az ethernet interfacet "felhúzni", így az failed státuszban maradt, majd bootolást követően valóban nem kaptam az ISP-től sem ip címet, sem pedig gatewayt, csak akkor, ha újra beadtam a login adatokat, de akkor is csak gw-t.

Logban kb annyi látszik, hogy nem tudja a ppp0 interfacet elinditani:

Sudo.pm:240 EBox::Sudo::_rootError - root command /usr/share/zentyal/unblock-exec /sbin/ifup --force -i /etc/network/interfaces zentyal-ppp-eth0 failed.

Error output: ethtool: bad command line argument(s)

For more information run ethtool -h

run-parts: /etc/network/if-up.d/ethtool exited with return code 1

ifup: failed to bring up zentyal-ppp-eth0

Command output: Plugin rp-pppoe.so loaded.

PPPOE Account adatok biztosan jók, mert notebook simán kapott netet, amire tudok gondolni, hogy talán azért nem kapott kapcsolatot, mert az adott domain névvel már futott a 4.2-es Zentyal szerver, vagy esetleg valami újabb bug?

Statikus IP címmel, és DHCP-vel stabilan működik az internet, de a pppoe lenne a legfontosabb, mivel azon kapná élesben a kapcsolatot.

Esetleg valaki találkozott már hasonló problémával, akár 7.0.9 előtti verziónál is érdekelne, hogyan oldotta meg.

Köszönöm előre is a segítséget!

Melyik a leghosszabb támogatási időtartamot ígérő disztro most?

Fórumok

Kellene frissíteni pár gépet és lehet, hogy szempont lenne, hogy melyik az a disztro, amelyikhez a legjobb eséllyel a legtovább nem kell hozzányúlni, csak frissítgetni. Linux Mint vagy Debian Bookworm lenne enélkül a szempont nélkül, a Mint Virginia 2027 áprilisig írja magát, a Bookworm meg ha jól értem valamikor 2026 és 2028 júniusa között... szóval nem tudom. Olvastam olyat, hogy RedHat vagy Suse a leghosszabb LTS, igazán nincsen olyan használati szempont ami alapján ne lehetne bármi, de mondjuk a wireguard-dal szeretnék lehetőleg nagyon keveset szopni... ebből a szempontból a Mint lenne a nyerő, azt hiszem. Hogy látjátok?

Sunshine/parsec alternativa - Reemo

Fórumok

Keresek egy ideje egy jo Remote Desktop appot, ami kielegiti a kovetkezoket:

 

- Windows host, NVENC supportal (legalabb 60 FPS, low latency, jatekra, filmezesre, CAD-ra is jó)

- Kepes direkt kapcsolatra a szerver/kliens, de ha kell, van relay mod is.

- Kliens oldalon legyen Windows és Linux tamogatas, utobbin Intel kartyaval VA-API menjen (H264 es/vagy HEVC)

- Nativ Linux kliens helyett HTML5, hasonlo teljesitmennyel (megy Androidon, Linuxon)

- Legalabb Personal Use-ra legyen ingyenes :)

 

Amit eddig probaltam:


Geforce Experience + Moonlight = Egesz jó, csak valami out of the boxot kerestem + nincs relay mod (Persze sajat cuccokon ott a VPN) Illetve a GF elv meg is szunteti

Sunshine + Moonlight = Lenyegeben azt tudja, mint a GFE, csak host oldalon csereltek a GFE-t Open Source-ra

Parsec = Nekem nem jott be, nem hozta azt a teljesitmenyt mint a GFE/Sunshine. Linux oldalon a VA-API eleg korlatozottan tamogatott... nincs relay.

Remotly = Nincs linux kliens, eleg bugos (direkt kapcsolat VPN-en nyogvenyelos...) van relay, hamarosan self hosted is.

 

Viszont ma ratalaltam a Reemo-ra! https://www.reemo.io/

 

Lenyegeben mindent tud, amit font leirtam, nativ kliense nincs (windowsra sem!) csak webes, viszont az nagyon jo teljesitmenyu, felveszi a versenyt a GFE+Moonlight komboval! Van relay is, sajnos (az ingyenes verzioban) self hosted-et nem lehet telepiteni.

Szoval igy egy nap utan en ajanlom! Alapvetoen nem remote supportra talaltak ki, de tavolrol pl jatekra vagy HO-ban benti "powerful" gep eleresere kivalo!

mysql 8 konfiguralasa es inditasa non-root user alatt

Fórumok

Sziasztok,

hogy tudnek non-root userkent mysql 8-t telepiteni Kubernetes alatt?

Asszem, letezik a docker image-ben default mysql user (uid=999) es group (gid=999).

Nem latok benne azonban systemctl-t demon inditasra. Gondolom, ha lenne is telepitve, root-kent amugy se koser kubernetes

alatt inditani.

Hogyan lehet igy korrekt modon leallitani, restartolni es inditani a mysql adatbazist? Linux alatt ez teljesen maskepp mukodik...

Hogyan tudnam megvaltoztatni a default telepitesi utat ? (mondjuk egy altalam letrehozott) pvc-be

Ezek lennenek bevezeteskent ... tobbit talan kesobb.

Koszonet a valaszokert.

Ardi