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:09 | moricef 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:25 | ben_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:00 | adrianorg has left IRC (adrianorg!~adrianorg@187.113.245.96, Ping timeout: 265 seconds) | |
| 02:01 | adrianorg 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:38 | Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas) | |
| 04:44 | alkisg_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:29 | alkisg 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:37 | alkisg_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:51 | robb_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:51 | vmlintu 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:04 | vagrantc 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:15 | robb_nl has left IRC (robb_nl!~robb_nl@ip-213-49-86-55.dsl.scarlet.be, Ping timeout: 240 seconds) | |
| 07:18 | eemeli 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:31 | mikkel 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:36 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 08:02 | uXus has left IRC (uXus!~uXus@217.77.222.72, Remote host closed the connection) | |
| 08:09 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 08:20 | F-GT has left IRC (F-GT!~phantom@ppp121-44-200-83.lns20.syd7.internode.on.net, Ping timeout: 250 seconds) | |
| 08:20 | Fenuks 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:27 | F-GT has joined IRC (F-GT!~phantom@ppp121-44-200-83.lns20.syd7.internode.on.net) | |
| 08:33 | Rob____ 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:55 | Rob____ has left IRC (Rob____!2e3cfdac@gateway/web/freenode/ip.46.60.253.172, Quit: Page closed) | |
| 08:56 | eemeli 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:49 | lbssousa has joined IRC (lbssousa!~laercio@187.11.244.53) | |
| 09:50 | <alkisg> What, that's all? No witty repartee?
| |
| 09:51 | lbssousa has left IRC (lbssousa!~laercio@187.11.244.53, Client Quit) | |
| 09:52 | <Hyperbyte> alkisg, that's it.
| |
| 09:52 | lbssousa 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:10 | robb_nl has joined IRC (robb_nl!~robb_nl@ip-213-49-86-55.dsl.scarlet.be) | |
| 10:17 | kione has joined IRC (kione!57806687@gateway/web/freenode/ip.87.128.102.135) | |
| 10:49 | Faith has joined IRC (Faith!~paty_@unaffiliated/faith) | |
| 10:50 | lbssousa has left IRC (lbssousa!~laercio@187.11.244.53, Quit: lbssousa) | |
| 10:50 | <alkisg> syncpackage succeeded
| |
| 10:55 | alkisg is now known as alkis_away | |
| 10:55 | alkis_away is now known as alkisg_away | |
| 10:59 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 11:09 | Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving) | |
| 11:14 | Faith has joined IRC (Faith!~paty_@unaffiliated/faith) | |
| 11:28 | lbssousa has joined IRC (lbssousa!~laercio@187.11.244.53) | |
| 11:57 | NeonLicht 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:58 | robb_nl has left IRC (robb_nl!~robb_nl@ip-213-49-86-55.dsl.scarlet.be, Ping timeout: 240 seconds) | |
| 14:27 | Fenuks has left IRC (Fenuks!~Fenuks@gate.ifmieo.nspu.ru, Ping timeout: 250 seconds) | |
| 14:34 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 14:47 | John___ 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:51 | alkisg_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:55 | John___ has left IRC (John___!29a4354e@gateway/web/freenode/ip.41.164.53.78) | |
| 15:59 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 18:01 | truth 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:43 | Faith 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:53 | lbssousa has left IRC (lbssousa!~laercio@187.11.244.53, Quit: lbssousa) | |
| 18:55 | Faith 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:38 | robb_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:07 | Faith 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:22 | Phantomas 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:37 | eu^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:46 | eu^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:51 | alkisg 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:55 | m3741 has left IRC (m3741!8c20b7fe@gateway/web/freenode/ip.140.32.183.254, Ping timeout: 252 seconds) | |
| 21:02 | ricotz 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:10 | kione_ 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:13 | kione_ has left IRC (kione_!57806687@gateway/web/freenode/ip.87.128.102.135, Client Quit) | |
| 21:17 | kione 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:59 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
| 22:05 | truth has left IRC (truth!~Tara@dslb-188-110-203-050.188.110.pools.vodafone-ip.de) | |
| 22:09 | vagrantc 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:28 | robb_nl has left IRC (robb_nl!~robb_nl@ip-213-49-86-55.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 22:34 | kione has left IRC (kione!~kione@mail.kione.de, Quit: afk) | |
| 22:42 | Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas) | |
| 23:25 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |