Windows XP-re NFS kliens

Microsoft Windows

Szeretnék Windows XP-re ingyenes NFS klienst. Ezzel próbálkoztam, de nem sikerült telepíteni. A pontos hibaüzenetre nem emlékszem, de talán a kernel driver aláírására nyafogott. Érdekesség, hogy a 7zip hibásnak gondolja ezt az önkitömörödős *.exe-t, ugyanakkor néztem md5sum-ot, az jó.

  • 2075 megtekintés

( SySERR | 2017. 02. 05., v – 09:46 )

Na ez engem is érdekel. Egy Win7-es gépre felkerült a haneWIN NFS server, mert max 20 kapcsolat mehet a sima windows-os megosztásra és már elég sok gépen fel lett csatolva az egyik megosztása hálózati meghajtóként. A linuxokat már NFS-en csatlakoztattam fel, de jó lenne a windowsos gépeket is. Az SFU nem megoldás, mert a winek nem Enterprise vagy Ultimate.

-------------------
http://streamstat.hu/ - A legtöbb magyar rádió és TV egy helyen!

Még az sem derült ki, hogy mire szeretnéd az NFS-t használni. OK, fájlmegosztásra. ;)

Részemről a windózos megosztást utálom, nincs is ilyen az ikszpémben! Viszont nagy gond, hogy a tükrözés sem a legnegyobb erénye a windowsnak. Úgyszólván használhatatlan, így az ott levő anyagok biztonságos tárolásáról mindig külön kell gondoskodni.

Az NFS hátrányai:
- performance - Használtam AIX és DOS között PCI-t. (PC-Interface, nem azonos az a PCI busszal!) Ennek a sebesség >300% az NFS-hez képest.
- Rendszeridegen. A Windows -> NFS auth és jogosultságok leképzése is rosszul illeszkedik a klienshez.

Ha leírom, idevonzom a trollokat. :) Arról van szó, hogy Linux host és Windows XP guest között sima filecserével eddig mindig szívás folt. Valami átok ül rajtam, neten olyan végtelenül egyszerű leírások vannak samba szerver konfigurációjára példaként, de nekem nem megy. Pontosabban megy, de aztán magára hagyom a gépet, s fél év múlva egy frissítés után nem megy. Mindez úgy, hogy a konfig file-t senki sem írta felül. Vagy megy, de az már nem, hogy ugyanaz a samba szerver befelé, a guest-nek, s kifelé a fizikai hálózati interface-en is szolgáltasson. Többször nekifutottam, de minél többet olvasok a témában, annál több megoldandó probléma jön elő, mint például a névfeloldás, ami igen sokféleképpen lehetséges. Ott van például a /etc/nsswitch.conf file, amit a küzdelmek során eléggé széttúrtam, nem vagyok meggyőződve arról, hogy helyesen tettem. Már az sem világos, mi az a domain, domain kontroller, master browser, s mindezek kellenek-e nekem. Simán file-t szeretnék megosztani, ami nem tűnik túl nagy igénynek. Nem tudom, lehet, ftp lesz belőle. Bár azt meg a biztonsága miatt illik utálni.

Most megelégeltem, s arra gondoltam, fordítsuk meg. Legyen a kiszolgáló nfs, s a kliens alkalmazkodjon hozzá, hátha ez egyszerűbb lesz. Egyelőre nem úgy tűnik. Itt például olyan kifejezésekkel találkoztam, mint nis, rpcbind, yp, és már megint azon kapom magam, hogy már rég nem az nfs-sel foglalkozom, hanem azzal, hogy egyáltalán foglalkozhassak vele.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Javaslat: ha ilyen alapokkal nem vagy tisztában, mint amiket leírtál.
A változtatásaid hatásának meg kevésbé vagy képes a jelek szerint átlátni a következményét...

Lehet, LEHET, hogy az nfs és yp rossz választás neked.
BTW.: Ha csak fájlmegosztás kell neked, azt sem értem, minek neked nis.
Ha tényleg csak pár fájlt szeretnél elérhetővé tenni win-ek számára, akkor én eleve ro, all-squash exportálnám.

Szeretnék egy univerzálisan használható megoldást arra, hogy vegyes, Windowst és Linuxot is futtató hálózaton működjön a filemegosztás, de úgy, hogy ebben a hálózatban lehetnek olyan Linuxok, amelyek qemu-kvm virtualizációban olykor guest Windows-t futtatnak, s a filemegosztás feléjük is menjen.

Ennek nyilván része valamiféle névfeloldási mechanizmus, hiszen az nem járható út, hogy például a hosts-ba bedrótozom az IP címeket. Szeretném, ha megengedett lenne, hogy egyes gépek „eltűnnek”, mások „megjelennek” a hálózaton, dinamikusan kapnak IP címet, s valamilyen filemanagerben - például Windows Intéző, Thunar - tudjam böngészni a gépeket, majd a megosztásra file-t másolni vagy onnan file-t elhozni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha linuxot használsz, akkor felejtsd el a frissítéseket! (Van egy éppen most futó topic.) El kell dötened, hogy működő vagy frissített rendszert akarsz használni! Ebben az esetben természetesen egy upgrade nagyobb meló lesz. Ügyfélnél 10 év alatt 3x frissített - inkább újrarakott - rendszer ment problémamentesen sambával.
Már az sem világos, mi az a domain, domain kontroller, master browser, s mindezek kellenek-e nekem.
Ezek mind a MS Network/rendszer elemei. "Normál használat mellett" soha nem kellenek. Ha csak halványan ilyen gondolatok fordulnak meg a fejedben, akkor rossz úton jársz. És itt is van, amit mondtam. Ha ezek a gondolatok NFS témakörben fordulnak elő, akkor az "idegen" NFS-t egy windózos guru integrálta a windózos világba. Tehát, ha nincs Exchange, Access és hasonló marhaságok, akkor felejtős.

