Ubuntu - LTSP - PXE/DHCP meg a tobbiek

Ubuntu Linux

Sziasztok,

Edubuntu-t probalok eppen eletre kelteni LTSP uzemmodban.
Sikeresen athidaltuk a PXE bootolasi problema elso lepeset (eppen, hogy a szememet nem verte ki a BIOS Boot order menujeben az 'Integrated network card', ami != a 'Legacy network cards' opcioval) Tanulsag, mindig el kell olvasni a kepernyot, nem csak az elso betuket. :)

De amugy a rom-o-matic megoldas is szimpatikusnak tunik.

Az a resz is rendbe van, hogy a server log-jaban lehet latni a DHCP mozgast:

# cat /var/log/syslog |grep DHCP
Aug 13 18:06:16 server dhcpd: DHCPDISCOVER from 00:01:03:0d:a9:4e via eth1
Aug 13 18:06:17 server dhcpd: DHCPOFFER on 192.168.0.249 to 00:01:03:0d:a9:4e via eth1
Aug 13 18:06:23 server dhcpd: DHCPREQUEST for 192.168.0.249 (192.168.0.1) from 00:01:03:0d:a9:4e via eth1
Aug 13 18:06:23 server dhcpd: DHCPACK on 192.168.0.249 to 00:01:03:0d:a9:4e via eth1
Aug 13 18:07:07 server dhcpd: DHCPDISCOVER from 00:01:03:0d:a9:4e via eth1
Aug 13 18:07:07 server dhcpd: DHCPOFFER on 192.168.0.249 to 00:01:03:0d:a9:4e via eth1

Mar egy TFTP-s hibauzenet is feltunt, hogy nincs ott a hivatkozott file.

Szoval ott akadtam el, hogy a /etc/ltsp/dhcp.conf aljan olyan file-okra hivatkozik, amik out-of-the-box telepitve a ltsp-server-standalone csomagot nincsenek ott:

# cat /etc/ltsp/dhcpd.conf
authoritative;

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.20 192.168.0.250;
option domain-name "edubuntudomain.com";
option domain-name-servers 192.168.0.1;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;
option subnet-mask 255.255.255.0;
if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
filename "/ltsp/i386/pxelinux.0";
}
else{
filename "/ltsp/i386/nbi.img";
}
option root-path "/opt/ltsp/i386";
}

Egesz pontosan /ltsp egyaltalan nincs, /opt/ltsp is asszem talan ugy van, hogy abbol meg en csinaltam valamikor az ltsp-t

A kerdesem az lenne, hogy akkor most hogyan tovabb?
Ezeket nekem kellen valahogy prezentalni? Ha igen, hogyan?

Ha beindul, szerintem ez egy eleg nagy josag lesz :)

Koszi!

e0

  • 4836 megtekintés

igazabol hibauzenet nincs is.

a syslog-ban egyelore ennyi latszik:

Aug 14 18:45:36 server dhcpd: DHCPDISCOVER from 00:01:03:0d:a9:4e via eth1
Aug 14 18:45:37 server dhcpd: DHCPOFFER on 192.168.0.249 to 00:01:03:0d:a9:4e via eth1
Aug 14 18:45:43 server dhcpd: DHCPREQUEST for 192.168.0.249 (192.168.0.1) from 00:01:03:0d:a9:4e via eth1
Aug 14 18:45:43 server dhcpd: DHCPACK on 192.168.0.249 to 00:01:03:0d:a9:4e via eth1

Eljutunk a TFTP-ig, az mar a syslog-ban nem latszik, aztan onnan se kep, se hang.
Neha olyan szines karakterek jelennek meg a monitoron, mint amikor anno egy C64-es jatek lefagyott.

Mondjuk megadtam neki a dhcpd.conf-ban, amit kertek:

filename "/opt/ltsp/i386/boot/pxelinux.0";
option root-path "/opt/ltsp/i386";

Jo, ennel annyi csalas tortent, hogy a doksi a kovetkezot irja:

Configure it to pass a boot filename of /ltsp/pxelinux.0 and a root path of /opt/ltsp/i386
If you are using Edgy Eft, so a boot filename is /ltsp/i386/pxelinux.0. The root path is the same as above.
For ISC DHCPD, use the following options:
filename "/ltsp/pxelinux.0";
option root-path "/opt/ltsp/i386";

