Szerintem ez már script.
Vagy esetleg find -type f -mtime -3 &&find -type f -mtime +3 -exec rm -f {} \; , ha esetleg ez elég.

Nyilván először rm helyett ls-sel futtasd (Kipróbáltam, blikkre működik, de nagyon nem néztem.)

[ Szerkesztve ]

Mutogatni való hater díszpinty

Ez akkor is törli a 3 napnál régebbieket, ha nincs újabb, szóval szvsz előbb kell egy listát csinálni a tényleg törlendő fileokról, aztán végrehajtani a törlést (előbb persze ls-sel tesztelve).

https://www.coreinfinity.tech

OK, nem volt időm meg sok file-om nagyon megnézni. Úgy voltam vele, hogy ha talál 3 napnál újabbat, akkor van, és lehet törölni a régebbieket.

Mutogatni való hater díszpinty

Az én linux ismeretem addig terjed, h find ./dir -mtime +3 -type f -delete, de ezzel ugye az a baj, h ha véletlen leáll a napi mentés akkor 3 nap múlva már egyáltalán nem lesz mentésem

̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿

"Az első find után egy |grep a filenév egy részére esetleg?" - ez mire lenne hivatott? Mármint vágom h mit csinál, de ha a könyvtárban csak a backup fileok vannak akkor van rá szükség?

̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿

A find mindig sikeresen lefut, ezért mondta Sh4d0w, hogy mindig törölne. Ha rágrepelsz a filenév egy részére (arra, ami nem változik), akkor ha nincs újabb file, akkor sikertelen kimenetet ad, és nem fog lefutni a második find. Ha van újabb file, akkor a grep kimenete "sikeres" lesz, és továbbengedi a cuccot.
(Parancs && parancs : akkor fut a második, ha az első 0-val tért vissza, és a find mindig 0-val tér vissza A másik ilyen érdekes állat a pl. ping, aminek szintén össze-vissza visszatéréi értékei vannak.)

[ Szerkesztve ]

Mutogatni való hater díszpinty

Vissza kellene állni régebbi Sambára?

nem létezik freebsd alapú linux.
a problémát pedig úgy lehet megoldani, hogy vagy szétrakod napi könyvtárakba a mentést, vagy minden fájlról csinálsz egy listát, és a másodiktól kezdve törlöd.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Köszi,

este kipróbálom!

Bambano: sajnos nem tudja a backuper külön mappába tenni.

̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿

Mi a rák az, hogy FreeBSD alapú Linux? Erre az egészre amúgy bash scriptet kell írni, és azt ütemezett feladatként futtatni vagy szolgáltatást kell írni, ami egy fokkal komplikáltabb, de az sem annyira nehéz. Szerintem néhány sorból meg tudod oldani, ha beletanulsz. Bash script helyett egyébként bármilyen programnyelven is megoldható ugyanez. Sőt ha fontos, hogy rendesen működjön, akkor én százszor inkább egy normális nyelven írnám automata tesztekkel.

[ Szerkesztve ]

Buliban hasznos! =]

de ezzel ugye az a baj, h ha véletlen leáll a napi mentés akkor 3 nap múlva már egyáltalán nem lesz mentésem

Szerintem itt rossz az alap koncepció. Mi lenne, ha maga a mentés triggerelné scriptet, de csak miután lefutott, akkor nem lehet ilyen probléma.

én még olyat nem láttam, hogy egy szerveren ne lehessen egy könyvtárat átnevezni.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

"Sőt ha fontos, hogy rendesen működjön, akkor én százszor inkább egy normális nyelven írnám automata tesztekkel.": amit meg lehet írni egy pár soros bash scriptben, arra nem írunk "normális" nyelven programot, pláne automata teszteket, stb.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

+1 Hányszor láttam már ilyet, hogy 20 sor bash/python + egy cron job helyett egy 2000 soros C-ben vagy C++-ban írt daemon

Hát ha nem szempont a helyes működés, és mondjuk jelen esetben az adatvesztés elkerülése, akkor ezek valóban szükségtelenek.

