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


Channel log from 21 May 2016   (all times are UTC)

01:48Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 260 seconds)
01:52Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
02:04ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
03:50vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
04:11rac_ 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:57rac_ has left IRC (rac_!71148af6@gateway/web/freenode/ip.113.20.138.246, Ping timeout: 250 seconds)
05:05rac_ has joined IRC (rac_!71148af6@gateway/web/freenode/ip.113.20.138.246)
05:09rac_ 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:59ricotz 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:16vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
06:16
<alkisg>
Good night vagrantc
07:28kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2, Ping timeout: 260 seconds)
07:33kjackal has joined IRC (kjackal!~quassel@athedsl-4547229.home.otenet.gr)
10:58adrianorg has left IRC (adrianorg!~adrianorg@177.134.62.136, Ping timeout: 260 seconds)
10:58adrianorg has joined IRC (adrianorg!~adrianorg@187.113.217.202)
12:10ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
13:09adrianorg has left IRC (adrianorg!~adrianorg@187.113.217.202, Ping timeout: 276 seconds)
13:10adrianorg has joined IRC (adrianorg!~adrianorg@187.115.109.156)
13:31ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Quit: Leaving)
14:51ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
15:36kjackal 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:32kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:e113:dadf:2c9a:ae4)
18:18cor_geeks_eadthe has joined IRC (cor_geeks_eadthe!~cor@cpe-76-92-215-174.kc.res.rr.com)
18:19cor_geeks_eadthe is now known as cor_gfg_eadthem
18:23cor_gfg_eadthem has left IRC (cor_gfg_eadthem!~cor@cpe-76-92-215-174.kc.res.rr.com, Quit: Leaving)
18:23eadthem_cor_gfg has joined IRC (eadthem_cor_gfg!~cor@cpe-76-92-215-174.kc.res.rr.com)
18:31eu^8478164117 has joined IRC (eu^8478164117!544ea475@gateway/web/freenode/ip.84.78.164.117)
18:31
<eu^8478164117>
Γειἀ σας, παιδιά
18:31eu^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:35kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:e113:dadf:2c9a:ae4, Ping timeout: 260 seconds)
19:25robb_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:46robb_nl has left IRC (robb_nl!~robb_nl@ip-83-134-2-39.dsl.scarlet.be, Quit: I'm gone, bye bye)
23:48gateway has joined IRC (gateway!c83797bc@gateway/web/freenode/ip.200.55.151.188)
23:50ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 250 seconds)
23:50ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
23:57gateway has left IRC (gateway!c83797bc@gateway/web/freenode/ip.200.55.151.188, Quit: Page closed)