-
Fototrend
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
-
válasz
Fecogame
#28680
üzenetére
Megoldva
apt install msmtp msmtp-mta mailutilsnano /etc/msmtprcaccount default
tls on
auth on
host smtp.gmail.com
port 587
user user@gmail.com
from user@gmail.com
password xxxxxxxxxxxxxxxxxx #https://myaccount.google.com/apppasswords
Innentől pedig már a szokásos mail paranccsal is megy az email küldés 2factoros auth-al védett email címről is. -
haddent
addikt
válasz
Frawly
#28695
üzenetére
Hát én letiltani tudok segíteni, csak aztán, hogy mi lesz nem tudom, fogalmam nincs kapásból ez mit csinál
De
systemctl status systemd-random-seed-del nézd meg, hogy hol a .service, pl nálam:... Loaded: loaded (/usr/lib/systemd/system/systemd-random-seed.service ...És konkrétan töröld ki (backup után)
Vagy kommentezd ki az ExecStart -ot és rakj be egy echot a helyére vagy valamit -
Frawly
veterán
válasz
haddent
#28694
üzenetére
Igen, írtam is a legelső vonatkozó hozzászólásomban, hogy ezt próbáltam először. Látszólag le is tiltja, nem ír semmi hibaüzenetet, de aztán reboot után pofátlanul továbbra is ott virít ez a futó random seed service, és dicsekszik, hogy 9 mp-cel hosszabbította meg a bootot. Valahogy mindig visszamászik, hiába tiltom le
-
Frawly
veterán
válasz
samujózsi
#28692
üzenetére
Kösz a választ. Bootoláshoz betettem a random.trust_cpu=on kernelparamétert, de nem segített. Az első link szerint nem is csoda, mert ehhez a procinak kell támogatnia az RDRAND utasítást, az enyém (2. genes mobil Core i) nem támogatja.
Egyébként a gondot, ahogy nézem, nem is a kernel jelenti, hanem a systemd-random-seed.service. Ezt kéne kikapcsolnom valahogy.
-
samujózsi
senior tag
válasz
Frawly
#28689
üzenetére
Nálam ez egy ubuntu szerveren jött elő. Valamelyik service (lehet, hogy saját készítésű volt) túl sok véletlenszámot használt, sajnos a részletekre nem emlékszem.
Próbáltam megkeresni, mert telesírtam vele a fórumokat, de helyette ezt találtam: [link]
Hátha valamelyik komment segít.
Illetve egy másik bug report: [link]
Ebben az az érdekes, hogy mindkettő a 243-as systemd telepítésével hozza összefüggésbe (persze lehet, hogy ugyanaz a bejelentő, csak a nick más)És a poettering által javasolt olvasnivaló is segíthet: [link]
-
Frawly
veterán
válasz
sh4d0w
#28690
üzenetére
Kösz a linket, azt tudom, hogy ez micsoda, mire való. Nagyon elszomorítana, ha nem tudnék tőle megszabadulni. Nem igaz, hogy valami kernelparaméter nincs erre, hogy az egész random-seed-es baromságot abbahagyná, és végre lehet lehetne tiltani a system service-t is.
Lassan már érik nekem egy nem systemd-s disztróra váltás, vagy Void, vagy Gentoo. A Devuan nekem nem elég friss. A választék meg korlátozott, elég kevés systemd-s disztró maradt. Így végül lehet nem is a binárisok optimalizálása miatt váltok Gentoo-ra.
-
Frawly
veterán
Na, most lett elegem ebből a linuxos random seed baromságból. Egyre jobban belassítja a bootot Archon, hosszú extra másodperceket jelent bootidőben.
Valamelyik itteni ubuntus topik hatására használtam egy ideig a haveged csomagot, ami ezt hivatott orvosolni, azzal gyorsabb is lett, de a régi bootidőt az sem hozta vissza teljesen. De egy idő után az újabb kernelekkel belassult (1 perc fölé majdnem) az is, úgyhogy eltávolítottam, nem volt más választásom.
Most viszont anélkül is egyre hosszabb a bootidő, systemd-analyze blame a system-random-seed.service-re hivatkozik, 8-10 mp. között van
Próbáltam ezt systemctl disable módszerrel letiltani, de hasztalan, minden bootkor elindul csakazért is.Hogy lehetne az egész Linuxból, kernelből, systemd-ből gyökeresen kitiltani ezt a random-seed baromságot, egyszer és mindörökre??? Nem az NSA-nak titkosítok államtitkokat, adataimat vagy külső hardveres titkosítással védem (SSD ATA jelszó), vagy egy másik gépen már legenerált kulccsal és hash-el ellátott LUKS titkosítással. Nem kell ez a random seed baromság egyáltalán, örökre meg akarok szabadulni tőle. Erre valakinek ötlete?
-
#68216320
törölt tag
Segítenél értelmezni a kapott eredményt?
Én nem látok semmi problémát.
EXT4 fájlrendszer/dev/md0:Version : 1.2Creation Time : Tue Feb 19 10:33:01 2019Raid Level : raid1Array Size : 9757696 (9.31 GiB 9.99 GB)Used Dev Size : 9757696 (9.31 GiB 9.99 GB)Raid Devices : 2Total Devices : 2Persistence : Superblock is persistentUpdate Time : Wed Oct 9 13:24:49 2019State : cleanActive Devices : 2Working Devices : 2Failed Devices : 0Spare Devices : 0Consistency Policy : resyncName : SERVER:0UUID : ffe5b372:5373598e:701c5824:9e944667Events : 1121599Number Major Minor RaidDevice State2 8 18 0 active sync /dev/sdb21 8 2 1 active sync /dev/sda2/dev/md1:Version : 1.2Creation Time : Tue Feb 19 10:34:11 2019Raid Level : raid1Array Size : 3896925184 (3716.40 GiB 3990.45 GB)Used Dev Size : 3896925184 (3716.40 GiB 3990.45 GB)Raid Devices : 2Total Devices : 2Persistence : Superblock is persistentIntent Bitmap : InternalUpdate Time : Wed Oct 9 12:56:30 2019State : cleanActive Devices : 2Working Devices : 2Failed Devices : 0Spare Devices : 0Consistency Policy : bitmapName : SERVER:1UUID : f5ab782c:c11aa09c:3f7398cc:a1a4fdd8Events : 21341Number Major Minor RaidDevice State2 8 19 0 active sync /dev/sdb31 8 3 1 active sync /dev/sda3 -
#68216320
törölt tag
Van egy Ubuntu 18.04 szerver-em, ami az előbb kapott egy áramkimaradást. 2db HDD 2-2 partícióval két RAID1 tömbben van. Valahogy le tudnám ellenőrizni, hogy rendben van-e a RAID?
cat /proc/mdstat nen mutat problémát, de gondoltam valami korrektebb ellenörzés jó volna.
Esetleg resync? md0 a root (/) alá van csatolva, az md1 adatpartíció (4TB) -
mstmp használatával sikerült megoldanom a Gmail-ból email küldést (ssmtp-vel nem ment).
A ~/.msmtprc fájl tartalma:
account gmailtls onauth onhost smtp.gmail.comport 587user user@gmail.comfrom user@gmail.compassword xxxxxxxxxxxxxxxxxAmit szeretnék elérni, hogy az elküldött emailemnek legyen tárgya.
Most ezzel a paranccsal tudok emailt küldeni, viszont nincs tárgya:
echo "prohardver" | msmtp -a gmail user@gmail.comAz alábbi parancs pedig hibát dob:
echo "prohardver" | mail -s "tárgy" user@gmail.commail: Cannot open mailer: No such file or directorymail: cannot send message: No such file or directoryHogyan lehetne megoldani, hogy legyen tárgya az emaileknek? A mail parancs "megjavítása" lenne a legjobb megoldás
-
haddent
addikt
válasz
Dißnäëß
#28662
üzenetére
Ezzel nem teljesen értek egyet. Abban igazad van, hogy egy szolgáltató szolgáltat, ebből él. Tehát ha hiba van, kérés, igény bármi, akkor szólsz és ugranak rá, mert ha nem elvesztenek és elesnek a megélhetésüktől. Abban is igazad van, hogy mivel ők nem egy-kettő netán 100 instancet üzemeltetnek, hanem (száz)ezreket, vagy többet, ezért minden felgyorsul. Nagyobb csapat, egy helyen lévő hiba mindenhol javítódik, stb stb..
Na ezért nem szabad egy problémát megoldani többször, tipikus rabbit hole. Tudni kell keresni, mert 99%, hogy bármi jut eszedbe, már van rá megoldás és jobb, mintha te nekiállsz gányolni egy kis csapattal.Azzal nem értek egyet, hogy ezt lényegében részrehajlóan csak 3rd party hostinggal lehet elérni. Egyrészt elvből kiröhögöm még az olyan Azuret is, amit on-premise kihoz az m$ és ledob a pincédbe. Nálunk a cégnél van ilyen, ehh.. továbbra is az futkos ott amit az m$ akar, ki tudja mi.. Ezzel max. azt lőttük ki, hogy nem megy ki a public netre és nem tudják fizikailag elvinni az m$ telephelyéről. Ezek azért ma már megoldott dolgok szerintem, nem ezen van a hangsúly.
Nem rossz dolog ez, de az agile is kötött, főleg egy kommersz cégnél. Ami sokaknak tetszik (a mazohista hülyék
), épp ez, az előnye is, hogy kötött, az az óriási hátránya is. Míg egy open source projektnél ilyen nincs, ráadásul ott van előtted a programkód, nincs turpisság meg susmus. Szerintem a legjobb választás egy olyan open source implementáció ami mögé már kiépült egy kommersz cég, aki azonban nem az eladásból, hanem a supportból él. Ott megvan a napi szintű pörgés és a community ereje, viszont nem csak a gugli és stackoverflow marad, ha beüt a gatya.. Mindkét világ jósága.Az, hogy a legtöbb cég és kedves kollega 20-25 évvel le van maradva pedig nem azt jelenti, hogy az törvényszerűen csak úgy működhet. Mondom ezt úgy, hogy ELTE -n tanultam papíron formális matematikai nyelven ciklust meg programkódot írni és C/C++ hívő vagyok, csak nem hülye
Simán kiépíthető egy poc/teszt és egy live környezet. Előbbi akár napi szinten automatizálva rángatja a frissítéseket és verziókat, Jenkins CI build + test, amint pass át is csapja livera. Mindezt mondjuk Dockerrel megspékelve gyönyörűen logolható, nyomonkövethető és fenntartható környezetet kapsz ami oda-vissza véresre veri az akár onpremise akár public monumentális nevetséges őskövületi szarokat akik már csak a nevükből élnek, mert más előnyük nem maradt 
Igen, az itt felsorolt megoldások merőben más gondolkodásmódot és szakembereket követelnek meg, mint az összekattintgatom egérrel microsoft jajjdejó megvan a winserver 2016 tanúsítványom elvégeztem a tanfolyamot dege#*menővagyok, de én ebben hiszek. Elismerem és elfogadom a te véleményed is, szerintem kicsit elkanyarodtunk és olyan mélységben tárgyalunk ahol nem feltétlen van megoldás és/vagy objektív igazság, hitvallás kérdése
-
samujózsi
senior tag
válasz
bucihost
#28674
üzenetére
Kilövöd a nohup.out-ba író processzt és nem szabadul fel?
Milyen fájlrendszer van alatta?Bocs, el kell mennem, ha délutánig nem lesz aki tud segíteni, megpróbálok utánanézni. Az echo-nak elvben illene felszabadítani a helyet, legalábbis ext4 esetén, szóval tényleg furcsa.
-
-
samujózsi
senior tag
válasz
bucihost
#28672
üzenetére
Ugye másolod, nem mv nohup.out x.x módszerrel csinálod?
Ha így van, a másolás után próbálj egy "echo >nohup.out" parancsot! Nem lesz teljesen konzisztens a végeredmény, ha nem tudod az x.sh futását felfüggeszteni, de talán nem lesz túl nagy az adatvesztés. Bocs, nem tudom mobilról formázni. -
bucihost
senior tag
Sziasztok! "nohup sh x.sh &" Megy, létrehozza a nohup.out-ot. viszont valamiért gondol egyet és csinál a pár megás logból több(100) gigát. Gondoltam rá, hogy cron-nal csinálok egy backupot máshova, a logot meg törlöm vagy ürítem. A mentés oké, törlés oké létre is jön az új log file. Viszont szabad hely nem szabadul fel... csak reboot után. Ezt valahogy ki lehet küszöbölni, hogy törlés után fel is szabaduljon a hely?
-
samujózsi
senior tag
válasz
inf3rno
#28663
üzenetére
Bocs, nem ezért kérdeztem. A windows környezetet évekkel ezelőtt száműztem az életemből és még akkorról maradt meg bennem, hogy talán a superuseren vagy askubuntun feltett sambás kérdésre az volt a válasz, hogy azt már CIFS-nek hívják, a samba felejtős, deprecated stb.
De a jelek szerint ez nem igaz. Vagy nem úgy... -
inf3rno
nagyúr
válasz
samujózsi
#28659
üzenetére
Nálam az volt a konkrét gond, hogy az ubuntu nautilus nevű fájl kezelője alapból SMB-t használt, és amikor fstabban beállítottam, hogy CIFS menjen a meghajtóra, akkor nem volt hajlandó jelszót kérni. Muszáj volt fstabban megadnom a jelszót, ami nem biztonságos megoldás, de csak így tudtam kihasználni a hálózat teljes sebességét. Azt hiszem SMB-vel is volt olyan könyvtár vagy beállítás, amivel lehetett jó sebességeket elérni, de valamiért mégis alapból baromi lassú volt amit a nautilus használt. Irtam először a gnome fejlesztőinek, ők irányítottak a nautilus-hoz. Irtam nekik, mondták, hogy ez nem az ő bajuk, hanem valami egységes fájlrendszer könyvtárat használnak, aminek már fogalmam sincs mi volt a neve, írjak oda. Irtam oda is, ők azt mondták, hogy az SMB kliens hibája, amit használnak, írjak inkább nekik. Aztán az SMB kliens oldalán már nem lehetett hiba bejelentést tenni, úgyhogy téma letudva. Kb. olyan életérzés volt, mint a garanciális meg a hivatali ügyintézések.
Megkérdeztem a fájlrendszereseket, hogyha ennyire gány az SMB kliens meg nincs karbantartva, akkor miért azt használják valami másik könyvtár helyett, vagy miért az a default, de választ nem kaptam. Nem lettem valami nagy ubuntu fan azt kell, hogy mondjam. 
Próbáltam C-ben megtákolni, hátha, de nem az én nyelvem. -
Dißnäëß
nagyúr
válasz
haddent
#28607
üzenetére
Az esetek többségében - kivétel mindig lesz, lehet nem is kevés - a mögöttes folyamatok sem mindegy, milyenek.
Például egy ~100+ "gépes" (VM-ek és konténerek vegyesen) teljes IT stack-et Azure-ben felépítve és üzemeltetve az erőforrás igénye sem összemérhető egy on-premise private cloude-éval, a hozzá adott csilliárd analitikáról és automatizálhatóságról meg n+1 nézetről nem is beszélve.
És aki azt mondja, nem tökéletes, meg itt-ott beteg, szar, izé ? Hát én még private cloud-ból sem láttam olyat, amibe nem lehet belekötni.
De a folyamatok mögötte akkoris... private cloud-nál vagy urambocsá, annak "elődjénél", az on-premise (akár DC-ben is) lévő üzemeltetésnél waterfall gigaprojektek verekednek iszonyú hiperdilettáns ITIL-helpdesk-szolgáltatási szinteken és xyz Service Management / Ticketing tool-okon keresztül mind hardver erőforrásért, mind élőember (know-how) erőforrásért, és mire elér valami egy úgy-ahogy értékelhető stádiumba, már újra kéne tervezni lassan a projektet, mert a világ odakint közben fordult kettőt. Egy tényleges public cloud mögött pedig (jó esetben, ha alkalmazható, de nem kötelező) egy agilis csapat valamiféle formája van, relatív nagy sebességű reakciókkal változó üzleti igényekre, amiket rendszerben is le tudnak követni és nem úgy, hogy feladom ticket-be a Change Request-et, vagy L1 felveszi nagylassan-tökhanyagul az incidens ticket-et és onnantól várunk heteket, néhol hónapokat
hogy történjen valami a hülyebuta-erőforráshiányos-nagyájtín a háttérben, hanem kb. behúzza PO a sprintbe, valamilyen prio-val ellátja oszt a devops összeüti neki öt kattintással, mondjuk egy új UAT környezetet, mert (ahogy az lenni szokott) a tesztelők épp elfogytak egy új feature tesztelésére tervezett környezetből, "mert azon még az xy release-be menő akármi egyéb fut " épp a Tosca-val, Katalonnal, vagy kőbaltával fullmanuálban. Ez agilisben egy szó szerint agilisen, gyorsan reagálva történve van lekezelve, hozzá egy ezzel kompatibilis Azure-ös pár kattintásos dologgal, amikor fogom az egyik korábban összeállított template-et (vagy az élest "replikálom", ez a legjobb, konzisztens lesz a teszt, abból pikkpakk beröffen egy újabb környezet (legyen az VM vagy konténer), felkonfigolódik, igény esetén még a frissítések is lejönnek rá, hálózat, környezeti változók, minden fiszfasz kialakul és ready to serve. Ott már nincs az, hogy az üzemeltető alvállalkozó embere túrja egy hétig meg konfigolgatja, aztán úgyis elakad, úgyis hívja Bélát a fő architektet, aki morogva de kisegíti, közben eltelt 7 nap.. Ez élőben úgy néz ki, hogy gomb megnyom, közben kimegyünk kajálni a közeli kínaiba, és mire visszaérünk, az infrás átkurjant az asztal fölött a tesztelőnek, hogy nyomhatjátok, közben JIRA-ban az erre kanban board-on felvett standalone issue-t gyorsba bekommenteli és cső, Done. Szóval a public cloud szvsz nem CSAK magáról a technológiáról szól, hanem a mögé tett folyamatok gyorsaságról is. Arról nem beszélve, hogy ha a 100 gépből 20-30 teszt és ezek lefutnak és van kis levegő "semmittevés" teszt oldalon, ha épp nem kell az erőforrás, lelövi az ember és a stopper megáll: nem fizet érte az ember. Ha pedig kell, akár csak pár órahosszára is, akkor megint "play gomb" és mehet a boogie, pár plussz dolcsiért.
Összességében a private cloud-ban megoldott public cloud-os tech sima mezei installációként még nem adja mindazt a plusszt, amit tényleg ad egy public cloud. Persze ha nagyon kapálózik az ájtí főfejes, jöhet az MS felajánlani, hogy helybe letelepíti az ezsört az összes funkciójával együtt on-premise, csilingel is a kassza, ez szép megoldás lesz (és mindenki jól jár hehe, szép kis ország).. , csak ha 100 gép helyett 20-ra mondjuk nincs szükséged, mivel Nálad a host, az attól még bekapcsolva marad és fogyaszt, van egy költsége, míg a public cloud-ban a leverage effekt érvényesül, azaz tojsz magasan ezekre, ha nem használod az aktuális gépet pár órára vagy napra, lelövöd és kész, annyival kevesebb a költséged is, a többi meg a provider dolga (PaaS és ház a szilícium völgyben azért előrébb vannak tőlünk pár évvel). Az más, és mindenki döntse el magának, hogy a működő gépekért elkért költségbe beárazza-e a cloud szolgáltató e költségeket szétterítve - hogyne, nem hülye. De azért összességében még mindig van, amikor éves szinten több tíz millióval (!) jobban térül egy fully fledged Azure installáció, legyen az kicsi vagy nehézsúlyú k*sok gépes birkózó, mint egy on-premise private cloud csilliárdért, ami ennek tizedét sem (!!!) tudja... ahol a beszerzéstől az IT vezéren vagy CEO fővezéren át sokak kapnak vastag borítékot a beszállítótól, hogy ugyanmár, vegyétek a mi hardverünket és tessék-lássék supportunkat, segítünk, jóleszaz, egy kis Cisco ide, egy kis F5 oda, egy rack ide, egy EMC amoda, jólvan, buksisimi... A kassza meg csilingel..
Mondom ezt elfogultságmentesen kő linux pártiként és kicsit (de nem vakon) anti M$-esként.
Baszottul csak előre van út, szerintem. Erősen felhasználásfüggő, mi mire kell és megfelelő, nem jó mindenre sem egyik, sem másik megoldás, de azért a public cloud-ot nem tudnám most úgy leírni és lehúzni, mint ahogy akárcsak 2 éve is néztem rá.
A motyók több mint felét már egy ideje cloud szolgáltatóknak gyártják és ők is veszik, illetve lassan ők lesznek abban a helyzetben, hogy keresztbe-kasul bevásárolnak beszállítókból, maguknak ...
Át kell állni fejben, nincs mese.
-
inf3rno
nagyúr
válasz
Jim Tonic
#28656
üzenetére
Az SMB nem volt karbantartva nagyon hosszú ideig. Én is próbáltam írni nekik még évekkel ezelőtt, hogy ugyanmár állítsák be normálisan a chunk méretet, mert túl kicsire vették a default-ot, és kritikán aluli volt a sebesség miatta azt hiszem Ubuntuban. Eljutottam egészen a bug report oldalukig, ahol nem lehetett semmit beküldeni, gondolom mert az utolsó, aki távozott a projektből lekapcsolta a villanyt. Lehet, hogy felkarolta most valaki, aki hajlandó is foglalkozni vele. A CIFS mounttal egyébként ment eddig is a 100.
-
Nem figyeltem a frissítéseket, illetve eddig nem is tűnt fel, de mikor jött a Sambára ennyire komoly fejlesztés? Szenvedtem a 30-40MB/s sebességgel, tegnap meg feltűnt, hogy 102 körül mozog. Végre. Vagy 10 éve szívtam ezzel, mindegy volt, mit hogyan állítottam be.
-
samujózsi
senior tag
válasz
kovaax
#28654
üzenetére
Jó kérdés, valahogy nálam a process/app tevékenység felderítés, nekem nem tetsző hozzáférési kísérletek listázása = audit.
Jobban lehet/tudom szabályozni, hogy mit, hogyan.
Pl nem kell vesződni azzal, hogy kié volt adott pillanatban az a pid, aki a bejegyzést generálta, mert lekérdezhető, amennyire még fel tudom idézni. -
-
kovaax
őstag
válasz
samujózsi
#28646
üzenetére
A port alapján kikövetkeztettem, aztán kipróbáltam, és ha sikerült reprodukálni a bejegyzést, akkor boldog voltam. Én viszont a saját gépemen saját magamat zargatom, vagyis a Debian-t reszelgetem, hogy ne kukorékoljon senki, akit nem akarok, ez egyszerűsíti a dolgomat azért...
-
-
kovaax
őstag
Én ezt úgy oldottam meg, hogy kifelé is tiltottam mindent, és logoltam. Aztán megnéztem a logot, hogy hova szeretnének menni, és amit úgy ítéltem meg, azt kiengedtem, amit meg nem akartam, azt kivettem a logolásból, és maradt letiltva. És egy idő után üres lett a log.
Egy darabig nem tudtam se válaszolni, se írni a fórumra. Másnak is volt már ilyen???
-
samujózsi
senior tag
-
-
Frawly
veterán
válasz
samujózsi
#28639
üzenetére
Nem dob fel semmit. Ha csak simán indítasz grafikus felületről (indítómenü, asztal, fájlkezelő) egy progit, akkor a normál usered nevében fut, és nethez fér a progi.
Ha viszont terminálban sudo -g eléggépelésével, vagy ezt végrehajtó, módosított indítóikonról indítod, ami szándékosan ebben a no-internet csoport nevében futtat, akkor sem kérdez semmit, nem fér az alkalmazás nethez. Külön kérdezés ilyenkor sem kell, mert azért indítod akkor az alkalmazás ilyen speciális módon (speciális paranccsal, vagy speciálisan erre a célra elkészített ikonnal), mert nem akarod, hogy nethez férjen.
-
samujózsi
senior tag
válasz
Frawly
#28638
üzenetére
Miért, feldob előbb egy dialog boxot, hogy mehet vagy tiltod?
Mert ha nem, akkor mégis kérdezés nélkül.Ami a repokat illeti... keresni kellene, de volt már rá példa, hogy ezekbe is bejutott malware. És ugye a *verse repok nem támogatottak az ubuntu által. Ezeket a magam részéről nem tartom megbízhatónak. Itthonra elmegy, de céges szerverre háromszor meggondolnám, hogy bármit feltegyek ezekből.
-
Frawly
veterán
válasz
samujózsi
#28635
üzenetére
Nem kérdés nélkül tilt. Csak abban az alkalmazás esetében tilt, amit kifejezetten ezzel a spéci csoporttal indítasz (alapesetben mindent a normál felhasználóddal indítasz ugyebár). Viszont ez a megoldás hekkelést és terminálozást igényel, szóval nem olyan kényelmes, mint Windowson. De arra jó, hogy nem kell hozzá egy újabb programot feltenni, és ha csak 1-2 szoftvernek a netelérését akarod tiltani, arra megfelelő hack.
Az Ubuntu Universe és Multiverse repók és elterjedtebb PPA-k, teljesen megbízhatók. Olyan csomagok vannak bennük, ami az alap Ubuntu tárolókban vagy nincs meg, vagy túl régi verziókban, vagy csak 64 bitesen. Tehát semmi baj nincs velük, meg lehet bennük bízni. Ugyanabból az opensource kódból forgatják őket, mint a többi ubuntus csomagot.
Vigyázni csak a teljesen ismeretlen, múlttal nem rendelkező PPA-kkal kell, meg az innen-onnan weboldalakról halászott .deb csomagokkal és franc tudja mit csináló scriptekkel kell. -
samujózsi
senior tag
válasz
haddent
#28636
üzenetére
Repoban bízni... hivatalosban még fogjuk rá.
De az ubuntu universe/multiverse repok?
Vagy a fedora... nem jut eszembe ott minek hívják ezeket a külsős dolgokat.
És akkor ott a snap, ami... hát nem tudom...
Vagy a letölthető konténerek.És ezekkel nem is az az elsődleges problémám, hogy esetleg malware van bennük, sokkal inkább az, hogy mennyivel több sec.hole lehet az ilyen helyekről telepített szoftverek egy részében, mint a hivatalos példanyokban.
Nem általában és minden tűnik megbízhatatlannak, de ezek (egy részük) sokkal kevésbé ellenőrzött források tudtommal. -
haddent
addikt
-
samujózsi
senior tag
válasz
Frawly
#28634
üzenetére
Viszont ez kérdés nélkül tilt, tehát nem igazán jó arra, amire használná a kérdező.
SP4C3: nagyon rég volt amikor ilyet akartam, akkor egy nagyon profi linuxos munkatársam viszonylag részletesen elmondta, hogy linuxon miért nem lehet ezt megoldani. Sajnos pont a részletekre nem emlékszem, csak annyira, hogy egy linuxos rendszer nem tudja követni, hogy milyen alkalmazás akar kommunikálni, csak azt, hogy melyik process.
Elvben írható lenne modul, azóta lehet, hogy írtak is ilyet, ami ránéz a pid alapján a program nevére, de kérdezni akkor sem tud igazán, hogy mehet-e.
Ötleteim talán lennének, de azok megvalósításához az én tudásom biztosan kevés, a kérdésedből meg arra tippelek, hogy te sem napi 48 órában dolgozol vele
Ismeretlen, nem megbízható forrásból származó programot valami világtól elzárt konténerből futtatnék, de az sem egyszerű, főleg, ha GUI is kell neki. -
Frawly
veterán
Grafikus tűzfalban továbbra sincs ilyen funkció. A Stack Exchangen találtam rá megoldást.
Létrehozol egy no-internet nevű felhasználói csoportot:
sudo addgroup no-internetAztán iptables-ben (vagy gufw-ben) tiltod ennek a hozzáférését
sudo iptables -A OUTPUT -m owner --gid-owner no-internet -j DROPMajd az alkalmazást az no-internet csoport nevében indítod:
sudo -g no-internet alkalmazásKicsit körülményes, de nem tudok más járható utat.
-
SP4C3
veterán
válasz
Frawly
#28632
üzenetére
Először is: köszi mindenkinek az ajánlásokat, próbáltam a gufw-t, sajna nem
tud olyat, amit én szeretnék.
Frawly - 112%, hogy szeretnék rá tűzfalat, sőt olyat, amilyet leírtam,
tehát szűr és kérdez, hogy minek engedem a nethozzáférést és minek nem.A befelejöveteltől nem kell félnem, LAN-hoz csak megbízható gépeknek van hozzáférés, net felé és felől ott a Router NAT-tal meg tűzfallal. Tehát nem ilyen védelemre kellene a tűzfal.
Viszont, nem szeretném, hogy a modern software-ek rendetlenkedjenek. Pl. egy fotónézegetőnek qrvára semmi keresnivalója a hálózaton, szeretném tudni, ha menne.![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Frawly
veterán
Igen. És azt a hibát is elkövetem, hogy ha valaki egy linuxos topikban kérdez, és nem ír kifejezetten spéci körülményt, akkor alapból feltételezem, hogy otthonról netezik és aktuális desktop disztróról van szó, és ez a feltételezés az esetek 99%-ban be is szokott jönni. Gondolatolvasó nem vagyok, ha szerverről meg céges felhasználásról van szó, akkor szépen írják a kérdezők ezt a körülményt.
-
-
haddent
addikt
A Darktrace igen, riaszt egyből. De kijátszható, mint minden. De itt a kérdés az, hogy hogy? Pl. amit mondtál, a 443. Te ott kifele mész ugye általában.. Ha meg te hosztolsz és 443 -on beengeded akkor az nginx egyből pofánba.... ha megpróbálsz rá ssh -ni, hogy mit képzelsz
Szerintem ez kicsit sok paranoia egy átlagfelhasználó számára. Utóbbi kommentedre pedig, ha nyilvános wifiket is használ messze a legjobban egy vpn, lehetőleg OpenVPN -nel jár, mintsem bármilyen tűzfalakkal.Unixon ezek a dolgok azért nem olyan pofonegyszerűek, mint winfoson. Itt ilyen szintű hackeléshez komoly user error kell, az ellen meg semmi nem véd. Persze értem amit mondasz és jogos, de mondom, személyes véleményem (és szigorúan az, nem tény!) szerint kicsit paranoia átlagnak
-
Frawly
veterán
Első kérdés: biztosan kell neked tűzfal Linuxra? Mert dekstop Linuxra nem szokott kelleni. Kiváltképp, ha eleve routerről csatlakozik a géped, és a routeren van NAT vagy hardveres tűzfal. Második kérdésedet megelőzve: nem, vírusirtó sem kell Linuxra. A Linux nem Windows. Értem, hogy megszoktad, hogy Windowson ezek kellenek, Linuxon nem.
Egyébként Linuxra olyan tűzfal nincs, ami alkalmazásonként kérdezne. Csak olyanok vannak, amiknél te adhatsz meg IP szabályokat, pl. gufw. Ezek a tűzfalak a kernelben lévő tűzfalat használják (ami desktop disztrón 0 szabállyal jön, nincs bekonfigurálva), abba vesznek fel szabályt, és csak grafikus felületet nyújtanak hozzá felhasználóbarátság miatt. Tehát ők maguk nem tűzfalak, csak ilyen beállítófelületek a kernelhez.
-
sonar
addikt
válasz
haddent
#28626
üzenetére
Nem 100%-osak az ismereteim, de mondjuk az általad felsorolt cuccokkal meg tudod különböztetni, hogy a 443-on https megy vagy éppenséggel ssh tunnel?
szép dolgok - amit fentebb irtam. Hogy nagyon testre lehet szabni, hogy ki mihez fér hozzá kifele a neten. De ez másik szint.
Viszont neked még jó lehet az App Aromor. Alapban bent van az ubuntu-ban. Mélységi tapasztalataim nincsenek, de elvileg azzal is sokmindent lehet szabályozni. -
haddent
addikt
Ez így nem feltétlenül igaz azért, meg hát eleve az iptables lényegében csak egy kernel szintű packet filter végülis, meg max egy cli hozzá. De akinek van rá igénye, annak ott a BPF, lehet vele kísérletezni, az a jövő. De persze, nyilván egy barebone iptables nem nyújtja azt out of the box mint egy stormshield + darktrace, annyira nem sokkoló hír
Mondjuk valószínűleg nincs is szükség ilyesmire, ha kattintgatós menjen-ne menjen feldobós ablakos tűzfalról történik a váltás, szerintem.
-
samujózsi
senior tag
-
sonar
addikt
Olyan alkalmazás szintű tűzfalat lokál gépre nem én nem ismerek.
De proxy-kkal (squid) illetve kicsit összetettebb tűzfalakkal (zorp - egy hazai fejlesztés) elég szép dolgokat lehet összehozni.
google: application based firewall#28623 IPTables nem képes a kommunikációba belenézni olyan szinten, mint mondjuk egy Palo Alto.
-
Vtmk
tag
Sziasztok. Azt szeretném kérdezni,hogy találtam egy m3 elérést. De viszont nem szeretnék minden nap böngészni meg letölteni elérést,hogy tudjam nézni. Hanem lehetsége hogy curl parancssal minden bekapcsoláskor lekérjem?
https://onlinestream.live/tv
És az a poén ha itt kattintok az m3u8 letöltésre oké. De ha curl-lel akarom leszedni ezt írja ki:
A lejátszási link csak a https://onlinestream.live weboldalról érhető el!
Tehát terminálból se tudom lehívni. vagy menteni az m3u8-at.
Ez a letöltési linkje:
https://onlinestream.live/play.m3u8?id=5931&ch=1&ext=.m3u8
Köszi a helpet előre.
Ezzel a parancscsal próbáltam.:
/usr/bin/curl https://onlinestream.live/play.m3u8?id=5931&ch=1&ext=.m3u8 -O /var/www/htdocs/
-
#28619
MasterMark
titán
MasterMark
titán
Köszi mindenki.
Az IPv6 probléma lenne a fontosabb, ha bárki tud bármit akkor írja. Keresgettem a gyári config fájlokban, de nem találtam egyértelműen meg. Manual meg ilyesmihez nem nagyon van, csak annyi, hogy az UI-n kapcsold ide vagy oda.
-
#28616
growler
őstag
MasterMark
#28611
growler
őstag
válasz
MasterMark
#28611
üzenetére
Persze ! Van ilyen lehetőség - úgy hívják, hogy mentésből visszaállítás.
-
#28613
Frawly
veterán
MasterMark
#28611
Frawly
veterán
válasz
MasterMark
#28611
üzenetére
Fájlrendszertől függ, hogy rm után nyerhető-e vissza valami, milyen tool van hozzá. De szerencsétől is függ, hogy nem írodott-e felül a törölt rész új adattal.
Ha visszaállítható törlést akarsz, használj valami lomtárat kezelő megoldást, valamelyik fájlkezelőt, mindegy, hogy GUI-s vagy terminálos, vagy konzolos, mindegyikben van hasonló funkció.
Az IPv6-ra passz, ezt a prefix delegationt meg Unraid-et nem ismerem. Kézikönyvét próbáltad?
-
#28612
sh4d0w
félisten
MasterMark
#28611
válasz
MasterMark
#28611
üzenetére
Szerintem nem, az rm ősi parancs, amikor még nem volt "lomtár" a rendszerekben.
-
#28611
MasterMark
titán
MasterMark
titán
Üdv, két kérdés:
Ha
rm -rf "$dir"parancssal törlök dolgokat, az visszaállítható valahogy utána? (Opredszer szinten gondolom, nem utólagos adatvisszanyerő progikkal. Like lomtár.)Hogy tudok több IPv6 címet definiálni. Egy prefix delegation-nal beállított kéne, és egy DHCPv6 / fix cím. (DUID-ot se találtam meg.)
Unraid az oprendszer, Slackware alapú, de saját konfigfájlokból áll fel.
Köszi.
-
inf3rno
nagyúr
Tudtok valami infot adni arról, hogy mi a betöltési sorrend szoftveres raid-nél és meghajtó titkosításnál? Konkrétan zfs native encryption-ről és sima mirrorról van szó. Vegyük úgy, hogy van egy bootloader, mondjuk GRUB, amit digitálisan aláírok, és azt indítja el először az alaplap. Utána hogyan tovább? Szeretnék mindent aláírni, és ellenőrizni mielőtt betöltöm, de nem világos, hogy a zfs-el, majd a kernellel, és a szolgáltatásokkal hogyan lehet ezt megtenni, ahogy az sem teljesen tiszta, hogy a particionálás hogyan megy ilyen raid-es témában. Esetleg tudtok valami átfogóbb cikket ajánlani?
-
haddent
addikt
Ízlés kérdése. Feleslegesen (és igen, mindig, minden eset 100% -ban felesleges
) nem helyeznék ki semmit sem távoli helyszínre, főleg nem egy - egy olyan megbízható nem kémkedős aranyos kis cég kezébe, mint az m$$$$ vagy a guggle. bambano Modern, működik és egyszerű. Néhány speciális feladattól eltekintve (pl matlab) simán minden mehet webes appnak, egy helyre. Nem kell azt kiengedni sehova, mehet lokálban, aztán ha távolról mégis akarnak dolgozni akkor openvpn-as. De a lényeg, hogy nulla telepítgetés, nincs adatvesztés a kliensek meg lényegében kb eldobható hasztalan kis semmiségek. A networking is leegyszerűsödik, mert mindent megold 443 -on. Persze, nem hatékony, de azért egy modern JS / HTML5 frontend + Python backend kemény cucc tud lenni. És újra: airbag fejlesztés matlabbal, meg kernel patchelés terminálos vim -ben nem így fog történni, de így kb. ezeket leszámítva a hülye usernek oda tudsz rakni valamit amit nehéz elb.... és ha sikerül akkor is kap egy új klienst egy böngészővel aztán mehet tovább.
Nyilván ez az én értelmezésem és ennél több és kevesebb is tud lenni a "cloud". De egy példa: a cégnél konkértan 2019 -ben kiba....ott keepass fájlokat küldözgettek egymásnak emailben, és pontosan ahogy egy levlistánál régen, úgy itt is nyilván kialakult egy össze-vissza cross dependency meg 25 branch kb. És akkor így megkérdeztem, hogy oké, akkor miért nem használunk pl. egy Syspass -t? HTTPS, php encrypted, benne lehet a személyes és a csoportokra osztott jelszavak is stb.. Megszűnik a probléma. Tehát pl. kollaboráció is.
Röviden szerintem lényegében addig a pontig amíg megengedhető/belefér a veszteségesség / "hatékonytalanság", addig csak előnye van -
CPT.Pirk
Jómunkásember
Az is lesz, de a "sokkal jobban működik", az erős túlzás. Két cégét is használom, de olyan alap hibái vannak, hogy pl. az email értesítő megjön egy új plan kommentről, miközben magában a Teamsben meg várhatok 2 percet is, mire frissül a plan comment mezeje és az se gyorsítja meg, ha becsukom kinyitom a plant... Egyszer ilyen, egyszer meg normálisan megy...
Feltölteni se lehet úgy általában, hanem először a sharepointba, aztán onnan továbblikelni a planhoz... -
-
haddent
addikt
válasz
bambano
#28600
üzenetére
Így van. Nálunk a cégnél konkrétan egyedül harcolok *nixesként a gonosz ellen. A múltkor csináltam egy backupot a "statikus" wordpressről amit kibaxtak áázzsőőőrbe mert az jó mert májkrémszoft. Azt hiszem 1.6GB és valami 80 ezer Ft ba került
De cserébe legalább jó szar.
A felhő maga nem ördögtől való, sőt, kifejezetten előnyös én nem is kezdenék új rendszer kiépítésébe de még modernizálásba sem másképp. Mindent fel a felhőbe meg termszerverre a kliensek meg tök mindegy, ami van, 10 perc alatt egy imageből húzható haszontalan kis vackok. ...szóval ja, csak éppen self-hosted cloud, nem ilyen m$$$
Próbáltam ezt systemctl disable módszerrel letiltani, de hasztalan, minden bootkor elindul csakazért is.
Megkérdeztem a fájlrendszereseket, hogyha ennyire gány az SMB kliens meg nincs karbantartva, akkor miért azt használják valami másik könyvtár helyett, vagy miért az a default, de választ nem kaptam. Nem lettem valami nagy ubuntu fan azt kell, hogy mondjam. 
Próbáltam C-ben megtákolni, hátha, de nem az én nyelvem.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Gyermek PC játékok
- Új, bontatlan World of Warcraft gyűjtői kiadások
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- AKCIÓ! Gigabyte B760M i5 14600KF 32GB DDR4 512GB SSD RX 6800XT 16GB Rampage SHIVA CM 750W
- HATALMAS AKCIÓK / MICROSOFT WINDOWS 10,11 / OFFICE 16,19,21,24 / VÍRUS,VPN VÉDELEM / SZÁMLA / 0-24
- DDR3 BAZÁR! 8GB 16GB 1333MHz 1600MHz 2400MHz DDR3 memória garanciával hibátlan működéssel
- AKCIÓ! Csere-Beszámítás! Gainward Phantom RTX 4070Ti 12GB GDDR6X Videokártya!
- BESZÁMÍTÁS! Apple MacBook Pro 14 M4 MAX 36GB RAM 1TB SSD garanciával hibátlan működéssel
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest