Sziasztok!
Otthoni "fat" ubuntu serveremen levo szolgaltatasaim kb 99%-at mar atmigraltam Docker ala. Most keresek valami kimondottan kontenerek ala keszult distrot. Ezeket neztem eddig:
- Fedora CoreOS
- Flatcar Container Linux
- openSUSE MicroOS
Managelni Portainer-el szoktam (bar ez sokat nem szamit)
Ti ajanlotok esetleg ezek kozul valamit, vagy ismertek meg hasonlot?
Sziasztok!
Megküzdöttem a https://hup.hu/node/181159 bejegyzésben említett problémával. Többmilló fájlt és többtízezer POSIX ACL-t migráltam a convmv parancs, illetve megfelelő chroot környzetekben futtatott getfack/setfacl párosokkal. Néhány hét használat után azonban észrevettem, hogy a SaMBa (4.16.4) mintha felesleges POSIX ACL bejegyzéseket generálna. Először egy Word dokumentumnál bukott ki a probléma: Azt vettem észre, hogy amikor egy (esetleg más által tulajdonolt fájlt) szerkesztek, akkor a Word egy új fájl hoz létre, majd mentéskor törli az eredetit, az újat pedig átnevezi és megpróbálja a jogosultságait az eredetihez hasonlóra beállítani. A jogosultságok/Windows ACL-ek szerkesztése viszont gyakorlatilag mindig ahhoz vezet, hogy (szerintem) felesleges bejegyzések tömege kerül a POSIX ACL-be.
Pl. a file.docx nevű fájl eredeti jogosultsági beállításai így néztek ki:
# file: file.docx
# owner: user_2 #Valaki más, nem én.
# group: group_2 #A tulajdonos egyik csoportja (nem elsődleges).
user::rw-
group::rw-
other::rw- #Az írást számomra lehetővé tevő jogosultsági bitek.
Két MS Word-os szerkesztés után így néz ki a fájl POSIX ACL-je (ez persze már nem ugyanaz a fájl, mert a Word újat hozott létre, majd mentéskor törölte az eredeti fájl, az újat pedig átnevezte, és megpróbálta rá átvinni az eredeti fájl jogosultságait):
# file: file.docx
# owner: user_1 #Az új fájl már az én tulajdonomban van.
# group: domain\040users #Az én elsődleges csoportom.
user::rw-
user:domain\040users:rw- #Az elsődleges csoportom GID-je hozzáadva az UID-ek listájához. Nyilván nincs ilyen nevű user.
user:user_2:rw- #Az eredeti fájl tulajdonosa.
user:group_2:rw- #Az eredeti tulajdonos csoport GID-je hozzáadva az UID-ek listájához. Nincs ilyen nevű user.
group::rw-
group:domain\040users:rw- #A tulajdonos GID még egyszer hozzáadva. Nem felesleges?
group:user_1:rw- #Az én UID-em hozzáadva a GID-ek listájához. Nincs ilyen nevű csoport.
group:user_2:rw- #Az eredeti tulajdonos UID-je hozzáadva a GID-ek listájához. Nincs ilyen nevű csoport.
group:group_2:rw- #Az eredeti tulaj csoport.
mask::rwx
other::rw-
Fájlkezelővel is megpróbáltam egy könyvtáron dolgozni. user_1-ként létrehoztam egy könyvtárt, amely az alábbi jogosultságokkal jött létre:
# owner: user_1
# group: domain\040users
user::rwx
group::rwx
other::---
Ezután nem csináltam mást, mint írási jogot adtam a könyvtárra az user_2 felhasználó számára, de ezen felül (szerintem) felesleges és hibás ACE-k adódtak hozzá a POSIX ACL-hez:
# file: directory_name
# owner: user_1
# group: domain\040users
user::rwx
user:domain\040users:rwx #UID-ként hozzáadott GID. Nincs ilyen nevű user.
user:user_2:rwx #Csak ezt a jogosultságot szándékoztam hozzáadni.
group::rwx
group:domain\040users:rwx #A tulajdonos GID még egyszer hozzáadva. Nem felesleges?
group:user_1:rwx #GID-ként hozzáadott UID. Nincs ilyen nevű csoport.
group:user_2:rwx #GID-ként hozzáadott UID. Nincs ilyen nevű csoport.
mask::rwx
other::---
A kérdésem annyi, hogy van-e elképzelésetek arról, miért kerül ez sok - látszólag - felesleges információ a POSIX ACL-be, és főként az, hogy miért veszi fel a POSIX ACL-be a SaMBa az UID-eket GID-ként és viszont?
Rocky 8, iptables. Szeretném tudni egy DROP szabály esetén melyik program hozta létre azt a csomagot, ami fennakadt a tűzfalon. Mert látok sok DROP üzenetet valami cél IP-vel, de hogy ki akart kapcsolódni, no azt nem tudom. És hát szeretném tudni, hogy melyik programot kell megnéznem, miért próbál csatlakozni. Ha esetleg az nftables tudja, akkor maximum (vissza)váltok rá. Kerestem neten, nem találtam megoldást, kérdezek.
Mindenkinek eddig és majd ezután is köszönöm a segítséget, egyszerű megoldást próbáltam találni, de akkor úgy látom kicsit bonyolultabb lesz, végignézem a lehetőségeket.
Sziasztok!
Hosszabb távon tervezés céljából gyűjtögetek információt, ki mit hallott-látott ebben a témakörben.
A problémakör röviden: Adott nagyságrendileg 20-25TB adat, ami sok-sok kis fájlból áll össze. A fájlok mérete a párszáz Kb-tól mondjuk 20-30Mb-ig terjed. Számosságukat tekintve ebben a pillanatban 33 millió fájlról beszélünk. Ez a mennyiség okos könyvtárstruktúrával még a kezelhető szinten mozog, de a jövőben ez nőni fog és már most is hatalmas gondot okoz egy-egy fsck, netán egy fs hiba. Úgy fogalmaznék, hogy kockázati tényezőt látok az FS alapú tárolásban lassan. Még amellett is, hogy az említett fájlrendszert kvázi replikáljuk, tehát egy 2 napos fsck esetén be tud állni a replika kiszolgálni az éles rendszereket.
Ezeket a fájlokat jelenleg http-n szolgáljuk ki (internal), úgy h. az alkalmazás tudja mit kell letöltsön egy index DB alapján.
Olyan megoldást keresek vagy képzelek el, ami:
Köszönöm h. végigolvastad, hátha lesznek jó tippek :)
Zoli
Van valakinek mukodo (free) rtmp URL-je a netrol? valami TV vagy streaming szllgaltatotol... tesztelesi celokra
A korabban hasznalt rtmp stream-jeim egyszeruen "eltuntek"....;)
Sziasztok,
meg tudna valaki magyarazni, mi alapjan futnak le a kubernetes job-ok?
Van egy konyvtaram python szkriptekkel.
Hogyan lehet barmelyik inditasakor kubernetes job-ot letrehozni es lefuttatni az eredmenyt pedig egy logfile-ba irni
(mountolt pvc - ami tartalma pod delete eseten megmarad.)
Koszonom a segitseget.
Ardi
Hali!
Megjelent a Docker CE 24-es verziója néhány napja, ami frissítéskor, bekapcsolt live-restore mellett összekuszálta a hálózatot. A konténerek egy network-ben DNS-sel, a konténernév alapján találták meg egymást, a frissítés után ez megszűnt.
Gondoltam én, egyszeri probléma, szépen újracsináltam mindent. Majd tegnap kijött a 24.0.1 és pontosan ugyanerre ébredtem. Egy AlmaLinux-os cPanel VPS automatikus frissítésének hála reggelre megint minden elesett Docker-ben. Probléma ugyanez, a megoldás is. Network-ök kitakarítása, újralétrehozása és megy tovább.
Több Debian gépen is kijött, de ott nem automatikus a frissítés, szóval késő este lehetett vele mojolni.
Más is tapasztalta? Fura, hogy két gépen is kijött, de itt és más fórumokon sem találtam róla említést - ami persze nem jelenti, hogy nem is volt.
Sziasztok!
Telepítettem egy Proxmox VE-t és egy Proxmox Backup Servert. Szeretnék létrehozni egy Proxmox Backup Server Storge-et a VE-n, de hibát jelez:
create storage failed: pbsid: error fetching datastores - 500 Can't connect to 1.2.3.4:8007 (Connection reset by peer) (500)
Tudom pingelni is a VE-ről a PBS-t, valamint a
telnet 1.2.3.4 8007
is működik.
Próbáltam egy debian hostról a
proxmox-backup-client login --repository 1.2.3.4:datastore
parancsot, ami szintén hibát adott:
Password for "root@pam": **********
Error: error trying to connect: Connection reset by peer (os error 104)
A PBS logjaiban nem találtam nyomát a csatlakozási kísérletnek.
Nem találtam kernel topikot, talán itt elfér a kérdés. Hogy áll mostanában btrfs a raid-ekkel? Korábban nem volt ajánlott a RAID-5 vagy a 6, ez fennáll még? Egy kis gépen kipróbálnám ha már a régebben ismert adatvesztési anomáliák nem jellemzőek...
Sziasztok,
adott egy OwnCloud amit Active Directory -hoz kellene illeszteni (MS AD), de az istenert nem akarja, mar szetgoogleztam magam...
Esetleg van valakinek mukodo konfigja?
A jelenlegi konfig a lenti kepeken lathato, 0 usert talal, a teszt userrel pedig -5 eredmenyt ad vissza...
https://mirror4.fazekas-bereczki.com/oc/1.png
https://mirror4.fazekas-bereczki.com/oc/2.png
https://mirror4.fazekas-bereczki.com/oc/3.png
Koszi!
