Linux-haladó

Sziasztok!

Anno egyszer sikerült megoldanom egy régi huawei USB mobil stick-el az SMS küldést, udev és usb_modeswitch segítségével.

Ahogy nézem a mostani eszköz ezzel már nemigen akar működni, helyette curl és az IP cím segítségével küldenek sms-t.

Na ez az , ami nekem nem akar működni.

Ez alapján próbálom de hibára futok.

./sendsms +3630XXXXXXXX "Teszt"
<request><Index>-1</Index><Phones><Phone>+3630XXXXXXXX</Phone></Phones><Sca/><Content>Teszt</Content><Length>5</Length><Reserved>1</Reserved><Date>2022-03-03 05:06:23</Date><SendType></SendType></request>
*   Trying 192.168.8.1:80...
* TCP_NODELAY set
* Connected to 192.168.8.1 (192.168.8.1) port 80 (#0)
> POST /api/sms/send-sms HTTP/1.1
> Host: 192.168.8.1
> User-Agent: curl/7.68.0
> Accept: */*
> Cookie: SessionID=bTekxTl3Qe47cALKUCkugWOnOYBb4BNiZrpjBubjKf90qqqfyAAPpLP7dBJC8Wm5OfCgcyFUD0Wgd8385G0ytytcKwFDYO2OPsBKJ1mgz0u0b13PbtppXNyh5kMvGeCH
> X-Requested-With: XMLHttpRequest
> Content-Type:text/xml
> Content-Length: 203
>
* upload completely sent off: 203 out of 203 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Content-Type: text/html
< X-Download-Options: noopen
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'
< X-Content-Type-Options: nosniff
< Content-Length: 88
<
<?xml version="1.0" encoding="UTF-8"?>
<error>
<code>125003</code>
<message/>
</error>
* Connection #0 to host 192.168.8.1 left intact
 

Az eszközt, jelenleg így látja az Ubuntu:

Bus 001 Device 004: ID 12d1:14db Huawei Technologies Co., Ltd. E353/E3131

A saját oldalán keresztül megy az SMS küldés.

Küzdött már meg valaki, sikeresen, ezzel?!

Vagy bármi 5let, az SS küldéshez?

Van három Proxmox szerverem két UPS-sel. Mindegyik szervert mindkét UPS táplálja, mert az adatbiztonság, a sérülésmentes leállás fontosabb, mint az üzemidő vagy a folyamatos rendelkezésre állás.
(Amúgy a load most 8% és a várható üzemidő tisztán akkumulátorról egy óra. De még nem nagyon vannak rajta VM-ek és konténerek, mert a telepítés és tesztelés folyik.)

Egy kis Linuxos gép Network UPS Tool azaz NUT szerverként működik, web-es felületen már lehet monitorozni mind a két szünetmentest.

Mindhárom Proxmox-on egy NUT kliens futna, ami a NUT szerverren keresztül figyelné a szünetmenteseket.

Azt akarom, hogy ha a két UPS közül akár az egyik is 5 percél tovább akkumulátorról működik akarok minden Proxmox álljon le, kapcsoljon ki!

Az a problémám, hogy nem igazán tudom, hogy konfiguráljam a NUT klienseket úgy, hogy mind a két szünetmentest figyeljék egyszerre és már az egyiknek a betáp 5 percet meghaladó áramkimaradása esetén induljon el a shuttdown.

Ha valaki ismeri a megoldást, vagy van ötlete kérem ossza meg velem!
 

Sziasztok!

Az itt leírtak alapján működik most a hálózat. Proxmox VE 7.
A NAT-olás a következőképpen működik:

[...]
iptables -t nat -A PREROUTING -d $egyik_publikus_IP/32 -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.4.2:22
iptables -t nat -A PREROUTING -d $masik_publikus_IP/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.6.2:80
iptables -t nat -A PREROUTING -d $masik_publikus_IP/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.6.2:443
[...]

1. probléma: bármelyik VM egy másik VM publikus IP-jén, vagy domainnéven keresztül nem elérhető, csak ha a /etc/hosts, vagy Windows alatt a C:\Windows\System32\drivers\etc\hosts fájlba beírom a domainhez tartozó local IP-t (hosts poisoning).
Pl. Windows alatt böngészőből nem tudok megnyitni egy ugyan ezen a szerveren, de másik VM-ben futó weboldalt, amely a külvilág felől elérhető, csak ha beírom a hosts-ba:

192.168.6.2 valami.tld

2. probléma: a belső IP tartományok nincsenek elszeparálva egymástól. Hiába a /24 az egyes vmbrX beállításaiban, a VM-ek belső IP alapján elérik egymást.
PL. a SAMBA megosztások IP alapján bármelyik VM-ben felcsatolhatóak, vagy a 192.168.6.4 IP-ről simán be tudok SSH-zni a 192.168.3.7-re, holott elméletileg más hálózat kellene, hogy legyen, mindkettő /24 maszkkal.

Segítenétek megoldani ezeket a problémákat?

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!

Adott egy Uyuni server, ami egy ideje (kb a 2. frissites ota) az allabit jatsza.

Ha probalok egy CentOS 7 klienst frssiteni ezt a hibauzit kapom:

susemanager:nginx-stable/signature                                                                                                    | 1.3 kB  00:00:00 !!!
https://hun25-14v.hft.local:443/rhn/manager/download/remi-php72/repodata/repomd.xml.asc: [Errno 14] HTTPS Error 404 - Not Found
Trying other mirror.
To address this issue please refer to the below wiki article

https://wiki.centos.org/yum-errors

If above article doesn't help to resolve this issue please use https://bugs.centos.org/.

susemanager:remi-php72                                                                                                                | 1.3 kB  00:00:00


 One of the configured repositories failed (Remi's PHP 7.2 RPM repository for Enterprise Linux 7),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. There are a few ways to work "fix" this:

     1. Contact the upstream for the repository and get them to fix the problem.

     2. Reconfigure the baseurl/etc. for the repository, to point to a working
        upstream. This is most often useful if you are using a newer
        distribution release than is supported by the repository (and the
        packages for the previous distribution release still work).

     3. Run the command with the repository temporarily disabled
            yum --disablerepo=susemanager:remi-php72 ...

     4. Disable the repository permanently, so yum won't use it by default. Yum
        will then just ignore the repository until you permanently enable it
        again or use --enablerepo for temporary usage:

            yum-config-manager --disable susemanager:remi-php72
        or
            subscription-manager repos --disable=susemanager:remi-php72

     5. Configure the failing repository to be skipped, if it is unavailable.
        Note that yum will try to contact the repo. when it runs most commands,
        so will have to try and fail each time (and thus. yum will be be much
        slower). If it is a very temporary problem though, this is often a nice
        compromise:

            yum-config-manager --save --setopt=susemanager:remi-php72.skip_if_unavailable=true

failure: repodata/repomd.xml.asc from susemanager:remi-php72: [Errno 256] No more mirrors to try.
https://hun25-14v.hft.local:443/rhn/manager/download/remi-php72/repodata/repomd.xml.asc: [Errno 14] HTTPS Error 404 - Not Found

A Channel/repo mind1, itt pl a remi, de a centos main re is csinalja, vagy akamelyik masikra (full random, neha tobbre is).

Ha torlom a repodata cache-t a /var/cache/rhn/repodata konyvtarbol (az osszes konyvtarat itt) majd nyomok egy mgr-sign-metadata-ctl regen-metadata -t konzolbol, akkor helyrejon, ideig oraig (szo szerint, neha 3-4 oran belul megint xar)

Esetleg valaki tapasztalt mar ilyet? Githubon is nyitottam mar issue-t, de ahogy latom uyuni mogott nem igazan eros a kozosseg...

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