megosztott /home és jogosultságok

Linux-kezdő

Sziasztok!

Adott több gép. Mindegyik gépet többen használjuk, és felváltva, hogy melyiket. Problémás, hogy nehéz szinkronban tartani a home könyvtárakat, és a felhasználói jogokat.
A következőt szeretném megoldani:
- Egy közös /home könyvtár legyen
- Egy helyen kelljen létrehozni és adminisztrálni a usereket

A közös home-ra van ötletem. Az egyik gépen létrehozok egy NFS foldert, és a többin ezt csatolom fel. Ez működik is, de ahova felcsatolom, a rootnak nincs joga minden könyvtárhoz. Eltérő lehet a root uid-ja?

A központi user adminra nincs ötletem. Szerintetek mivel lehet az ilyet megoldani?

Köszönöm,
András

  • 3118 megtekintés

( eliyahu | 2011. 10. 26., sze – 08:57 )

Ja, bocs. Mindegyik gépen linux van. :-)

( zeller | 2011. 10. 26., sze – 09:02 )

A root mindenütt 0 uid, azonban alapértelmezetten az NFS-en felcsatolt könyvtárakban nobody userként matathat. A megoldást lásd: exports(5)

( apal v | 2011. 10. 26., sze – 09:21 )

Eltérő lehet a root uid-ja?
A root uid-ja mindenhol 0, de az nfs kliens az nobody-ra (65534) forditja. Ezt ki lehet kapcsolni a no_root_squash opcioval, lasd `man 5 exports`.

Szerintetek mivel lehet az ilyet megoldani?
Vagy NIS, vagy egy halozati/adatbazisos nss+pam modul. Lehet ezutobbi LDAP is, vagy aka'r mysql alapu is, mindegyik mukodik teljesen jol. De fontos hogy itt az ``admin''-t maguk a modulok nem szolgaltatjak, csak annyit lehet elerni hogy mindegyik ge'p ugyanabbol az adatbazisbol vegye a belepesi adatokat (felhasznalok listaja, jelszavak ugyanazok legyenek mindenu"tt, stb). Ezek fele' me'g kellhet egy kulon admin felulet is, ha epp' ugy hozza a szu"kseg, de ez egy masik mese.

( golgota | 2011. 10. 26., sze – 10:28 )

Kevés flehasználónál NIS, 10+ esetében LDAP.

Azt hiszem az LDAP lesz a megfelelő.
Tudnátok segíteni az elindulásban? Elég nagy terület, és egyelőre arra sincs ötletem, hogy mire guglizak rá. :-(

Az egyszerűbb oldalról próbáltam megfogni a dolgot, Felraktam az LDAP kliens és szerver csomagokat. Létrehoztam Yast2-ben (igen, Suse van a gépeken) egy LDAP szervert, a másik gépen meg egy LDAP klienst próbáltam beállítani. Hogyan tudom elérni, hogy:
1. a kliens lássa a szervert
2. az eredeti célt elérjem, új user létrehozásakor minden gépen létrejöjjön a user

Tudom, elég lamer kérdés, ezért is raktam a kezdő kategóriába. Jól jönne egy mórickás segítség.

Köszönöm,
András

1. szerver telepítése
2. megfelelő schema fájlok hozzáadása (samba, stb. amire szükséged van)
3. kliens telepítése
5. ldap szerver feltöltése a felhasználókkal/hosztokkal
5. ldapsearch/ldapmodify a kliensről simple bind-dal, hogy működik a szerver
6. nsswicth/pam (pam_ldap) hangolás
7. felhasználó törlése az /etc/passwd-ből, id felhasználónév -re vissza kell kapd az ldaptól a felhasználót. Ha nem megy, akkor ldap szerver logjainak olvasása

Problémák:
Az ldap akkor jó, ha majd folyamatosan megy szerverként az egyik gép. Vagy az összes gépen fel kell telepítened a szervert és replikációt kell beállítanod. Ebben az esetben az ldap.conf-ban célszerű az összes szervert felsorolni nem csak a localhoston futót.

+ jóságok
kerberos belövése

És innentől nyílik meg a világ. :)

Köszönöm, kezd összeállni a kép, hogy mit is kellene csinálnom.
Amit nem értek, hogy több helyen be kell állítani egy domaint, pl a slapd.conf-ban:
suffix "dc=example,dc=com”
Ide milyen domain-t kell megadni? A szerver domain navét? És ha nincs, akkor megadhatom az IP címét is? Valahogy így:
suffix "dc=192.161.1.1” ?

Elvileg fut a slapd:
openldap 2015 0.0 0.3 27444 3448 ? Ssl 13:09 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d

Ennek ellenere ha megprobalom a passwordoket importalni, akkor ezt kapom:
./ldapadd -x -h hostname -D "cn=ldapadmin,dc=ericsson,dc=se" -w password -f /root/passwd.LDIF
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Miert akadhat el? Firewall nem lehet gond, hiszen sajat magan probalom.

THX,
Andras

( dj | 2011. 10. 27., cs – 12:19 )

Ha suse, akkor a yast-ban át lehet állítani az authentikációt ldap-ra vagy akár nis-re pár kattintással. Persze előtte az ldap szervert be kell állítani. Lehet, hogy a nis-t érdemes lenne megnézned, ha már tisztán linux-os a környzet.

( sany | 2011. 10. 30., v – 19:59 )

"- Egy közös /home könyvtár legyen
- Egy helyen kelljen létrehozni és adminisztrálni a usereket"

Miért kell több user?
Ha minden közös, elég egy is és mindenki ennek a nevében lép be.
Vagy tévedek? Naplózni akarod ki mikor mit csinál(-t)?

( eliyahu | 2011. 10. 30., v – 22:57 )

“Linux bevetés közben” szerint az /etc/ldap/slapd.conf –ba kell beírni a kvetkezőket:
suffix “dc=example,dc=com”
rootdn “cn=ldapadmin,dc=example,dc=com”

A könyv szerint megadható még password is, de nem szükséges. Ezután el lehet indítani az /etc/init.d/slapd start paranccsal. Namost, ez nekem nem működik. Az /etc/init.d/slapd az /etc/ldap/slapd.d/ könyvtárból várja a paramétereket. Ha átírom, akkor nem működik. Alapból elindul a deamon, de nem tudok rá csatlakozni az ldapadd-dal (mindig ezt írja ki’ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)’), és az /etc/ldap/slapd.d állomány eléggé áttekinthetetlen. Van ennek valami konfig felülete?