Namarmost errol a /ltsp-rol nem montak sehol semmit, hogy hogy is lesz, meg miert, az install alatt nem is jott letre.
A /opt/ltsp/i386/boot/ alatt meg ott a pxelinux.0 igy gondoltam, csak irjuk at a filename ocpiohoz a path-t, hatha.

Maga a subnet range is definialva van:

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.200 192.168.0.240;
# option routers 192.168.0.1;
}

ehhez kepest eleg szepen oszt neki egy 192.168.0.249-et... (?)

En a PXE problemat kizarnam.

Nem egy mai vas, HP Vectra VL600, de tud az alaplapi NIC PXE-t, TCP/IP-s DHCP-t es BOOTP-t is.

A PXE-vel nem jutottam eddig semmire, siman timeout-ol, viszont a TCP/IP-s DHCP moddal legalabb mar produkal valami kis mozgast.

Szoval itt egyertelmuen a DHCP szerverrel lesz valami obb, csak meg nem latom, hogy mi.

na, kozben elorebb jutottunk.

egy ps fax dokat tud am erni szeles kepernyon:

9631 ? Ss 0:00 /usr/sbin/dhcpd3 -q eth1 -pf /var/run/dhcp3-server/dhcpd.pid -cf /etc/ltsp/dhcpd.conf

szoval nem is jo conf file-t heggesztettem eddig (10 fekvotamasz)

Ez legalabb megmagyarazza, hogy miert oszt 192.168.0.249-et.

Na sebaj, utana igazitottam a /etc/ltsp/dhcpd.conf-ot, valahogy igy:

cat /etc/ltsp/dhcpd.conf
authoritative;

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.20 192.168.0.250;
option domain-name "edubuntudomain.com";
option domain-name-servers 192.168.0.1;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;
option subnet-mask 255.255.255.0;
if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
filename "/opt/ltsp/i386/boot/pxelinux.0";
}
else{
filename "/opt/ltsp/i386/boot/nbi.img";
}
option root-path "/opt/ltsp/i386";
}

erre meg az a kinja a TFTP-nel, hogy file not found.
Na ezt meg vegkepp nem ertem, mert ponthogy igy jok a boot image-ekhez vezeto path-ok.
Vagy van itt valami chroot jail, amirol nem tudok?

Hat ezen a ponton erdekes feladvannya kezd valni a dolog....

Ebben az esetben a TFTP file not found hibat dob, pedig a boot image-ek path-ja rendben van:

if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
filename "/opt/ltsp/i386/boot/pxelinux.0";
}
else{
filename "/opt/ltsp/i386/boot/nbi.img";
}

Ebben az esetben nem dob hibat, valamit le is huz a TFTP, csak az aztan nem indul el:

if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
filename "/ltsp/i386/pxelinux.0";
}
else{
filename "/ltsp/i386/nbi.img";
}

Most akkor mi a f.sz van?

Kozben, sikerult rajonni, hogy a /var/lib/tftpboot a gyoker es ha onnan nezzuk, akkor valoban a

filename "/ltsp/i386/pxelinux.0";

a helyes.

Nnnnna, akkor mar tudjuk, hogy pontosan honna tolt le es, hogy mit, mar csak azt kell kideriteni, hogy az me' nem indul el.

A TFTP gyökerét amúgy valami TFTP szerver mondja meg. Nem ismerem az LTSP-t, de valahol a /etc/default tuti megmondja a frankót.

Én amúgy kézzel csinálok mindent, ha ilyen van.
Általában atftpd-t használok, annak van aranyos konfig fájlja amiben meg lehet mondani, hogy mi a gyökér (legalábbis gentoo alatt), és standalone szerverként indítom (nem inetd-ből).
A dhcp-t simán konfigolom és yó.

Hogy neked is válaszoljak: Meg kellene próbálni pxegrub-ot szerezni valahonnan, és azzal tolni, hátha a pxelinux.0 vacak.

pxegrub-ot csak forrásból tudsz tenni ha yól tudom, a gentoo szervereken van grub-$VER-patches-$PATCHVER.tar.bz2 file, abba korrekten benne van a pxegrub patch-e.
Patcheld meg, utána 