Úgyanúgy a nis, rpcbind, yp olyanok, amik vannak ugyan, de soha nem kerültek szóba. Pedik évekig használtam NFS-t Novell/linux/AIX környezetben.

Szóval:
- Ha ragaszkodsz a megosztáshoz, (több felhasználó közösen használ állományokat) akkor samba. Barátod a SWAT.
- Ha tárolni akarsz, akkor winscp. (Be lehet állítani a kiterjesztéshez a műveletet. Pl. xls->Excel.)
- Ha lassú az scp, akkor FileZilla. Achtung, achtung! A WXP nem támogatott, ezért régi verziót kell használni: client 3.7.3. Ha mást olvasol, akkor sem működik! ;)


Már az sem világos, mi az a domain, domain kontroller, master browser, s mindezek kellenek-e nekem.
Ezek mind a MS Network/rendszer elemei. "Normál használat mellett" soha nem kellenek.

Azért ez ebben a formában kicsit erős.
Már ha csak egy egyszerű otthoni hálózatról van szó, amiben 3-nál több gép beszél smb-t, akkor már nem árt tudni mi az a Master Browser, még akkor is, ha csak valami nagyon régi dialektusát akarod a sambának beszélni.

Meg azért, ha az ember b..kurálja a rendszerét, és olyanokba belenyúl, mint nss konfiguráció... Ld. kérdező esetén.
Jó ha legalább úgy az alapokkal tisztában van, hogy mi mit csinál.

Biztos vagyok benne, hogy érted amit írtál. ;)
Ennek ellenére, ha a MS Network, WORKGROUP és tsai felejtősek, akkor nem ennyire bonyolult a dolog. Ezért kérdeztem vissza, hogy a kérdező mire akarja használni a megosztást. Ilyen esetben mindaz amitől a windows windows nem létezik. Egyszerű "unix alapú" share (ok. ez baromság). Az user eléri a smb-t, és kész. Biztosan a windows alapértelmezett konfigurációja csinál olyanokat, amikről nem is akarok tudni, de működik.
Egész egyszerűen fogalmazva:
- windows felrak
- samba felrak
- SWAT - share
= múkodik.
Ha az ügyfélnél 20 gépen keletkezett magától Master Browser, akkor volt. Ha nem, akkor nem volt. XP esetén már nem beszélhetünk frissítésről sem. Legfeljebb a linux fejlődött odáig, hogy már ez sem megy. Ezért nem is értem, miért kellene tudni mi az a Master Browser ÉS az nss konfiguráció. Ez véletlenül nem hasonló dolognak a megoldása eltérő platformon és eltérő környezetben?
Pontosan erre hívtam fel a figyelmet! Ha NFS konfiguráció közben workgroup-ot látsz, akkor összekeverték a két rendszert. Ennek is van létjogosultsága, meg biztosan érti is valaki, de ez a legutolsó, ami egy MS alkalmazásokat (szerverkomponenseket külön gépen) NEM futtató rendszerben szükség van.

Egész egyszerűen fogalmazva:
- windows felrak
- samba felrak
- SWAT - share
= múkodik.

És kaptál egy olyan rendszert, ami 1) már nem támgotatott/nem fejlesztik (SWAT-ot a Samba3 után kihúzták [ami ugye EOL], a helyére lépő SWAT2 git repójához meg négy éve nyúltak utoljára...), 2) fogalmad sem lesz, hogy mi hajtja (mert azzal, hogy egy tool konfigolta be neked, az összes probléma, amiben döntést kellett volna hoznod, megmarad: a teljesség igénye nélkül - hogyan authn-eled a usereket, hogyan authz-zed a usereket, hogyan mappeled az SMB user neveket a rendszeren levő UID-ekre (ill. a csoportjaikat GID-ekre), ezeket a beállításokat központosítod-e vagy sem, milyen a környezeted [standalone gépek, gépek munkacsoportban, gépek NT domain-ben, gépek AD domain-ban] és azt hogyan éred el, milyen szerepet töltesz be, ...).

Ha csak annyi kell, hogy egy free-for-all guest share-t kirakj a 445-ös porton, a gépet IP alapján címzed, nincs semmi auth, ..., akkor tényleg egyszerű és nem kell hozzá semmi.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Értjük, az IP nem jó neked.

Akkor hogyan szeretnéd?

dns névvel?
DNS regisztrációhoz értesz?
Képes vagy a szervereid dns nevét megjegyezni fejből, és nem kell böngészési lehetőség?
Ha mindhárom kérdésre igen a válasz, akkor problem solved. nfs / samba bármi jó lehet neked, ennek megfelelően kell bekonfigurálni.

"böngészhetően"?
Tudod mi az a master browser, és hogy működik az election, milyen lokális és esetleg dhcp-n kapott attributumok, meg még ...öm tudja honnan, kerülnek figyelembe vételre?
Szeretsz sajtreszelővel rej..olni? (részletesen: minden munkaállomáson képes vagy deployolni ugyanazokat a settingeket, amik a konzisztens működéshez kellenek + megvannak az evvel kapcsolatos és szükséges előismereteid ennek az enforcementjére, hogy tényleg az kerüljön deployra és legyen az érvényes beállítás, amit te szeretnél + magabiztosan le tudod ellenőrizni, hogy tényleg így is van-e? )
Ha erre a három kérdésre igennel tudsz válaszolni, akkor az SMB egy jó választás.