( spectator | 2011. 10. 30., v – 23:44 )

Ez igy hosszu lesz.

Javaslom a kovetkezo google-t:

user auth ldap

de egyebkent egy "-x" hianyzik.

( eliyahu | 2011. 10. 31., h – 10:50 )

Kezdek belekeveredmi. :-(

Mostanra sikerült elérnem, hogy egyáltalán ne működjön a slapd. Ezt nehéz volt elérnem, a teljes tegnapi napom ráment. :-)
Próbáltam reset-elni a jelenlegi állapotot egy reinstallal, de nem sikerült. Megjegyzi a beállításokat. Nem értem, mert már az etc-ből és a var-ból is töröltem.

Ami nagyon zavaró, hogy a legtöbb leírás slapd.conf-ról szól, de ugye az újabb verziókban slapd.d-n belül van a config fájl. Ez, elvileg menet közben is szerkeszthető. Hogyan lehet módosítani ahhoz, hogy ne keljen újraindítani a slapd-ot?

Próbáltam egy slapd.conf fájlt importálni: slaptest -f slapd.conf -F slapd.d
Erre ezt írja:
could not open config file "/etc/ldap/slapd.conf": Too many open files (24)
slaptest: bad configuration directory!

Ami nagyon zavaró, hogy a legtöbb leírás slapd.conf-ról szól, de ugye az újabb verziókban slapd.d-n belül van a config fájl. Ez, elvileg menet közben is szerkeszthető. Hogyan lehet módosítani ahhoz, hogy ne keljen újraindítani a slapd-ot?

Szerkeszteni szerkeszthető menet közben a slapd.conf, de a legközelebbi újraindításnál fogja azt olvasni a daemon...

