-
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
-
Batman
őstag
linux-os skype-ban nincs video támogatás , amivel eddig használni tudtam az az amsn, de szerintem menne gaim-mel is.
mod: meg azt meg lehet probalni, hogy wine-al feltelepítesz egy skype-ot és úgy lehet megy, én próbáltam fel is települt, de valamiért nem fogadta el a jelszavam és a user nevem , nem szántam még rá időt szal nem tudom mi volt a baja.A Rák ellen az Emberért a Holnapért! - "..ez csak azt bizonyítja, hogy a Firefoxtól maximum a pöcsöd érzed nagyobbnak, de ugyanolyan hüje maradsz a számítógéphez..." by moonman
-
04ahgy
nagyúr
válasz Veriakilis #3436 üzenetére
Szia!
Amit én tudok: Mandriva, SUSE esetén (mindkettőt próbáltam) egyszerűbb beállítani a PPPoE jelszó/felhasználóneves internetet, mint Windows XP/Vista esetén! Grafikus felület alól! Sőt, rendszerindításkor is sokkal készségesebben csatlakozik az így beállított nethez, mint az XP...
Szerintem a Mandriva ONE 2007.1 Live CD-t próbáld meg. Nekem az a disztrib van, csak nem CD-ről, hanem telepítve. Azt mondanám, inkább windowshoz hozzáértőbb létemre, hogy le a kalappal!
Örömmel látom, hogy az etch Debianra csak jókat mondtok grafikus felület + user friendlység terén. Én próbáltam a Sarge unofficial x64 portolást, kb. egy éve, de nagyon nem akart 800*600-nál többet az A64 konfigomon, X1800XL-lel. Majd most megpróbálkoztatom magam ezzel az etch verzióval is, hátha kisebb kihívás lesz neki az X2 és az X1900XT.
HGyu
[Szerkesztve]7855.94MHz CPU-Z valid \ Pulchra tibi facies, oculorum acies, capillorum series; o quam clara species! Rosa rubicundior, lilio candidior, omnibus formosior; semper in te glorior!
-
Veriakilis
senior tag
válasz rokefeller #3447 üzenetére
Honnan lehet letölteni?
Kerestem google-val...A spagóca a kondenzátor, és az illesztőtrafó nevében térjetek meg. http://www.heatpipes.tk/
-
04ahgy
nagyúr
Nem az előző hozzászólásom miatt néztem ám be a topicba elsősorban. Éjjel Linux kernelt fordítottam! 0km-es gyakorlattal. Elmesélném, hogyan ment, és volna egy-két kérdésem, remélem tudtok segíteni...
Néztem egy mezei parancs howto-t google-ön, és nekifogtam. A make xconfig nem akar nálam működni, a következő dolgokkal van baja:
Unable to find QT installation. Please make sure that the QT developement package is correctly installed and either install pkg-config or set the qtdir environment variable to the correct location.
HOSTCC scripts/kconfig/kconfig_load.o
make[1]: *** No rule to make target 'scripts/kconfig/.tmp_qtcheck', needed by 'scripts/kconfig/qconf.o'. Stop.
make: *** [xconfig] Error 2
Nem csüggedtem, konzol, és make menuconfig. Nah, ide nem volt leírásom, lépegettem szép sorban, gyakran nyomogattam ?-et az elemeken, és megpróbáltam értelemszerűen dönteni. Tevékenységemre az erős gyomlálás lenne a jó kifejezés. Amit szükségesnek éreztem, és kernelben volt, azt hagytam, amit szükségesnek, de alapból modulban volt, azt is hagytam.
Amit nem éreztem szükségesnek, azt gyomláltam, legyen az kernel, vagy modul szintű. Mindezt értelemszerűen. Mire a sok olvasgatás után a végére értem, nagyon megkönnyebbültem, ~22:00-2:30-ig ez töltötte ki az időmet!
make dep: ez nálam nem akar semmit csinálni, azt írja, unnecessary. Ha neki nem fontos, én sem erőltetem.
make clean megvolt.
make -s bzImage elszöttyögött magában, addig a grafikus felületen neteztem, zenét hallgattam, és amint a prociterhelés lecsökkent, visszanéztem. Sok warning-os sor volt, de a kernel lefordult. Ez normális?
make -s modules az előzőek szerint, itt is voltak warning-ok szép számmal.
Kész volt, ekkor átmásolgattam a szükséges dolgokat a /boot könyvtárba (bzImage-gyuri, System.map-gyuri) , és a grub-ba felvettem az új bejegyzéseket.
Elsőre működött (kisebb meghagyásokkal): például a hang, és a hálózat nem ment, minden más tökéletesen. Gondolom ez azért, mert a hardvereszközök szekciónál túlgyomláltam...
Kérdéseim:
- Mandriva 2007.1 a disztribúció, és a saját, frissített, linux-2.6.17-14mdv kernelforrást használtam. Ennél ugye van sokkal firssebb, 2.6.21.1 is. Azt is használhatom-e, annak ellenére, hogy az nem speciálisan Mandrivás?
- Az általam fordított bzImage 1,74M lett, holott a gyári, ''mindent tudó'' kernel meg csak 1,69M. Hogy lehet ez, ha sok mindent még kiszedtem belőle? Nem illene kisebbnek lennie?
- A gyári kernelhez van initrd, kellene nekem is haszálni?
- Az normális-e, hogy a System.map-gyuri indítás után ''eltűnik''?
HGyu7855.94MHz CPU-Z valid \ Pulchra tibi facies, oculorum acies, capillorum series; o quam clara species! Rosa rubicundior, lilio candidior, omnibus formosior; semper in te glorior!
-
dr_strange
senior tag
válasz Veriakilis #3453 üzenetére
erre gondolsz?
http://www.damnsmalllinux.org/download.htmlJRR Tolkien nyelvei - aglardh.middangeard.org.uk
-
dr_strange
senior tag
Nálam a make menuconfig után a make && make modules_install, utána bzImage átmásolása /bootba és grub conf frissítése elegendő szokott lenni. Ha jól emlékszem, 2.4 óta(?) a make önmagában legyártja a bzImage-t és a modulokat is. modules_install meg beteszi a /lib/modules alá őket.
JRR Tolkien nyelvei - aglardh.middangeard.org.uk
-
BluEyes
őstag
válasz Veriakilis #3449 üzenetére
A Slaxon van valami konzolos parancs (most nem jut eszembe, hogy mi a szintaktikája pontosan, de F1-re kírja), amivel a ramba másolja a teljes pendrdive-os Slaxot.
slax toramAzért jó a tengerparton, mert ott csak 3 oldalról vesznek körbe hülyék.
-
BluEyes
őstag
válasz Veriakilis #3453 üzenetére
Esetleg próbáld fel a Puppy-t. Ma jött ki új version (2.16), épp alóla pötyögök. Van benne valami adsl-beállító segédprogi, hátha jutsz vele valamire. Nekem sajna (hála? ) kábelnetem van, ehhez nem köll.
Puppy hómpédzs: [link]
Letöltés: [link]Azért jó a tengerparton, mert ott csak 3 oldalról vesznek körbe hülyék.
-
válasz dr_strange #3456 üzenetére
Szerintem nem gyártja le a modulokat, a modules_install gyártja le, ha nem találja őket telepítés előtt.
A System.map-ot is illik a bootba másolni.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Claudius
tag
Azt szeretném megtudni, hogy debian alá szeretnék java-t, mert alapból nincs a csomagkezelőben van egy pár nem sun-os felsorolva.
Lehet sun-ost rátenni, hol keressek -
korcsi
veterán
Sziasztok!
Ebben tudna valaki segíteni?
[link]
Előre is köszi!referencia 5700(XT) plexi ARGB-s blokk eladó!
-
Claudius
tag
További info az előző problémámmal kapcsolatban:
megnéztem a java verziót a rendszer azt írja, hogy 1.4.2-es fennt van a netes böngészőben a teletex oldalt megszeretném nézni és kapásból azt írja ki, hogy a java hiányzik. / ez debian alatt van / .Másik számítógépemen ubuntu 7.04 van ott ugyan ez a helyzet.
Mit lehetne tenni, hogy működjön.
[Szerkesztve] -
válasz dr_strange #3462 üzenetére
Kernel csinál System mapot fordítás közben. Nem nagyon tudom elképzelni, hogy gentoo alatt ezt a fontos dolgot külön kitakarították belőle, csak hogy több baja legyen vele az embernek.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
GD
őstag
válasz Claudius #3463 üzenetére
A. google: java
első3. aztán egy linket kell rakni a firefox plugin mappára a telepítési mappából..
[link]
[link]
további részletek: google: howto java firefox linux szavak variálása
''--> xx/jre/plugin/i386/ns7/libjavaplugin_oji.so --> simlink -->/usr/lib/firefox/plugin
B. automatix2 felrakása és ott a sun java install
működik debian és ubuntu alatt is
[Szerkesztve] -
04ahgy
nagyúr
#3454
Az xconfig hibaüzijére mit szóltok? Hogy tudnám xconfiggal fordítani a kernelt?
Miért lett az én kernelem kevesebb belefordított dologtól mégis nagyobb? Most megint fordítok egyet, nem árt az, ha gyakorolja az ember. Ezúttal a 2.6.21.1-es kernel lesz, meglátjuk a Mandriva fog-e problémázni miatta.
HGyu7855.94MHz CPU-Z valid \ Pulchra tibi facies, oculorum acies, capillorum series; o quam clara species! Rosa rubicundior, lilio candidior, omnibus formosior; semper in te glorior!
-
-
GD
őstag
üdv!
1.
milyen filerendszer ajánlott nagy fileok tárolására? (film divx) <700mb
és apróbbaknak? változtat valamit ha pl mindez raid1-en is van?
érezhető javulás van, vagy maradjak a jól bevált ext3-nál?
2. egy lvm állomány ha a rendszer nem lvm-en van, újra látható lesz új rendszer telepítéskor? (feltételezem) kérdés, hogy mi módon? ha több rendszer is látja az lvm-et nem vesznek össze rajta? pl két linux van fent, persze felváltva boot-olva, mikor mihez van kedv...
bocs az amatőr kérdésekért -
A filerendszer típusát mindig az határozza meg, mennyi idő van egy probléma utáni újraindulásra. Ha nem kritikus a reboot ideje, akkor minden esetben kizárólag ext2.
Ha kritikus a reboot ideje, akkor nem tudom, leginkább ext3, de gyakorlatilag mindegyik filrendszerre volt panasz mostanában, a reiser fő alkotója éppen feleséggyilkosság vádjával sitten van, a többinek is voltak ilyen-olyan bajai.
Kernel verziótól is függ.
A raid1 nekem nem gyorsított semmit, annyi előnye van, hogyha bedöglik egy diszk, nem 0 eséllyel marad meg az adatod, ámde sokkal nagyobb valószínűséggel borul meg tőle a gép. Úgyhogy ha nem félsz a diszk hibától (mert bízol a diszkben vagy mert nem tartod értékesnek a rajta tárolt dolgokat), akkor ne használj raidet és ne használj ext3-at, mindkettő nagyban egyszerűsíti a rendszert és nagyon sokat csökkent azon programkód mennyiségén, amiben hibát lehet találni.
Ha igazán sokat akarsz kockáztatni, akkor tedd az összes adatod raid-re, lvm-re vagy evms-re és használj xfs-t vagy reiser4-et lehetőleg a legújabb kernelekkel. Ez a tutti módja annak, hogy legnagyobb rizikó felvállalása mellett legvalószínűbben összeboruljon a géped.
Tudom, hogy amit ide írtal, az szembe megy a mainstreaim véleménnyel, ennek ellenére a személyes tapasztalataim alapján ezt tudom javasolni (én is kerülöm a raidet és csak ext2-m van, ha lehet).Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
Az lvm nem filerendszer, hanem volume manager.
Az ext3 általában fele olyan gyors, mint az ext2. Ha nincs szükséged a naplózásra valami nyomós okból, akkor szerintem nem éri meg kézifékes fájlrendszert választani.
Bajod majd akkor lesz a raid1-gyel, amikor elromlik egy diszked.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
rokefeller
senior tag
válasz bambano #3472 üzenetére
akkor én is kérdeznék, mert olvasgattam, de tapasztalatom nincs, az ext2 használata esetén valami csúnya nagy fagyás és reset után mekkora eséllyel bukik az ember minden adatot, vagy e2fsck helyre tudja rakni? ezekszerint a journal fölösleges erőforráspazarlás csak sima végfelhasználóként?
A télapó nem a régi már...
-
válasz rokefeller #3473 üzenetére
Először is a csúnya nagy fagyás még nem indok a gondolkodás nélküli resetre. Attól, hogy a kernel és/vagy az oprendszer nagyrésze lefagyott, még lehet menteni az adatokat, a magic sysrequest dologgal. Ez szerencsés esetben akár jelentős adatvesztést is megakadályozhat.
Nekem még nem volt rossz tapasztalatom ext2-vel, amit éppen akkor ír a rendszer, mikor fagy, az természetesen megy a levesbe, más nem szokott. Nem zárom ki, de nem valószínű.
Én nem mondom meg senki helyett, hogy neki a journal erőforráspazarlás-e, sőt, azt se, hogy egy gépen mi neki a jobb. A journal egyértelmű előnye, hogy akár sok száz gigás partíciót is pillanatok alatt felmountol a rendszer, még összeomlás után is, viszont a journal metadata írása pont ugyanolyan írás, mint a többi, ez peches esetben simán lefelezi a teljesítményt. Ami nagy méretű filmek írásakor jól jöhet, tehát még az is simán előfordulhat, hogy valakinek egyik gépe ilyen, másik olyan vagy egy gépen belül egyik partíció ilyen, másik olyan.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Veriakilis
senior tag
válasz BluEyes #3458 üzenetére
Köszi!
Próbáltam CD-ről a Puppy-t, de nem indul el.
A Slax-nál is az IRQ7-es megszakítással vlot probléma, de ott el tudtam indítani így:
slax-irqpoll
De a Puppy-t nem tudom, hogy hogyan vegyem rá, hogy elinduljon.A spagóca a kondenzátor, és az illesztőtrafó nevében térjetek meg. http://www.heatpipes.tk/
-
GD
őstag
válasz bambano #3474 üzenetére
mindezt csak véleménycsereként nem kötekedés vagy okoskodás
azért nem gondolom hogy túl nagy veszteség lenne a naplózó történet, mert a másolás más hdd-kre, ami ntfs, fat32 és esetleg ext3, megközelítőleg ugyan annyi sebességgel zajlik, még anno windows alatt is hasonlókat mértem két hdd között
értem a mondanivalód lényegét, de szvsz erőforrásban a mai gépeknél emberi szemmel észrevehető sebesség különbség nincs naplózó és nem naplózó filerendszer között,
főleg egy olyan home rendszeren ahol a proci max 20%-on megy ha mindent egyszerre használok és a ram 80%-a szabad..
úgy érzem a hardware erősen beelőzött pár éve és az oprendszerek csak próbálják tartani a tempót, hogy ki lehessen hozni a userek 90%-nak teljesen fölösleges pluszt
(nem számítva pistikét és az aktuális csúcsgamét)
mire gondolsz mint probléma forrásra raid1 esetén ha kidöglik az egyik disk?
mitől nem lehet újraépíteni a tükröt vagy elérni a másik féltükrön az adatokat? -
''mindezt csak véleménycsereként nem kötekedés vagy okoskodás'': ne aggódj, majd hétfőn felébrednek a linux fanok és fogok kapni hideget-meleget, hogy rosszat mertem szólni a kernelre
''azért nem gondolom hogy túl nagy veszteség lenne a naplózó történet'': naplózó filerendszer elképzelésem szerint kétféleképpen működhet:
1. - jön adat, leteszik az adatot a metadata (a journalba) területre
- leteszik a szükséges rendszerterület változtatást a metaadat területre (inode-ok, clusterek, stb).
- átmásolják a metaadat területről az adatot a rendes helyére
- átmásolják a metaadat területről a rendszerterület változtatásokat a rendszerterületre
- adminisztrálják a journalt
2. - jön az adat, leteszik a végleges helyére
- a rendszerterület változtatást leteszik a metaadat területre
- a rendszerterület változtatást végrehajtják a rendszerterületen
- adminisztrálják a journalt.
Ezzel szemben az ext2-nél lerakják az adatot a végleges helyére és lerakják a rendszerváltozásokat a végleges helyükre. Ez pont fele annyi lemezio művelet.
Ami már nem az én elképzelésem, hanem az én mérésem, hogy ez nagyságrendileg 40-50% teljesítményvesztés, minél kisebb gépen és minél gyengébb hdd-vel nyomod, annál látványosabban lassú a naplózás. Én pont a felét mértem a gépemen. Amíg valaki nem mutat egy 200MB/sec fölötti írási végeredményt bonnie++ kimenetben, addig pesszimista vagyok a naplózós rendszerek írásával kapcsolatban. Az olvasás vélhetőleg nem lassul jelentősen, tehát egy ext3-ról fat32-re másolás az simán lefuthat teljes sebességen.
Elfogadom, ha azt mondod, hogy neked a felezett teljesítmény nem észrevehető, irigyellek a gépedért. De ne szvsz legyen hanem konkrét mérés.
Szerintem a hw nem előzött sehova, a kernel simán kihajt mindent a vasból, ami benne van.
A raid, lvm, ext3, xfs, reiser4 használata esetén azt lehet állítani, hogy ha és amennyiben a tisztelt programozók nem rontottak el semmit az adott alrendszer programkódjában, akkor az adott alrendszer a tőle elvárt előnyöket nyújtja.
Na ezen szokott megbukni a dolog, mostanában annyi ótvaros pocsék kód került a kernelbe, hogy sírhatnékom van. Ennek van pl. olyan eredménye, hogy megdöglik a raid1 kötet második diszkje, ami lehúzza az egész gépet, elérhetetlen, használhatatlan lesz tőle minden. Pedig a raid1-nek elvileg a rendelkezésre állást is javítania kellene diszkhiba esetén, de nem, hanem ettől omlik porba a gép.
Vagy: diszk hiba miatt megdöglik raid1, szabályosan kicserélem a diszket, újraindítom a gépet és pillanatok alatt felbootol. Majd pár óra múlva megomlik az egész. Alapos vizsgálat után kiderül, hogy a frissen berakott lemezt a raid1 nem szinkronizálta, maradt üresen. Minden olvasási művelet, ami a második lemezen zajlott, 0-val feltöltött szektorokat olvas be, ettől a bináris programokban folytonossági hiba keletkezik és értelmezhetetlen problémák kerülnek elő. Végül az egész összeborul. Visszabootolva egy korábbi kernelt, pár óra alatt lemegy a szinkronizálás és utána megy minden korrekten.
Vagy: mostanában valami olyan baja van a raid kódnak, hogy ha kidöglik a diszk alóla, megpróbálja szinkronizálással helyrehozni. Na ettől szépen megáll az egész blokkos eszköz, mint a szög.
Nem merném azt állítani, hogy minden fejlesztő mindig gondolkodik és mindig helyes eredményre jut. Szoktunk néha agyhalottazni, nem minden ok nélkül. Fentiek megtörtént esetek, tehát aki vitatkozni akar vele, annak azt kell bizonyítania, hogy vak vagyok vagy hazudok. Meg azt is, hogy az általam leírt hibára a hivatalos kernel changelogban adott magyarázat nem igaz.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
BluEyes
őstag
válasz Veriakilis #3475 üzenetére
Konkrétan mi nem indul, illetve írd le légyszi, hogyan próbálod élesíteni, hátha meglátok valamit.
[Szerkesztve]Azért jó a tengerparton, mert ott csak 3 oldalról vesznek körbe hülyék.
-
-
Sipi
addikt
válasz dr_strange #3462 üzenetére
Kézi kernelinstallnál a ''make install'' létrehozza. Nekem legalábbis van. Azt hiszem, initrd-alapú kerneleknél (pl. amit a genkernel gyárt) nem jön létre.
Egyébként tudtommal system.map nélkül is megy a rendszer, eddig egyetlen, béta modul nem fordult le, ezt hiányolva. De azt is szarul írták meg.
SipiMont-joie! Saint Denis! Je trépasse si je faiblis!
-
A system map arra jó, hogyha valami kernel programozási hiba miatt összeborul a kernel és szeretnéd bejelenteni a fejlesztőknek a hibát, akkor a system mapra szükség van ahhoz, hogy kideríthessék, merre járt a kernel, amikor eldobta az agyát. Régebben mintha a ps is használta volna, de ez nem mostanában volt.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Sipi
addikt
válasz bambano #3482 üzenetére
Akarja a fene. Eszemet nem tudom, mikor volt utoljára kernel-összeomlásom, pedig az itt divatos disztrók fogalmaiban gondolkodva, én egy tervezés előtt álló, 1 év múlva megjelenő béta-disztribet használok. Vagyis ezek szerint usernek nincs szüksége a system.map-re.
Ja, a hosszabb szösszenetedhez: sosem mértem, s mivel egy gépem van, nem is tudom megtenni. De sosem vettem észre, hogy a naplózó fs-ek lassabbak lennének.
Mások mérései alapján pedig a RAID-1 tutira gyorsít. Ha nem, ott szar a vezérlő, vagy iszonyat lassú a gép minden eleme. Saját tapasztalat nincs, csak netes mérési eredmények.
Otthoni felhasználásnál semmilyen negatívumát nem tapasztaltam az ext3 és reiserfs3.x rendszereknek. Melóhelyi gépem alól időnként elszáll a fél kerület ELMÜ-je, és semmi baja. Pedig azon is elég béta kernel fut.
Persze, problémák lehetnek, de szerintem kifogtál valami hibás és/vagy ótvar hardvert.
SipiMont-joie! Saint Denis! Je trépasse si je faiblis!
-
GD
őstag
xfs-nek is van lefoglalt blokk %-a mint pl amit az ext3-nál ki lehet szedni a tune2fs-el?
ha kell akkor mivel lehet megcsinálni? -
No, hogy ne hiedelmek meg mítoszok alapján beszéljünk, csináltam most egy mérést. A feltételezés ugye az, hogy minél ócskább a gép, annál lassabb a naplózó filerendszer az ext2-höz képest. További feltételezés még, hogy ez a lassulás akár 40-50%-ot is elérhet.
Itt egy izompacsirta gépen, bonnie++-szal mérve az ext2 98243K/sec-cel írt, az ext3 88054 K/sec-cel, az xfs 82827K/sec-cel, a reiserfs pedig 87764 K/sec-cel (ez utóbbi gondolom reiser3 lehet, a debian csak reiserfs-nek hívja, viszont van külön reiser4 csomag).
98243/82827=1.18612, tehát az eredeti feltételezés majdnem fele megvan. Ez egy két diszkes raid1 volt, ami az átlapolódó műveletek miatt szerintem gyorsabb, mint a gyalog diszk, illetve ez a gép sokkal jobb hardver, mint amit otthon használok fájlok tárolására. Az egy 233Mhz-es p1, 128M rammal, 250Gs samsung pata diszkekkel, ez egy 930D, 2G ddr2/800-as rammal, wd400ks sata diszkekkel. A p1-es gép nem hibás, hanem simán régi.
Nincs most kéznél önálló diszk, pedig lehet, hogy volna értelme nem raid0-n hanem egy darab diszken is tesztelni ugyanezt.
Úgy gondolom, továbbra is maradok annál a véleménynél, hogy minél ócskább gép, annál inkább lassú a naplózó filerendszer az ext2-höz képest.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
OddMan
őstag
A hosts fájlba meg lehet adni MX rekordot?
Szóval azt szeretném, hogy a sendmail mielőtt a dns-hez fordul, előtte a hosts fájlt nézze meg és ha ott megtalálja egy adott domain-hez tartozó mx rekordot, akkor az ott rögzített IP címet használja.
[Szerkesztve]''A szíved szabad! Légy bátor és kövesd!''
-
-
OddMan
őstag
válasz bambano #3489 üzenetére
Akkor hogyan lehetne megoldani ezt a problémát?
Sajnos a dns rossz IP címet ad vissza egy bizonyos domain-re és a domain gazdája egyelőre nem tud foglalkozni a dologgal.
Szóval nekem kellene egy olyan, hogyha egy bizonyos domain-re küld a sendmail levelet, akkor ne a dns-hez forduljon, hanem mondjuk egy fájlból olvassa ki az előre rögzített IP címet. Viszont minden más domain névnél továbbra is a dns-t használja.
[Szerkesztve]''A szíved szabad! Légy bátor és kövesd!''
-
ngabor2
nagyúr
ajánljatok valami kultúrált ftp-klienst a gftp helyett. ha kicsit nagyobb adag cuccot akarok áthúzni, egyszerűen kilép. nem terminálból futtattam, de 99%-ra merem mondani, hogy segfaulttal. korábban próbáltam a kftp-t is, az még instabilabb volt.
-
-
-
OddMan
őstag
válasz bambano #3493 üzenetére
A hosts-ba beírtam az adott domain-t, de a sendmail figyelmen kívül hagyja. Azt olvastam, hogy a sendmail mindenképpen dns-t használ.
Asszem meg kell várnom, hogy a másik gép rendszergazdája helyesen megadja az MX rekordhoz tartozó IP címet, addig nem fog menni a dolog.''A szíved szabad! Légy bátor és kövesd!''
-
Tehát akkor mégegyszer: az mx rekord domain NÉVRE mutat, nem domainre, ezt ne keverjük. A domain nevet és a helyes ip címet kell bevésni a hostsba. Kétségeim vannak afelől, hogy a sendmail képes-e figyelmen kívül hagyni a hosts filet, ugyanis az a rezolver dolga, hogy foglakozik-e vele vagy sem, nem a sendmailé. Ha a /etc/nsswitch.conf jól van kitöltve, akkor szerintem a sendmail nem nagyon tudja kikerülni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis