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


Channel log from 28 January 2016   (all times are UTC)

00:00
<moricef>
Or lightdm-gtk-greeter? If not, lightdm....
00:02
<vagrantc>
Phantomas: if i don't get to it tomorrow, it might not be till the following week ... but yes, look forward to it!
00:04
<Phantomas>
vagrantc: Cool. alkisg_alway informed me that an older change we had in epoptes regarding the use of faketime is breaking the edubuntu iso builds
00:04
I don't know if you were informed.
00:05
<vagrantc>
didn't know
00:06
guess you could set TZ=-14 instead :)
00:06
although that only gives you a few hours
00:06
and only in most timezones
00:08
<Phantomas>
Well, he has pushed the fix for it
00:09
<moricef>
time to sleep
00:09moricef has left IRC (moricef!d5d1bbe3@gateway/web/freenode/ip.213.209.187.227, )
00:10
<Phantomas>
I think 28 Jan would be the alpha2 edubuntu release, so if we get epoptes to debian, alkisg_alway could sync it to edubuntu and have a release this way.
00:11
Of course if you don't have the time, I guess he could upload it to edubuntu only somehow
00:14
<vagrantc>
hrm.
00:14
i'll make the time tomorrow
00:14
<Phantomas>
btw, we use faketime to fake the date, setting it to the Epoch, in order to allow clients with bad CMOS batteries to connect to epoptes with SSL
00:15
<vagrantc>
i guess the same issue holds for LTSP and LDM ...
00:15
Phantomas: i believe you could find that approach listed under the definition for hack in a decent dictionary.
00:15
:)
00:16* Phantomas secretively points to alkisg_alway
00:17
<Phantomas>
He tends to *love* hacks...
00:17* vagrantc nods knowingly
00:19
<vagrantc>
also hackish, but simply setting the time from a file in the package build would be a little more sane...
00:20
rather than continuing to operate with an outdated clock ... that can cause all sorts of weirdness
00:21
i mean, you'd still have an outdated clock in those cases... but at least it wouldn't predate the invention of epoptes :)
00:21
also, it's arguably not epoptes' business to mess with the clock ...
00:23
<Phantomas>
I think this led alkisg_alway to use faketime. It only fakes the date for the creation of the certificate, in order to make it valid since the epoch
00:25
My suggestion was to somehow sync the client clock at every client boot with an ntp server, either from LTSP or otherwise, but he didn't agree, probably because it isn't LTSP's job either to mess with the clock (?)
00:25
although more appropriate than epoptes doing it, I guess
00:27
Now we leave the clock broken, but we at least have a certificate which was virtually created in 1970-01-01 00:00:00 UTC
01:25ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
01:29
<vagrantc>
yeah, i get all that.
01:29
eesh.
01:47
<Phantomas>
sorry! :P
01:48
vagrantc: http://bazaar.launchpad.net/~epoptes/epoptes/trunk/revision/493 there's the changelog!
01:49
<vagrantc>
Phantomas: it was more an "eeesh." at the mess, nothing you said. i vaguely recall hashing this out with alkisg_alway back when it was implemented
01:49
Phantomas: cool! maybe i can even get it uploaded tonight
01:50
<Phantomas>
Awesome you are! :D
01:54
<vagrantc>
Phantomas, alkisg_alway: when you going to move to git? :)
01:55
<Phantomas>
vagrantc: Should we? I didn't have any issues with bzr tbh
01:56
and I find convenient Launchpad in the sense that we have all we need there: code/bugs/questions/translations/builds
01:57
<vagrantc>
i use git for all my other projects, save ltsp and epoptes ... would be nice to consolidate, but git-remote-bzr lets me forget about the difference most of the time
01:57
except when alkisg refers to commits based on the bzr id. heh.
02:00adrianorg has left IRC (adrianorg!~adrianorg@187.113.245.96, Ping timeout: 265 seconds)
02:01adrianorg has joined IRC (adrianorg!~adrianorg@187.113.250.55)
02:01
<Phantomas>
We could move to git and sync the branches to launchpad for the rest of our needs, but I don't think I have any good reason to support that.
02:03
<vagrantc>
i think alkisg wanted to try out github, maybe hoping it'll be easier for others to contribute
02:03
<Phantomas>
And it's pretty much the opposite for me. I mostly use launchpad/bzr, so you maybe should motivate me with something like "switch to git or I won't ever again upload epoptes to debian" :P
02:04
<vagrantc>
i wouldn't bother with threats like that :)
02:04
it's not major for me, i just notice it when i need to roll an upstream tarball
02:05
<Phantomas>
Yeah, his main argument was that bzr is dying. But I don't really see that, yet (?).
02:05
<vagrantc>
as i typically generate the changelog from the VCS and it would look odd to have the wrong VCS :)
02:05
most free software projects have moved to git ... for whatever reason
02:07
https://bugs.debian.org/src:epoptes is empty! good job!
02:09
<Phantomas>
We also have a lot of bugs fixed in the upstream tracker for this release!
02:09
<vagrantc>
yeah, saw
02:37
<Phantomas>
It's 4:40AM here, I'll get some sleep. Thanks for your time vagrantc! Have a nice day :)
02:37
<vagrantc>
Phantomas: should be on the mirrors by the time you wake up! :)
02:38
<Phantomas>
yay! :D
02:38Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
04:44alkisg_alway is now known as alkisg
04:44* alkisg waves
04:44* vagrantc waves
04:44
<alkisg>
vagrantc: setting the date from a file, at package install time, is way more hackish than telling openssl that we want our certificate to be valid in the past too
04:45
<vagrantc>
both are hugely hackish, one of them is closer to reality.
04:45
<alkisg>
what if openssl had a "--from-date" parameter? would that be hackish?
04:46
Another alternative would be to have an ltsp init script that sets the date to the epoptes certifiate date, if it's lower than that. So the hackish part would be (again) in the ltsp code only :D
04:47
But I believe it would be best if openssl had a --from-date parameter, and faketime does just that
04:47
<vagrantc>
you could have an epoptes hook to ltsp to do that, and we both share the fun :)
04:47
except when it doesn't :)
04:48
heh. that would be a way to abuse the SOURCE_DATE_EPOCH variable that the reproducible-builds project has been pushing into everything
04:48
<alkisg>
Or, certificates should have the ability to be issued without an starting date, assuming they're valid at whatever time in the past, that's a valid use case. E.g. rpi doesn't have a cmos to store the clock; one would not be able to use chrome without some faketime mechanism
04:51
Haha, so essentially debian will be using faketime itself? :)
04:51
Then debian is hackish :P :D
04:52
<vagrantc>
alkisg: you might know translation infrastructure better than i do... i'm thinking about removing all the debconf-updatepo and "make -C po update-po" calls in the packaging... i *think* po/* is basically handled by launchpad translation infrastructure now ... and debian/po/ is updated so infrequently it should probably only be done manually or something.
04:52* alkisg doesn't see anything wrong with allowing certificates to be valid in past dates, or with setting the clock on a specific date/time at build time
04:52
<vagrantc>
alkisg: no, reproducible-builds is working with upstreams to support SOURCE_DATE_EPOCH (or drop embedded timestamps in various things)
04:53
<alkisg>
That's the same as asking openssl to support a --from-date parameter
04:53
Except it's in an environment variable rather than a parameter, no real difference there
04:55
<vagrantc>
alkisg: regarding the /etc/network/interfaces issue ...
04:55
<alkisg>
Also, instead of asking all programs to work with a new parameter, they could just use faketime :)
04:55
Yup?
04:55
<vagrantc>
alkisg: the "no-auto-down $interface" doesn't work.
04:55
alkisg: well, it kind of does
04:55
<alkisg>
We don't need that, do we?
04:56
That would be used in inet dhcp + no auto down case, while we still want to use manual, right?
04:57
<vagrantc>
well, leaving the manual interface in now doesn't take the interface down anymore, but it does stall out the shutdown process
04:57
<alkisg>
Ah, by 10 seconds?
04:57
<vagrantc>
more like 1.5 minutes
04:57
<alkisg>
Hmm I haven't seen that
04:57
<vagrantc>
removing the manual stanza fixes it.
04:58
and i added the /etc/NetworkManager/conf.d/ltsp.conf stuff
04:58
<alkisg>
Does systemd mention which process is waiting to finish at that time?
04:59
<vagrantc>
from memory, something like: Stopping Bringing up network interfaces
04:59
<alkisg>
ifupdown then... we should mention that in the bug report then
04:59
That's with stretch, right?
04:59
<vagrantc>
which hurt even the largely weak and forgiving english grammarian in me
04:59
yeah
05:00
<alkisg>
Hahaha
05:00
Windows made the start there... click on the start menu to stop your computer
05:00
<vagrantc>
leave it to the pros.
05:01
<alkisg>
What happens if you put both manual and no-auto-down?
05:01
Does it stop quickly then?
05:01
<vagrantc>
alkisg: hangs
05:01
well, stalls
05:01
<alkisg>
Meh
05:01
<vagrantc>
yeah.
05:01
if there's an interface defined, it does *something* waiting for it to do something, and then gives up.
05:01
<alkisg>
Yup, I do think we should mention those in the bug report
05:02
manual shouldn't make it wait
05:02
<vagrantc>
so, i guess, my question is ... is the /etc/NetworkManager/conf.d/ltsp.conf hook sufficient in older versions?
05:02
<alkisg>
What about service ifupdown or service networking stop, while the client is running?
05:02
<vagrantc>
do we need the manual stanza?
05:02
<alkisg>
Yes, we're not using network manager
05:02
So we do need the manual stanza
05:03
<vagrantc>
why?
05:03
<alkisg>
ltsp chroots don't have nm installed by default
05:03
Only ltsp-pnp chroots have it
05:03
<vagrantc>
ifupdown will do nothing to the interface
05:03
<alkisg>
...true
05:03
<vagrantc>
i thought you only added it so that networkmanager wouldn't do anything
05:03
if we have another more specific way to do that...
05:03
<alkisg>
Ah yes, no it was not only for that
05:03
<vagrantc>
ah, ok.
05:04
<alkisg>
It was to tell ifupdown to send if-up events
05:04
I.e. ntpdate, epoptes-client etc were not running without the manual part there
05:04* vagrantc sighs
05:05
<alkisg>
Well, we could emulate the events ourselves, but it doesn't sound like an ltsp job...
05:05
We just want all the packages to work as they do normally... and there are many packages that have things in the if-up.d dir
05:05
<vagrantc>
it feels pretty broken to upload ltsp with shutdown/reboot basically broken
05:05
<alkisg>
In 16.04 it only stalls for 10 seconds, which seemed acceptable
05:06
<vagrantc>
hrm.
05:06
<alkisg>
I think the issue will be solved in ifupdown
05:06
So no new ltsp upload will be necessary
05:06
<gehidore>
people still use ifconfig? ;)
05:06
<vagrantc>
the other problem is backports, if it requires the "no-auto-down $interface"
05:06
<alkisg>
We can include the "remove the execstop stanza" if it will make you feel better
05:07
It's backportable, it works etc etc
05:07
<vagrantc>
gehidore: that's lower down the stack
05:07
<alkisg>
gehidore: what do other distros use, when they're not using network manager?
05:07
<vagrantc>
alkisg: what execstop stanza?
05:07
ip
05:07
<alkisg>
I had a previous revision in ltsp that did a sed in the ifupdown service file
05:08
Then I removed it, when ifupdown solved it upstream
05:08
<vagrantc>
alkisg: that's also discussed to not be relied upon
05:08
<alkisg>
We can reintroduce it temporarily, it won't hurt
05:08
The way I see it, we're currently trying to upload an ltsp version that will work with a temporarily broken ifupdown, right?
05:08
<vagrantc>
alkisg: from what phantomas said, you need stuff uploaded to debian basically now in order to sync?
05:08
<alkisg>
An ifupdown that will stay broken only for a month or so
05:09
vagrantc: not ltsp/ldm etc
05:09
Only epoptes
05:09
<vagrantc>
ah, good. done.
05:09
<alkisg>
It's breaking the build process of edubuntu
05:09
It's already uploaded? Great job! :)
05:09
<vagrantc>
i'm thinking i'll upload ldm tonight anyways
05:09
<alkisg>
There's no hurry for ltsp+ldm
05:10
The import freeze is at 18 Feb
05:10
<vagrantc>
why's epoptes different?
05:10
<alkisg>
It's not an issue of having a newer version in ubuntu,
05:10
<vagrantc>
i also would like to get LTSP working in Debian ...
05:10
<alkisg>
the problem is that epoptes.postinst is using faketime, and this fails on launchpad build environment, thus breaking the edubuntu.iso generation process
05:11
<vagrantc>
alkisg: reading the bug reports, the ifupdown maintainer didn't seem to accept the use-case as valid....
05:11
<alkisg>
He did leave the "manual" keyword for that, didn't he?
05:11
<vagrantc>
supposedly.
05:11
<alkisg>
The no-auto-down stanza does *not* help for netbooted clients
05:11
So, that was the solution he accepted, to leave the manual keyword for netbooting
05:12
<vagrantc>
and it works, just with an unreasonable delay in shutdown
05:12
<alkisg>
Which is a bug in his newly introduced code, and he'll probably fix it when we report it
05:12
<vagrantc>
alkisg: do you think it's worth adding the network-manager hacks?
05:13
alkisg: i was still able to access the interface via network-manager ... not sure if i'm able to break it.
05:13
<alkisg>
I think it's the same question as "do we want to also put wicd hacks there?"
05:13
<vagrantc>
don't forget connman!
05:13
<alkisg>
:)
05:14* vagrantc concedes alkisg's point
05:14
<alkisg>
Ideally we should be able to see the interface ip, connection speed etc, but not be able to change it
05:14* vagrantc is going to have to build a regular chroot to test some of this
05:15
<vagrantc>
alkisg: i can test if that's the case here.
05:15
<alkisg>
I don't think nm currently allows that
05:15
I'm not even sure it allowed vpn over that connection
05:16
Most debian packages rely on ifupdown compatibility, right?
05:16* vagrantc shrugs
05:16
<alkisg>
I.e. if ntpdate needs an if-up hook, it uses ifupdown for it, not network-manager, right? And then nm provides a compatibility layer
05:17
I haven't seen many packages shipping scripts in dispatcher.d yet...
05:18
As long as manual works, I wouldn't add more "hacks" there... Maybe some time in the future someone will define a common method to mark netboot interfaces
05:18
<vagrantc>
it's not uncommon for packages that are on top of things to support multiple ways
05:18
<alkisg>
Then the scripts would run twice
05:18
As nm also runs the if-up.d scripts
05:18
<vagrantc>
not if they're smart
05:19
<alkisg>
I think packages are smart to leave the compatibility layer up to nm :)
05:19* vagrantc writes an alkisg.service file
05:19
<alkisg>
but I would also think that debian would be smart to use faketime instead of defining a custom var, so what do I know :D
05:20
<vagrantc>
faketime has numerous technical problems
05:20
<alkisg>
That way it would have 99% of the packages doing reproducible builds without the devs even knowing about it
05:20
<vagrantc>
it was certainly tried in several cases
05:22
https://buildd.debian.org/status/package.php?p=epoptes
05:22
yay, it built!
05:22
<alkisg>
:)
05:22
<vagrantc>
this source-only uploads thing is pretty new andshiny for me
05:23
arch:all packages used to require a locally uploaded build
05:23
<alkisg>
highvoltage, stgraber: can we run syncpackage directly from unstable? Do we have time for the alpha2 build? Does edubuntu even have an alpha 2 build?
05:23
<vagrantc>
alkisg: i think it might technically be in incoming still ... but should hit unstable within the next 6-12 hours
05:23
<alkisg>
Ah, ok
05:24
<vagrantc>
quite possibly much sooner, if we're lucky
05:24
<alkisg>
No lintian warnings?
05:24
<vagrantc>
a handful of lintian warnings
05:24
but minor ones
05:24
<alkisg>
Spelling error in changelog? :(
05:25
<vagrantc>
I: epoptes: desktop-entry-lacks-keywords-entry usr/share/applications/epoptes.desktop
05:26
I: epoptes-client: init.d-script-does-not-implement-optional-option etc/init.d/epoptes-client status
05:26
W: epoptes-client: init.d-script-does-not-source-init-functions etc/init.d/epoptes-client
05:26
<alkisg>
I think it does source them, but conditionally, we need a lintian override for that one
05:26
OK I'll have a look to get rid of them for 0.6
05:27
If possible, it would be nice to get a 0.6 release in a couple of weeks, in time for the new translations + 16.04 feature freeze
05:27
<vagrantc>
I: epoptes source: vcs-field-uses-insecure-uri vcs-bzr http://bazaar.launchpad.net/~epoptes/epoptes/trunk
05:27
I: epoptes source: vcs-field-uses-insecure-uri vcs-browser http://bazaar.launchpad.net/~epoptes/epoptes/trunk/files
05:28
<alkisg>
...does launchpad support https there?
05:28
Ah, nice
05:28
OK I'll switch those to https
05:28
<vagrantc>
I: epoptes source: debian-watch-file-is-missing
05:28
i *think* launchpad does.
05:28
<alkisg>
kids wake up time, bb in 1h, thanks vagrantc :)
05:29alkisg is now known as alkisg_away
05:29
<vagrantc>
the watch file is really minor, as basically we release it
05:29* vagrantc waves
05:32
<vagrantc>
"A stop job is running for Raise network interfaces (45s / 1min 40s)"
05:32
and counting...
05:35
<gehidore>
alkisg_away: ip of course
05:36* vagrantc wonders what bzr branch/push/pull lp:epoptes resolves to
05:47
<vagrantc>
"bzr missing http://bazaar.launchpad.net/~epoptes/epoptes/trunk" works and "bzr missing https://bazaar.launchpad.net/~epoptes/epoptes/trunk" doesn't. boo.
05:58
huh. apparently launchpad has git support
06:37alkisg_away is now known as alkisg
06:37
<alkisg>
Back :)
06:39
gehidore: there's an "ip" package? That brings up/down interfaces on boot/shutdown? Any links?
06:39
<vagrantc>
iproute2
06:39
but it's all manual, like ifconfig
06:40
<alkisg>
It's not at all an ifupdown or network manager or wicd replacement then
06:40
<vagrantc>
ifupdown is a wrapper around ip (and historically, ifconfig) and other things
06:40
<alkisg>
Packages can't rely on that to get notifications...
06:46
<vagrantc>
alkisg: sounds like phantomas isn't keen on switching to git ...
06:46
<alkisg>
vagrantc: it's just a couple of commands, nothing important :)
06:47
The good thing with launchpad is that it's an all-in-one solution
06:47
<vagrantc>
alkisg: in digging around for a secure VCS URL, #launchpad said that bzr had no https anonymous access, but that git does
06:47
<alkisg>
If we find a good solution for translations for git, I don't mind if we switch to git or not
06:47
<vagrantc>
so apparently launchpad has some git support now?
06:48
<alkisg>
No idea, I only knew about remote git branches
06:48
Also, launchpad if completely opensource, while github is a bit closed, are you sure you prefer github over launchpad?
06:49* alkisg expects that sometime in the far future, launchpad might natively support git...
06:49
<alkisg>
I wouldn't want to have to move the projects twice then, once to github and then back to launchpad for the translations + build integration
06:49
<vagrantc>
https://help.launchpad.net/Code/Git
06:51robb_nl has joined IRC (robb_nl!~robb_nl@ip-213-49-86-55.dsl.scarlet.be)
06:51
<alkisg>
If that works, it's fine for me!
06:51vmlintu has joined IRC (vmlintu!~vmlintu@a88-112-3-40.elisa-laajakaista.fi)
06:52
<alkisg>
Let's try it for epoptes after 0.6 is out
06:52
<vagrantc>
can manually mirror it with git-remote-bzr, and experiment with it a bit
06:55
<gehidore>
ididn't see you said ifupdown
06:58
<alkisg>
vagrantc: where should I be looking to see when unstable gets the new epoptes release? On https://packages.qa.debian.org/e/epoptes.html ?
06:58
(so that I run syncpackage at that point)
06:58
<vagrantc>
alkisg: hard to know exactly
06:58
alkisg: rmadison epoptes
06:59
alkisg: but that sometimes lags behind the actual mirrors
06:59
or sometimes is ahead
06:59
<alkisg>
Thanks, I'll try that
06:59
<vagrantc>
https://tracker.debian.org/epoptes is basically the replacement for packages.qa.
07:00
<alkisg>
So let's check our TODO list... syncpackage, to fix the epoptes lintian warnings, to check the delay on ltsp client shutdown...
07:00
Anything else?
07:00
<vagrantc>
those are the main issues i recall
07:00
and really, none of those lintian warnings are very serious
07:01
<alkisg>
Cool, I'll start with syncpackage + the ifupdown bits
07:01
<vagrantc>
it would be nice to figure out secure-ish Vcs URLs
07:01
but apparently that's not an option for bzr hosted on launchpad
07:02
<alkisg>
If launchpad can handle git (for translations, recipes etc), then by all means, lets switch to it
07:02
<vagrantc>
i've given up on the kiosk mode breakage
07:03
no idea if it really supports all that
07:04vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
07:13
<alkisg>
highvoltage: syncpackage epoptes -d sid ==> syncpackage: Error: Debian version 0.5.9-1 has not been picked up by LP yet. Please try again later.
07:13
Does edubuntu have an alpha 2 release?
07:15robb_nl has left IRC (robb_nl!~robb_nl@ip-213-49-86-55.dsl.scarlet.be, Ping timeout: 240 seconds)
07:18eemeli has joined IRC (eemeli!3e94cd0c@gateway/web/freenode/ip.62.148.205.12)
07:23
<highvoltage>
alkisg: nope, that's why we need a fixed daily build :)
07:24
alkisg: hopefully there's not much else that breaks the build, we can do our own alpha testing and join in on alpha3 again
07:25* alkisg runs a loop... while ! syncpackage epoptes -d sid; do sleep 1h; done
07:31
<highvoltage>
heh
07:31mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
07:32
<highvoltage>
I'm sure the automated sync will be good enough because the daily builds only happen at midnight. but thanks anyway :)
07:33
<alkisg>
Ah ok then, I'll leave it up to the automated sync
07:36ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
08:02uXus has left IRC (uXus!~uXus@217.77.222.72, Remote host closed the connection)
08:09uXus has joined IRC (uXus!~uXus@217.77.222.72)
08:20F-GT has left IRC (F-GT!~phantom@ppp121-44-200-83.lns20.syd7.internode.on.net, Ping timeout: 250 seconds)
08:20Fenuks has joined IRC (Fenuks!~Fenuks@gate.ifmieo.nspu.ru)
08:22
<Fenuks>
Hello. Is it possible to keep i386 and amd64 ltsp clients and choose them from menu?
08:27F-GT has joined IRC (F-GT!~phantom@ppp121-44-200-83.lns20.syd7.internode.on.net)
08:33Rob____ has joined IRC (Rob____!2e3cfdac@gateway/web/freenode/ip.46.60.253.172)
08:34
<Rob____>
!ask
08:34
<ltsp>
ask: Don't ask to ask a question, simply ask it, and if someone knows the answer, they'll respond. Please hang around for at least a full hour after asking a question, as not everybody constantly monitors the channel.
08:35
<Rob____>
Hello. Custom software on PiNet. How does this work please. Are there any guides?
08:41
<alkisg>
Hi Rob____, pinet is not supported here, it's supported by mails to the developer
08:41
Here we only support ltsp
08:41
!raspberrypi
08:41
<ltsp>
raspberrypi: (#1) Ubuntu/LTSP on Pi 2: https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi, or (#2) Debian/LTSP (with raspbian chroot) on Pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#3) unofficial Ubuntu/LTSP (with raspbian chroot) on Pi: http://pinet.org.uk/
08:42
<Rob____>
OK, thanks
08:42
<alkisg>
Fenuks: yes, although it's usually not worth it to have both of them, i386 can serve amd64 clients just fine
08:42
Rob____: i.e. the first solution there, not pinet
08:42
#1
08:44
<Fenuks>
alkisg: Still, is there a documentation on how to set it up? It seems to load amd64 kernel with tftp, but use i386 image.
08:45
<alkisg>
No documentation, but there's support for it in the ltsp code if you can read shell
08:45
There's ifcpu64 in syslinux that can differentiate between i386 and amd64 clients, and chain to the appropriate image
08:46
ltsp has support for either automatically using that, or selecting via a menu
08:47
<Fenuks>
and to select it via menu I'll need to read the shell scripts and see what parameters to put where to, essentially, trick it, right?
08:54
alkisg: Also, there's a new parameter FAT_RAM_THRESHOLD. Does it mean that I can create a fat-client image, and it will only load initrd and select only certain binaries/libs to work as thin client is client's RAM is below such threshold?
08:55Rob____ has left IRC (Rob____!2e3cfdac@gateway/web/freenode/ip.46.60.253.172, Quit: Page closed)
08:56eemeli has left IRC (eemeli!3e94cd0c@gateway/web/freenode/ip.62.148.205.12, Quit: Page closed)
09:06
<alkisg>
Fenuks: yes to both
09:41
<Hyperbyte>
alkisg, sign here please: [ ]
09:42
<alkisg>
OK I'll bite, [ alkisg-gpg-signature... ] :P :D
09:48
<Hyperbyte>
Thanks.
09:49lbssousa has joined IRC (lbssousa!~laercio@187.11.244.53)
09:50
<alkisg>
What, that's all? No witty repartee?
09:51lbssousa has left IRC (lbssousa!~laercio@187.11.244.53, Client Quit)
09:52
<Hyperbyte>
alkisg, that's it.
09:52lbssousa has joined IRC (lbssousa!~laercio@187.11.244.53)
09:52
<alkisg>
Meh, all those CPU cycles for the digital signature wasted... :)
09:55
<Hyperbyte>
alkisg, who says it's wasted? You don't know what's going to happen now.
09:55
<alkisg>
Oh my... and my mother always used to tell me to be careful where to put my digital signature and my..
09:56
<Hyperbyte>
Well, too late now buddy.
10:10robb_nl has joined IRC (robb_nl!~robb_nl@ip-213-49-86-55.dsl.scarlet.be)
10:17kione has joined IRC (kione!57806687@gateway/web/freenode/ip.87.128.102.135)
10:49Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
10:50lbssousa has left IRC (lbssousa!~laercio@187.11.244.53, Quit: lbssousa)
10:50
<alkisg>
syncpackage succeeded
10:55alkisg is now known as alkis_away
10:55alkis_away is now known as alkisg_away
10:59cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
11:09Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
11:14Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
11:28lbssousa has joined IRC (lbssousa!~laercio@187.11.244.53)
11:57NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, Ping timeout: 272 seconds)
13:00
<Fenuks>
How can I configure the path to lts.conf? Assuming I have i386 and amd64 clients, they reside in /opt/ltsp/<arch> and tftp dir is /var/lib/tftp/ltsp/<arch>. It always loads /var/lib/tftpboot/ltsp/i386/lts.conf
13:04
Nevermind, found it. It's hardcoded and I've broken it by adding the menu on top of default one
13:58robb_nl has left IRC (robb_nl!~robb_nl@ip-213-49-86-55.dsl.scarlet.be, Ping timeout: 240 seconds)
14:27Fenuks has left IRC (Fenuks!~Fenuks@gate.ifmieo.nspu.ru, Ping timeout: 250 seconds)
14:34ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
14:47John___ has joined IRC (John___!29a4354e@gateway/web/freenode/ip.41.164.53.78)
14:49
<John___>
Hi. I would like some information about LTSP cluster. Can it be used to manage / support multiple LTSP servers over a slow VPN? Scenario is a number of rural schools without high end internet access that needs to be supported from a central support center.
14:51alkisg_away is now known as alkisg
14:52
<alkisg>
John___: normally you'd use ltsp on them to netboot their clients, and manage them via ssh/x2go
14:52
I.e. the servers themselves wouldn't be netbooted using ltsp, they'd be ltsp servers only, not ltsp clients
14:54
<John___>
Thanks. That clears things up.
14:55
I'll do some reading up on x2go. Thanks for your help
14:55John___ has left IRC (John___!29a4354e@gateway/web/freenode/ip.41.164.53.78)
15:59mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
18:01truth has joined IRC (truth!~Tara@dslb-188-110-203-050.188.110.pools.vodafone-ip.de)
18:26
<truth>
Hi,
18:26
I'm using Debian as a multi-user platform for the members of my family within a private network.
18:26
Since my children are getting older and want to use the computer more often I would like to have a second working station (or even more). I would like to have both places behaving the same way.
18:26
My first idea was to setup a LTSP-PNP fat client which is working fine but does (on the client side) only show the home-directory of the user which is logged in - so it is not exactly the same behavior.
18:26
I haven't tried yet but maybe VNC would be an other way to have a second working station.
18:26
Is there any other way to get a copy of my multi-user system which has reasonable performance to run e.g. things like VirtualBox, Flightgear, Minetest and so on.
18:26
My kids would be happy ...
18:26
Truth
18:28
<Hyperbyte>
Oh hi.
18:29
truth, what exactly are you asking? Do you want the full home dir to show up on the fat clients? If so, just use FSTAB_xx in the lts.conf file to mount home over NFS. Piece of cake.
18:30
If you're looking for something different than LTSP, you'll have to specify what exactly you need that you can't find in LTSP. Plus, we're not the most objective people in the world, since this IRC channel kinda -is- about LTSP....
18:32
<truth>
Does that mean that I would mount the complete /home in addition to the already existing /home which contains only one user ...?
18:43Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
18:46
<truth>
I'm not sure if it is possible at all but I would like to have a second multi-user platform which has identical information (data) and performance.
18:46
How can I do that?
18:48
<Hyperbyte>
truth, there is no existing /home with one user. There's a full home dir on the server, on the client only the home dir of the user that logs in is mounted. You can however mount the entire /home dir from the server, so all directories of other users are there too on the client. Wouldn't serve much purpose though unless you're using shared files in /home.
18:48
If you log in as another user, the home dir of that user will be mounted instead. LTSP manages that automatically.
18:48
As for a second multi-user platform with identical information and performance.... I have no idea what you mean by that. Can you be a little more specific, in regards to your use case?
18:52
<truth>
You say I can mount the entiere /home dir from the server ... how would I do this?
18:53lbssousa has left IRC (lbssousa!~laercio@187.11.244.53, Quit: lbssousa)
18:55Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
19:06
<alkisg>
truth: read the lts.conf manpage for FSTAB_0, it has an example for nfs home
19:06
If you want to mount the whole /home, nfs is easier + faster
19:07
<truth>
Concerning a second multi-user platform:
19:07
If a user is logged in on the server and an other user would like to e.g. quickly print out something you can just quickly change to another user (and make your printout). The previous user will than change back to his session again.
19:07
On the client side the first user would need to log out to allow the second user to print.
19:07
I know that it is possible open a shell and so on ..., but it will be not so easy to explain all this to my ten years old daughter.
19:09
<alkisg>
truth: each kid should have his/her own account, and you should have a share for shared data
19:10
<truth>
Each family member has an own account ...
19:11
<alkisg>
So why do you want access to the whole /home?
19:11
When one logs out, and another one logs in, another /home/username will be automatically mounted
19:13
<truth>
Sorry, I have mixed two questions ...
19:17
Concerning how to mount the entire /home I will read the man page ... thank for this information.
19:17
The more interesting thing would be to have a second multi-user platform as described above ...
19:23
So I probably should ask if it is possible to change the user on the client without need to log out the first user ...(as it is possible on the server)?
19:36
<Hyperbyte>
Basically, you want the "switch user" feature, but with LTSP?
19:38
<truth>
If this would be possible ...?
19:38
Of course if every family member would have his or her own client than there is no need for switching the user (on the client side). But at some point you might not want to spend 4 or 5 or even more terminals for just a home network.
19:38robb_nl has joined IRC (robb_nl!~robb_nl@ip-213-49-86-55.dsl.scarlet.be)
19:41
<Hyperbyte>
alkisg, could the switch user feature be implemented by doing multiple SCREEN=ldm entries?
19:41
alkisg, don't think so huh?
19:45
<alkisg>
In theory, it would be possible, in practise I think LDM needs a few patches before allowing that
19:46
truth: why does the first user need to stay logged in while the second user works on the same pc?
19:46
And second, why do you need the whole /home mounted?
19:50
<truth>
If the first user has many windows open he/she probably don't want to log out for just a print session.
19:51
<vmlintu>
alkisg: anything new regarding configd?
19:52
<alkisg>
truth: for a print session, you can use x2go to login to the server from inside the user session
19:52
vmlintu: nah, only me and vagrantc are working on ltsp, so there's little manpower for new things, it's mostly maintainance
19:53
Maybe a kickstarter / bounty program for ltsp 6 could speed up things
19:53
I think abou 6 man-months are needed for the bulk of ltsp 6, and then it can go back to maintainance mode...
19:55
<vmlintu>
alkisg: we just started working on a new configuration module for our systems and it might suit your needs too
19:55
alkisg: https://github.com/puavo-org/puavo-os/tree/the-repo-migration/parts/conf
19:56
alkisg: it's still very early, but the goal is to get dynamic configuration support so that we could change most settings without reboot
19:56
That's the client side of it
19:57
The server side can be anything that supports a rest api
19:57
<alkisg>
I think we've visualized different systems with similar names
19:58
What I have in mind is configd (or ltspd), the daemon, to serve anything, from the kernel + initrd to lts.conf to ldminfod settinsg etc
19:58
And the config client side would be a bash script that applies the settings
19:59
wget + put/get requests, plus a bit of sed'ing through files
19:59
<vmlintu>
puavo-rest + puavo-tftpd is what we are running on the server that serve kernel+initrd + configs etc..
20:00
<alkisg>
So the end result would be that I could boot a client from an ubuntu live cd, and only pass it a special kernel parameter to point to the ltspd server, and then it would boot like an ltsp client with all my settings applied
20:00* alkisg would like to keep only lpxelinux.0 in tftp, nothing else
20:00
<alkisg>
All the rest would go over http(s)
20:01
<vmlintu>
lpxelinux.0 is actually our goal too
20:01
for us thin and fat clients are soon a minority of devices, so we need something that works without a server connection
20:02
<alkisg>
the config client can store the settings in got in /var/cache and reapply them on the next boot, if needed
20:02
*it
20:02
<vmlintu>
yes, that's what we'll be doing
20:03
<alkisg>
Nice... unfortunately it seems that integrating things from puavo back to ltsp isn't easy
20:04
<vmlintu>
we are now splitting the server side from the image side so that it should get easier
20:04
<alkisg>
It would be nice if we could work together in the form of modules, code that can be shared between the projects
20:05
<vmlintu>
we are not using ltsp as a base anymore because of the missing laptop support, but components should be usable elsewhere
20:05
<alkisg>
I'm sure ltsp would welcome the laptop support, but I understand it's sometimes easier for someone to implement their own projects than integrating them to someone else's project
20:06
<vmlintu>
and if configd provided the same rest apis as puavo-rest, you could pretty much just use that instead of puavo server
20:06
<alkisg>
I had the same dillema when I implemented ltsp-pnp; I decided to upstream that one,
20:06
and when we implemented epoptes and sch-scripts; we kept those as separate projects
20:07
The configd client will be able to run without installation, it will basically just run wget + source the result, i.e. it will be getting shell code from the server
20:07Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
20:08
<alkisg>
That way it'll be possible to netboot any pc as a config client, even in a cow form, without changes being saved
20:14
<vmlintu>
laptop support is one thing, then things like wireless access points, digital signage screens, etc..
20:15
<alkisg>
I think that sysadmins can support all those with simple shell scripts, and each common use case can go upstream to ltsp
20:16
server side=ltsp devs, in python, client side=ltsp devs and sysadmins, in shell
20:16
The client side shell scripts are located on the server though
20:20
<vmlintu>
so the idea is that sysadmins add new functionality by writing code on the server and that is then run on the client?
20:21
<alkisg>
Yup
20:21
Of course that's for *new* functionality
20:22
While stock ltsp functionality will still be configurable with directives like the current lts.conf
20:22Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
20:23
<vmlintu>
years ago we used a script with ltsp that loaded a file over tftp during boot from the server and then just run it
20:25
what kind of pieces is ltsp6 missing?
20:26
I've been trying to figure out over the years if there's anything that would fit ltsp's scope that we are doing. We started by using ltsp so they are not worlds apart, just solving the same problems from different angles..
20:27
<alkisg>
I think we have the same goals and use cases, we're just trying to solve them with different implementations
20:27
We too have wireless laptops here that's hard to fit in ltsp networks without copying the image and config locally
20:28
For ltsp 6, I think the basic parts are ditching ldm, and implementing ltspd/configd and the client part
20:28
<vmlintu>
Are you using the same image on those laptops as for fat clients?
20:28
<alkisg>
Which is pretty much rewritting ltsp from scratch
20:29
Currently we're asking schools not to use wifi
20:29
And they're not taking them home either
20:31
<vmlintu>
so they boot the laptops over ethernet?
20:31
<alkisg>
Yup, normally like they do with the desktop pcs
20:33
<vmlintu>
I have just spent a couple of days with debian's initramfs-tools to get it support laptops properly with image files.. maybe something usable will come out of that
20:35
<alkisg>
The best part is when we get to upstream the solutions we find... initramfs-tools could use a lot of new features
20:35
Like, support for multiple mount=xxx kernel parameters, so that we could easily e.g. mount nfs first, then loop-mount a squashfs image over that, and use it for root...
20:35
<vmlintu>
While looking over debian's initramfs-tools I started thinking that I really need to dig in to dracut
20:36
<alkisg>
Unfortunately it doesn't seem to work in debian, right?
20:36
(due to packaging issues...)
20:36
<vmlintu>
I haven't really tried dracut yet, it did install for my unstable test chroot
20:37
<maldridge>
on another OS I have found dracut to be quite satisfactory
20:37eu^ip-93-94-190- has joined IRC (eu^ip-93-94-190-!5d5ebeb4@gateway/web/freenode/ip.93.94.190.180)
20:38
<alkisg>
I don't know if it has support for creating a cow view of a read-only system... like ltsp needs...
20:38
<vmlintu>
I managed to get debian initramfs extended so that it loop mounts a squashfs image from local partition, but using nfs as a base should be no problem
20:39
Also using a local partition as /cow worked and also writing fstab to get systemd mounting all other local partitions
20:39
<alkisg>
Debian's initramfs supports loopback squashfs images, but it checks for init on nfs, so it breaks there
20:40
vagrantc proposed a patch to fix that, but the initramfs-tools maintainer hasn't yet accepted it
20:40
<vmlintu>
that breaks also if you store the squashfs image on a local partition
20:40
<eu^ip-93-94-190->
Hi, tom from Poland i'v got problem my Epoptes on 32bit server kindly work with 32bit host but NOT working with 64bit host.... Has anybody know smtng about it?
20:41
<alkisg>
eu^ip-93-94-190-: which epoptes version are you using?
20:41
vmlintu: no, locally it works fine here
20:41
<eu^ip-93-94-190->
latest, installed last week from Canonical PPA
20:41
<vmlintu>
I used now boot=puavo parameter and the puavo script overrides the mountroot() method so that it does the loop mounts and everything else
20:41
<alkisg>
It's the boot=nfs script that breaks it
20:42
<vmlintu>
on debian?
20:42
<eu^ip-93-94-190->
lubuntu 14
20:42
<alkisg>
eu^ip-93-94-190-: what is the output of this? apt-cache policy epoptes
20:43
E.g. I have 0.5.9-1~ubuntu16.04.1 here
20:43
<eu^ip-93-94-190->
sorry but now i'm home & and epo i far far away in my work...
20:43
<alkisg>
We've sent a new version today
20:44
Try updating the client and the server tomorrow, from the "epotpes stable ppa"
20:44
So that you get the 0.5.9 version
20:44
If you still have the problem after that, come again here in irc
20:44
<eu^ip-93-94-190->
Ok I'll try, LARGE thnx ;)
20:45
<alkisg>
sudo add-apt-repository ppa:epoptes
20:45
<truth>
alkisg: I've just searched for x2go which looks very interesting and I will certainly give a try on this.
20:45
Nevertheless, if two or more users have to share a client it would still be interesting to have the "switch user" feature for the client as well.
20:45
<alkisg>
That's the command to use
20:45
truth: sure, there's a bug report in ltsp for that since 3-4 years now
20:45
It will be solved in ltsp 6, whenever that gets implemented
20:46
....as it will use lightdm instead of ldm
20:46
<Hyperbyte>
truth, x2go can keep sessions active if you log out. So it kinda has the switch user feature. Problem with x2go is that the client hardware isn't used; the desktop runs on the server. That's fine if that's what you want, but it's very different from LTSP fat clients.
20:46eu^ip-93-94-190- has left IRC (eu^ip-93-94-190-!5d5ebeb4@gateway/web/freenode/ip.93.94.190.180, Quit: Page closed)
20:46* alkisg suggested x2go only for the "quickly print something" use case
20:47
<Hyperbyte>
alkisg, ah.
20:47
<truth>
ok, thanks for all this information ...
20:48
<alkisg>
truth, you're welcome
20:51alkisg is now known as alkisg_away
20:51
<vmlintu>
I think I need to dig deeper to debian's initramfs..
20:51
and learn dracut
20:55m3741 has left IRC (m3741!8c20b7fe@gateway/web/freenode/ip.140.32.183.254, Ping timeout: 252 seconds)
21:02ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:06
<truth>
One more question:
21:06
In order to also use my little Asus EeePC as a LTSP client I installed i386 (instead of amd64) on my LTSP-PNP server which is working fine.
21:06
However, the performance (even on the server) is significantly reduced so I am thinking about to switch back to amd64.
21:06
Is it possible to run two different LTSP-server sessions in parallel (one for i386 clients and one for amd64 clients) ?
21:09
<maldridge>
truth: iirc it is possible, but it is more work to maintain
21:10kione_ has joined IRC (kione_!57806687@gateway/web/freenode/ip.87.128.102.135)
21:13
<truth>
I've done a test installations for LTSP fat client as well as LTSP-PNP.
21:13
But I'm not sure if I can have both in parallel ...?
21:13kione_ has left IRC (kione_!57806687@gateway/web/freenode/ip.87.128.102.135, Client Quit)
21:17kione has joined IRC (kione!~kione@mail.kione.de)
21:18
<||cw>
IIRC pnp will automatically do fat client for clients with 512MB ram or more
21:19
I guess you could try a ltspbiuld-client for i386 on pnp, might require some manual config to force the client to use it
21:29
<truth>
ltsp-build-client has an --arch option which I already used for LTSP.
21:29
However, is this still usefull when using PNP ...?
21:33
As far as I understood for LTSP-PNP the image is build with ltsp-update-image ... (instead of ltsp-build-client ...)
21:43
<||cw>
exactly
21:44
<truth>
... and I would need two images (one for i386 and one for amd64), right?
21:45
<||cw>
yes
21:46
let ltsp-update-image make your x64 images and ltsp-build-client make your x32
21:46
theoretically should work
21:49
<truth>
ok, I will give a try ... Thanks
21:59gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com)
22:05truth has left IRC (truth!~Tara@dslb-188-110-203-050.188.110.pools.vodafone-ip.de)
22:09vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
22:13
<vagrantc>
Phantomas, alkisg_away: i see you got epoptes into ubuntu already, did it make it for the alpha release?
22:15
Phantomas: doh! should've set the priority to medium
22:15
Phantomas: modern versions of "dch --release" should do that for you.
22:16
<Phantomas>
oops.
22:16
<vagrantc>
Phantomas: that just means it will take 10 days to migrate from unstable to testing instead of 5 ... which means uploading to jessie-backports will be delayed
22:16
not a huge deal
22:16
Phantomas: i should've caught it, too.
22:17
<Phantomas>
oh! Do you know if Ubuntu syncs with testing or unstable?
22:18
<vagrantc>
Phantomas: it's already synced, from what i can see
22:18
i know in the past ubuntu has sync'ed LTS releases with testing, though i'm not sure the end result was good
22:18
so they might have changed that
22:20
<Phantomas>
Indeed it's synced. Probably alkisg_away's work. So yeah, no big deal, but I'll remember to use dch next time.
22:28robb_nl has left IRC (robb_nl!~robb_nl@ip-213-49-86-55.dsl.scarlet.be, Quit: I'm gone, bye bye)
22:34kione has left IRC (kione!~kione@mail.kione.de, Quit: afk)
22:42Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
23:25ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)