Létezik olyan megoldás, hogy a konfigurációt az adatbázisban tárolja a daemon, és az elején egyszer be lehet tölteni. Ez azoknak készült, akiknek egyébént működik az adatbázisa és értenek is az egészhez. És még ők is szopnak ezzel a megoldással néha. Mivel te nem értesz hozzá, ne szopasd magad ezzel az adatbázisbatöltögetős konfig fájllal, maradj a slapd.conf verziónál.

Próbáltam reset-elni a jelenlegi állapotot egy reinstallal, de nem sikerült. Megjegyzi a beállításokat. Nem értem, mert már az etc-ből és a var-ból is töröltem.

Akkor nem törölted elég hatékonyan... :)
Van egy könyvtár, abban van az adatbázisa (több is lehet, de csak nem voltál ennyire elvetemült). A slapd.conf tartalmazza a könyvtár nevét:

directory /var/lib/openldap-data.ldap1

Ha leállítod a daemont, és törlöd ebből a könyvtárból az adatbázis fájljait, akkor biztosan elmúlik minden, ami a régi installból megmaradt.

( eliyahu | 2011. 10. 31., h – 12:00 )

Tiszta lappal… (Virtualmachine-on kísérletezem, újrahúztam az egészet…)

Próbálom manuálisan elindítani a slapd-ot:
slapd –u openldap –g openldap –f /etc/ldap/slapd.conf
Nem indul el. Ha ellenőrzöm a conf filet:
slapd –Tt –f /etc/ldap/slapd.conf
akkor a következő hibaüzenetet kapom:
/etc/ldap/slapd.conf: line 31: suffix not allowed in frontend database.
slaptest: bad configuration file!
Miért?

Kipróbáltam, hogy az /etc/ldap/slapd.d –be beírtam a következőket:
olcSuffix: "dc=example,dc=com"
olcRootDN: "cn=ldapadmin,dc=example,dc=com"
olcRootPW: secret