Ha egyik hármasra se sikerült egyöntetűen igent mondjál, akkor nézd meg, melyiket tudod könnyebben elérni, és go that way!

A netbios... csak egy protokoll.
De ha ilyet akarsz, és nem akarsz DNS regisztrációval foglalkozni (ami szerintem sokkal egyszerűbb, és letisztultabb, még otthoni környezetben is, pl. egy dnsmasq-al, ami elérhető pl. akármelyik random openwrt-ben), akkor bizony meg kell tanuld a windowsos hálózat működését:

* Mi az a master browser szerep,
* hogyan megy a master browser election,
* a résztvevők milyen beállításokat vesznek figyelembe (pl. milyen dhcp opció, hogyan befolyásolja ezt a viselkedést)
* etc.

Persze lehet, ahogy esik úgy puffan alapon, csak ha nem tudod hogy műkdik, és mi történik a hálózatodban,...

na akkor k...a nehéz kinyomozni, hogy valami miért megy, vagy miért nem megy.

Szóval, ha ilyet akarsz, akkor bizony neked a fentieknek kell utánanézz, és megtanuld.
Előre súgok: szopó! ;)

Kifelejtetted a topc kis nevét. Van benne egy Windows XP is. :)
Szóval a feladat több mint 10 éve változatlan, ehhez képest SWAT? tökmindegy. Nekem 12 évig 20 géppel több felhasználóra és csoportra működött. (NEM MUNKACSOPORT) A megoldás roppant egyszerű: a linux usereket leképeztük a smb és az imapd felé is (a szerveren), azaz minden windows userhez kellett egy unix user is. Nem ördöngős dolog, viszont roppant egyszerű vele dolgozi akár MS Network ismerete és használata nélkül is. Tehát nem tool konfigolta, hanem én scripteltem. ;)
Eközben az egész MS világháló megoldásáról beszélsz, pedig világosan leírtam: NEM ez a cél. Mindössze egyszerű megoszás.

+1

Nem win adminkent anno tobb kis cegnel ugyanigy csinaltam meg mint te, csak nezek itt, hogy mivel etetik a kerdezot, ismerd meg a 7 meletes teknologiai sztekk minden elemet igy, amig ezt nem fogod fel addig ugy. Mivan?? En nem tudom mi tortent XP utan, ott meg ez mukodott (emlekezetbol, vazlatosan):

addgroup sambausers
addgroup ugyvezetes
mkdir sambashares/ikszkft
mkdir sambashares/ikszkft/ugyvezetes
chown -R valami:sambausers ikszkft
chown -R valami:ugyvezetes ikszkft/ugyvezetes
chmod a-rwx ikszkft/ugyvezetes
chmod g+rwx ikszkft/ugyvezetes
apt-get install samba swat
swatban uj megosztas letrehozas, szerver ugyazaz a workgroup mint az osszes kliens ("IKSZKFTIRODA")
adduser --no-create-home --disabled-password --mittomenmar... --ingroup sambausers kovacs2bela
smbpasswd -a kovacs2bela
adduser --no-create-home --disabled-password --mittomenmar... --ingroup ugyvezetes fonokgizi
smbpasswd -a fonokgizi
kesz.

Ezutan kovacs2 a \\ikszserver\ helyen elerte a megosztast, gore gizi meg a \\ikszserver\ugyvezetes konyvtarba is be tudott kukkantani.

Elhiszem, hogy fogalmatlan hulye vagyok es csak szerencsem volt a debian default beallitasaival, de a kerdezonek pont ez az osi, XP-s dolog kell. Meg akarjak tanitani kinaiul, mikozben csak nem ert valamit az uj dvd jatekos leirasaban es megkerdezett kinaiul tudokat, hogy mit ir eredeti nyelven.

Igazából a samba még csak-csak megy, azzal van gondja, hogy vagy nem találja névvel hivatkozással a szervert, vagy elhajt a fenébe azzal, hogy nincs jogosultság, és ilyenkor tör fel belőlem keserűen a klasszikusnak számító „de hát ez egyszer már működött” mondat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"azzal van gondja, hogy vagy nem találja névvel hivatkozással a szervert,"

Ehh, ilyen nincs. ( Azaz de megis, van ha valaki olyan hulye, hogy netbios (vagy rovid == host resze a nevnek) nevet hasznal dns nev helyett. Mint pl a mi felhasznaloink helyenkent. )

"vagy elhajt a fenébe azzal, hogy nincs jogosultság,"
Ilyet sem csinal, ha a config nem valtozott. Ha egyszer ment es utana nem megy akkor marpedig valami valtozott.

De a fent felsorolt dolgok egyike sem a samba hibaja.

Nem azt mondtam, hogy a samba rossz. Azt mondtam, hogy keresek egy kevés ezirányú ismerettel könnyen konfigurálható megoldást filemegosztásra.

Azaz de megis, van ha valaki olyan hulye, hogy netbios (vagy rovid == host resze a nevnek) nevet hasznal dns nev helyett. Mint pl a mi felhasznaloink helyenkent.

Ez máris kíváncsivá tett, mert lehet, hogy ebben én is vastagon bűnös vagyok. Fogalmam sincs, mit lehet, mit kell, mit célszerű, hogyan, s miért.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azt értjük, hogy keresel.
Csak valahogy van egy rohadt nagy vakfolt a szemed előtt: Már sehogy sem sikerül itt senkinek rávezetnie téged, hogy ahhoz amit akarsz, a sambás böngészhetős választás NEM a kevés ismerettel könnyen konfigurálható megoldás kategória.
Lehet megpróbálni erőlködni, meg try-and-error módon megközelíteni a dolgot, csak akkor hasznos, hogy már az elején feltételezed, hogy nem a rendszer a hibás / rosszul megtervezett, hanem neked nincs fogalmad az egész működésének alapjairól sem.

