-
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
-
bambano
titán
válasz
samujózsi
#29205
üzenetére
"Azért az érzed, hogy itt átlaguserről van szó, nem hobbista kernelfejlesztőről?": de itt az alapeszméről van szó.
nem mondtam, hogy hatékonyan fog belenyúlni, nem mondtam, hogy sikeres lesz, azt mondtam, hogy hagyni kell.az opensource és a linux alapeszméje, hogy mindenki buherálhatja. ezt az alapeszmét szerintem helytelen lenne megölni.
az egy másik tészta, hogy a hivatalos kernelbe mi hogyan kerül bele és az is, hogy a júzer saját energiáit vagy másokét hogyan pazarolja. ha be akar menni bekötött szemmel az erdőbe, hagyni kell, hagy menjen. ha koppan, koppan, ez téged ne zavarjon. de lehet, hogy felfedezünk egy új mingót.
-
bambano
titán
válasz
samujózsi
#29199
üzenetére
"És sokadszor: átlag felhasználó ne akarjon kernel dumpot fejteni.": miért? azok, akik most kernelt fejlesztenek, átlag felhasználóként kezdték és nulláról tanulták meg azt, a dump olvasást is.
a linux egy szabad világ, ne akarjuk előírni senkinek, hogy mit csináljon. azt mondhatod, hogy te nem tudsz átlag felhasználónak dump olvasásban segíteni. ha más tud, vagy megtanulja önállóan, akkor mindenki boldog.
-
bambano
titán
"Ez teljesen megoldhatatlan. A kernel nem valami 10 ezer soros sufni program.": ha meg tudod számolni, hogy hány sorból áll a kernel, akkor megoldható.
"Az end-user beleértve a rendszer gazdit is inkább ne nyúlkáljon kernel kódba pls.": miért ne? azért opensource, hogy bárki belebabrálhasson.
-
bambano
titán
válasz
kraftxld
#28810
üzenetére
nincs jobb ötletem, mint az, hogy meg kell találni azt a pontot, ahova a drbd-t be lehet szúrni.
persze kérdés, hogy a sas miben tárolja az adatokat. tehát az a valódi kérdés, hogy blokkos eszközt kell replikálni, vagy esetleg az, hogy adatbázist kell?
a másik lehetőség, hogy aki felvette érte a zsetont, az befárad és megoldja
-
bambano
titán
válasz
kraftxld
#28808
üzenetére
nincs jobb ötletem, mint a 8 pár guest között drbd-vel replikálni.
persze jobb lenne a vmware blokkos eszközeit replikálni drbd-vel, de ha az nem megy, akkor marad a guest.vagy ha sokat akarsz dolgozni, akkor kuka az egész és újracsinálni xen vagy kvm alatt
az alá simán be lehet tolni a drbd-t. esetleg belegondolni, hogy tényleg kell-e gfs2, nem jó-e helyette nfs.szerk: annak van valami előnye, hogy egy vason 8 virtualizált gépen futtatsz egy sas clustert, ahelyett, hogy egy natív vason futtatnál egy sas-t?
-
bambano
titán
"Ha minden normálisan működik és rendesen van megírva a service fájl": ezt nem vitatom, csak ha összeveted azzal, amit a vita elején írtam, akkor kiderül, hogy ez egy üres állítás.
te azt támasztod feltételnek, hogyha minden normálisan működik, én meg azt írtam, hogy a systemd jelentős része nem működik. következmény: a feltétel utáni rész sosem valósul meg.
-
bambano
titán
válasz
haddent
#28787
üzenetére
azt gondoljátok, hogy az init csak egy shell szkriptet indít el, ami nem így van. induláskor a runlevelnek megfelelő szkripteket indítja el, és amikor elérte a végleges runlevelt, akkor utána az inittabban leírt daemonok futását menedzseli ugyanúgy, mint a systemd. viszont az inittab kevesebb szájtépést tartalmaz, mint a systemd fájljai, tehát nem igaz, hogy a sysvinit szájtépő.
továbberősítitek bennem azt a véleményt, hogy azért rossz a sysvinit, mert nem tudjátok, mit tud.
-
bambano
titán
válasz
haddent
#28778
üzenetére
alapvetően most cseréltünk szervereket az egyik helyen, ahol dolgozom, újra lett húzva minden nulláról, és azt találtam ki, hogy drbd-vel realtime mentést csinálok. mivel kitolom a házból máshova, így legyen rajta titkosítás. és hogy gyors is legyen, raid1-be raktam. ezt elvileg meg kellett volna tudni csinálni systemd-vel, de a doksija alapján nem működött. mondjuk az md raid drivert is szétokoskodták, a raid1-be rakott raid1 például egy neuralgikus pontja.
vagy ilyet akartam megcsinálni, hogy a postfix ne induljon el addig, amíg nincs felmountolva a leveleket tároló partíció.
úgyhogy most úgy van összerakva, hogy rebootkor a gép félig elindul, utána kézzel összerakom a maradékot.
-
bambano
titán
válasz
inf3rno
#28773
üzenetére
"az a benyomásom, hogy túl keveset tud": érted már, hogy miért JÓ?
"Mármint az jött le, hogy annyit csinál összesen, hogy elindít egy bash scriptet bootoláskor, amit megadsz neki, aztán kalap.": ennél azért többet csinál, nem ártana ismerni, mielőtt azt hiszed, hogy arra a feladatra a systemd jobb.
-
bambano
titán
válasz
haddent
#28772
üzenetére
"mire pazarlod a munkaidőd, amikor systemd -re kényszerülsz?": hát systemd-re, mi másra.
ha azt akartad megkérdezni, hogy mit nem tudtam megcsinálni vele, akkor a válaszom: stackelj egymásra raid1-et, drbd-t, lvm-et, cryptofst, raid1-et különböző sorrendekben. ez nem működik a debian systemd-jével. -
bambano
titán
debianon és solarison is ugyanúgy működött, tehát van két "disztró", akkor már szabványos?
ha az init maga szabványos, de nem korrekten implementálják, akkor az az init hibája vagy az implementációé?szerinted jó a systemd, szerintem egy nagy vödör csavar. hogy ne tartson ez a vita túl sokáig, azt is megígérem neked, hogyha külső segítségre lesz szükségem hardverfejlesztési stratégia kialakításához, te leszel az első, akit meg fogok keresni.
és azt az állításomat is fenntartom, hogyha szerinted a systemd magas százalékban le van fedve tesztekkel, akkor a tesztek se érnek többet egy vödör csavarnál. a systemd használata egy rakás elpazarolt munkával jár és ez engem bosszant.
-
bambano
titán
válasz
inf3rno
#28768
üzenetére
de mennyi felesleges munkát és kárt fog okozni pöcstering, mire végre felfogja a többség, hogy el kell zavarni, és mennyi meló lesz majd egy elcseszett systemd-ből migrálni egy másik rendszerbe megint?
Ráadásul ha mindent magába olvaszt, akkor az nem egy linux kerneles unix lesz, hanem egy linux kerneles windows.
"mert jobb, ha egy külön service manager felel a szolgáltatások futtatásáért": volt service manager, úgy hívták: init.
"Mondjuk, mint már előzőleg írtam, azért ráférne a szabványosítás mielőtt ténylegesen kódot írunk rá": tényleg mondtad, pedig nem kellene, mert téves. az init eléggé szabványos volt. szabványosítás igényével lecserélni egy egységes, szabványosnak tekinthető rendszert egy egyedire, tévedés.
-
bambano
titán
válasz
haddent
#28759
üzenetére
de nem csak egy szempont szerint kell ezt a dolgot értékelni.
ha a te szempontodat, a szoftverfejlesztés hatékonyságát nézzük elaprózott platformon, akkor igazad van, hogy nem logikus.Itt az a lényeg, legalábbis az én véleményemnek ez az alapja, hogy az is számít, hogy a szabad szoftver megad egy csomó szabadságot, és ebbe az is beletartozik, hogy forkolod a cuccot. Az egész miskulancia arra épül, hogy nem pofázunk, hogy rossz, hanem írunk jobbat. Tehát ha felmerülne, hogy a disztró készítés jogát korlátozzuk, azzal kompletten kiherélnénk az egész szabad szoftveres eszmét. Ilyet, hogy nem nyúlhatsz bele valamibe, csak a nagy ellenség, az m$ csinál, debianék meg archék nem.
Nem tudok ennél fontosabb elvet szabad szoftver kérdésben.
-
bambano
titán
válasz
haddent
#28748
üzenetére
"Linuxból hány van? Hány olyan okoskodó jajdekülöndisztró kell akik annyit csinálnak, hogy reskin aztán hello": de mi ezzel a gond? te, mint user, megkapod a választás szabadságát, hogy bizonyos célra optimalizált disztrót választhass. te, mint fejlesztő, nyugodtan csinálhatsz saját disztrót, ha akarsz. szerintem ez nem gond, sőt.
gond akkor van, amikor valaki marhaságot tesz kötelezővé. van vagy 400 disztró, egyet se vagy köteles használni. virágozhat minden virág.
-
bambano
titán
"A klasszik BSD style init lényegében egy shell scriptet indít, esetleg több shell scriptet, rohadtul nem a stabilitás mintaképe.": értem, tehát az egy darab, ezer éve használt, debuggolt init shell szkript az instabil, a rakás systemd szkript meg stabil.
kizártnak tartom, hogy magamévá tegyek egy ilyen véleményt systemd-től függetlenül.
"Fejlesztői szemmel a systemd egy értelmezhető, modern, tesztekkel lefedett kód": ez csak annyit jelent, hogy a teszteset írók munkája se ér egy vödör csavart se.
"service fájlt írni elég egyszerű.": és működő service fájlt?
"a sysvinit buta, mint a franc": aki ért hozzá, az ezt a tényt pozitívumként kezeli, nem hátrányként. érdekes módon én mindent meg tudtam oldani vele triviálisan.
"A gcc talán a legkomolyabb compiler jelenleg": melyik gcc? és miért nem az intel c fordítója a legkomolyabb?
-
bambano
titán
"A systemd amúgy az OS X initjére hasonlít erősen, nem a windowsra.": én nem arról beszéltem, hogy a szolgáltatásai mire hasonlítanak, hanem arról, hogy milyen szemlélettel programozták le. Ez a nagy bloatware egybe-minden-vackot szemlélet ez windows. Ez az állítás nem zárja ki, hogy beleértsd, hogy akkor az osx-et is lewindowsoztam.
"Amúgy érdekes, hogy a deb alapú csodák használói vinnyognak folyamatosan a systemd-re.": mert a deb alapú csodák tökéletesen működtek külsőleg oktrojált szemét nélkül is. Semmi szükség nem volt rá, hogy az rpm kitalálójának alkalmazottja szétcsessze a deb alapú csodákat is. Egyébként pöcstering már kifejtette, hogy a csomag rendszert is meg akarja reformálni meg a home könyvtárakat is. Csak azt nem értem, miért nem tette még helyre senki. Ha osx-et meg windowst akar csinálni a debianból, tegye meg otthon magának. Az én rendszereimet meg hagyja békén, mert az én fizetésem függ tőlük és ezért harapok.
"A pulseaudio funkciója feltétlen szükséges a rendszerbe a normális működéshez": nem, nem szükséges. De hagy emeljem már ki a korábbi állításomat ismét: sokkal könnyebben elfogadnák az emberek pöcstering lomjait, ha azok nem lennének tele hibával. És könnyebb lenne elfogadni pöcsteringet, ha amikor egy hibára reagál, a válasza nem tűnne totál elmebetegnek.
"Az ALSA magában nem elég több programos használathoz": minek kellene több programból használni a hangrendszert??? Az olyan lenne, mint amikor egy társaságba kerülsz több nővel, és egyszerre pofáznak mindenféléről. Az ember füle nincs felkészítve arra, hogy több, különböző audio streamet értelmezzen.
"A BSD init amúgy egy mindennél rosszabb szkript gányolás, komplex rendszerek készítésére alkalmatlan.": merugye a systemd az nem egy szkript gányolás...
-
bambano
titán
válasz
haddent
#28733
üzenetére
"a BSD -k mellett az érvelés Linux-szal szemben mindig az volt, hogy sokkal összeszedettebb": azért tűnhet messziről összeszedettebbnek a bsd, mert *SOKKAL* régebbi (úgy értem, le van maradva, mint állat), mint a linux. Amikor utoljára megnéztem, a töredékét tudta, a töredéke mennyiségű szoftver volt rá, és brutálisan ócska volt a kernele a linuxhoz képest. Tudásban nagyjából a 2.4.x-es linuxok szintjén járt, vagy még előtte. Például nem volt benne rendes smp, nem volt benne multithreaded hálózati stack, rotfl.
egyébként ja, a bsd-k sokkal összeszedettebbek, merugye nincs openbsd, freebsd, netbsd, pcbsd, meg freenas meg hasonlók... ja, de, mégiscsak töredezett az is, legalábbis a felhasználói bázisának nagyságához képest... nincs elég emberük, hogy széttördeljék
"Baromira nem érdekel melyik lesz az irányvonal, de ugyan már legyen már egy irány": volt egy irány: svr4 init. A debian rc rendszere pontosan ugyanúgy nézett ki, mint pl. a solarisé. Emlékeim szerint a slackware-é is ugyanilyen volt. Majd jött az okoskodó redhat, aki mindig mindenben mást csinált és sajnos túl ritkán verték érte pofán (lásd gcc 2.96), és elkezdték tördelni az egységességet. Hol is dolgozik pöcstering?
-
bambano
titán
válasz
inf3rno
#28725
üzenetére
a deuvan például összekeveri az ethernet interfészeket telepítés után. én nem tudok olyan disztróval dolgozni, ami telepítés után nem érhető el, mert a másik ethernet lett az eth0.
a systemd-ről meg annyit, hogy nem valós problémákat talál fel. tehát például lehetne probléma, hogy mennyi idő alatt bootol egy linux. csak ki a bánatos francot érdekli, hogy 10 másodperc vagy 4, amikor egy csomó ibm szerveren a raid vezérlő kernele 300 másodpercig bootol. Ha systemd-vel 307 másodperc alatt bootol be a debian, svr4 inittel meg 312. és akkor mi van? miközben ritkábban, mint évente egyszer kell bootolni.
ezzel szemben meg ha nem teljesen abban a sorrendben stackeled össze a raidet, az lvm-et meg a drbd-t, ahogy az ostobenkó elképzelte, akkor fél éves sz.pás kideríteni, hogy te írtad rosszul a mount unitot vagy a köcsög szkriptjei nem működnek (hint: utóbbi). Ezt a fél évet ki fogja kifizetni?
-
bambano
titán
a systemd-ben levő cuccok jelentős százaléka nem működik.
megismétlem: NEM MŰKÖDIK. az svr4 init töredékét se tudta annak, amit a systemd, de azt mindig megcsinálta jól.a másik probléma, hogy a unix attól lett unix és sikeres, hogy kis, egyszerű építőelemekből van összerakva. van másik irányzat, azt windowsnak hívják. windowsos szemlélettel unixot programozni alapvető tévedés, mintha egy vegán arról kezdene vitatkozni, hogy a bélszínt mennyire átsütve szereti.
a harmadik probléma, hogy egy közösség által összelapátolt rendszerben egy őrültnek ekkora hatalmat adni a kezébe pocsék ötlet. különös tekintettel arra, hogy pöcstering nem először próbálkozott és bukott meg a hülyeségével, lásd pulse audio.
a negyedik probléma, hogy senkinek nincs joga ekkora pénzkidobásra kényszeríteni senkit, amennyibe a systemd megtanulására fordítandó erőforrás kerül, különös tekintettel arra, hogy egyébként a systemd nemlétező problémákra ad (rossz) megoldást.
tehát a 2-4 problémák akkor is a systemd ellen szólnának, ha egyébként az rendesen működik. de mivel ettől a rendes működéstől igen messze vagyunk, az, hogy a systemd megvalósítása egy rakás sz.r, übereli az összes többi problémát.
további probléma még, hogy például akik devuant fejlesztenek, fejleszthetnének debiant is, ha nem ette volna bele a fene a systemd-t a debianba. azzal, hogy systemd-s lett a debian, pazarlódik a munkaerő és lassul a fejlesztése. így eljutottunk odáig, hogy akik eddig debianra alapozták az életüket, azoknak most jelenleg nincs működő oprendszer választási lehetőségük.
-
bambano
titán
szerintem félreértetted, amit írtam.
annyi minden szól a felhő ellen, hogy ezek korrekt megoldása önmagában tönkre teheti a költségvetést.emvy: én meg biztos vagyok benne, hogy a nagy szolgáltatói felhő összességében többe kerül. vagy úgy jár legjobban, ha mindent megcsinál maga itthon, vagy úgy, ha a saját méretosztályára szakosodott szakértővel megcsináltat mindent (tanyacsenöl rulez).
-
bambano
titán
válasz
CPT.Pirk
#28584
üzenetére
a levelezés elsősorban attól függ, hogy milyen internet kapcsolatotok van. fix ip nélkül kicsit macerás levelezni.
skype for businness pótlékot nem ismerek, helyette voip-t tudok elképzelni. a szervert is illik backupolni, tehát arra is gondolni kellene.kérdés még, hogy azt a bizonyos tervezőprogramot a munkaidejük mekkora részében használják, mert ha csak ritkán, akkor lehet terminálszerverre felpakolni.
csoportmunkára sokan használnak zimbra-t.
-
bambano
titán
válasz
Dißnäëß
#28578
üzenetére
igen, teljesen beteg dolog, hogy ezt raid5-tel akarod megcsinálni
azt kellene eldöntened, hogy pontosan mit is akarsz. ha azt akarod, hogy legyen egy realtime másolatod, ami titkosítva van, arra nem ez a megoldás, hanem a crypto blokk device. ha azt akarod, hogy legyen másolatod, arra a korábban említett network blokk device nem alkalmas, mert teljesen döglött és nem vagy nem jól fejlesztett technológia.
ha azt akarod, hogy legyen egy gyors, redundáns, titkosított cuccod, akkor egymásra pakolsz 1-több drbd-t, arra crypto-t majd arra raid1-et. készülj fel rá lélekben, hogy ha systemd alapú oprendszered van, nagyon hosszasan, harsányan és cifrán fogod pöcstering anyját emlegetni. én 4 hónapig tettem
-
bambano
titán
válasz
#68216320
#28473
üzenetére
1. szerintem lesz elég bajod a cuccal, totálisan felesleges még egy dockerrel is bonyolítani az életedet.
2. ha van fent lamp, akkor valóban igaz, hogyha felraknád az nginx-et is, akkor összeakadnának, de minek raknád fel, ha van fent apacs. azt a feladatot, amit az nginx-re bíznak, megoldja az apacs is. -
bambano
titán
szerintem elsősorban arra figyelj oda, hogy hagyd békén a kernelt. annak az esélye, hogy itt kérdezned kell, és ezek után jobban beállítod a kernelt, mint a komplett linux közösség esze alapján gyárilag megvan, nulla. nem tudom, mit értesz jiffy/HZ alatt, de azt se piszkálnám.
a nagyobb szolgáltatók 40-100 gigabit/sec közötti forgalmat képesek generálni egy kernellel. tehát ha 100 gigánál lassabb a hálózatod, akkor nem a kernel lesz a szűk keresztmetszet.
másrészt ha ennyire aggódsz a tcp kapcsolatok miatt, miért nem használsz udp-t?
-
bambano
titán
válasz
#68216320
#28364
üzenetére
"Irigyellek, hogy egy olyan 4TB-os HDD-t, aminél még csak gyenge szektor van nem pedig bad-block, te csak úgy kihajítasz.": ezek a diszkek maguk menedzselik a hibás szektorokat. amikor ez már kívülről is látszik, az azt is jelentheti, hogy elfogyott a menedzselésre fenntartott hely. tehát a diszk erősen halad az elromlás felé.
engem nem zavar, ha a hsz-emet mellőzöd, téged fog zavarni, ha az adataidat is?
-
bambano
titán
válasz
#68216320
#28357
üzenetére
oké, akkor a részletek:
ha raid1 tömbbe teszed a partíciót, akkor az elejére odateszi az md superblockot. majd csak utána tudod rátenni az ext4fs első szektorát.
tehát ha raidben volt a partíció, akkor csak úgy tudod megnézni, hogy van-e rajta fájlrendszer, hogy csinálsz egy ideiglenes raid kötetet és belerakod (vagy tudod, hogy a mountot hogy kell paraméterezni elcsúsztatott szektoros mounthoz).vagyis normálisan nincs látható fájlrendszer a raidből kihullott partíción. hasonló módon értelmetlen fájlrendszert kreálni, mielőtt visszarakod a kötetbe.
ezt azért érdemes tudni, mert elfeded a valódi problémát, így azt nem javítod meg, vagyis lélekben készülj fel rá, hogy megint szét fog hullani a kötet.
-
bambano
titán
válasz
kezdosql
#28335
üzenetére
"Linux alatt napi frissites tonkretette a firefoxot, ahogy webre csatlakozik azonnal merevre fagy a linux": be tudsz rá jelentkezni hálózaton?
szerk: ha mostanában jött elő, hogy "megfagy" a linuxod firefoxtól, akkor lehet, hogy egy videokártya tisztítás segít rajta. lehet, hogy nem megfagy, hanem megfő.
-
bambano
titán
válasz
radi8tor
#28307
üzenetére
az interfaces fájlban található dolgokat a hálózat indulásakor állítja be a kernelben.
tehát ha sem reboot nem volt, sem kézzel nem gyalultad ki a régi konfigot, akkor a kernelben benne van.ha bcp-zni akarsz, akkor egyszerűen másold le egy backup könyvtárba a konfigot módosítás előtt.
-
bambano
titán
válasz
Fecogame
#28282
üzenetére
az alapkérdés az, hogy hol legyen a vezérlőterminál.
ha azt csinálod, hogyssh user@gep 'command' &, akkor az ssh klienst futtató gépen van a vezérlő terminál, vagyis a kliens gépnek működnie kell, az ssh parancsot futtatnia kell mindaddig, amíg a távoli gépen le nem fut a parancs.ha pedig azt csinálod, hogy
ssh user@gep 'nohup command &', akkor az ssh kapcsolat lebomolhat a parancs elindításakor és nem kell megvárni a kliens gépen, hogy lefusson a távoli gépen a parancs. -
bambano
titán
válasz
dzoli87
#28274
üzenetére
a gond az, hogyha veszel egyszerre négy diszket, egy szállítmányból, egy gyártásból, akkor nem őrültség feltételezni, hogy egyszerre fognak tönkremenni. ha fontos az adat, akkor meg lehet fontolni a raid5-öt, de ahogy a kolléga is javasolta, nem egyforma diszkekből. a raid10 talán jobb lehet, vagy a raid1+0, mert az akár két diszk kiesését is eltűri.
de ha fontos az adat, akkor inkább backup.
-
bambano
titán
oké, de az nfs reexport azt jelenti, hogy:
forrás nfs szerver --- nfs protokoll ---> köztesnfs szerver --- nfs protokoll ---> végső kliens
ehelyett lehetne:
forrás nfs szerver --- nfs protokoll ---> végső kliens
ha ez nem működik, akkor azt tudod csinálni, hogy legyen a forrásból leszedett adat helyi. például blokkos eszközként rakd fel a forrást a host nfs szerver alá. vagy pedig először rsync-celj a forrásról a host gépre, és onnan nfs.
-
bambano
titán
azt, hogy smb fájlrendszert tovább lehet-e osztani nfs-en, még nem próbáltam.
azt viszont, hogy nfs fájlrendszer nem lehet továbbosztani nfs-en, az nfs szabvány is tartalmazza.
értelmetlen ötlet, ha egyik gépre fel tudod venni az nfs-t, akkor azon is, ahova egyébként továbbosztanád. -
bambano
titán
válasz
Dißnäëß
#28182
üzenetére
a bájtméretre nem érzékeny, mert az mindenhol 8 bit
a szektorméret már fogósabb kérdés, a régi diszkeken 512 bájtos fizikai szektorok voltak, az újakon 4096 bájtosak, ezt nem jó keverni, mert csúnyán ronthatja a teljesítményt. igazán alaposan azzal tudod lerontani a teljesítményét, ha nem illeszted 8 szektoros határra a szektorokat. Akkor akár 20MBps-t is ki lehet csikarni egy jó diszkből.
a gpt/mbr tudomásom szerint nem számít ebben a kérdésben. abból semmi gond nincs, ha különböző méretű diszkeken csinálsz ugyanolyan méretű partíciókat és abból raidet.
-
bambano
titán
válasz
Mr Dini
#28169
üzenetére
"Hát azért én inkább mondanám, hogy de. Egy épeszű konfig általában tartalmaz tűzfalat": egy épeszű konfig azokra a portokra tartalmaz tűzfalat, amiket egy futó applikáció megnyitott. Ha nincs ilyen, márpedig a desktopnak telepített linuxokon simán lehet, hogy nincs, akkor oda nincs értelme tűzfalat tenni.
-
bambano
titán
válasz
Mr Dini
#28151
üzenetére
a gép költözését nagy valószínűséggel akkor se úszod meg dns és hasonló faragások nélkül, ha fix ip-t kaptál. ha másik routing domainbe kerül a géped, akkor változni fog az ip. nincs mit tenni.
de most már leírhatnád, hogy mi hogy van, mert nem látni, hogy vps-ben vagy, saját vas van hosztingban vagy mit hogy kavartál.
ha például saját vason van proxmox, akkor kaptál egy valamilyen ip-t, azt teszed a saját vas ip címének, meg kaptál fix ip-t, azt teszed a virtuális gépre.
tehát összebridgeled a virtuális gép külső interfészét (amit a hoszt os-en látsz belőle) a gazdagép fizikai ethernet kártyájával, erre a bridge-re teszed rá a valamilyen ip-t, és a virtuális gépen belül teszed be a fix ip-t.
-
bambano
titán
válasz
Mr Dini
#28149
üzenetére
tisztázzunk már valamit:
ha van egy fix ip-d a gépnek, akkor minek mellé másik???ha pedig felhúzol két interfészt, amihez mindkettőhöz van gateway, annak jó eséllyel a hálózat lerohadása lesz a vége. ahhoz, hogy egy gép két ip címen hibátlanul elérhető legyen, policy routing kell.
tehát szerintem tedd rá az alap interfészre a statikus ip címet az interfaces fájlban, és rebootolj egyet, a másik ip-det meg felejtsd el.
-
-
bambano
titán
válasz
Frawly
#27943
üzenetére
belépsz egy könyvtárba a lemezen, mindegy, melyikbe.
dd if=/dev/zero of=test.dd bs=1M &majd pár másodperc várakozás után
rm test.ddés megvárod, hogy lefusson a dd. mivel már letörölted a könyvtárbejegyzést, ezért amikor a dd kilép, felszabadítja a helyet. viszont a kinullázott terület jól tömöríthető.
-
bambano
titán
válasz
vargalex
#27873
üzenetére
"Mondjuk pont ezért szokták mondani, hogy inkább drop-ot érdemes alkalmazni, hiszen akkor a "támadó" nem tudja biztosan, hogy az adott IP címen valóban van-e valamilyen eszköz, míg reject esetén ebben biztos lehet.": ha nincs eszköz az ip címen, akkor az adott hálózathoz tartozó routertől kap egy icmp host unreachable üzenetet. tehát a drop nem alkalmas arra, hogy elrejtsd magad.
"NAT-olt hálózatban a torrent csak passzív módban működik": ez elméletben így van, gyakorlatban pedig a torrenthez rendszerint előírják a feltöltést is, tehát natolt hálózatban szinte mindenki portforwarddal állítja be a torrent kliensét. Ezért a tracker is meg tudná szólítani a klienst.
de te egy rendes, jogkövető gyerek vagy, nyilván nem tudod az ilyen részleteket a torrentről
-
bambano
titán
válasz
vargalex
#27870
üzenetére
"Lehet, hogy az alkalmazás is hibásan van megírva, előfordulhat, hogy a REJECT-ből inkább rájönne.": ha a kernel rejectelt egy csomagot, arról az alkalmazás biztosan nem értesül.
"A szerver oldali ellenőrzés nem mindig megvalósítható, ugyanis lehet, hogy a kliens egy NAT-olt hálóban van, így kívülről nem is elérhető...": tehát a kívülről nem elérhető natolt hálózaton a torrent működik, a tracker ellenőrzése meg nem? meglepne...
-
bambano
titán
válasz
s1999xx
#27869
üzenetére
tudni kellene, hogy milyen csomagokat dropolt el a kernel, amikről most morogsz.
mert az, hogy 300 támadás meg a tízszerese, eléggé tág kategória.egyébként ha a szolgáltató elvette a régi ip címedet, akkor te ott már senkit nem fogsz értesíteni arról, hogy a régi címed lejárt.
Új hozzászólás Aktív témák
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Nintendo Switch 2
- Óvodások homokozója
- Esik a hóóó!!
- Samsung Galaxy S23 Ultra - non plus ultra
- NFL és amerikai futball topik - Spoiler veszély!
- Magga: PLEX: multimédia az egész lakásban
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Samsung Galaxy S21 FE 5G - utóirat
- Nvidia GPU-k jövője - amit tudni vélünk
- További aktív témák...
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- 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
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- 120 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- Vásárold meg most a Zalman T7-et, és élvezd a minőséget!
- LG 48GQ900-B - 48" OLED - 4K 3840x2160 - 138Hz & 0.1ms - G-Sync - FreeSync - HDMI 2.1
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest