Linux-haladó

Van egy buta (de jó nagy) UPS-em. Gondoltam, hogy csinálok hozzá ESP32-vel egy feszültség (és esetleg áramerősség) érzékelőt.
Teszek rá Tasmotát, és akkor MQTT-vel simán tudok kommunikálni.
Na de hogyan lesz ebből shutdown event?
Mi lenne a megoldás?

Azelőtt nut volt a régi ups-hez, gondoltam létezik valami mqtt-to-nut bridge, de nem találtam. Nut-to-mqtt persze van (de az triviális is).
A leggagyibb megoldás az mqtt kliensből kiadott shutdown lenne persze, lehet hogy az lesz a vége, de nem szeretném. 
 

Sziasztok!

Van köztetek olyan, aki már valaha Freeipa szervert össze tudott kötni trust kapcsolaton keresztül egy Windows szerverrel?

Active Directory trust setup - FreeIPA ez alapján próbálkozok már de nagyon hosszú ideje.

A Windows 2016 szervert próbáltam már 2012R2 és 2008R2 szinten is, de nem sikerül pedig a validatálás is meg volt ahogy az oldalon szerepelt a slideon.

A hibaüzenet, amikor bekérdezek a Windowsba a következő:

[root@ipa home]# ipa trust-fetch-domains winteszt.local
ipa: ERROR: error on server 'ipa.ipateszt.local': Fetching domains from trusted forest failed. See details in the error_log

Az error logban pedig csak a semmitmondó dolog van.

[Fri Feb 18 08:43:57.519977 2022] [wsgi:error] [pid 77042:tid 77393] [remote 192.168.4.3:33026] ipa: INFO: [jsonserver_session] admin@IPATESZT.LOCAL: trust_fetch_domains/1('winteszt.local', version='2.245'): ServerCommandError
[Fri Feb 18 09:00:02.308060 2022] [:warn] [pid 77834:tid 77881] [client 192.168.4.3:46358] failed to set perms (3140) on file (/run/ipa/ccaches/admin@IPALAN.LAN-13hoev)!, referer: https://ipa.ipateszt.local/ipa/xml
[Fri Feb 18 09:00:27.347679 2022] [wsgi:error] [pid 77039:tid 77396] [remote 192.168.4.3:46358] ipa: ERROR: Failed to call com.redhat.idm.trust.fetch_domains helper.DBus exception is org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken..
[Fri Feb 18 09:00:27.347757 2022] [wsgi:error] [pid 77039:tid 77396] [remote 192.168.4.3:46358] ipa: ERROR: Helper fetch_domains was called for forest winteszt.local, return code is 2
[Fri Feb 18 09:00:27.347794 2022] [wsgi:error] [pid 77039:tid 77396] [remote 192.168.4.3:46358] ipa: ERROR: Standard output from the helper:
[Fri Feb 18 09:00:27.347798 2022] [wsgi:error] [pid 77039:tid 77396] [remote 192.168.4.3:46358] <not available>---
[Fri Feb 18 09:00:27.347800 2022] [wsgi:error] [pid 77039:tid 77396] [remote 192.168.4.3:46358]
[Fri Feb 18 09:00:27.347825 2022] [wsgi:error] [pid 77039:tid 77396] [remote 192.168.4.3:46358] ipa: ERROR: Error output from the helper:
[Fri Feb 18 09:00:27.347828 2022] [wsgi:error] [pid 77039:tid 77396] [remote 192.168.4.3:46358] <not available>--
[Fri Feb 18 09:00:27.347830 2022] [wsgi:error] [pid 77039:tid 77396] [remote 192.168.4.3:46358]
[Fri Feb 18 09:00:27.347969 2022] [wsgi:error] [pid 77039:tid 77396] [remote 192.168.4.3:46358] ipa: INFO: [jsonserver_session] admin@IPATESZT.LOCAL: trust_fetch_domains/1('winteszt.local', version='2.245'): ServerCommandError

Sziasztok, 

van valakinek tapasztalata, mennyire jó ötlet AWX alapokra építeni automatizációs megoldást produktív környezetben?  Elég stabil-e ehhez, vagy felejtsem el és küzdjek meg a Tower licenszért? 

A tesztkörnyezetben remekül teljesít az AWX, viszont élesben igencsak jól kell bírnia a strapát és az üzemeltetést sem szeretném megőrjíteni, ha nem muszáj, a serpenyő másik végében pedig a licenszköltség áll, tudnám másra is költetni azt a pénzt.

Ha van valakinek tapasztalata, ossza meg velem. 

Köszönöm! 

Sziasztok!

Kollégák beállítottak 2db Synology RS1221+ eszközt storage cluster célra, aktív-passzív formában.