Mint írtam: Csak egyszer!!! szánd rá az idődet, hogy elolvasol, és MEGÉRTESZ egy doksit a master browser election működéséről, illetve hogy hogyan működik a browsing.

Ezt elfogadom, csak úgy vagyok a samba-val, mint egyszeri titkárnő a Windows-zal: elhitették velem, hogy ez valami egyszerűen konfigolható dolog, alig pár sor a konfig file-ban, s meg is vagyunk. Jó, értem, hogy a névfeloldás szigorúan nézve már nem samba, de ez kicsit olyan, hogy hiába van valakinek internet elérése, dns nélkül gyakorlatilag használhatatlan.

Szerk.: különben nem ragaszkodom a samba-hoz. Amennyiben nfs használata esetén egyszerűbben kivitelezhető a névfeloldás, akkor legyen az. Nekem csak annyi kellene, hogy file-t tudjak megosztani gépek között, ideértve a virtuális gépeket is. Jó volna nem IP-címmel hivatkozni, hanem némileg ergonoikusabb módon valamilyen hostnévvel.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tehát azt mondod, a helyes eljárás dns szervert indítani a hálózaton. Egy valós hálózaton ezt el is tudom képzelni, viszont az a gyanúm, a virtuális gépek miatt kell egy-egy dns szerver a virtualizációt biztosító host-okra is.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Samba esetén elég, ha WINS kiszolgálót használsz. Ehhez nem kell semmilyen Windows-os cucc, a Samba kiszolgáló is el tudja látni ezt a feladatot. Ha nem akarsz WINS kiszolgálót, akkor "kézzel" is megoldhatod a névfeloldást, amihez szerkesztened kell egy fájlt (lmhosts), ami tartalmazza az egyes gépek neveit és IP címeit egymáshoz rendelten. Ezt egy XP esetén be tudod olvastatni a TCP/IP konfigurálásánál (speciális TCP/IP beállítások --> WINS --> Keresés az LMHOSTS használatával). Ez utóbbi elég macerás sok gép esetén, de néhány PC esetén elviselhető, viszont nem elegáns...

Egyébként nem járnál jobban, ha összedobnál egy NAS-t? Kész megoldások vannak a feladatra, pl. OpenMediaVault (OMV), FreeNAS, NAS4free stb.
Ezeket elég egyszerű konfigurálni a webes felületükön, tudnak "mindent" (Samba, NFS, FTP stb.)
Ha nem akarsz rögtön gépen szerelni, virtuális gépben kipróbálhatsz pl. egy OMV-t.

Nem szedtem elég jól szét a bajaimat, valójában egyetlen témafelvetésbe sűrítettem több nyavalyámat. Egyfelől van egy konkrét probléma: egy linuxos gépen qemu-kvm virtualizációban Windows XP, a kettő között kellene file-okat cserélni. Ment, de most nem megy, nem vagyok a gép közelében, de ssh-n elérem a host-ot, ha nagyon akarom, akkor virt-managerrel a virtuális gépet.

A másik gondom, hogy egyszer meglehetősen fogalmatlanul, doksik olvasgatása után a saját gépemen véletlenül sikerült elérnem, hogy a samba szerver kiszolgáljon virtuális gépet, de fizikai interface-en is, ráadásul file browser-ben tallózhatóan, névvel. Aztán egyszer elromlott, s bosszant, hogy azóta sem tudom, mitől. Ami rosszabb, azt sem tudom, mitől működött. :)

Mivel a filemegosztás gyakori igény mind host <---> guest, mind pedig fizikai gépek viszonylatában, szeretnék végre tiszta vizet a pohárba, s szeretnék egy számomra kényelmes, könnyen megtanulható és alkalmazható eljárást arra, hogy magabiztosan, működőképesen összeszögeljem ezt szinte bárhol, bármikor. Ezért vagyok rugalmas abban, hogy samba vagy nfs, lényeg az, hogy vegyes környezetben univerzálisan használható legyen lehetőleg megbízhatóan és fájdalommentesen.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Vegyes környezetben nem jó választás az NFS, pl. Windows 7 esetén még a professional sem elég, hogy telepítsd rá a Microsoft kliensét.
Ha nincsenek nagy igények, nem kell nagy sebesség, nincsen túl nagy mozgás, akkor egy virtuálisan futtatott OMV teljesen jó lehet, hordozható, bármikor bevethető.

Értem, csak amikor a host egy Fedorát futtat, minden eszköz rendelkezésre áll, akkor virtuális gépben futtatni egy NAS-t, ezzel megetetni egy nagy rakás RAM-ot és háttértárat nem igazán optimális. Linuxozni nem ma kezdtem, csak valahogy kimaradt nekem a szerverek, névfeloldás világa.

Annyi azért kiderült, maradjak nyugton, ne erőltessem Windows-ra az nfs-t, jó lesz nekem a samba is, csak a névfeloldással kezdjek előbb valamit helyi hálózaton. Izgassak fel egy dnsmasq-ot, s talán a csodák bekövetkeznek?

Olyan hálózati szolgáltatás létezik, hogy a host tudja a saját nevét, majd valaki teszem azt broadcast címzéssel lekérdezi a hálózaton lévő host-októl, így aztán egy dns szerverrel ezek a nevek és címek feloldhatók? Arra gondolok, hogy ne feltétlenül a router futtasson dns szervert. Vagy mindenképpen úgy érdemes, hogy aki dhcp-n a címet adja, az mondja meg hozzá a nevet is? Az a baj, hogy ekkor csökken a rugalmasság: ha ugyanaz a gép statikus címmel, de nem a router által osztandóval lépne a hálózatra, máris nem lehet tudni, név szerint ki ő.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Linuxozni nem ma kezdtem, csak valahogy kimaradt nekem a szerverek, névfeloldás világa.

