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


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

00:58bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 252 seconds)
01:01bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132)
01:18vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
01:28bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 245 seconds)
01:30bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132)
02:18bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 248 seconds)
02:20bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132)
02:28bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 258 seconds)
02:30bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132)
03:05GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Remote host closed the connection)
03:09lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18)
03:12lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection)
03:13lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18)
03:39lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection)
04:27bennabiy_ has joined IRC (bennabiy_!~bennabiy@97.89.236.39)
05:04bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 260 seconds)
05:05bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132)
06:18bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 258 seconds)
06:51bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132)
08:03ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
09:16Statler has joined IRC (Statler!~Georg@mail.lohn24.de)
09:57markus_e92 has left IRC (markus_e92!~markus_e9@62-46-29-32.adsl.highway.telekom.at, Ping timeout: 258 seconds)
09:59markus_e92 has joined IRC (markus_e92!~markus_e9@62-46-97-71.adsl.highway.telekom.at)
11:53lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18)
11:56lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection)
12:19lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18)
12:38lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection)
12:42markus_e92 has left IRC (markus_e92!~markus_e9@62-46-97-71.adsl.highway.telekom.at, Ping timeout: 268 seconds)
12:45markus_e92 has joined IRC (markus_e92!~markus_e9@91-115-159-161.adsl.highway.telekom.at)
12:52markus_e92 has left IRC (markus_e92!~markus_e9@91-115-159-161.adsl.highway.telekom.at, Ping timeout: 252 seconds)
12:54markus_e92 has joined IRC (markus_e92!~markus_e9@62-46-24-107.adsl.highway.telekom.at)
13:10cliebow has joined IRC (cliebow!~Adium@Ubiquiti.sumner.k12.me.us)
13:15lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18)
13:16lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Client Quit)
13:17lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18)
13:18lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18)
14:20bitchecker has left IRC (bitchecker!~bitchecke@31.131.20.132, Ping timeout: 258 seconds)
14:26bennabiy_ has joined IRC (bennabiy_!~bennabiy@97.89.236.39)
14:30bitchecker 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:24vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:27lucascastro 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:47JerryT 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:49lucascastro 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:58vagrantc 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:08vagrantc 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:23lucascastro has left IRC (lucascastro!~lucas@186.227.185.10, Remote host closed the connection)
18:34cliebow 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:39Statler 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:55gp 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:08ricotz 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:37gp 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:04forum 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:09Tombo1001 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:10forum 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:12vagrantc_ 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:16vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 256 seconds)
21:16vagrantc_ 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:22Tombo1001 has left IRC (Tombo1001!~dev@90.210.116.48, Quit: rm -rf MyPresence)
21:25
<sbalneav>
Kind of like me ;)
21:59zamba 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:00JerryT has left IRC (JerryT!~jerry@wsip-70-165-106-163.om.om.cox.net, Remote host closed the connection)
23:29gp has joined IRC (gp!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net)