Ezek egy szolgálati IP-n iSCSI -t adnak 2db Hyper-V Failover Cluster számára. Ha lekapcsoljuk az aktív synology-t, a passzív átveszi az aktív szerepét és IP címét, viszont az iSCSI leakad. Kézzel kell lökni rajta, hogy ismét aktív legyen.
Számlázó programok, fájlszerver, egyéb irodai sw-k futnak a virtuális gépeken, aminek a diszkjeit a synology ada.

Kérdésem: Ennek nem folyamatosan kellene mennie? Értem, hogy storage oldalon synology és IP vándorlás történik, de ez a döccenés és beavatkozás nem vállalható. Ennyit tud vagy valamit nem jól állítottak be a kollégák?

Régen..10 éve, mikor olvastam a synology HA bejelentéséről, az maradt emlékként, hogy az aktív syno folyamatosan tolja az adatokat a passzív párjának, memória képpel, sessionokkal együtt, így tökélesen át tudja venni a szerepét. Ezt komolyabb syno hardverek tudják vagy az egészre rosszul emlékszem?

Van megoldás a problémára ezekkel a synology hardverekkel?

Sziasztok!

Storage megoldást keresek 2 egyidőben futó webszerver kiszolgálásához. Sarkítva: 1 mappa egyszerre 2 helyen van jelen, 2 helyről olvasható, esetleg 2 helyről írható, bár ez nem feltétel.

Jelenlegi állapot: 2 node, mindkét node-on drbd adja a közös diszket, ezen ocfs adja a közös fájlrendszert. Az egész debian aktuális stabil kiadása alól megy.
Az elmúlt 10 évben egész stabilan ment, leszámítva 3-4 évente egy-egy drbd széthullást és split-brain állapotot.
Az utóbbi időben viszont vállalhatatlanul instabillá vált. A drbd még talán stabil, de az ocfs mostanában nem áll össze, ha összeáll, fél nap alatt beragadnak az I/O-k. Egyik lockolja a másikat. Csak a reboot segít. Korábban belefutottunk kernel frissítés után rejtélyes ocfs bugba, downgrade segített.

Ezzel kellene valamit kezdeni vagy teljesen más technológiára áttérni. Így azért nehezen vállalható.

A cél: egyszerre 2-3 webszerver elérje a fájlokat. Ha csak az egyik webszerver írhatja a fájlrendszert, nem gond. Proxyból megoldható, hogy az írásműveletet végző admint csak dedikált webszerver szolgálja ki.

Ötletek:

1. dobozos storage, ami a fekete dobozon belül minden redundanciát megold, NFS-t ad. Probléma, hogy a régi használt hálózati storage-k még nem tudnak NFS-t (beszállító partner szerint), az újak amik tudják ezt, aránytalanul drágák a projekthez mérve. A keret kb 0.5-1M Ft diszkek nélkül.

2. DRBD marad, de OCFS repül és GFS-re váltunk. Kérdés, aki használja, mi a tapasztalat? Ezek azért nem a tömeg "termékek". Kevés róla az olvasható tapasztalat. Nem szeretnénk egy döcögő projektre váltani.

Hogy csinálják nagyvállalati környezetben, ahol több webszerver szolgál ki egy időben azonos tartalmakat? Drága storage + NFS? Nekem már maga az NFS is egyfajta visszalépésnek tűnik, de perpill nincs az ismereteim között jobb ötlet.

Sziasztok!
Egy Proxmox VE7 szerveren az eddigi 1 IP mellé vettem egy /29 subnetet (Hetzner a hosting).

Szeretnék 6 db, egymástól elszeparált NAT hálózatot, mindegyiknek saját IP címmel.
Ezért csináltam 6 bridget (vmbr1 - vmbr6), rendre 192.168.1.1/24 - 192.168.6.1/24, a helyi IP-ket DHCP osztja MAC alapján.
iptables-szel NAT-olom a megfelelő publikus IP megfelelő portját a megfelelő gépekhez.
Eddig megy is minden szépen, de ha az egyik ilyen VM-ből lekérdezem a publikus címemet, mindig a szerverhez kapott eredeti IP-t kapom, nem a saját címét (amin pl. ssh-n beléptem).
Pl.:

# ssh 1.2.3.4
# curl ifconfig.me
4.3.2.1

# ssh 1.2.3.5
# curl ifconfig.me
4.3.2.1

/etc/network/interfaces:
 

auto lo
iface lo inet loopback

iface lo inet6 loopback

auto enp6s0
iface enp6s0 inet static
        address 1.2.3.4/26
        address 4.3.2.1/32
        address 4.3.2.2/32
        address 4.3.2.3/32
        address 4.3.2.4/32
        address 4.3.2.5/32
        address 4.3.2.6/32
        gateway 1.2.3.129
        hwaddress aa:bb:cc:dd:ee:ff
        pointopoint 1.2.3.129
        up route add -net 1.2.3.128 netmask 255.255.255.192 gw 1.2.3.129 dev enp6s0
