|00:48||teknkik_ has joined IRC (email@example.com)|
|00:48||yanu_ has joined IRC (firstname.lastname@example.org)|
|00:49||teknkik has left IRC (email@example.com, Ping timeout: 248 seconds)|
|00:49||yanu has left IRC (firstname.lastname@example.org, Ping timeout: 248 seconds)|
|00:49||quinox has left IRC (email@example.com, Ping timeout: 248 seconds)|
|00:49||quinox has joined IRC (firstname.lastname@example.org)|
|01:18||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 264 seconds)|
|02:06||dtcrshr has left IRC (dtcrshr!~datacrush@unaffiliated/datacrusher, Ping timeout: 260 seconds)|
|02:10||dtcrshr has joined IRC (dtcrshr!~datacrush@unaffiliated/datacrusher)|
|05:16||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
|05:34||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
|05:56||ogra_ has left IRC (email@example.com, Remote host closed the connection)|
|05:56||ogra_ has joined IRC (firstname.lastname@example.org)|
|06:01||alkisg_away is now known as alkisg|
|06:01||ogra_ has left IRC (email@example.com, Ping timeout: 268 seconds)|
|06:01||ogra_ has joined IRC (firstname.lastname@example.org)|
|06:49||ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)|
|07:10||mikkel has joined IRC (email@example.com)|
|07:58||Vlad__ has joined IRC (Vlad__!c2e28421@gateway/web/freenode/ip.18.104.22.168)|
Hello, I'm trying to config iPXE with LTSP on Debian 7, it works, but clients do not want to use lts.conf; seems they can't download it
lts.conf is located in the default /srv/tftp/ltsp/i386, tftp-server is up and running
Vlad__: are you sure it doesn't have syntax errors? Can you put its contents to pastebin?
i just want to change color depth : [Default] X_COLOR_DEPTH=24
Is that on the same line?
Or in 2 lines?
it works with default pxe but not with iPXE
(on a thin client)
and paste the result here, when you boot it with ipxe
So that we see the exact command line that you use
init=/sbin/init-ltsp root=/dev/nbd0 nbdroot=192.168.25.1:/opt/ltsp/i386
OK, and: cat /var/cache/ltsp/net-*.conf
Put that one in pastebin
Actually, what's the ROOTPATH there?
The rest aren't important
Ah, and filename
So basically, what's the output of this command: grep -A1 ROOTPATH /var/cache/ltsp/net-*.conf
|08:29||kjackal has joined IRC (firstname.lastname@example.org)|
mmm... there are no such files in /var/cache/ltsp, only ltsp_config and ltsp_config_env, none of them have ROOTPATH
Vlad__: find /var -name 'net*.conf'
Maybe debian put it in run instead of cache
If you have *root* access to the client, you can also try this: sudo /usr/lib/klibc/bin/ipconfig -n eth0
This will ask for a fake ip lease, so that we can look at rootpath/filename from there
there is /run/net-eth0.conf with empty ROOTPATH=''
OK, so the client tries to get lts.conf from /srv/tftp/ipxe/lts.conf
Either symlink it there or change the filename that you send to ipxe
...to ipconfig,not to ipxe
Somewhere in your dhcpd.conf you have an "if" for the boot filename
There are 3 things that ask for the filename
PXE, iPXE, and Linux ipconfig in the initramfs
|08:36||PeperPots has left IRC (PeperPots!sid1218@gateway/web/irccloud.com/x-hpnzkgdlcnichswm, Ping timeout: 268 seconds)|
The last one should be pointed to lts.conf, not to "ipxe/undionly.kpxe"...
|08:36||riddle has left IRC (email@example.com, Ping timeout: 244 seconds)|
i made a symlink in ipxe folder and it works now
thanks a lot!
|08:38||Vlad__ has left IRC (Vlad__!c2e28421@gateway/web/freenode/ip.22.214.171.124)|
|08:38||riddle has joined IRC (firstname.lastname@example.org)|
|08:44||PeperPots has joined IRC (PeperPots!sid1218@gateway/web/irccloud.com/x-aodyqbphqxbtjpxm)|
|09:00||kjackal has left IRC (email@example.com, Remote host closed the connection)|
|09:02||kjackal has joined IRC (firstname.lastname@example.org)|
|09:03||NeonLicht has joined IRC (NeonLicht!~NeonLicht@darwin.ugr.es)|
|09:10||NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es)|
kvm: Virtual thin client: kvm -vga-vmware -ctrl-grab -no-shutdown -net nic,model=virtio -net user,tftp=/var/lib/tftpboot,bootfile=/ltsp/i386/pxelinux.0
I do not know about 'nbd-clients', but I do know about these similar topics: 'nbd-client'
client-list: to get a list of all nbd-clients (which sometimes is the same as ltsp clients), run: netstat -tn | sed -n 's/.*:10809 *\([0-9.]*\):.*/\1/p' | sort -Vu
|09:40||Sathya has joined IRC (Sathya!90313201@gateway/web/freenode/ip.126.96.36.199)|
I have a bunch of embedded systems
I need to connect to them via the internet
through different ports
But the same IP
I was just wondering if this is possible through LTSP?
LTSP is about netbooting linux systems
Not about connecting to them
Maybe you're interested in epoptes instead
epoptes: Epoptes is a computer lab administration and monitoring tool. It works on Ubuntu and Debian based labs with LTSP or non-LTSP servers, thin and fat clients, standalone workstations, NX clients etc. More info: http://www.epoptes.org
Will check that,
|09:44||robb_nl has joined IRC (email@example.com)|
|09:44||Sathya has left IRC (Sathya!90313201@gateway/web/freenode/ip.188.8.131.52, Client Quit)|
alkisg, actually, what he's interested in I think is setting ip_forward to 1
Or maybe I misunderstand
How's Greece today?
|12:14||kjackal has left IRC (firstname.lastname@example.org, Ping timeout: 244 seconds)|
|12:30||robb_nl has left IRC (email@example.com, Ping timeout: 240 seconds)|
|12:31||robb_nl has joined IRC (firstname.lastname@example.org)|
|12:38||robb_nl has left IRC (email@example.com, Ping timeout: 252 seconds)|
|12:44||Hyperbyt1 is now known as Hyperbyte|
|12:47||Faith has joined IRC (Faith!~paty_@unaffiliated/faith)|
|13:00||kjackal has joined IRC (kjackal!~kjackal@2a02:587:3110:5800:cca9:866f:3437:83c2)|
|13:00||kjackal has left IRC (kjackal!~kjackal@2a02:587:3110:5800:cca9:866f:3437:83c2, Remote host closed the connection)|
|13:00||kjackal has joined IRC (kjackal!~kjackal@2a02:587:3110:5800:cca9:866f:3437:83c2)|
|13:02||gvy has joined IRC (gvy!~mike@altlinux/developer/mike)|
|13:29||Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)|
|14:08||cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 252 seconds)|
|14:15||Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)|
|14:37||robb_nl has joined IRC (firstname.lastname@example.org)|
|14:48||mikkel has left IRC (email@example.com, Quit: Leaving)|
|14:56||ben_roose has joined IRC (firstname.lastname@example.org)|
|15:45||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
Hyperbyte: I thought he was interested to connect *from* the internet (e.g. his home), *to* the remote embedded systems, when they're all behind NAT. That could be done with one port forwarding per device on the router, or with reverse connections, like epoptes does.
Greece is fine, a bit of rain, a bit of sun... :)
Well. That's been a productive bit of hacking that will help LTSP
So, now you can do a:
(sleep 2; echo "password") | pty ssh user@host
|16:26||robb_nl has left IRC (email@example.com, Ping timeout: 252 seconds)|
Can't `ssh -tt` do that?
depends on how many -t arguments and the phases of the moon and the alignment of invisible forces
alkisg: No, ssh -tt will never read purely from stdin, it'll complain if it loses a controlling terminal
however, what this does is actually fork a pty, which becomes the child process' controlling terminal.
sbalneav: so, we don't need sleepy echo passwords ... how would you propose to use it?
well, here's what I want... I hate that right now, we're having to write the password out to a file in libpam-sshauth. It's gross. Especially since libpam_exec can expose the password via stdin.
So here's what I want to modify.
in libpam_sshauth, I'll add in the code to do a "id -u" and "id -t", and set a pam environment variable.
then in the libpam_exec, we can just do a (su - $uid pty ssh user@server <args>) once, get the password from stdin, and bingo, we've got our user-owned ssh in one call, rather than doing the two ssh's and saving the password like we do now.
ok, that sounds better in principle...
although knowing the right time to send the password to ssh seems ... tricky.
Well, the sleep thing's just a quicky. I'll script things so that I wait to see the ":" before sending the passwd
"please enter your authentication details which will be published in cleartext on the internet:"
like that? :)
CIA's already got your password anyway, so what's the big deal? :D
|16:40||robb_nl has joined IRC (firstname.lastname@example.org)|
I used that pty thing to write a pygtk password changer that's just a shell around the "passwd" program, that ALSO doesn't talk nicely to stdin/out.
I'll pop that up on github later today, too.
vagrantc: While I'm at it, would you be willing to sponsor two packages into debian sid? We're getting ready to release lightdm-webkit-greeter and lightdm-webkit2-greeter soon.
I've worked my *ss off for the last several months. The webkit greeters are currently the only ones in which it's possible to see all the pam messages in.
sbalneav: entirely different codebase for the two?
-webkit2's based off -webkit, but with lots of changes based on the different way webkit2 acts. But *functionally*, they do the same thing. Have all the same features.
I took over maintainership of -webkit, then I approached the -webkit2 port guys with my changes/fixes/improvements, and started syncing the two, function-wise.
|16:47||robb_nl has left IRC (email@example.com, Remote host closed the connection)|
I'd love to see 'em both make their way into debian proper. Into the next release would be awesome, but I don't know if it's too late for that or not.
it's pretty infeasible to integrate them into a single project with different build flags?
I'd say, yeah. webkit's a standalone program, -webkit2's a plugin
sbalneav: also, not sure what the lifespan of webkit vs. webkit2 is ... if it's deprecated, it might not be proper to push to debian
AFAIK, both are still supported; in Jessie, only webkit's available, the version of webkit2 in jessie is buggy.
but the webkit2 in sid works fine.
So if you only wanted to do that one, I'd be cool with it.
the idea is that, at some point, the -webkit one will just die on the vine as webkit reaches EOL, and webkit2'll be the go-forward one.
So if there's a chance for lightdm-webkit2-greeter to be in the next debian stable, then forget -webkit and just do the webkit2 one.
Personally, I'd like to see us use it for the big "lightdm" conversion; we can very easily theme an "ltsp" greeter, and we know we'll have the ability to see all the pam messages we may need to deal with when we eventially move to libpam-sshauth
sbalneav: not real familiar with webkit, so just brought up some of my quick thoughts on the matter
kind of kills the original goal of arbitrary display managers
but if it reduces how much code to maintain, it might still be a good thing
The problem with other pam-aware display managers is that they don't pass the password to the ssh-auth pam hooks?
No, they should all work fine... the issue is, lots of display managers and/or greeters do a *very* sloppy job of handling the full range of pam messages.
Here's the problem; for me, in a corporate environment, we have password strength checkers, password expiry, and we're using the ldap password policy thing to handle password history
so when your password expires, it's going to do LOTS of things, like tell you if a password you've typed is too short, a dictionary word, etc.
Ah, and the other display managers don't show the whole chat in their UI?
we're using pam-passwdqc, which spits out pam messages like this:
(current) LDAP Password:
You can now choose the new password or passphrase.
A valid password should be a mix of upper and lower case letters,
digits, and other characters. You can use a 9 character long
password with characters from at least 3 of these 4 classes, or
an 8 character long password containing characters from all the
classes. An upper case letter that begins the password and a
digit that ends it do not count towards the number of character
A passphrase should be of at least 3 words, 12 to 40 characters
long, and contain enough different characters.
Alternatively, if no one else can see your terminal now, you can
pick this as your password: "trace!rise!censor".
Enter new password:
lightdm-gtk-greeter has *one* status line for messages :D
so you don't see all of that help text.
And I think GDM just throws that stuff away entirely
Don't even get me started on kdm :D
So, in regular cases without ldap etc etc, the other display managers may also work fine with ssh-auth?
They all work in "simple" cases.
i.e. "enter your username, enter your password, thanks you're logged in"
That's much better, at first I was thinking they wouldn't work at all
It's just when you start wanting to do "complicated" things with pam, then the number of options goes *way* down, because lots of DM's just don't handle the full range of stuff that pam's capable of doing.
sbalneav: thanks for the extended explanation ... that's a lot clearer :)
sbalneav: have you thought about the hooks that ltsp will need from the DM or the PAM? Like all the ACTIONs in /usr/share/ldm/ldm-script? init/pressh/start/xsession/stop?
lightdm + webkit-greeter get's ALL the messages, and can handle them all. So, if you're looking for *one* DM + greeter combo that will absolutely, positively, work no matter HOW COMPLICATED your pam setup is... that's the one to use.
(err sorry, finish with the *but* first :))
alkisg: yeah, we'll have to cook that in somehow.
Got it, so ltsp could Recommend lightdm + webkit2, but also allow users to select other DMs if they want
I think it's all doable.
And all the broken parts of lightdm, like breaking the keyboard layout etc etc :D
ahhhh, but I'm now "in good with" lightdm's author, Robert Ancell
So if something's broken, let's fix it :D
That's a great asset :)
wow, there are a sea of libwebkit packages in debian
sbalneav: are you testing with the libwebkit*gtk*-dev packages?
looks like webkitgtk3 for lightdm-webkit-greeter
and webkit2gtk-4.0 for lightdm-webkit2-greeter
well, lightdm-webkit-greeter still seems to build with the packaging from when i last touched it in november
here's to properly done build systems.
Here's one of the key things I think we're missing that we'll need.
We want to be able to pass arbitrary data back and forth from the greeter to other parts of the pam stack; i.e. have a drop-down on the greeter page with a list of servers to log into, and then have that be able to be picked up elsewhere.
The way to do that is with pam environment variables; i.e. set a pam env variable at auth, that would be available later on.
lightdm currently doesn't have that, but I think I could add that easily to lightdm... I'll talk to Robert about it.
Maybe we could also do it the windows way, \\server\user, whenever there are multiple servers and the default isn't the one the user wants?
I.e. type the server as part of the username, not sure about the exact syntax there
Well, sure, but the issue is, there's no way to pass that "server" back up the pam stack to be used later on in the login process by the ltsp scripts
|17:36||aluno has joined IRC (aluno!b154a939@gateway/web/freenode/ip.184.108.40.206)|
within lightdm. But I could add that.
|17:37||aluno has left IRC (aluno!b154a939@gateway/web/freenode/ip.220.127.116.11, Client Quit)|
Maybe the local username can keep the "server" part in it
Imagine multiple logins, user@server1 and user@server2, simultaneously
...shouldn't those map to 2 different local users?
|17:40||cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)|
|17:40||gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)|
as the one who originally pushed for multiple login servers ... do we need to continue to support it?
I don't use it personally; but that don't mean bupkis :D
|17:47||* alkisg votes no... only with some automatic load-balancer script that rotates the "server" hostname|
and libpam-sshauth only provides one auth server currently, right?
Yes, but the auth is fast; presumably, once you've authed the session can be spawned anywhere.
hrm. lightdm-webkit2-greeter is failing to autogenerate it's makefiles
sbalneav: as in, authenticate on one server, and then sshfs mount the homdir (and/or log in to alternate server as a thin client) from an alternate server with the same credentials?
oh, maybe i need cmake?
Different servers might have different (or same) $HOME for the same user. A complete mess...
Multiple logins would only make sense with a different $HOME per user
|17:54||Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)|
multiple concurrent logins from the same machine seem like a nightmare, yes ...
but simply logging into different servers?
Personally I wouldn't want to ever have to work on DMs, greeters etc
So since they usually don't expose the server there, I'd prefer it if we either didn't support it at all, or with the \\server\user syntax
...i.e. anything that doesn't require us to touch DM/greeter code
I understand that maintaining our own greeter gives us a lot of flexibility, and I wouldn't mind defaulting to that, but I wouldn't want to _depend_ on that...
the \\server syntax is awful
sbalneav: i'm getting configure.ac:115: error: required file 'themes/antergos/css/vendor/Makefile.in' not found
alkisg@server2 might be a better syntax
sbalneav: any idea how that is supposed to be generated?
alkisg: breaks on systems that have @ in the username
I know exactly what that is.
He's got a git submodule in there for his antergos theme.
|17:59||* sbalneav whispers|
can we ditch that theme?
I want him to remove it, yes.
I'll talk to him about it.
any other submodules?
No, only that one.
i think i can just patch it out of themes/Makefile.am ?
Might need to touch configure.ac as well
Better option would be for upstream to make it a separate package
but in the meantime...
Sure, patch now, I'll wheedle in the meantime :D
huzzah! lightdm-webkit2-greeter built!
sbalneav: are the .la files needed at runtime, or can they be excluded?
Needed, i believe, due to webkit2's plugin nature.
So, on fat clients with ancient graphics cards, setting X_COLOR_DEPTH=16 makes things 3+ times faster, youtube watchable vs unwatchable etc
E.g. trident: 8bpp => 50 putimage/sec, 16bpp => 20 putimage/sec, 24 bpp => 6 putimage/sec
8bpp is crashing many apps, so 16bpp is the best option there
|19:22||* quinox will check that out|
http://www.inktechnologies.com/blog/wp-content/uploads/2011/04/Color-Depth.jpeg hardly noticeable
16bpp is usable as a color depth, sure. It's just strange that it makes such a big difference on fat clients graphics speed though.
its' 50% per bandwidth, and if that's all that's needed to saturate the link...
in the case of old graphics cards, the link is pci, and often RAM constrained
Back in 1995 I was doing graphics in assembly, it was easy to get 60fps etc. I can't understand how e.g. x11perf -putimagexy500 can only do 0.7 putimages per second in e.g. nvidia vanta
Maybe too much copying around between buffers, dunno what they're doing wrong
http://www.nvidia.com/page/vanta.html => 200 million pixels per second, 1 GB / sec bandwidth etc
vanta's a name I haven't heard in a while
More than enough for HD video :)
Not 1 fps :)
putimagexy500 in 32bpp = 1 MB. So the bandwidth is enough for 1000 putimages per second, not 0.7...
Even if the pci bus limits that to e.g. 133 MB/sec, it should be 200 times faster than what it is
|20:13||Faith has left IRC (Faith!~paty_@unaffiliated/faith, Ping timeout: 252 seconds)|
|20:18||Faith has joined IRC (Faithfirstname.lastname@example.org)|
|20:28||ogra_ has left IRC (email@example.com, Ping timeout: 260 seconds)|
|20:28||ogra_ has joined IRC (firstname.lastname@example.org)|
|20:42||Faith has left IRC (Faithemail@example.com, Changing host)|
|20:42||Faith has joined IRC (Faith!~paty_@unaffiliated/faith)|
|21:01||Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)|
|21:11||ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)|
|21:17||Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)|
vagrantc: ...could you give me a command to build a wheezy chroot with your ltsp backports, from a stretch server? :)
alkisg: not at this second, gotta run!
|22:25||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
np, paste it whenver you have time, bb
deb https://cascadia.debian.net/~vagrant/debian wheezy-backports-sloppy-UNRELEASED main
Goodies it booted fine with a 16.04 server
|23:30||ben_roose has left IRC (firstname.lastname@example.org, Remote host closed the connection)|