IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 21 May 2016 (all times are UTC)
| 01:48 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 260 seconds) | |
| 01:52 | Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack) | |
| 02:04 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 03:50 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 04:11 | rac_ has joined IRC (rac_!71148af6@gateway/web/freenode/ip.113.20.138.246) | |
| 04:12 | <rac_> I install google chrome on ltsp-PNP, the installation is completed properly, but in google chrome ltsp client does not show
| |
| 04:12 | can help me,
| |
| 04:13 | <vagrantc> did you rebuild the image?
| |
| 04:13 | fat or thin clients?
| |
| 04:15 | <rac_> on client,
| |
| 04:16 | I should run after installation software,
| |
| 04:18 | <vagrantc> if you're using fat clients, you need to re-run ltsp-update-image in order for installed software to be available
| |
| 04:18 | <rac_> ok i want try
| |
| 04:22 | a good answer, my problem is finished.
| |
| 04:22 | thanks,,
| |
| 04:22 | one more, why the client computer is sometimes a bit slow and not respond
| |
| 04:23 | <alkisg> rac_: what is the cpu/ram of the client?
| |
| 04:23 | <rac_> is there another way to make it faster in client ltsp ?
| |
| 04:23 | <vagrantc> if it is a fat client, the main way to make it faster is to get a faster fat client...
| |
| 04:24 | <rac_> ON Server : Processor : i7, Memory 16G, HDD :1T...On the Clinet Processor : Dual Core, Memory 1G
| |
| 04:25 | <alkisg> On the client, run: grep 'model name' /proc/cpuinfo
| |
| 04:25 | What is the output?
| |
| 04:25 | Because saying "dual core" is like saying "my vehicle has 4 wheels". Not too specific...
| |
| 04:29 | <rac_> rocessor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Sempron(tm) 145 Processor stepping : 3 microcode : 0x10000c8 cpu MHz : 2800.000 cache size : 1024 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp :
| |
| 04:30 | <alkisg> http://www.cpubenchmark.net/cpu.php?cpu=AMD+Sempron+145
| |
| 04:30 | It has a cpu score of 800
| |
| 04:30 | Here is one i7: https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-6700K+%40+4.00GHz
| |
| 04:30 | It has a cpu score of 10000+
| |
| 04:30 | That means that your server is 10 times faster than your amd client
| |
| 04:31 | For modern operating systems, clients should have more than 1000 score, and for new clients, it's best to buy with at least 2000 score
| |
| 04:32 | <rac_> if the client computer I have a problem with the specification
| |
| 04:33 | What can I maximize existing computer ?
| |
| 04:34 | <alkisg> Is this your only client?
| |
| 04:34 | How many clients do you have?
| |
| 04:35 | <rac_> there are multiple client computers at our place with the following specifications
| |
| 04:35 | 10 Client,
| |
| 04:36 | <alkisg> Then you can't do much to make it better. LTSP doesn't make the clients run the OS faster than it would run if you installed it on a local disk.
| |
| 04:38 | <vagrantc> since you have a nice server, you could try thin clients...
| |
| 04:38 | but a lot of things will still be very slow
| |
| 04:43 | <rac_> I use ubuntu 16.04lts, if I use ubuntu 10.04lts, what could be better?
| |
| 04:45 | <alkisg> No, it's chromium that goes slowly, not ubuntu
| |
| 04:45 | Web browsing will be faster if you use firefox 1.0 or dillo, but half of the web won't be working at all then :)
| |
| 04:50 | <rac_> This means the problem of Chrome instead of ubuntu, if I only use thunderbird what's the problem?
| |
| 04:50 | <alkisg> No problem, thunderbird should be faster than chrome
| |
| 04:50 | !learn cpubenchmark as One way to measure your client CPU performance is by looking up its CPU score in cpubenchmark.net. Anything with score below 1000 isn't really acceptable for today's web browsing needs etc. For new clients, try to buy ones with score>2000, whether you plan to run them as LTSP fat clients or to install a local OS in them.
| |
| 04:50 | <ltsp`> The operation succeeded.
| |
| 04:50 | <vagrantc> but thunderbird is only a mail client
| |
| 04:53 | <rac_> ok, thanks for the advice ( alkisg, vagrantc )
| |
| 04:53 | <alkisg> You're welcome rac_
| |
| 04:54 | <vagrantc> rac_: good luck!
| |
| 04:57 | rac_ has left IRC (rac_!71148af6@gateway/web/freenode/ip.113.20.138.246, Ping timeout: 250 seconds) | |
| 05:05 | rac_ has joined IRC (rac_!71148af6@gateway/web/freenode/ip.113.20.138.246) | |
| 05:09 | rac_ has left IRC (rac_!71148af6@gateway/web/freenode/ip.113.20.138.246, Ping timeout: 250 seconds) | |
| 05:27 | <alkisg> vagrantc: in epoptes.postinst, we're using faketime to fool openssl to generate a certificate that is valid since the Epoch
| |
| 05:27 | ...it segfaults in 16.04, it'll probably segfault on sid too, I haven't checked
| |
| 05:28 | You've done some work on reproducible builds, right? Is there any other way than faketime to fool apps to think the date=epoch?
| |
| 05:32 | <vagrantc> the way reproducible_builds has been going is to support SOURCE_DATE_EPOCH in the build tools.
| |
| 05:32 | faketime isn't prone to a variety of errors.
| |
| 05:33 | er, faketime is prone to a variety of errors.
| |
| 05:33 | <alkisg> vagrantc: so that wouldn't help in telling openssl to generate a certificate valid since the Epoch, it could only be used at the build time of openssl...
| |
| 05:33 | Any other ideas that could work?
| |
| 05:34 | The problem is that clients like rpi or PCs with failed CMOS dates don't accept the epoptes certificate if their clock is wrong
| |
| 05:34 | *failed CMOS batteries resulting to wrong dates...
| |
| 05:35 | I see that there are other apps using faketime with openssl, e.g. http://permalink.gmane.org/gmane.linux.pve.devel/16245, maybe we should file a bug report against faketime or openssl
| |
| 05:51 | <vagrantc> alkisg: well, you could set SOURCE_DATE_EPOCH=0
| |
| 05:52 | alkisg: but openssl would have to respect SOURCE_DATE_EPOCH
| |
| 05:53 | SOURCE_DATE_EPOCH is seconds since the start of the unix clock.
| |
| 05:54 | <alkisg> vagrantc: openssl would only need to respect that during its build though, not during runtime, right?
| |
| 05:54 | * vagrantc has been noticing some at least reset to the CMOS manufacturing date or software date, rather than 1970 | |
| 05:55 | <vagrantc> alkisg: during runtime *might* be reasonable for openssl
| |
| 05:55 | <alkisg> That still makes the certificate invalid, even 2014 does, when epoptes was installed in 2016
| |
| 05:55 | <vagrantc> toolchains need to respect it
| |
| 05:56 | alkisg: yeah, i get that
| |
| 05:56 | openssl could arguably be part of a toolchain
| |
| 05:58 | alkisg: might make sense to use fake-hwclock or timesyncd to ensure a sane time
| |
| 05:59 | <alkisg> vagrantc: fake-hwclock can't work with ltsp without server-side storage
| |
| 05:59 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 05:59 | <alkisg> and timesyncd might run too late, after the epoptes service starts
| |
| 06:00 | * vagrantc thought timesyncd ran very early | |
| 06:00 | <vagrantc> the network time doesn't necessarily kick in in a timely fashion, but it also has a timestamp file
| |
| 06:00 | <alkisg> It has to contact the server, possibly skew the clock etc... even if it starts early, in practice I've seen it doesn't succeed
| |
| 06:01 | <vagrantc> the timestamp file read should happen very early
| |
| 06:01 | <alkisg> One way around it is to implement something like fake-hwclock in ltsps or epoptes,
| |
| 06:01 | <vagrantc> we could touch that file from ltsp-update-image
| |
| 06:01 | <alkisg> so that if the client clock date is earlier than the epoptes certificate timestamp, to update the clock date to that
| |
| 06:01 | <vagrantc> yeah, it wouldn't be hard
| |
| 06:02 | <alkisg> epoptes-client can do that while starting itself, or can put a script at ltsp/init-ltsp.d
| |
| 06:02 | it can do that for any client, or only for ltsp clients
| |
| 06:02 | <vagrantc> only problem is one of "should we really be messing with that" vs. relying on services which are supposed to handle that
| |
| 06:02 | <alkisg> What do you think it should do?
| |
| 06:03 | I'm not sure that certificates are supposed to have a start date
| |
| 06:03 | <vagrantc> i'm fairly sure init-ltsp.d hook to touch the appropriate timesyncd file should work.
| |
| 06:03 | <alkisg> Yes, but that won't solve the problem in non-ltsp clients
| |
| 06:04 | <vagrantc> oh yeah, those other computers
| |
| 06:04 | <alkisg> :D
| |
| 06:04 | E.g. suppose that the epoptes-client manpage states: "if the certificate start date is in the future, epoptes assumes that the clock is broken, and updates it"
| |
| 06:04 | How reasonable is that?!
| |
| 06:05 | I don't see any downsides other than the initial "omg! that sucks!" :P
| |
| 06:05 | <vagrantc> i see the logic of it, but it's kind of stepping on other toes.
| |
| 06:05 | <maldridge> alkisg: X509 dictates that the start date is for allowing you to pre-generate certificates which will become valid at specific cases where you might want to "automatically" cut over from an outdated certificate
| |
| 06:06 | <alkisg> maldridge: yes, but what about *not* specyfing a start date because you don't need one?
| |
| 06:06 | <vagrantc> not specifying a start date sure would be a more elegant solution
| |
| 06:06 | <alkisg> I think not providing for that is similar to a bug... not just feature request
| |
| 06:06 | <maldridge> hmm, I don't think that's within spec, but I believe most things do tolerate that
| |
| 06:07 | * vagrantc wonders if there's an alternative to openssl that miht be more flexible | |
| 06:07 | <maldridge> I've always just set the start date to '0' and the end date to 2038
| |
| 06:08 | <vagrantc> well, that sounds like what alkisg is looking for
| |
| 06:08 | maldridge: how do you do that?
| |
| 06:09 | <maldridge> I actually didnt' write those scripts, another guy on my team did
| |
| 06:09 | I can ask him in the morning (its 0100 here)
| |
| 06:09 | <vagrantc> if it's already possible with the existing tools, that would solve the issue
| |
| 06:10 | <alkisg> I've seen other packages using faketime just to fool openssl
| |
| 06:11 | <maldridge> I believe it might be possible to set the server start date back to an earlier time and then generate it with a long window, but that might mess with other things when stuff gets installed
| |
| 06:11 | <alkisg> I do hope it's possible to set a blank or another start date, but I don't have high hopes for it...
| |
| 06:11 | maldridge: that's what we're using faketime for
| |
| 06:11 | We're setting the date back to 1970
| |
| 06:11 | (just for openssl)
| |
| 06:12 | <maldridge> yeah that would make sense
| |
| 06:12 | we're largely moving away from fake certs at my site, but that does seem like a good idea to do it that way
| |
| 06:16 | * vagrantc waves | |
| 06:16 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 06:16 | <alkisg> Good night vagrantc
| |
| 07:28 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2, Ping timeout: 260 seconds) | |
| 07:33 | kjackal has joined IRC (kjackal!~quassel@athedsl-4547229.home.otenet.gr) | |
| 10:58 | adrianorg has left IRC (adrianorg!~adrianorg@177.134.62.136, Ping timeout: 260 seconds) | |
| 10:58 | adrianorg has joined IRC (adrianorg!~adrianorg@187.113.217.202) | |
| 12:10 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 13:09 | adrianorg has left IRC (adrianorg!~adrianorg@187.113.217.202, Ping timeout: 276 seconds) | |
| 13:10 | adrianorg has joined IRC (adrianorg!~adrianorg@187.115.109.156) | |
| 13:31 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Quit: Leaving) | |
| 14:51 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 15:36 | kjackal has left IRC (kjackal!~quassel@athedsl-4547229.home.otenet.gr, Ping timeout: 276 seconds) | |
| 15:46 | <Leolo_2> nbd_server[32548]: Read failed: End of file
| |
| 15:49 | _longines has joined IRC (_longines!~longines@static.95.25.4.46.clients.your-server.de) | |
| 15:50 | <Leolo_2> Entering request loop
| |
| 15:50 | *Error: Read failed: End of file
| |
| 17:32 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:e113:dadf:2c9a:ae4) | |
| 18:18 | cor_geeks_eadthe has joined IRC (cor_geeks_eadthe!~cor@cpe-76-92-215-174.kc.res.rr.com) | |
| 18:19 | cor_geeks_eadthe is now known as cor_gfg_eadthem | |
| 18:23 | cor_gfg_eadthem has left IRC (cor_gfg_eadthem!~cor@cpe-76-92-215-174.kc.res.rr.com, Quit: Leaving) | |
| 18:23 | eadthem_cor_gfg has joined IRC (eadthem_cor_gfg!~cor@cpe-76-92-215-174.kc.res.rr.com) | |
| 18:31 | eu^8478164117 has joined IRC (eu^8478164117!544ea475@gateway/web/freenode/ip.84.78.164.117) | |
| 18:31 | <eu^8478164117> Γειἀ σας, παιδιά
| |
| 18:31 | eu^8478164117 has left IRC (eu^8478164117!544ea475@gateway/web/freenode/ip.84.78.164.117, Client Quit) | |
| 18:33 | <gehidore> and to you too
| |
| 18:35 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:e113:dadf:2c9a:ae4, Ping timeout: 260 seconds) | |
| 19:25 | robb_nl has joined IRC (robb_nl!~robb_nl@ip-83-134-2-39.dsl.scarlet.be) | |
| 19:25 | <alkisg> Haha, hello unknown greek person that joined the channel just to salute us...
| |
| 19:37 | <gehidore> yep
| |
| 19:46 | robb_nl has left IRC (robb_nl!~robb_nl@ip-83-134-2-39.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 23:48 | gateway has joined IRC (gateway!c83797bc@gateway/web/freenode/ip.200.55.151.188) | |
| 23:50 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 250 seconds) | |
| 23:50 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 23:57 | gateway has left IRC (gateway!c83797bc@gateway/web/freenode/ip.200.55.151.188, Quit: Page closed) | |