UNIX haladó

Xigmanas (FreeBSD + HAST) szinkron hiba.

Fórumok

Sziasztok!

Belefutottam egy érthetetlen jelenségbe, és nem találok semmit róla.

Adva van két Xigmanas rendszer.

Azon felkonfiguráltam a HAST + CARP-ot.

Amikor az elején kézzel inicializálom a master slave-et:

hastctl role init da1
hastctl create da1

hastctl role primary da1

...

akkor minden rendben, lefut a szinkron és tartja is amíg hozzá nem nyúlok a konfighoz.

Viszont amint kézzel átváltanék, ott már gond van. Vagy akár ha eltűntetem a mastert (kikapcsolom) és a visszajön, ött is teljes a fejetlenség az eredetileg secondary server részéről.

Olyan mint ha nem tudnának kommunikálni, pedig az első inicializálásnál lefut a szinkron.

Kézi átváltásnál az alábbit mondják:

Master:

Feb 17 12:17:07 xenstorage1 kernel: carp: 1@bge0: MASTER -> INIT (hardware interface up)
Feb 17 12:17:07 xenstorage1 kernel: bge0: promiscuous mode disabled
Feb 17 12:17:07 xenstorage1 kernel: bge0: promiscuous mode enabled
Feb 17 12:17:08 xenstorage1 kernel: carp: demoted by 240 to 240 (interface down)
Feb 17 12:17:08 xenstorage1 kernel: bge0: link state changed to DOWN
Feb 17 12:17:08 xenstorage1 root: /etc/rc.d/netif: WARNING: $ifconfig_bge0_alias1 needs leading "inet" keyword for an IPv4 address.
Feb 17 12:17:11 xenstorage1 kernel: carp: 1@bge0: INIT -> BACKUP (initialization complete)
Feb 17 12:17:11 xenstorage1 kernel: carp: demoted by -240 to 0 (interface up)
Feb 17 12:17:11 xenstorage1 kernel: bge0: link state changed to UP
Feb 17 12:17:11 xenstorage1 carp-hast: Switching to secondary provider for da1. (carp=backup)
Feb 17 12:17:11 xenstorage1 carp-hast: Stopping services and unmounting disks.
Feb 17 12:17:13 xenstorage1 hastswitch: Unmount /dev/ufsid/6203b9055c61153b (/dev/hast/da1p1) from /mnt/xendrive.
Feb 17 12:17:15 xenstorage1 kernel: carp: 1@bge0: BACKUP -> MASTER (master timed out)
Feb 17 12:17:17 xenstorage1 kernel: carp: 1@bge0: MASTER -> BACKUP (more frequent advertisement received)
Feb 17 12:17:17 xenstorage1 mDNSResponderPosix: Default: mDNSCoreReceiveResponse: Received from 10.0.99.106:5353 19 110.99.0.10.in-addr.arpa. PTR xenstorage2.local.
Feb 17 12:17:17 xenstorage1 mDNSResponderPosix: Default: mDNSCoreReceiveResponse: Unexpected conflict discarding 19 110.99.0.10.in-addr.arpa. PTR xenstorage1.local.
Feb 17 12:17:18 xenstorage1 carp-hast: Role switched to secondary for resource da1.
Feb 17 12:17:18 xenstorage1 kernel: GEOM: da1: corrupt or invalid GPT detected.
Feb 17 12:17:18 xenstorage1 kernel: GEOM: da1: GPT rejected -- may not be recoverable.
Feb 17 12:17:18 xenstorage1 carp-hast: Switching to primary provider for da1. (carp=backup)
Feb 17 12:17:24 xenstorage1 1 2022-02-17T12:17:24.672456+01:00 hastd: da1 (primary) hastd 7099 - - [da1] (primary) Unable to receive handshake header from 192.168.77.2: Socket is not connected.
Feb 17 12:17:24 xenstorage1 carp-hast: Role for HAST resources da1 switched to primary.
Feb 17 12:17:24 xenstorage1 carp-hast: Mounting disks and strting services.
Feb 17 12:17:24 xenstorage1 hastswitch: Mount /dev/ufsid/6203b9055c61153b (/dev/hast/da1p1) on /mnt/xendrive.
Feb 17 12:17:25 xenstorage1 kernel: carp: 1@bge0: BACKUP -> MASTER (user requested via ifconfig)
Feb 17 12:17:25 xenstorage1 mDNSResponderPosix: Default: mDNSCoreReceiveResponse: Received from 10.0.99.106:5353 19 110.99.0.10.in-addr.arpa. PTR xenstorage2.local.
Feb 17 12:17:25 xenstorage1 mDNSResponderPosix: Default: mDNSCoreReceiveResponse: Unexpected conflict discarding 19 110.99.0.10.in-addr.arpa. PTR xenstorage1.local.
Feb 17 12:17:25 xenstorage1 carp-hast: Switching to secondary provider for da1. (carp=master)
Feb 17 12:17:25 xenstorage1 carp-hast: Stopping services and unmounting disks.
Feb 17 12:17:26 xenstorage1 hastd: [da1] (primary) We act as primary for the resource and not as secondary as requested by tcp://192.168.77.2:25781.
Feb 17 12:17:27 xenstorage1 hastswitch: Unmount /dev/ufsid/6203b9055c61153b (/dev/hast/da1p1) from /mnt/xendrive.
Feb 17 12:17:27 xenstorage1 hastd: [da1] (primary) We act as primary for the resource and not as secondary as requested by tcp://192.168.77.2:40935.
Feb 17 12:17:28 xenstorage1 hastd: [da1] (primary) We act as primary for the resource and not as secondary as requested by tcp://192.168.77.2:13992.
Feb 17 12:17:29 xenstorage1 hastd: [da1] (primary) We act as primary for the resource and not as secondary as requested by tcp://192.168.77.2:26842.
Feb 17 12:17:30 xenstorage1 hastd: [da1] (primary) We act as primary for the resource and not as secondary as requested by tcp://192.168.77.2:30531.

 