Majd, elindítottam az /etc/init.d/slapd start-ot. Hibaüzenettel leállt, és az alábbi hibalog keletkezett a syslog-ban:
Oct 31 12:26:37 test-ubuntu slapd[1528]: @(#) $OpenLDAP: slapd 2.4.21 (Jun 2 2011 19:41:11) $#012#011buildd@palmer:/build/buildd/openldap-2.4.21/debian/build/servers/slapd
Oct 31 12:26:37 test-ubuntu slapd[1528]: is_entry_objectclass("cn=config", "2.16.840.1.113730.3.2.6") no objectClass attribute
Oct 31 12:26:37 test-ubuntu slapd[1528]: config error processing cn=schema,cn=config:
Oct 31 12:26:37 test-ubuntu slapd[1528]: slapd stopped.
Oct 31 12:26:37 test-ubuntu slapd[1528]: connections_destroy: nothing to destroy.

Mit rontok el?

( eliyahu | 2011. 10. 31., h – 13:43 )

openldap 2007 0.0 0.2 22768 2616 ? Ssl 13:22 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d/

Automatikus beállításokkal fut a server. Beállítottam az ldap-ot is, hogy csatlakozni tudjak, de…
Mivel a suffix-et és a rootdn-t nem állítottam be, ezért nem is tudom, hogy hova kellene csatlakoznom. (Azt meg megint nem tudom, hogy hogyan kellene beállítani a slapd.d-ben.)

Ami konkrét kérdés lenne, hogy a slapd.d/cn=config.ldif-ben milyen paramétereket kell megadni, amikre az ldap.conf-ból hivatkozni lehet?
(régen ez a suffix és a rootdn volt, az ldap-ban pedig a host és base néven lehetett rá hivatkozni.)

berakok neked egy mintapéldát.


/etc/openldap/slapd-ldap1.conf:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema

password-hash {crypt}

access to attrs=userPassword
by dn="uid=root,ou=People,dc=domain,dc=hu" write
by dn="cn=ldapadmin,dc=domain,dc=hu" write
by anonymous auth
by self write
by * none

access to *
by dn="uid=root,ou=People,dc=domain,dc=hu" write
by dn="cn=ldapadmin,dc=domain,dc=hu" write
by * read

pidfile /var/run/openldap/slapd-ldap1.pid
argsfile /var/run/openldap/slapd-ldap1.args

loglevel stats sync

idletimeout 3600
sizelimit 10000
timelimit 60

database hdb
suffix "dc=domain,dc=hu"
checkpoint 128 2
rootdn "cn=Manager,dc=domain,dc=hu"
rootpw password
directory /var/lib/openldap-data.ldap1
index objectClass,entryCSN,entryUUID eq
index uidNumber,gidNumber,memberUid,uniqueMember eq
index cn,sn,uid,mail,displayName,givenname pres,eq,subinitial

/etc/openldap/ldap.conf:

BASE dc=domain,dc=hu
URI ldap://127.0.0.1/

/var/run/openldap/slapd-ldap1.args:

/usr/lib/openldap/slapd -u ldap -g ldap -f /etc/openldap/slapd-ldap1.conf -h ldap:///

/etc/nsswitch.conf-ban:

passwd: compat ldap
shadow: compat ldap
group: compat ldap

/etc/ldap.conf:

uri ldap://localhost/
suffix "dc=domain,dc=hu"
scope one
timelimit 15

bind_timelimit 1
bind_policy soft

pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberuid
pam_password exop

nss_initgroups_ignoreusers root,ldap,cron,portage

nss_base_passwd ou=People,dc=domain,dc=hu
nss_base_shadow ou=People,dc=domain,dc=hu
nss_base_group ou=Groups,dc=domain,dc=hu

nss_reconnect_tries 4 # number of times to double the sleep time
nss_reconnect_sleeptime 1 # initial sleep value
nss_reconnect_maxsleeptime 16 # max sleep value to cap at
nss_reconnect_maxconntries 2 # how many tries before sleeping

Ez azért különféle fájlokban lehet másoknál, meg nem feltétlenül ezekkel az opciókkal kell használni, meg nem feltétlenül pont ezeket a sorokat kell, de a pam_ldap használatára egy példa (érdemes a meglevő, pam_unix-ot tartalmazó fájlokba belehegeszteni, nem pedig lecserélni a meglevőeket):

/etc/pam.d/system-auth:

auth required pam_env.so
auth sufficient pam_unix.so try_first_pass likeauth nullok shadow
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_ldap.so

password sufficient pam_unix.so try_first_pass nullok md5 shadow
password sufficient pam_ldap.so use_authtok
password required pam_deny.so

session required pam_limits.so
session required pam_env.so
session required pam_unix.so
session optional pam_ldap.so

Kipróbáltam, de valamiért nem működik. A kliens-en megadom a usernevet, és a passwd-öt, de valamiért a local /etc/passwd-ből veszi az adatokat.
Az ldap server oldalán a szslogüban ez szerepel:

Nov 7 14:37:50 ubuntu slapd[1073]: Entry (cn=eandill,ou=test,dc=example,dc=com): object class 'account' requires attribute 'uid'
Nov 7 14:38:48 ubuntu slapd[1073]: Entry (uid=1000,ou=test,dc=example,dc=com): object class 'posixAccount' requires attribute 'cn'
Nov 7 14:39:01 ubuntu CRON[8482]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)
Nov 7 14:42:59 ubuntu slapd[1073]: <= bdb_equality_candidates: (uid) not indexed
Nov 7 14:50:43 ubuntu slapd[1073]: <= bdb_equality_candidates: (uid) not indexed
Nov 7 15:04:48 ubuntu slapd[1073]: connection_input: conn=1058 deferring operation: binding
Nov 7 15:06:44 ubuntu slapd[1073]: connection_input: conn=1069 deferring operation: binding
Nov 7 15:07:40 ubuntu slapd[1073]: connection_input: conn=1073 deferring operation: binding

hát de írgya is...hozzáadtál attribútumokat, de kellene egy uid is, ami az object class leírója szerint MUST, Add hozzá az uid-ot lécci lécci lécci a cn=eandill-hez. A másik esetben meg csináltál egy uid=1000-t (ezt meg minek?) aminek nincs cn attribútuma. Az se lenne baj, ha indexelve lenne az uid, mint ahogy írja is. Bár ez utóbbi nem hiba, de lasabb lesz a keresés. Mondjuk 10 felhasználónál pont nem számít.