Buliban hasznos! =]

Ugyanúgy pár sor kód lesz a megfelelő könyvtárak használatával.

Buliban hasznos! =]

Bash is teljesen jól működik, ha jól van megírva. Rossz programot meg bármiben lehet írni (tapasztalat )

Mutogatni való hater díszpinty

Természetesen jól működik, csak az egyik esetben erre a bizonyíték a te szavad, a másik esetben meg az, hogy átmegy a működést ellenőrző teszteken. Egyébként bash-t is lehet automatizáltan tesztelni, mint minden mást: [link] [link] Én csak azért szeretem a komolyabb nyelveket, mert ott több a nyelvi eszköz és a kód amit kapok is könnyebben megérthető, nem kell agyon kommentelni, plusz nem függ annyira a környezettől, hogy rendesen működik, mint egy bash scriptnél. De ez valamenyire ízlés, feladat kérdése. Ha nem tud nagy kárt okozni, akkor egy teszteletlen bash script is jó lehet, csak pl egy törlés tipikusan olyasmi, amit ha elcseszel, abból komoly károk lehetnek.

[ Szerkesztve ]

Buliban hasznos! =]

Nos, egy otthoni felhasználású scriptet bizonyára automatizáltan szoktak tesztelni.
Amúgy tudom, hogy mi az a szoftvertesztelés, de egy átlagos munkahelyen a sysadminok scriptjeit nem szokás különösebben tesztelni, általában elég, ha jól működnek.
Az előző helyemen meg kötve hiszem, hogy a cég hivatalos belső ellenőrző scriptjei bármilyen tesztelésen átmentek volna, olyan trágyák voltak

Mutogatni való hater díszpinty

Persze vágom, hogy mi az általános gyakorlat, de attól még nem lesz helyes valami, hogy mindenki úgy csinálja.

[ Szerkesztve ]

Buliban hasznos! =]

Akkor most én leszek közgazdász kicsit, szóval olyan scriptek, amiket 1-5 ember használ kb. arra, hogy ne kelljen mindig ugyanazt begépelni, azoknak mégis hol érné meg a mindenre kiterjedő tesztelése?

Mutogatni való hater díszpinty

Ha megnézed az eredeti kérdést, semmi szó nem esik arról, hogy milyen fontosságú a dolog, hányan használják, milyen adatokról van szó: [link] Én továbbra is tartom, hogyha fontos az adat vagy a helyes működés, akkor tesztelni kell a kódot. Ha nem fontos, akkor azt csinálsz, amit akarsz. Hogy a kérdésre is válaszoljak, akkor éri meg ezeknek a tesztelése, ha egy elgépelés miatt lecsukhatnak x évre vagy rádvernek egy több milliós bírságot, de akár már akkor is megéri, ha csak otthon mókolsz valamin, és számodra pótolhatatlan adat veszhet el miatta. Szóval ez inkább biztonsági, mint üzemeltetői kérdés, bár van némi átfedés. Szoftverfejlesztői szempontból azért jó automatizáltan tesztelni, mert az utólagos tesztek nélküli hibakeresés sokkal tovább tart, de ez pár soros szkripteknél annyira nem szempont. Én mondjuk már megszokásból csinálom ebből a szempontból rövidebb kódnál is, mert rühellek debuggolni. No mondjuk én sem szoktam a unit tesztek szintjére lemenni, mert ott több lesz a teszt, mint a futó kód, de azért alapvető dolgokat mindig kitesztelem legalább néhány e2e vagy integrációs teszttel.

[ Szerkesztve ]

Buliban hasznos! =]

Nem egészen. Valamilyen shelled van, tehát annak a használata nem jelent sem addicionális telepítést, sem extra kockázatot. Ellenben ha akár csak pythonban készítesz valamit, akkor kell az intepreter plusz a modulok, amelyekkel megoldod a feladatot - ez mind plusz telepítés és kockázat, plusz ha binárisba fordítod, aránytalanul nagy lesz.