./configure --enable-diskless --enable-{3c{5{03,07,09,29,95},90x},cs89x0,davicom,depca,eepro{,100}} \
--enable-{epic100,exos205,ni5210,lance,ne2100,ni{50,65}10,natsemi} \
--enable-{ne,ns8390,wd,otulip,rtl8139,sis900,sk-g16,smc9000,tiara} \
--enable-{tulip,via-rhine,w89c840}
make

A stage2 mappában lesz a pxegrub, azt kell bemásolni a TFTP gyökérbe (esetedben a /var/lib/tftpboot mappába).
Utána keress google-val a 'grub option 150' szavakra, és az első pár link valamelyike megmondja, hogyan lődd be a DHCP-t hozzá.
A 150-es opció egy grub.conf-ot (régebben: menu.lst, a név mind1) nyom ki (a TFTP gyökeréből természetesen), ezt értelemszerűen kell belőni, a TFTP device-nak (nd) a neve.
Érdemes az elejére egy 'dhcp' parancsot elhelyezni, mert nem mindig sikerül neki átvenni a PXE-től a ip-címet.
A pxelinux.cfg/default fájl tud segíteni hogyan írd meg a grub.conf-ot.

Tippeket tudok csak adni:

-Nézz meg másik hálókártyát, találtam már olyat, ami hasonló módon nem bootolt, egyszerűen azért, mert rossz volt. A legtöbb kártya megteszi, bootrom nélkül is, csak tölts hozzá le egyet: http://rom-o-matic.net/
-Próbáld meg a sima vmlinuz-t is a pxelinux helyett.
-Küldök néhány működő config részletet, hátha találsz benne valami használhatót (ez még dapper):

inetd.conf:
tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot

dhcpd.conf:
default-lease-time 21600;
max-lease-time 21600;

option subnet-mask 255.255.255.0;
option broadcast-address 10.0.0.255;
option routers 10.0.0.11;
option domain-name-servers 212.200.191.166, 212.200.190.166;
option domain-name "mic"; # <--Fix this domain name

option root-path "/opt/ltsp/i386";

option option-128 code 128 = string;
option option-129 code 129 = text;

