IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 28 December 2013 (all times are UTC)
| 00:13 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 246 seconds) | |
| 01:15 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 01:17 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 01:20 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds) | |
| 01:26 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 01:45 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 02:04 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.) | |
| 02:33 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 272 seconds) | |
| 02:45 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |
| 02:56 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 04:18 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 04:23 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 260 seconds) | |
| 04:49 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 05:20 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 05:24 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 252 seconds) | |
| 05:47 | Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas) | |
| 05:48 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 272 seconds) | |
| 06:20 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 06:21 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 06:25 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 252 seconds) | |
| 06:28 | <alkisg> stgraber: pastebinit doesn't work with debian.net?
| |
| 06:28 | $ echo test | pastebinit -b 'http://paste.debian.net'
| |
| 06:28 | http://paste.debian.net/
| |
| 06:29 | I.e. the returned URL is wrong...
| |
| 06:29 | Same with fpaste.org...
| |
| 06:37 | Phantomas1 has left IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas, Ping timeout: 260 seconds) | |
| 06:41 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 06:46 | * vagrantc waves to alkisg | |
| 06:46 | <alkisg> Hi vagrantc!
| |
| 06:47 | <vagrantc> alkisg: so, i know you said you didn't think it was worth it, but would you consider reviewing my pxelinux changes?
| |
| 06:47 | <alkisg> vagrantc: sure, I will, sorry for being a little absent the last 2 days
| |
| 06:47 | * vagrantc too | |
| 06:47 | <alkisg> To compensate, here's aoe support for ltsp: http://pastie.org/8581907
| |
| 06:47 | :P
| |
| 06:47 | <vagrantc> i suppose i should post them somewhere
| |
| 06:48 | ah, cool. yet another ROOTFS option.
| |
| 06:49 | <alkisg> vagrantc: the coolest thing about it is that it doesn't care about IPs and leases etc
| |
| 06:49 | <vagrantc> alkisg: that's all?
| |
| 06:49 | <alkisg> You can have network manager manage your IPs and still have an ethernet-based root below that...
| |
| 06:50 | <vagrantc> alkisg: does that go in local/top or.. ?
| |
| 06:50 | <alkisg> Yeah, basically a modprobe aoe is all that's needed
| |
| 06:50 | <vagrantc> that sounds pretty awesome.
| |
| 06:50 | <alkisg> local-top should be the best place for it, according to the initramfs-tools manpage
| |
| 06:50 | How should I name it? It's not really ltsp related...
| |
| 06:51 | <vagrantc> alkisg: well, if we're shipping it in ltsp, i'd say name it ltsp-aoe, because it should really go in some aoe support package as a hook for initramfs-tools
| |
| 06:52 | or if it's just kernel, then it should go right into initramfs-tools
| |
| 06:52 | <alkisg> OK, I'll name it aoe_ltsp to match nbd_ltsp
| |
| 06:52 | Ah, yeah, it's just kernel
| |
| 06:52 | <vagrantc> then we should submit it to initramfs-tools
| |
| 06:53 | <alkisg> Will you do the honors?
| |
| 06:53 | Or should I?
| |
| 06:53 | <vagrantc> alkisg: what's the server-side stuff like?
| |
| 06:53 | alkisg: if you've got the time to at least file the inital patch, i can do follow-up. :)
| |
| 06:53 | <alkisg> Nice, thanks, will do
| |
| 06:53 | <vagrantc> alkisg: as it's mostly your work :)
| |
| 06:54 | <alkisg> # apt-get install vblade; vblade -r 0 0 eth0 /opt/ltsp/images/i386.img (or edit /etc/vblade.conf)
| |
| 06:54 | <vagrantc> then i can just test it and say "yup, it works!" and do any tweaking to the patch
| |
| 06:54 | <alkisg> That's all there is for server-side...
| |
| 06:54 | <vagrantc> alkisg: that's pretty cool.
| |
| 06:54 | <alkisg> The cool thing is that our init-bottom script adds the cow part automatically ;)
| |
| 06:54 | <vagrantc> yup
| |
| 06:55 | i was really happy when we figured out to use init-bottom for the cow stuff.
| |
| 06:55 | <alkisg> I'd prefer it if it was in init-ltsp.d, but it's not a big deal
| |
| 06:56 | <vagrantc> is it technically feasible to put in init-ltsp.d ?
| |
| 06:57 | we'd have to manage migrations of all the mountpoints and such, no?
| |
| 06:58 | before we had implemented all the cow stuff in our ltsp_nbd hooks
| |
| 06:58 | <alkisg> We'd probably have to call the pivot_root etc once more, but it should be possible...
| |
| 07:03 | vagrantc: I'll add CMDLINE_AOE in our update-kernels.conf, ok?
| |
| 07:03 | Is ip=dhcp needed?
| |
| 07:04 | * alkisg will test all our latest commits, just give me a couple of days... :) | |
| 07:07 | <vagrantc> is it always hardcoded to root=/dev/etherd/e ?
| |
| 07:08 | alkisg: i'm eagre to test this stuff, but i probably shouldn't keep pulling late-nighters
| |
| 07:08 | <alkisg> I don't see any settings in the aoe module, so I imagine it always puts the devices there, yeah
| |
| 07:08 | /dev/etherd/e1.2
| |
| 07:09 | Where 1 == device major, 2== device minor
| |
| 07:10 | And btw it automatically uses all the interfaces, so you have bonding with it without the need to configure anything...
| |
| 07:11 | * alkisg has better equipment for testing stuff at work, which is a bit far from home, that's why he's postponing the testing and wants to test all of them together at once... | |
| 07:12 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 245 seconds) | |
| 07:14 | <vagrantc> alkisg: my recent pxelinux stuff: http://paste.debian.net/72803/
| |
| 07:14 | <alkisg> I want to update the udhcp script too, it was never meant to be committed upstream that way
| |
| 07:15 | <vagrantc> committed to upstream ltsp?
| |
| 07:15 | <alkisg> Yeah
| |
| 07:15 | <vagrantc> alkisg: i think the menus tend to default to the unversioned kernels now, too.
| |
| 07:15 | <alkisg> It was back when I was still learning bash :)
| |
| 07:15 | <vagrantc> or maybe that was some uncommitted code
| |
| 07:16 | <alkisg> cp -a "$chroot/boot/." "$tftpboot/$name/"
| |
| 07:16 | find "$tftpboot/$name/" -maxdepth 1 ! -perm -o=r -exec chmod +r {} \;
| |
| 07:16 | ...why not cp -r instead?
| |
| 07:16 | <vagrantc> i didn't want to get into unrelated changes
| |
| 07:16 | <alkisg> OK
| |
| 07:16 | <vagrantc> although technically the symlinks and the pxelinux stuff are probably technically different things
| |
| 07:16 | hrm.
| |
| 07:16 | <alkisg> But feel free to push both of them as 2 changes, I'll test everything when I go to work
| |
| 07:22 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
| 07:23 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 07:27 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 260 seconds) | |
| 08:00 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 08:08 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 245 seconds) | |
| 08:23 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 08:24 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 08:29 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds) | |
| 09:04 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 245 seconds) | |
| 09:05 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
| 09:24 | Enslaver has left IRC (Enslaver!~Enslaver@fedora/Enslaver, Read error: Connection reset by peer) | |
| 09:26 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 09:27 | Enslaver has joined IRC (Enslaver!~Enslaver@fedora/Enslaver) | |
| 09:30 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 09:31 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds) | |
| 09:57 | sbalneav has left IRC (sbalneav!~sbalneav@50.71.200.173, Ping timeout: 272 seconds) | |
| 10:00 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 10:11 | sbalneav has joined IRC (sbalneav!~sbalneav@50.71.200.173) | |
| 10:27 | <stgraber> alkisg: "ps aux | pastebinit -b http://paste.debian.net" works fine here
| |
| 10:28 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 10:33 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds) | |
| 10:42 | gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113) | |
| 10:44 | <gdi2k> | |
| 10:56 | ok, got that fixed - must specify arch as part of ltsp-chroot. next question: no audio on fat clients. pulse is installed, but no hardware shows
| |
| 11:46 | anyone? Neither USB or on-board audio devices are showing up in pulse audio - only a "Dummy Device", which doesn't help much. I have SOUND = true for good measure but apparently that doesn't affect fat clients. I have also done the NFS_HOME thing as per https://help.ubuntu.com/community/UbuntuLTSP/FatClients
| |
| 12:10 | gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Quit: Leaving) | |
| 12:20 | gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113) | |
| 12:41 | rkwesk has joined IRC (rkwesk!5e4706c2@gateway/web/freenode/ip.94.71.6.194) | |
| 12:42 | <rkwesk> I thought I had this figured out but I'd like to confirm: Configuration 1 unmanaged switch w 1 giga port and 16 100 ports not connected directly w router Server with two nics, one gigabit to giga port on switch and one 100 bit to router directly. Clients, mixed thin and fat but all with 100 bit nics to same switch to 100 bit ports. Configuration 2 unmanaged switch w 1 giga port and 16 100 ports, one of 100 bit ports connected w ro
| |
| 12:42 | connected w router Server with one nic (giga) to giga port on switch Clients, mixed thin and fat but all with 100 bit nics to same switch to 100 bit ports. In both cases (I think) there should be no overload and so the possible complications with flow control are avoided. Is this correct? Richard
| |
| 13:02 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 13:08 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 13:08 | <rkwesk> hi alki
| |
| 13:09 | <alkisg> Hi Richard
| |
| 13:09 | I just saw your mail to ltsp-discuss, basically on both cases you may have a flow control issue
| |
| 13:09 | It depends on the switch and NIC of the server
| |
| 13:10 | <rkwesk> why is that? where is the overload?
| |
| 13:10 | <alkisg> There's no overload. The flow control issue is this:
| |
| 13:11 | server tries to send some data to a client. server is gigabit, client is 100mbps.
| |
| 13:11 | So server sends data too fast, and the client sends to the server an "ethernet pause"
| |
| 13:11 | Depending on the interpretation of that pause, the flow control issue will exist or not
| |
| 13:12 | If the server pauses sending data to that particular pc, then everything is ok
| |
| 13:12 | <rkwesk> so what u describe sounds like overload to me
| |
| 13:12 | <alkisg> If the server pauses sending data to all PCs, then we have the flow control issue
| |
| 13:12 | The problem isn't the overload, is the pause
| |
| 13:12 | <rkwesk> yes, but pause is invoked by overload, no?
| |
| 13:13 | <alkisg> It's just a mechanism to regulate speed
| |
| 13:13 | It's the same in tcp too
| |
| 13:14 | When someone sends too fast, the other peer says "slow down"
| |
| 13:14 | It's usual traffic, nothing particular there...
| |
| 13:14 | <rkwesk> how can a switch w 100 port send to a 100 nic too fast?
| |
| 13:16 | if switch only had giga ports then, of course data goes too fast
| |
| 13:16 | <alkisg> It cannot
| |
| 13:16 | Only if the client is stressed otherwise...
| |
| 13:17 | The flow control issue only appears when you have BOTH gigabit and 100mbps ports
| |
| 13:17 | <rkwesk> but only when a giga port is connected to 100 nic
| |
| 13:18 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 13:19 | <rkwesk> i guess i don't really understand the nuances
| |
| 13:21 | summing up, a 100 port cannot send to a 100 nic too fast. a pause occurs when data is ent too fast. where is the complication?
| |
| 13:21 | <alkisg> Configuration 1 unmanaged switch w 1 giga port and 16 100 ports not connected directly w router Server with two nics, one gigabit to giga port on switch and one 100 bit to router directly. Clients, mixed thin and fat but all with 100 bit nics to same switch to 100 bit ports.
| |
| 13:21 | Question: can this setup suffer from the flow control issue?
| |
| 13:22 | Answer: yes, depending on the brand
| |
| 13:22 | unmanaged switch w 1 giga port and 16 100 ports, one of 100 bit ports connected w router Server with one nic (giga) to giga port on switch Clients, mixed thin and fat but all with 100 bit nics to same switch to 100 bit ports.
| |
| 13:22 | Same question/answer there too.
| |
| 13:22 | So to sum up, when your server<=>switch connection is gigabit, and your clients <=> switch connection is 100 mbps, then watch out when you're buying your hardware
| |
| 13:23 | <rkwesk> sorry to be dense but i still see no where data being sent too fast
| |
| 13:24 | <alkisg> The switch doesn't have infinite buffers
| |
| 13:24 | So when the buffer is full, it's the switch that notifies the server to stop sending data
| |
| 13:25 | <rkwesk> only within the switch that received data from giga port and needs to send to 100 port suffers
| |
| 13:26 | so it is there that overload occurs, yes?
| |
| 13:27 | <alkisg> Buffer overload?
| |
| 13:27 | I guess so, if you want to call it that way...
| |
| 13:28 | <rkwesk> only this seems to be clear (to me) as overload
| |
| 13:30 | <alkisg> http://en.wikipedia.org/wiki/Buffer_underrun
| |
| 13:30 | <rkwesk> if an all giga switch were in place of above switch then buffer overload is replaced by client's nic suffering overlaod, right?
| |
| 13:33 | so whichever way we go there is agood chance of overload?
| |
| 13:40 | ramcq has joined IRC (ramcq!~robot101@iota.hadesian.co.uk) | |
| 13:42 | <ramcq> hi folks, happy holidays :)
| |
| 13:42 | I've got a couple of Ubuntu Precise machines which have their ~ shared, and I've configured them to run with GNOME classic to avoid upsetting people too much
| |
| 13:43 | I had a question which isn't specifically about LTSP but you guys might know the solution
| |
| 13:43 | <rkwesk> from what i see buffer underrun might occur when client sends to server and buffer overflow when server sends to client in original configs above
| |
| 13:43 | <ramcq> is there a well-known method to set these systems up to log idle users out?
| |
| 13:44 | my least-bad idea so far was to backport the https://mail.gnome.org/archives/commits-list/2012-December/msg03185.html patch to the 3.2 version of gnome-session we're running
| |
| 13:45 | <alkisg> Write a small script (or cron job) that uses xprintidle...
| |
| 13:46 | Or use a special screensaver that logs people out :D
| |
| 13:47 | <rkwesk> rkwesk is signing off
| |
| 13:47 | rkwesk has left IRC (rkwesk!5e4706c2@gateway/web/freenode/ip.94.71.6.194, ) | |
| 13:49 | <ramcq> alkisg: hmm, and guess the display number from awking the output of w or something?
| |
| 13:49 | Fenuks has joined IRC (Fenuks!~Fenuks@176.51.96.60) | |
| 13:56 | <alkisg> ramcq: if you run the script from /etc/xdg/autostart or from xsession, it already has DISPLAY and XAUTHORITY etc
| |
| 13:57 | If you really need to run it from cron, then you need some magic to get access to display/xauthority...
| |
| 13:57 | The first method is easier; the later allows you to power off inactive clients that stayed too long at the LDM prompt
| |
| 13:58 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
| 14:07 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 14:19 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 14:34 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 246 seconds) | |
| 14:56 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Remote host closed the connection) | |
| 15:57 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 15:58 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 16:04 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 272 seconds) | |
| 16:16 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |
| 16:17 | alzjqhiteluy has joined IRC (alzjqhiteluy!iamparadox@c-71-206-130-134.hsd1.va.comcast.net) | |
| 16:17 | |Paradox| has left IRC (|Paradox|!iamparadox@c-71-206-130-134.hsd1.va.comcast.net, Read error: Connection reset by peer) | |
| 16:17 | alzjqhiteluy is now known as |Paradox| | |
| 16:17 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 16:18 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 16:20 | Patina has left IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net, Ping timeout: 240 seconds) | |
| 16:20 | Patina has joined IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net) | |
| 16:50 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 17:05 | Fenuks has left IRC (Fenuks!~Fenuks@176.51.96.60, Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) | |
| 17:08 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 245 seconds) | |
| 17:28 | markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it) | |
| 19:04 | <alkisg> vagrantc, I had to do some changes in the packaging order to be able to build a package: https://code.launchpad.net/~ts.sch.gr/sch-scripts/ltsp-debian-packaging
| |
| 19:06 | *in order..
| |
| 19:40 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
| 19:46 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.) | |
| 20:28 | xet7 has joined IRC (xet7!~xet7@80-186-81-85.elisa-mobile.fi) | |
| 21:25 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 21:34 | jamest_ has joined IRC (jamest_!46b3939b@gateway/web/freenode/ip.70.179.147.155) | |
| 21:35 | jamest_ has left IRC (jamest_!46b3939b@gateway/web/freenode/ip.70.179.147.155) | |
| 22:02 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |
| 22:03 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 22:07 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds) | |
| 22:13 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 22:17 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |
| 22:19 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 260 seconds) | |
| 22:22 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 22:33 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 22:45 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 22:49 | <gdi2k> hi all, smee again. I'm struggling with fat client sound issues. Sound on thin clients works fine. 13.10 Xubuntu. I have SSH_FOLLOW_SYMLINKS = False in my lts.conf and have set everything up as per https://help.ubuntu.com/community/UbuntuLTSP/FatClients - pa volume control only lists a "Dummy Device" in Output devices. The USB headset shows in lsusb on the client, so it is being seen. Any ideas?
| |
| 23:04 | <markit> gdi2k: I've no idea, I use kde, but are you absolutely sure it's a fat client?
| |
| 23:05 | it should see local hardware... does the client really have a sound card?
| |
| 23:05 | and is it supported by the os (i.e. if you boot with a live cd)?
| |
| 23:15 | <gdi2k> markit, yes, definitely a fat client. I can open a terminal and see the local machine's /proc/cpuinfo
| |
| 23:16 | and yes, it definitely has a sound card (USB headset and onboard audio). Both work fine with a LiveCD and even as a thin client
| |
| 23:16 | if I do lsusb the headset is visible
| |
| 23:16 | but pulse doesn't want to see it
| |
| 23:23 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection) | |
| 23:23 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 23:28 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds) | |
| 23:28 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 23:30 | Selveste1 has left IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net, Remote host closed the connection) | |
| 23:31 | <vagrantc> wow. AoE allows for remote devices without even any networking information configured
| |
| 23:32 | Selveste1 has joined IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net) | |
| 23:35 | <markit> vagrantc: is it Ata over Ethernet? What are you doing with it? Seems that everyone goes for iSCSI instead...
| |
| 23:35 | (but I don't want my storage connection being routable, I want it fast and simple)
| |
| 23:42 | <vagrantc> markit: yeah, ata o'er ethernet
| |
| 23:43 | markit: alkisg came up up with the remarkably simple stuff to use AoE for an LTSP rootfs on debian/ubuntu, and i was just testing it
| |
| 23:43 | haven't looked into iscsi
| |
| 23:47 | but AoE was pretty surprisingly simple to set up ...
| |
| 23:48 | will need some tweaks to configure networking, though.
| |
| 23:49 | which was a little suprise
| |
| 23:51 | <gdi2k> I had a go with AoE a while back when I was playing with clustered file systems - worked nice
| |
| 23:51 | (AoE, not the clustered file systems)
| |
| 23:53 | <vagrantc> heh
| |
| 23:53 | issues with writeability?
| |
| 23:53 | since LTSP only needs read-only access, that makes a lot of things simpler.
| |
| 23:54 | <gdi2k> it was more config and reliability - I was playing with gluster at the time, but it was all over the place. ended up with RAID 1 on a single server
| |
| 23:55 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
| 23:56 | <gdi2k> vagrantc, any experience with fat client and sound? been fighting this for too many hours and can't see where I'm going wrong
| |
| 23:57 | <vagrantc> i haven't worked much with fatclients, actually
| |
| 23:57 | and haven't tested sound support very consistantly lately...
| |
| 23:57 | i really need to set up a testing lab or something.
| |
| 23:58 | i've been doing most testing on virtual hardware, and my setup doesn't support testing sound well, if at all.
| |
| 23:59 | <gdi2k> yes, sound on VMs adds another dimension of things to go wrong
| |