- bitpork: Augusztus 2- szombat jelen állás szerint.
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- eBay-es kütyük kis pénzért
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Chosen: Canon 5D II - portrézás 2025-ben
- Geri Bátyó: B550 szűk keresztmetszet, de mi és miért?
- Fogkefe: elektromos vagy manuális?
- Magga: PLEX: multimédia az egész lakásban
-
LOGOUT
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
-
inf3rno
nagyúr
Ja valahogy így. Ez is egyetemi műszer volt, az előző hallgató tropára szétcseszte, aztán odaadták, hogy mérjek rajta. Utána egy mérés sem volt ismételhető, de azért csak csináljam. A végén már annyira ki voltam akadva és napi 16 órát mértem vele, hogy produkáljak valamit diplomához, hogy figyelmetlenségből én adtam meg neki a kegyelemdöfést. Utána adtak egy régebbi gépet, amin egy hét alatt lemértem amit ezzel 3 hónap alatt nem sikerült.
-
inf3rno
nagyúr
válasz
bambano
#31391
üzenetére
"(3) A kártérítés mértéke nem haladhatja meg a munkavállaló négyhavi távolléti díjának összegét. Szándékos vagy súlyosan gondatlan károkozás esetén a teljes kárt kell megtéríteni." - Ha mondjuk egy kezdő root jogosultsággal törli az összes fájlt, akkor simán rá lehet fogni, hogy súlyosan gondatlan károkozás történt szerintem. Mondjuk nem ő a hibás, hanem aki jogot adott neki, de attól még ő fogja elvinni a balhét.
Én mondjuk csak azt tudom, hogy állami és önkormányzati szervezeteknél az információbiztonsági szabályzatot meg kell ismertetni a munkavállalókkal, és alá kell iratni velük, hogy tudomásul vették, és hogy büntetőjogi felelősséggel tartoznak, ha nem tartják be, illetve ha elmennek a cégtől és adatot szivárogtatnak, akkor is. Illetve külön kihangsúlyozták, hogy erre figyeljünk oda, mert volt már, hogy emiatt nem lehetett felelősségre vonni valakit. -
-
bambano
titán
válasz
inf3rno
#31388
üzenetére
egyrészt aggályos, hogy ilyen nyilatkozat törvényes-e. (2012. évi I. törv. 179. par. 3. bek).
másrészt ha bármit alá akarnak íratni velem, ami a munkaszerződés módosításával jár, akkor az egyrészt kétoldalú egybehangzó akarat kérdése, másrészt ha már módosul a munkaszerződés, akkor más pontok is módosulnak. -
válasz
inf3rno
#31388
üzenetére
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... -
inf3rno
nagyúr
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.
-
válasz
inf3rno
#31374
üzenetére
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. -
inf3rno
nagyúr
válasz
bambano
#31381
üzenetére
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.
-
bambano
titán
válasz
inf3rno
#31370
üzenetére
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 backupln -s $(LANG=C date '+%a') backuputasí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... -
bambano
titán
válasz
inf3rno
#31368
üzenetére
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.
-
inf3rno
nagyúr
válasz
sh4d0w
#31375
üzenetére
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.
-
inf3rno
nagyúr
válasz
sh4d0w
#31375
üzenetére
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.
-
CPT.Pirk
Jómunkásember
válasz
Livius
#31325
üzenetére
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!
-
válasz
inf3rno
#31367
üzenetére
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.
-
inf3rno
nagyúr
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.
-
válasz
inf3rno
#31370
üzenetére
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 -
inf3rno
nagyúr
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.
-
-
-
inf3rno
nagyúr
válasz
Magnat
#31350
üzenetére
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.
-
válasz
Magnat
#31356
üzenetére
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.) -
válasz
Magnat
#31354
üzenetére
Arra gondoltam, hogy csak akkor fusson le a 3 napnál régebbiek törlése, ha van 3 napnál újabb file. Tehát a 3 napnál újabb file-ok listázása ha van ilyen, akkor mehet a törlés. A && csinál annyit, hogy ha egy parancs sikeresen lefutott, akkor lefuttatja a következőt, különben nem.
Az első find után egy |grep a filenév egy részére esetleg?
find -type f -mtime -3 |grep backupnevénekegyrésze&&find -type f -mtime +3 -exec ls -la {} \; -
-
Magnat
veterán
Sziasztok,
tudna abban vki segíteni, h hogyan tudok egy adott könyvtárra kiadni úgy egy törlést, h minden 3 napnál régebbi állományt töröljön, de csak akkor ha az adott könyvtárban van fiatalabb állomány? Napi mentés megy az adott könyvtárba, de azt szeretném megoldani, h ha bármi miatt nem fut le mentés kliens oldalon, akkor se törlődjön 3 nap után az összes, hanem legalább egy mindig maradjon meg. Egy Synology nasról van szó egyébként, ha jól emléxem, ezeken FreeBsd alapú linux fut, ha ez számít.
-
válasz
_kovi_
#31347
üzenetére
Nem látom ezt, de ha a RH se tudja...
Amúgy kernel mikori? Mert erre 2020.03-as bugreport van, a 6.8 meg talán már csak extended-ben támogatott? -
Nem nagyon, főleg nem susén ahol a btrfs az alap fájlrendszer és elég alaposan tesztelt. A ramhiba onnan jött elő amúgy, hogy egyszer jártam így, szétszedte a metadatat, hiába töröltem fájlokat továbbra is tele volt. A régebbi susékon a snapper default configja nem igazán szerencsés, újabbakon már agreszzívebben takarít.
-
-
Hello,
Érdeklődök, mert ismerősék kifogytak az ötletekből.
Linux, amit valami értelmes(?) létforma btrfs-re telepített. (Adatok meg ext4-en.
)
Nemrég elkezdte, hogy boot után pár órával elmegy a / /opt /var /tmp /minden, ami egy Linux működéséhez kell 100% telítettségbe, read-only lesz az összes rendszerpartíció, és telehányja a dmesg-et ilyennel :[2938413.951351] BTRFS: error (device sda2) in btrfs_drop_snapshot:5493: errno=-28 No space left
meg ilyennel :[ 6.335131] BTRFS warning (device sda2): block group 28710010880 has wrong amount of free space[ 6.335135] BTRFS warning (device sda2): failed to load free space cache for block group 28710010880, rebuilding it nowNa most nekem az a meredek, hogy úgy látszanak a rendszerkönyvtárak, mintha külön partíciók lennének, de mind az sda2-n van, és nyilván ezért "telnek fel" egyszerre. Ez valami btrfs feature?
lsof|delete-t persze elfelejtettek nézni
(Amikor még futott a cucc, most meg hétfőig nem férnek hozzá .) Mármint hogy az van-e, hogy valami tényleg teleírja a /-t, de az szerintem látszana a dfkimenetén. Márpedig nem látszik, egyszer csak ilyen lesz :/dev/sda2 40G 21G 0 100% //dev/sda2 40G 21G 0 100% /srv
Nem is megtelik, hanem 0-ra zuhan a szabad hely. WTF
Kapott egyfsckforce-t boothoz, de mintha nem ment volna le a btrfs javítása. Jelenleg el se indul.
Tök olyan, mintha kiesegetne a storage a gép alól, de a storage team szerint nincs ilyen, és más, ugyanonnan futó gépeknek sincs baja. Viszont ez évek óta ment rendben, most egy update előtt adta meg magát.Valaki btrfs tapasztalattal tud erre ötletet adni?
-
CentOS-en hogyan tudok auditot/logolást beállítani egy specifikus kapcsolatra (az érdekel, milyen userid és process nyitja)? A meglévő eszközöket kell használni, nincs lehetőség telepítésre, fizikailag nem hozzáférhető a szerver.
-
Livius
őstag
válasz
bambano
#31327
üzenetére
Fájlátvitelre a Visual Studio és az ingyenes Visual Code is igazából az rsync-et használja, tehát amikor buildelsz, akkor a PC-én lévő project mappádat az ARM-es Linuxra beszinkonrizálja és kész. Utána lescriptelt módon belép az SSH-án ott a gcc-vel fordít egyet és a gdbserverrel együtt elindítja a debugolandó progidat. Innentől kezdve már nincs SSH, a gdbserver saját protokolja szerint megy a debug, aminél nincs hatékonyabb jelenleg.
Ebben a módszerben, amit az MS megcsinált szerintem sehol semmi kókányolás nincs, maximálisan követ egy unix filozófiát, és a usernek minimalizálja az extra konfigurálási kényszert, tehát nem kell hozzánemértő módon NFS megosztással bajlódni, ami mindenképp külön telepítgetéseket követel és hozzáértő beállítást, az nem lenne user friendly és nem eladható széleskörben.
-
bambano
titán
válasz
Livius
#31325
üzenetére
a kifejezés, amit kerestél: remote debuggal.
egyébként ez egy jó példa arra, hogy a unix filozófiát nem ismerők hogyan kókányolnak keresztül-kasul, hogy elérjenek valami eredményt, ahelyett, hogy megcsinálnák normálisan.minek másolgatnál mindent jobbra-balra? ha nem felel meg a verziókezelő repója erre (de, megfelel), akkor is feltalálták az nfs-t.
-
Livius
őstag
válasz
CPT.Pirk
#31311
üzenetére
Amúgy a jelenlegi "state of the art" az lenne, ha a már meglévő C vagy C++ libjeiteket beraknátok egy igazi C/C++-os Python modulba, tehát egy olyan .so-ba amit a python betud importálni, és abból az ehhez megcsinált osztályokkal egy sima python scriptben tudnátok a top level szintű működést megvalósítani.
Én kb fél éve ezt megcsináltam, egy ugyan ilyen ARM-es Linux alá, és a világ legkorszerűbben és leggyorsabban fejleszthető cucca lett az eredmény ebből.
Amúgy az Eclipse valamilyen tcf-agent cuccal tudja ugyan azt a gdbserveres debugolást mint a VS2019 vagy a VS Code.
-
Livius
őstag
válasz
CPT.Pirk
#31311
üzenetére
Ha van lehetőséget a R-Pi-re rakni gcc-t és gdbservert meg ami mind kell ahhoz hogy tudj fordítani az SSH-án keresztül akár a beágyas Linuxon, akkor én azt javaslom próbálkozz inkább a Visual Studio 2019-ben lévő remote debug-val. Annak a gdbserver-es verziója a jelenlegi legjobb szerintem.
Röviden tömören, amikor buildelsz az SSH-án keresztül feltölti a forrásfájlokat, és az R-Pi-ben lévő gcc-vel fordít mindent, és ez a legjobb, így nem megy félre semmi. Aztán amikor debugban futtatod, akkor SSH-án a buildet cuccot elindítja úgy, hogy a gdbserver is megy közben a Linuxon, és azon keresztül tudsz a VS 2019-ben a saját PC-den breakpointozni, meg mindent amit akarsz, úgy hogy valójában a progi az ARM-en fut. Abban is okos a VS2019, hogy a remote Linux fordítójának és rendszereiben elérhető headerjeiről is csinál egy cahcelt állapotot, és 100%-osan tud működni az IntelliSense a Linuxban lévő includok alapján.
Amúgy ez létezik az Eclipsben is, de kb fél évig tarthat a bekonfigolása, meg én is azt vettem észre, hogy alig van normális blog bejegyzés vagy valami tutorial hozzá, ami gond nélkül ugyan ezt összerakná.
-
vicze
félisten
válasz
#68216320
#31322
üzenetére
"FakeRAID
This type of RAID is properly called BIOS or Onboard RAID, but is falsely advertised as hardware RAID. The array is managed by pseudo-RAID controllers where the RAID logic is implemented in an option rom or in the firmware itself with a EFI SataDriver (in case of UEFI), but are not full hardware RAID controllers with all RAID features implemented. Therefore, this type of RAID is sometimes called FakeRAID. dmraid from the official repositories, will be used to deal with these controllers. Here are some examples of FakeRAID controllers: Intel Rapid Storage, JMicron JMB36x RAID ROM, AMD RAID, ASMedia 106x, and NVIDIA MediaShield." -
#68216320
törölt tag
Sziasztok.
Kis segítséget szeretnék kérni.
Van a két RAID kártyám. Nem hardveres, hanem az olcsóbbik cpu-t dolgoztató fajta. Az egyik valami SIL3xxx, a másik JMB366. Bármelyikkel csinálok egy RAID0 (128k) tömböt 2db HDD-ből, linux-on belül a GParted külön-külön hdd-nak jelzi és nem jelzi a logikai tömböt.
Direkt kártyával szeretném megcsinálni és nem mdadm-el, hogy Win alatt is tudjam olvasni majd a tömböt.
Mi az oka, hogy nem látom egyben a dupla hdd méretű tömböt?
-
Keem1
veterán
Srácok, van egy saját írású mono service-em aminek ugyan vannak még gyermekbetegségei, de mostanság egy forrás REST API időnkénti elérhetetlensége miatt failure után leáll. A hibát le fogom kezelni, de alapvetően a service úgy van beállítva, hogy failure esetén restartoljon:
Restart=on-failure
RestartSec=30Mivel a fenti, leállással járó hiba ritkán fordul elő, és ha a service újraindul, legközelebb már jól végzi dolgát. HA újraindulna... és itt van a probléma. A lock file létezése miatt a syslog tele van entryvel, hogy nem tud elindulni.
Ha kiszedem a lock file-t, és failure-re fut a program, simán restartol 30 másodperc múlva és megy minden a maga rendjén. Mivel "szerveren" fut a program, sajnos nem opció, hogy amikor a monitoring alertál arról, hogy leállt a service, kézzel újraindítom, hisz lehet hogy épp alszom. Jó lenne, ha maga indulna újra. Az a baj, hogy ez a probléma (a lock file miatti sikertelen újraindítás) sokkal nagyobb gond, mint az ezt kiváltó program exception.Hogy vehetném rá a service-t, hogy failure restart esetén nyugodtan írja felül a lock file-t?
-
Frawly
veterán
válasz
_kovi_
#31300
üzenetére
Azon kívül, amit a többiek írtak, én megjegyezném, hogy a scripted egy másik oldalról is sántít. Cselesen eltitkoltad, hogy milyen disztró, de pl. a legtöbb disztró systemd-s, és ott kiadod ezt a service parancsot, és képen vág egy service: command not found sorral, hogy a fal adja a másikat.
Látszik, hogy valahonnan összeollóztad a scriptet, kicsit bele is hegesztettél saját kútfőből, és az egész több sebből vérzik. Ez azért is veszélyes, mert ha még le is fut, ha nem jól van megírva, akkor más környezetben vagy egy újratelepített rendszeren nem fogod érteni, hogy miért nem működik.
-
bambano
titán
válasz
_kovi_
#31313
üzenetére
először is megígéred, hogy legközelebb a helyes topicba írsz: [link]
másodszor azért lehet gondod a fordított aposztróffal, mert egyáltalán nincs szükséged rá. nem azért nem megy, mert az echo elé vagy mögé tetted, hanem azért, mert tetted.
harmadszor lehet zárójelezni, sőt, erősen javasolt is, mert a fordított aposztróf idejétmúlt, de nincs rá szükséged. a processzbehelyettesítés régi módszere a fordított aposztróf volt, az új pedig a $( ) -
_kovi_
aktív tag
Először is köszönöm a válaszotokat!
Igazából, csak általánosan gondolkodva ezt akartam volna megvalósítani:
vsftpd= service vsftpd status #ennek a kimenete egy sor amiben van 'pid' szó
if -ben, kiíratom a vsftpd változó értékét echoval és átadom a grepnek, hogy a -q miatt logikai értéket adjon vissza, amit hasonlíthatok az -eq-val. Ami 0-val tér vissza, ha a pid szerepel a vsftpd string sorban.
Sajnos systemctl nem használható, mert RedHat 6.8 a szerver.De az if-ben elrontom a színtaktikát. Sajnos nem vagyok bash guru, az echo elé téve a fordított aposztrófot sem megy.
Ha lehetne zárójelezni mint C-ben jobban átlátható lenne. Mert a fordított aposztróffal egy zárójelet akartam felyettesíteni, hogy annak a két parancsnak a kimenetét hasonsítsa az -eq.
vsftpd=`service vsftpd status`if [ `echo "$vsftpd" | grep -q "pid"` -eq 0 ];thenecho "a service fut"elseservice vsftpd startfi -
vargalex
félisten
válasz
bambano
#31309
üzenetére
De a kolléga azt írta, hogy: "vsftpd-be beleteszed a status outputot, majd ezt az outputot akarod elindítani (mert felüldefiniáltad), ha nem fut a cucc"
majd
"Rendben, azt eltévesztettem, de attól még felüldefiniálta, ezért kap syntax errort."
Nem definiál felül semmit. Én erre reagáltam. Az egy másik probléma, amit te írsz. Arra írtam, hogy megírtad, mi a probléma...
-
CPT.Pirk
Jómunkásember
válasz
bambano
#31310
üzenetére
Jah kupleráj, de ez nekem mind totál új terület.
Most éppen rájöttem, hogy totál hiába kínlódtam eddig az Eclipse-el. Az csak 64 biten létezik, a PI-re ugyan létezik 64-bites oprendszer is amire fel is települ, viszont a GPIO portok buzerálásához kellő wiringPi nem működik 64 biten, meg amúgy is egy kínlódás volt olyan toolchaint találnom, ami 64 bites arm-en le is tudott fordítani valamit...
Szóval per pillanat visszaálltam az eredeti raspberry OS-re, és ott Geany alatt elkezdtem dolgozni, szépen megy a GPIO kezelés, még a végén az egész projektet az alatt csinálom meg...Most még meg tudom csinálni, hogy teszek monitort meg perifériákat a PI-re, viszont a fejlesztés későbbi szakaszában már be lesz építve a termékbe ahol nem fogok hozzáférni a hdmi-hez, de debuggolni már ott kell majd helyben.
Egyébként a Geany egész jó sebességgel használható ssh -X -en keresztül, és még az általa futtatott program is átjött hozzám. Viszont majd megpróbálom megvalósítani amit írtál. -
bambano
titán
válasz
CPT.Pirk
#31307
üzenetére
próbáljunk már unixosan gondolkodni, mert ez kupleráj
két dolog miatt lassú:
1. az eclipse nagy. tehát lehet, hogy akkor is lassú lenne, ha közvetlen képernyőt dugnál a pi-re. egyébként miért is nem dugsz képernyőt a pi-re?
2. az ssh titkosít. ezért minden rajta átküldött adat lassabban megy át és összeszed egy rakás késleltetést, ami interaktív desktopon idegesítő tud lenni.
3. a teamviewer ezen a két tételen tovább tud rontani, várhatóan elég sokattehát ha nem elektromos csellentyűcskékben gondolkodunk, hanem meg akarjuk oldani a problémát, akkor az eredeti unixos megoldást kell használni: az X kliens-szerver alapú.
- elindítasz egy terminált a pc-den, beleírod, hogy
xhost +
- miközben kifejezetten nagy erőkkel odafigyelsz arra, hogy az ssh parancssori paraméterei között NE szerepeljen a -X.
- ssh-val bemész a pi-re, ott beírod, hogy:export DISPLAY=desktoppcipcime:0
- ezután elindítod az eclipse-t.ekkor gyorsabb lesz. hogy ez neked elég gyors-e, az szubjektív kérdéskör. miután a pi-n gyakorlatilag nincsenek perifériák (arra célzok, hogy az ethernet is usb-n lóg), ezért ott lehet, hogy ez is lassú lesz, majd eldöntöd.
azt ne zárjuk ki, hogy agyhalott csomagolók gyári állapotában letiltották a pc-n a hálózati X-et, ilyenkor meg kell keresned azt a parancsfájlt, ami az X-et indítja, megnézni, hogy van-e -notcp kapcsoló és azt ki kell gyalulni.
az biztos, hogy rendes gigás ethernettel rendelkező rendes számítógépek között az X minimum elfogadhatóan, de inkább jól működik. 10 gigás neten pedig semmi különbség nincs a lokális és a távoli programok között. én mindkettőt használom.
-
bambano
titán
válasz
vargalex
#31305
üzenetére
de, dollárral hivatkozik rá.
ez van az eredeti hsz-ben:
if [ echo `"$vsftpd" | grep -q "pid"` -eq 0 ];
az idézőjelen belül kifejti a $vsftpd-t, ami az előző futtatás eredményét tartalmazza, majd mivel fordított aposztrófok között van, ezért azt forkolja és egy subshellben elindítja a csővezetékkel, greppel egyetemben.
azért kap syntax errort, mert a parancsok kimenete rendszerint nem futtatható. -
vargalex
félisten
válasz
sh4d0w
#31306
üzenetére
Mit definiált felül? A vsftpd az egy lokális shell változó lesz. Ha hivatkozni akarna a változóra, akkor egy
$kell elé, azaz$vsftpd.Pl.:
[gavarga@gavarga-5500 temp]$ ls=$(echo akarmi)[gavarga@gavarga-5500 temp]$ lstaj.lua[gavarga@gavarga-5500 temp]$ $lsbash: akarmi: parancs nem találhatóLáthatod, hogy attól, hogy van egy ls nevű változóm, az ls parancs továbbra is működik.
Bambano leírta, hogy mi okozza a hibát.
-
CPT.Pirk
Jómunkásember
válasz
bambano
#31283
üzenetére
Úgy nézem, hogy mindenképpen helyben kell futtatnom a fejlesztő környezetet a PI-n, ha hozzá szeretnék férni pl. a GPIO portokhoz.
Azt most megcsináltam, hogy fut az Eclipse-CDT a raspberry-n. Kíváncsiságból ssh -X -el elindítottam az Eclipse-t ami át is jött hozzám az asztali gépemre, de ebben a formájában használhatatlanul lassú. (kisebb progikkal tök jól ment ez)
Mit lenne célszerű használni ami erre való? Egyik lehetőség gondolom a TeamViewer használata és teljes távoli asztal...
-
-
vargalex
félisten
válasz
bambano
#31302
üzenetére
Jó lehet az első megoldás is. Jelen állapotában annyi, hogy az exit status-t kell vizsgálni (persze ekkor felesleges a vsftpd változóban letárolni az egyébként is üres kimenetet):
service vsftpd status| grep -q -i pidif [ $? -eq 0 ]; thenVagy nem quiet-be grep-elünk és a visszaadott sorok számát számoljuk:
vsftpd=$( service vsftpd status| grep -i pid | wc -l) -
bambano
titán
válasz
_kovi_
#31300
üzenetére
a fordított aposztróf elvileg futtatja a parancsot.
tehát a vsftpd változóba a státusz kimenete kerül, nem pedig a parancs, amivel lekéred a státuszt.
ezért az ifben az echo után a szintén fordított aposztróf nem a státusz lekérésére szolgáló parancsot fogja futtatni, hanem a státusz eredményét akarja parancsként végrehajtani, ami eléggé kétesélyesszerintem azt kellene, hogy (egyrészt van rá szaktopic
) a vsftpd változóba a státusz eredményét rakod, valahogy így:vsftpd=$( service vsftpd status| grep -q -i pid)if [ $vsftpd -eq 0 ]; thende ez sem lesz jó, mert nem szám lesz benne, hanem string.
a legegyszerűbb:service vsftpd status | grep -q -i pid || service vsftpd start
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.
, akkor próbálják 
(Amikor még futott a cucc, most meg hétfőig nem férnek hozzá 
Abból az egyszerű okból, hogy ssh szerver kell a gdbhez is szóval az alapból van, tök felesleges lenne még egy protocol.
Új hozzászólás Aktív témák
Hirdetés
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Vírusirtó, Antivirus, VPN kulcsok
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Bomba ár! Lenovo ThinkPad T490s - i7-8GEN I 16GB I 256SSD I 14" WQHD HDR I Cam I W11 I Gari!
- Telefon felvásárlás!! iPhone X/iPhone Xs/iPhone XR/iPhone Xs Max
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5800X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- Tablet felvásárlás!! Samsung Galaxy Tab A8, Samsung Galaxy Tab A9, Samsung Galaxy Tab S6 Lite
- Új és régi konzolok Okosítása/Softmodoloása, és Szoftveres szintű javítása - RÉSZLETEK A LEÍRÁSBAN
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest