00:02 | t0mmii has quit IRC | |
00:08 | t0mmii has joined #ltsp | |
00:13 | alkisg has joined #ltsp | |
00:13 | alkisg has joined #ltsp | |
00:18 | vagrantc has joined #ltsp | |
00:20 | alkisg has quit IRC | |
00:28 | artista_frustrad has quit IRC | |
00:36 | t0mmii has quit IRC | |
00:41 | artista_frustrad has joined #ltsp | |
00:43 | t0mmii has joined #ltsp | |
00:45 | johnny has left #ltsp | |
00:46 | johnny has joined #ltsp | |
00:48 | artista_frustrad has quit IRC | |
01:01 | artista_frustrad has joined #ltsp | |
01:07 | artista_frustrad has quit IRC | |
01:09 | johnny has left #ltsp | |
01:10 | johnny has joined #ltsp | |
01:16 | t0mmii has quit IRC | |
01:16 | t0mmii has joined #ltsp | |
01:22 | johnny has left #ltsp | |
01:26 | johnny has joined #ltsp | |
01:28 | vagrantc has quit IRC | |
01:31 | johnny has left #ltsp | |
01:32 | johnny has joined #ltsp | |
01:43 | gymeleou has joined #ltsp | |
01:51 | johnny has left #ltsp | |
01:52 | gnunux has joined #ltsp | |
01:52 | gymeleou is now known as alkisg_work | |
01:54 | ogra_cmpc has quit IRC | |
01:56 | ogra_cmpc has joined #ltsp | |
01:58 | dobber has joined #ltsp | |
02:02 | vmlintu has quit IRC | |
02:04 | Egyptian[Home] has quit IRC | |
02:06 | Egyptian[Home] has joined #ltsp | |
02:10 | rickogden has joined #ltsp | |
02:14 | pthsWork has quit IRC | |
02:23 | vmlintu has joined #ltsp | |
02:24 | chupacabra has joined #ltsp | |
02:32 | pthsWork has joined #ltsp | |
02:39 | johnny has joined #ltsp | |
02:46 | ogra has joined #ltsp | |
02:53 | Guerdal82 has joined #ltsp | |
03:02 | ogra has quit IRC | |
03:03 | ogra has joined #ltsp | |
03:08 | ogra has quit IRC | |
03:25 | <alkisg_work> Hmm looks like compcache is making the clients slow, it's going much better after removing it and using nbd swapping is its place
| |
03:27 | <dobber> we are happy with nbdswapping for now
| |
03:27 | <alkisg_work> compcache is used by default too, so you have 2 swap spaces.. (if you're using ubuntu, that is)
| |
03:28 | <dobber> we are
| |
03:33 | pthsWork has quit IRC | |
03:38 | pthsWork has joined #ltsp | |
04:06 | Selveste1 has joined #ltsp | |
04:08 | Selveste1 has quit IRC | |
04:08 | Selveste1 has joined #ltsp | |
04:09 | Guerdal82 has quit IRC | |
04:19 | mikkel has joined #ltsp | |
04:38 | alkisg has joined #ltsp | |
04:41 | mikkel has quit IRC | |
04:45 | mikkel has joined #ltsp | |
04:51 | wima1 has joined #ltsp | |
05:16 | <alkisg> !learn reset-panels as to reset gnome panels to their initial state, losing any customizations you may have made: gconftool-2 --recursive-unset /apps/panel && killall gnome-panel
| |
05:16 | <ltspbot> alkisg: The operation succeeded.
| |
05:25 | <alkisg> Does debian have compcache enabled by default?
| |
05:29 | I think compcache is making low-end ltsp terminals very slow (wasting precious memory to make a compressed swap space there). My tests appareantly show that if I disable compcache and _only_ use nbd swapping, the low-end terminals go much faster...
| |
05:29 | * alkisg tests some more... | |
05:39 | <sep> alkisg, not even sure it's available in debian. debian does not have the linux-ubuntu-modules package ?
| |
05:40 | <alkisg> sep: in my ubuntu it shows as part of the initramfs-tools...
| |
05:40 | sudo chroot /opt/ltsp/i386 dpkg -S /usr/share/initramfs-tools/hooks/compcache
| |
05:40 | <sep> even the kernel modules ?
| |
05:40 | <alkisg> initramfs-tools: /usr/share/initramfs-tools/hooks/compcache
| |
05:40 | Ah no let me see the modules...
| |
05:41 | <sep> lsmod shows compcache ?
| |
05:41 | <alkisg> No, ramzswap something... checking...
| |
05:42 | # dpkg -S /lib/modules/2.6.32-22-generic/kernel/ubuntu/compcache/ramzswap.ko
| |
05:42 | linux-image-2.6.32-22-generic: /lib/modules/2.6.32-22-generic/kernel/ubuntu/compcache/ramzswap.ko
| |
05:43 | But ok, it says Ubuntu there, so I suppose it's Ubuntu specific
| |
05:43 | <sep> implemented in ubuntu and have not had time to spread yet i guess
| |
05:44 | <alkisg> sep: could you upload the result of this command to pastebin for me? ls -lha -R /opt/ltsp/i386/usr/share/initramfs-tools/
| |
05:44 | <sep> i have no recent ltsp chroot. only old stuff
| |
05:46 | <alkisg> Ah, ok, thanks anyway
| |
05:53 | <dobber> http://www.eyrie.org/~eagle/faqs/questions.html
| |
05:57 | converted the 8th and final client
| |
05:57 | server load is 0.78 :)
| |
06:06 | F-GT has quit IRC | |
06:23 | F-GT has joined #ltsp | |
06:29 | wwx has quit IRC | |
06:43 | wwx has joined #ltsp | |
06:44 | <dobber> starting a heavy loaded thunderbird for the first time
| |
06:45 | spikes mem usage to the maximum
| |
06:50 | otavio has quit IRC | |
06:50 | F-GT has quit IRC | |
06:55 | otavio has joined #ltsp | |
07:01 | pmatulis has joined #ltsp | |
07:07 | F-GT has joined #ltsp | |
07:08 | rad4Christ has joined #ltsp | |
07:08 | sharles has joined #ltsp | |
07:09 | <sharles> ltsp error: failed to connect to nbd server
| |
07:11 | LTSP installed on Ubuntu 10.04; client can find server, gets to the Gnome splash screen, then drops GUI, with error message "failed to connect to nbd server"
| |
07:11 | <Appiah> common problem
| |
07:12 | did you upgrade?
| |
07:18 | <sharles> updated both the sshkeys and the image, twice to be sure
| |
07:18 | <alkisg> If it fails to connect to the nbd server, then it isn't the gnome screen
| |
07:18 | It's just the (plymouth) splash screen
| |
07:19 | <Appiah> sharles: did you just upgrade to 10.04 ?
| |
07:19 | <sharles> yes, new install
| |
07:19 | <Appiah> ehh
| |
07:19 | "Yes I did upgrade to 10.04"
| |
07:19 | "No, I just installed 10.04"
| |
07:19 | which one
| |
07:20 | <sharles> Appiah: You're right, I need disambiguation. "o, I just installed 10.04
| |
07:20 | <Appiah> so this install has never been up and running?
| |
07:21 | <sharles> Appiah: No, have never been able to logon from thin client to 10.04 Desktop
| |
07:21 | <Appiah> which packages did you install for ltsp?
| |
07:22 | <sharles> Appiah: per instructions I followed: ltsp-server-standalone openssh-server
| |
07:31 | <alkisg> sharles: you should be getting a busybox prompt on the client. In that prompt, type: nbd-client server-ip 2000 /dev/nbd0
| |
07:36 | <sharles> alkisg: tryed that, and received: error connection refused
| |
07:37 | <dobber> check is nbd server is started in your server: `grep nbd /etc/inetd.conf` . also `netstat -antp|grep 2000`
| |
07:37 | s/is/if/
| |
07:41 | <sharles> ps aux | grep nbd shows nbd-server is not running
| |
07:41 | ran dpkg-reconfigure nbd-server, but not sure of the parameters I should enter
| |
07:42 | <alkisg> nbd-server shouldn't be running
| |
07:42 | It starts from inetd
| |
07:42 | dpkg-reconfigure just messes with the normal configuration
| |
07:42 | see what dobber proposed
| |
07:42 | bbl
| |
07:43 | <dobber> sharles check is you have inetd running `ps auxw|grep inetd
| |
07:46 | <sharles> dobber: inetd is not running
| |
07:47 | alkisg has quit IRC | |
07:47 | <dobber> sharles you need to have it running
| |
07:48 | in /etc/inetd.conf among other things, put this at the end
| |
07:48 | http://pastebin.com/TvYkXCbX
| |
07:48 | ./etc/init.d/openbsd-inetd
| |
07:48 | to start inetd do : `/etc/init.d/openbsd-inetd start`
| |
07:51 | also you need to check that /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
| |
07:52 | have a line that reads `append ro initrd=initrd.img quiet splash nbdport=2000`
| |
07:52 | have a line that reads `append ro initrd=initrd.img quiet splash nbdport=2000`
| |
07:54 | <sharles> dobber: ok, thanks. Hate to be a pest, but now, getting "No response from server, restarting" from logon screen.
| |
08:00 | <dobber> sharles i get this error when my user/password does not match
| |
08:02 | sharles on the server do : `ltsp-update-sshkeys`
| |
08:02 | and try again
| |
08:03 | you will need to restart the client
| |
08:04 | <sharles> dobber: yup, updated keys, and image "just to be thorough," and am logged on
| |
08:04 | Thanks!
| |
08:05 | And, is there a good, comprehensive guide to setting up LTSP on Ubuntu 10.04
| |
08:05 | Gadi has joined #ltsp | |
08:05 | <dobber> yes
| |
08:05 | ltsp.org
| |
08:05 | click on documentation
| |
08:05 | !docs
| |
08:05 | <ltspbot> dobber: "docs" :: For the most current documentation, see https://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstream
| |
08:13 | <dobber> https://help.ubuntu.com/community/UbuntuLTSP
| |
08:38 | korcan has joined #ltsp | |
08:41 | sharles has quit IRC | |
08:46 | shawnp0wers has joined #ltsp | |
09:11 | alkisg has joined #ltsp | |
09:14 | sharles has joined #ltsp | |
09:15 | <rad4Christ> My local app, Firefox, looks different in visual style than the rest of my gnome session from the server. The panels, windows, and GUI for all apps running on the server are using the human theme, but Firefox is blocky and dull grey. Any ideas on how to implement the same visual style as the remote part of the session?
| |
09:17 | <alkisg> Install ubufox? (just an idea, not sure...)
| |
09:18 | <LedHed> alkisg, disabling nbd-proxy did the trick. No boot issues since the patch.
| |
09:18 | thanks for the tip
| |
09:18 | <alkisg> LedHed, nice, do mention that in the bug report
| |
09:18 | <LedHed> I will
| |
09:20 | <rad4Christ> alkisg: Checking to see if it is installed now.
| |
09:27 | Selveste1 has quit IRC | |
09:31 | rickogden has quit IRC | |
09:36 | <LedHed> alkisg, in lts.conf where can I find the Time_Zone codes? I looked in the documentation, but there wasn't a list of valid codes to use.
| |
09:38 | <alkisg> LedHed: I think they're in /usr/share/zoneinfo
| |
09:38 | E.g. mine is Europe/Athens
| |
09:38 | <LedHed> alkisg, great thanks
| |
09:41 | ogra_cmpc has quit IRC | |
09:43 | <LedHed> ls
| |
09:43 | oops
| |
09:43 | ogra_cmpc has joined #ltsp | |
09:44 | <LedHed> alkisg, TIMESERVER in lts.conf, can I have more than one IP address (maybe comma seperated list)?
| |
09:45 | <alkisg> No I don't think so
| |
09:46 | <LedHed> ok, one will do. :)
| |
09:52 | jammcq has joined #ltsp | |
09:52 | <jammcq> hey friends
| |
09:52 | for all interested, looks like BTS-2010 will be Oct 28-31 in SW Harbor, Maine
| |
09:57 | dobber has quit IRC | |
09:58 | vongrippen_ has joined #ltsp | |
09:59 | dobber has joined #ltsp | |
10:00 | Selveste1 has joined #ltsp | |
10:02 | vbundi has quit IRC | |
10:07 | dobber has quit IRC | |
10:19 | gnunux has quit IRC | |
10:19 | dobber has joined #ltsp | |
10:27 | staffencasa has joined #ltsp | |
10:31 | vagrantc has joined #ltsp | |
10:34 | dobber has quit IRC | |
10:43 | wima1 has quit IRC | |
10:44 | <alkisg> Hi vagrantc, I've been experimenting with 64MB clients today. It looks that they perform better with compache=off and nbd_swap=on. But they won't even boot this way, they need a swap space before they get to ltsp-init-common. So by increasing min_ram in ltsp_nbd to 64M, they worked fine.
| |
10:44 | I do recall that you had some objections about increasing min_ram there, but I don't remember why... whenever you have some time to talk about it... I'm here :)
| |
10:45 | <vagrantc> alkisg: min_ram is what?
| |
10:45 | <alkisg> 48MB - an arbitrary low end
| |
10:45 | # try to get swap from the server if we dont have enough ram (less than 48M)
| |
10:45 | min_ram=${min_ram:-48}
| |
10:45 | real_ram=$(cat /proc/meminfo |grep MemTotal|tr -d " [a-z][A-Z]:")
| |
10:45 | etc...
| |
10:46 | Erm, it's hardcoded to 48MB, I just changed that for testing.
| |
10:46 | <vagrantc> ah, in ltsp_nbd
| |
10:47 | does it respect ENCRYPTED_SWAP ?
| |
10:47 | <alkisg> No
| |
10:48 | Also it uses /dev/nbd1 hardcoded again
| |
10:48 | <vagrantc> that's my main objection...
| |
10:48 | <alkisg> It's poorly written, sure. But what's the objection on increasing that?
| |
10:48 | <vagrantc> 64 is probably not evil...
| |
10:48 | we start hitting 128 and i'll grumble louder :)
| |
10:49 | shawnp0wers has quit IRC | |
10:49 | <alkisg> Heh - no, 128MB boot fine with no problems
| |
10:49 | I could use a kernel parameter and solve it locally, but others would hit the same problem...
| |
10:49 | alexqwesa has quit IRC | |
10:49 | <alkisg> So I'd prefer to increase 48M to 64M so that no kernel parameter would be needed
| |
10:49 | * vagrantc wonders if debian has the same or similar arbitrary limits | |
10:50 | <vagrantc> i haven't actually been testing with that little memory lately
| |
10:50 | <alkisg> Is compcache available on debian?
| |
10:50 | <vagrantc> almost
| |
10:50 | <alkisg> But you don't use it by default, do you?
| |
10:50 | <vagrantc> the kernel module is available in squeeze/testing, but the tools are still stuck in NEW :(
| |
10:50 | <alkisg> It made my low-end clients super slow because of constant compression
| |
10:50 | <vagrantc> and it doesn't seem to work without the tools to initialize it
| |
10:51 | <alkisg> After some hours of examination, I'd suggest that we shouldn't use it at all in ltsp
| |
10:51 | alexqwesa has joined #ltsp | |
10:51 | <alkisg> I think it's only useful for live CDs, where no swap space is available
| |
10:51 | For ltsp, nbd swapping makes much more sense
| |
10:51 | As it doesn't occupy 25% of RAM just to offer a swap space...
| |
10:51 | <vagrantc> sure
| |
10:52 | <alkisg> (whenever that's available, of course)
| |
10:52 | <vagrantc> though i think there are some thin clients where it does make sense...
| |
10:52 | * vagrantc doesn't really like nbd swap | |
10:52 | <alkisg> Are you using some swapping method in debian?
| |
10:53 | <vagrantc> the first few times i used it, nbd-client got swapped out... which is disasterous
| |
10:53 | alkisg: not by default
| |
10:53 | <alkisg> Ouch
| |
10:53 | <vagrantc> this was in 2006... i presume it works better now
| |
10:54 | <alkisg> After disabling compcache and enabling a 64MB (=the default) nbd swap for each client, my 64MB RAM clients were working just fine
| |
10:54 | <vagrantc> what sort of processor?
| |
10:54 | <alkisg> I've tested all morning, except for some unrelated booting problems increasing min_ram to 64M and passing nocompcache as a kernel parameter to disable compcache looks like the best way to use such low end clients
| |
10:54 | 500MHz celerons
| |
10:55 | 10 year old pcs...
| |
10:55 | <vagrantc> the machines at freegeek range from 400MHz-1GHz machines, with 256-512M of ram...
| |
10:55 | <alkisg> Even for localapps or fat clients, I'd still would prefer nbd swapping to compcache
| |
10:56 | <vagrantc> the 400MHz ones definitely seem a little sliggish
| |
10:56 | <alkisg> When the RAM gets excausted, the user tries to e.g. scroll firefox and experiences weird delays
| |
10:57 | <vagrantc> i wonder what implementation of compcache you're using ... ubuntu started using compcache long before it was in-kernel
| |
10:57 | <alkisg> The module is called ramzswap
| |
10:57 | <vagrantc> right
| |
10:57 | i wonder if the module in ubuntu is reasonably current
| |
10:58 | <alkisg> I think that "wasting" 25% ram to gain some swap space is only justified if one doesn't have any other means of swapping
| |
10:58 | So I wouldn't use a compcache module (when I have nbd swap) no matter the implementation...
| |
10:59 | <vagrantc> the percentage is adjustable
| |
10:59 | <alkisg> (that 25% btw is very well chosen, modifying it ...
| |
10:59 | ...either makes the client not boot, or it makes it extra slow)
| |
10:59 | <vagrantc> but you've used it more than i have
| |
11:00 | anyways... gotta reboot...
| |
11:00 | <alkisg> OK so I'll commit a min_ram=${min_ram:-64M} change there
| |
11:00 | vagrantc has quit IRC | |
11:04 | vagrantc has joined #ltsp | |
11:04 | <alkisg> OK so I'll commit a min_ram=${min_ram:-64M} change there. Thanks!
| |
11:38 | guaka has joined #ltsp | |
11:38 | <guaka> hi, anyone managed to use a scanner connected to a thin client on ltsp5?
| |
11:41 | secayford has joined #ltsp | |
11:44 | otavio has quit IRC | |
12:04 | nesusvet has joined #ltsp | |
12:07 | <nesusvet> hello, guys. I am from russian and speak not very well in english. Sorry. Anyway. I want to change my login shell, i mean SCREEN_07. I want to see string like "login:" and "passwd" like on tty1
| |
12:08 | Could you help me
| |
12:08 | ?
| |
12:09 | I have myself will write a script? Or is there an easier way?
| |
12:10 | <vagrantc> nesusvet: you just want to log in to the thin client? or a connection to the server?
| |
12:10 | <nesusvet> thin client
| |
12:10 | without GUI
| |
12:10 | <vagrantc> you can specify SCREEN_07=shell
| |
12:10 | but that will not propmt for username or password
| |
12:10 | just gives a root shell
| |
12:11 | <nesusvet> YEs, but i get root sheel
| |
12:11 | it's not good idea for me
| |
12:11 | <vagrantc> normally, root is the only user on a thin client
| |
12:11 | <nesusvet> i know
| |
12:11 | <vagrantc> ok
| |
12:11 | it's a common confusion as to what happens on the thin client vs. server
| |
12:11 | <nesusvet> I know about it
| |
12:12 | I know what i do )
| |
12:12 | I know what i amd doing )
| |
12:12 | <vagrantc> nesusvet: does logging in at tty1 work for what you want?
| |
12:12 | you just want another on tty7?
| |
12:12 | <nesusvet> yes
| |
12:12 | <vagrantc> or a way to disable SCREEN_07 ?
| |
12:12 | <nesusvet> if i may
| |
12:12 | guaka has quit IRC | |
12:13 | <vagrantc> nesusvet: what distro?
| |
12:13 | <nesusvet> ubuntu
| |
12:13 | 10.04
| |
12:13 | <vagrantc> this is a use-case i don't think we've well considered
| |
12:14 | <nesusvet> hmm
| |
12:14 | <vagrantc> it autodetects which screen session to run
| |
12:14 | <nesusvet> ((
| |
12:14 | <vagrantc> you could specify a custom screen session that just sleeps forever
| |
12:15 | <nesusvet> how can i do that?
| |
12:15 | * vagrantc thinks it over | |
12:16 | <vagrantc> ok...
| |
12:16 | SCREEN_DEFAULT=01
| |
12:16 | that should make the default screen be 01
| |
12:16 | er, tty1
| |
12:17 | <nesusvet> thanks
| |
12:17 | <vagrantc> and shouldn't start ldm on tty7 unless you switch to tt7
| |
12:17 | tty7
| |
12:17 | <nesusvet> and how i can disable tty7?
| |
12:17 | <vagrantc> that's a little trickier....
| |
12:19 | could drop a screen script in /opt/ltsp/i386/usr/share/ltsp/screen.d/sleep that contains: while : ; do sleep $((60*60*24)) ; done
| |
12:20 | and then specify SCREEN_07=sleep
| |
12:20 | there might be a simpler way...
| |
12:21 | if you really don't need graphical stuff, uninstalling the xserver-xorg ought to do it as well
| |
12:21 | <nesusvet> thanks
| |
12:21 | relly
| |
12:21 | ok
| |
12:21 | thanks
| |
12:21 | <vagrantc> it'll remove the ltsp-client package, but ltsp-client-core should still be present
| |
12:22 | <nesusvet> ok
| |
12:22 | good
| |
12:22 | <vagrantc> HAH! a use-case for ltsp-client-core!
| |
12:22 | * vagrantc pushed for the existance of ltsp-client-core some years ago | |
12:23 | <vagrantc> alkisg: hmmmm... regarding the ENCRYPT_SWAP with the swap from NBD ...
| |
12:24 | alkisg: maybe if ENCRYPT_SWAP=True is specified, it should simply fail?
| |
12:24 | <nesusvet> And now another question. I deployed the server through pxe i mean live servers ))))). Is it a good idea to use ltsp in this case?
| |
12:24 | <vagrantc> nesusvet: don't quite understand?
| |
12:24 | <nesusvet> ok
| |
12:24 | how to say )))
| |
12:24 | I have a server
| |
12:25 | and some server stuff in a NFS folder
| |
12:25 | this stuff is servers stuff ).. Sorry
| |
12:26 | <vagrantc> files on the server you want available on the thin-client?
| |
12:26 | <nesusvet> No, i know how do it
| |
12:26 | I want to explain. Wait a minute
| |
12:27 | I deployed servers through servers )
| |
12:27 | via PXE
| |
12:28 | Is it a good idea to use ltsp in this case?
| |
12:28 | I'm just wondering your opinion
| |
12:28 | I deployed servers through ltsp servers )
| |
12:28 | <vagrantc> so the servers are ltsp clients?
| |
12:29 | <nesusvet> yes
| |
12:29 | <vagrantc> i think it's a great idea :)
| |
12:29 | <nesusvet> cool
| |
12:29 | <vagrantc> it's exactly the use-case i made ltsp-client-core for
| |
12:29 | guaka has joined #ltsp | |
12:30 | otavio has joined #ltsp | |
12:30 | <vagrantc> nesusvet: i mean, there may be limitations or problems, depending on what exact sort of server it is...
| |
12:31 | in my crazy dreams i envisioned ltsp servers that were themselves ltsp clients
| |
12:31 | <nesusvet> It does not matter. I guess I'll deal with this
| |
12:31 | )
| |
12:31 | vagrantc, so is it your project?
| |
12:32 | <vagrantc> nesusvet: i'm one of the ltsp developers, if that's what you mean. i mainly work on the ltsp implementation for debian.
| |
12:33 | <nesusvet> ohh, great... vagrantc you should make option disable graphics )
| |
12:33 | <vagrantc> shouldn't be too difficult... may already be there.
| |
12:34 | it's just pretty uncommon
| |
12:34 | could just make a screen type that's a no-op.
| |
12:34 | <nesusvet> ok
| |
12:35 | <vagrantc> the while loop would be a workaround for that, though
| |
12:36 | nesusvet: what sort of servers are you planning on running?
| |
12:36 | <nesusvet> It a game server
| |
12:36 | It's game servers
| |
12:36 | <alkisg> vagrantc: we don't have access to lts.conf variables at that point. Sure, we could do some rewrites there, but is it worth it?
| |
12:37 | <nesusvet> sorry, i can't say. This is the secret of the company
| |
12:37 | <vagrantc> nesusvet: ah, just curious
| |
12:37 | alkisg: ah well.
| |
12:38 | <nesusvet> I want to say, but i can't... (((, Really sorry
| |
12:38 | <vagrantc> alkisg: any ideas how to implement a no-op for screen scripts, other than writing a screen script that does nothing?
| |
12:39 | looking at the code, it looks a little more difficult that i'd have hoped.
| |
12:39 | <alkisg> vagrantc: I didn't understand, what is nesusvet trying to accomplish?
| |
12:39 | I.e. how is he going to use the clients?
| |
12:39 | <vagrantc> alkisg: basically wants them to not have a default for SCREEN_07
| |
12:40 | <alkisg> If he specifies another screen, then they won't
| |
12:40 | <vagrantc> but doesn't really need anything running on SCREEN_07
| |
12:40 | <alkisg> But how is he going to use them? Login locally on vt1?
| |
12:40 | If he specifies e.g. SCREEN_02=shell, he won't get a SCREEN_07 at all
| |
12:40 | <vagrantc> alkisg: they'll be some sort of server
| |
12:40 | alkisg: no login needed
| |
12:40 | <nesusvet> I tried to do something like, /bin/login, but this thing is updated every 60 seconds
| |
12:41 | <alkisg> So he's going to ssh to them?
| |
12:41 | OK.... thinking..
| |
12:41 | <vagrantc> nesusvet: do you actually need a login at all? or do the services just run?
| |
12:42 | <nesusvet> ???? i want login ask or nothing in the Screen_07
| |
12:42 | sleep is good idea
| |
12:42 | <alkisg> Here's one quick script:
| |
12:42 | while true; do read x; done
| |
12:42 | <vagrantc> since it already runs a login on tty1
| |
12:43 | ah, that's even simpler
| |
12:43 | <alkisg> This doesn't call sleep so it's lighter than calling sleep
| |
12:43 | <vagrantc> still calls a shell
| |
12:43 | but that's not too bad
| |
12:43 | <alkisg> Otherwise the initscripts would need to be hacked, to not call openvt at all
| |
12:44 | <nesusvet> i have openssh-server on thin client
| |
12:45 | <vagrantc> as a workaround, you could specify SCREEN_DEFAULT=01 and SCREEN_07=telnet
| |
12:45 | the telnet screen script will just wait for input
| |
12:45 | and SCREEN_DEFAULT=01 will put you in the login on tty1
| |
12:45 | <alkisg> Heh, with the current code, I think setting SCREEN_DEFAULT=13 would do it :)
| |
12:46 | <nesusvet> may be woud be better do it throw ssh?
| |
12:46 | )
| |
12:46 | <alkisg> Ah, or SCREEN_DEFAULT=01... that should also work (i.e. not show anything on vt7)
| |
12:46 | <nesusvet> screen_07=ssh
| |
12:46 | <vagrantc> nesusvet: that'd work too
| |
12:46 | i think
| |
12:46 | <nesusvet> hmm
| |
12:46 | ok will try
| |
12:46 | I am just at home
| |
12:46 | Thanks guys
| |
12:47 | <vagrantc> nesusvet: you need both SCREEN_DEAFULT=01 and SCREEN_07=something
| |
12:48 | both the telenet and ssh screen scripts do nothing really
| |
12:48 | <nesusvet> and one can leave
| |
12:48 | and one variant can leave
| |
12:49 | If I will see one 1 tty it will be ok
| |
12:49 | i think
| |
12:49 | <vagrantc> ah, the "menu" script might also work
| |
12:49 | <nesusvet> how?
| |
12:50 | ok will try
| |
12:50 | <vagrantc> SCREEN_07=menu
| |
12:50 | <nesusvet> hmm not bad
| |
12:50 | <vagrantc> it just displays a menu for you
| |
12:50 | which you can configure to say whatever you want.
| |
12:50 | <nesusvet> it is not a bad idea
| |
12:52 | johnny has left #ltsp | |
12:53 | <alkisg> Setting SCREEN_DEFAULT=01 and SCREEN_01=nothing worked for me.
| |
12:53 | johnny has joined #ltsp | |
12:54 | <nesusvet> ((
| |
12:54 | )))
| |
12:55 | alkisg,i am confused. I can't translate. is it good or bad?
| |
12:56 | <alkisg> nesusvet: you want to disable SCREEN_07 completely, right?
| |
12:56 | <nesusvet> If i can
| |
12:56 | <alkisg> You can. Let me try again and I'll tell you...
| |
12:56 | <nesusvet> thanks
| |
12:56 | Selveste1 has quit IRC | |
12:57 | Selveste1 has joined #ltsp | |
13:00 | <alkisg> OK this works:
| |
13:00 | [Default]
| |
13:00 | SCREEN_01=nothing
| |
13:00 | SCREEN_DEFAULT=01
| |
13:01 | ...but I don't understand why I need to specify SCREEN_01... anyway, it does work.
| |
13:02 | Ah, because of ltsp_config. OK.
| |
13:04 | <nesusvet> GREAT
| |
13:04 | cool
| |
13:05 | Thanks a lot
| |
13:07 | nesusvet has quit IRC | |
13:10 | guaka has quit IRC | |
13:12 | vongrippen_ has quit IRC | |
13:13 | <vagrantc> alkisg: so specifying a non-existant script just ends up doing nothing
| |
13:14 | <alkisg> I'm not quite sure if that's true for any screen, or just 01...
| |
13:14 | <vagrantc> we used to special-case 01
| |
13:14 | but i think we stopped at some point not so long ago
| |
13:15 | * alkisg tries the same with 02... | |
13:17 | <alkisg> Yup, it works with any screen
| |
13:17 | Btw, vagrantc, could you check if your bash supports tcp?
| |
13:17 | E.g. /bin/bash 0<>/dev/tcp/server/1234
| |
13:17 | <vagrantc> i would thin start-stop-daemon would error out or soemthing when it tries to call screen_session
| |
13:17 | alkisg: it used to something like 8 years ago... don't see why it wouldn't now
| |
13:18 | <alkisg> I think they dropped that from debian for security reasons
| |
13:19 | <vagrantc> still in the man page
| |
13:20 | <alkisg> nc -l 1234
| |
13:20 | bash 0<>/dev/tcp/localhost/1234
| |
13:20 | ...a test should be faster and more accurate...
| |
13:21 | <vagrantc> faster than nc?
| |
13:21 | <alkisg> No I mean faster than looking in the manpages if it is supported
| |
13:21 | <vagrantc> nc's hugely smaller than bash's binary ... hard to imagine spawning it would be any faster
| |
13:21 | <alkisg> nc can't offer a shell
| |
13:21 | bash can...
| |
13:21 | <vagrantc> sure
| |
13:22 | vongrippen has joined #ltsp | |
13:22 | <alkisg> ...but erm I was just asking if it's supported, because I read that it isn't. Thanks!
| |
13:22 | <vagrantc> doesn't seem to work
| |
13:22 | <alkisg> Right, that's what I read
| |
13:23 | <vagrantc> doh.
| |
13:23 | from the manpage: NOTE: Bash, as packaged for Debian, does not support using the /dev/tcp and /dev/udp files.
| |
13:23 | <alkisg> I wonder _why_ is that considered a security hole...
| |
13:24 | It's very handy for getting remote shells
| |
13:24 | <vagrantc> i think you just answered your own question
| |
13:24 | <alkisg> You can still do that with nc on debian
| |
13:24 | So... no, I still don't get it
| |
13:27 | Btw, I'm running bash <>/dev/tcp, and then exec'ing /bin/sh to get a shell - so that's the absolute minimum RAM needed to get a reverse shell... while nc would add itself to that.
| |
13:28 | OK anyway thanks, on to min_ram :)
| |
13:30 | <vagrantc> weird. it appears that bash in debian disabled /dev/tcp redirections in june of 2000 ... but i was experimenting with it in 2001...
| |
13:30 | maybe i was using stable and it ... took a while
| |
14:20 | leio has quit IRC | |
14:22 | rad4Christ has quit IRC | |
14:24 | leio has joined #ltsp | |
14:52 | pmatulis has quit IRC | |
15:05 | vvinet has quit IRC | |
15:06 | denisesball has joined #ltsp | |
15:07 | <denisesball> hey all, have a weird issue. if a terminal is at the login screen for too like (like overnight) if you try to login into it, it fails until you restart the whole terminal
| |
15:15 | <Gadi> denisesball: if you have shell access on such a machine, try dropping to a shell next time and do an ls of something on the filesystem
| |
15:15 | sounds to me like your nbd connection has been severed
| |
15:15 | and the client has no accessible rootfs
| |
15:17 | <denisesball> seems to happen every night to my techs
| |
15:18 | its fine if you login/logout right away
| |
15:18 | but it the login screen is left for a long time, like hours/overnight, it says "server connection lost" or something similar and the whole client has to be rebooted
| |
15:20 | <vagrantc> denisesball: do you have a cron job that runs ltsp-update-image?
| |
15:21 | <denisesball> vagrantc: no, also anytime ive ran that it tells me that theres a new image and reboots itself
| |
15:21 | <vagrantc> ah, so this is different
| |
15:21 | <Gadi> denisesball: some switches will not allow prolonger connections
| |
15:21 | *prolonged
| |
15:22 | in other words, if the connection has been open for too long, it will close it
| |
15:22 | nbd-proxy is supposed to magically reconnect
| |
15:22 | tho, I am not sure how well it works
| |
15:22 | <vagrantc> been hearing a lot of bug reports about how badly it works...
| |
15:23 | <Gadi> but, in any event, if you get input/output errors when reading from the filesystem, then you will know
| |
15:23 | <denisesball> yeah we dont have this issue with our older ltsp servers though
| |
15:23 | though i think those use nfs instead of nbd
| |
15:23 | just asked the noc guy and he said nothing they do would be affecting it
| |
15:24 | <Gadi> well, you cannot troubleshoot until you get a machine to the bad state
| |
15:24 | but, try to have shell access on such a machine setup for when the time comes
| |
15:25 | <denisesball> Gadi: do you mean like go to ctrl-alt-f1 on the actual terminal that cannot connect?
| |
15:25 | and try to login to shell?
| |
15:25 | <Gadi> right, or set up shell on one screen
| |
15:25 | probably setting up shell on one screen is better
| |
15:26 | as you will certainly be at a shell
| |
15:26 | <denisesball> ok, cuz i think i did try that and obviously i couldnt login because the server couldnt be connected...
| |
15:26 | <Gadi> well, the login is local
| |
15:26 | <denisesball> so i dont understand if the issue is only happening when they logout, how can i login when it cant connect to the server?
| |
15:27 | <Gadi> a shell on the client is a shell on the client
| |
15:27 | <denisesball> what does it mean that i couldnt login to it then? cuz i did try that i believe
| |
15:27 | <Gadi> not on the server
| |
15:27 | <denisesball> just kept getting "login incorrect"
| |
15:27 | <Gadi> if you have a shell when the server rootfs goes away, you can still look at the tmpfs filesystem and issue shell commands
| |
15:27 | such as ls
| |
15:28 | <denisesball> ok, maybe im missing something. i get the machine to this state, i hit ctrl-alt-f1 and try to login, correct?
| |
15:28 | <Gadi> if you try to ls any file on the rootfs, however, and get an i/o error, then you know that the nbd connection is the root cause
| |
15:28 | no
| |
15:28 | I am saying: set up SCREEN_02=shell SCREEN_07=ldm
| |
15:28 | so a shell prompt is always there
| |
15:29 | shell runs in memory
| |
15:29 | so, if your nbd connection dies, it doesnt matter
| |
15:29 | <denisesball> where do i do that? in the lts.conf? sorry i dont think ive done this before
| |
15:29 | <Gadi> yeah, in lts.conf
| |
15:29 | (and those are two seperate lines)
| |
15:30 | <denisesball> ok, just in the default stanza?
| |
15:30 | <Gadi> default would affect all machines
| |
15:30 | <denisesball> thats fine, i just have 1 test user on there for now
| |
15:30 | <Gadi> if you want to just affect one, make a [mac-address] stanza
| |
15:30 | <denisesball> thats ok
| |
15:30 | <Gadi> ah, ok
| |
15:30 | <denisesball> but will he still see the regular login screen?
| |
15:30 | <Gadi> yup
| |
15:31 | <denisesball> but i can go to ctrl-alt-f2 and get a cli shell?
| |
15:31 | <Gadi> he will be running ldm on ctrl-alt-f7
| |
15:31 | right
| |
15:31 | and his is default
| |
15:31 | <denisesball> which will not have a login prompt on it?
| |
15:31 | <Gadi> correct
| |
15:31 | <denisesball> interesting
| |
15:32 | <Gadi> anyhow, I would guess one of two different things:
| |
15:32 | 1. nbd connection is failing
| |
15:33 | 2. dhcp is handing out the IP address to another client and kicking the client offline
| |
15:33 | (or some other IP mishap)
| |
15:34 | #1 may be caused by #2 or by something else
| |
15:37 | <denisesball> oh, good idea with #2
| |
15:38 | let me look at my dhcpd.conf, cuz its not as clean as it should be
| |
15:38 | terms get moved around, MACs move
| |
15:42 | damn, nope that wasnt it
| |
15:42 | <vagrantc> with the new code, a shell wouldn't actually start in memory unless you switched to it, though
| |
15:43 | though you would likely see filesystem errors when it fails to spawn the shell
| |
15:43 | so it's as good a test as any
| |
15:43 | <denisesball> http://pastebin.com/f4mf1t25
| |
15:44 | thats that term's dhcp stanza, none os this lines are duplicate
| |
15:45 | Gadi: what reasons would the nbd connection fail?
| |
15:46 | this is the second server i put there that has had that issue
| |
15:46 | <vagrantc> same switch(es)?
| |
15:47 | <denisesball> yeah i had built a 64-bit server that had the same issue but replaced it with a 32-bit only on the same port to resolv another issue
| |
15:48 | Jun 10 16:42:18 termserver2 nbd_server[18769]: connect from 10.170.5.200, assigned file is /opt/ltsp/images/i386.img
| |
15:48 | Jun 10 16:42:18 termserver2 nbd_server[18769]: Size of exported file/device is 492478464
| |
15:48 | Jun 10 16:42:18 termserver2 nbd_server[18769]: Disconnect request received.
| |
15:48 | that looks like it could be it
| |
15:55 | <Gadi> denisesball: you are sure that IP is not statically set elsewhere, right? or in some other dhcp raange?
| |
15:55 | *range
| |
15:56 | <denisesball> $ sudo cat /etc/dhcp3/dhcpd.conf | grep 10.170.5.200
| |
15:56 | fixed-address 10.170.5.200;
| |
15:56 | i dont see how it could be
| |
15:56 | i can change it for the hell of it
| |
15:56 | <Gadi> and there is no other dhcp server?
| |
15:56 | (on that segment)
| |
15:56 | <denisesball> nope
| |
15:56 | <Gadi> ok, check /var/lib/dhcpd.leases
| |
15:56 | <denisesball> is that what the line would look like when the tech logged out?
| |
15:57 | <Gadi> I dont think so
| |
15:57 | note the timestamp
| |
15:57 | <denisesball> thats probably the time he logged out yesterday
| |
15:57 | <Gadi> it is at the same time that nbd-server serves it up
| |
15:57 | <denisesball> oh right
| |
15:57 | well he does leave at 4:30
| |
15:58 | <Gadi> the connect and disconnect happen at the same time
| |
15:58 | <denisesball> ok
| |
15:58 | i got nothing in my leases file
| |
15:58 | <Gadi> I seem to recall stgraber disconnecting nbd and reconnecting it in the rootfs
| |
15:58 | wish he were around
| |
15:58 | are you using 10.04?
| |
15:58 | <denisesball> 10.10.
| |
15:58 | 10.10*
| |
15:59 | <Gadi> already?
| |
15:59 | <denisesball> shit sorry
| |
15:59 | 10.04
| |
15:59 | my bad
| |
15:59 | <Gadi> ah, ok
| |
15:59 | <denisesball> i was reading the something on meerkat earlier
| |
16:00 | <Gadi> well, 10.04 has a few differences from older versions that don't all seem to work as well :)
| |
16:00 | eg:
| |
16:00 | 1. udhcpc as a dhcp client by default instead of ipconfig
| |
16:00 | 2. nbd-proxy
| |
16:00 | 3. uncompressed squashfs images
| |
16:01 | <alkisg> 1. was there in 9.10 as well
| |
16:01 | <Gadi> all of these were meant to provide improved stability, but I am hearing more issues of instability than anything
| |
16:01 | <alkisg> But yeah, it still has problems
| |
16:02 | <denisesball> just fyi, the im not using the 10.04 server for dhcp
| |
16:02 | oh u said dhcp client, my bad
| |
16:02 | shouldnt matter then
| |
16:02 | <Gadi> well, with ipconfig, the IP was never refreshed - with udhcpc it is, so that could explain the freeze
| |
16:02 | <alkisg> Urm. What server are you using?
| |
16:02 | <Gadi> (if it gets a different IP)
| |
16:02 | <alkisg> A widows server?
| |
16:02 | <denisesball> no a separate debian server
| |
16:02 | <alkisg> Is it dhcp3-server?
| |
16:02 | <denisesball> an old etch server
| |
16:02 | alkisg: yeah
| |
16:03 | <alkisg> It should probably work then - udhcp has a serious problem with ip leases
| |
16:03 | All the clients send the same identifier, so proper dhcp servers think they're all the same client
| |
16:04 | <denisesball> i'll try changing the IP assigned to this term just for the hell of it
| |
16:04 | <alkisg> When the problem happens, shut off that terminal and then try to ping the ip
| |
16:04 | If you can ping it, someone else took it
| |
16:05 | <denisesball> right
| |
16:05 | <Gadi> denisesball: you can revert back to using ipconfig and see if that helps (but I would make one change at a time, so you know what the prob is)
| |
16:05 | <denisesball> yeah, ill go with the changed IP for now
| |
16:06 | alkisg and anyone else, do you remember me trying to figure out why the hell my new termserver with gnome was so slow compared to our old debiand 4 kde termservers?
| |
16:06 | i figured out why
| |
16:06 | <alkisg> LDM_DIRECTX?
| |
16:07 | <denisesball> nope, it actually has nothing to do with the server which is why it was so hard to troubleshoot
| |
16:07 | we acquired another company a few years ago and had a stack of their old Dell optiplexes, which was good because we're using old dell optiplexes for our current terminals
| |
16:08 | <vagrantc> sabotage!
| |
16:08 | <denisesball> so when i was testing the new server i naturally grabbed one of those, but the performance like i said was awful
| |
16:08 | the terminals had the same speed proc, 500-550MHz, same amount of RAM - 128mb
| |
16:09 | so finally i thought i would try one of our terminals with the new server, and voila! it behaved perfectly
| |
16:09 | the difference:
| |
16:09 | our terminals: pentium IIIs with 512kb cache
| |
16:09 | the ones we acquired: CELERONs! with 128k cache
| |
16:09 | <vagrantc> seriously?
| |
16:10 | <denisesball> this was the complete difference between flash video playing smoothly or horribly, lightbox/javascript taking 5 times as long to load
| |
16:10 | i couldnt believe it
| |
16:10 | and i never thought to look because someone had already printed the specs on the outside and they were the same
| |
16:10 | but it was that big of a difference
| |
16:11 | i coudlnt believe it
| |
16:11 | bobby_C has joined #ltsp | |
16:15 | <denisesball> anyways, thought i would let u guys know. thanks for the help as always!
| |
16:18 | denisesball has left #ltsp | |
16:18 | <alkisg> Well my terminals behave the same, from 300Mhz/128 RAM to 800MHz/256 RAM... No noticable difference.
| |
16:19 | chupacabra has quit IRC | |
16:21 | chupacabra has joined #ltsp | |
16:25 | <jammcq> chupacabra: ???
| |
16:28 | highvoltage has quit IRC | |
16:29 | jammcq has quit IRC | |
16:34 | <chupacabra> hiya jim
| |
16:42 | ogra_cmpc has quit IRC | |
16:44 | ogra_cmpc has joined #ltsp | |
16:52 | Gadi has left #ltsp | |
16:57 | vongrippen has quit IRC | |
17:17 | bobby_C has quit IRC | |
17:44 | secayford has quit IRC | |
17:54 | johnny has left #ltsp | |
17:55 | LedHed has quit IRC | |
17:56 | pmatulis has joined #ltsp | |
18:03 | alkisg has quit IRC | |
18:39 | staffencasa has quit IRC | |
18:46 | gentgeen__ has quit IRC | |
19:12 | mikkel has quit IRC | |
19:17 | johnny has joined #ltsp | |
20:06 | Egyptian[Home]1 has joined #ltsp | |
20:09 | Egyptian[Home] has quit IRC | |
20:22 | pmatulis has quit IRC | |
20:30 | peter_tm has joined #ltsp | |
20:31 | try2free has joined #ltsp | |
20:37 | ogra_cmpc has quit IRC | |
20:39 | ogra_cmpc has joined #ltsp | |
20:40 | howie_ has joined #ltsp | |
20:43 | howie_ has quit IRC | |
21:22 | peter_tm has left #ltsp | |
21:30 | jammcq has joined #ltsp | |
21:30 | <jammcq> hello friends
| |
21:33 | try2free has left #ltsp | |
21:33 | ball has joined #ltsp | |
21:48 | johnny has left #ltsp | |
21:52 | ogra_cmpc has quit IRC | |
21:54 | ogra_cmpc has joined #ltsp | |
22:16 | ogra_cmpc has quit IRC | |
22:22 | sharles has quit IRC | |
22:24 | johnny has joined #ltsp | |
22:25 | bix0r has quit IRC | |
22:25 | sch-bot has quit IRC | |
22:28 | ogra_cmpc has joined #ltsp | |
22:33 | bix0r has joined #ltsp | |
22:33 | sch-bot has joined #ltsp | |
22:59 | ogra_cmpc has quit IRC | |
23:01 | ogra_cmpc has joined #ltsp | |
23:02 | ball has quit IRC | |