Érted amúgy, hogy hogy is épül fel egy ldap és benne az adatok?

A hierarchikus adatszerkezetre gondolsz? Azt elvileg értem. Legalábbis azt hiszem. :-)

Nos, a user, amivel belépni próbálok, így néz ki az ldap-ban:
dn: uid=1007,ou=test,dc=example,dc=com
uid: 1007
cn: eandill
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: 123456
shadowLastChange: 15282
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1007
gidNumber: 1007
homeDirectory: /home/eandill
gecos: Andras Illes,,,,

Itt van uid is, és cn is. Egyébként a fenti log is ezzel a bejegyzéssel keletkezett. Valamit nagyon benézek. :-(

ehhez képest egy uid=1000-el próbál meg authentikálni. Úgyhogy vagy valahol van egy uid=1000-esed az ldap-ban, vagy nem azt az ldap-ot használod amit kellene.

szerveren:
service slapd stop
slapd -d 5|tee /tmp/slapd.log

kliensen:
id eandill

aztán had lássuk mi történik

Ne így nézzen ki a user.

Így jobban fog menni:

uid=username,ou=People,dc=domain,dc=hu
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
userPassword: {crypt}asdfghertydfgh
uid: username
uidNumber: 10000
gidNumber: 100
cn: Fullname
sn: Fullname
displayName: Fullname
homeDirectory: /home/username
loginShell: /bin/sh
shadowLastChange: 12795
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
shadowInactive: 7
shadowExpire: 2147483647
shadowFlag: 0

Így meg a group:

dn: cn=sysadmin,ou=Groups,dc=domain,dc=hu
objectClass: posixGroup
gidNumber: 1200
cn: sysadmin
memberUid: username
description: System administrators
displayName: sysadmin

Ja, és aki benne van a /etc/passwd-ben, annál leszarja, hogy benne van-e az ldapban (és ezt így akarod). Amelyik group benne van a /etc/group-ban, azt meg nem nézi az ldapban.
Amelyik user benne van a konfig fájlban a nss_initgroups_ignoreusers felsorolásában, annál pedig leszarja, hogy milyen groupokban van benne az ldapban, csak a /etc/group tartalmát nézi.

------

Igazából _ne_ szerepeljen ugyanaz a username, sem ugyanaz az uid a fájlokban meg az ldapban. Groupok esetén szintén. Ne legyen ütközés, mert meglepő dolgokkal fogsz találni.

( fdavid | 2011. 11. 20., v – 20:53 )

Bar meg csak olvasgatom es nem probalgatom az altalam elkepzelt megoldast, de valahogy elozetesen szeretnem latni, hogy hogyan fog osszeallni.

Jol ertem-e a kovetkezoket:
* A kozos /home megoldhato lenne LDAP vagy NIS nelkul is, csak ebben az esetben a kozponti user adminisztracio hianyozna.
* A nem kozponotsitott user adminisztracional figyelni kellene a user es group id-k azonossagara.
* Az LDAP szerver replikacioja megoldhato, tehat nem kotelezo, hogy egy gep allandoan fusson, legalabbis a user adminsiztracio miatt onmagaban nem. Ebben az esetben az LDAP szerverek automatikusan szinkronizalnak? Mi alapjan? Van egy master, ahol a valtozasokat kell csinalni, vagy egyenertekuek? Mi van, ha utkozes van? (Jo, itt azert ez nem realis eset, csak erdekelne.)
* Ugyanakkor az NFS kiszolgalonak mindenkepp futnia kell, kulonben nem lesz /home konyvtar a kliensen. Tehat celszeruen az NFS szerver kell legyen az LDAP szerver, es akkor nem kell a replikacio.

Kerdes:
Van-e valakinek tapasztalata azzal, hogy egy g-s WLAN router hany klienset bir kiszolgalni ertelmes sebesseggel. Hiszen a /home-ban azert lehet eleg intenziv adatforgalom. Pl. internet hasznalatnal minden letoltott adat utja: internet -> router -> kliens -> router -> NFS szerver.

* A kozos /home megoldhato lenne LDAP vagy NIS nelkul is, csak ebben az esetben a kozponti user adminisztracio hianyozna.
* A nem kozponotsitott user adminisztracional figyelni kellene a user es group id-k azonossagara.

A központi user adminisztráció nélkül ami leginkább fog fájni, hogy minden usernek minden gépen külön jelszava van.
Ha a gépek úgy általában random időpontokban vannak bekapcsolva, a userek általában csak 1-2 gépet használnak, de néha bárhova be kell tudniuk lépni, akkor nagyon hamar az lesz a dolog vége, hogy a userek sosem váltanak jelszót, lévén nem tudják egyszerre az összes gépen megváltoztatni (arról ne beszéljünk, hogy mondjuk 10 user 10 gép viszonylatban mekkora szívás 10 különböző gépen jelszót változtatni...), mivel nem biztos, hogy egyidőben mind elérhető, azt meg senki nem fogja nyilvántartani, hogy hol volt már meg a jelszóváltás. Inkább a könnyebb ellenállás felé mennek, és marad ugyanaz 8 éven át...

* Az LDAP szerver replikacioja megoldhato, tehat nem kotelezo, hogy egy gep allandoan fusson, legalabbis a user adminsiztracio miatt onmagaban nem. Ebben az esetben az LDAP szerverek automatikusan szinkronizalnak? Mi alapjan? Van egy master, ahol a valtozasokat kell csinalni, vagy egyenertekuek? Mi van, ha utkozes van? (Jo, itt azert ez nem realis eset, csak erdekelne.)

Nem kötelező, hogy állandóan fusson. Automatikusan szinkronizálnak. Ha ütközés van, akkor jobb esetben az újabb verzió lesz az "erősebb", rosszabb esetben inkonzisztens marad a rendszer, még rosszabb esetben elcrashel az egész, és lehet kézzel takarítani (egyik adatbázis töröl, másikról újraszinkronizál).

A master-slave replikáció viszont meglehetősen kiforrott technológia.
A master-master is teljesen jól megy, ha alapvetően folyamatosan mennek a masterek, jó közöttük a netkapcsolat, és nem akarod ugyanazokat a rekordokat párhuzamosan mindkét szerverben updatelgetni rendszeresen. Szóval HA helyett tökéletes a master-master is. De ilyen full elosztott, sok desktop gépes master-master-master replikációt eszembe nem jutna csinálni (tekintsünk el a dolog biztonsági oldalától is: aki root bármelyik masteren, az bármit be tud írni az adatbázisba).

* Ugyanakkor az NFS kiszolgalonak mindenkepp futnia kell, kulonben nem lesz /home konyvtar a kliensen. Tehat celszeruen az NFS szerver kell legyen az LDAP szerver, es akkor nem kell a replikacio.

Ez praktikus gondolat, valóban.

Van-e valakinek tapasztalata azzal, hogy egy g-s WLAN router hany klienset bir kiszolgalni ertelmes sebesseggel. Hiszen a /home-ban azert lehet eleg intenziv adatforgalom

Mi anno 15 évvel ezelőtt egyetemi laborban használtunk 10 megás lanon linuxokat, amik a /home-ot egy nfs szerverről vették. Vezetékes lanon működőképes a technológia (élvezetesnek nem nevezném), viszont bizonyos fájlműveletek baszott lassúak tudnak lenni, az írást pedig nem igazán szereti az nfs (egészen pontosan udp-n halál, tcp-n so-so). Egyes fájlműveletek (pl. törlés) máshogy viselkednek, mint lokál fs-nél, és ez egyfelől "meglepi" az embereket, másfelől okozhat gondot is.
A wifi használata ilyen célra szerintem öntökönbökés, mivel tapasztalataim szerint sávszélességben még csak-csak, de packet loss és latency terén sokkal gyengébb, mint egy 10 megás lan, ha többen is használják, vagy van a szomszédoknak is wifijük.