Az tök mindegy mikor kezdtél.
Meg, ha már "linuxozás"ként fogalmazol, az is elárul valamit.

Hogy konstruktív is legyek, csak újra azt tudom mondani: meg kell barátkozz a gondolattal, hogy a windows névfeloldásával megismerkedj.
Az sem árt, ha hálózati alapokkal tisztában vagy. Pl. tudod mi az a collision domain (bár ennek egyre kisebb szerepe van ma már), broadcast domain, etc.

Ha van egy "routered"... Optimális esetből kiindulva, hogy egy 0 megosztással futó sambát arra is lehet hegeszteni, én a következőt csinálnám:
Kinevezném őt master browsernek, lévén, amikor a "routered" nem megy, akkor úgyis nagyobb gondod van annál, mint hogy sambát akarj elérni bármilyen környezetben.
(Főleg, hogy ha annak a beépített switchét használod a helyi eszközeid összekötésére is.)
Onnantól, hogy ez megvan, elérném, hogy ő legyen a master browser, minden eszközöm számára.
Ha jól csinálod, akkor az sem baj, ha nincs minden ugyanabban a broadcast domainben.
Pl. kézileg, vagy dhcp beállítással megadod a node-type-ot, meg hogy ki legyen a master browser. (Ahogy fentebb is írták, van ahol "WINS" szerverként hivatkozik rá a beállítási panel)
Onnantól kezdve, még ha a virtuális windowsod egy másik nat mögött is van, de a routeredet eléri, akkor tud tőle kérdezősködni, és ha unicaston eléri a megosztást biztosító IP-t, akkor már be is tudsz csattanni rá miután betallóztad.

Arra gondolok, hogy ne feltétlenül a router futtasson dns szervert.
Ez miért baj amúgy? A routered folyamat be van kapcsolva, <5W energiát fogyaszt. Miért ne?

Olyan hálózati szolgáltatás létezik, hogy a host tudja a saját nevét, majd valaki teszem azt broadcast címzéssel lekérdezi a hálózaton
Van. Defaultban így működik a master browser election, hogy broadcast storm-mal döntik el ki nyerjen.
A hansúly a storm-on van. Igen, jól sejted, az nem jelent jót! By design szarság van.
Ezért mondtam, hogy érdemes ismerni, hogy működik a master browser election.
Ezért mondom, hogy ha nem akarod, hogy a hálózatod mást se csináljon folyamatosan csak a master browser election broadcastjait kézbesítgesse, akkor TE EXPLICIT kijelölsz egy master browsert. Célszerűen a ROUTERED, mert az MINDIG be van kapcsolva.

Plusz mint írtam, nem árt az alapokkal tisztában lenni, pl. hogy mi a f... is az a broadcast domain.
Ha az említett virt géped nem L2 kapcsolódik a lan-odra amin a többi cuccod van (pl. a megosztást biztosító gép), akkor az broadcastolhat világnak... Kéménybe korommal esete.

Meg, ha már "linuxozás"ként fogalmazol, az is elárul valamit.

És mit? Nem különösebben titok, teljes mértékben hobbyként, kedvtelésből ismerkedtem meg vele, de annyira bejött a rugalmassága, scriptelhetősége, testreszabhatósága, hogy otthoni gépen nagyjából 2000 óta csak Linux van, munkahelyin néha használok Windows-t, de elvétve. Egész egyszerűen kellenek nekem azok a utility-k, amelyekkel szinte bármi megoldható. Bash, awk, sed, meg egy rakás aprójószág.

Ami a router-t illeti, sajnos picike, a nat-oláson túl nem nagyon alkalmas másra, mert van 4 MiB flash benne meg 32 MiB RAM.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Amennyire a kommentekből látszik, a területen lévő szakértelme elég felületes.

Pl. a leírt jelenségekbe simán belefér, hogy fogalma nincs, hogy működik a master browser election.
Újraindított egy gépet. A kisebb uptime miatt, már más paraméterekkel vesz részt az electionben is a gépe.

Aztán, lehet, hogy mivel nem ő nyerte a választást, "vak" marad, mert... És akkor itt jönne az, hogy elolvassa és megérti a logokat, majd ennek megfelelően, és a működés ismeretében már javítja is.

Igen, de az alapvető fórum viselkedési normákkal (mondhatni netikett) sem vagy teljesen tisztában.

#1 folyamatosan ellene mégy minden javaslatnak
#2 csak menetközben, random csöpögtetsz olyan információkat, amikből kiderül valami

Könyörgöm, legalább kérdezni tanuljunk meg! Ez elektronikától, linuxtól, meg minden ...tól független!

Értékelem a segítséged, örülök is neki, ugyanakkor te is tudod, ha pontosan tudnék kérdezni, talán már a választ is tudnám. Az ember sokszor azért kérdez pontatlanul, esetleg nem igazán lényeglátóan, mert az adott területen vannak hiányosságai.

Például az nfs-sel hozakodtam elő, mert kitaláltam, az jó lesz nekem, mivel a samba-val eddig mindig csak gondom volt. Aztán itt kibogoztuk, hogy sohasem volt gondom a samba-val, nekem mindig a névfeloldással volt problémám, ennél fogva nfs-sel éppen úgy szívnék.