subnet 10.0.0.0 netmask 255.255.255.0 {
use-host-decl-names on;
option log-servers 10.0.0.2;
filename "/ltsp/pxelinux.0";
range dynamic-bootp 10.0.0.41 10.0.0.49;

host amdk5_pr90 {
hardware ethernet 00:50:ba:da:9a:c7;
filename "/ltsp/vmlinuz-2.6.15-23-386";
}

hosts:
10.0.0.40 ws040.mic ws040
...

Es igen!
Ott a pont!!!
Toltottem egy ISO-t a rom-o-matic-rol es kiirtam CD-re.
Azzal bezzeg elindult a TFTP is rendesen. F@szomat a 3Com-ba!
A halokartyanal is, de ott megakadt ugy 10 potyi utan.
Igy viszont szepen be-boot-ol a kernel, csak most meg a halokartyanal akad meg a boot-olas.
Felhozza a kartyat, a CISCO swich is atvalt zoldbe, de ott megall.

Kozben beugrott egy tipp.
A gep, amit kliensnek hasznalok, voltakeppen _A_ gep, 2 halokartyaval, amibol az egyik megy a chello-ra, de pl. a beregisztralt mac address-t csak boot-olas kozben kapja meg. Ez funkcinal egy NAT-ket a szerver es a net kozott.
Jo, ez alapbol hulyeseg, de jelen esetben a gepem a statikus valtozo, a szerver meg csak ugy itt van egy idore.
Akkor itt merul fel az a kerdes, hogy amikor a halorol DHCP/TFTP-vel lehuzott kernel eljut a masodik DHCP fazisba, akkor az vajjon melyik halokartyan tortenik es ezt lehet-e szabalyozni.
Bar itt megbukik az elmelet, mert azt a kartyat irja ki, amelyikhez a rom-o-matic boot image-et toltottem.
Mindenesetre futok egy kort meg ezen elmelet korul, mert az sem kizart, hogy itt lesz a gaz.

Es b+ ez volt a gond.

A rom-o-matic azon a NIC-en boot-olt, amelyik-re toltottem (nyilvan) de aztan a kernel eth0-nak a masik NIC-et hozta fel es gondolom a chello ott nem osztott lapot.
Meg az is lehet, hogy ment volna igy is, ha gyozom kivarni.

Elso teszt:

chello-bol kabel kihuz, belso kabel meghagy, elso DHCP utan kabel atdug masikba - eredmeny: mukodik

Masodik teszt:

chello-s halokartya teljesen kihuz, csak alaplapi meghagy - eredmeny: tokeletesen mukodik

Tanulsag:

gondolkodni, nem tul bonyolitani a sajat eletunket

Amugy ezeket az onszopato kis maloroket kiveve (de hat ezekrol en tehetek), kifejezetten tetszik a cucc.
+ Abszolut konnyu telepiteni
+ Tokeletesen funkcionalis. (elsore 1028x1024-ben jott fel, 24bit-en + hang is elsore megszolalt)
+ Szinte mintha a kliensen lenne a linux (mar nyilvan laikusok szamara)
- Szerintem kicsit lassan boot-ol.

( LGee | 2007. 08. 14., k – 19:06 )

hali, probalj meg valahol tcpdump-pal belenyulni, nekunk sokat segitett a multkor hasonlo jellegu problemanal

( eyez00 | 2007. 08. 19., v – 00:21 )

na ismet erdekes jelenseg...
Dell Optiplex GX150, 3Com 3C905C-TX halokartyaval
A TFTP-ig sima, potyik vegigmennek, aztan 'Issuing RESET' es szepen ujraindul a gep.

???

Ez a gep pont nem tud ilyet, masik NIC meg most nincs a kozelben.
+ ez amugy sem megoldas
En azt szeretnem, ha ez a gep ezzel az alaplapi kartyaval tudna beboot-olni.
Tobb ilyen halozatot szeretnek majd osszedobni es ezt nem mondhatom, hogy ebbe a 30 gepbe uj NIC kene, mert keptelen vagyok megoldani, hogy az amugy tokeletesen funkcinalis NIC-en keresztul boot-oljanak.
Egy grub odagyurasa az XP melle, meg benyelheto, de a NIC csere, az nem.

( eyez00 | 2007. 08. 19., v – 14:27 )

Arrol nem talalok meg egyelore doksit sehol, hogy mit kene csinalnom, ha egy Windows-os DHCP szerverrel azonos szegmensen szeretnek uzemeltetni egy LTSP-t, szinten DHCP szerverrel felszerelve.

http://diet-pc.sourceforge.net/windows/etherboot-w2k.html

ez pl. egy leiras arrol, hogy hogyan ganyoljuk meg a windows-os dhcp szervert, hogy az szolgalja ki az LTSP DHCP igenyeit, de ez megintcsak nem elegans.

egy letezo halozatban nem mondhatom azt, hogy bocs, meg a windows-os DHCP szervereteket is szet kell ganyoljam elobb (ja meg akkor meg kene 32 uj NIC is... ;)

na ez mar egy ertelmes megkozelites, csak megint verzik egy kicsit:

If you have an already existing network you might use the following /etc/dhcpd.conf :

# dhcpd.conf
ddns-update-style ad-hoc;
option subnet-mask 255.255.255.0;
option broadcast-address 10.1.1.255;
option routers 10.1.1.1;
option domain-name-servers 10.1.1.2;
option domain-name "intra.telemedia.ch";
get-lease-hostnames true;
next-server 10.1.1.4;
option root-path "10.1.1.4:/opt/ltsp/i386";
subnet 192.168.0.0 netmask 255.255.255.0 {
range 10.1.1.100 10.1.1.199;
host thinclient1 {
hardware ethernet 00:01:02:40:50:60;
fixed-address 10.1.1.101;
filename "/tftpboot/lts/2.4.26-ltsp-3/pxelinux.0";
}

}

This way only the hosts you define in your dhcpd.conf will be offered a file to boot from, all others will boot as usual and expected.

De mi van akkor, ha en grub-os boot menu-t akarok csinalni egy gepre es ott a user valaszthat, hogy

- Windows - ami ugyebar DHCP-t kap a sajat Windows-os DHCP szerveretol
- Linux-os terminal client (LTSP) - ami ugyebar kapjon DHCP-t/TFT-t/NFS-t a sajat kis Linux szerveretol

Tudom, hogy ossze lehet vonni, de az szerintem mar gany. Mindegyiknek jobb, ha sajat cuccait szolgalja ki.

+ szeretnem tudni demozni, hogy ez itt a szerver (pl. laptop) ez meg ti halotok (lehet rajta barmi) es huss maris Linux futkoraszik a barmilyen gepeteken. Kafa nem? /* Ja, bocs... osszeakadt a ket DHCP szerver, elnezest... nem attol kapta, meg nem olyat... */ es itt mar el is bukott a kerdes.

https://help.ubuntu.com/community/ThinClientHowto

Tips

If you have a separate DHCP that you do not want to install LTSP on you can just redirect the thin-client to boot off a different server.

In your DHCP server's dhcpd.conf:

next-server 192.168.0.3;

where 192.168.0.3 is the address of your LTSP server

Itt egyedul arrol nem nyilatkozik a draga doksi iro, hogy egyszerre 2 DHCP szerver van a halon, akkor
- nem ad-e veletlenul a masik DHCP szerver (jelen esetben Windows-os) az eppen boot-olo felben levo klienseknek cimet
- nem ad-e veletlenul a LTSP DHCP szervere az ugyanazon halon levo Windows-os klienseknek cimet

Valakinel felmerult mar ez a problema?

Az nem megoldás, ha a LTSP gépek MAC-addressét feketelistára teszed a Win DHCP serveren (már ha az tud ilyent)?

Ha nem, akkor csak különj VLAN lehet a megoldás. Tedd a LTSP gépeket VLAN-ba, ami egy gateway-jel kapcsolódik a normál hálóhoz. Persze minden egyéb broadcast is el fog veszni (SMB broadcast pl.) de kompromisszum mindig kell.

A feketelista azert nem jo, mert akkor hogy ad neki megis DHCP-t a Windoz, ha XP-t akarnak boot-olni ugyanazon a masinerian.
Alapvetoen az a baj, hogy sehol nem feltetelezik azt a teljesen trivialis felallast, hogy mar van egy masik, mukodo DHCP szerver a halon, amit _nem_ akarnak kiiktatni es _tokugyanazokat_ a gepeket szolgalja ki.
Azaz windoz + linux_LTSP parallel ugyanazon a halon. Ahogy a user kedve tartja.
Az egyik a default, a masik az alternativa/beetetes/csali/josag
Melyik lehet melyik....? ;)