Secondary:

 

Feb 17 12:17:14 xenstorage2 kernel: carp: 1@bge0: BACKUP -> MASTER (master timed out)
Feb 17 12:17:14 xenstorage2 carp-hast: Switching to primary provider for da1. (carp=master)
Feb 17 12:17:22 xenstorage2 1 2022-02-17T12:17:22.343336+01:00 hastd: da1 (secondary) hastd 66982 - - [da1] (secondary) Unable to receive request header: Socket is not connected.
Feb 17 12:17:22 xenstorage2 kernel: GEOM: da1: corrupt or invalid GPT detected.
Feb 17 12:17:22 xenstorage2 kernel: GEOM: da1: GPT rejected -- may not be recoverable.
Feb 17 12:17:27 xenstorage2 hastd: [da1] (secondary) Worker process exited ungracefully (pid=66982, exitcode=75).
Feb 17 12:17:29 xenstorage2 mDNSResponderPosix: Default: mDNSCoreReceiveResponse: Received from 10.0.99.105:5353 19 110.99.0.10.in-addr.arpa. PTR xenstorage1.local.
Feb 17 12:17:29 xenstorage2 mDNSResponderPosix: Default: mDNSCoreReceiveResponse: Unexpected conflict discarding 19 110.99.0.10.in-addr.arpa. PTR xenstorage2.local.
Feb 17 12:17:30 xenstorage2 kernel: carp: 1@bge0: MASTER -> BACKUP (more frequent advertisement received)
Feb 17 12:17:30 xenstorage2 1 2022-02-17T12:17:30.663284+01:00 hastd: da1 (primary) hastd 67211 - - [da1] (primary) Remote node acts as primary for the resource and not as secondary.
Feb 17 12:17:30 xenstorage2 1 2022-02-17T12:17:30.663317+01:00 hastd: da1 (primary) hastd 67211 - - [da1] (primary) Waiting for remote node to become secondary for 20s.
Feb 17 12:17:31 xenstorage2 mDNSResponderPosix: Default: mDNSCoreReceiveResponse: Received from 10.0.99.105:5353 19 110.99.0.10.in-addr.arpa. PTR xenstorage1.local.
Feb 17 12:17:31 xenstorage2 mDNSResponderPosix: Default: mDNSCoreReceiveResponse: Unexpected conflict discarding 19 110.99.0.10.in-addr.arpa. PTR xenstorage2.local.
Feb 17 12:17:31 xenstorage2 1 2022-02-17T12:17:31.727691+01:00 hastd: da1 (primary) hastd 67211 - - [da1] (primary) Remote node acts as primary for the resource and not as secondary.
Feb 17 12:17:32 xenstorage2 1 2022-02-17T12:17:32.761985+01:00 hastd: da1 (primary) hastd 67211 - - [da1] (primary) Remote node acts as primary for the resource and not as secondary.
Feb 17 12:17:33 xenstorage2 1 2022-02-17T12:17:33.826060+01:00 hastd: da1 (primary) hastd 67211 - - [da1] (primary) Remote node acts as primary for the resource and not as secondary.
Feb 17 12:17:34 xenstorage2 1 2022-02-17T12:17:34.887185+01:00 hastd: da1 (primary) hastd 67211 - - [da1] (primary) Remote node acts as primary for the resource and not as secondary.