Éppen az az oka, hogy infókat csöpögtetek, mert magam sem tudom teljes bizonyossággal megmondani, mit is szeretnék. Ahogy tisztul a dolog azáltal, amit írsz, illetve a többiek írnak, tudok újabb kérdésekkel előhozakodni. Mondhatnám azt is, hogy mindössze annyit szeretnék, hogy „működjön ez a sz.r”, de nyilván nem fogalmaz az ember arrogánsan, ha segítséget kér, továbbá valóban szeretném érteni, hogy mitől megy a villamos.

Nem feltétlen megyek ellene minden javaslatnak, hanem puhatolózom, szeretném látni a lehetséges alternatívákat, s kiválasztani közülük a számomra legkedvezőbbet. Van a dolognak műszaki háttere is. Nyilván céges környezetben van erőforrás, de ott, ahol egy 7000 Ft-os TP-Link TL-WR841ND a „router”, lehet, picit másképp kell megközelíteni a kérdést, különösen, ha az, akinek erre szüksége van, egy fillért sem áldoz rá, mondván, nehogy már probléma legyen a XXI. században gépek közötti filecsere, ha azok fizikailag össze vannak kötve.

Ebből én az a láncszem vagyok, aki szeretné ezt megérteni, de nem feltétlenül olyan szinten, hogy a félév végén vizsgázhassak is belőle. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez nem hülyeség, csak nem értesz hozzá. :(
Vagy mit mondanál egy olyan rendszer rendelkezésre állásáról, amit frissítgetsz, osztán nem működik?
Elfelejted, hogy egy rendszernek nem az a célja, hogy frissítsed, hanem legyen megbízható, biztonságos és folyamatos működésű. Megfordítva a dolgot, ha az előbbi feltételek teljesülnek, akkor mi lenne az oka/célja a frissítésnek. Ez nem fittnessz világbajnokság!
Természetesen a fenti elvárásoknak nem megfelelő, l'art pour l'art ideológiával kialakított és üzemeltett rendszernél azt csinálsz amit akarsz.

Ez az kijelentés nem fedi az igazságot. Inkább hit kérdése.
Ha lenne egy jól kialakított rendszered, akkor nem kellene ezt elhinni. Általában célszerű megvizsgálni a frissítést: Mit javít, használsz-e olyan komponenst/üzemmódot ami miatt fel kellene rakni? Következő lépésként tesztelni kell mit okoz a frissítés. Ha nagyobb a kár, akkor nem alkalmazható. Ez a való világban így működik.

Ide tartozik egy sztori.
- Négy csomagot kell biztonsági okok miatt frissíteni a rendszereden!
(A szóló nevét takarja jótékony homály: zeller huptársunk volt. :))
- Sz*rt! - és mind a négyet leinstalláltam.
(Kérdőjel alakú pislogás.)
- Ja, én vagyok a hibás. Ez a négy csomag biztonsági okokból nem volt fent. De közben volt egy biztonsági audit! A rendszerrel inkompatibilis szoftverük miatt kellett felraknom, és fentfelejtettem. :-)

Komolyra fordítva a szót, ez nem linux rendszer volt. Linux esetén néha annyira kaotikus összefüggés van az egyes csomagok között, hogy nem egyszerű a frissítgetés. És ez elég szomorú.

annyira kaotikus összefüggés van az egyes csomagok között

Melyik évtizedben és melyik disztribúcióban? Fedorán nem. Ha törés lenne a függőségekben, a csomagkezelő akkor kihagyja az érintett csomagok frissítését Fedorán.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

törés != kaotikus*
És íme, így néz ki a hit. Nem kétlem, a Fedora az egyetlen, igaz és tökéletes disztribúció. ;) Bár láttam pl. linux vezérlésű Motorola telefonközpontot is. Melyik disztró volt az alapja? Hát egyik sem, mert volt egy olyan elvárás is, hogy működjön.

*Ezt most nem vesézném ki. Több topicban is szóba került.

Az nem sec, hanem ad2k-s móka volt emlékeim szerint :) Viszont a biztonsághoz az is hozzátartozik, hogy fölösleges sw ne legyen a gépen - ami meg ott van, azt tessen frissen tartani - ha csak lehet.

A dependency problémák valóban lehetnek nagyok és károsak-kórosak, de ha gyártói/szállítói támogatást szeretnél igénybe venni, akkor muß felrakni a függőségeket...

Bizony sec volt, sőt a sendmail is benne lehetett. Azt meg nem a biztonsági megfontolás miatt nem használtuk (ami miatt tiltotta a CÉG), hanem bizonyíthatóan hibás volt a hozzá csomagolt config előállítási módszer. Azaz pont locsemege-szerűen jártunk: A frissítés kinyírta a rendszert. Ezért került fel a következő 10+ évben a postfix, méghozzá installp formátumban, amit én raktam össze.

Eme utolsó mondatodban MS effektust érzek. :)
Van olyan rendszer, ami nem így működik. (prerequisit, corequisit és tsai)
Nem emléxem a pontos nevekre, csak a jellegére kreálok egy példát.
- install esetén felmegy a bost.net.all + magával rántja a szükséges nls csomagot
- utána szabadon leszedheted pl. a bos.net.uucp csomagot, vagy a plusz nls csomagot, stb.
- természetesen a fennmaradt csomagok konzisztensek és frissíthetők

Ezzel a rutinnal próbáltam linuxot optimalizálni, de lehetetlennek bizonyult. Valamelyik topicban megtalálod, itt csak a "jellegét" írom le. Alapul véve a fenti példát a uucp eltávolítása falakba ütközik, mert eltávolítaná az észak-közép-tajvani-ciril tájszóláshoz tartozó nls csomagot (LANG=C esetén:)))), ami ütközik az akármilyen más, de legalább 30 csomag összefüggéseivel, tehát a fél rendszert lerombolná. Ez a gondosan megfontolt :) csomag-kompozícióknál sajnos gyakran előfordul. (Nem, nem keverem a bundle összefüggéseivel!)

