IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 30 December 2016 (all times are UTC)
| 00:58 | bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 252 seconds) | |
| 01:01 | bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132) | |
| 01:18 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 01:28 | bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 245 seconds) | |
| 01:30 | bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132) | |
| 02:18 | bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 248 seconds) | |
| 02:20 | bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132) | |
| 02:28 | bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 258 seconds) | |
| 02:30 | bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132) | |
| 03:05 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Remote host closed the connection) | |
| 03:09 | lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18) | |
| 03:12 | lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection) | |
| 03:13 | lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18) | |
| 03:39 | lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection) | |
| 04:27 | bennabiy_ has joined IRC (bennabiy_!~bennabiy@97.89.236.39) | |
| 05:04 | bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 260 seconds) | |
| 05:05 | bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132) | |
| 06:18 | bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 258 seconds) | |
| 06:51 | bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132) | |
| 08:03 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 09:16 | Statler has joined IRC (Statler!~Georg@mail.lohn24.de) | |
| 09:57 | markus_e92 has left IRC (markus_e92!~markus_e9@62-46-29-32.adsl.highway.telekom.at, Ping timeout: 258 seconds) | |
| 09:59 | markus_e92 has joined IRC (markus_e92!~markus_e9@62-46-97-71.adsl.highway.telekom.at) | |
| 11:53 | lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18) | |
| 11:56 | lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection) | |
| 12:19 | lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18) | |
| 12:38 | lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection) | |
| 12:42 | markus_e92 has left IRC (markus_e92!~markus_e9@62-46-97-71.adsl.highway.telekom.at, Ping timeout: 268 seconds) | |
| 12:45 | markus_e92 has joined IRC (markus_e92!~markus_e9@91-115-159-161.adsl.highway.telekom.at) | |
| 12:52 | markus_e92 has left IRC (markus_e92!~markus_e9@91-115-159-161.adsl.highway.telekom.at, Ping timeout: 252 seconds) | |
| 12:54 | markus_e92 has joined IRC (markus_e92!~markus_e9@62-46-24-107.adsl.highway.telekom.at) | |
| 13:10 | cliebow has joined IRC (cliebow!~Adium@Ubiquiti.sumner.k12.me.us) | |
| 13:15 | lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18) | |
| 13:16 | lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Client Quit) | |
| 13:17 | lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18) | |
| 13:18 | lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18) | |
| 14:20 | bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 258 seconds) | |
| 14:26 | bennabiy_ has joined IRC (bennabiy_!~bennabiy@97.89.236.39) | |
| 14:30 | bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132) | |
| 14:51 | <sbalneav> Morning all
| |
| 15:32 | <bennabiy> morning
| |
| 15:32 | But, probably not morning for alkisg ;)
| |
| 15:45 | <cliebow> Scottie!!!
| |
| 15:45 | <sbalneav> Morning bennabiy, cliebow
| |
| 15:46 | <bennabiy> I am about to head out for the day... will have to check back this afternoon
| |
| 15:48 | <sbalneav> Cheers
| |
| 16:24 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 16:27 | lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection) | |
| 16:34 | <sbalneav> vagrantc: Check out the "remote" command I've added: now with autodetect of pulseaidio, espeaker, and TCP xserver
| |
| 16:34 | * vagrantc checks | |
| 16:37 | <vagrantc> sbalneav: looks reasonable
| |
| 16:37 | although i wonder if espeaker is even a thing anymore
| |
| 16:38 | <sbalneav> I've also sent off an email to the pam-python author about python3
| |
| 16:38 | <vagrantc> yay!
| |
| 16:38 | <sbalneav> vagrantc: Want me to remove it?
| |
| 16:38 | I just threw it in there for completeness
| |
| 16:39 | <vagrantc> sbalneav: in general, i think we should only add code that we're fairly confident we'll use
| |
| 16:39 | sbalneav: just to remove a lot of legacy cruft that built up over the years
| |
| 16:39 | <sbalneav> Sounds good, out it goes.
| |
| 16:42 | So rather than upload every time, I just create our little "script" on the server once in .local, and if it's already there, we just use it.
| |
| 16:43 | <vagrantc> it's a wrapper script?
| |
| 16:44 | is it really too expensive to regenerate it every time?
| |
| 16:45 | i can see advantages to just calling the remote script with ssh ...
| |
| 16:45 | but i also wondered if it wouldn't be more elegant to copy a script with all the arguments embedded in it...
| |
| 16:46 | and then execute it
| |
| 16:46 | <sbalneav> Well, it's the bit that decodes the args from base64 encode.
| |
| 16:46 | <vagrantc> actually, could you just stream python code over the wire and pipe to python?
| |
| 16:46 | <sbalneav> hm
| |
| 16:46 | that's an interesting idea
| |
| 16:46 | <vagrantc> sbalneav: if the args were embedded, you wouldn't even probably need to base64 them
| |
| 16:47 | sbalneav: as you'd remove the shell
| |
| 16:47 | <sbalneav> Lemme see if we can stream it, that'd be interesting
| |
| 16:47 | JerryT has joined IRC (JerryT!~jerry@wsip-70-165-106-163.om.om.cox.net) | |
| 16:47 | <vagrantc> then it avoids having to copy anything :)
| |
| 16:49 | echo 'print(1 + 1)' | python3
| |
| 16:49 | that seems to work
| |
| 16:49 | lucascastro has joined IRC (lucascastro!~lucas@186.227.185.10) | |
| 16:50 | <sbalneav> eugh, no that ain't gonna work.
| |
| 16:50 | Because then, we have to escape the python strings.
| |
| 16:50 | What if we're trying to open a file called "Bob's picture.jpg"
| |
| 16:51 | <vagrantc> hm.
| |
| 16:51 | <sbalneav> See, that's why I base64 encode the arguments :D
| |
| 16:51 | I avoid all that nonsense :D
| |
| 16:51 | <vagrantc> well, echo obviosuly wouldn't work ...
| |
| 16:51 | well, you could still base64 the code
| |
| 16:52 | <sbalneav> hmm, yeah
| |
| 16:52 | <vagrantc> python -c 'bse64foomagic' | python3
| |
| 16:52 | <sbalneav> lemme diddle with it a bit.
| |
| 16:52 | see if I can get something working
| |
| 16:53 | <vagrantc> sbalneav: you're a champ to entrtain all my wild ideas :)
| |
| 16:53 | <sbalneav> Well, if we can avoid copying files, and just do it over a pipe... that's obviously "better"
| |
| 16:53 | <vagrantc> just depends on how ugly the code gets
| |
| 16:54 | <sbalneav> Well, in THEORY, it should be less ugly.
| |
| 16:55 | Since we eliminate all the create-temp-dir-and-copy-script nonsense.
| |
| 16:58 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 17:31 | <sbalneav> LOL
| |
| 17:31 | got it to work
| |
| 17:31 | saweeet
| |
| 17:31 | no file to copy
| |
| 17:31 | <jammcq> wooo hoooooo
| |
| 17:43 | <sbalneav> lulz
| |
| 17:43 | this is awesome
| |
| 17:44 | Hey jammcq
| |
| 17:51 | I honestly can't believe this works :D
| |
| 18:08 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 18:14 | <vagrantc> sbalneav: looks like you've implemented the pipe to python3? :)
| |
| 18:15 | src/usr/share/ltsp-pam/remote | 67 ++++++++++++++++---------------------------------------------------
| |
| 18:15 | 1 file changed, 16 insertions(+), 51 deletions(-)
| |
| 18:15 | not bad :)
| |
| 18:23 | lucascastro has left IRC (lucascastro!~lucas@186.227.185.10, Remote host closed the connection) | |
| 18:34 | cliebow has left IRC (cliebow!~Adium@Ubiquiti.sumner.k12.me.us) | |
| 18:42 | <gehidore> that looks like a good cleanup :D
| |
| 18:53 | <sbalneav> vagrantc: Yeah, can't believe it worked.
| |
| 18:54 | I should probably do a bit more error checking.
| |
| 18:54 | <vagrantc> i've had worse ideas that worked out ok
| |
| 18:54 | <sbalneav> Yeah, that worked brilliantly
| |
| 18:55 | <vagrantc> sbalneav: admittedly, i'm not quite sure i understand what's going on in the new code :)
| |
| 18:56 | <sbalneav> We just convert the commandline we're passed into base65
| |
| 18:56 | *64
| |
| 18:56 | <vagrantc> ah, the key is: child = Popen(argv, stdout=PIPE, stdin=PIPE, shell=False)
| |
| 18:56 | childdata = child.communicate(input=script.encode('UTF-8'))[0]
| |
| 18:56 | <sbalneav> bingo
| |
| 18:56 | <vagrantc> i missed the child.communicate bit
| |
| 18:57 | so you create a "pipe" object, and then send it the script data?
| |
| 18:57 | <sbalneav> yeah
| |
| 18:57 | So, if you say "remote artril foo.pdf"
| |
| 18:57 | the remote script that gets piped is:
| |
| 18:57 | from base64 import urlsafe_b64decode
| |
| 18:57 | import subprocess
| |
| 18:57 | argv = (b'YXRyaWw=', b'Zm9vLnBkZg==')
| |
| 18:57 | newargv = [urlsafe_b64decode(a) for a in argv]
| |
| 18:58 | subprocess.call(newargv, shell=False)
| |
| 18:58 | with the argv being the bas64 encoding of "atril" and "foo.pdf"
| |
| 18:58 | <vagrantc> and there's no cleanup necesary, cuz it's never written anywhere?
| |
| 18:58 | <sbalneav> nope.
| |
| 18:58 | Nothing written.
| |
| 18:58 | sweet, no?
| |
| 18:58 | <vagrantc> sounds good!
| |
| 18:59 | <sbalneav> And with the base64 encode, we avoid all the escaping woes.
| |
| 18:59 | <vagrantc> relies on python3 being installed on the server in path, basically
| |
| 18:59 | <sbalneav> basically
| |
| 18:59 | I could exec "/usr/bin/env python3" if that would be better
| |
| 19:00 | <vagrantc> is the DISPLAY necessary to set? wouldn't that already by set on the initial ssh connection?
| |
| 19:00 | <sbalneav> and, of course, if you've got X over tcp enabled, or the pulse server enabled, it sets the environment variables needed for the python3 command.
| |
| 19:00 | <vagrantc> sbalneav: assumine /usr/bin/env is installed in the same path everywhere... which i bet it isn't.
| |
| 19:00 | <sbalneav> No, because ssh will always set display=localhost:blah
| |
| 19:01 | I think it is. /usr/bin/env is mandated, iirc
| |
| 19:01 | exactly for this reason.
| |
| 19:01 | <vagrantc> sbalneav: ah, so you're not doing remote encrypted X? basically just LDM_DIRECTX ?
| |
| 19:01 | <sbalneav> Well, ONLY if tcp X is enabled.
| |
| 19:01 | <vagrantc> mandated by someone nobody listens to, i fear :/
| |
| 19:02 | aha!
| |
| 19:02 | <sbalneav> If it ISN'T, then the display is't overwritten
| |
| 19:02 | and it goes over the ssh tunnel
| |
| 19:02 | <vagrantc> and it uses whatever is already there... e.g. ssh tunnel
| |
| 19:02 | <sbalneav> right
| |
| 19:03 | <vagrantc> ok, so i should give this a spin and see what happens
| |
| 19:03 | <sbalneav> yes.
| |
| 19:03 | <vagrantc> sbalneav: import tempfile no longer needed, eh? :)
| |
| 19:03 | <sbalneav> Oh, do I still have it there? Yes, no longer needed.
| |
| 19:03 | <vagrantc> i could commit it just to get my hands dirty :)
| |
| 19:04 | <sbalneav> I'll remove it.
| |
| 19:04 | Sure, you do it.
| |
| 19:04 | <vagrantc> just to prove i was paying attention
| |
| 19:04 | <sbalneav> kek
| |
| 19:07 | <vagrantc> this seems like it would be generally useful ... although currently needs PAM_SSHAUTH* variables
| |
| 19:10 | <sbalneav> pull again
| |
| 19:10 | I simplified a bit more
| |
| 19:11 | <vagrantc> yay!
| |
| 19:11 | <sbalneav> "Every line of code I remove is a line I don't have to debug" :D
| |
| 19:14 | <vagrantc> does only importing part of base64 require the same amount of resources
| |
| 19:14 | granted, we're probably talking about a tiny amount of code...
| |
| 19:16 | probably really splitting hairs at that point
| |
| 19:18 | <sbalneav> Is that working?
| |
| 19:19 | * vagrantc builds and tests | |
| 19:21 | <vagrantc> oh, i can just copy this over to test
| |
| 19:21 | <sbalneav> I'm not even sure we need the urlsafe_ bit.... lemme check
| |
| 19:21 | <vagrantc> yeah, i was thinking urlsae wouldn't be needed if we're doing a pipe
| |
| 19:22 | <sbalneav> yeah, lemme fix
| |
| 19:22 | * vagrantc will monkey-patch what's there to test, since it's only a single file | |
| 19:23 | <sbalneav> pushed
| |
| 19:25 | So, opening:
| |
| 19:25 | remote atril Documents/Dauphin_Office_wiring_memo_July_2016.pdf
| |
| 19:25 | results in a script submitted to python 3 over the ssh tunnel of:
| |
| 19:25 | import base64
| |
| 19:25 | import subprocess
| |
| 19:25 | subprocess.call([base64.b64decode(a) for a in (b'YXRyaWw=', b'RG9jdW1lbnRzL0RhdXBoaW5fT2ZmaWNlX3dpcmluZ19tZW1vX0p1bHlfMjAxNi5wZGY=')])
| |
| 19:27 | neat
| |
| 19:27 | <vagrantc> from subprocess import call ; from base64 import b64decode ; call([b64decode(a) ...
| |
| 19:27 | would that work?
| |
| 19:28 | it'd make for a shorter line, final line at the expense of slightly longer import statements
| |
| 19:29 | <sbalneav> Here's my theory:
| |
| 19:29 | I do that to make lines fit into 80 chars
| |
| 19:30 | Since the final line already fits into 80 chars, I eliminate two "from" keywords.
| |
| 19:30 | <vagrantc> ./remote firefox
| |
| 19:30 | <sbalneav> Works?
| |
| 19:30 | <vagrantc> Error: no display specified
| |
| 19:30 | <sbalneav> hm
| |
| 19:31 | oh
| |
| 19:31 | I wonder if I have to make sure to specify "-Y" on the command line for X.
| |
| 19:31 | one sec...
| |
| 19:31 | <vagrantc> i suspect so
| |
| 19:32 | <sbalneav> try that push
| |
| 19:32 | I might have "X11 forwarding = yes" in my ssh config
| |
| 19:33 | <vagrantc> yup
| |
| 19:33 | that works
| |
| 19:34 | <sbalneav> perfect
| |
| 19:34 | <vagrantc> at least with ./remote firefox and ./remote xterm
| |
| 19:34 | now, on to arguments!
| |
| 19:34 | <sbalneav> Try a "firefox http://ltsp.org"
| |
| 19:35 | <vagrantc> atril worked with a .pdf passed
| |
| 19:35 | <sbalneav> It's almost like I know what I'm doing. Almost :D
| |
| 19:35 | <vagrantc> ok, found one interesting quirk
| |
| 19:36 | if you ctrl-c the remote process, it doesn't kill the application at the other end and traebacks
| |
| 19:36 | <sbalneav> Yeah, that's something we'll need to fix.
| |
| 19:36 | I'll
| |
| 19:36 | One sec, I think I know how
| |
| 19:37 | <vagrantc> probably for stuff started from the menu, that wouldn't matter
| |
| 19:38 | so, the only things i can think of to test are filenames with spaces, and arguments with unicode characters
| |
| 19:39 | Statler has left IRC (Statler!~Georg@mail.lohn24.de, Remote host closed the connection) | |
| 19:39 | <vagrantc> spaces works like a charm
| |
| 19:40 | * sbalneav crosses fingers for unicode | |
| 19:43 | <vagrantc> date >> ☃
| |
| 19:43 | ./remote leafpad ☃
| |
| 19:43 | works!
| |
| 19:43 | <sbalneav> yay for bas64encode
| |
| 19:44 | My true genius is revealed
| |
| 19:44 | <vagrantc> it's really helpful doing ltsp-pnp style ... because i can tab-complete all the applications and know there there on the server as well as the user's homedir
| |
| 19:44 | er, as well as edit files in the user's homedir
| |
| 19:45 | <sbalneav> Well there we go, another piece of the puzzle fits into place, rather elegantly
| |
| 19:45 | <vagrantc> this could get addictive
| |
| 19:45 | <sbalneav> If I weren't at work, I'd crack a beer.
| |
| 19:47 | <vagrantc> so, to implement thin clients ... could we just run remoteapp your-deskto-of-choice ?
| |
| 19:47 | i mean, it'll have some problems, for sure
| |
| 19:47 | my first fat client implementation was running localapp desktop-foo
| |
| 19:47 | we've come full circle
| |
| 19:47 | <sbalneav> Pretty much, yeah
| |
| 19:49 | <vagrantc> so lightdm only remembers the last desktop chosen
| |
| 19:49 | or it uses the default, which sometimes, at least on ebian, picks strange defaults
| |
| 19:50 | we can't do what we did for ldm, parsing ~/.dmrc, since the ssh connection happens after the display manager has already chosen the desktop
| |
| 19:51 | <sbalneav> hm
| |
| 19:52 | What if we, instead of executing the session script in session, executed it as part of the auth process?
| |
| 19:52 | <vagrantc> https://bugs.launchpad.net/ltsp/?field.tag=ltsp6
| |
| 19:52 | yay for URL hacks
| |
| 19:52 | !ltsp6
| |
| 19:52 | <ltsp> ltsp6: See: !future
| |
| 19:52 | <vagrantc> !future
| |
| 19:52 | <ltsp> future: Some of the highlights include working towards obsoleting LDM (using libpam-sshauth/libnss-sshsock), moving stuff out of ltsp-build-client into initramfs run-time modifications, and making it possible to maintain the chroot from a booted environment
| |
| 19:53 | <vagrantc> learn ltsp6 as https://bugs.launchpad.net/ltsp/?field.tag=ltsp6
| |
| 19:53 | sbalneav: maybe i'm not understanding the phases of pam auth well ...
| |
| 19:54 | sbalneav: that sounds like it could lead to bizarre bugs, though ... doing things so differently from the typical display manager process
| |
| 19:54 | <sbalneav> I'd have to test.
| |
| 19:54 | <vagrantc> i would put session selection pretty low on the list, personally
| |
| 19:55 | which is why i started looking at bugs
| |
| 19:55 | gp has joined IRC (gp!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net) | |
| 19:55 | <sbalneav> https://bugs.launchpad.net/ltsp/+bug/1653150
| |
| 19:55 | Can we close that one now? :D
| |
| 19:55 | <vagrantc> you read my mind :)
| |
| 19:55 | i'd say so
| |
| 19:56 | i'd link to the latest git commit
| |
| 19:56 | <sbalneav> Should I move that "remote" command in the source tree to usr/bin/remoteapp?
| |
| 19:56 | <vagrantc> sbalneav: you want the honors, or should i?
| |
| 19:56 | <sbalneav> I'll do it,
| |
| 19:56 | but should we move that first?
| |
| 19:57 | <vagrantc> sbalneav: not sure on the name ... it's a bit too generic ...
| |
| 19:57 | but it's also pretty generic functionality
| |
| 19:58 | <sbalneav> I'll take any name you suggest :D
| |
| 19:58 | * vagrantc does some searches on sources.debian.net | |
| 19:58 | <vagrantc> it's arguably no longer ltsp specific?
| |
| 19:59 | <sbalneav> vaguely arguably
| |
| 19:59 | <vagrantc> ltsp5 has ltsp-remoteapps
| |
| 19:59 | <sbalneav> i'd say it's more tightly ltsp-coupled than pam-sshauth
| |
| 19:59 | ltsp6-remoteapps
| |
| 19:59 | <vagrantc> ltsp6-remoteapp, ltsp-remoteapp
| |
| 19:59 | <sbalneav> ltsp6-remoteapp is my vote
| |
| 20:00 | <vagrantc> we can always rename it later
| |
| 20:00 | <sbalneav> ok, I'll move it to usr/bin/ltsp6-remoteapp
| |
| 20:01 | <vagrantc> uh-oh... what if we suddently release ltsp7 ? :)
| |
| 20:01 | no, no, for now, let's stick with ltsp6-remoteapp :)
| |
| 20:02 | looking pretty.
| |
| 20:03 | <sbalneav> um, I'm not sure how to link the commit. I'll let you close it :D
| |
| 20:04 | <vagrantc> oh, i'd just past the url to the commit into the commit message
| |
| 20:04 | er, the close message
| |
| 20:04 | <sbalneav> oh, ok
| |
| 20:06 | <vagrantc> or whatever
| |
| 20:06 | <sbalneav> ok, changed status to "fix committed"
| |
| 20:06 | * vagrantc stumbles trhough launchpad every time | |
| 20:06 | <vagrantc> yay!
| |
| 20:08 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 20:09 | <sbalneav> https://bugs.launchpad.net/ltsp/+bug/1653147
| |
| 20:09 | See my comment.
| |
| 20:09 | Problem is, user geometry simply doesn't exist on the thin client until the user has logged in.
| |
| 20:13 | <vagrantc> so some things work without the user geometry and others don't ?
| |
| 20:13 | <sbalneav> Well, su is going to require that the user actually be in /etc/passwd, etc.
| |
| 20:13 | <vagrantc> given that it works for console, lightdm (hopefully *dm), and several screensavers, we can consider it a wishlist bug, probably.
| |
| 20:13 | <sbalneav> until they are, they're literally a non-existant user on the thin client.
| |
| 20:14 | <vagrantc> or even wontfix or whatever it's called
| |
| 20:14 | <sbalneav> Well, it's easily fixed; just don't use the ssh authentication method and switch to ldap.
| |
| 20:14 | We use the ssh+extrausers because it's simple to set up for an admin:
| |
| 20:15 | they just adduser <user> on the server, and then the user can log in on a thin client, so long as the admin has the sshd running on the server
| |
| 20:16 | ldap's the "next level", which requires far more admin know-how.
| |
| 20:16 | <vagrantc> right, but we hopefully won't get in the way of using ldap and such
| |
| 20:16 | <sbalneav> no, that's the whole point here. We're trying to set up something that will work with ldap
| |
| 20:16 | <vagrantc> right :)
| |
| 20:17 | <sbalneav> that's why I implement "try_first_pass" functionality.
| |
| 20:17 | so in your pam stack:
| |
| 20:17 | auth requred ldap.so .....
| |
| 20:17 | auth required pam_python.so pam_sshauth.py try_first_pass ....
| |
| 20:17 | The ldap module will do the authentication
| |
| 20:18 | the pam_sshauth module will then use the PAM_AUTHTOK to plumb the tunnel for you
| |
| 20:19 | The other way to do it (and the way *I* would do it) is just to implement ldap on the SERVER
| |
| 20:19 | and then just use the ssh authenticator to do everytiong on the client
| |
| 20:19 | and put up with "su" not working on a console until the user logs in.
| |
| 20:19 | <vagrantc> right
| |
| 20:20 | <sbalneav> tl;dr: we gots the flexibilty
| |
| 20:20 | <vagrantc> do more with less!
| |
| 20:21 | <sbalneav> yadda yadda
| |
| 20:21 | With the bits we have here now, we can support:
| |
| 20:21 | 1) Full fat client (all apps on thin client)
| |
| 20:21 | 2) Mixed mode (some apps on client, some on server)
| |
| 20:22 | 3) full thin client (just no support for usb sticks or whatever)
| |
| 20:22 | <vagrantc> i've pretty much given up on full thin client for now
| |
| 20:22 | but i know it's partly there
| |
| 20:23 | <sbalneav> Well, here's the thing, I'd say if we were going to try to support usb storage devices on thin client mode, we'd be better off to try and get:
| |
| 20:23 | http://usbip.sourceforge.net/
| |
| 20:23 | <vagrantc> for now, i'd be fine saying goodbye to thin clients
| |
| 20:24 | <sbalneav> Well, all we'd need to do is just say "If you run thin client, you can have sound, but no usb sticks"
| |
| 20:24 | That would be the only loss.
| |
| 20:24 | <vagrantc> i think session logout had some issues
| |
| 20:25 | <sbalneav> That can be fixed pretty easy, I'd expect.
| |
| 20:25 | So, really, the only real piece left we need to solve is the "ltspd" bit
| |
| 20:26 | Once alkisg is back at school and finds the bit that he's already partially done, we can finish that off.
| |
| 20:26 | <vagrantc> the ltspd thing was really numerous different ideas all wrapped up in one
| |
| 20:27 | the major pieces i recall off the top of my head are a) something to replace lts.conf and b) something to provide custom boot code/policy
| |
| 20:27 | <sbalneav> This is really starting to turn into something here.
| |
| 20:27 | <vagrantc> it really is!
| |
| 20:28 | i think the hanging on logout basically needs something like "kill $PPID"
| |
| 20:30 | <sbalneav> A quick count indicates we've got a large part of LTSP6 written in <700 lines of code.
| |
| 20:30 | <vagrantc> it's really cool to be able to debug on the console without having to do any setup
| |
| 20:30 | e.g. log in as a typical user
| |
| 20:31 | <sbalneav> yeah
| |
| 20:31 | that's kind of nice.
| |
| 20:31 | <vagrantc> tus
| |
| 20:31 | gah
| |
| 20:31 | the whole "SCREEN_02=shell" thing that people forget to turn off ... always made me nervous
| |
| 20:32 | or setting up accounts in the chroot, or setting a root password
| |
| 20:32 | <sbalneav> yeah, all that goes away
| |
| 20:32 | In a nice, neat manner
| |
| 20:33 | * vagrantc wonders if anyone would be able to do a security audit | |
| 20:34 | <vagrantc> we've certainly started mucking around with authentication internals ... although it certainly can't be any worse than what we used to do with sed on /etc/passwd
| |
| 20:34 | and arguably considerably better
| |
| 20:34 | <sbalneav> Yeah, I'd argue better. Now we're doing things "properly"
| |
| 20:34 | <vagrantc> ldm_password_hash and all that ... which was a good workaround for what it is, but still not ideal
| |
| 20:35 | * vagrantc sprinkles some seasonings on propriety | |
| 20:36 | <vagrantc> so, shutting the system down... not a good idea
| |
| 20:36 | er, killing the ssh process before hte homedir is unmounted, at least
| |
| 20:36 | deadlock
| |
| 20:37 | fuse and/or linux gets a little touchy about inaccessible filesystems
| |
| 20:37 | gp has left IRC (gp!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net, Quit: Leaving) | |
| 20:37 | <sbalneav> Well, that would have been the case before, anyway.
| |
| 20:38 | <vagrantc> sure
| |
| 20:39 | <sbalneav> I should probably make sure I start the tunnel with some kind of keepalive going, as well
| |
| 20:40 | -o ServerAliveInterval=120 or something
| |
| 20:48 | vagrantc: See latest commit
| |
| 20:49 | That should ensure that the ssh tunnel doesn't time out, and yank the sshfs out from underneath us.
| |
| 20:51 | ls
| |
| 20:51 | <jammcq> du
| |
| 20:52 | <sbalneav> rm -rf /
| |
| 20:53 | dd if=/dev/random of=/dev/hda bs=1024K
| |
| 20:59 | !ltsp6
| |
| 20:59 | <ltsp> ltsp6: See: !future
| |
| 20:59 | <sbalneav> !future
| |
| 20:59 | <ltsp> future: Some of the highlights include working towards obsoleting LDM (using libpam-sshauth/libnss-sshsock), moving stuff out of ltsp-build-client into initramfs run-time modifications, and making it possible to maintain the chroot from a booted environment
| |
| 21:00 | <sbalneav> !learn ltsp6bugs as https://bugs.launchpad.net/ltsp/?field.tag=ltsp6
| |
| 21:00 | <ltsp> The operation succeeded.
| |
| 21:00 | <sbalneav> !ltsp6bugs
| |
| 21:00 | <ltsp> ltsp6bugs: https://bugs.launchpad.net/ltsp/?field.tag=ltsp6
| |
| 21:01 | <vagrantc> huh
| |
| 21:01 | we should kill off future and fix ltsp6
| |
| 21:02 | ltsp: learn ltsp6 as https://bugs.launchpad.net/ltsp/?field.tag=ltsp6
| |
| 21:02 | 1learn ltsp6 as https://bugs.launchpad.net/ltsp/?field.tag=ltsp6
| |
| 21:02 | !learn ltsp6 as https://bugs.launchpad.net/ltsp/?field.tag=ltsp6
| |
| 21:02 | <ltsp> The operation succeeded.
| |
| 21:02 | <vagrantc> !ltsp6
| |
| 21:02 | <ltsp> ltsp6: (#1) See: !future, or (#2) https://bugs.launchpad.net/ltsp/?field.tag=ltsp6
| |
| 21:02 | <vagrantc> !forget ltsp6 #1
| |
| 21:02 | <ltsp> Error: There is no such factoid.
| |
| 21:02 | <vagrantc> !forget ltsp6 1
| |
| 21:02 | <ltsp> The operation succeeded.
| |
| 21:02 | <vagrantc> !ltsp6
| |
| 21:02 | <ltsp> ltsp6: https://bugs.launchpad.net/ltsp/?field.tag=ltsp6
| |
| 21:03 | <sbalneav> !learn future as The Future is Now! See https://launchpad.net/~ltsp-upstream/+git/
| |
| 21:03 | <ltsp> The operation succeeded.
| |
| 21:03 | <sbalneav> kek
| |
| 21:03 | <vagrantc> !learn ltsp6 as wiki.ltsp.org/wiki/Dev:LTSPPamNotes
| |
| 21:03 | <ltsp> The operation succeeded.
| |
| 21:03 | <vagrantc> !ltsp6
| |
| 21:03 | <ltsp> ltsp6: (#1) https://bugs.launchpad.net/ltsp/?field.tag=ltsp6, or (#2) wiki.ltsp.org/wiki/Dev:LTSPPamNotes
| |
| 21:03 | <vagrantc> !future
| |
| 21:03 | <ltsp> future: (#1) Some of the highlights include working towards obsoleting LDM (using libpam-sshauth/libnss-sshsock), moving stuff out of ltsp-build-client into initramfs run-time modifications, and making it possible to maintain the chroot from a booted environment, or (#2) The Future is Now! See https://launchpad.net/~ltsp-upstream/+git/
| |
| 21:04 | <sbalneav> The one thing we need to be able to continue to support is chroot as i386 and server as amd64, since that's my use case for the forseeable future :D
| |
| 21:04 | forum has joined IRC (forum!~Icedove@192-164-128-103.hdsl.highway.telekom.at) | |
| 21:05 | <jammcq> sbalneav: are your workstations not 64-bit ?
| |
| 21:05 | <vagrantc> we've already done the ltsp-build-client -> initramfs stuff
| |
| 21:05 | !forget future 1
| |
| 21:05 | <ltsp> The operation succeeded.
| |
| 21:05 | <vagrantc> some futures are harder to forget, apparently
| |
| 21:05 | sbalneav: yeah, i don't think it'll be hard to do
| |
| 21:05 | <sbalneav> No, the ones we have from Ron are i386
| |
| 21:06 | <vagrantc> sbalneav: https://bugs.launchpad.net/ltsp/+bug/1653151
| |
| 21:06 | <jammcq> whoa!!!!
| |
| 21:06 | <sbalneav> !future
| |
| 21:06 | <ltsp> future: The Future is Now! See https://launchpad.net/~ltsp-upstream/+git/
| |
| 21:06 | <sbalneav> tee hee
| |
| 21:07 | <vagrantc> alkisg also had ideas that go so far as to get rid of ltsp code in the chroot/image entirely and instantiating it from initramfs
| |
| 21:07 | or something like that
| |
| 21:08 | that was one idea, ltspd can just append stuff into the initramfs that then gets executed at boot ... can even use a clean live-image or something
| |
| 21:08 | <sbalneav> jammcq: model name: Intel(R) Atom(TM) CPU D2550 @ 1.86GHz
| |
| 21:08 | address sizes: 36 bits physical, 32 bits virtual
| |
| 21:09 | Tombo1001 has joined IRC (Tombo1001!~dev@90.210.116.48) | |
| 21:09 | <sbalneav> well, there's certainly a lot less stuff needed now.
| |
| 21:10 | <vagrantc> we've basically implemented all that ancient stuff in !future
| |
| 21:10 | forum has left IRC (forum!~Icedove@192-164-128-103.hdsl.highway.telekom.at, Quit: forum) | |
| 21:11 | <vagrantc> well, the old future
| |
| 21:11 | welcome to the new future
| |
| 21:12 | vagrantc_ has joined IRC (vagrantc_!~vagrant@unaffiliated/vagrantc) | |
| 21:13 | * vagrantc_ ☃ wired networking | |
| 21:15 | <vagrantc_> sbalneav: regarding chroots, i think we'll be able to do ltsp-update-image on a chroot like always
| |
| 21:15 | <sbalneav> yeah
| |
| 21:15 | <jammcq> sbalneav: https://en.wikipedia.org/wiki/Intel_Atom
| |
| 21:16 | <vagrantc_> unfortunately, NFS has been rather unreliable with overlay FS in recent times, so i don't expect to be able to use that
| |
| 21:16 | <jammcq> shows 'Intel 64 if enabled' for the D2550
| |
| 21:16 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 256 seconds) | |
| 21:16 | vagrantc_ is now known as vagrantc | |
| 21:16 | <sbalneav> hm
| |
| 21:16 | <vagrantc> not sure how much of ltsp-update-image we might want to rewrite
| |
| 21:16 | <sbalneav> something in the bios?!
| |
| 21:16 | bbi one sec
| |
| 21:17 | <vagrantc> sometimes you can have the bios do things like disable features that the hardware is otherwise capable of and provide no way to enable it
| |
| 21:17 | <jammcq> it may depend on the bios and other chips
| |
| 21:19 | address sizes: 40 bits physical, 48 bits virtual
| |
| 21:19 | that's my desktop with a xeon that is definately 64-bit
| |
| 21:21 | <sbalneav> Yeah, there's nothing in the bios to enable 64 bit mode.
| |
| 21:21 | Wonder if it's a jumper on the mobo or something.
| |
| 21:21 | Meh, figure it out later :D
| |
| 21:22 | <jammcq> yeah, it's probably permenantly lame
| |
| 21:22 | Tombo1001 has left IRC (Tombo1001!~dev@90.210.116.48, Quit: rm -rf MyPresence) | |
| 21:25 | <sbalneav> Kind of like me ;)
| |
| 21:59 | zamba has left IRC (zamba!marius@flage.org, Ping timeout: 252 seconds) | |
| 22:27 | <vagrantc> sbalneav: just pushed a minor patch that uses "from X import Y" since we were importing two modules and two functions... makes the code look more readable to me, at least. :)
| |
| 22:27 | not that it was bad
| |
| 22:28 | * vagrantc wonders about generating the example.conf from the code somehow | |
| 22:29 | <vagrantc> to not have to edit in both places...
| |
| 23:00 | JerryT has left IRC (JerryT!~jerry@wsip-70-165-106-163.om.om.cox.net, Remote host closed the connection) | |
| 23:29 | gp has joined IRC (gp!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net) | |