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


Channel log from 17 February 2017   (all times are UTC)

01:02vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
04:04deepbook5broo has joined IRC (deepbook5broo!~gk.1wm.su@2a03:4a80:2:2d4:2d4:e830:6db2:a7d4)
04:04deepbook5broo has left IRC (deepbook5broo!~gk.1wm.su@2a03:4a80:2:2d4:2d4:e830:6db2:a7d4)
05:18Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 245 seconds)
05:23Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
06:40url_work has left IRC (url_work!~url_work@220-128-110-82.HINET-IP.hinet.net, Ping timeout: 240 seconds)
06:43url_work has joined IRC (url_work!~url_work@220-128-110-82.HINET-IP.hinet.net)
07:13ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:22Statler has joined IRC (Statler!~Georg@p579FE927.dip0.t-ipconnect.de)
07:34mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
07:46lunz has joined IRC (lunz!~gwd@190.213.49.89)
07:47lunz has left IRC (lunz!~gwd@190.213.49.89)
07:59lunz has joined IRC (lunz!~gwd@190.213.49.89)
08:00lunz has left IRC (lunz!~gwd@190.213.49.89, Quit: Leaving.)
09:01Statler has left IRC (Statler!~Georg@p579FE927.dip0.t-ipconnect.de, Remote host closed the connection)
09:41Statler has joined IRC (Statler!~Georg@mail.lohn24.de)
09:58markus_e92 has left IRC (markus_e92!~markus_e9@62-46-97-156.adsl.highway.telekom.at, Ping timeout: 255 seconds)
10:01markus_e92 has joined IRC (markus_e92!~markus_e9@80-121-123-63.adsl.highway.telekom.at)
10:23lurky_work has joined IRC (lurky_work!~url_work@220-128-110-82.HINET-IP.hinet.net)
10:25url_work has left IRC (url_work!~url_work@220-128-110-82.HINET-IP.hinet.net, Ping timeout: 260 seconds)
11:07Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
11:19* alkisg just bumped into the unshare command, e.g. sudo unshare -f -p --mount-proc bash -c 'ps aux'
11:19
<alkisg>
stgraber, ogra_, sbalneav, would it be a good idea to use `unshare` whenever we use `chroot` too? So that the pid and mount namespaces don't mix while installing programs or restarting services etc?
11:20
For example, we could easily do a `killall` while exiting the chroot, to make sure nothing remains and affects the server operation...
11:25alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
11:33alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
12:34lurky_work has left IRC (lurky_work!~url_work@220-128-110-82.HINET-IP.hinet.net, Read error: Connection reset by peer)
12:42
<al-geo>
hello my saviors. i cant figure out where to write down on server my networks default gateway for my fat client. for now route writes my ltsp-servers ip
12:45mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
13:13
<alkisg>
al-geo: what are you using, dnsmasq or isc-dhcp-server?
13:13
And I assume that you don't have an external dhcp server like a router, right?
13:14kjackal_ has joined IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16)
13:46
<al-geo>
apt-get install ltsp-server-standalone - i install with this. i think its isc-dhcp-server
13:47
and for now i am testing but in future i must use router as dhcp server
14:02
<alkisg>
al-geo: then use dnsmasq in proxy-dhcp mode. Problem solved.
14:02
!ltsp-pnp
14:02
<ltsp>
ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
14:02
<alkisg>
!proxydhcp
14:02
<ltsp>
proxydhcp: A proxy DHCP server is defined by the PXE specification as a server which sends auxiliary boot information to clients, like the boot filename, tftp server or rootpath, but leaves the task of IP leasing to the normal DHCP server. More info: https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP
14:02
<alkisg>
Those are docs about the default proxydhcp mode
14:19
<al-geo>
thank you very much
14:19
<sbalneav>
Morning all
14:19TatankaT has joined IRC (TatankaT!~tim@193.190.253.114)
14:22
<alkisg>
Heya Scotty
14:24
<sbalneav>
Hey alkisg
14:24
I don't know much about "unshare", I'll read up on it.
14:56ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
15:44vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
15:56ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
15:57ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
16:45dtcrshr has joined IRC (dtcrshr!~datacrush@2801:88:f7a:100:cd0e:4045:cabe:7462)
16:45dtcrshr has joined IRC (dtcrshr!~datacrush@unaffiliated/datacrusher)
16:50kjackal_ has left IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16, Ping timeout: 255 seconds)
17:10kjackal_ has joined IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16)
17:11forum has joined IRC (forum!~Icedove@212-183-50-240.adsl.highway.telekom.at)
17:15forum has left IRC (forum!~Icedove@212-183-50-240.adsl.highway.telekom.at, Ping timeout: 240 seconds)
17:17kjackal_ has left IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16, Ping timeout: 255 seconds)
19:14
<alkisg>
vagrantc: heya
19:14
Got time to talk about the daily builds?
19:20
One method that I can think of, is to name the patches with some special name, e.g. -upstreamed.patch, and then have autogen.sh or debian/control delete them before build, when the build environment has some launchpad-specific variable
19:21
If that will work for you, I can search the specific env var that we can check
19:23
<vagrantc>
alkisg: anything that actually requires changes in the build system don't sound too pleasant
19:23
<alkisg>
vagrantc: how so? we have conditionals for "if building on ubuntu", why daily builds are an issue?
19:23forum has joined IRC (forum!~Icedove@212-183-50-240.adsl.highway.telekom.at)
19:23
<vagrantc>
alkisg: applying and unapplying patches manually is a mess
19:24
<alkisg>
I didn't propose that
19:24
<vagrantc>
alkisg: there's no way to run an arbitrary command in the recipe to strip the patches out of the series before they're applied?
19:24
<alkisg>
I proposed deleting the files that we don't want, before the debuild process
19:25
<vagrantc>
alkisg: you'll also have to patch debian/patches, and it won't work correctly if the package was built from .dsc, in fact, it would likely cause a FTBFS
19:25
<alkisg>
Recipes can't run commands afaik, but I can put a script somewhere else and merge it, and still, some existing code will need to call it
19:26
Building from .dsc will work if one patches debian/patches from a recipe but not from a script's code?
19:26
<vagrantc>
so, my other proposal is to have a the branch/repository you merge from strip the things you don't want
19:27
<alkisg>
Let's split this into 2 tasks, I think I'll understand easier
19:27
<vagrantc>
alkisg: if you simply patch the files out of debian/patches/series in the launchpad build, it should generate a .dsc that will build the same.
19:27forum has left IRC (forum!~Icedove@212-183-50-240.adsl.highway.telekom.at, Ping timeout: 240 seconds)
19:28
<vagrantc>
alkisg: but if you patch the files after it's been unpacked by dpkg-source or quilt or whatever, then there will be applied patches that are ignored for the build
19:28
alkisg: presuming launchpad doesn't automatically apply the patches as part of the build outside of dpkg-buildpackage or whatever it calls
19:29
it's essentially a state caching problem
19:30
depending on how you build the debian package, the patches may be applied or unapplied, and they might get applied at build time
19:30
(if not already applieD)
19:30
so, if we can implement a mechanism to ensure they're unapplied, strip out the patches we don't want, and then run the build, it should work.
19:31
you can do that in a separate git repository or branch, but then you need to handle rebasing it all the time... unless you can generate a throwaway branch.
19:32
<alkisg>
I'm lost. I think this should be simpler than that. Let's have a look at the launchpad build process log: https://launchpadlibrarian.net/306804382/buildlog.txt.gz
19:33
Committed revision 1592. Applying quilt patches
19:34
Are you saying that the build process applies the patches without even getting yet to debian/control?
19:34
<vagrantc>
i'm not sure why you're talking about debian/control... that doesn't have to do with debian/patches/
19:35
that log is so full of meaningless noise... gah.
19:35
<alkisg>
What part is applying the patches, isn't it some debhelper component?
19:35
Sorry, debian/rules, I meant
19:36
<vagrantc>
alkisg: it looks to me like launchpad is doing it.
19:37
alkisg: it looks like launchpad is merging the contents of the debian dir into the top-level source dir, and then applying quilt patches...
19:38
alkisg: so, in that sense, it's emulating what "dpkg-source -x" would do...
19:38
alkisg: i don't think it will be possible to fix in the packaging if that's true
19:38
<alkisg>
I was thinking that patches would be applied when building, not when extracting the source...
19:39
<vagrantc>
alkisg: it's typically both, in modern packaging
19:39
alkisg: if they're unapplied, they get applied when building the package, but they're typically applied when the source tree is unpacked as well
19:40
at least with debian/source/format: 3.0 (quilt)
19:40
old-school systems applied them from debian/rules, but it's really error prone
19:40
<alkisg>
OK, so, will any of the ideas that you said work with launchpad?
19:41
If it chokes while still extracting/merging the code... it's too early, we can't run anything to omit patches...
19:41
<vagrantc>
alkisg: only way i can see is to merge from a branch that has the unwanted patches in debian/patches/series edited/comment out
19:42
alkisg: which, if we rename the patches systematically, like dropping them all in debian/patches/upstream/* that part should be easy and automatable
19:42
but then you need a branch that's forcibly rebased all the time
19:43
or something like that
19:43
<alkisg>
Which is exactly what I'm trying to avoid...
19:44
I would need to monitor when you push something to your branch, and then make another just to avoid breaking the daily builds
19:44
<vagrantc>
well, i think it's automatable.
19:44
<alkisg>
To have some cron job somewhere check all that, and update some branch on launchpad?
19:44
Maybe it can be added as a script to your workflow?
19:45
Like, when pushing, run that script too?
19:45
<vagrantc>
i guess i could even set up a hook in the git commit stuff to handle that
19:45
server-side...
19:45
what other import methods does launchpad support?
19:45
e.g. tarball?
19:46Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
19:46
<alkisg>
I don't think so, I've seen git, bzr, and cvs...
19:46
Let me check again
19:46
https://code.launchpad.net/+code-imports/+new
19:47
<vagrantc>
creating a single-commit git branch that's always overwritten with the latest upstream patches removed shouldn't be too hard.
19:47
<alkisg>
bzr, git, subversion, cvs
19:47
<vagrantc>
and really, should be fine to leave the patches in debian/patches ... just needs to be removed from debian/patches/series
19:48
while i say... not too hard... i probably won't have time to work on it till april
19:48
<alkisg>
Hrm. I wonder then if I could merge a single file that would override that
19:48
Ouch, without testing trunk until april?
19:49
<vagrantc>
we've gone how many months without it working?
19:49
alkisg: i guess you could merge without any patches fairly simply that way.
19:50
<alkisg>
I haven't tested ltsp in all those months
19:50
ltsp-trunk, that is
19:51
ltsp - 5.5.7~r2732+p1249+201603261524~ubuntu16.04.1 (Newer version available) (changes file) no signer 2016-03-27 Published Xenial Misc
19:51
...so, it's been about a year without testing ltsp-trunk in real world
19:52
<vagrantc>
rough times
19:55
<alkisg>
(09:54:48 μμ) dobey: alkisg: yes, so there is a different debian/ tree for experimental than for stable. you can't avoid that
19:55
I think that's what I'm looking for, a debian/ tree that corresponds to experimental...
19:55
<vagrantc>
as in "debian experimental" ?
19:56
as that may still contain additional patches...
19:56
<alkisg>
Whatever, as long as it can build against upstream code
19:56
<vagrantc>
what you need is a separate branch for that purpose.
19:57
as there's no guarantee that debian/experimental will build with upstream either
19:57
<alkisg>
So we're back to having to maintain a different ltsp for ubuntu...
19:57
*packaging
19:57
well actuall for upstream...
19:57
<vagrantc>
right... technically, we've always been there, just sometimes it works by pure luck
19:59
right... ubuntu's been following debian's ltsp packaging just fine
19:59
<alkisg>
Oh well... would you mind if I pushed a debian/ dir upstream in ltsp?
19:59
<vagrantc>
ever since they've been synced.
19:59
<alkisg>
I really don't like to maintain forks
19:59
<vagrantc>
alkisg: that would cause conflicts on every merge
19:59
alkisg: please not that :)
20:00
<alkisg>
It would be the upstream debian dir, and you can then keep your own in debian...
20:00
:D
20:00
<vagrantc>
i would fork.
20:00
right now i have the packaging working quite nicely for debian
20:01
<alkisg>
But we can't test ltsp for a year now
20:01
With a debian/ dir upstream like it is in epoptes, we would be able to
20:01
<vagrantc>
we fixed that in epoptes.
20:02
<alkisg>
And then you can keep snapshots and local modifications for every debian release
20:02
And the ubuntu maintainer can keep snapshots for ubuntu releases
20:02
<vagrantc>
seriously, it's going to create merge nightmares.
20:02
<alkisg>
But upstream would always build
20:02
<vagrantc>
it's not the way to do it.
20:03
<alkisg>
Epoptes worked fine for years. LTSP can't have daily build for a year. Which one of those 2 works? :
20:03
:(
20:03
<vagrantc>
i had to fork epoptes a few times, and then spend a huge amount of time to re-merge them.
20:04
<alkisg>
Why? Aren't debian releases essentially snapshots of the debian/ dir?
20:04
And the source dir too?
20:05
<vagrantc>
alkisg: because the source dir got out of sync with the debian dir
20:05
<alkisg>
That should never happen upstream
20:05
I can understand this work flow: "some debian-based distro wants to release. OK, clone the whole tree, with src/ and debian/ in it, and it should work fine at that point; otherwise it's an error",
20:06
<vagrantc>
it happened every time there was a commit upstream that didn't get updated in the debian dir
20:06
<alkisg>
"then, if new patches need to be backported, they would be backported to that fork"
20:06
I never do such commits
20:06
I would consider them an error that should be fixed immediately
20:07
<vagrantc>
sure, and that works as long as upstream doesn't break the debian dir
20:07
<alkisg>
Which is what we do when we are both upstream and debian maintainers
20:07* vagrantc sighs
20:07
<alkisg>
I wouldn't mind forking the debian/ dir for someone else's project; I mind having to keep a fork for my own projets
20:08
And more importantly, a fork of an older version!
20:10
<vagrantc>
just keep an upstream branch for packaging, and there's no issue...
20:10
<alkisg>
Sure. I'd love to have an upstream branch for packaging, one that would be forked whenver debian or ubuntu or any other debian-based distro wants to release ltsp
20:11
Can we have that, with both of us as committers?
20:11
<vagrantc>
a split branch? bah.
20:11
<alkisg>
What do you mean "split branch"?
20:12
<vagrantc>
basically, as long as there's an upstream branch without a debian dir, it works well for me. if there's a separate branch with debian packaging with just the debian dir, or with upstream+debian dir, that's fine.
20:13
<alkisg>
So we can settle with a branch in git format in launchpad, which would contain the latest version of the debian/ dir?
20:13
<vagrantc>
i may not use the "upstream" packaging dirs at all in debian
20:14
<alkisg>
Then I wouldn't use them either, because ubuntu would get the debian/ folder from debian, not from "upstream"
20:15
I can understand that you don't want to maintain a debian/ dir that builds against ltsp-trunk,
20:15
but can't we find some way that I can maintain that, without having to fork older versions each time?
20:15
<vagrantc>
what do you mean by "fork older versions" ?
20:15
<alkisg>
Something like me maintaining debian-experimental, and you maintaining stab/stable, testing etc
20:16
When I would want to test debian-experimental, I would have to fork your last tree from debian-testing or debian-stable, and remove the patches that were applied upstream
20:16
The opposite of what feels normal to me
20:16
<vagrantc>
alkisg: there's no difference to supporting debian stable, debian unstable/testing and debian experimental ... they all require manual care and feeding
20:17
<alkisg>
For me, the latest upstream code and latest packaging code should work fine in the latest debian and ubuntu versions
20:17
<vagrantc>
yeah, sure, but what you really want is debian-based-distro-upstream
20:17
<alkisg>
I can't have that now
20:18
<vagrantc>
alkisg: i think what you want is for me to maintain a packaging branch for upstream :P
20:18
<alkisg>
I don't mind if I maintain debian in ltsp
20:18
I do mind if someone else maintains it, and I need to fork all the time
20:18
So yes, please maintain a packaging branch for upstream :)
20:19
<vagrantc>
i still think it's possible to do in a mostly automated way
20:19
though there will still be occasions where packaging needs to change in more ways that simply excluding upstream patches
20:20
<alkisg>
It's like flashplugin-installer
20:20
The maintainer needs to have a cron job to check for new versions, and download them from the internet and build them
20:21
<vagrantc>
at any rate, i think we'll be able to come up with something, but i need to put some focus on other things today
20:21
<alkisg>
It's ok to do it if you're not adobe. It's a shame to do it if you are upstream...
20:22
vagrantc: thanks for your thoughts. Sorry if I was a bit too anxious about it. :
20:22
<vagrantc>
most upstreams just ship a Makefile or something
20:22
and then let the distributions do their thing
20:23
<alkisg>
Imagine having to sync your debian/ dir with the opensuse packaging all the time, while you're both upstream and debian maintainer
20:23
<vagrantc>
if the Makefile (or other build system) is done right, then the packaging is trivial
20:23
<alkisg>
That's how bad it sounds to me, that I want to care for both src/ and debian/, but I can't, I need a fork
20:25
<vagrantc>
alkisg: in general, i see what you're saying ... the main issue is when a debian freeze hits
20:25
alkisg: then it becomes more than i want to deal with to have to maintain upstream packaging separately
20:25
<alkisg>
Freezes happen all the time. For debian, for ubuntu, and every week or month that I release to the ppa for 1000+ schools
20:25
<vagrantc>
then i commit patches upstream, and include them in the packaging patches
20:26
<alkisg>
That's why there should be a packaging-trunk version, not a packaging-for-a-specific-distro version, and -trunk would fork from it!
20:26
Here's an idea:
20:27
If I implement that hook for your workflow, would you be able to test it before april?
20:27
(the one that would push 2 branches, one for debian and one without the upstream patches)
20:29
<vagrantc>
alkisg: i'm a bit nervous to send you off on a project like that
20:30
<alkisg>
OK. Let's close it for now then, I'll do a fork once; but please think about it for the future, there has to be some way that I can help you maintain a packaging-trunk
20:31
<vagrantc>
yeah, i'll think about it
20:32
<alkisg>
ty! :
20:33
<vagrantc>
got a couple conference talks in the coming two weeks, middle of debian freeze, so my focus isn't so much on upstream at the moment
20:33
which reminds me of that stupid nbd bug where it strips the leading /
20:34
gah. really want to get that fixed for stretch
20:35kjackal_ has joined IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16)
20:42
<alkisg>
vagrantc: does it also break with ROOTPATH=/opt/ltsp/i386 or with nbdroot=/opt/ltsp/i386, or only with nbdroot=192.168.67.1/opt/ltsp/i386 ?
20:43
<vagrantc>
alkisg: it strips the first /
20:43
<alkisg>
Because in the first 2 cases, it's clearly a bug
20:43
<vagrantc>
and a bug has been filed...
20:43
<alkisg>
In the last case, / is a separator
20:43
In the first 2 cases, it's not, so it needs to be included in the requested export name
20:44
<vagrantc>
well, it's nbdroot=192.168.67.1:/opt/ltsp/i386
20:44
<alkisg>
But LTSP users don't use that normally
20:44
While they do use the ROOTPATH syntax by default
20:45
So, is the default installation broken too? Or only user-modified ones?
20:45
<vagrantc>
default is broken
20:45
<alkisg>
That is clearly a bug then, as ROOTPATH doesn't contain a port, it doesn't need a separator there
20:46
<vagrantc>
it's a shell globbing issue
20:46
or, maybe not globbing specifically
20:46
<alkisg>
In theory, can one define ROOTPATH=192.168.67.1:/opt/ltsp/i386, either in nfs or in nbd?
20:46
<vagrantc>
but all the various ${VAR%%"value"} style variable
20:47
<alkisg>
Or that goes in ROOTSERVER/next-server?
20:47
<vagrantc>
i think the ROOTPATH is used if the commandline variables aren't passed
20:47
it just sets the variable and it's the same codepath otherwise
20:47
<alkisg>
No, I mean the definition of ROOTPATH as used by nfs and DHCP, I'm not asking about how wouter implemented its parsing
20:48
Because if the definition of ROOTPATH can't contain a server, then we can easily send a patch for that to wouter
20:48
<vagrantc>
can't contain a port?
20:49
but then ROOTPATH=192.168.67.1:/opt/ltsp/1234 would also break
20:49
as the / is being used as a separator to define the port
20:49
<alkisg>
Is this a valid ROOTPATH for NFS?
20:49
<vagrantc>
no
20:49
er, yes
20:49
<alkisg>
I thought that the server was defined in next-server...
20:49
<vagrantc>
but the /1234 is a path, not a port
20:49
it's also valid there
20:50
in fact, i think it overrides next-server
20:50
at least, in all implementations i've seen for many many years
20:50
<alkisg>
OK, if ROOTPATH is allowed to contain a server, yeah the default ltsp installation has the same issue...
20:50
<vagrantc>
really, it's a just a bug that was introduced when wouter added a configurable port, using the "/" as a separator
20:51
and then it was "fixed" by stripping the leading slash...
20:51
well, maybe that wasn't the intention
20:52
https://bugs.debian.org/846998
20:52
which refers to the bug that "fixed" the previous problem
20:52
<alkisg>
"- We change the definition of the ip:port/exportname syntax so that the / is only stripped if an IP address and/or a port was specified, too; i.e., if you don't specify anything before a /, then it is assumed that the / is part of the export name, rather than it being a separator. Not sure whether that fixes the issue for LTSP (in fact, not even sure whether it's valid currently to specify only the exportname, but ignoring that), but if so,
20:52
That would make the default ltsp installation work
20:52
But anyone that wanted to specify a server as well, would have to use 2 slashes
20:53ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
20:57
<vagrantc>
case nbdroot in
20:57
^/*|*:/*) nbdpath= ...
20:57
i think that should solve all the use-cases i can think of
20:57syrius has joined IRC (syrius!syrius@thunder.stormtek.net)
20:59
<vagrantc>
i need to bump that on my priority list
21:02* vagrantc waves and wanders off to other things
21:03
<syrius>
having a difficult time finding straight-forward information for using NX through LTSP instead of X11. anyone had success? i'm on opensuse 13.2 atm
21:11vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 255 seconds)
21:14kjackal_ has left IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16, Ping timeout: 255 seconds)
21:27kjackal_ has joined IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16)
21:41
<||cw>
syrius: should be kinda similar to using rdp or vnc. you're basically using very little of ltsp that way
21:42
<syrius>
sure.. at this point i'm looking to improve performance with thin clients
21:42
<||cw>
what are you client specs?
21:43
if faster than P4's you might look into fat client or ltsp-pnp
21:43
<syrius>
yeah, newer than that
21:43
haven't heard of ltsp-pnp
21:43
<||cw>
which is far better supported on ubuntu, not sure any real suse effort has been done
21:43
<syrius>
hmm
21:43
<||cw>
!ltsp-pnp
21:43
<ltsp>
ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
21:44
<syrius>
i'll take a look at that
21:44
another issue could be the network speed, but we really only have a couple simultaneous clients
21:44
the ltsp nic is separate and it's just a 100mbit
21:44
<||cw>
basically makes everything run local, but with a remote disk, so still diskless and PXE booted
21:45
<syrius>
oh interesting
21:45
<||cw>
far less server resources needed, but you can't disconnect and resume a session like you can with NX
21:46
<syrius>
yeah that's not required functionality
21:57ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
22:18kjackal_ has left IRC (kjackal_!~quassel@2a02:587:3108:3100:48c7:5851:ea72:7e16, Ping timeout: 255 seconds)
22:44
<syrius>
||cw: sorry i was debugging the nx stuff.. how is ltsp-pnp different from a thin client?
22:44
i mean i see the description says it's not chrooted
22:44
but i don't see our current implementation doing that for the thin clients
22:59
<||cw>
pnp uses the server's root to build the image, the based on client specs or your lts.conf overrides chooses thin or fat client mode.
23:00Statler has left IRC (Statler!~Georg@mail.lohn24.de, Remote host closed the connection)
23:36
<syrius>
gotcha