A muß-ról csak annyit, hogy eme karakter már vagy 20 éve osztályidegen. Ha meg nem repűlőékezetesen írtad, akkor nem is lehetsz igazi szakember! :-)

Bocsánatot kérek, de zellerrel egy offtopic nosztalgiázásba fogtunk. Ennek viszont semmi köze nincs a linuxhoz, mivel az események AIX 4 és 5 verziók alatt történtek.

A linuxos élmények elég frissek. Az a sajnálatos tendencia, hogy az (egyes)linux disztribúciók kivitelezésben egyre inkább tendálnak a windows irányába, hacsak nem rosszabbak.

Az offtopicból még az is kiderül, hogy a 15 évvel ezelőtti AIX csomagkezelése/-összeállítása (device driver kezelése!) már akkor jobb volt a mai linuxokénál. Ez nem magyarázható csak a nyílt/zárt rendszerrel. (Bár az AIX-hez is hozzátehetsz bármit, tehát csak az oprendszer forrás zárt.) Ez alól három disztribúció lehet kivétel: RHEL, SLES és újabban az Ubuntu Enterprise. Ugyanez vonatkozik a rendszerek (disztribúciók) dokumentáltságára is.

Alapul véve a fenti példát a uucp eltávolítása falakba ütközik, mert eltávolítaná az észak-közép-tajvani-ciril tájszóláshoz tartozó nls csomagot (LANG=C esetén:)))), ami ütközik az akármilyen más, de legalább 30 csomag összefüggéseivel, tehát a fél rendszert lerombolná. Ez a gondosan megfontolt :) csomag-kompozícióknál sajnos gyakran előfordul. (Nem, nem keverem a bundle összefüggéseivel!)

Többek között ezért használok Gentoo-t ;-)
és még ez sem tökéletes, de sokkal közelebb áll a valósághoz. Majdnem olyan, mintha én csináltam volna, viszont csak töredék energiába kerül ahhoz képest.

Természetesen a második verzió. Már 2-3 gépnél is sokkal kevesebb energia vm-ben/chrootban buildelni, plusz lehet tesztelni élesítés előtt, plusz ha vissza kell menni, akkor az is sokkal egyszerűbb, és nem utolsó sorban: lehet jó combos gépen buildelni, és régebbi gépen futtatni. Kell hozzá egy infrastruktúra, az mondjuk kétségtelen.

Mit javít

Ezt honnan tudod meg? Van Windows forrásod? Nekem nincs. A "bőbeszédű" MS odalakon kb. egy félmondat szokott arról lenni, hogy melyik komponensnek kb. miféle dolgához nyúltak hozzá. Mondjuk a login DLL authentikációs hibáját fixálták. Aztán mondd meg, hogy ez érint-e vagy sem...

És gyakorlatilag minden hónapban van security vonatkozású, alap OS DLL-t cserélő patch, amiről jobb esetben megtudsz annyit, hogy melyik CVE-t fixálja, rosszabb esetben még ennyit se (ha nincs CVE pl). Oszt ennyi.

Na ha ez alapján megalapozott döntést tudsz hozni, komolyan irígyellek...

Biztosan azt hiszed megfogtál. :)
Mellékesen a topic WXP-ről szól. Frissítés nincs!
Amiről írtam, az konkrétan AIX - legyen offtopic.
Persze nem ennyire egyszerű a helyzet. Osztályozzuk a frissítéseket, méghozzá példákkal.
1. Security
A frissítés javítja mondjuk az Internet Explorer, vagy a Windows Media Player biztonsági hibáit. Nem rakom fel, mert
- nincs ilyen a rendszeren
- esetleg van, de nem használom (és gondoskodtam róla, hogy el se indulhasson)
Viszont nem tudtam installálni az elavult SHA-1 aláirás miatt egyes újabb programokat. Az ehhez tartozó frissítést sikerült felraknom.
2. Hibajavítás
Nem/vagy hibásan működik az xxx program. Ha használok ilyet, akkor felrakom. De ha az adott program javított funkcióját nem használom, akkor esetleg még sem rakom fel.
3. Funkció bővítés
Új usb eszköz egy bizonyos üzemmódját nem támogatja a WXP-m. Javítás nincs, de a MS megoldása egy embedded rendszerhez tartozó driver felrakása. Ezt megtettem.
Nem támogatott a skype. Cserélni kellett az SP2->SP3 kernel32.dll-t. Bár ez nem életbiztosítás!
4. Megelőző karbantartás (preventive maintenance + Technical Level)
Ez az AIX-re jellemző karbantartási mód. Ha eldurran egy diszk vagy a gép, akkor esetleg már nem lehet beszerezni régi alkatrészt a cseréhez. Egy ilyen frissítés hatására felkerül az új driver, illetve az új hw bekerül az adatbázisba. HW csere esetén az oprendszer további frissítés nélkül képes használni az új eszközt.

Visszatérve a windowsra, de bármilyen más rendszerre. Azért írtam, hogy a befagyasztott rendszerek használata a járható út, mert ott tudod mi van fenn, mi működik és mit használsz a rendszerből. Egy ilyenre nem lehet agy nélkül felrakni egy (teszteletlen) frissítést. A javítások listája még MS esetében is megtalálható. Egy update esetén felsorolják a hozzá tartozó tételeket (KB article number). Hotfix esetén ez ki is olvasható, míg egy nagyobb update általában a hotfixek gyűjteménye. Pont ezért tartom jónak az XPSP2 használatát, mert az ismert hibáival együtt kiforrott rendszer, így alkalmas a befagyasztásra. Nem csak azt tudod milyen hibák voltak az SP2-ben, hanem azt is, hogy mik lesznek :), azaz miért nem érdemes SP3-mal foglalkozni. ;)