Olyan mint ha nem tudnának kommunikálni. De a fenti parancsok kiadásánál az elején mégis szinkronizál.

A HAST verziók stimmelnek, a két meghajtó mérete egyezik. A kommunikációjuk bge2-n történik. A CARP cím a bge0-án van, a host.conf kitöltve.

Van esetleg bárkinek bármi tippje?

Üzemben lévő rendszerből POSIX ACL-ek listájának "formába" öntése ?

Fórumok

Üdv,

Adott egy samba alapú fájlmegosztásos móka, semmi extra, se AD, se semmi. Se LDAP.

Sima unix user / groupok vannak POSIX ACL-ekkel kiegészítve.

Van egy megosztás /opt/samba néven, ez alatt van egy perpill üzemelő megosztás, rengeteg könyvtárral / fájllal / miegymás. 

Ki kellene nyernem az összes ACL-t ami könyvtárakra vonatkozik és valamilyen "ember által emészthető" formátumba bele kellene gyömöszölnöm. Könyvtár mélységig 8 lenne az a mélység amire le kellene menni.

A végeredményre valami olyasminek kellene kijönnie, hogy mittudomén:

/opt/samba/egyik konyvtar/alatta levo konyvtar/valami/ - xycsoport rwx - xyuser r-x - zuser rwx 
/opt/samba/egyik konyvtar/alatta levo konyvtar/ - xycsoport rwx - xyuser r-x - zuser rwx - yuser r-x

stb.

Ha lekérem a könyvtár listát 8 depth-re, akkor kapok kb egy ~1.4millió soros txt-t ... amit eléggé nehéz feldolgozni kézzel :)

Ha esetleg valakinek kellett már ilyesmit csinálni és esetleg vannak eldugott scriptjei ilyesmire, akkor kérem ne tartsa magában :)

A vége úgy is az lesz, hogy majd összetákolom magam rá a scripteket / egyebeket, de ha valaki tud valami "egyszerű" megoldást, azt megköszönném :)

ps.: gyak. egy jogosultság mátrix kellene egy perpill használatban lévő share-ra. Nem export miatt, mert az megoldanám egy .tar -al. Human áttekintésre kellene ez, hogy emberke végignézze a jelenlegi állapotot.

thx

cloud-init - 2 eth (eth0,eth1) definialasa RHEL 7.x

Fórumok

Sziasztok,

cloud-init-tel szeretnenk 2 eth interfecet beallitani.

Tudna valaki segiteni?

#pelda egy interface-re

network-interfaces: |
iface eth0 inet static
address 192.168.1.10
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.254
bootcmd:
- ifdown eth0
- ifup eth0

Koszonom a segitseget.

Ardi

samba update - 2:4.2.14+dfsg-0+deb8u13 - debian jessie ==> stretch ==> buster

Fórumok

Sziasztok,

egy problemaval kuszkodom.

Egy fileszerveren 8.11-rol szeretnek debian busterre (10.x) upgrade-elni, remelve, hogy kijavitom a kovetkezo hibat

a samba-n:

 