Most is nyomozok egy érdekes, kábé naponta ismétlődő kapcsolat után, aminek nincs tulajdonosa. Megírhattam volna pythonban a monitoringját, de mivel a shell kéznél van és az egész 7 sor, nem vacakoltam vele - pláne, hogy prod szerver.

[ Szerkesztve ]

https://www.coreinfinity.tech

Ma jutottam el oda, hogy ki is próbáljam. A VS2019 telepítése után 2 perccel már ment a távoli debug a Raspberry-n, nem sokkal később meg már érdemben programoztam is rajta. Nem hittem a szememnek, hogy ez ennyire könnyű is lehet és a dolog ráadásul kétirányú, mert behozza PC-re a raspberry-n lévő libraryket, mintha itt állnának a projekt mappájában.

Köszi a tippet!

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

Jó, innen nézve igaz, hogy nem rántasz be új függőségeket. Szóval akkor ez nekem csak egyéni kényelmi szempont, hogy más nyelveket jobban szeretek, mert jobban megszoktam őket, és akkor ebben igazuk van. A tesztelés része viszont megoldható bash-re is és az már biztonsági kérdés is lehet, hogy tesztelt e a kód, ami fut.

Buliban hasznos! =]

Akkor oszd meg kérlek a megoldást, köszi.

̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿

Egyébként úgy rémlik, hogy komolyabb helyeken össze szokták szedni az ilyen üzemeltetői szkripteket, daemonokat is és dokumentálni szokták, hogy melyik mit csinál, mert azok is cégen belül használt szoftvernek számítanak, aztán ha a kolléga lelép, akkor ott fognak futni a háttérben olyan dolgok, amikről senkinek nincs fogalma, hogy mit csinálnak, de lelőni sem merik őket, nehogy valami eltörjön.

[ Szerkesztve ]

Buliban hasznos! =]

"meg tudod oldani ha beletanulsz." - köszi, te is sokat segítettél.

̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿

overengineeringnek hívják.
a unix alapfilozófiája : KISS. Keep It Stupid and Simple.

"Természetesen jól működik, csak az egyik esetben erre a bizonyíték a te szavad, a másik esetben meg az, hogy átmegy a működést ellenőrző teszteken": amely tesztek adekvát voltára a bizonyíték a te szavad, de legalább egy rakás melót belefeccöltél.

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

azért kanyarodjunk már vissza a kezdetekhez: biztonsági másolatot akar verziózva úgy, hogy a kliens oldalhoz nem tud hozzányúlni.
Erre egy lehetséges megoldás, hogy a szerveren létrehoz napi mappákat például Sun Mon stb. neveken, majd cronból minden nap lefuttat egy:

rm -f backup
ln -s $(LANG=C date '+%a') backup

utasításpárt. Ezen a bonyolultsági szinten nem írunk unit tesztet, pláne nem otthoni felhasználáskor, nem tervezünk projektet a megvalósítására, nem tűzünk ki a projekben mérföldköveket, nem csinálunk drp-t, bcp-t, nem készül projekt alapító dokumentum, nem írjuk le hetven oldalban a projekt termék elfogadási kritériumait, stb. hanem odaülünk a konzolhoz és bevésünk egy sort a crontabba. hasonló módon nem írunk maven szkriptet ötven gigabájtnyi függőség és könyvtár letöltéséhez, nem használunk hatféle keretrendszert, nem használunk mvc framewörköt, perzisztencia réteggel és különösen nagyon határozottan nem rakunk fel dockert egy tetves link létrehozására. kubernetest se. érthető okból nem illesztjük a rendszert távmenedzsment cuccokhoz, még Muninhoz se.

A személyes tapasztalatomban minden túltervezett projekt becsődölt.
A segítségem nélkül is...

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

python pl hol nincs kéznél?