Ezek mind megtörtént okoskodások. A frissítések kezelését mindenképpen meghatározza, hogy otthoni játékgépről, munkához használt rendszerről vagy business critical alkalmazást kiszolgáló szerverről van szó. Az utóbbi igen egyszerű, mert a windwos kiesett. :-D

Biztos, hogy megfogtalak :D

A javítások listája még MS esetében is megtalálható. Egy update esetén felsorolják a hozzá tartozó tételeket (KB article number).

Ezt a hajadra kenheted. De tényleg. A KB article-ből nem derül ki, hogy pontosan mit változtattak, sokszor az sem, hogy ez kit/mit mennyiben érint. Ami biztosan kiderül, hogy mely fájlokhoz nyúltak hozzá, ezt persze elég egyszerűen ki is lehet deríteni. Azt tudhatod, hogy az adott fájlt használod-e, és itt véget ér a történet, mert ha nincs internal accessed, továbbá nem óhajtasz nekiállni disassemblálni a kódot, szinte biztosan nem tudsz meggyőződni arról, hogy a használt és megváltoztatott kód mennyiben érint. Már persze ha nem tudsz "leállni" az adott DLL használatával, ami mondjuk erősebb core DLL-eknél szinte lehetetlen, vagy kb. teljesen el kell szeparálnod a gépet a külső felhasználói forgalomtól. Nyilván a "húzzuk ki a hálókábelt, zárjuk be a gépet egy szekrénybe" hozzáállás működik, ez kétségtelen :D

Ebből kiderül, hogy nem bízol a MS-ban. Ezzel őszintén egyetértek.
Én meg bízok az IBM-ben, ezért a - Hiba kód, Hiba leírás, javítottuk az nnn-ben - számomra mindig meggyőző volt.
A kutyus inkább ott van elhantolva, hogy míg az AIX elég fegyelmezett rendszer, a windows és a linux meg nem. Így egy entitás modosításának a hatóköre az előbbinél belátható, mig az utóbbiaknál a rosseb se tudja.
Persze tudok AIX rémtörténetet is. Véletlenü pont NFS-t is frissítettünk és nem bírt elindulni. Csomag kibont, prerequisit megnéz, sömmi. Akkor górcső alá vettük az üzeneteket és kiderült: nincs math lib.
WTF, mit számol az NFS?! Ilyen meg úgy fordulhat elő, hogy a fejlesztők bizonyára valami performance/statisztika számításához használtak math dolgokat, majd a production-ben bennefelejtették a kódot. A csomagban a helyes működéshez nem kellett volna ilyennek lennie, ezért nem szerepelt a math lib a prereuisit-ek között, tehát az install nem rakta fel. A program meg szigorúan a libeket tölti először, így el sem indult.
Azért érdekes ez az eset, mert nyilvánvalóan egy MS rendszeren egyszerűen, alap eszközökkel egy ilyen hibát nem tudsz felderíteni. (strings, grep, hex editor, obj dumpolás már nem alap eszköz)
Elismerem, hogy a windows-hoz jóval kevesebbet értek. De szeretek és szoktam is olvasgatni. Ha könnyedén elérhető lenne egy ilyen hiba felderítéséhez az információ, akkor csak megtaláltam volna.

( tovis v | 2017. 02. 09., cs – 17:48 )

Sajnálom, de azt kell hogy mondjam a samba tökéletes ha windows -nak szolgáltatsz. Viszont, a név feloldás az ősidők óta nem erőssége a windows -nak, ha működött is lassú volt (akár félóra az NT4 korszakában) hiába találták ki a wins -t, ami most már ki is kopott (ha jól tudom).
Szeretjük az IP címeket, az IP címzés jó, szerettesd meg barátoddal is.
Ha annyira szeretnél "név szerint" hivatkozni a szerverre akkor szerkeszd a windows -ban a c:\Windows\System32\Drivers\etc\hosts fájlt.

A samba konfigurálása nem túl egyszerű, de még nekem is sikerült - még annyira is letudtam butítani, hogy DOS alól be lehessen jelentkezni (na ez csak két tűzfal mögött :) Egyébként milyen disztrót használsz? - én Debian.

* Én egy indián vagyok. Minden indián hazudik.

Fedorát használok, ezt ismerem, kedvelem. Minden jó benne, mindent meg lehet vele csinálni, ha valami nem megy, akkor magamban kell keresnem a hiányosságot. Igazából nem akartam bedrótozni statikusan a címeket, mert dhcp van, igaz, kvázi statikus, mert a router-en viszont MAC alapján azt mondom, hogy adott MAC-hez adott IP-t rendeljen, aztán ami ezen felül jelenik meg a hálózaton, annak meg adjon olyan címet, amit akar. Már persze a lefoglalt címeken kívül.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hááát, egy fájl szervernek dukál a fix ip cím - ő a szerver.
Milyen vasra kerülne a samba (vagy nfs)? - lehet ez egy a routerbe dugott USB pendrive (esetleg 2,5" kis HDD)?
Ráadásul, emlékeim szerint, van valami hálózati tallózó - a samba konfigurációban is be kell állítani, különben a magasabb prioritású(?) windows 10 a "fő tallózó" nem a szervered.

* Én egy indián vagyok. Minden indián hazudik.