Oct 11 15:05:55 fileserver winbindd[2442]: [2021/10/11 15:05:55.762587,  0] ../source3/lib/util_tdb.c:493(tdb_chainlock_with_timeout_internal)
Oct 11 15:05:55 fileserver winbindd[2442]:   tdb_chainlock_with_timeout_internal: alarm (40) timed out for key xxx.YYYLAB.xxx.lab in tdb /var/run/samba/mutex.tdb
Oct 11 15:05:55 fileserver winbindd[2442]: [2021/10/11 15:05:55.762676,  0] ../source3/winbindd/winbindd_cm.c:918(cm_prepare_connection)
Oct 11 15:05:55 fileserver winbindd[2442]:   cm_prepare_connection: mutex grab failed for xxx.YYYLAB.xxx.lab
Oct 11 15:06:01 fileserver winbindd[2351]: [2021/10/11 15:06:01.166782,  0] ../source3/lib/util_tdb.c:493(tdb_chainlock_with_timeout_internal)
Oct 11 15:06:01 fileserver winbindd[2351]:   tdb_chainlock_with_timeout_internal: alarm (40) timed out for key xxx.YYYLAB.xxx.lab in tdb /var/run/samba/mutex.tdb
Oct 11 15:06:01 fileserver winbindd[2351]: [2021/10/11 15:06:01.166987,  0] ../source3/winbindd/winbindd_cm.c:918(cm_prepare_connection)
Oct 11 15:06:01 fileserver winbindd[2351]:   cm_prepare_connection: mutex grab failed for xxx.YYYLAB.xxx.lab
Oct 11 15:06:05 fileserver snmpd[2311]: Connection from UDP: [10.253.52.4]:37256->[10.253.61.75]:161
Oct 11 15:06:37 fileserver winbindd[20797]: [2021/10/11 15:06:37.251279,  0] ../source3/librpc/crypto/gse.c:340(gse_get_client_auth_token)
Oct 11 15:06:37 fileserver winbindd[20797]:   gss_init_sec_context failed with [ The context has expired: Success]
Oct 11 15:06:55 fileserver winbindd[20831]: [2021/10/11 15:06:55.219065,  0] ../source3/lib/util_tdb.c:493(tdb_chainlock_with_timeout_internal)
Oct 11 15:06:55 fileserver winbindd[20831]:   tdb_chainlock_with_timeout_internal: alarm (40) timed out for key xxx.YYYLAB.xxx.lab in tdb /var/run/samba/mutex.tdb
Oct 11 15:06:55 fileserver winbindd[20831]: [2021/10/11 15:06:55.219249,  0] ../source3/winbindd/winbindd_cm.c:918(cm_prepare_connection)
Oct 11 15:06:55 fileserver winbindd[20831]:   cm_prepare_connection: mutex grab failed for xxx.YYYLAB.xxx.lab
Oct 11 15:07:20 fileserver winbindd[2351]: [2021/10/11 15:07:20.210149,  0] ../source3/lib/util_tdb.c:493(tdb_chainlock_with_timeout_internal)
Oct 11 15:07:20 fileserver winbindd[2351]:   tdb_chainlock_with_timeout_internal: alarm (40) timed out for key xxx.YYYLAB.xxx.lab in tdb /var/run/samba/mutex.tdb
Oct 11 15:07:20 fileserver winbindd[2351]: [2021/10/11 15:07:20.210389,  0] ../source3/winbindd/winbindd_cm.c:918(cm_prepare_connection)
Oct 11 15:07:20 fileserver winbindd[2351]:   cm_prepare_connection: mutex grab failed for xxx.YYYLAB.xxx.lab
Oct 11 15:07:23 fileserver winbindd[20797]: [2021/10/11 15:07:23.258058,  0] ../source3/lib/util_tdb.c:493(tdb_chainlock_with_timeout_internal)
Oct 11 15:07:23 fileserver winbindd[20797]:   tdb_chainlock_with_timeout_internal: alarm (40) timed out for key xxx.YYYLAB.xxx.lab in tdb /var/run/samba/mutex.tdb
Oct 11 15:07:23 fileserver winbindd[20797]: [2021/10/11 15:07:23.258259,  0] ../source3/winbindd/winbindd_cm.c:918(cm_prepare_connection)
Oct 11 15:07:23 fileserver winbindd[20797]:   cm_prepare_connection: mutex grab failed for xxx.YYYLAB.xxx.lab
Oct 11 15:07:41 fileserver winbindd[20831]: [2021/10/11 15:07:41.225730,  0] ../source3/lib/util_tdb.c:493(tdb_chainlock_with_timeout_internal)
Oct 11 15:07:41 fileserver winbindd[20831]:   tdb_chainlock_with_timeout_internal: alarm (40) timed out for key xxx.YYYLAB.xxx.lab in tdb /var/run/samba/mutex.tdb
Oct 11 15:07:41 fileserver winbindd[20831]: [2021/10/11 15:07:41.225934,  0] ../source3/winbindd/winbindd_cm.c:918(cm_prepare_connection)
Oct 11 15:07:41 fileserver winbindd[20831]:   cm_prepare_connection: mutex grab failed for xxx.YYYLAB.xxx.lab
fileserver #

 

