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


Channel log from 30 December 2008   (all times are UTC)

00:14litlebuda has joined #ltsp
00:14alkisg has quit IRC
00:33vagrantc has joined #ltsp
01:23gate_keeper_ has joined #ltsp
01:36tjikkun_work has joined #ltsp
02:13alkisg has joined #ltsp
03:02vagrantc has quit IRC
03:10warren has quit IRC
03:11
<Appiah>
Does anyone have a solution to clients not being able to PXE boot the same time? I dont feel like having to start 5 at the time as solution
03:40cib01 has left #ltsp
04:13wizzy has joined #ltsp
04:14
<wizzy>
folks, upgraded a thin client lab from v old CentOS to latest intrepid. some clients are *old*
04:15
i get error: "nbd0: Receive control failed (result -32)
04:16
help. I am in northern zululand, net access via my phone
04:17
and "Error Ioctl/1.1a failed: Bad file descriptor"
04:21F-GT has quit IRC
04:34
<Appiah>
I've seen that error in my interpid labb
04:34
but everything works
04:36F-GT has joined #ltsp
04:37
<wizzy>
some further googling suggests I go back to nfs from nbd
04:37
<Appiah>
so what happends after the result -32 ?
04:38
<wizzy>
how do I re-create nbi.img
04:38
I get the ioctl error, and everything stops
04:38
<Appiah>
ltsp-update-client or ltsp-build-client
04:39
ioctl error?
04:39
<wizzy>
I don,t want to rebuild
04:40
my 12:17 comment
04:40
<Appiah>
oh
04:40
why not rebuild?
04:41
<wizzy>
I have update-image, update-kernels
04:41
I have no net access
04:42
I just want to make nbi.img from kernel and initrd
04:43
<Appiah>
you can use cd or a file location with --mirror
04:43
<wizzy>
initrd is new - after moving to nfs' but nbi.img is still old
04:43hanthana has joined #ltsp
04:44
<wizzy>
and rebuild will put me back to nbd
04:44
<Appiah>
well I belive the ltsp-build-client does the nbi.img so you can check the script and do it by hand
04:45
<wizzy>
that script has no mention of nbi
04:46
hmm - update-kernels does
04:47
<Appiah>
hmm
04:47
<wizzy>
but I ran that
04:49cyberorg has quit IRC
04:49
<Appiah>
only thing update-kernels does it delete nbi.img
04:49
to cleanup
04:49
cant find which script that generates it >_>
04:49
<wizzy>
yes
04:50
I seem to remember mknbi or something
04:50
<Appiah>
none of the scripts in sbin seams to meantion it
04:50
<wizzy>
but the web is so lame on my phone
04:51
<Appiah>
I can imagen ;)
04:53
<wizzy>
maybe I can do oldstyle vmlinuz/initrd
04:54
can you google re nbi.img for me?
04:55
<alkisg>
wizzy: I don't think that "Bad file descriptor" is your actual problem, many people get that with Ubuntu 8.10 but everything else works. What is your *actual* problem? No X loading?
04:56
As for the nbi.img, I _think_ it's /usr/share/ltsp/update-kernels -u
04:57
<wizzy>
no X - the bootsplash progress bar stops
04:57
<alkisg>
Do you get any other error message?
04:57
Or it just hangs?
04:57
Can you logon to the console and do X -configure?
04:59
<wizzy>
retried again - seems to work now?? must do more testing
04:59shamino has joined #ltsp
05:00
<wizzy>
sorry re my extreme lag
05:00
<alkisg>
No problem, I can relate to how slow dial up access is! :)
05:01
Appiah: what error do you get if you try to boot more than 5 clients?
05:02
<Appiah>
alkisg not an error really, the clients just does not seam to get an IP from the DHCP
05:03
its not exactly 5 but if you try to boot up about 25clients , we get problems
05:03
if we boot up 5 , wait for them to get to X , then boot up another 5 , no thin client have to wait for an DHCP lease
05:03
it's on interpid
05:04
<alkisg>
Appiah: that's for the first or the second dhcp request?
05:05
i.e. the first = the one made by the pxe protocol (bios), the second = made from ipconfig in the initramfs
05:05
I'll bet the problem is with the second one... :)
05:13
Anyway, if the problem is with the second one, you may bypass it from /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
05:13
<Appiah>
it's the first
05:13
the PXE boot
05:14
<alkisg>
And if you enable "logging" in dhcpd.conf, you see that it complains about leases?
05:19
<Appiah>
I dont think I made these logs with the right debug lvl
05:20
<alkisg>
alkisg@alkisg:~$ grep logging /etc/ltsp/dhcpd.conf
05:20
logging;
05:20
<Appiah>
all it says is DHCPDISCOVER FROM [mac] via eth0 DHCPOFFER on [IP] to [mac] via eth0
05:20
repeats
05:20
and repeats
05:21
until you reboot about4-5 times
05:22
I'm not at the location of these clients or server atm so I cant make new logs
05:22dirigeant has joined #ltsp
05:22
<Appiah>
I'll have to make new ones
05:23
<alkisg>
So you don't get DHCPREQUEST / DHCPACK?
05:25
<Appiah>
not until I restarted that client about 5 times
05:26
<alkisg>
Do you have another dhcp server in the network?
05:26
And, are your TCs "real" PXE capable, or do they use etherboot or something similar?
05:27
<Appiah>
I think this one is seperated from the others
05:27
http://pastebin.ca/1296324
05:27
as you see it justs repeats (each repeat is the client failing and then restarting)
05:28
this are real PXE booting HP thin clients
05:28
pastebin is the old log
05:28
dont think there's a debug level defined in that log
05:35yanu has quit IRC
05:35
<alkisg>
Two requests, two acks... you either have another dhcp server somewhere running, or some packets are lost
05:36
You should use wireshark to see what exactly goes on
05:36
<Appiah>
Ye I will look deeper
05:36
when I'm there
05:38yanu has joined #ltsp
05:38
<Appiah>
wait
05:38
if there was 2 , shouldnt there be 2 different DHCPOFFER
05:40
<alkisg>
No
05:40
<Appiah>
I think I'll start with debugging dhcpd , then I'll debug the cisco switch
05:40
<alkisg>
It goes like this: ltsp offers IP#1, client requests IP#1,
05:41
<Appiah>
wouldnt suprise me if it filters when it gets to many requests
05:41
<alkisg>
second dhcp server offers IP#2, and at this point the client requests again IP#1
05:42
You could easily see if another dhcp server is running by blacklisting one mac address in dhcpd.conf. So if it gets an IP, it doesn't get it from the ltsp server
05:42
But it's probably the switch, it may be cutting off some broadcasted traffic
05:42
<Appiah>
ah , didnt think of the blacklisting
05:42
I'll try that
05:43
thanks
05:59
anyways alkisg if it was the "second" problem what is it that should be in /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default `?
06:03
<alkisg>
IPAPPEND 3
06:03
ipconfig had (and still has) some major problems, loosing packets etc
06:04
So by adding IPAPPEND 3 to a new line in pxelinux.cfg/default, you completely bypass the second dhcp request
06:16
<Ryan52>
some people must just sit around waiting for somebody to say something on launchpad, so that they can contradict the person...
06:17
<ogra>
heh
06:17
Ryan52, that bug should have a proper upstream task additionally to the fedora and ubuntu ones it currently has ... you should have closed the upstream one, then he would have understood it
06:20
<Ryan52>
ya.
06:23
<ogra>
i think that was fixed in 2.0.3 upstream ?
06:29
ah, no, commit 911, so version 2.0.13
06:30
<Ryan52>
no, it looks like it was fixed in 2.0.3.
06:30* Ryan52 thought 2.0.13 at first
06:30
<Ryan52>
heh. nevermind. it is 2.0.13. :)
06:30
<ogra>
well, Xsession is only actually used for executing ldm_session since 911 :)
06:31
<stgraber>
ogra: did you see that status change war on that ldm dependency bug ? :)
06:31
<ogra>
stgraber, yes, he just changed it again
06:32
and i'm out of arguments, i can probably throw in backportablity in debian ;)
06:32
silly bug
06:32
<Ryan52>
I don't even get why he cares so much..
06:33
ogra, backportability to what? sarge? 0_o
06:33
<ogra>
etch :)
06:34
<stgraber>
anyway, going to the office now, will be back in a bit
06:34
<Ryan52>
ryan52@reiche:~$ apt-cache show gtk2-engines-clearlooks | grep Description
06:34
Description: Clearlooks GTK+ 2.x engine and theme (dummy package)
06:34
that's an etch system.
06:34
<ogra>
oh, k ... packages.d.o said etch stll had a real package
06:35
oh, no, i misread :)
06:39* ogra strikes back on the theme bug :P
06:39
<Ryan52>
hehe
06:52BrunoXLambert has joined #ltsp
07:15
<Ryan52>
and he filed a bug in Debian :)
07:36hanthana is now known as hanthana|afk
07:39
<stgraber>
ogra: can you ack https://bugs.edge.launchpad.net/ubuntu/+source/ltspfs/+bug/311873 ?
07:49evilx has joined #ltsp
07:52
<stgraber>
ogra: can you upload: http://www.stgraber.org/download/ubuntu/ltsp/ ?
07:57six2one has joined #ltsp
08:01CAN-o-SPAM has joined #ltsp
08:06dirigeant has quit IRC
08:12gate_keeper_ has quit IRC
08:17gate_keeper_ has joined #ltsp
08:21
<gate_keeper_>
Guys
08:21
messages error:
08:21
kernel: [24925.821917] end_request: I/O error, dev nbd0, sector 225260
08:21
kernel: [24909.885538] end_request: I/O error, dev nbd0, sector 225909.921436] nbd0: Attempted send on closed socket
08:21
what can cause this?
08:21
:/
08:28Gadi has joined #ltsp
08:50
<cliebow>
Gadi, what would i use to count the characters in a variable in put from keyboard in bash
08:55
<evilx>
Gadi, I finally got the openchrome to work with xorg. I ended up just compiling the svn version from openchrome site
08:55
<nubae>
gate_keeper_: sounds like youre trying to connect from a clossed ltsp session
08:56
ie, u restarted the server, or unplugged cable for period of time
08:57
<gate_keeper_>
hmm
08:57
maybe
08:57
but i cannot connect to the server also
08:57
it takes forever to login
08:57
via ssh
08:58
and all the services are slowing down on the server with responce
08:58
<nubae>
and directly from the server gdm login screen?
08:58
<gate_keeper_>
yup, also directly
08:58
with no ssh
08:59
<nubae>
u've looked at the xsession-errors?
09:01
<gate_keeper_>
slow responce from the commands
09:01
also
09:01
brb, reboot
09:02nubae has left #ltsp
09:04gate_keeper_ has quit IRC
09:08gate_keeper_ has joined #ltsp
09:10
<evilx>
where can I find documentation on ldm, I would like to change the background of it
09:11
think i found it
09:13
<gate_keeper_>
back ..
09:14nubae has joined #ltsp
09:16
<alkisg>
cliebow: echo ${#DISPLAY}
09:21babyhuey has joined #ltsp
09:21
<babyhuey>
can anyone reccommend a thin client that will work with ltsp5 and is decent?
09:22
like is the series 1000 on disklessworkstations going to work decent or will it suck?
09:23
<cliebow>
alkisg:got it!
09:23
<alkisg>
cliebow: I think it also works with sh/dash
09:27
<cliebow>
good! and Thanks
09:30dirigeant has joined #ltsp
09:30
<CAN-o-SPAM>
babyhuey: ltsp term 1000 not recommended for LTSP 5 (not enough power)
09:30spectra has joined #ltsp
09:31
<Ryan52>
/g 26
09:31
<evilx>
im not sure what ltsp I am using but we have two system here I got working a neoware and hp
09:31
<CAN-o-SPAM>
babyhuey: ltsp term 1220 or 1420 works very well with LTSP 5
09:32
<evilx>
the neoware slow, the T5135 decent for some things
09:33
<Gadi>
cliebow: read junk; echo -n $junk|wc -c
09:33
(sorry - was in a mtg)
09:34
cliebow: or: read junk; echo ${#junk}
09:35
evilx: you may want to set LDM_DIRECTX=True
09:35
<babyhuey>
evilx: the t5135 has a decent boot time for ltsp5?
09:35
<evilx>
i did
09:36
<babyhuey>
about how long is the boot time?
09:36
<Gadi>
babyhuey: why so obsessed with boot time?
09:36
reboot often?
09:36
<babyhuey>
the software that runs on them crashes often and need to be rebooted
09:36
<Gadi>
hehe
09:36
<babyhuey>
its just running a piece of software that allows people to clock in and out
09:37
<CAN-o-SPAM>
character or GUI based?
09:37
<Gadi>
it crashes the whole system?
09:37
<babyhuey>
i was thinking about just keeping the hardware we have now and rebuilding a 4.2
09:37
we have jammin125 and they are slow as dirt with ltsp5
09:37
<Gadi>
the fastest reboot is the one you dont have to do
09:37
<babyhuey>
yea
09:38
<Gadi>
can you fix the sw?
09:38
<babyhuey>
i just need something cheap that will be stable
09:38
<Gadi>
or work around the crash?
09:38
<babyhuey>
the system is pretty much hosed, i was just going to do a reinstall on a virtual machine
09:38Sarten-X[bikinis has joined #ltsp
09:38
<babyhuey>
the crash locks the system up
09:38
<Gadi>
is the app running on the server?
09:39
<babyhuey>
the backend is
09:39
its running off a different server
09:39
<Gadi>
is it GUI?
09:39
on the client?
09:39
<babyhuey>
yes
09:39
<Gadi>
try setting XRAMPERC
09:39
to something like 90
09:39
or some such
09:40
that may keep the system from locking up
09:40
and just kill the app
09:40
then, you can make the app respawn
09:40
which would be much more graceful than rebooting
09:40
<evilx>
hold on and let me but the hp
09:40
<babyhuey>
its running on 10 thin clients
09:40
<evilx>
right now I am running it in vmware and over the neoware and i need to switch the kvm
09:41
i hit the power button let see
09:42alkisg has quit IRC
09:42
<evilx>
still going
09:43
and it at the login screen
09:43
so about two minutes
09:43
<babyhuey>
mmk
09:43
ty evilx
09:43
<evilx>
np
09:44
<Gadi>
babyhuey: I would still set XRAMPERC and have the app respawn. You can also optimize the chroot a bit by turning off some services that run by default
09:44
such as syslog, acpi, ...
09:45
or postpone them until after ldm
09:45
booting with the splash turned off will tell you where the delays are
09:45
<evilx>
babyhuey, if you get an thin client, do not get one with a via video card
09:46
<Gadi>
well, thats a bit unfair
09:46
via has a million chipsets
09:47
and you throw them all out the window based on an old cle266
09:47Sarten-X has quit IRC
09:47
<evilx>
ok fine
09:47
<Gadi>
evilx: you may want to try via's binary driver
09:47
<evilx>
atleast I finally got it working
09:47
<Gadi>
you are using a reverse engineered open source driver
09:47
:)
09:48
<evilx>
there a binary driver!
09:48
<Gadi>
sure
09:48
from their website
09:48
<evilx>
I had to compile the svn of openchrome to get it to work
09:48
<Gadi>
just think back to your Windows 3.1 days
09:48
when you would actually install drivers
09:48
;)
09:48
<evilx>
I don't want to remember those days, I might end up installing doom and not get any work done at work
09:48
<Gadi>
lol
09:49
<evilx>
plus, I am glad I never have to set irq's anymore
09:50UsUrp_away is now known as _UsUrPeR_
09:52daya has joined #ltsp
09:56alkisg has joined #ltsp
09:57johnny has left #ltsp
09:58alkisg has quit IRC
09:59evilx has quit IRC
09:59evilx has joined #ltsp
10:05gate_keeper_ has quit IRC
10:06johnny has joined #ltsp
10:07
<CAN-o-SPAM>
does anyone know when ogra is back from vaca?
10:08
<mistik1>
Gadi: That was a purely bad memory you invoked there
10:08
almost evil
10:10
<Ryan52>
CAN-o-SPAM: he was on irc last night/morning/whatever you call it :)
10:11
<CAN-o-SPAM>
Ok! Thanks Ryan
10:11
<Gadi>
bwahahaha
10:13
<mistik1>
oh no, madness has indeed claimed my friend
10:17alkisg has joined #ltsp
10:18staffencasa has joined #ltsp
10:21alkisg has left #ltsp
10:22
<_UsUrPeR_>
ok, F10, newly installed ltsp-server package, can't log in from client
10:23
the only thing I see in the logs is: "localhost sshd[pid]: connection closed by <client IP Address>"
10:23alkisg has joined #ltsp
10:24
<_UsUrPeR_>
The client shows "verifying password. Please wait..." then restarts X and goes back to a login prompt.
10:25
<johnny>
you should know what to do next
10:25
by now
10:26vagrantc has joined #ltsp
10:26
<_UsUrPeR_>
ssh is working fine
10:26
from the client to server, from server to client
10:27
that's from the client shell of course
10:28
update-ssh-keys has been done
10:28
<johnny>
hmm did you check the ldm log?
10:29
<_UsUrPeR_>
on the client? not yet.
10:29
lemme take a look
10:30
<alkisg>
I think that's by far the most common "bug"... ldm should display more info about ssh problems... :)
10:31
<_UsUrPeR_>
I see the following on my login attempt: "ssh_session: ssh -Y -t -M -S /var/run/ldm_socket_2484_10,1,1,1 -o NumberOfPasswordPrompts=1 <username>@10.1.1.1 echo LTSPROCKS; /bin/sh -"
10:32
<johnny>
and then what?
10:33
<_UsUrPeR_>
it's not getting a response for "RSA key fingerprint question - "Are you sure you want to continue connecting (yes/no)?""
10:33
"expect saw:"
10:34
""No response, restarting"
10:34
grrr
10:36
ok, so it's not typing "yes"
10:36
<johnny>
that's the problem
10:36
it shouldn't
10:36
it should have the server hostname already
10:36
<_UsUrPeR_>
a porblum indeed
10:36
<johnny>
err the server's key already
10:37
copy the server's key to the chroot
10:37
<_UsUrPeR_>
just ran update-ssh-keys again
10:37
ok
10:37evilx has quit IRC
10:37
<alkisg>
_UsUrPeR_: you also need ltsp-update-image after update-ssh-keys...
10:37
<johnny>
alkisg, not on fedora yet
10:37
it doesn't do nbd
10:37
<alkisg>
ooops, sorry
10:37
<johnny>
only ubuntu does nbd by default
10:37
iirc
10:38* alkisg is ashamed that didn't find the time to try out more distros
10:38
<johnny>
and as far as i know ubuntu and debian are the only ones that can do nbd easily
10:38
due to the usage of initramfs-tools that they share
10:38
<alkisg>
So other distros use nfs?
10:38
<johnny>
with the possible exception of opensuse
10:39
even debian uses nfs by default
10:39
altho nbd is optional
10:39
err is an option
10:41
<alkisg>
How much quicker is nbd than nfs? Is it worth all this trouble, or is it only for people complaining about 10 secs more while booting?
10:42
(I also don't like the fact that if you pull off a client's cable, you don't have a chance to put it back before everything crashes... :P)
10:42
<vagrantc>
alkisg: it's a lot faster, as long as you don't change the chroot all the time.
10:42
<alkisg>
Well, I imagine only on critical updates...
10:43
<johnny>
sure
10:44
<vagrantc>
at freegeek, we're sometimes making changes to the chroot multiple times a day ...
10:44
so NFS is the way to go. it's also simpler for debugging issues
10:45
i haven't tested the NBD support with Debian in a while ...
10:45
<alkisg>
Wow... for "production" clients? I thought this would only be the case for testing environments!
10:46
Bah... we school teachers/admins are happy to only click "yes" on update manager... :P :D
10:46
<vagrantc>
Debian actually has basically two options for NBD ... the thing like what ubuntu uses (NBD+aufs+squashfs+tmpfs) with ltsp's initramfs-tools hooks and NBD+*fs, using nbd-client's initramfs-tools hooks
10:47
<alkisg>
...too many *fs interpretation error, alkisg is restarting... :)
10:47
<vagrantc>
heh. http://bugs.debian.org/510204 ... they reported a bug against the *only* version of the package that doesn't have the bug.
10:48
<alkisg>
...and I thought someone was working on sshfs?
10:48
<vagrantc>
well, by *fs, i guess i mean your conventional filesystems ... ext*, reiserfs* *cringe*, etc...
10:49
<alkisg>
Ah, ok
10:49
<vagrantc>
it creates a loopback image, puts a filesystem on it, mounts it, and builds the ltsp chroot in it. then it's exported over NBD
10:49
<alkisg>
By the way, you remember the problem with the gpxe disk? It turns out that all it needs is padding to 1.44 MB, there's a perl script inside the utils directory for that, it just isn't called from the build scripts (don't know why)
10:50
<_UsUrPeR_>
where is the ssh key stored on the server? where does it go on the client?
10:50
<vagrantc>
the advantages is that you can update the NBD image directly...
10:50
alkisg: ah. there's also make pdsk or something like that, which does some sort of padding, but not all the way out to 1.44MB
10:51
<_UsUrPeR_>
ok, a better question: did I install ltsp wrong in F10? "yum install ssh-server"
10:51
this problem should not appear if installed properly, after all :/
10:51
<vagrantc>
alkisg: i enable it in the gpxe debian packages that i built ...
10:53
<alkisg>
Someone at #etherboot is working on enabling gpxe command line parameters (when loaded from e.g. grub), when he does it it'll be very easy to have static IPs with ltsp.
10:54daya has quit IRC
10:55
<vagrantc>
nice!
10:56daya has joined #ltsp
10:57sepski has joined #ltsp
10:59jammcq has joined #ltsp
10:59
<jammcq>
hello #ltsp
11:00
<_UsUrPeR_>
sup jammcq
11:00
<mistik1>
hey there pops
11:00
<cliebow>
Daddoo!1
11:04
<jammcq>
hello gentlemen
11:05
<johnny>
_UsUrPeR_, they should go in /etc/ssh
11:07RobertMLaptop has joined #ltsp
11:07RobertLaptop has quit IRC
11:07RobertMLaptop has quit IRC
11:07RobertLaptop has joined #ltsp
11:11alkisg has left #ltsp
11:14alkisg has joined #ltsp
11:17hanthana|afk is now known as hanthana
11:18cyberorg has joined #ltsp
11:18tjikkun_work has quit IRC
11:18cyberorg_ has joined #ltsp
11:23sepski has quit IRC
11:26daya has joined #ltsp
11:28daya has joined #ltsp
11:31daya has joined #ltsp
11:32daya has quit IRC
11:33daya has joined #ltsp
11:36hanthana has quit IRC
11:41daya has quit IRC
11:45Ahmuck has joined #ltsp
12:08* vagrantc uploads ltsp 5.1.44-1 to debian experimental
12:36vagrantc has quit IRC
12:39evilx has joined #ltsp
13:00
<stgraber>
ogra: around ?
13:36
<rjune>
staffencasa, I think he's still on holiday
13:36
staffencasa, ^
13:36
stgraber, ^
13:36
*sigh*
13:42evilx has quit IRC
13:42evilx has joined #ltsp
13:47
<Gadi>
stgraber: ping
13:49
<stgraber>
Gadi: pong
13:49
rjune: he's but he usually is on IRC even when he's on vacation :)
13:49
<Gadi>
stgraber: 2 things: 1. I just pushed a fix to the localapps getent group stuff
13:49
<stgraber>
rjune: at least he was some hours ago
13:49
Gadi: fixing what ?
13:49
<Gadi>
if you could test it with ur pam_group setup, that'd be great
13:50
the "group" command fails in an AD environment
13:50
on groups like Domain Users
13:50
(2 words)
13:50
which causes the entire usermod command to fail
13:50
due to nonexistant groups "Domain" and "Users"
13:51
this way, it should work in both
13:51
<stgraber>
ok
13:51
<Gadi>
until the pam_groups bug is fixed
13:51
:)
13:52
if you could test it in ur pam_groups env, that would help
13:52
and... 2. whenever you want to play with local ltspfsmounter lemme know
13:52
:)
13:53
<stgraber>
yeah, I'm mainly working on some ia64 things today, I just had a look at your patch and it looks like it should work, will try it later today or tomorrow
13:53
<Gadi>
cool
13:53
ping me when u get around to it
14:05
<CAN-o-SPAM>
!seen warren
14:05
<ltspbot>
CAN-o-SPAM: warren was last seen in #ltsp 15 hours, 14 minutes, and 6 seconds ago: <warren> Ryan52: ltsp-trunk lacks configure?
14:17vagrantc has joined #ltsp
14:24* vagrantc hopes Gadi and stgraber don't get into a revert war :)
14:24
<Gadi>
vagrantc: stop stirring pots
14:24
:P
14:24
oh, and feel free to test
14:25
:)
14:25
<vagrantc>
yes, i intend to.
14:25
<Gadi>
oh and clean up my code
14:25
:D
14:25
<vagrantc>
last i looked, i was still getting inconsistancies with GIDs
14:26
<Gadi>
system GIDs should/can differ - non-system should be the same
14:26
<vagrantc>
Gadi: it's not just a revert, but you actually re-wrote it a little?
14:26
<Gadi>
I wrote it to support both
14:26
<vagrantc>
Gadi: well, the groups that the user is in was based on GID, not name, last i looked.
14:26
but i couldn't figure out why based on the code.
14:27
<Gadi>
nah, what it does (and always did_) was:
14:27
<vagrantc>
that's why i can't figure out why it was broken, because it *looked* like it was doing the right thing. but it wasn't.
14:27
it looked like it set it based on name, but then the results were clearly GID based.
14:28
<Gadi>
1. getent the server's groups and add any additional groups to the local /etc/groups
14:28
preserving the local's system groups
14:28
(and GIDs)
14:28
2. add the user into all the groups s/he is in on the server
14:28
so, the only GIDs that should differ from the server are the system GIDs
14:29
s/should/may/
14:29
which is important
14:29
<vagrantc>
but when i type groups on the server, and groups on the localapp'ed xterm, i get discrepencies.
14:29
<Gadi>
wouldn't want to belong to the server's fuse group on the client, for example
14:29
right
14:30
for system groups, you should
14:30
<vagrantc>
like, the user *should* belong to the fuse group, but instead belongs to the pulse group.
14:30
<Gadi>
ah
14:30
thats wrong
14:30
<vagrantc>
i.e. on the server, GID 106 is fuse, and on the thin client, GID 106 is pulse
14:30
<Gadi>
I thought you meant it belonged to fuse(112) vs. fuse(113)
14:31
hmm...
14:31
<vagrantc>
when i type groups on the server, it shows me as belonging to fuse, but when i type it on the thin client, it shows me as belonging to pulse
14:31
<Gadi>
lemme look at the code again
14:31
<vagrantc>
maybe it has something to do with when the usermod is called relative to when the group data is updated in the client's /etc/groups ?
14:32xmagixx has quit IRC
14:33
<Gadi>
no, but it may be whether while read line; do .. ; done </etc/group reads from bottom up or top down
14:33
it *should* read top down
14:35xmagixx has joined #ltsp
14:50Eghie has joined #ltsp
14:50cliebow has quit IRC
14:52pscheie has joined #ltsp
15:16Michiel has joined #ltsp
15:16Michiel is now known as Guest81991
15:17Guest81991 is now known as Eghie_
15:18Eghie has quit IRC
15:18F-GT has quit IRC
15:18davidj has quit IRC
15:22F-GT has joined #ltsp
15:23davidj has joined #ltsp
15:25CAN-o-SPAM has quit IRC
15:28spectra has quit IRC
15:32alkisg has quit IRC
15:38pscheie has quit IRC
15:41loather-work has quit IRC
15:42loather-work has joined #ltsp
15:43pscheie has joined #ltsp
15:46pscheie has quit IRC
15:48six2one has quit IRC
15:51Eghie_ has quit IRC
15:51Eghie has joined #ltsp
15:58pscheie has joined #ltsp
16:06BrunoXLambert has quit IRC
16:11jammcq has quit IRC
16:13evilx has quit IRC
16:18epoxy|w3rk has quit IRC
16:21Gadi has left #ltsp
16:35ogra has quit IRC
16:37ogra has joined #ltsp
17:08Eghie has quit IRC
17:21dirigeant has quit IRC
17:56johnny has left #ltsp
18:01vagrantc has quit IRC
18:32cyberorg has quit IRC
18:32Gadi_eeepc has joined #ltsp
18:34johnny has joined #ltsp
18:42loather-work has quit IRC
18:43loather-work has joined #ltsp
18:47GodFather has joined #ltsp
19:00staffencasa has quit IRC
19:08warren has joined #ltsp
19:17J45p3r__ has joined #ltsp
19:17petre has joined #ltsp
19:38_stink_ has joined #ltsp
20:03GodFather has quit IRC
20:04andresmujica has joined #ltsp
20:22Gadi_eeepc1 has joined #ltsp
20:22Gadi_eeepc has quit IRC
20:23J45p3r__ has quit IRC
20:57Loto_ has quit IRC
21:09loather-work has quit IRC
21:18loather-work has joined #ltsp
21:51RobertLaptop has quit IRC
21:53RobertLaptop has joined #ltsp
21:57mistik1_ has joined #ltsp
21:58cyberorg has joined #ltsp
21:58mistik1 has quit IRC
21:58mistik1_ is now known as mistik1
22:02CaScAdE^FarAway has joined #ltsp
22:10petre has quit IRC
22:10johnny has left #ltsp
22:14Ahmuck has quit IRC
22:18CaScAdE^1arAway has quit IRC
22:35alkisg has joined #ltsp
22:39johnny has joined #ltsp
23:02andresmujica has quit IRC
23:31alkisg has quit IRC
23:50litlebuda has quit IRC