A kulon VLAN amugy jo otlet, csak ehhez meg uralni kell az egesz halot, vagy legalabis a switch-eket mindenkeppen.

Most kiprobaltam amugy ket konkurens (Win/Lin) DHCP szerverrel a felallast, a tapasztalat a kovetkezo:

- Ha a windozos DHCP szerver is megy, akkor 'megkavarodik a Linux-on az NFS', azaz a TFTP-vel szepen lehuzott nbi kernel az NFS mount-nal elhasal 'need a path' felkialtassal.
Es query-zgeti tovabb a DHCP szervereket es hol egyiktol kap IP-t, hol masiktol.

- Ha lelovom a windoz DHCP szerveret, es ujra neki futok a PXE boot-nak a kliensekkel, akkor jo.

- Ha lelovom a windoz DHCP szerveret, de nem futok ujra neki a boot-nak, akkor sem sikerul az NFS mount.

Egyelore ennyi a tapasztalat.

ja, ezt en is tudom, csak itt sajnos bukik az elmelet, hogy izzy to setup
meglatasom szerint egy egyszerubb letezo mar DHCP vel felszerelt halo eseten (tipikusan iskolak (lasd EDUbuntu celterulet), ahol van 1 VLAN ozt csa) nem konnyu integralni a letezo kornyezetbe

az a default abra, amit prezentalnak, hogy van egy

- occso router az internet fele
- egy ket NIC-es LTSP
- mogotte az egesz LAN

szerintem igencsak idealisztikus es mondjuk egy otthoni halora all csak meg.

Nem feltétlen. egy occsó rúter mehet a szervezeti LAN felé is.

A másik meg, hogy akik rendszeresebben használják, azoknak vagy ráhatásuk van a hálózat egészére, vagy pedig a bevezetés egy megtervezett döntés, azaz a hálózatért felelős tudja, hogy neki ki kell alakítania egy VLAN-t a bootolós gépeknek, ha Win DHCP szervert is akarnak használni, vagy döntenek a Win DHCP szerver lelövéséről és migrálásáról.

Sajnos a netboot tényleg tervezést igényel, akár meglevő rendszerbe illesztik be, akár új rendszerbe. Ez megfellebbezhetetlen.