# dpkg -l|grep samba
ii  python-samba                   2:4.2.14+dfsg-0+deb8u13            amd64        Python bindings for Samba
ii  samba                          2:4.2.14+dfsg-0+deb8u13            amd64        SMB/CIFS file, print, and login server for Unix
ii  samba-common                   2:4.2.14+dfsg-0+deb8u13            all          common files used by both the Samba server and client
ii  samba-common-bin               2:4.2.14+dfsg-0+deb8u13            amd64        Samba common files used by both the server and the client
ii  samba-dsdb-modules             2:4.2.14+dfsg-0+deb8u13            amd64        Samba Directory Services Database
ii  samba-libs:amd64               2:4.2.14+dfsg-0+deb8u13            amd64        Samba core libraries
ii  samba-vfs-modules              2:4.2.14+dfsg-0+deb8u13            amd64        Samba Virtual FileSystem plugins
#

2 windowsos - AD rendszer van a topologiaban es nem tudok AD userkent bejelentkezni a fileszerverre.

 

Megoldja a problemamat a "sima" upgradeles?

 

https://linuxconfig.org/how-to-upgrade-debian-8-jessie-to-debian-9-stre…

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

# dpkg -C
# apt-mark showhold

 cp /etc/apt/sources.list /etc/apt/sources.list_backup

# sed -i 's/jessie/stretch/g' /etc/apt/sources.list

eddig a parancsok vegrehajtva:
----------------------------------------------------------------------
# apt-get update
# apt list --upgradable

# apt-get upgrade
# apt-get dist-upgrade
# aptitude search '~o'

 

Mivel nem vagyok jartas sanba-ban, csak nezem es nezem a

https://www.spinics.net/lists/samba/msg143457.html linket, de nem tudok A-rol Be-re jutni.

Tudna nekem valaki segiteni?

Koszonom elore a segitseget.

Ardi

bash script feladatok

Fórumok

Sziasztok!

Tudna nekem valaki olyan feladatsort adni, ami nem a BASH  alapokról szól, tehát nem a feltételeket, ciklusokat, függvényeket taglalja hanem egyszerűbb, erre épülő feladatsort tartalmaz.

 

Üdv!

ssh bekacsolasa virtualis felhasznalo reszere

Fórumok

Sziasztok,

debian 10 rendszeren root+user mellett virtualis felhasznalok is mukodnek (user be tud jelentkezni ssh-val eth0 porton levo IP-re), amelyek a szerver eth0 portja helyett annak eth1 portjat hasznaljak sftp-re.

beallithato egy bizonyos virtualis felhasznalo reszere, hogy o is be tudjon jelentkezni ssh-val? Guglizok a vegtelensegig, de nem lelem a megoldast.

Koszi elore a segitseget.

Ardi

find grep head felgyorsítása

Fórumok

Van 1 kis makróm, aminek a lényegi része:

dest=$(find ${r} -depth 1 -type d -print |grep -i ${t}|head -1)

Adok neki 2 paramétert, hogy hol mit keressen. Ez úgy 5mp alatt fut most, ezt kéne felgyorsítani. Egyszer már kitaláltam, de az elveszett/ottmaradt valahol.

Arra használom, h gyorsan tudjak navigálni a kacatjaim között, szótöredék alapján is oda tudjon találni.
Ötlet?

Partíció elérhetőség udev event

