Main page
[00:06] Selveste1 (~Selveste1@wnn72114.wireless.dtu.dk) joined #ltsp.
[00:06] [X-Raimo] hello. can anyone help me with pulseaudio issue http://paste.org.ru/?dyd9jg please? This happens at LTSP Server and client
[00:17] daya (~daya@202.63.242.211) left irc: Ping timeout: 265 seconds
[00:26] *** alkisg wonders where's a good place to put a "fix-polkit-1-files" script...
[00:37] try2free (~send2us@118.96.121.25) joined #ltsp.
[00:41] try2free (send2us@118.96.121.25) left #ltsp.
[01:11] daya (~daya@202.63.242.211) joined #ltsp.
[01:16] [ogra] alkisg, what does it do ?
[01:17] [ogra] just cp files to /etc/polkit-1/*.d/ ?
[01:17] [alkisg] ogra, I was thinking of modifying things in polkit-1, yeah, but I wonder if that's the right approach
[01:17] [alkisg] Maybe it would be best if (1) I fixed ltsp so that the logged on users shows as ACTIVE in PK,
[01:18] [ogra] if you put them in the .d dirs i think thats the right approach
[01:18] [alkisg] and (2) created a shadow entry to enable the users to get authenticated
[01:18] [ogra] i would make an upstart job with a script that checks if you are on a fat client and based on that copies the files or not
[01:18] [alkisg] of course, *only* if the admin allows it in lts.conf
[01:19] [alkisg] That would make fat clients work like normal ubuntu pcs
[01:19] [ogra] does ltsp-client-core expose a dm event for upstart ?
[01:19] [alkisg] and, when in the future sbalneav implements libpam_sshauth, I'd just remove the shadow entry, as it would be redudant
[01:20] [ogra] i wouldnt fiddle with shadow if possible
[01:20] [alkisg] How would the users authenticate?
[01:20] [alkisg] E.g. I'd want an admin to be able to mount the internal disks, but not a student
[01:20] [ogra] how do they do it now ?
[01:20] [alkisg] That's not possible with ltsp currently...
[01:20] [alkisg] They don't
[01:21] [ogra] at all ?
[01:21] [alkisg] Yup
[01:21] [ogra] oh
[01:21] [alkisg] The user cannot authenticate himself *locally*
[01:21] [ogra] i thought you already had a solution and were just held up by PK
[01:21] [alkisg] So any localapps which need authentication do not work
[01:21] [alkisg] E.g. if the screensaver runs locally, and it locks, there's no way to unlock it
[01:22] [alkisg] OK, storing a hash in shadow does have some security implications
[01:22] [ogra] gss talks through dbus to the session bus ;)
[01:22] [alkisg] But I think it should be there as an option
[01:22] [ogra] fix dbus ;)
[01:22] [alkisg] That wouldn't help
[01:22] [ogra] sure
[01:22] Selveste1 (~Selveste1@wnn72114.wireless.dtu.dk) left irc: Read error: Connection reset by peer
[01:22] [alkisg] I'd need to fix pam
[01:22] [ogra] you'd need to merge server and client busses
[01:22] Selveste1 (~Selveste1@wnn72114.wireless.dtu.dk) joined #ltsp.
[01:23] [alkisg] How would that help with unlocking the screensaver?
[01:23] [ogra] (in your fat client case it would have to be the system busses)
[01:24] [ogra] the system bus looks for an entry in shadow ... if your busses are merged it looks for that on the server
[01:24] [alkisg] But for fat clients the system bus is on the client...
[01:24] [ogra] right, because you didnt kmerge the two busses yet
[01:25] [alkisg] How can one merge 2 system busses?
[01:25] [ogra] the system busses need to be tied together at login time
[01:25] [ogra] with a ssh based dbus protocol :)
[01:25] [alkisg] I'm not worried about the communication part
[01:25] [ogra] in case of thin clients you use the system bus on the client and merge the session busses
[01:25] [alkisg] I just don't think it's possible to merge 2 system buses
[01:25] [ogra] in case of fat clients you run the session bus locally and merge the system busses
[01:26] [alkisg] So which networkmanager would I keep?
[01:26] [alkisg] The server one or the client one?
[01:26] [alkisg] Which realtimekit? which pk?
[01:26] [alkisg] which avahi?
[01:26] [ogra] you would need some policies ...
[01:26] [alkisg] which upower?
[01:26] [ogra] as i said, you need some policies
[01:26] [alkisg] When the client wanted to get to standby, would the server also get to standby?
[01:27] [alkisg] I think each system bus is designed to manage exactly one machine
[01:27] [ogra] all auth goes through the server bus ... all HW access through the client bus
[01:27] [alkisg] I don't think it's possible to merge 2 system busses...
[01:27] [ogra] no, but make your session bus talk to one or the other
[01:27] [ogra] (thats what i mean with merge :) )
[01:28] [ogra] network transparent dbus is the only proper solution to either thin or fat clients
[01:28] [ogra] and the proper set of policies
[01:28] [alkisg] I can't even begin to understand how that would work.
[01:28] [alkisg] I think it's not designed to do that.
[01:29] [ogra] you connect your session bus to both system buses at log in (dbus needs to learn that, i thinnk sbalneav looked into various options for dbus over ssh)
[01:29] [ogra] and have a policy for the session bus that ll auth requests go to the server
[01:29] [ogra] everything else goes to the client
[01:30] [ogra] for thin clients you want it exactly the other way round
[01:30] [alkisg] How would a session bus be connected to 2 system busses?
[01:30] [alkisg] Would I duplicate all C pointers inside their source code?
[01:30] [ogra] you have two session buses that both need to connect to the clients system bus
[01:30] [ogra] i have no idea ...
[01:30] [ogra] i'm not a dbus hacker
[01:31] [ogra] i just say thats the only proper solution :)
[01:31] [alkisg] I mean, *all* client apps would need to be changed to support that
[01:31] [ogra] no
[01:31] [alkisg] We couldn't just change dbus for that
[01:31] [ogra] just the bus
[01:31] [alkisg] We'd need to change all apps that talk to dbus...
[01:31] [ogra] no
[01:31] [ogra] you need to change the dbus policies
[01:32] [ogra] dbus knows if an auth request comes
[01:32] [ogra] so it needs to route it to the right system bus
[01:32] [ogra] the only apps you will get probs with are gksu apps in the case of your fat client approach ...
[01:33] [ogra] but gksu is going away
[01:33] [alkisg] ogra, I still don't think dbus has anything to do with authentication
[01:33] [ogra] huh ?
[01:33] [alkisg] If a user wants to run something from the console, e.g. sudo ls, it won't work
[01:33] [ogra] dbus is 'all' about authentication
[01:34] [ogra] no, as i said, sudo apps will get you probs
[01:34] [alkisg] If he wants to run getent shadow, it won't work
[01:34] [alkisg] So the proper way to solve this is with a pam module
[01:34] [ogra] well, there is no safe solution to that prob
[01:34] [ogra] nothing thats not hackish at least ...
[01:34] [alkisg] That way it would work no matter what's used at the backend
[01:35] [alkisg] Be it ldap or libpam-sshauth
[01:35] [ogra] for GUI apps dbus provides a proper solution if you modify it the right way
[01:35] [alkisg] dbus doesn't get involved in that. It just uses whatever pam is available...
[01:35] [ogra] libpam-sshauth wont solve the dbus prob
[01:35] X-Raimo (alexmurav@opensuse/member/raimoschmidt) left #ltsp.
[01:35] [alkisg] Sure, but it will solve the authentication problem
[01:35] [alkisg] And, for fat clients, nothing dbus-related is needed
[01:36] [ogra] well, then help finishing libpam-sshauth :)
[01:36] [alkisg] I don't have the knowledge to do that
[01:36] [ogra] fiddling with shadow us definately a bad idea
[01:36] [ogra] *is
[01:37] *** ogra needs to reboot after an upgrade...
[01:37] [alkisg] ogra, I just want the fat clients plugin to work good enough for lucid
[01:38] [alkisg] I don't see any other options here
[01:38] [alkisg] It's either 'modifying polkit files' or 'inserting a shadow entry'
[01:38] [alkisg] It's not nearly as bad as allowing LDM_PASSWORD...
[01:38] [alkisg] ...anyone can get that with tftp
[01:39] [alkisg] And, the polkit approach won't be there for long - I think the shadow entry gives a more consistent user experience
[01:39] [alkisg] Anyway, I'd appreciate any hints on how to make CK think that our session is ACTIVE... :)
[01:39] ogra (~ogra@ubuntu/member/ogra) left irc: Read error: No route to host
[01:40] ogra (~ogra@ubuntu/member/ogra) joined #ltsp.
[01:40] [nubae] alkisg: and LDAP won't do?
[01:41] [alkisg] nubae: ldap would do just fine, but it's not integrated to ltsp
[01:41] [nubae] how not? its integrated enough
[01:41] [nubae] I use it
[01:41] [alkisg] How do you build a client that uses ldap for authentication?
[01:41] [ogra] because you picked a default setup
[01:42] [nubae] thesame way build any client
[01:42] [nubae] that has nothing to do with the authentication
[01:42] [alkisg] ogra, http://alkisg.pastebin.com/s6uzW0bB
[01:42] [ogra] the prob is that there is nobody who said "thats the ubuntu default, screw all other setups"
[01:42] [alkisg] nubae: are the clients authenticating *WITH LDAP*? or with ssh to the server, then THEN use ldap?
[01:42] [ogra] so if someone has an existing ltsp server that uses ldap and you enforce a default on him you will break the existing setup
[01:43] [alkisg] nubae: try this: ltsp-localapps xterm => and then login nubae. Does that work? Can you login locally?
[01:43] [alkisg] (or, SHELL_02=shell => login as nubae)
[01:43] [alkisg] *SCREEN_02
[01:44] [nubae] why wouldnt it work?
[01:44] [alkisg] Because the client doesn't use ldap
[01:44] [nubae] ldap authentication works fine across the board
[01:44] [alkisg] The server uses ldap...
[01:44] [ogra] alkisg, fiddling with shadow is error prone and might even introduce security isssues if yousay "its either PK or shadow", go with PK
[01:44] [nubae] u set it up to use ldap
[01:44] [nubae] thats a 5 minute setuop
[01:44] [alkisg] nubae: so you don't use ldm
[01:44] [alkisg] ?
[01:44] [alkisg] because ldm uses ssh, not ldap...
[01:44] [nubae] I do use ldm, that has nothing to do with it....
[01:44] [alkisg] Sure it does
[01:44] [nubae] right
[01:45] [nubae] but ldap supports ssh too
[01:45] [nubae] its an all encompassing authentication system
[01:45] [alkisg] nubae: ok, are you one a client?
[01:45] [ogra] nubae, the problem is that you might break existing ldap server setups
[01:45] [nubae] no, as many as I want
[01:45] [alkisg] Put SCREEN_02=shell, and run: getent passwd
[01:45] [nubae] why=
[01:45] [alkisg] You won't see the ldap users there. Try it.
[01:45] [nubae] the client setup is identical to a non ltsp client setup
[01:46] knipwim_ (~wim@ip4da83870.direct-adsl.nl) joined #ltsp.
[01:46] [ogra] yes, the client setup should be pretty safe to do
[01:46] [nubae] I wont see why users where?
[01:46] [ogra] the server setup wont
[01:46] [nubae] I have tried it and run it... it runs just fine
[01:46] [nubae] The first time I ran fatclients was LDAP only... there were no issues
[01:47] [nubae] I just uses the passwd shadow copy hack method cause it was easier and didnt require ldap installed in the client
[01:47] [nubae] but both methods work
[01:47] [nubae] ogra: I dont understand what u mean, u dont need to change the ldap server setup
[01:47] knipwim (~wim@ip4da83870.direct-adsl.nl) left irc: Read error: Operation timed out
[01:47] [nubae] it is the same as for any other system
[01:47] [ogra] ldap is surely cleaner in that case ... but there is no solution to the server side unless someone defines a standard layout for all ubuntu ldap servers
[01:48] [nubae] u mena schema wise?
[01:48] [nubae] mean
[01:48] [ogra] nubae, the db layout is freely choosable
[01:48] [ogra] right
[01:48] [nubae] ok...
[01:48] [alkisg] nubae: in any case, the client session isn't considered active. So even if ldap worked, you couldn't use the local disks etc. We'd need to fix LTSP against consolekit first.
[01:48] [nubae] now I get u... still u can have mutliple schemas
[01:48] [nubae] and they are very easily transferable
[01:48] [ogra] as long as there is no standard you might completely screw up existing setups
[01:48] [ogra] thats the biggest prob with ldap
[01:49] [ogra] if there would be a defined standard you could just hook into it
[01:49] [nubae] that I dont get... u're just talking about fitting an existing database into the ldap server setup... admins go through that all the time
[01:49] [nubae] and thats not ltsp specific
[01:49] [ogra] no
[01:49] [nubae] I'm running LDAP with ltsp right now... with a standard posix schema
[01:49] [nubae] it runs just fine
[01:50] [ogra] if an admin defined a schema for all the stuff he wants authenticated you cant guarantee your schema mautches
[01:50] [ogra] *matches
[01:50] [ogra] so you add your schema additionally ... that means two auth db's
[01:50] [nubae] but u can modify a schema (ldap can read more than one schema)
[01:50] [nubae] so?
[01:50] [ogra] which defeats the purpose of ldap :)
[01:50] [ogra] the admin has to maintin two auth dbs
[01:51] [nubae] vs hacking tons of scripts to get everything from local devs to sound to god knows what else working?
[01:51] [ogra] ldap will only work properly if someone finally defines a standard
[01:51] [nubae] no... u can have the auth all in one db
[01:51] [nubae] u dont need 2 seperate dbs
[01:51] [nubae] I have it in one db
[01:51] [ogra] how if the db schemas dont match ?
back next →
1 2 3 4 5
up
Generated by logs2html module for eggdrop v.2.3.4
Find latest version at http://sourceforge.net/projects/logs2html or http://shmupsik.osetia.org