# route 1.2.3.128/26 via 1.2.3.129

iface enp6s0 inet6 static
        address 2a01:4f9:6b:1f0d::2/64
        gateway fe80::1

auto vmbr0
iface vmbr0 inet manual
        address 192.168.0.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up   iptables -t nat -A POSTROUTING -s '192.168.0.0/24' -o enp6s0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '192.168.0.0/24' -o enp6s0 -j MASQUERADE
        post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

auto vmbr1
iface vmbr1 inet static
        address 192.168.1.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        up ip route add 4.3.2.1/32 dev vmbr1
        post-up   iptables -t nat -A POSTROUTING -s '192.168.1.0/24' -o enp6s0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '192.168.1.0/24' -o enp6s0 -j MASQUERADE
        post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

auto vmbr2
iface vmbr2 inet static
        address 192.168.2.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        up ip route add 4.3.2.2/32 dev vmbr2
        post-up   iptables -t nat -A POSTROUTING -s '192.168.2.0/24' -o enp6s0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '192.168.2.0/24' -o enp6s0 -j MASQUERADE
        post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

auto vmbr3
iface vmbr3 inet static
        address 192.168.3.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        up ip route add 4.3.2.3/32 dev vmbr3
        post-up   iptables -t nat -A POSTROUTING -s '192.168.3.0/24' -o enp6s0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '192.168.3.0/24' -o enp6s0 -j MASQUERADE
        post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

auto vmbr4
iface vmbr4 inet static
        address 192.168.4.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        up ip route add 4.3.2.4/32 dev vmbr4
        post-up   iptables -t nat -A POSTROUTING -s '192.168.4.0/24' -o enp6s0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '192.168.4.0/24' -o enp6s0 -j MASQUERADE
        post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

auto vmbr5
iface vmbr5 inet static
        address 192.168.5.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        up ip route add 4.3.2.5/32 dev vmbr5
        post-up   iptables -t nat -A POSTROUTING -s '192.168.5.0/24' -o enp6s0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '192.168.5.0/24' -o enp6s0 -j MASQUERADE
        post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

auto vmbr6
iface vmbr6 inet static
        address 192.168.6.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        up ip route add 4.3.2.6/32 dev vmbr6
        post-up   iptables -t nat -A POSTROUTING -s '192.168.6.0/24' -o enp6s0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '192.168.6.0/24' -o enp6s0 -j MASQUERADE
        post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

Mit felejtettem ki?

Megoldás

Sziasztok!

Adott egy Debian 11 alapu rendszer (Deepin) amire folraktam a wireguard-tools-t. Viszont en 5.15-os kernellel hasznalom a Deepin-t, a wireguard tools viszont apk install-al a 5.10-es kernelt eroltette. Ezert leszedtem a .deb-et a deepin repobol es felraktam dpkg-al. (siman folment amugy, erdekes mod igy fuggosege sem volt...) Mukodik is rendben.

A kerdesem az, hogy ha frissul a repoban a wireguard-tools, akkor nem akarja majd ugye rameroltetni megint az 5.10-es kernelt? Felek, hogy x honap mulva elfelejtem es majd csak nyomok az update-re...

apt policy ezt adja vissza, szoval elv frissulni fog, ha valtozik a verzio a repoban.

apt policy wireguard-tools 
wireguard-tools:
  Telepítve: 1.0.20210223-1
  Jelölt:    1.0.20210223-1
  Verziótáblázat:
 *** 1.0.20210223-1 500
        500 https://proposed-packages.deepin.com/dde-nightly bullseye/main amd64 Packages
        100 /usr/lib/dpkg-db/status

Persze le is tilthatnam a frissiteset ennek a csomagnak, de ha amugy nem huzna be a regi kernelt, akkor had frissuljon...

(amugy nem ertem, 5.6 folott miert van a toolsnak egyaltalan kernel fuggosege....)

Itthoni infrastruktúra (közepesen bonyolult, mondjuk SoHo top, SME alja.

Vannak fizikai eszközök, több vlan, konténerek, vpn, miegymás. Mi az a szoftver+módszer amivel ezt jól lehetne monitorozni?

Első körben él/nem él jelleggel, később mondjuk filesystem betelés esetén is szólhatna.

Push notification lenne az ideális (vagy slack v telegram v ilyesmi). Zabbix? Prometheus/grafana/alertmanager?

Előny ha nem kell hetekig tanulni a konfigot.!

Sziasztok!

Azt szeretném megoldani, hogy mondjuk Alt Ctrl F7-nél user1-ként legyek belépve és használhassak mondjuk négy munkaterületet, Alt Ctrl F8-nál pedig user2-ként.

Elnézést hogyha a probléma megoldása triviális, de az általam kitalált keresésekre nem erre jött megoldás. De lehet hogy csak nem voltam elég találékony.
 

Előre is köszönöm a javaslatokat.