Fórumok

Sziasztok!

Külső HDD-re kell időnként backupot csinálni, ennek automatizálására úgy gondoltam hogy tök jó lesz az udev event, indít egy scriptet, csatol, backupol, leválaszt, és nem kell kézzel semmit sem csinálni.

Ehhez képest tök megbízhatatlan az egész.... Néha triggerelődik az esemény, néha meg nem. Egyáltalán nem determinisztikus. Több diszk van, kétféle méretben (4 és 8TB, 5-5db), Seagate USB külső HDD-k, mondanám hogy működés szempontjából teljesen mindegy, de nem.

A 4T-os többnyire mennek és indulnak automatán amikor csatlakoztatják a diszket. Talán 1 ami nem. A 8T-sokból viszont egy sem indul, vagy max 1. 10x leellenőriztem az UUID-t, hogy stimmel-e. Volt amelyiken már újrakreáltam a GPT-t, a partíciót, a luks-ot, mindent, semmi nem változott.

A működés az (lenne), hogy az udev triggerelt esemény elindít egy systemd unitot, paraméterben az uuid-vel, ami egy sima simple unit, elindít egy scriptet szintén a diszk uuid-jével, ami majd tudja hogy melyikre mit kell syncelni. De ez mindegy is, mert idáig nem jutunk el.

Szóval a lényeg:


cat 2712c798-7f3a-4884-b394-244aa6dacf37.rules
ACTION=="add", SUBSYSTEM=="block", ATTR{partition}=="1", ENV{ID_FS_UUID}=="2712c798-7f3a-4884-b394-244aa6dacf37", RUN+="/usr/bin/systemctl start backupstart@$env{ID_FS_UUID}"

Csak az UUID más természetesen, illetve ezzel korrelálva a fájlnév, de ez működés szempontjából mindegy.

Próbáltam már csűrni-csavarni, igazából semmi változást nem értem el - pár diszk megy, pár meg nem. Talán annyi, hogy azok a diszkek, amik indulnak automatán, azok mindig, amik meg nem, azok sosem, de erre nem esküszöm meg, lehet csak a véletlen műve.

Ha belépek minden esetben látszik a diszk, a megfelelő uuid-jű partíció, akkor is ha az udev nem indította, kézzel elindítva systemctl start backupstart@akarmi lefut rendben, szóval a rossz a diszk, nem jó az usb port és hasonlók is kizárható.

 

Ötleteket várok: mit csináljak vele?

levelezés kérdés

Fórumok

Van két email cím. Az egyik gmail.com (USA), a másik gmail.hu (HU). S van ugye a ClawsMail. (CM)
No már most. Azt elértem hogy a CM lekérje mindegyikről a leveleket, bár a gmail.hu csak pop3-at kezel. Azt is elértem hogy a gmail.com küldjön levelet a saját smtp szerverén keresztül, viszont a gmail.hu, mivel nincs smtp szervere, így az is a gmail.com smtp-n keresztül küldi ki a levelet.

Meg is érkezik, de feladóként az USA cím van megadva. Tehát ha válaszolok a kapott emailre, akkor az USA beli címre megy a válasz. Ez nem jó. 

Ha a gmail_USA  webes felületén felveszem a magyar fiókot, akkor a CM lehozza a leveleket egy xxx@gmail.hu almappába, de így meg végképp nem tudok a CM-ből írni erről az email címről.

Automatikus válasz az összes e-mail-re

Fórumok

Sziasztok!

Van egy levelezésem dovecot-tal, ahol az a kérés, hogy a postafiókba érkező összes e-mail-re menjen válasz üzenet. Nem jó ha naponta egyszer, hanem mindig mindenre. Ha jól néztem a sieve vacation-seconds extension az én barátom. Elég gyér leírásokat találtam róla. Valaki állított már be ilyet? Kell telepítenem külön valamilyen módon ezt az extensiont? Hol tudom aktiválni? Tippem szerint a dovecot 90-sieve.conf fájljába, de nem vagyok biztos. Utána kézzel kell elkészítenem a .dovecot.sieve fájlt, vagy esetleg a Roundcube-ba is be tudja állítani a felhasználó?

Köszi!

Pöfe