IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 11 June 2010   (all times are UTC)

00:02t0mmii has quit IRC
00:08t0mmii has joined #ltsp
00:13alkisg has joined #ltsp
00:13alkisg has joined #ltsp
00:18vagrantc has joined #ltsp
00:20alkisg has quit IRC
00:28artista_frustrad has quit IRC
00:36t0mmii has quit IRC
00:41artista_frustrad has joined #ltsp
00:43t0mmii has joined #ltsp
00:45johnny has left #ltsp
00:46johnny has joined #ltsp
00:48artista_frustrad has quit IRC
01:01artista_frustrad has joined #ltsp
01:07artista_frustrad has quit IRC
01:09johnny has left #ltsp
01:10johnny has joined #ltsp
01:16t0mmii has quit IRC
01:16t0mmii has joined #ltsp
01:22johnny has left #ltsp
01:26johnny has joined #ltsp
01:28vagrantc has quit IRC
01:31johnny has left #ltsp
01:32johnny has joined #ltsp
01:43gymeleou has joined #ltsp
01:51johnny has left #ltsp
01:52gnunux has joined #ltsp
01:52gymeleou is now known as alkisg_work
01:54ogra_cmpc has quit IRC
01:56ogra_cmpc has joined #ltsp
01:58dobber has joined #ltsp
02:02vmlintu has quit IRC
02:04Egyptian[Home] has quit IRC
02:06Egyptian[Home] has joined #ltsp
02:10rickogden has joined #ltsp
02:14pthsWork has quit IRC
02:23vmlintu has joined #ltsp
02:24chupacabra has joined #ltsp
02:32pthsWork has joined #ltsp
02:39johnny has joined #ltsp
02:46ogra has joined #ltsp
02:53Guerdal82 has joined #ltsp
03:02ogra has quit IRC
03:03ogra has joined #ltsp
03:08ogra 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:33pthsWork has quit IRC
03:38pthsWork has joined #ltsp
04:06Selveste1 has joined #ltsp
04:08Selveste1 has quit IRC
04:08Selveste1 has joined #ltsp
04:09Guerdal82 has quit IRC
04:19mikkel has joined #ltsp
04:38alkisg has joined #ltsp
04:41mikkel has quit IRC
04:45mikkel has joined #ltsp
04:51wima1 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:06F-GT has quit IRC
06:23F-GT has joined #ltsp
06:29wwx has quit IRC
06:43wwx has joined #ltsp
06:44
<dobber>
starting a heavy loaded thunderbird for the first time
06:45
spikes mem usage to the maximum
06:50otavio has quit IRC
06:50F-GT has quit IRC
06:55otavio has joined #ltsp
07:01pmatulis has joined #ltsp
07:07F-GT has joined #ltsp
07:08rad4Christ has joined #ltsp
07:08sharles 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:47alkisg 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:05Gadi 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:38korcan has joined #ltsp
08:41sharles has quit IRC
08:46shawnp0wers has joined #ltsp
09:11alkisg has joined #ltsp
09:14sharles 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:27Selveste1 has quit IRC
09:31rickogden 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:41ogra_cmpc has quit IRC
09:43
<LedHed>
ls
09:43
oops
09:43ogra_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:52jammcq 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:57dobber has quit IRC
09:58vongrippen_ has joined #ltsp
09:59dobber has joined #ltsp
10:00Selveste1 has joined #ltsp
10:02vbundi has quit IRC
10:07dobber has quit IRC
10:19gnunux has quit IRC
10:19dobber has joined #ltsp
10:27staffencasa has joined #ltsp
10:31vagrantc has joined #ltsp
10:34dobber has quit IRC
10:43wima1 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:49shawnp0wers 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:49alexqwesa 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:51alexqwesa 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:00vagrantc has quit IRC
11:04vagrantc has joined #ltsp
11:04
<alkisg>
OK so I'll commit a min_ram=${min_ram:-64M} change there. Thanks!
11:38guaka has joined #ltsp
11:38
<guaka>
hi, anyone managed to use a scanner connected to a thin client on ltsp5?
11:41secayford has joined #ltsp
11:44otavio has quit IRC
12:04nesusvet 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:12guaka 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:29guaka has joined #ltsp
12:30otavio 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:52johnny has left #ltsp
12:53
<alkisg>
Setting SCREEN_DEFAULT=01 and SCREEN_01=nothing worked for me.
12:53johnny 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:56Selveste1 has quit IRC
12:57Selveste1 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:07nesusvet has quit IRC
13:10guaka has quit IRC
13:12vongrippen_ 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:22vongrippen 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:20leio has quit IRC
14:22rad4Christ has quit IRC
14:24leio has joined #ltsp
14:52pmatulis has quit IRC
15:05vvinet has quit IRC
15:06denisesball 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:11bobby_C has joined #ltsp
16:15
<denisesball>
anyways, thought i would let u guys know. thanks for the help as always!
16:18denisesball has left #ltsp
16:18
<alkisg>
Well my terminals behave the same, from 300Mhz/128 RAM to 800MHz/256 RAM... No noticable difference.
16:19chupacabra has quit IRC
16:21chupacabra has joined #ltsp
16:25
<jammcq>
chupacabra: ???
16:28highvoltage has quit IRC
16:29jammcq has quit IRC
16:34
<chupacabra>
hiya jim
16:42ogra_cmpc has quit IRC
16:44ogra_cmpc has joined #ltsp
16:52Gadi has left #ltsp
16:57vongrippen has quit IRC
17:17bobby_C has quit IRC
17:44secayford has quit IRC
17:54johnny has left #ltsp
17:55LedHed has quit IRC
17:56pmatulis has joined #ltsp
18:03alkisg has quit IRC
18:39staffencasa has quit IRC
18:46gentgeen__ has quit IRC
19:12mikkel has quit IRC
19:17johnny has joined #ltsp
20:06Egyptian[Home]1 has joined #ltsp
20:09Egyptian[Home] has quit IRC
20:22pmatulis has quit IRC
20:30peter_tm has joined #ltsp
20:31try2free has joined #ltsp
20:37ogra_cmpc has quit IRC
20:39ogra_cmpc has joined #ltsp
20:40howie_ has joined #ltsp
20:43howie_ has quit IRC
21:22peter_tm has left #ltsp
21:30jammcq has joined #ltsp
21:30
<jammcq>
hello friends
21:33try2free has left #ltsp
21:33ball has joined #ltsp
21:48johnny has left #ltsp
21:52ogra_cmpc has quit IRC
21:54ogra_cmpc has joined #ltsp
22:16ogra_cmpc has quit IRC
22:22sharles has quit IRC
22:24johnny has joined #ltsp
22:25bix0r has quit IRC
22:25sch-bot has quit IRC
22:28ogra_cmpc has joined #ltsp
22:33bix0r has joined #ltsp
22:33sch-bot has joined #ltsp
22:59ogra_cmpc has quit IRC
23:01ogra_cmpc has joined #ltsp
23:02ball has quit IRC