Nagyon jó, csak az overengineering egyáltalán nem ezt jelenti. Az overengineeringnél túl magas absztrakciós szintre teszel dolgokat, túláltalánosítod őket teljesen feleslegesen. Jelen esetben viszont két ugyanazt a dolgot csináló eszköz közül választom a számomra kényelmesebbet. A háttérben a unix parancssori eszközök meg amiket használt tök ugyanazt fogják csinálni, mint egy általam választott programnyelven berántott könyvtárak.

A tesztekkel kapcsolatban bárki ellenőrizheti a tesztelési módszereket és futtathatja újra a teszteket szemben a te szavaddal, aminél semmi info nincs arról, hogy hogyan tesztelted vagy hogy egyáltalán tesztelted e bárhogyan.

[ Szerkesztve ]

Buliban hasznos! =]

Az eredeti kérdésben nem szerepelt az otthoni környezet, de később említette

"Hogy a kérdésre is válaszoljak, akkor éri meg ezeknek a tesztelése, ha egy elgépelés miatt lecsukhatnak x évre vagy rádvernek egy több milliós bírságot,"
Ehhez képest az ilyesminek gyak. egy cégnél sem látom a tesztelését. Ennyi erővel azt is felügyelhetnéd, hogy az admin mit gépel. Mondjuk van, ahol próbálták, pár év után elég lett, és felmondtam, mert 2:1 volt az adminisztráció a tényleges munkával.
Mit beszélek, oktatás se szokott lenni, felvesznek, 2 nap múlva root jog Komplett környezetek úgy rárakása csapatokra, hogy sosem láttak olyan OS-t, middleware-t, semmit Jó esetben csak én jártam néhány ilyen helyen, és nem a túlnyomó többség ilyen

Komolyabb helyeken össze szokták szedni - elméletben gondolom, bár remélem, hogy van, ahol tényleg Meg azt se hiszem, hogy az olyan szintű dolgokat szedik össze, amiket páran használnak, senkinek az orrára nem kötve. A komolyabban használt dolgokat persze össze kell, de az egy másik szint.

[ Szerkesztve ]

Mutogatni való hater díszpinty

Persze ebben egyetértünk, hogy egy kétsoros otthoni kódnál nincs szükség komplett fejlesztő csapat felállítására.

[ Szerkesztve ]

Buliban hasznos! =]

Ez addig rendben van, amíg nem iratnak veled alá nyilatkozatot azzal kapcsolatban, hogyha ilyen módon kárt okozol a cégnek, akkor te állod a költségeket. Szerintem csak idő kérdése amúgy, hogy egy cég mikor kezdi el biztonsági szempontból egy kicsit komolyabban venni magát.

Buliban hasznos! =]

Hát... ez egy igen nagy múltú cég, bár lehet ezért koptak ki az értelmes emberek mára
Ám ott - legalábbis a belső infrás részeken - nem volt ilyen nyilatkozat, pedig ott is volt olyan support (nem is egy) ami regionális, vagy globál cuccokra ment. Ügyfélrendszereken lehet, de ott sem említett senki ilyet.
Meg mérlegelni kell, hogy egy ilyen nyilatkozat mennyi fizunál éri meg...

Mutogatni való hater díszpinty

Ja hát igen, mérlegelni kell. Néha belefűzik a szerződés szövegébe.

Buliban hasznos! =]

Ez tökjó! Érdekes! Milyen jót lehetnre ezekről a linuxos offba dumálgatni.

Nem félünk! Nem félünk! Itthon vagyunk e földön. Nem félünk! Nem félünk! Ez nem maradhat börtön!

Ja bocs, már itt sem vagyok. :-)

Buliban hasznos! =]

Most már kiváncsi vagyok mi a számodra kényelmesebb, de tényleg Mert tök jó, volt itt szó libekről, meg mindenről, de hogy te miben akarnád megírni a dolgot arról nem.

Itt egysoros find + parancs a feladat, plusz max. 1-2 if.

[ Szerkesztve ]

Például sehol, ahol csak a funkcióhoz szükséges csomagok vannak telepítve (vagy bambano valamelyik szervere).

https://www.coreinfinity.tech