UNIX haladó

Ü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

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

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

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!

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

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?

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?

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.

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

Hi

Egy hét alatt már 4x kifagy az nginx proxy-nk.
Tegnap áttettük Debianról Ubuntura hátha, de úgy is. (frissítve mindent)
Se syslog, se VM szinten nem látunk hibát.. (proci, memória, hálózat, node_exporter, stb.)

Valami ötlet hogy lehetne jobban debuggolni mitől fagy consol szintig ki a gép?