Linux-haladó

Windows fluentbit 3.0 GELF -> Graylog 5.2.5 host mező hiánya

Fórumok

Felraktam egy Graylog 5.2 szervert Debian 12-re, egyéb Linux-os gépek (Debian és Ubuntu, vegyes kiadások) rsyslog segítségével átküldik a syslog-ot GELF formátumban UDP-n.

Adódott hogy egy Windows 10 egyedi szoftverének logját is ide kellene átküldeni. Ehhez feltelepítettem a fluentbit 3.0-át a következő konfigurációval - log-ban nincs benne a gépnév, azt külön kell beleraknom FILTER segítségével.

parsers.conf

[PARSER]
    Name EgyediProgramLog
    Format regex
    Regex /(?<time>\d+/\d+/\d+ \d+:\d+:\d+ \+\d+:\d+),(?<message>.*)/
    Time_Key time
    Time_Format %Y/%m/%d %H:%M:%S

fluent-bit.conf

[INPUT]
    Name tail
    Tag EgyediProgram
    Path C:\[log_directory]\*.log
    Parser EgyediProgramLog
    Refresh_Interval 10

[FILTER]
    Name modify
    Match EgyediProgram
    Add hostname ${HOSTNAME}

[OUTPUT]
    Name  stdout
    Match EgyediProgram

[OUTPUT]
    Name                 syslog
    Match    EgyediProgram
    Host                 [graylog-szerver-ip]
    Port                 514
    Mode                 tcp
    Syslog_format        rfc3164
    Syslog_message_key   message
    Syslog_hostname_key  hostname

[OUTPUT]
    Name gelf
    Match EgyediProgram
    Host [graylog-szerver-ip]
    Port 12201
    Mode udp
    Compress false
    Gelf_Short_Message_Key message
    Gelf_Host_Key hostname

stdout kimenete

[0] EgyediProgram: [[1712658673.000000000, {}], {"message"=>"[log_bejegyzes]", "hostname"=>"[Windows_host_neve]"}]

Syslog üzenet megfelelően megérkezik Graylog szerver gyűjtött logjai közé, látszik a teljes üzenet, helyes Windows gépnévvel.

Ha (még Windows-on, Wireshark-al) megnézem a hálózati forgalmat, ez megy át GELF-ként: {"version":"1.1", "short_message":"[log_bejegyzes]", "host":"[Windows_host_neve]", "timestamp":1712658673.000}

Ezt nem fogadja el a Graylog szerver, server.log-ban ez szerepel: 2024-04-09T10:33:29.335+02:00 WARN  [GelfCodec] GELF message <d77d0960-f64b-11ee-812f-000c2929b7fa> (received from <[Windows_host_IP]:56029>) is missing mandatory "host" field.

Mit nézek be? Pláne hogy Linux GELF források mennek, Windows log értelmezés és átalakítás stdout szerint rendben és syslog üzenetként megfelelően át is megy. GELF-ben meg a meglévő host mező hiányára hivatkozik. Plusz infó hogy a kb harminc próbálkozásból két Windows GELF mégis átment (később vettem csak észre), de host neve helyett a Windows gép IP címe van a log-ban - valamilyen közbenső konfigurálási próba eredménye lehet.

(Open)SUSE ala VDO? - Sikerült már valakinek?

Fórumok

Sziasztok!

 

CentOS alatt nagy megelegedettseggel hasznaltam a VDO-t, de most szeretnem migralni az egyik serverem OpenSUSE ala. csomag nincs sajna OpenSuse hoz, forrasbol sem sikerult meg leforgatom eddig sem a kernel modult sem a userspace toolt OpenSuse alatt... Van valakinek ezzel sikere? ha igen meg tudna osztani a metodust? Vagy ha van VDO alternativa SUSE ala, az is erdekelne... (BTRFS/ZFS nem jatszik jelen esetben)

ldapsearch filter

Fórumok

Udv!

Ilyen strukturaban vannak a csoportok megadva windowsos AD-ben:

ou=Groups,ou=company,dc=domain,dc=com
  - ou=Tech
    - cn=Test
    - ou=Engineer
      - cn=foo_admins
      - cn=foo_devs
    - ou=Command Center
      - cn=bar_admins
      - cn=bar_users
  - ou=Operation
    - ou=Sales
      - cn=ize
    - ou=Management
      - cn=csigabiga
  - ou=Misc
    - ...

ez sajna adott, nincs lehetoseg modositani.

Linuxon olyan ldap search filter keresek, ami visszaadja a ou=tech es ou=operation alatti ossze csoportot, barmilyen melyen is van. (es ne a Misc kizarasaval, mert ott meg van 5 masik amit ki kene zarni)

probaltam netet bujni, AI-t kerdezni, de nem segitett. BaseDN: ou=Groups,ou=company,dc=domain,dc=com

Valakinek van otlete?

nfs4 unhandled error 10018

Fórumok

Sziasztok,

 

Az alabbi NFS4 hiba gyakran elofordul egy adott esetben:

 

https://i.ibb.co/b7VZSBJ/image.png

Csak a kliens restart oldja meg sajnos a gondot... Van valakinek ra otlete, vagy talalkozott hasonlo hibaval?

 

A hiba leirasa

13.1.3.4. NFS4ERR_RESOURCE (Error Code 10018)

For the processing of the COMPOUND procedure, the server may exhaust available resources and cannot continue processing operations within the COMPOUND procedure. This error will be returned from the server in those instances of resource exhaustion related to the processing of the COMPOUND procedure.

VMware-es Fedora alatt középső egérgomb emulálása

Fórumok

Most cserélték le a céges laptopomat. A régin 3, az újon csak 2 touchpad gomb van. És nagyon hiányzik a középső gomb, ugyanis terminálablakban ki szoktam jelölni egy szöveget, és a középső touchpad gombbal beillesztettem máshova. Most Ctrl+Shift+C és Ctrl + Shift + V kettőssel helyettesítem az egyetlen középső gomb kattintást.

 

Tehát Windows-ot használok és VMware-ben futtatok egy Fedorát, MATE desktoppal. Windows-ban sikerült emulálnom a középső touchpad gomb lenyomását Three-Finger-Tap-Guesture-val. Ez a Touchpad beállításainál megtalálható. Sajnos ugyanezt nem tudom megvalósítani Fedora alatt. Kínlódtam a touchegg progival, de nem tudom mit kéne a .conf file-ba írnom. Nekem az is jó lenne, ha 3as tap-re a CTrl+Shift+V meghívódna. A fusuma nevűt fel se tudtam rakni. Valakinek van valami konkrét javaslata?

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.