Na, ezt amugy kiprobaltam.
Windwos-os DHCP szerver, a megadott beallitasokkal kiegeszitve.
Odaig sikerult eljutni, hogy a PXE resz be-boot-ol, de amikor eljut az NFS mount-hoz, akkor valami ilyesmi hibat dob, hogy nfsmount: need path

az elozoekben megadott link-en

http://diet-pc.sourceforge.net/windows/etherboot-w2k.html

a jelolt cuccok nem egeszen egyertelmuek a szamomra:

66 Boot Server Host Name nimbus <<<-- ez itt nem akar egeszen mukodni nekem, bar hozzaadtam a Win DNS szerverhez, de nem pinglik a LTSP szerver az ott megadott neven. (lehet, hogy pont emiatt nem megy az NFS mount?)
128 Etherboot ID e4 45 74 68 00 00 <<<-- ez itt, hogy ez itt mi es miert???

( uid_2783 | 2009. 07. 10., p – 10:02 )

egy kicsit firssítsük a témát, mert én pl 2 napot szívtam.
ubuntu 8.04 szerver
apt-get install ltsp-server ltsp-server-standalone tftpd-hpa
-illetve ami ide tartozik-
dhcpd.conf illetve /etc/ltsp/dhcpd.conf helyesen megírva.
ltsp-build-client
aztán a /tftpboot könyvtárba az /opt/ltsp/i386/boot tartalmát
átmásolva (mindig hiányzott valami...)
aztán próba.
2 nap szopogatás után bootoltam a klienssel, syslogba a dhcp
sorok után látszott, hogy serving pxelinux.0 meg nbi.img,
meg minden egyéb, csak épp loginolni nem tudtam, mert nem
engedett be.
aztán 1-2 órára
kikapcsoltam mindent, mert léptem otthonról.
aztán tegnap este power on.
syslogba tftpd-hpa rinyált, hogy udp port problémái vannak,
netstat-ba nem látszik, ps szerint fut.
aztán elkezdtem megbangítani: remove tftpd-hpa (ltsp-*), majd
install atftpd, de sehogy sem jutottam előbbre:
kliens hiba: tftp file not found
aztán syslogba semmi tftpd-re utaló bejegyzés nincs...
nos, jelen állás szerint miután atftpd eltávolítva, ltsp-* install,
tftpd-hpa install.
a szokásos automatikus konfigurálások után kliens restart, majd
boot a kártyáról, s ismét a tftp hibával rinyál.
syslog még nyomokban sem tartalmaz tftpd-vel kapcsolatos bejegyzést.
/etc/default/tftpd-hpa fileban nem daemonként fut, illetve
"-l -s /tftpboot" paraméter.
hozzáteszem, hogy 2 nap nyűgösködés után elindult a téma, csak
azt nem értem, hogy miután power off/power on és nem nyúltam
a konfigokhoz, miért van port problémája a tftpd-nek.

--
Sony Vaio &

jelenlegi allas (okos felmegoldas):
dhcpd.conf es ltsp/dhcpd.conf fileokban a pxelinux.0 es nbi.img fileok
elol a /tftpboot/ szovegreszt kivagva bootol a kliens.

hanem hiaba trukkozok, nem lehet bejelentkezni a kliensrol.
group*, passwd* es shadow* atmasolva, majd ltsp-update-image ujra,
de semmi valtozas.
azt azert jo lenne tudni, hogy mikor letrehozzuk az ltsp rendszert,
akkor miutan repokbol lehuzkodja a csomagokat, miert is nem kreal
legalabb 1 db felhasznalot....
chroot-al is probalkozam, ertelme nem volt.
azt meg sem emlitem, hogy ha livecd-bol akarsz ltsp-t csinalni,
akkor azzal mennyi rumli van... meg csak gondolkodom rajta,
nemsokara talan kivitelezem, csak ugy probabul...

--
Sony Vaio &

login probléma megoldva:
nálam az sshd nem a 22-es porton figyelt, hanem eltolva másfelé,
így nem nagyon tudott szerencsétlen kliens bejelentkezni...

hanem még némi finomítás a képfelbontáson, meg hangbeüzemelés,
aztán eddig jó is.
remélem visszaolvasva is érthető mindenkinek, aki hasonló
cipőben sántikál.

--
Sony Vaio &